Re: Synching mirrors and clients (was: Re: apt-proxy v2 and rsync)
On Thu, Nov 04, 2004 at 05:46:55PM +0100, Otto Wyss wrote: > > Now if you feel advantous, repack as many package on the source mirror > with gzip --rsyncable and notice the difference. Exactly how is this going to help? I can only see this as being useful when the files change. Files should never change. You get a completly new file. Unless you can somehow tell to use the old file as base, this is not going to help. Kurt
Re: Linux Core Consortium
On Sun, Dec 12, 2004 at 08:29:16PM +0100, Goswin von Brederlow wrote: > Tollef Fog Heen <[EMAIL PROTECTED]> writes: > > > The problem is not the autobuilder infrastructure per se. It is that > > testing and unstable are largely in sync (!). This, combinded with the > > fact that testing must not have versions newer than unstable (they > > will then be rejected) means testing-security wouldn't work at the > > moment. > > How is that different from testing-proposed-updates? Because they're ussualy for fixing bugs in testing where there is an other version in unstable? Why else would you be using testing-proposed-updates? Kurt
Re: For people more knowledgeable about buildds...
On Tue, Jan 04, 2005 at 10:13:11PM +1100, Andrew Pollock wrote: > Hi, > > Is there a webpage that shows the current queue of packages in Needs-Build > state? igloo's pages are great, but they only let you know the position in > the queue of a package, not what's before or after it (out of curiosity). buildd.debian.org/stats Kurt
Re: Manpages licensed under GFDL without the license text included
On Sun, Jan 09, 2005 at 01:20:15PM -0500, Joey Hess wrote: > Bernhard R. Link wrote: > > Looking into sarge I found a number of manpages, that do not look > > redistributeable as they are licensed under the G"F"DL but do not > > include the full licence text needed to be distributeable. Especially > > Debian-specific ones seem to be affected due to some templates debhelper > > contained in the past. > > Debhelper has never contained "templates". He probably means dh-make. Kurt
Re: Bug#292831: udev: udev prevents X from beeing started
On Mon, Jan 31, 2005 at 03:46:50PM +1100, Hamish Moffatt wrote: > On Mon, Jan 31, 2005 at 05:31:03AM +0100, Joey Hess wrote: > > Marco d'Itri wrote: > > > My package works as designed, but let me know if you can design > > > something better. > > > > Oh, so it's udev that's responsible for what IIRC is a race that can > > cause X to not see the ps/2 mouse if the module is loaded as part of X's > > setup? Nice design. :-P > > > > FWIW, we have worked around this bug in d-i unstable for at least i386 > > and amd64 by always putting psmouse in /etc/modules. > > I did an amd64 install last week from the (then) current install image > and didn't end up with psmouse in /etc/modules; I added it by hand when > I found that udev was preventing X from starting. :-( I only commited it for amd64 to ddetect yesterday, and it's not uploaded yet. It already had it for i386 and ia64 (and some powerpc subarches). Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
On Fri, Feb 04, 2005 at 12:47:28PM -0200, Henrique de Moraes Holschuh wrote: > It would be better to set up a arch-indep > autobuilder (on a FAST machine that can handle pbuilder's unpacking of > chroots, so that chroot crappage won't happen so often) and file FTBFS > automatically. We build all binary all packages as part of the amd64 port. All that fail to build should have been filed in the BTS, although I'm ussualy slower looking at those package than others. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: About valid and invalid user names
On Sat, Feb 05, 2005 at 01:38:36PM +0100, Marc Haber wrote: > Hi, > > adduser has two bug reports open where people are asking for user name > rules to be relaxed. One report wants "." to be allowed in user names, > another wants usernames to start with numbers. > > May I ask for your opinion before denying or following the requests? Let's quote SUS a little. Base def (Definitions) Login Name A user name that is associated with a login. User ID A non-negative integer that is used to identify a system user. When the identity of a user is associated with a process, a user ID value is referred to as a real user ID, an effective user ID, or a saved set-user-ID. User Name A string that is used to identify a user; see also User Database . To be portable across systems conforming to IEEE Std 1003.1-2001, the value is composed of characters from the portable filename character set. The hyphen should not be used as the first character of a portable user name. Portable Filename Character Set The set of characters from which portable filenames are constructed. A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 . _ - The last three characters are the period, underscore, and hyphen characters, respectively. >From the chown utility: The following operands shall be supported: owner[:group] A user ID and optional group ID to be assigned to file. The owner portion of this operand shall be a user name from the user database or a numeric user ID. Either specifies a user ID which shall be given to each file named by one of the file operands. If a numeric owner operand exists in the user database as a user name, the user ID number associated with that user name shall be used as the user ID. Similarly, if the group portion of this operand is present, it shall be a group name from the group database or a numeric group ID. Either specifies a group ID which shall be given to each file. If a numeric group operand exists in the group database as a group name, the group ID number associated with that group name shall be used as the group ID. [...] The BSD syntax user[. group] was changed to user[: group] in this volume of IEEE Std 1003.1-2001 because the period is a valid character in login names (as specified by the Base Definitions volume of IEEE Std 1003.1-2001, login names consist of characters in the portable filename character set). The colon character was chosen as the replacement for the period character because it would never be allowed as a character in a user name or group name on historical implementations. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debug packages cluttering the archive
On Sun, Feb 06, 2005 at 01:14:09AM -0500, Glenn Maynard wrote: > On Sat, Feb 05, 2005 at 10:33:53PM -0700, Joel Aelwyn wrote: > > It was brought up on IRC, a couple of weeks ago (my apologies, but I don't > > recall who brought it up, nor do I have a log) that it is now possible > > to strip debugging information from a binary or library, and keep the > > debugging information in a separate file. When invoking GDB (I don't know > > (Aha: the strip tool mentioned is in elfutils, which is non-free. Blah.) You can do this with strip and objcopy, see the manpage for --only-keep-debug Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The ghost of libc-dev
On Thu, Feb 17, 2005 at 02:05:56PM -0700, Joel Aelwyn wrote: > > *) The standard way of doing this today is to have a -dev package which > needs libc headers Depend on 'libc6-dev | libc-dev' to avoid the situation > of having only a pure-virtual package. Why does that rule exists anyway? It's already part of build-essential. And build-essential is already defined for each arch. > *) On further reflection, and re-reading other parts of the thread, I think > it might be more useful to try to implement the following, and I would like > feedback on whether this needs adjustment, or people think it would be a > good idea. If it works, I can publish it as it's own tool, or try to get it > included in the debhelper package (the latter probably being prefferable). > > dh_devincludes I was also thinking about something like that some time ago. I'm just afraid it's not going to be very easy to get correct. > Searches the target package for *.h files, then searches each file found > for #include lines. Attempts to resolve each include, checking first the > package area, then the system library area. If the file is found in the > package, it is ignored; if not found at all, it throws a warning. However, > if the package is found in the system area, it checks the installed files > information and extracts the name of the package which provides that file. > The list of packages found is places into the substvar dev:Depends. I was thinking about libtool .la files and pkgconfig .pc files and looking at the libraries they require. (In case they are using it.) > * Does it need some way (a la shlibs) to resolve problems with "what > version of the -dev package is needed for this", or is this likely to be > uncommon enough to expect the maintainer to override it where necessary? I think there are lots of cases where there currenctly is a versioned dependency on a -dev package. However, I'm not sure if all of them are needed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Does this break binary compatability on 64bit architectures?
On Thu, Feb 24, 2005 at 05:53:02PM +0300, Nikita V. Youshchenko wrote: > Hello. > > Upstream of a library package that I maintain changed function prototypes > in the followinf way: > > > > > -int mailpop3_retr(mailpop3 * f, uint32_t index, char ** result, > > +int mailpop3_retr(mailpop3 * f, unsigned int index, char ** result, > > size_t * result_len); > > That is, 'uint32_t' was changed to 'unsigned int'. > > Does this break binary compatability on any of debian architectures (so > soname change is needed)? Afaik, on all 64 bit arches in debian an int is still 32 bit. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gcc-3.3 3.3.5-9 C++ ABI problem.
Hi, gcc-3.3 3.3.5-9 was build with the configure option --disable-__cxa_atexit instead of --enable-__cxa_atexit. This causes it to have a different C++ ABI. This was fixed in the 3.3.5-10 which should be available soon. I've made a list of source packages that might have been build with the 3.3.5-9 version so far. This is based on all packages uploaded after the gcc-3.3 3.3.5-9 package. This is a list of source package who have a binary package with a dependency on the libstdc++5 package. This list is probably not complete since people can still be uploading packages with this broken ABI. Please make sure you either have the 3.3.5-8 or 3.3.5-10 version installed if you are uploading a new package. This is the list of source packages: acovea akregator bidentd bincimap capi4hylafax capisuite cloop cmt d4x flwm glibmm2.4 gtkmm2.4 gtkwave k3b kcdlabel kino kismet knetfilter kwave latd lcdf-typetools mozilla-firefox mysql-query-browser nmap octave2.1 openam openh323 oprofile poedit sdcc sms-pl synaptic t38modem tagtool tora trackballs wine wipl Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where are the files of tetex-bin_3.0-1?
On Fri, Mar 11, 2005 at 07:45:23PM +0100, Frank Küster wrote: > (Cc to -devel, because this might be of general interest). > > Hello, > > on Tuesday I got a mail from katie that tetex-bin_3.0-1 was accepted, > but the files don't seem to be in the archive. There was a problem with katie stopping halfway in it's run for 2 days. It stopped on and old mlterm twice, so anything that's in the alphabet after that wasn't processed for 2 days. This was fixed and all the packages should be available in a few hours. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
On Sun, Mar 13, 2005 at 12:04:59PM +, Henning Makholm wrote: > Scripsit Daniel Schepler <[EMAIL PROTECTED]> > > > - Putting autoconf-generated files in the source package is nearly as > > fragile as generating them at build time. If there are changes in > > autoconf which break the configure.ac etc, then the next time you want > > to make other changes or bring your changes forward to a new upstream > > version, you'll have to fix things anyway. This to my mind pretty > > much reduces the "future buildability" benefits to nearly nothing. > > That's a reason *contra* in my opinion. > > When I include the configure script in my source packages, I can feel > pretty confident that they package I upload will stay buildable even > if a week from now autoconf or automake gets updated to something not > backwards compatible. Some arches for instance have problems with old versions of libtool resulting in a broken configure on only those arches. Now they have to file a bug report asking for a libtool update to the latest (debian) version. It _could_ be handy that such requests weren't needed. Note that I do understand your argument that a new version could break. But we do have autoconf, autoconf2.13, automake1.4, automake1.6, automake1.7, automake1.8, automake1.9, libtool, libtool1.4. You can build-depend on the version that you require. However, I do understand that if you just build-depend on autoconf and you suddenly have to change to autoconf2.13 because they changed the version to 2.5x and your script doesn't work with autoconf 2.5x you have a problem. But sooner or later you will have to do something about the problem anyway. You can't stay using autoconf2.13 for ever. Some day that version will get removed from the archive. Just like libtool1.4 is already orphaned and planned to be removed after sarge gets released. An other argument that was only vaguely mentioned was that you can look at configure.in/ac as source. Some people seem to disagree with this but I haven't seen their arguments for it. I don't think I can agree to their arguments anyway. The same goes for things like bison. We do not have a requirement that everything is build from source, only that we should be able to do so. But I think it's a good idea to always build everything from sources. If you have to fix something, it's always going to be easier to fix in the source. And how can you know you can actually build it if you never tried it? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: automake/autoconf in build-dependencies
On Sun, Mar 13, 2005 at 02:02:29PM +, Henning Makholm wrote: > Scripsit Kurt Roeckx > > > And how can you know you can actually build it if you > > never tried it? > > That's the point, actually: If I build-depend on autoconf, I *cannot* > know that it will actually build after the next update to autoconf, > because most likely nobody will try it. If it's known that a new major version of autoconf is uploaded to the archive that might break some packages, it's rather easy to see which packages build depend and you can very if they still work or not. This goes for all build dependencies for a package. Also, there are some people (including me) who rebuild the whole archive regularly (but uncoordinated) to look for pacakges that no longer build. There are more things than just autoconf updates that make packages suddenly fail to build. Or are you saying that all build dependencies should be removed, since they all can cause you problems. Maybe you want to have everything your packages requires to build in your .orig.tar.gz file? Including things like all headers from libc and gcc. You know, gcc might change some day and your package might no longer build because it's more strict about some things, maybe you should also include your own copy of gcc in it for all arches. I find the argument that it might break some time because of new version your package build depends on a bad reason. Where does that stop? Some packages for instance have their own copy of libz or gettext included. I find that a bad thing, they should all be changed to build depend on the packages that provide it and not use the included version if possible. There are several reasons why you want that, one of them being that it's alot easier to have all packages fixed if there is a security bug found in one of those packages. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
On Mon, Mar 14, 2005 at 09:44:33AM +1100, Matthew Palmer wrote: > On Sun, Mar 13, 2005 at 11:17:52PM +0100, Andreas Barth wrote: > > Because we want packages in base to be preferred, as well as packages in > > libs. > > I think I slightly misunderstood the "ordering by section" bit -- I was > assuming an alphabetical ordering by section. So once base and libs have > had their priority building, what's the ordering after that? Alphabetical > by section, or does it go straight into a alphabetical by package name? There is a list in wanna-build for each section. The start of it looks like: libs debian-installer base devel shells perl python If you want to full list, look at the source. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible freetype transition; improved library handling needed for all C/C++ packages
On Thu, Nov 24, 2005 at 02:43:14PM +0100, Peter Eisentraut wrote: > Steve Langasek wrote: > > * Use Debian's libtool. > > kmldonkey links with the following libraries: -lkdeui -lkio. As shipped, > libtool expands that to every library under the sun. The new libtool > indeed reduces this to /usr/lib/libkdeui.so /usr/lib/libkio.so and a few > system libraries/objects, which is then greeted by ld with hundreds of > error messages of the kind: > > /usr/share/qt3/include/qstring.h:847: undefined reference to > `QString::shared_null' > /usr/share/qt3/include/qstring.h:848: undefined reference to > `QStringData::deleteSelf()' kmldonkey seems to have alot (26?) includes of qstring.h, so to me this doesn't looks like a bug in libtool but rather in your package not linking to all the libraries it should be. It just used to work, which is not an excuse for not having a build dependency on it or linking to it. > Both libkdeui and libkio reference (as shown by ldd) libqt-mt (which > I suppose is where these symbols should be). So you probably should add a build dependency to libqt3-mt-dev, and add a -lqt-mt > The error messages in the rekall build are of the sort > > .../rekall-2.2.3-2/db/mysql/kb_mysql.cpp:595: undefined reference to > `i18n(char const*)' Which is defined in /usr/include/kde/klocale.h, so that would be part of kdelibs, and seems you need to link to -lkdecore for that, which you don't seem to link atleast for that. (Also see libs/common/kb_classes.h:408) > Have other maintainers of Qt/KDE-related packages > perhaps experienced this? I'm not sure many people have actually tried to get things right, since it "just works". I hope more people actually look at their packages, and maybe ask for help if they can't figure it out themself. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible freetype transition; improved library handling needed for all C/C++ packages
On Sun, Nov 27, 2005 at 11:48:37PM +1100, Hamish Moffatt wrote: > > I've trimmed the configure scripts to avoid this, leaving me with the > link commands for the two binaries being: > > g++ -Wall `"/usr/bin/wx-config" --cxxflags` -I/usr/include -I/usr/include > -I/usr/include -g -O2 -o tqsl tqsl.o extwizard.o tqslwiz.o dxcc.o > stationdial.o qsodatadialog.o tqslvalidator.o tqsl_prefs.o wxutil.o -pthread > -lwx_gtk-2.4 -ltqsllib > > However, my built package depends on zlib1g, which it doesn't use > directly and doesn't -l during link. ./tqsl.cpp:#include And on line 691 you have a gzFile, 1157 calls gzopen, ... Your configure script also checks for it, and adds it. linking tqslcert to -lz doesn't seem to be needed though. > I'd welcome any suggestions on how this might be... dpkg-shlibdeps bug? This is a linker feature which I dislike. It adds missing libraries if one of the libraries you link to happens to be linked to the one you need. For more info see: http://sourceware.org/ml/binutils/2005-09/msg00200.html Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
On Mon, Dec 05, 2005 at 10:43:15PM +0100, Thomas Viehmann wrote: > Hi, > > Vincent Sanders wrote: > > [1] http://buildd.debian.org/~jeroen/status/architecture.php?a=arm > > taking a "random" (end of alphabet) sample from maybe-failed: > > twinkle: requeue (probably libccrtp was stuck in NEW) Just try to install the build dependencies for it on any arch. They are not available. There is a reason this has failed on all arches. The problem is that libccrtp1-1.3-0 is still linked to libcommoncpp2-1.3c2 instead of libcommoncpp2-1.3c2a. > wvstreams: Dep-Wait (libxplc0.3.13-dev) - dep in new queue, see #340696 > xchm: retry (needed libchm-dev) This can probably be requeued indeed. But it would help if the maintainer uploaded xchm after libchm was in installed state on all arches, so buildd admins don't have to look at this. > xmms-openspc: arch specific (says maintainer in control) > zinc-compiler: arch specific dependency (ghc6) So those should get added to P-a-s instead. > visualboyadvance: buggy, could requeue to get #334727 What's the point to requeue if this bug isn't fixed? > weechat: don't know, error on dh-strip on 5 archs, no bug filed > > That's 2 out of 7 which need actual debugging, both not arm-specific. And only 1/7 where some action of the buildd maintainer is needed at this time to get something build. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
On Tue, Dec 06, 2005 at 11:51:00AM +0100, Thomas Viehmann wrote: > Hi, > > hotkey-setup: might also work on amd64 ia64 (depends on dmidecode) > OTOH, maintainer usually seems to know what he's doing... Also see #331280. Afaik, there is no reason this couldn't be changed to work on other arches. It's not because something doesn't build now it it that it should get added to P-a-s. > libpam-encfs: isn't arch-specific, see #340575. Maybe random arch > disabling should be RC... Also see the release policy about this: http://release.debian.org/etch_rc_policy.txt > prj2make-sharp: i386 powerpc s390 > # amd64: #314517 without maintainer comment > # ia64 arm unknown, others disabled in P-a-s It's a mono packages, and that currently only supports a limited number of arches. P-a-s is correct in it that it should attempt to build it on all of those, there is no reason to think it shouldn't work on those. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sparc build failure analysis (was Re: StrongARM tactics)
On Sun, Dec 11, 2005 at 05:55:23AM -0800, Steve Langasek wrote: > > > Indeed, for practical buildd maintainance purposes, the distinction is > > not that important -- though 'Failed' is known to not benefit of a > > requeue, while 'Building:Maybe-Failed' might or might not, it's unkown, > > most archs should have enough surplus buildd power that retrying > > everything once in a while doesn't hurt. > > > The major benefit is though to make it apparant for porters what to look > > into, without all the 'noise' in between of maybe-transient failures. > > One could also make sure that the FTBFS bugs are tagged (user-tagged) > > with [EMAIL PROTECTED] (etc) for example (or [EMAIL PROTECTED] There > > doesn't exist a [EMAIL PROTECTED] for example...), so that one can get a > > nice overview of all the porting bugs. It'd make sense to synchronise > > this across all architectures, so that it is consistent. > > http://lists.debian.org/debian-alpha/2005/12/msg00028.html I have a long list of bug affecting amd64, but I haven't started with usertags for it. The (FTBFS) bugs I encouter (as buildd admin) are: - General bugs affecting all arches. - General bugs affecting 64 bit arches. - Bugs affecting some arches (like not using -fPIC) - Bugs only affecting amd64. And the later really is the minorty of the problems. Note that this does not cover runtime problems or something like that, but they're very simular. Do we need to have a special usertag for the first kind? This is basicly something everybody can look at. The only reason I can think of that it requires some tag is that it's better then looking at those that don't have a tag. So, I'm open for suggestions on how to tag the first 3 of those. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ldd -u (Re: Solving recursive dependency disease in KDE-based packages)
On Sun, Dec 11, 2005 at 04:56:08PM +0100, Adeodato Simó wrote: > * Nathanael Nerode [Sun, 11 Dec 2005 07:35:41 -0500]: > > > To work out which libraries you're linked to which you don't actually > > need, > > ldd -u is invaluable. > > This seems like not the case _at all_ to me (the "invaluable" bit): > > % ldd -u /usr/lib/amarok/amarokapp > Unused direct dependencies: ldd -u /usr/lib/amarok/amarokapp ldd: unrecognized option `-u' Try `ldd --help' for more information. This atleast doesn't even seem to work on all arches either. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ldd -u (Re: Solving recursive dependency disease in KDE-based packages)
On Sun, Dec 11, 2005 at 05:02:15PM +0100, Kurt Roeckx wrote: > On Sun, Dec 11, 2005 at 04:56:08PM +0100, Adeodato Simó wrote: > > * Nathanael Nerode [Sun, 11 Dec 2005 07:35:41 -0500]: > > > > > To work out which libraries you're linked to which you don't actually > > > need, > > > ldd -u is invaluable. > > > > This seems like not the case _at all_ to me (the "invaluable" bit): > > > > % ldd -u /usr/lib/amarok/amarokapp > > Unused direct dependencies: > > ldd -u /usr/lib/amarok/amarokapp > ldd: unrecognized option `-u' > Try `ldd --help' for more information. > > This atleast doesn't even seem to work on all arches either. So that seems to be caused by having ia32-libs installed, which still has an older glibc version. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On Wed, Dec 14, 2005 at 11:25:03AM +1100, Anand Kumria wrote: > > [1]: As I write this 79 NEW packages, 85 total. Then ftp-master must be really busy, since it's now 64, total 69. Also note that most of those packages in new aren't even a week in it, alot aren't even a day old. I think they're doing a really good job, even with the number of packages being so high because of the ongoing C++ transition. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: urgency='low' testing propogation only 5 days for gtk+2.0?
On Fri, Dec 16, 2005 at 06:10:11PM -0500, Justin Pryzby wrote: > It is my understanding that an urgency='low' upload defines a 10 day > delay in testing propogation, unless overridden by hints. > > However, yesterday's gtk+2.0 upload indications only a 5 day delay. > Why? > > http://packages.qa.debian.org/g/gtk+2.0.html 2.6.10-2 was uploaded with urgency medium and didn't reach testing yet, it only has 2.6.10-1. It keeps the highest urgency since the last version that reached testing. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Sun, Dec 18, 2005 at 08:34:04PM +0100, Frank Küster wrote: > > > > Six months is a lot of time; and experimental should provide you with > > the space and machine power to handle the rebuilding. > > I don't know of any autobuilders that build packages from sid against > build-dependencies in experimental. I thought I did build alot of packages from sid against your tetex from experimental, and reported the results to you. I guess you found more problems after the ones I got? Anyway, I'm willing to do build tests for such things. Feel free to ask me. I'd rather have that those bugs are known before they hit unstable. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Tue, Dec 20, 2005 at 09:54:34AM +0100, Frank Küster wrote: > Kurt Roeckx <[EMAIL PROTECTED]> wrote: > > On Sun, Dec 18, 2005 at 08:34:04PM +0100, Frank Küster wrote: > >> I don't know of any autobuilders that build packages from sid against > >> build-dependencies in experimental. > > > > I thought I did build alot of packages from sid against your > > tetex from experimental, and reported the results to you. I > > guess you found more problems after the ones I got? > > Thank you very much, that was indeed a great help. But you didn't build > all, and that was okay at that time, since we detected that some > often used something-to-LaTeX converters had bugs that led to FTBFS, and > it didn't make sense to continue before those would be fixed. I think I > asked you a couple of questions during debugging, and while you were > very responsive at the beginning, you stopped answering at some point, > and I assumed you simply didn't have any time left, when mass building > started to make sense again. Probably I should have asked you > explicitly. It does help if you ask. I don't have the time to keep up with everything that is going on, and forget about such things. > > Anyway, I'm willing to do build tests for such things. Feel free > > to ask me. I'd rather have that those bugs are known before they > > hit unstable. > > Is there a list of packages that have not been built by the autobuilders > since a certain date? After subtracting those with known FTBFS bugs, it > would make sense to rebuild them. The same is true for Architecture: > all packages that didn't have an upload since teTeX 3.0 is in unstable. There are various people who rebuild whole unstable on regular basis. Now that it's actually in unstable for a long time, someone should have picked up those failures already. I'll ussually build everything from testing against testing, but I'll start one for unstable later today. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian "experimental"
On Fri, Dec 30, 2005 at 04:12:23PM +0100, Michal Piotrowski wrote: > Hi, > > I have noticed that directory > debian/dists/experimental/main/binary-i386 is empty. > Where is new "experimental" repository? -rw-r--r-- 1 mirror mirror 1288427 2005-12-29 21:14 Packages drwxr-sr-x 2 mirror mirror4096 2005-12-29 21:51 Packages.diff -rw-r--r-- 1 mirror mirror 246604 2005-12-29 21:14 Packages.gz -rw-r--r-- 1 mirror mirror 104 2005-12-29 21:51 Release That doesn't look empty to me? Maybe it's on your mirror? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian "experimental"
On Fri, Dec 30, 2005 at 04:48:06PM +0100, Michal Piotrowski wrote: > Hi, > > deb http://ftp.debian.org/debian/ experimental main contrib non-free > deb-src http://ftp.debian.org/debian/ experimental main contrib non-free So why do you use ftp.debian.org and not ftp.pl.debian.org for experimental? > http://ftp.debian.org/debian/dists/experimental/main/binary-i386/Packages.gz: > 404 Not Found So ftp.debian.org seems to be broken. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
On Sat, Jan 07, 2006 at 03:09:34PM +0100, Josselin Mouette wrote: > Le vendredi 06 janvier 2006 à 14:28 -0600, Alejandro Bonilla a écrit : > > /usr/lib/libgconf2-4/gconf-sanity-check-2: error while loading shared > > libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such > > file or dir > > Ladies and gentlemen, this is a perfect example of why linking indirect > dependencies is a very bad thing. Let me explain. Linking indirect dependency isn't a good thing, but not linking to them isn't magicly going to fix bugs like this. > Of all binaries shipped with GConf, gconf-sanity-check is the only one > using GTK+. The only application using gconf-sanity-check is > gnome-session. On first sight, it looks safe to exclude > gconf-sanity-check for the computation of gconf dependencies, as > gnome-session will always require libgtk2.0-0, and gconf-sanity-check > isn't susceptible to use any symbols that could be added to GTK+. You should _never_ exclude anything for the calculation of the dependencies, because it will result in such errors. Even if you think some other dependency will (now) take care of this for you doesn't mean you shouldn't have a depends on it. There are cases where excluding something can make sense, but this isn't one of them. > Now, let's have a look at gconf-sanity-check: > NEEDED libgtk-x11-2.0.so.0 [...] > NEEDED libpangocairo-1.0.so.0 [...] So gconf-sanity-check-2 (from the libgconf2-4 package) NEEDS libpangocairo-1.0.so.0 from the libpango1.0-0 package. So libgconf2-4 should depend on libpango1.0-0. And it doesn't. This is an RC bug in the libgconf2-4 package. It's also missing all those other depends, specially the one on libgtk2.0-0. > The only libraries from which it actually uses symbols are libgconf2, > libgtk-x11, libglib and libc. It seems to be: libgtk-x11-2, libgconf-2, libpopt, libgobject-2, libpthread, libglib-2 and libc. So make it only link to those libraries instead. This shouldn't be that hard. And I think that using --as-needed as you did is the wrong way to go. This should be a last resort option in case you really can't fix it some other way. So in short you should: - Remove the -Xgconf-sanity-check from DEB_DH_SHLIBDEPS_ARGS This is something you should do in _any_ case since it's just wrong. - Remove the LDFLAGS="-Wl,--as-needed" from DEB_CONFIGURE_SCRIPT_ENV - Use Debian's libtool - Only link (gconf-sanity-check-2) to the libraries it needs. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Implicition declarations of functions and bugs
On Fri, Jan 20, 2006 at 11:19:58PM +0100, Samuel Thibault wrote: > Samuel Thibault, le Fri 20 Jan 2006 23:15:11 +0100, a écrit : > > Maybe the debian policy should require > > -Werror-implicit-function-declaration in CFLAGS so as to avoid such > > issue? > > Or buildds could check for "implicit declaration of function" warnings. We could also check for lots of other things in buildd logs. One that happens alot more is "cast to pointer from integer of different size" and "cast from pointer to integer of different size". During the past 24 hours I had 300 such warnings, and 94 of "implicit declaration of function". But this really is the maintainer of the package that should look at this. I don't think it's up to the buildd's maintainers to go and look for this type of bugs. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Severity of architecture-dependent bugs
On Sat, Feb 25, 2006 at 11:30:16AM -0700, Shaun Jackman wrote: > A grave bug has been file against a package I maintain pointing out > that the package does not work on AMD64 and in fact never has, even > though it builds on AMD64. Since it turns out this package has never > worked on AMD64, this bug is not a regression, but the status-quo. > Should such a bug be grave, or merely important? As Steve has pointed out already, packages that don't work on amd64 are considered to be grave bugs. Anyway, not having even idea which package it is, it's probably affecting more than 1 arch. Like for instance all 64 bit arches. So it should be an RC bug for those too. I suggest you try to find out what kind of problem it is, which shouldn't be that hard. And depending on that you can do various things, like fixing it. In any case, it's always a good idea to do some regression tests during build, and make it fail to build in case it finds an error. That way you can be a little more sure that you can do basic things with it. It also means that if it's failing, no binaries that aren't working end up in the archive, and you don't end up with grave bugs. In case there are more architectures that have the same problem, you'll have to file a request to remove those binaries from unstable after you've made sure that no broken binaries will get upload to unstable. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge release for amd64 - Please help to fix the remaining bugs
On Mon, Apr 25, 2005 at 11:32:25AM +0200, Andreas Jochens wrote: > > There are still a few packages in sarge which fail to build from source > on amd64. Those packages will not be part of the amd64 release of sarge. I've made a list list on saterday too which included all patched versions in the archive that I know about, and which possible could also need a patch. It's available on: http://debian-amd64.alioth.debian.org/patched-versions.txt Note that I also have a list of package that failed to build in sid and sarge at /pure64/failed.txt and /pure64/failed-testing.txt > Package BTS Bug Problem description > --- --- > amynth #274703+ missing '#include ' in main.cc That's amsynth > armagetron - dh_installchangelogs: command returned error code > 11 #298198 > cal3d- + libcal3d-doc/html/functions_rela.html missing #305411 > ftape-tools - "ltconfig: you must specify a host type..." That's marked as not-for-us because it only works with older kernels? > gnustep-base - + does not build with gcc-3.3 (needs gcc >= 3.4) It looks like it builds fine with gcc-3.3. But if my memory is any good, it (used to?) miscompile it? > libgtk-java - java.lang.NullPointerException There are alot of java package that fail to build and I still have to track those down. Those are ussually not the fault of the package itself. They're also arch all, so you can get them from the archive anyway. > libpolyxmass - "*** [localealias.o] Error 1" #303856, not sure what you mean with that error. > mondo- missing amd64 in architecture list This requires mindi, which we don't have either. > mozart - "undefined reference to `free'" Not 64 bit clean: #119583 > ogre - "no matching function for call to ..." It's in dep-wait for cegui-mk2-dev (#303072) The version for sarge has: #291606 > plex86 - amd64 missing from architecture list I doubt plex86 is going to work at all. > pocketpc-gcc - "/tmp/ccEpnAHc.s:1046: Error: bignum invalid" #301645 > portslave- "pppd.h: No such file or directory" ?? > prc-tools- "machine `x86_64' not recognized" It uses gcc 2.95, which just doesn't support us. > redboot - "Unknown target amd64" #152911 > tela - configure: error: "Blas not found!" ?? > xview#294844+ amd64 missing from architecture list It's been said more than once that xview (and everything depending on it) does not work on ia64 and amd64. You even said so yourself in the bugreport. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge release for amd64 - Please help to fix the remaining bugs
On Mon, Apr 25, 2005 at 07:36:36PM +0200, Adrian von Bidder wrote: > > Does that mean amd64 installer come without a mailer by default? Or will the > amd64 installer install a different mailer? The problem is that the old version of libmysqlclient-lgpl was build before we switched to an nptl only libc, and build fine at that point. It's still in the archive like that. It also builds fine if you just disable the configure check. Packages like postfix and exim4 can be build and installed without problems, the problem is more that the archive can't be rebuild from sources. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?
On Mon, May 16, 2005 at 07:44:37PM +0200, Adeodato Simó wrote: > > 1. apt-get install aptitude > 2. change the /etc/apt/sources.list to point to "stable" > 3. aptitude update > 4. aptitude install aptitude dpkg > 5. aptitude -f --with-recommends dist-upgrade 0. change the /etc/apt/sources.list to point to "woody" ? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free to main, but buildds not picking up?
On Sun, May 29, 2005 at 04:05:42PM -0500, Dirk Eddelbuettel wrote: > > My ggobi package recently made it from non-free/math to math (as the AT&T > license was replaced by the CPL, same as for graphviz). However, as shown by > igloo's script, buildds are not picking it up: > > http://people.debian.org/~igloo/package-status.php?package=ggobi > > Is there something I need to do / can do to trigger builds? I don't see that there is anything wrong with it? It's either in installed, building or needs-build state for all arches? The buildd logs are already available for several arches so it looks like it just needs to be uploaded for those. What more do you want? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PostgreSQL transition ahead
On Tue, Jun 07, 2005 at 07:24:06PM +0200, Florian Weimer wrote: > * Martin Pitt: > > > (2) PostgreSQL 8.0 brought a new SONAME for libpq (libpq4), which > > removed a few symbols which were only intended for internal use, > > but were used nevertheless by some client apps (like "psql"). > > libpq4 can talk to all PostgreSQL servers back to 7.3 (same like > > libpq3). > > I assume applications linked to libpq3 should be able to connect to > PostgreSQL 8.0 servers. Is this correct? (According to a few tests, > it is.) Afaik, the postgres backend still supports all versions of the protocol, so any libpq should be able to connect to it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package building problems (was Re: Canonical and Debian)
On Tue, Jun 07, 2005 at 08:11:46PM -0700, Blars Blarson wrote: > > > > >4) buildd software issues(pbuild,sbuild,wanna-build,etc) > > > > It looks like this software could use some redesign to put less work > > > on the buildd maintainers and scale better to more buildds. > > > Do you have some specific insights into this? This certainly sounds > > like a good area for us to work on.. > > Almost all of the dep-wait and many of the not-for-us errors could be > detected by the software. What do you mean with the "not-for-us" errors? I think what you're refering too is that quinn-diff tells you to build packages you really shouldn't. I filed a bug with a patch that works for me: http://bugs.debian.org/275835 The only thing wrong about it that I know of is that the -i option is now useless with that patch, but I think that can be solved easely too. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Orphaning packages
On Sat, Jun 18, 2005 at 11:08:28PM +0200, Ivo Timmermans wrote: > Hi, > > I'm orphaning these packages: > > dutch (bug #314839) > > dutch should probably be adopted by someone who speaks Dutch. I'm willing to adopt this package is nobody else wants it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HashKnownHosts
On Sun, Jul 03, 2005 at 03:52:07PM +0100, Colin Watson wrote: > The only time I've ever removed entries from > known_hosts is when I know that a specific host's key has changed, and > 'ssh-keygen -R' deals with that just fine. That options seems to be undocumented. It's not in the man page or the help it show at the command line. But it does seem to exist. (It doesn't give an error.) It also looks rather weird to me to use a tool to generate your key to manage the public key of other hosts. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Buildds still not picking up new architectures, why?
On Mon, Aug 07, 2006 at 10:47:13AM +0200, Ludovic Brenta wrote: > > This issue has been blocking the Ada transition (19 source packages, > 11 RC bugs) for about 3 weeks now, and I'd really like to be able to > proceed. I don't see how this can be blocking a transition. Please just do it for the arches that are supported now. The buildd admins/porters can perfectly take care of it once P-a-s gets updated. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /usr/bin/ld: cannot find -lraw1394
On Tue, Sep 12, 2006 at 12:28:24PM +0200, Martin Michlmayr wrote: > A number of packages (at least three, but possibly more) fail to build > with the error: > /usr/bin/ld: cannot find -lraw1394 > Can someone investigate why this is the case. I've put built logs > (mbox file) at http://people.debian.org/~tbm/logs/1394.bz2 I'm guessing they're all packages making use of pkg-config and have a build dependency on libavcodec-dev. But that doesn't seem to be the case for the last one. In any case, I think libavcodec-dev is missing a dependency. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /usr/bin/ld: cannot find -lraw1394
On Tue, Sep 12, 2006 at 09:20:00PM +0200, Kurt Roeckx wrote: > On Tue, Sep 12, 2006 at 12:28:24PM +0200, Martin Michlmayr wrote: > > A number of packages (at least three, but possibly more) fail to build > > with the error: > > /usr/bin/ld: cannot find -lraw1394 > > Can someone investigate why this is the case. I've put built logs > > (mbox file) at http://people.debian.org/~tbm/logs/1394.bz2 > > I'm guessing they're all packages making use of pkg-config and have > a build dependency on libavcodec-dev. But that doesn't seem to be the > case for the last one. In any case, I think libavcodec-dev is missing a > dependency. ffmpeg-config --libs also returns -lraw1394 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On Sat, Sep 16, 2006 at 06:54:05PM +0200, Andreas Metzler wrote: > Hello, > It has been pointed out to me in http://bugs.debian.org/387699 > that syvinit is going to move /var/run to a tmpfs to solve a long-standing > issue, having some place to store state information before partitions > are checked and mounted. (I do not know how they are going to handle > the fact that /var/run is needed before /var is mounted, mount --move > requires kernel 2.6 afaict.) > > This is nice, but is going to break packages that either ship a > subdirectory of /var/run in the deb or generate it once in > postinst and rely on its existence afterwards. > > Contents*gz and therefore packages.d.o do not list (empty) directories > but only files, so I cannot yet say how many packages this is actually > going to break, I have listed those I found on my system in the > bug-report noted above. Afaik, Ubuntu is already using this. As a result, I've actually got a bug against my package submitted because it didn't handle it. My package now recreates the directory from the init script if it's missing, and I'm not really happy about that solution. I'm not really sure what the right thing to do is. Maybe the FHS should be made clear on what you can expect from /var/run. I guess it would be useful to know what people now put in there. I know some daemons just want to have empty directory they can chroot to. Maybe they should put that somewhere else? I have no idea what others are putting there. Anyway, it would be useful if you didn't have to login on merkel to be able to see your list. I suggest you either submit those files to the BTS, or put it on people.debian.org or something. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On Sat, Sep 16, 2006 at 02:21:19PM -0500, Peter Samuelson wrote: > > [Kurt Roeckx] > > Afaik, Ubuntu is already using this. As a result, I've actually got a > > bug against my package submitted because it didn't handle it. My > > package now recreates the directory from the init script if it's > > missing, and I'm not really happy about that solution. > > Why not? 'mkdir -p' (or 'install -d' if you need a non-root owner or > custom permissions) is a quick one-liner. I'd much rather my system > didn't assume that /var/run or /tmp or /dev/shm will retain anything at > all between reboots. The FHS says we can create directories under /var/run that are application specific. It also says that all files should be removed or truncated. It does not say anything about directories being removed. On the other hand, about /tmp it very clear and says: "Programs must not assume that any files or directories in /tmp are preserve between invocations of the program." If I create a directory in /var/run, I expect it to stay there. And if I can't expect that, I'd like to see that documented somewhere. kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
On Sun, Sep 17, 2006 at 09:55:46AM -0700, Russ Allbery wrote: > Petter Reinholdtsen <[EMAIL PROTECTED]> writes: > > [Mario Holbe] > > >> So, as long as the Debian policy doesn't handle this, > > > I agree that we should update the policy to document this fact. > > It would be quite nice to have more people participating in the Policy > process in general. There are a fair number of proposals, but not a lot > of people reading proposals, helping achieve consensus, and seconding. > For example, I haven't gotten any responses to my patch to document ~ in > version numbers, and I'm not sure what happened to the menu policy > overhaul. I don't think policy changes need to be seconded. We have a policy team that should decide on what comes in policy and what not. Although, it more looks like it's just 1 person doing all the work. I sometimes feel that they go to slow which changing things, and I'm not really sure it's a good or bad thing. Some of those currently open bugs against the policy package, like your ~ in version numbers, really shouldn't be a problem to get into the policy. I don't think anybody has a problem with it. I think it's just that no new version of the policy has been made yet. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy process (was: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?)
On Sun, Sep 17, 2006 at 11:43:18AM -0700, Russ Allbery wrote: > Copying the debian-policy list, since this conversation is basically about > that. > > Kurt Roeckx <[EMAIL PROTECTED]> writes: > > > I don't think policy changes need to be seconded. We have a policy team > > that should decide on what comes in policy and what not. Although, it > > more looks like it's just 1 person doing all the work. > > > I sometimes feel that they go to slow which changing things, and I'm not > > really sure it's a good or bad thing. > > > Some of those currently open bugs against the policy package, like your > > ~ in version numbers, really shouldn't be a problem to get into the > > policy. I don't think anybody has a problem with it. I think it's just > > that no new version of the policy has been made yet. > > Well, policy-process is still shipped with the debian-policy package, and > my experience in the past is that when I follow that process, the changes > go into Policy fairly quickly. Certainly seconding would show that > someone reviewed the wording of my proposed ~ patch and has confirmed that > it sounds like an accurate and implementable description of their > behavior. > > Maybe Manoj could weigh in on how he sees the current process? That document says things like: The group that decides on policy should be the group of developers on the debian-policy mailing list, which is how it was always done; so the group of policy maintainers have no real power over policy. And that is not the impression I get from it. Also, I believe this has changed since they are now delegates of the DPL: http://lists.debian.org/debian-devel-announce/2005/07/msg2.html But it's unclear to me what this exactly means. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "~" in builddirs caused libtool to fail
On Sun, Sep 24, 2006 at 04:26:16PM +0200, Elimar Riesebieter wrote: > > > # libtool --version > > > ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18 > > > 22:14:06) > > > > That's what you have installed in /usr/bin, try: > > ./ld10k1/libtool --version > > ltmain.sh (GNU libtool) 1.5 (1.1220.2.1 2003/04/14 22:48:00) > > Ok, this is the bug in alsa-tool-1.0.12rc1. I copied `which libtool` > into ./ld10k1 and everything went well ;) That's not the proper way to update your libtool version. You'll need to run atleast libtoolize, aclocal and autoconf. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Top 20 unnecessary dependencies [was: Re: A plan to get rid of unnecessary package dependencies]
On Tue, Sep 26, 2006 at 11:41:33PM +0700, Mikhail Gusarov wrote: > > You ([EMAIL PROTECTED]) wrote: > > KBM> Most of these are X-related, suggesting that quite a lot of .la > KBM> and .pc files are pretty indiscriminate about which X libs they > KBM> link in. > > Will this problem disappear if end programs will pass --as-needed flag > to the ld command line? --as-needed basicly does the same as checklib. They both might say that some library isn't needed while it actually is. It might work in most cases, but it might break in others. The best solution is to avoid telling the linker it should be linking to that library, but that might be hard in some cases. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A plan to get rid of unnecessary package dependencies
On Mon, Sep 25, 2006 at 02:40:49PM -0700, Kevin B. McCarty wrote:
>
> One thing I noticed is that there are a lot of "problems" (in your
> terminology) caused by unneeded dependencies on libgcc1
> (/lib/libgcc_s.so.1). From my quick investigation, it appears that the
> C++ and Fortran compilers (g++, g77, gfortran) introduce this dependency
> automatically to programs linked with them. However, if gcc is instead
> used in the linking step, no such dependency is created (at least on
> amd64 where I'm testing).
>
> That is, programs compiled like this have libgcc_s.so.1 NEEDED:
>
> g++ foo.cc
> g77 foo.F
> gfortran foo.F
>
> but if they are compiled to object code and then linked with plain
> vanilla gcc, like this, they don't:
>
> g++ -c foo.cc -o foo.o && gcc foo.o -lstdc++
> g77 -c foo.F -o foo.o && gcc foo.o -lg2c -lfrtbegin
> gfortran -c foo.F -o foo.o && gcc foo.o -lgfortran -lgfortranbegin
>
> [CC'ed to debian-gcc to see if someone there can explain why this happens.]
Atleast for g++, it ends up being linked to both -lm and -lgcc_s
Using g++ I get:
[pid 22315] execve("/usr/bin/ld", ["/usr/bin/ld", "--eh-frame-hdr", "-m",
"elf_x86_64", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-o", "foo",
"/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crt1.o",
"/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crti.o",
"/usr/lib/gcc/x86_64-linux-gnu/4.1.2/crtbegin.o",
"-L/usr/lib/gcc/x86_64-linux-gnu/4.1.2",
"-L/usr/lib/gcc/x86_64-linux-gnu/4.1.2",
"-L/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64", "-L/lib/../lib64",
"-L/usr/lib/../lib64", "foo.o", "-lstdc++", "-lm", "-lgcc_s", "-lgcc",
"-lc", "-lgcc_s", "-lgcc", "/usr/lib/gcc/x86_64-linux-gnu/4.1.2/crtend.o",
"/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crtn.o"], [/* 18 vars
*/]) = 0
Using gcc I get:
[pid 22347] execve("/usr/bin/ld", ["/usr/bin/ld", "--eh-frame-hdr", "-m",
"elf_x86_64", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-o", "foo",
"/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crt1.o",
"/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crti.o",
"/usr/lib/gcc/x86_64-linux-gnu/4.1.2/crtbegin.o",
"-L/usr/lib/gcc/x86_64-linux-gnu/4.1.2",
"-L/usr/lib/gcc/x86_64-linux-gnu/4.1.2",
"-L/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64", "-L/lib/../lib64",
"-L/usr/lib/../lib64", "foo.o", "-lstdc++", "-lgcc", "--as-needed", "-lgcc_s",
"--no-as-needed", "-lc", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed",
"/usr/lib/gcc/x86_64-linux-gnu/4.1.2/crtend.o",
"/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crtn.o"], [/* 18 vars
*/]) = 0
Notice the --as-needed and --no-as-needed around the -lgcc_s's.
>From the specs:
*libgcc:
%{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc --as-needed -lgcc_s
--no-as-needed}%{shared-libgcc:-lgcc_s%{!shared: -lgcc
g++ seem to be using some other specs, but I have no idea how I
should dump them.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Top 20 unnecessary dependencies [was: Re: A plan to get rid of unnecessary package dependencies]
On Tue, Sep 26, 2006 at 09:36:08AM -0700, Kevin B. McCarty wrote: > > In case it's of interest to anyone, I went through the checklib logs > available on the web page for "problems" and found the libraries that > are most often listed as bogus dependencies. Here are the top twenty > offenders, listed with the number of packages that (according to > checklib) have each as an unnecessary dependency: > > 1663: libxext6 out of 2061 packages that have a Depends on it on unstable/amd64, so that's about 80% > 1275: libxi6 out of 1393: 91% > 1196: zlib1g out of 1796: 66% > 1174: libx11-6 out of 2502: 47% > 949: libice6 out of 983: 96% > 948: libsm6 out of 976: 97% > 940: libfontconfig1 out of 1136: 82% > 923: libxrender1 out of 1071: 86% > 918: libxinerama1 out of 1093: 84% > 918: libxcursor1 out of 1053: 87% > 905: libxrandr2 out of 1049: 86% > 697: libatk1.0-0 out of 850: 82% > 688: libcairo2 out of 865: 79% > 636: libgcc1 out of 2277: 28% > 610: libxfixes3 out of 653: 93% > 536: libpango1.0-0 out of 881: 71% > 480: libpng12-0 out of 753: 64% > 424: libfreetype6 out of 596: 71% > 394: libart-2.0-2 out of 444: 89% > 386: libxml2 out of 790: 49% Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Top 20 unnecessary dependencies [was: Re: A plan to get rid of unnecessary package dependencies]
On Thu, Sep 28, 2006 at 04:17:39PM +0200, Martijn van Oosterhout wrote: > > > >The gtk+2 .pc file needs to be changed to mark a bunch of those Requires > >as Requires.private, pkg-config provides all the necessary > >infrastructure now. (If not, please do file bugs.) > > Ok, the reduces the libs list, but it also reduces the cflags list. So > much so that you can't actually compile anything gtk-related. Note that Requires.private is used for cflags since the last version of pkg-config. Please see http://bugs.debian.org/340904 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Top 20 unnecessary dependencies [was: Re: A plan to get rid of unnecessary package dependencies]
On Thu, Sep 28, 2006 at 10:20:18PM +0200, Martijn van Oosterhout wrote: > On 9/28/06, Kurt Roeckx <[EMAIL PROTECTED]> wrote: > >Note that Requires.private is used for cflags since the last version > >of pkg-config. Please see http://bugs.debian.org/340904 > > Well, then something wierd is going on. I have 0.21-1 installed and I > get this. This first time is with Requires, the second is with > Requires.private. My understanding is that the results should be the > same? Afaik, they should, so I suggest you file a bug. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build failure: cannot find -lglib-2.0
On Fri, Oct 13, 2006 at 11:40:04AM +0100, Martin Michlmayr wrote: > A number of packages currently fail to build with: > /usr/bin/ld: cannot find -lglib-2.0 > > Can someone please investigate whether this is a bug in those packages > or some underlying problem and file bugs. I've put some buid logs at > http://people.debian.org/~tbm/logs/glib.bz2 That would be QtCore.pc having -lglib-2.0 in it. They all have libqt4-dev installed. I'll file a bug. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Missing days?
On Tue, Oct 17, 2006 at 02:34:11PM +, Sune Vuorela wrote: > Hi! > > I have started to wonder a bit about 'missing days' - a thing that is > especially importaint now when we are heading for a total freeze. > > >From http://packages.qa.debian.org/u/udev.html: > Too young, only 1 of 10 days old > [2006-10-15] Accepted 0.100-2.1 in unstable (low) I got: Date: Sun, 15 Oct 2006 10:02:15 -0700 Which is before the dinstall run on the 15th. A few hours later dinstall runs. Yet a few hour later britney runs and sees it for the first time. At that point, it's 0 days old. Than 24 hours later, britney runs again, and it's 1 day old. In about 10 hours, britney will run again, and it will become 2 days old. > But here: > http://packages.qa.debian.org/k/kwin-style-crystal.html > Too young, only 1 of 10 days old > [2006-10-13] Accepted 1.0.2-1 in unstable (low) Date: Fri, 13 Oct 2006 14:48:15 -0700 Which is a few hours after the dinstall run on the 13th. A few hours later when britney runs, it doesn't see it yet. Britney only sees it more than 24h after it was uploaded. So it's 2 days old now. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First draft of review of policy must usage
On Wed, Oct 25, 2006 at 01:03:11AM -0500, Manoj Srivastava wrote: > Next, I removed clauses that said that all the requirements of > policy must be met for a package to be in main or contrib; we know > that is not true. > > I have replaced some uses of the word must when it was > intended to be non-normative with alternate and equivalent wording, > which makes it easier to grep for "must". This still needs to be > done for should (which I often replace with 'ought to'). So, you changes some things from must to needs, because we don't consider them RC anymore. But then also remove the requirement to comply with the policy for us to distribute it? I think you're trying to do the same thing twice. I don't think we should remove the requirement to comply with all the requirements. > @@ -986,7 +891,7 @@ > particular version of that package. > >Essential is defined as the minimal set of functionality > - that must be available and usable on the system even > + that have to be available and usable on the system even >when packages are in an unconfigured (but unpacked) >state. This is needed to avoid unresolvable dependency >loops on upgrade. If packages add unnecessary Why do you downgrade this? Maybe this should be reworded though. This seems to be the only place in the policy that says that an essential package must have all it's functionality when it's in an unpackaged state. I think that should atleast be moved to the part about essential (3.8) instead of a footnote about Dependencies. > @@ -1931,7 +1848,7 @@ > > > The build, binary and > - clean targets must be invoked with the current > + clean targets need to be invoked with the current > directory being the package's top-level directory. > > I don't see why you want to change that. I think packages rely on it that it's called with a proper current working directory. > @@ -3195,8 +3112,8 @@ > >Additionally, packages interacting with users using >debconf in the postinst script should > - install a config script in the control area, > - see for details. > + usually install a config script in the control > + area, see for details. > > > You seem to have changed "should" to "should usually", and I don't see what the real difference is. > > - Packages involving shared libraries should be split up into > + Packages involving shared libraries ought to be split up into > several binary packages. This section mostly deals with how > this separation is to be accomplished; rules for files within > - the shared library packages are in instead. > + the shared library packages are in > + instead. > > > I think the "should" there was good. > @@ -4722,7 +4640,7 @@ > > > If a package contains a binary or library which links to a > - shared library, we must ensure that when the package is > + shared library, we have to ensure that when the package is > installed on the system, all of the libraries needed are > also installed. This requirement led to the creation of the > shlibs system, which is very simple in its design: I have no idea why you want to change that. If it's linked to a shared library, it really needs that library and won't work without it. So this should be a "must". Also, if you really want to change that, you might want to change the "This requirement" too. > @@ -4748,7 +4666,7 @@ > determined by calling ldd, but now > objdump is used to do this. The only > change this makes to package building is that > - dpkg-shlibdeps must also be run on shared > + dpkg-shlibdeps also has to be run on shared > libraries, whereas in the past this was unnecessary. > The rest of this footnote explains the advantage that > this method gives. It really must be run on it, or things will break. > @@ -4865,7 +4783,7 @@ > determine whether foo-prog's library > dependencies are satisfied by any of the libraries > provided by libfoo2. For this reason, > - dpkg-shlibdeps must only be run once > + dpkg-shlibdeps has to be run only once > all of the individual binary packages' > shlibs files have been installed into the > build directory. If you remove that requirement, I think you need to another one. foo-runtime really needs to have a dependency on libfoo2, one way or another. > @@ -6736,10 +6654,10 @@ > the LSB anyway. > > Thus, shell scripts specifying /bin/sh as > - interpreter must only use POSIX features
Re: First draft of review of policy must usage
On Wed, Oct 25, 2006 at 01:49:03PM -0500, Manoj Srivastava wrote: > > > > - Packages involving shared libraries should be split up into > > + Packages involving shared libraries ought to be split up into > > several binary packages. This section mostly deals with how > > this separation is to be accomplished; rules for files within > > - the shared library packages are in instead. > > + the shared library packages are in > > + instead. > > > > > > > > > I think the "should" there was good. > > This is something I want to discuss further. Consider the case > where there is a package with a set of, say, 20 binaries with a lot > of common code, and upstream decided to abstract it out into a shared > lib. This is a shred lib used by anyone else, and it is changing > rapidly enough that there is the equivalent of a soname change on > every upload. There is no interest in supporting older versions, or > even having multiple versions of that lib. In this case, either we > can make packaging that software hard (since moving the lib out of > /usr/lib etc may involve some work), or we allow some packages to > include share libs in the package. > > I don't know which way one should lean, so I decided to go the > route of fewer bugs. If it's not supposed to be used by an other package, it should be moved to /usr/lib/package/. If it doesn't contain any other libraries in /usr/lib, it shouldn't provide a -dev package. So there really isn't a need for a seperate lib package either. Anyway, that's why it says "should" in the first place, and I don't see why it needs to be changed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lots of (easily recognisible) spam sent to the BTS today
On Mon, Oct 30, 2006 at 01:36:56PM -0800, Blars Blarson wrote: > In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: > >On Sun, 29 Oct 2006 16:02:41 -0800, Blars Blarson <[EMAIL PROTECTED]> > >wrote: > >>We have a SA rule for this run now, but sending such hints to > >>[EMAIL PROTECTED] will get them seen much faster than debian-devel that I'm > >>more than a week behind in reading. > > > >So you really want to be manually informed about spam runs against the > >BTS? Don't you notice unusual activity in some rrd-based monitoring > >system? > > If you have an idea for a new spamassassin rule that will get a > current spam run without triggering on non-spam, send it to > [EMAIL PROTECTED] Unfortunatly, much spam is now using anti-bayes tecniques > and is hard to catch without also getting non-spam. > > I do see each message with a SA score >= -1, but at times I've been > days behind slogging through them. Does that mean that we shouldn't report spam we see in the BTS? If I now see spam going to a bugreport of mine, I always go and press the "this bug log contains spam". Should I just not bother with it? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ca-certificates symlinks out of /etc
On Sat, Nov 04, 2006 at 12:52:03PM +0100, Joey Schulze wrote: > > Maybe one improvement would be to reduce the number of links in this > directory to one per certificate. Currently for each certificate > provided by ca-certificates the certificate has a link to /usr/share/.. > and the hash has a link to the other link. Wouldn't it be possible to > only create the hash link as a symbolic link to /usr/share/...? I'm not sure the current c_rehash supports that. People (or scripts) may want to run c_rehash on /etc/ssl/certs, at which point it would remove the hash links, and you have nothing left. We need something that says "those certificates should be in /etc/ssl/certs", and I don't think the hash symlinks work for that. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ca-certificates symlinks out of /etc
On Sat, Nov 04, 2006 at 02:30:54PM +0100, Joey Schulze wrote: > Kurt Roeckx wrote: > > On Sat, Nov 04, 2006 at 12:52:03PM +0100, Joey Schulze wrote: > > > > > > Maybe one improvement would be to reduce the number of links in this > > > directory to one per certificate. Currently for each certificate > > > provided by ca-certificates the certificate has a link to /usr/share/.. > > > and the hash has a link to the other link. Wouldn't it be possible to > > > only create the hash link as a symbolic link to /usr/share/...? > > > > I'm not sure the current c_rehash supports that. People (or scripts) > > may want to run c_rehash on /etc/ssl/certs, at which point it would > > remove the hash links, and you have nothing left. > > Are the hashes recalculated randomly? Which programs do that? > (since I was left with a missing hash several times, at least > I don't seem to have such a program installed) It seems there is an update-ca-certificates, which has a config file (/etc/ca-certificates.conf) that says which certificates should be enabled. It runs c_rehash at the end of it, to regenerate the hashes. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: behaviour of "bts show" command with new BTS default behaviour
On Sun, Nov 12, 2006 at 01:02:06AM +, Julian Gilbey wrote: > Hi all! > > Thinking of changing the default behaviour of the devscripts "bts show" > (aka "bts bugs") command, and want to ask for opinions before I do so. [...] > It now resolves to: > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=;dist=unstable When using "bts show package" or going to "http://bugs.debian.org/package"; we get that behaviour, and I find both of them annoying. Some other thing it does now is that if I file a bug against a package before the bts knows about it, it shows up as "in other versions" or something. I think the default of the bts when going to http://bugs.debian.org/package should change back to the old behaviour, and you shouldn't change the bts command. Some other behaviour of the BTS I'm annoyed about is the order in which it shows bugs without a way for me to show them in the order I want. I've actually filed a bug about that: #356270 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: behaviour of "bts show" command with new BTS default behaviour
On Sun, Nov 12, 2006 at 03:50:46AM -0800, Don Armstrong wrote: > > Some other thing it does now is that if I file a bug against a > > package before the bts knows about it, it shows up as "in other > > versions" or something. > > You should be hard pressed to be able to actually install packages > before the BTS has learned about the version unless you're filing bugs > on packages which you've built yourself. [Far more likely that the > version the bug is filed against is wrong.] As buildd admin, I can file bugs at the moment I get the buildd log, and so can other buildd admins and people who get the logs. At that time, the bts will not know about that version yet, but it does exists. This is also very simular to packages that just get out of NEW. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: behaviour of "bts show" command with new BTS default behaviour
On Sun, Nov 12, 2006 at 03:50:46AM -0800, Don Armstrong wrote: > On Sun, 12 Nov 2006, Kurt Roeckx wrote: > > When using "bts show package" or going to > > "http://bugs.debian.org/package"; we get that behaviour, and I find > > both of them annoying. > > I switched the default to appending dist=untable because it actually > tells you which bugs affect unstable; it's far more informative than > merely categorizing based on whether a bug has been closed. If you > know you want something else, you really should be using the precise > url that you want. So, the default is basicly for the maintainer of the package, so they can see what bugs they need to fix in unstable? Users on the other hand might be more interested in the bugs affecting stable (or testing). It seems more logical to just lists all bugs for them. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: flock() and sendmail
On Thu, Nov 16, 2006 at 11:24:34AM -0800, Richard A Nelson wrote: > On Thu, 16 Nov 2006, John Kelly wrote: > > >I don't need NFS with sendmail. Surely flock() is not *still* broken > >in 2.6 kernels? > > I doubt that flock is *still* broken - that was quite some time ago... >From the flock manpage: NOTES flock(2) does not lock files over NFS. Use fcntl(2) instead: that does work over NFS, given a sufficiently recent version of Linux and a server which supports locking. The reason flock() doesn't work over NFS probably has to do with that flock() and fcntl() locks don't interact with each other. > >** NOTE: Override HASFLOCK as you will but, as of 1.99.6, mixed-style > >** file locking is no longer allowed. In particular, make sure > >** your DBM library and sendmail are both using either flock(2) > >** *or* fcntl(2) file locking, but not both. > > This, indeed, is the important part ! DB has changed alot, and now > has its own locking system, and whatever it uses to lock the entire > DB is what should be used by its callers. > > Has DB changed from fcntl to flock ? > Are you trying to access the sendmail databases from another > program that has differing locking conventions ? > > You fail to provide any hints as to on why fcntl which is used instead > of flock is causing you grief. If sendmail is using libdb, I don't see why sendmail would need to use fcntl() or flock() on any libdb file. It's an internal problem of libdb how it should do it's locking before it updates the database. However, sendmail might want to make sure that it's only updating it once, and can do this is various ways. As long as sendmail properly uses libdb, I don't see why there should be any problem at all. Anyway, from the linux/Documentation/locks.txt file: 1.2.1 Typical Problems - Sendmail - Because sendmail was unable to use the old flock() emulation, many sendmail installations use fcntl() instead of flock(). This is true of Slackware 3.0 for example. This gave rise to some other subtle problems if sendmail was configured to rebuild the alias file. Sendmail tried to lock the aliases.dir file with fcntl() at the same time as the GDBM routines tried to lock this file with flock(). With pre 1.3.96 kernels this could result in deadlocks that, over time, or under a very heavy mail load, would eventually cause the kernel to lock solid with deadlocked processes. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: flock() and sendmail
On Fri, Nov 17, 2006 at 06:27:13PM +, John Kelly wrote: > On Fri, 17 Nov 2006 19:09:33 +0100, Kurt Roeckx <[EMAIL PROTECTED]> > wrote: > > >Anyway, from the linux/Documentation/locks.txt file: > >1.2.1 Typical Problems - Sendmail > >- > >Because sendmail was unable to use the old flock() emulation > > I believe flock() *emulation* is no longer used in 2.6 kernels. flock was changed to not use emulation in 1.3.x and the old flock emulation has been removed in 2.1.x, according to the same doc. > >installations use fcntl() instead of flock(). This is true of Slackware 3.0 > >for example. This gave rise to some other subtle problems if sendmail was > >configured to rebuild the alias file. Sendmail tried to lock the aliases.dir > >file with fcntl() at the same time as the GDBM routines tried to lock this > >file with flock(). With pre 1.3.96 kernels this could result in deadlocks > >that, > >over time, or under a very heavy mail load, would eventually cause the kernel > >to lock solid with deadlocked processes. > > Then I have to wonder why sendmail is still configured to use fcntl() > when running on linux. Sounds like the modern kernel implementation > of flock() would be better. I have to wonder why sendmail needs to use fcntl() or flock() at all to lock the database. I don't see why flock() would be better, it's just different. fcntl() is a standardised and can do more than flock(). I actually see no good reason to want to use flock() over fcntl(). Also note that this deadlock was caused by the flock() emulation. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: flock() and sendmail
On Fri, Nov 17, 2006 at 07:03:00PM +, John Kelly wrote: > On Fri, 17 Nov 2006 19:54:13 +0100, Kurt Roeckx <[EMAIL PROTECTED]> > wrote: > > >I actually see no good reason to want to use flock() over fcntl(). > > > Maybe because the fcntl() > > >interface follows the completely stupid semantics of System V and > >IEEE Std 1003.1-1988 (``POSIX.1'') that require that all locks associated > >with a file for a given process are removed when any file descriptor for > >that file is closed by that process. This semantic means that applica- > >tions must be aware of any files that a subroutine library may access. > >For example if an application for updating the password file locks the > >password file database while making the update, and then calls > >getpwnam(3) to retrieve a record, the lock will be lost because > >getpwnam(3) opens, reads, and closes the password database. The database I think this is a rather bad example. If you lock a file and then use something other than read() or write() that might access it, you're very likely having problems. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: base-files: please ship /etc/networks and include "link-local 169.254.0.0" to it
On Sun, Nov 19, 2006 at 09:05:08PM +0100, Marco d'Itri wrote: > On Nov 19, Russ Allbery <[EMAIL PROTECTED]> wrote: > > > > I'd like to receive comments about: > > > - shipping /etc/networks in netbase > > > - adding 169.254.0.0 to it > > The second makes sense to me. > I am not sure. For a start, I would need to add *all* /24 in the > link-local networks space since /etc/networks comes from a pre-CIDR > world. > And I am not sure about which modern software still uses the file. In the classful/pre-CIDR world, 169.254.0.0 would be a class B, and so be a /16. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Archive Automatic Signing Key (4.0/etch)?
On Tue, Nov 21, 2006 at 04:50:29PM -0600, Peter Samuelson wrote: > > [Martin Zobel-Helas] > > gpg --recv-keys A70DAF536070D3A1 && (gpg --export -a A70DAF536070D3A1 | > > apt-key add -) > > Uh, don't forget the part about verifying that the key is actually > signed by the ftpmasters. Skipping that step pretty much defeats the > entire point. > > gpg --list-sigs A70DAF536070D3A1 Try gpg --check-sigs A70DAF536070D3A1 instead. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Name of a binary package according to sonames
On Sun, Dec 17, 2006 at 06:07:18PM -0400, Jose Luis Rivas Contreras wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I'm maintaining libtorrent package, this source builds 2 binaries, > libtorrent-rakshasa (is libtorrent9 last version in debian archive) and > libtorrent-rakshasa-dev (is libtorrent9 last version in debian archive), > I get this warning from lintian when I build the package. > > Now running lintian... > W: libtorrent-rakshasa: package-name-doesnt-match-sonames libtorrent10 > Finished running lintian. > > The version I'm building is libtorrent-0.11.0 so I don't think I should > call the binary libtorrent10. Please check the real soname with objdump -p libtorrent-0.11.0 |grep SONAME Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403619: RFP: languagetool -- rule-based language checker
Package: wnpp Severity: wishlist Package name: languagetool Version: 0.8.6 Upstream Author: Daniel Naber (naber at danielnaber de) URL: http://www.danielnaber.de/languagetool License: Mostly LGPL, also some BSD, Creative Commons Attribution ShareAlike 2.0 Description: A rule-based language checker This is a rule-based language checker for which a rule is defined. It can detect errors that a simple spell checker cannot detect e.g. mixing up there/their, no/now etc. It can also detect a limited amount of grammar mistakes. It currently has support for English, German, Polish, and Dutch, and limited support for French, Spanish, and Italian. It can be used standalone, as plugin for openoffice.org, with LyX, in java applications and as standalone web server. I think this would be a useful thing to have in Debian, since we currently don't seem to have something simular. But I have no intention to package this myself. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Name of a binary package according to sonames
On Mon, Dec 18, 2006 at 11:14:33AM -0400, Jose Luis Rivas Contreras wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > On Sun, Dec 17, 2006 at 06:07:18PM -0400, Jose Luis Rivas Contreras wrote: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> I'm maintaining libtorrent package, this source builds 2 binaries, > >> libtorrent-rakshasa (is libtorrent9 last version in debian archive) and > >> libtorrent-rakshasa-dev (is libtorrent9 last version in debian archive), > >> I get this warning from lintian when I build the package. > >> > >> Now running lintian... > >> W: libtorrent-rakshasa: package-name-doesnt-match-sonames libtorrent10 > >> Finished running lintian. > >> > >> The version I'm building is libtorrent-0.11.0 so I don't think I should > >> call the binary libtorrent10. > > > > Please check the real soname with objdump -p libtorrent-0.11.0 |grep > > SONAME > > The real soname is libtorrent.so.10 > > So, should I name it libtorrent10? Either the soname should be libtorrent.so.11, or you might want to rename libtorrent-0.11.0 to libtorrent-0.10.0 or something. If the soname really is and should be libtorrent.so.10, you want to name it libtorrent-rakshasa10 or something. But it should have the 10 in it. >From what I understand there are 2 incompatible libtorrent packages, so you want to reflect that in the name of the package. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Name of a binary package according to sonames
On Mon, Dec 18, 2006 at 12:09:13PM -0400, Jose Luis Rivas Contreras wrote: > > The version I'm building is libtorrent-0.11.0 so I don't think I should > call the binary libtorrent10. > >>> Please check the real soname with objdump -p libtorrent-0.11.0 |grep > >>> SONAME > >> The real soname is libtorrent.so.10 > >> > >> So, should I name it libtorrent10? > > > > Either the soname should be libtorrent.so.11, or you might > > want to rename libtorrent-0.11.0 to libtorrent-0.10.0 or something. > > I can't that version already pass... If the soname is set to libtorrent.so.10, it means applications will start to look for a file called "/usr/lib/libtorrent.so.10". That will probably be a symlink in your case to libtorrent-0.11.0, which looks rather confusing to me. In libtorrent9 you have a file called "/usr/lib/libtorrent.so.9". But there doesn't seem to be a file named libtorrent-0.9.0.so or something, so I'm a little confused what changed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Name of a binary package according to sonames
On Mon, Dec 18, 2006 at 12:52:40PM -0400, Jose Luis Rivas Contreras wrote: > > If the soname is set to libtorrent.so.10, it means applications will > > start to look for a file called "/usr/lib/libtorrent.so.10". That will > > probably be a symlink in your case to libtorrent-0.11.0, which looks > > rather confusing to me. > > > > In libtorrent9 you have a file called "/usr/lib/libtorrent.so.9". But > > there doesn't seem to be a file named libtorrent-0.9.0.so or something, > > so I'm a little confused what changed. > > No, there's only libtorrent.so.10 libtorrent.so.10.0.0 in my build > (libtorrent-0.11.0) So, your source package is "libtorrent" version is 0.11.0, which has a binary package libtorrent10-rakshasa with a library called libtorrent.so.10, and also has that soname. That all looks good. > I'm more confused since I renamed the package to libtorrent10-rakshasa > and libtorrent-rakshasa10 and lintian keeps giving me the warning... I think in this case you can probably ignore the warning. Do you conflict with the -dev package of the other libtorrent package? You'll both want to have a /usr/lib/libtorrent.so, so you should conflict. You probably now don't have a conflict with other library package now, but at some point this might happen. And I think this should be avoided. I think either one or both should really change the name of the library itself, to avoid all confusion, and also make them not conflict. For instance, you could name it librakshasatorrent (or librtorrent). The ideal solution would be that there really was only 1 libtorrent package, and that both current of them worked on 1 library. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Explications needed...
On Fri, Dec 29, 2006 at 11:20:30AM +0100, Josselin Mouette wrote: > An arm buildd maintainer not reading [EMAIL PROTECTED] is simply not > doing his job as buildd maintainer. You can't pretend to be the one > handling builds for the whole archive while not following discussions > around problems specific to this architecture. I think you're confusing the buildd admin with the porters. I expect porters to read the [EMAIL PROTECTED] list, I don't expect the same from the buildd admin. The buildd admin's job is getting packages built, while the porter's is to deal with architecture specific issues. The buildd admins aren't always also porters for that arch. But I think it would be a good thing that (some) porters also see all the buildd logs. That way they know alot faster about problems the port might have. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can ftpmasters do ONE SIMPLE THING?
On Sun, Dec 31, 2006 at 09:17:06AM -0500, Nathanael Nerode wrote: > Namely, fix bug #224469. It's really trivial and it's been waiting > for over three years now. This is just STUPID. > > Next DPL election, I want to see someone running on the platform of > adding an extra ftpmaster *whether or not the current ftpmasters > like it*. Someone who will get simple stuff like this DONE. Afaik, it can't be removed from unstable before oldstable is removed from the main archive. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Not depending on shlibs because of plugins?
On Fri, Jan 05, 2007 at 05:37:56PM +0100, Christoph Berg wrote: > Hi, > > I'm packaging a database wrapper library (http://oss.devit.com/yada/). > Its purpose is to provide one single API to a program and let the user > configure if the database used is actually postgres/mysql/sqlite. The > actual interfacing with the databases is done by .so plugins that are > dlopened at run time. > > Currently my package will depend on all of the database libs: > > | Depends: [...], libmysqlclient15off (>= 5.0.24-2), libpq4 (>= 8.1.4), > libsqlite3-0 (>= 3.3.8) >From the subject, I seem to understand that those are added by shlibs? This seems to suggest that something in the package is linked to all the libraries, and I don't see how you could remove it. If it was only using dlopen(), you probably had to add those depends by hand, which seem to be error prone to get the right versions. If it's using dlopen(), you probably want to depend on the -dev packages, unless you want to hardcode the complete name of the library instead of the soname. It probably already breaks if they're not installed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Not depending on shlibs because of plugins?
On Fri, Jan 05, 2007 at 06:44:49PM +0100, Kurt Roeckx wrote: > If it's using dlopen(), you probably want to depend on the -dev packages, > unless you want to hardcode the complete name of the library instead of > the soname. It probably already breaks if they're not installed. Of course soname is wrong there, I mean just the name of the library. kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Etch Software RAID Upgrade Trouble & Suggested Installer Improvements
On Sat, Jan 06, 2007 at 10:56:33PM -0500, Roberto C. Sanchez wrote: > On Sun, Jan 07, 2007 at 01:25:31PM +1100, Russell Coker wrote: > > On Saturday 06 January 2007 18:35, Claus Fischer > > <[EMAIL PROTECTED]> wrote: > > > 1. Rescue mode needs MD devices > > > > > >The rescue mode of the installer needs a step > > >to activate MD devices. Currently, only the plain > > >disk partitions are visible; that's no help. > > > > Sounds like a reasonable request. Filed a bug report? > > > > Note that it has to be an optional measure. > > > Well, at the least it should scan for partitions marked as a RAID and > prompt the user whether or not to start the set. You basicly have to start the software raid configuration tool, and then press finish. After that it will see the drives. I've filed a bug about this some time ago: http://bugs.debian.org/391474 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First AMD64 Binary Uploaded
On Mon, Mar 27, 2006 at 04:25:43PM -0500, Aaron M. Ucko wrote: > Yee-ha! This makes a wonderful (if moderately belated) first birthday > present for my em64t workstation. :-) > > One question, though: what's the contact address for the new buildd's > administrators? I tried [EMAIL PROTECTED] (to call #359023 to their > attention), but it bounces. I've requested the binNMU to be done, it should probably get build tomorrow somewhere. For now I suggest you contact [EMAIL PROTECTED] Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First AMD64 Binary Uploaded
On Mon, Mar 27, 2006 at 05:56:11PM -0500, Aaron M. Ucko wrote: > Kurt Roeckx <[EMAIL PROTECTED]> writes: > > For now I suggest you contact [EMAIL PROTECTED] > > OK, thanks; I considered that, but wasn't sure it was focused enough. > (Granted, -devel isn't that focused either, but it is more > developer-oriented.) That list should be a porters list, even though it's more abused as a user list. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: amd64 uploads
On Fri, Apr 07, 2006 at 07:25:30PM +0200, Aurelien Jarno wrote: > >kid3 > > This one dep-wait on the wrong package. The package did declare a build dependency on libtunepimp2-dev until you uploaded one that build depends on libtunepimp3-dev yesterday. wanna-build doesn't remove those automaticly, and I didn't notice that it was build depending on a non-existing package. Most of those are fixed, but I need to go over the list again. Anyway, the dep-wait state for kid3 should get cleared shortly. > I also noticed cpuburn has not been rebuilt, probably because it is > listed i386 only in Package-Arch-Specific, whereas the amd64 team was > probably using another version of this file. I've always kept an P-a-s file myself, and most of my changes are merged in the real one. I still need to go over it again to see which are actually useful. I've only requested those changes which are important and mostly obvious. If you as maintainer think it should get added, please mail the P-a-s maintainers. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: amd64 uploads
On Fri, Apr 07, 2006 at 02:20:09PM -0400, Aaron M. Ucko wrote: > Aurelien Jarno <[EMAIL PROTECTED]> writes: > > >> kid3 > > > > This one dep-wait on the wrong package. > > Yeah, the dep-wait should be dropped to reflect the recent upload. > > Speaking of dep-wait, there appear to be a few bugs whose fixes would > probably clear out most of > http://buildd.debian.org/stats/?arch=amd64&state=Dep-Wait : > > atlas3 bug #351646 (needs tweaking for new make) > gdal bug #360389 (bad cast, fix pending since Tuesday) > ruby1.9 bug #321316 (needs less optimization or [AFAICT] new upstream) > wxwidgets2.6 bug #350695 (FTBFS with new make, fix "pending" for months) > wxwindows2.4 bug #350696 (likewise) Those 5 just happen to be the same I'm waiting for, and I'll probably NMU some of those. > A lot of the others simply need to desupport old versions of Python. python2.1 and 2.2 are supposed to be removed soon, but both currently fail to build. There are lots of packages that build depend on those that should get changed. They all have open bugs. I'd welcome anyone that fixes a few of those. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: amd64 uploads
On Fri, Apr 07, 2006 at 09:47:25PM +0200, Pierre Habouzit wrote: > Le Ven 7 Avril 2006 20:33, Kurt Roeckx a écrit : > > > A lot of the others simply need to desupport old versions of > > > Python. > > > > python2.1 and 2.2 are supposed to be removed soon, but both > > currently fail to build. There are lots of packages that build > > depend on those that should get changed. They all have open > > bugs. I'd welcome anyone that fixes a few of those. > > what's the policy about them ? > > should the packages be built for python 2.3 and 2.4 ? only for 2.3 ? > only for 2.4 ? I guess it depends on the package. Currently the default seems to be 2.3, but if it supports multiple versions, adding 2.4 probably won't hurt. > and currently bugs like #351145 are only normal bugs. is it okay to nmu > in delayed/7 without warning ? See: http://lists.debian.org/debian-release/2006/04/msg5.html Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian package-has-a-duplicate-relation
On Sun, Apr 16, 2006 at 01:19:36PM -0700, Russ Allbery wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > > Now, the clean solution for those cases when there's a compelling reason > > to implement this bad idea: see what dpkg-shlibdeps(1) has to say about > > shlibs.local. > > I've tried to do this before and encountered: > >See dpkg-shlibdeps(1) for details of the format of shared library >dependency files. > > which of course is recursive and that man page contains no such details. > I don't actually know what the format of that file is (although I expect I > could make guesses at it from poking around, or get a much better idea by > reading over the source code). But if there is a standard format that > someone knows, it would be great to have that as a patch to Bug#316485. See policy section 8.6. It's the same as normal shlibs files. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: AMD64: etch and uploads
On Tue, Apr 18, 2006 at 12:17:54PM -0400, Stefano Zacchiroli wrote: > On Wed, Apr 19, 2006 at 12:41:50AM +1000, Anthony Towns wrote: > > Developers with amd64 machines are also now able to upload new versions > > of their package built locally (rather than in an i386 chroot) -- but > > in order to ensure dependencies are calculated correctly, please make > > sure you're building using Debian unstable and not packages from Ubuntu > > or the unofficial debian-amd64 archive; using pbuilder or debootstrap > > to create a chroot build environment might be helpful in this case. > > In order to fulfill this requirement, is there a best practice / any > possible way to "convert" an amd64 box which has been installed from > debian-amd64 to an official debian amd64 box? I use the following: apt-get clean apt-get --reinstall install -d `dpkg --get-selections |grep -v deinstall | sed -e 's/\t.*//' ` cd /var/cache/apt/archives dpkg -i *.deb You can't do it without the -d, apt-get seems to have a problem with depedency loops. Note that it might complain about packages it can't (re)install, in my case those were all packages that have been replaced. You should remove those. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Help] Versioning of a library
On Sat, Apr 22, 2006 at 11:10:35PM +0200, Andreas Tille wrote: > Hi, > > I'm the maintainer of libgtkdatabox-0.2.3.0-0. Until now there > was no request for an update of the upstream version and I had > personal reasons to stay with an outdated version. Now I was > asked to package the latest version and the library is probably > not important enough to keep different versions and thus I will > package version 0.5.2.0 that is the latest version avialable from > http://www.eudoxos.de/gtk/gtkdatabox/ . My guess is that there > is an ABI change involved and thus I have to rename the package > to libgtkdatabox-0.5.2.0-X . My question is: What is the right > choice for 'X' if I skipped several upstream versions inbetween? The current library in the archive seems to be libgtkdatabox-0.2.4.7-0, and not libgtkdatabox-0.2.3.0-0. The currently library seems to be libgtkdatabox-0.2.4.so.7.0.0 and has an soname of libgtkdatabox-0.2.4.so.7. I guess the the new one will have something like libgtkdatabox-0.5.2.so.0? I don't see what you feel the need to add this extra -X to your library name, libgtkdatabox-0.5.2.0 should be good enough. As long as he changes the soname when he breaks the ABI. And it seems upstream even seems to change soname for every release, so I don't see that as a problem. However, it would be better if upstream actually didn't change soname every release. He seems to be using the soname as a version, which isn't how it should get used. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Does /etc/shadow exist in an sbuild environment?
On Thu, Apr 27, 2006 at 07:09:17AM +0200, Christian Perrier wrote: > > Turning shadow on in chroots is left up to the local admin. > > This is optionnally done by the passwd package when it is > reconfigured, see /var/lib/dpkg/info/passwd.config > > Of course, using "shadowconfig on" is also possible without > reconfiguring the passwd package..:) > > Apart from that, yes, enabling shadow passwords is the default on > newly installed Debian. The relevant question is hidden in default > high priority installs and has a positive answer as default. It is > shown when the install is run at medium priority. I don't have passwd installed in my chroots, don't have a /etc/shadow, and installing passwd doesn't get create it either. It also seems to require that you have debconf installed, which I don't. Even with debconf installed it doesn't turn it on by default. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITP: elfutils
Package: wnpp Severity: wishlist * Package name : elfutils * Version : 0.120 * Upstream Author : redhat (Ulrich Drepper <[EMAIL PROTECTED]>) * URL :ftp://sources.redhat.com/pub/systemtap/elfutils/ * License : GPL Description : A collection of utilities and DSOs to handle compiled objects. Elfutils is a collection of utilities, including ld (a linker), nm (for listing symbols from object files), size (for listing the section sizes of an object or archive file), strip (for discarding symbols), readelf (to see the raw ELF file structures), and elflint (to check for well-formed ELF files). Also included are numerous helper libraries which implement DWARF, ELF, and machine-specific ELF handling. >From the changelog: - The license is now GPL for most files. The libelf, libebl, libdw,and libdwfl libraries have additional exceptions. Add reference toOIN. (This allow to link with any open source license approved by OSI) It contains other libraries which have something simular in Debian already. libelf (with binary package libelfg0) seems to do exactly the same, so maybe we should look at only providing one of them. I have no idea why it has the g in it's name though. libdw seems to be simular to libdwarf, but differ alot. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363486: dpkg: [update-alternatives] New categories for: WORD, EXCEL, MEDIA-PLAYER etc.
On Mon, Jun 12, 2006 at 12:53:57PM +0300, Jari Aalto wrote: > | > > | > The same problem is with Office programs: > | > > | > lyx > | > abiword > | > oowriter > | > ... > | > > | > The /etc/alternatives contains a good framework to canonicalize actions to > | > common names available in system and to control the preferred program. I think you're not very clear in what you're asking, so I'm going to try and explain what I think you said. If you open a file in a file browser, or you open it thru a web browser or something, it might have a mime type assosiated with it. So what I think you suggest is that based on the mime-type we start an application that should be able to handle that mime-type. I'm not sure if the alternatives system is the best place to "register" mime types. I'm also not sure that a Debian specific solution as the alternatives system is the best way to go. But I can see why this would be useful, and maybe it should work in combination with the alternatives system. I hope I understood your suggestion. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
On Thu, Jun 29, 2006 at 09:35:09PM +0200, Bastian Venthur wrote: > Steinar H. Gunderson wrote: > > On Thu, Jun 29, 2006 at 09:15:13PM +0200, Bastian Venthur wrote: > >> Same here. Very annoying on a box where you only update every few weeks > >> or something. Wouldn't it be possible to make snapshots every week and > >> only pdiff from this snapshot? > > > > You can turn off pdiffs if you'd like to; the old packages files are still > > there. The question here is what to do with the default. > > Ah ok, I was not aware of this feature. But since downloading pdiffs of > > x days might in fact result in a larger download than downloading the > package-files directly, aptitude (or apt-get) should decide > automatically when to use pdiffs and when not. > > Someone could make stats to calculate the average day-count x when the > summ of the pdiffs becomes larger that the package-files. Then aptitude > (or apt-get) could decide whether the last update is more than x days > away and decide what to use. You don't need stats for that, the Packages.diff/Index has the size in it. But what I don't get is that it seems to be downloading every file more than once. It atleast looks to be downloading twice as files as it should, but it more looks like it's downloading the same file 3 times if I look at the sizes. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: additions to dpkg-architecture
> > | You have searched for the contents of libssl0.9.7 in stable, > > | architecture sparc. Package contains 9 files, displaying files 1 to 9. > > | > > | usr/lib/libcrypto.so.0.9.7 > > | usr/lib/libssl.so.0.9.7 > > | usr/lib/v8/libcrypto.so.0.9.7 > > | usr/lib/v8/libssl.so.0.9.7 > > | usr/lib/v9/libcrypto.so.0.9.7 > > | usr/lib/v9/libssl.so.0.9.7 > > | usr/share/doc/libssl0.9.7/changelog.Debian.gz > > | usr/share/doc/libssl0.9.7/changelog.gz > > | usr/share/doc/libssl0.9.7/copyright > > > > In other words: Problem solved since sarge. I've tested this on sarge before, and it doesn't seem to work there. But the same package on etch/sid do work. I'm guessing the dynamic linker changed between sarge and etch. Also see #203285. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Ping] Packages-arch-specific: please add architectures to Ada packages
On Fri, Jul 21, 2006 at 10:03:56PM +0200, Ludovic Brenta wrote: > It has been a week since I sent the request below, and I received no > answer. I am resending to the three maintainers of > Packages-arch-specific, and CCing debian-devel. > > I've restricted the list of supported architectures to those where > gnat-4.1 not only exists but also builds its shared libraries. This > is because all other packages are, or depend on, shared libraries that > depend on libgnat. I've actually requested the same changes for ada. I've always been annoyed by the lack of response we get when sending updates for it. There are other changes I'm waiting for. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NPTL support in 2.4 kernel series?
On Fri, Jan 21, 2005 at 07:51:22PM +0100, Martin Kittel wrote: > Hi, > > I am maintaining the packages of the MaxDB database system. > > Recently upstream has converted the database kernel from > linuxthread-style threading to NPTL. While -at least for i386- > linuxthreads is still supported in MaxDB at this time, it will go away > in one of the next releases. What is the problem with linuxthread? Are there some problems linuxthreads cause that go away when using NPTL? Anyway, the package currently only supports i386, so I don't see a problem with using linuxthread for now. Please make sure that you then atleast prevent it from using NPTL. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Junichi Uekawa <[EMAIL PROTECTED]> wrote: > > > 2. The information of -dev packages depending on other -dev packages > > > cannot be automatically determined currently; > > > it should be possible to obtain a minimal list by analyzing the > > > NEEDED field of the objdump output. > > > > Errr, -dev packages generally don't (and shouldn't) depend on other -dev > > packages. If you're trying to push the idea that -dev packages should > > depend on the -dev packages of libraries they depend on- don't. That's > > *wrong*, it's the completely wrong approach and should *not* be taken. > > Give me justifications rather than just saying *wrong*, > because you are giving me an argument that is contrary to > current practice in Debian. > > -dev packages do depend on other -dev packages, > and if they don't work, they are usually filed a serious bug > for non-functionality. Reasons why you need you need to add a build-dependency on libfoo-dev package: - You're linking to it - You're using include files from it. Simular, if your package is libbar, your lib libbar-dev package needs to depends on the libfoo-dev packages if: - Your include files include libfoo's include files. This is ussually something you want to avoid. - You have a static lib, and people will need to link libfoo if they're linking to your package. I think static libs should be avoided in most cases. An other reason why it's currently done is that some packages link to packages that only "use" your libbar lib, but also link to libfoo, which isn't needed. Isn't not needed because libbar already depends on libfoo. This can for instance be the case when using libtool. The version of libtool in the archive shouldn't be doing this. The correct way to fix this is by updating the libtool package, or whatever that's being used, and not by having -dev packages depend on other/more -dev packages. It's just easier to fix this in the short time, because it only requires one -dev package to be fixed while else all packages build-depending on it need to be fixed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The BTS and bug subscriptions
On Fri, Jul 22, 2005 at 06:11:14PM +1000, Pascal Hakim wrote:
>
> It is now possible to subscribe and unsubscribe from individual bugs in
> the Bug Tracking System. To do so, simply send an email to
> [EMAIL PROTECTED], or [EMAIL PROTECTED], where
> nnn is the bug number you wish to {,un}subscribe to. You will then need to
> reply to the confirmation email for the action to take effect.
I would like that I don't have to confirm each time I subscribe
to a bug. Could there be some list added so that you don't need
to confirm your subscription?
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: status of jackd? (bug #318098)
On Tue, Aug 09, 2005 at 10:28:58AM -0400, David Nusinow wrote: > On Tue, Aug 09, 2005 at 01:01:16AM -0700, Erik Steffl wrote: > > mini rant: what's the point in breaking important packages in > > unstable for significant periods (e.g. the bug above was filed > > 2005/07/13)? Isn't experimental more appropriate for stuff like this? > > Where would you like us to do our work? This is exactly what unstable is > *for*. It lets us break things while they're in development in order to > push the distro as a whole forward. No, that's what experimental is for. If you upload something to unstable, it should be ready to migrate to testing in a short period. And it would be best that you could "prove" that it's ready to go to testing before you upload it to unstable. I really think that anything with has a alot of reverse dependencies (let's say 10 or something), should be uploaded to experimental before doing any kind of transition and should contact the release team that they plan to do so. I think this should be done for everything that has the potential to break something. This of course includes shared libraries that have to go thru an soname change, but really should include most things that have reverse dependencies. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please notify your rdepends' maintainers if you break an interface
On Sat, Aug 13, 2005 at 06:33:59PM +0200, Marc 'HE' Brockschmidt wrote: > Ron Johnson <[EMAIL PROTECTED]> writes: > > apt-rdepends > > Interesting, but not useful for the case I had today: > > [EMAIL PROTECTED]:~$ apt-rdepends --build-depends --reverse foo > E: Reverse build-dependencies are not supported And the man page says so too: apt-rdepends cannot do reverse build-dependencies. This is really dif- ficult, since it would have to load the whole cache into memory before discovering which packages depend on others to build. What I ussually do is: grep-dctlr -F Build-Depends foo -s Package Sources Where Sources points to the apt Sources file. This will only find direct build dependencies, and this is ussually enough. Note that you need to do the same for Build-Depends-Indep too. If you want to have everything that needs it installed to build, you'll have to do some more work: apt-cache rdepends foo And then for each of those you'll need to do the grel-dctlr above again. Afaik, this should catch all of them. I would love to see a command which automates all of this for me. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-shlibdeps: warning: could not find path
On Tue, Aug 16, 2005 at 01:34:56PM -0700, Russ Allbery wrote: > For the past week, I've started getting errors like the following when > building any packages in pbuilder that include shared libraries with the > current tool chain in unstable: > > dpkg-shlibdeps: warning: could not find path for libkafs4.so.0 > dpkg-shlibdeps: warning: could not find path for libkrb.so.1 > dpkg-shlibdeps: warning: could not find path for libroken.so.16 > dpkg-shlibdeps: warning: could not find path for libkafs4.so.0 > dpkg-shlibdeps: warning: could not find path for libkrb.so.1 > dpkg-shlibdeps: warning: could not find path for libroken.so.16 Do you get those warnings for all packages, or is this from a log for some specific package? I'm guessing that this is from a log krb4 package, who contains all those libraries? Afaik, dpkg-shlibdeps always gave such warnings for libraries from the same source package, since those libraries are not installed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: order of builds on a buildd: icu (optional/libs)
On Thu, Aug 18, 2005 at 05:46:19PM -0700, Steve Langasek wrote: > On Thu, Aug 18, 2005 at 07:40:30PM -0400, Jay Berkenbilt wrote: > > > Based on what I've seen in other threads, the order in which packages > > get built on a buildd is a function of, among perhaps other factors, > > its priority and section. I uploaded icu several days ago and have > > watched other packages (including my other uploads) sneak in front of > > it that shouldn't have based on these two factors. For example, nip2 > > (optional/graphics, no reverse dependencies) built much faster than > > icu (optional/libs). The only thing I can think of is that the latest > > icu builds two binary packages that have not previously existed > > because it is a library with a new soname. Does that impact it? > > libicu21c2 and libicu21-dev, built by the old icu, have reverse > > dependencies, but libicu34 and libicu34-dev don't yet. (I'm waiting > > to upload the packages that depend upon these until they are built on > > all architectures.) > > > Is there a place where I could have looked (other than reading the > > code to buildd and/or wanna-build) to find the exact method used to > > calculate the build order? > > TTBOMK, new binary packages should not affect the ordering of the > package in the build queue. In this case it does since all binary packages got renamed, so non of them got compiled before. > The sort criteria are, in order of > precedence: the upload target; out-of-date vs. uncompiled; the source so it's the out-of-date vs. uncompiled that does it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian shared libs use far more memory than required
On Thu, Aug 25, 2005 at 07:47:17PM +0200, Thiemo Seufer wrote: > The immediate suspect is binutils, particularily ld. It might be > interesting to do test compiles with an older binutils version > (2.15 vs. 2.16?) and see if the problem is reproducible. The package in question was already build using binutils 2.16 according to the buildd log. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian shared libs use far more memory than required
On Fri, Aug 26, 2005 at 12:21:07AM +0200, Stephane Chauveau wrote: > > I am not really surprised because I just compared the linker scripts > from 2.15 and 2.16. > They have a different section ordering and the official debian package > clearly follows the 2.16 ordering. Also, there was no differences > between the linker scripts in 2.16 and in 2.16.1 > > My main suspect is still libtool. The libtool version in debian didn't change for a while so I doubt this. And since the source itself didn't change either, I don't see how libtool can cause this at all. Do you only see this difference with libraries, or also with binaries? This seems to have been a temporary problem that has now gone away, and all the obvious candidates don't seem to be the cause. Building the same source (from sid) on sarge gives: .rodata 689389 2101632 .data4 3907584 Which is comparable to the current version in sarge: .rodata 684173 2084992 .data 4 3883168 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
