Re: Rebuilding all etch packages inside etch, round 2
On Wed, Oct 18, 2006, Lucas Nussbaum wrote: > I'm not going to process all the logs, so feel free to pick up some of > them and work on them. Maybe we should find a way to work together on > this ? (like a list of packages on wiki.d.o or in a svn repos ?) > Are there some wiki-like table edition tool ? I think a Wiki page would be nice. I'd like to clear my own build failures, and I suppose others as well. Now that I'm at it: - flumotion: python-central not installable, needs newer debhelper, should be ok now - gnome-python-desktop: python-central not installable, needs newer debhelper, should be ok now - rhythmbox: python-gtk2-dev not installable, needs newer python-gtk2, should be ok now -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding all etch packages inside etch, round 2
On Wed, Oct 18, 2006, Frans Pop wrote: > python-xml: Depends: python-central (>= 0.4.15) but it is not going > to be installed > I expect this is either a transient error or a bug in the python > packaging. I would probably be good if someone could check for this > globally. I got python-central installation failures in my logs as well, this is because debhelper was not available in a sufficiently high version, but should be fixed now. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: deluser on purge (was: Piuparts testing status update)
On Tue, Nov 14, 2006, Steve Langasek wrote: > > This is something that I'd really like to see us sort out in policy, since > > I think we should be able to describe consistent behavior with regard to > > system users and package purging to our users. Right now, every > > maintainer is making their own decision in this area, and I think that > > provides an inferior experience for users. > Every time the discussion has come up so far, there's been an absence of > consensus about whether it was correct to attempt to reclaim user ids on > purge. At this point, I found no objection to the proposal of having a configuration to decide to remove user on purge or to keep them. -- Loïc Minier <[EMAIL PROTECTED]> 10 SIN 20 GO TO ROBOT HELL -- Temple of Robotology -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ideas for additional large scale tests
Hi there, (We had a small exchange via private email with Lucas and he suggested we continue the discussion on debian-qa@, hence full text included below.) On Mon, Feb 26, 2007, Lucas Nussbaum wrote: > On 24/02/07 at 16:34 +0100, Loïc Minier wrote: > > Hi, > > > > I've been rebuilding the GNOME stack with a couple of interesting QA > > tests: > > - -Os in CFLAGS > > - -Wl,-O1 in LDFLAGS > > - -Wl,-z,defs in LDFLAGS > > - -j2 in MAKEFLAGS > > - use differents directories for builddir and srcdir > > > > Not all these tests are easily achieved with Debian packages. It was > > easier for me because I didn't dpkg-buildpackage these, I used a > > GNOME tool named jhbuild instead. > > > > These tests would be however interesting for Debian packages: > > - -Os is useful for embedded platforms > > - -Wl,-O1 gives better performances and might be promoted for all > >packages at some point > > - -Wl,-z,defs checks for missing link flags; this is a very useful test > >but it breaks with Python extensions > > - -j2 is interesting to catch errors in Makefiles and might be used in > >the future to speed up builds > > > > One way to easily test these flags might be to use wrappers for cc, > > gcc, c++, g++..., adding the flags. > > The main problem with testing -Os, -Wl,-O1 and -Wl,-z,defs is that they > could cause the compiler/linker to generate incorrect code instead of > just failing, and this is much harder to detect. I think -Os and -Wl,-O1 are more about testing our toolchain, but I think it's interesting to check whether this works on a large scale or in e.g. the GNOME stack because this has some direct benefit for people interested in the use of these flags and because it will improve our toolchain. I agree it might also produce broken binaries and that it would be hard to test, but it's a good first step into ensuring we could provide a "thin client optimized" archive for example. -Wl,-z,defs shouldn't cause any incorrect binaries; it should simply prevent the build in interesting cases, that is when some link flags are missing. The most problematic packages with -z defs are Python bindings which explicitely avoid linking to -lpython since the python interpreter is not linked to libpython, but provides the same symbols. > make -j2 looks really interesting. Yes; I expect it will expose some rare Makefile races (rare is in the context of GNOME since all modules are mostly automakized; other upstreams might have broken Makefiles :-) but it will certainly help us work toward building with parallel=$i, and I'm sure you would benefit of that! > Are you interested in working with me on that ? Well, I've got the tools to do the work over GNOME (jhbuild), and I'm busy enough that I'd prefer avoiding putting my finger in more general QA stuff. O:-) These were mostly suggestions as a followup to your request during your talk at FOSDEM of what tests you could run; it seemed you were requesting more ideas to keep more nodes busy. :) -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ideas for additional large scale tests
On Tue, Feb 27, 2007, Bastian Venthur wrote: > Just one thought: Why not test "-Wl,--as-needed" too? It should greatly > reduce the number of dependencies for most packages without the tedious > and error-prone task to re-libtoolize the package for every new release. --as-needed would also be a test, but it's too dangerous to do before everything builds with -z defs; I experienced breakage with this option between an application and its modules, and it was only visible at runtime. --as-needed also exposed toolchain issues on non-i386 arches, which _is_ interesting. :) > I'd also like to know how many percent of our packages which could be > re-libtoolized actually are re-libtolized (my guess is < 20%) and if we > can do something to improve the situation. Well, it would be nice to push the libtool patch upstream. My guess is that the recursive pulling of all libs could be kept in a separate field of the *.la files instead of suppressing that behavior completely, but I didn't look at the actual patch which was sent upstream (and not applied so far). -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Storing the bug summaries information in an SQL DB
On Tue, Mar 13, 2007, Lucas Nussbaum wrote: > Any comments/suggestions ? My comment is: great! You rock! -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Processed (with 1 errors): Re: Bug#418689: Please include packages NEWS file
# either -1 doesn't work with block or it needs "by" / "with" block 418689 with 419201 stop On Sat, Apr 14, 2007, Debian Bug Tracking System wrote: > > clone 418689 -1 > Bug#418689: Please include packages NEWS file > Bug 418689 cloned as bug 419201. > > block 418689 -1 > Unknown command or malformed arguments to command. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008, Raphael Geissert wrote: >gstreamer0.10-gnonlin-dev Fixed in SVN (useless package dropped). >libavahi-common-data (U) Ships a GDBM file which is arch-dep; shouldn't ship it in /usr/share though. >libdvb-dev (U) Only ships static libs; no idea why. >system-tools-backends-dev (U) Fixed in SVN; shipped an arch-indep pkg-config file which should be moved from /usr/share to /usr/lib. >vala-doc (U) I filed a bug on this one (I'm mostly sponsor-uploader). -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474211: Link to ffmpeg copyright file 403s
Package: qa.debian.org Severity: normal Hi, On http://packages.qa.debian.org/f/ffmpeg.html the link to the copyright file <http://packages.debian.org/changelogs/pool/main/f/ffmpeg/current/copyright> results in a 403. I don't know whether it's an issue with packages.qa.debian.org or packages.debian.org, please reassign as appropriate, but it seems /current isn't present on packages.debian.org/changelogs/pool/main/f/ffmpeg. Bye, -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Loïc Minier
Re: goal-recommends: new findings in testing
On Sat, Apr 05, 2008, Amaya wrote: > http://wiki.debian.org/ReleaseGoalRecommends I had a quick look at misc packages I could have fixed easily, but I fail to see why we would change a libgnomedb3-4-dbg recommends into libgnomedb3-4-dbg [!ia64], or python-imaging to python-imaging [!armel], or gnome-mag to gnome-mag [!m68k] etc. The bug for these seems to lie in missing builds, not broken dependencies (or these would be listed in Packages-arch-specific or something). -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#481315: PTS could avoid duplicate copies of messages
Package: qa.debian.org Severity: wishlist Hi, In the Debian GNOME Team, we're PTS subscribed to most of our packages, but for some of them the Maintainer: is set to the team's email address. What regularly happens is that the packages with the team as Maintainer end up subscribed to the PTS as well (because we switched the Maintainer field and didn't update the PTS), or we forget to subscribe a package to the PTS after changing to a real maintainer. This often leads to duplicate messages on our list (bug reports, testing migrations notes) or -- worse -- we don't see messages for some of our packages. It would be easier if we could simply subscribe to the PTS of all packages all the time, but the PTS would exclude the Maintainer: from the subscribers when sending emails which are already sent to the Maintainer upstream (debbugs, dak etc.). However, some people might actually like receiving the duplicates, so perhaps a new "duplicates" keyword is needed so that people actually wanting to receive the dups can susbcribe to that keyword and receive them. What do you think? Thanks, -- System Information: Debian Release: lenny/sid APT prefers hardy-updates APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 'hardy') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-16-generic (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: esound [was: Re: Non-related 'Recommends' dependencies - bug or not?]
On Tue, Jun 17, 2008, Martin Pitt wrote: > That's interesting indeed! So you avoid that by using an OSS driver > instead of the ALSA one? I can really not imagine how esound on top of > a broken ALSA driver would sound better than just using the ALSA > output directly? It might normalize which sampling rate / sample width is used -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Monitoring debian/shlibs.local files?
On Sun, Dec 21, 2008, Cyril Brulebois wrote: > I'm wondering whether it might be a good idea to track those in source > packages, so as to make sure bugs got filed, and that those files go > away. Having a fixed shlibs file would be profitable to all packages > linking against this library, rather than having a single package > getting its dependencies properly, through its shlibs.local file. I'm all for it; over time I came across a bunch of broken packages due to shlibs.local files, or simply with the risk of these files bitrotting and causing issues later. Just like we have descriptions for patches, we could require a description for shlibs.local, perhaps with a #xx bug in the text; when enough packages drop shlibs.local or implement the comment, we can add a lintian tag. I would expect not too many packages should keep it though; it's probably cruft in most cases. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Monitoring debian/shlibs.local files?
On Sun, Dec 21, 2008, Cyril Brulebois wrote: > (generated by the Makefile in ~kibi/shlibs-check.git, on gluck.) attached dd-list with uploaders sed -n '/^#/!s/:$//p' mapping.list | dd-list -i -u -- Loïc Minier Guenter Geiger (Debian/GNU) jack-audio-connection-kit (U) rezound Jacek Śliwerski (rzyjontko) elmo Bill Allombert libjpeg6b Kumar Appaiah festival (U) Hakan Ardo libcompface maximilian attems usplash Mirco Bauer mono (U) Christian Bayle gatos Christoph Berg xar Bastian Blank cdebconf (U) Jérémy Bobbio cdebconf (U) Jeff Breidenbach leptonlib Ludovic Brenta monotone (U) Marc 'HE' Brockschmidt gail (U) Phil Brooke topal Mark Brown nis nis (U) Thomas Bushnell, BSG gnucash Martin Buck xview Marco Cabizza control-center Ondrej Certik blas (U) lapack (U) Joost Yervante Damad glew Debian CLI Applications Team tangerine Debian GIS Project proj Debian GNOME Maintainers control-center (U) gail librsvg (U) Debian Install System Team cdebconf Debian Mono Group mono Debian Multimedia Team jack-audio-connection-kit Debian OpenMPI Maintainers openmpi Debian Qt/KDE Maintainers kdepim Debian Scientific Computing Team blas lapack Debian Tcl/Tk Packagers itcl3 itcl3.1 Debian VoIP Team iaxclient libosip2 ser Matthieu Delahaye libunwind Yann Dirson tulip Sebastian Dröge control-center (U) gail (U) librsvg (U) mono (U) tangerine (U) Dirk Eddelbuettel openmpi (U) r-base r-base-core-ra rmysql Robert S. Edmonds adns Mark W. Eichin owl Free Ekanayaka jack-audio-connection-kit (U) Carey Evans tn5250 ExpPsy Maintainers pyode Arnaud Fontaine tuxonice-userui Charles Fry courierpassd courierpasswd courieruserinfo Peter S Galbraith proj (U) RISKO Gergely freecell-solver mcrypt Sergei Golovan itcl3 (U) itcl3.1 (U) tcl8.3 (U) tcl8.4 (U) tcl8.5 (U) tk8.3 (U) tk8.4 (U) tk8.5 (U) Debian QA Group ftplib metamail prestimel saods9 smtpguard waproamd wsoundserver Yaroslav Halchenko pyode (U) Brandon Hale tangerine (U) Michael Hanke pyode (U) Chris Hanson uudeview Sam Hartman barnowl Paul Hedderly vstream-client HJ Heins iceape (U) Joey Hess cdebconf (U) Mike Hommey iceape (U) David Härdeman usplash (U) Jan Janak ser (U) Matthew Johnson lirc (U) LaMont Jones util-linux xdelta Muammar El Khatib scalapack Tatsuya Kinoshita eb Michael Koch sdl-image1.2 Kilian Krause iaxclient (U) libosip2 (U) ser (U) Anand Kumria libosip2 (U) Mario Lang gail (U) Sylvestre Ledru lapack (U) openmpi (U) Micha Lenk kmymoney2-plugin-aqbanking Richard Levitte monotone (U) Faidon Liambotis iaxclient (U) Anselm Lingnau tcl8.3 (U) tcl8.4 (U) tk8.3 (U) tk8.4 (U) Stefan Lippers-Hollmann lirc (U) lirc Maintainer Team lirc Ana Beatriz Guerrero Lopez kdepim (U) Francesco Paolo Lovergine proj (U) Sven Luther gnome-randr-applet Marcelo E. Magallon glew (U) mesa-legacy Mikael Magnusson iaxclient (U) Camm Maguire blas (U) lam lapack (U) xmpi Maintainers of Mozilla-related packages iceape Santiago Garcia Mantinan swfdec-mozilla Patrick Matthäi geoip Alastair McKinstry console-tools slang2 Remco van de Meent gsnmp libsmi A Mennucc1 libppd Samuel Mimram sdl-ttf2.0 Loic Minier control-center (U) gail (U) librsvg (U) Jim Mintha slang2 (U) Kartik Mistry festival Emilio Pozuelo Monfort librsvg (U) Debian Maintainers for Monotone monotone Josselin Mouette control-center (U) librsvg Ramakrishnan Muthukrishnan ygl (U) Sven Müller lirc (U) Mark Nevill libxdg-basedir Jaakko Niemi sfs Sam Hocevar (Debian packages) sdl-ttf2.0 (U) Barak A. Pearlmutter adolc Andrei Pelinescu-Onciul ser (U) Ari Pollak pidgin Frans Pop cdebconf (U) Manuel Prinz openmpi (U) Mark Purcell iaxclient (U) libosip2 (U) ser (U) Prabhu Ramachandran ygl Petter Reinholdtsen usplash (U) Andreas Rottmann guile-gnome-platform Miriam Ruiz libxdg-basedir (U) Alexander Sack iceape (U) Anibal Monsalve Salazar pcp (U) xfsdump (U) Darren Salt xine-lib (U) Otavio Salvador usplash (U) Niv Sardi xfsdump (U) Nathan Scott pcp xfsdump Jo Shields mono (U) Raúl Sánchez Siles kdepim (U) Miquel van Smoorenburg nis (U) Roger So im-sdk im-sdk (U) Jose Carlos Garcia Sogo tangerine (U) Clément Stenac libcddb Al Stone libunwind (U) Tatsuki Sugiura libfcgi Akira TAGOH im-sdk (U) NOKUBI Takatsugu namazu2 Reinhard Tartler xine-lib Michael Tautschnig dia
Re: Monitoring debian/shlibs.local files?
On Mon, Dec 22, 2008, Adeodato Simó wrote: > it is also with ideas like this that i regret that our policy process > won't allow for a top-down flow of recommendations. imho this would be a > nice use for it, once consensus was be reached that this is a good idea. The good thing is that lintian people are quite open to clever changes; this gives us immediately: - a mean to test a package - a mean to tell maintainers about it (if they run lintian) and hence put the actual work on their side - an up-to-date db of the affected packages (lintian.d.o) -- Loïc Minier -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: piuparts PTS integration
On Tue, Mar 17, 2009, Lucas Nussbaum wrote: > First, real piuparts failures are usually real RC bugs. If they are only > reported to the PTS, they won't be properly tracked by the release team, > for example. Are you planning to actively report bugs on piuparts > failures in addition to reporting them to the PTS? Have you reported > bugs on the piuparts failures you found so far? This is comparable to build failures; buildd logs are linked from the PTS. > Second, since piuparts failures are real bugs, they should be "pushed" > to the maintainer. I don't think that adding them to the PTS web page is > a "pushy-enough" way to provide that information to maintainers. > Instead, the PTS mail interface could be a nice way to inform the > maintainer of failures. > > Third, in my experience, piuparts generates a lot of false positives, > that are either: > - minor bugs (like corner-cases related to symlinks) > - bugs in other packages (packages failing because one of their > dependencies is failing) > Before information is provided automatically to maintainers, I would > like to see numbers about percentage of false positives. Is piuparts > really ready for that? I think the false positive problem is a good reason to avoid sending emails and a good reason to link the logs from the PTS to allow maintainers to read them if they like to. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
