Re: automake/autoconf in build-dependencies
[EMAIL PROTECTED] (Paul Hampson) writes: > The arguments _for_ build-depending on the various autotools are (off > the top of my head) Here are some other reasons pro that I can think of: - 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. - You automatically get bug fixes in autoconf. (Minor, and not worth doing it for this alone, imho.) - The extra space in the diff.gz expands the size needed on every single Debian mirror, as opposed to the short one-time penalties on a few buildd's. And I heartily agree with the argument concerning making diff.gz's readable. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: combining fakeroot and distcc/SSH
martin f krafft <[EMAIL PROTECTED]> writes: > also sprach Petter Reinholdtsen <[EMAIL PROTECTED]> [2005.03.05.1225 +0100]: >> > I am trying to use distcc to compile Debian packages and kernels, >> > and am failing. The reason is that I need to use distcc-over-SSH, >> > but the Debian compile process is run as (fake)root. >> >> Why isn't it enough to do 'make install' as root? Is there something >> in the build process requiring root access? > > Weird; some packages have dh_testroot in the build target. I tried > removing that and using fakeroot only for install. It seems like it > works now, but we'll see... argh. It seems that some people > (including myself when I wrote these scripts) think that `fakeroot > dpkg-buildpackage` is the same as `dpkg-buildpackage -rfakeroot`). Any such packages are broken and should have a serious FTBFS bug filed against them. That said, I haven't seen any such packages running pbuilder locally. If you mean dh_testroot in the clean target, on the other hand, that's a different story; clean is allowed to require root access. (IIRC, the reason is to be able to clean files created in the build directory during the make install phase.) -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- 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
Le Jeudi 24 Novembre 2005 14:43, Peter Eisentraut a écrit : > Steve Langasek wrote: > > * Use Debian's libtool. > > I took one affected package (kmldonkey) from your list, relibtoolized > it as described, and rebuilt it, which failed spectacularly. Then, I > took another one (rekall), relibtoolized it, rebuilt it, and that > failed with a strikingly similar pattern. > > 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()' > > Both libkdeui and libkio reference (as shown by ldd) libqt-mt (which > I suppose is where these symbols should be). > > 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*)' > > In this case -lqt-mt is actually on the libtool command line. > > So what is wrong here? Have other maintainers of Qt/KDE-related packages > perhaps experienced this? Try debian/patches/common/07_disable_no_undefined.diff from any of the core KDE packages. -- Daniel Schepler
Re: possible freetype transition; improved library handling needed for all C/C++ packages
Le Vendredi 25 Novembre 2005 02:38, Steve Langasek a écrit : > > Try debian/patches/common/07_disable_no_undefined.diff from any of the > > core KDE packages. > > Er... that doesn't sound like a good thing, why would you want to allow > undefined references? If I recall correctly, the -no-undefined flag was being used along with --allow-undefined as an attempt to make all templates used by a library be instantiated. Unfortunately, that _depended_ on libtool's broken behavior; without a full list of libraries, the link spews loads of undefined symbol warnings. (Back when I wrote the patch, the link would actually succeed eventually despite all the warnings, but that might have changed since then.) With the patch, KDE falls back to its old behavior of resolving this by linking a fake object file against the library object files before linking the libraries. -- Daniel Schepler
New make is breaking several packages
Just a heads up to all packagers out there that I've been seeing a number of
build failures similar to this one (randomly selected from gsfonts-x11):
perl -e 'my $lines=""; my $count=0; \
while (<>) { \
next if /^\d+$/; \
$lines.=$_; $count++; \
if(/iso8859-1/) { \
s/iso8859-1/iso8859-2/g; \
$lines.=$_; $count++; \
s/iso8859-2/iso8859-15/g; \
$lines.=$_; $count++; \
} \
} \
print "$count\n$lines";' \
< fonts.scale \
> `pwd`/debian/gsfonts-x11/etc/X11/fonts/Type1/[longline]
syntax error at -e line 2, near "while"
syntax error at -e line 5, near "if"
syntax error at -e line 10, near "}"
Execution of -e aborted due to compilation errors.
make: *** [install] Error 255
This is due to changes in make 3.80+3.81.b3-1 concerning how the lines are
passed to the shell. Previously, they would be concatenated; now they are
passed verbatim to the shell, backslashes and newlines included (minus the
first tab on each line).
One way to fix this is to rewrite the above as:
perl -e 'my $lines=""; my $count=0; '\
' while (<>) { '\
'next if /^\d+$/; '\
'$lines.=$_; $count++; '\
...
' print "$count\n$lines";' \
< fonts.scale \
> `pwd`/debian/gsfonts-x11/etc/X11/fonts/Type1/[longline]
That way the shell sees a list of strings with no spaces between them, so it
concatenates all of them together before passing them to perl.
I'll probably start filing bugs about this about the beginning of next year,
when I return from holidays. In the meantime, here's a list of some packages
I've run into this with, which is by no means complete:
debconf
dwww
gsfonts-x11
jade
libogg
libvorbis
opensp
psmisc (and I notice the buildds choke on the recent upload too)
--
Daniel Schepler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New make is breaking several packages
Le Mardi 20 Décembre 2005 14:10, Marco d'Itri a écrit : > On Dec 20, Daniel Schepler <[EMAIL PROTECTED]> wrote: > > This is due to changes in make 3.80+3.81.b3-1 concerning how the lines > > are passed to the shell. Previously, they would be concatenated; now > > they are passed verbatim to the shell, backslashes and newlines included > > (minus the first tab on each line). > > It breaks a widely used feature. Why should this change not be > considered a make bug? In make's NEWS.Debian.gz it says this change was for POSIX compliance. And since there's the simple way to rewrite these things that I outlined, I think it's better to make our debian/rules and Makefiles compliant than to revert this change. -- Daniel Schepler
Re: New make is breaking several packages
Le Mardi 20 Décembre 2005 14:29, Frank Küster a écrit : > Daniel Schepler <[EMAIL PROTECTED]> wrote: > > Le Mardi 20 Décembre 2005 14:10, Marco d'Itri a écrit : > >> It breaks a widely used feature. Why should this change not be > >> considered a make bug? > > > > In make's NEWS.Debian.gz it says this change was for POSIX compliance. > > And since there's the simple way to rewrite these things that I outlined, > > I think it's better to make our debian/rules and Makefiles compliant than > > to revert this change. > > I hope "fixed" Makefiles will continue to work with older versions of > make, right? > > Regards, Frank Yes, a Makefile with all: echo 'foo'\ 'bar' will pass to the shell: (old make) echo 'foo''bar' (new make) echo 'foo'\ 'bar' And both will echo a single word. -- Daniel Schepler
Re: New make is breaking several packages
Le Vendredi 23 Décembre 2005 09:11, Robert Luberda a écrit : > On Tue, 20 Dec 2005, Daniel Schepler wrote: > > Hi, > > > Yes, a Makefile with > > all: > > echo 'foo'\ > > 'bar' > > > > will pass to the shell: > > (old make) echo 'foo''bar' > > (new make) echo 'foo'\ > > 'bar' > > > > And both will echo a single word. > > Unfortunatelly that's not true: the sarge version of make > prints two words ;( > Has anybody any other ideas how to write a Makefile that will > work in the same way with both sarge and sid make? Sorry, I didn't have access to an old make at the time I wrote this. I guess the old make preserves leading tabs on continuations, so this would instead have to be: all: echo 'foo'\ 'bar' Hopefully this will work on both versions, but again I don't have easy access to an old make to test it. There's also the suggestion elsewhere in the thread to put the script in a make variable instead. -- Daniel Schepler
Packages still Depending on xlibs-dev
With the recent upload of xorg-x11 version 6.9.0 to unstable removing xlibs-dev, any package still having a Depends: xlibs-dev will become uninstallable very soon once xlibs-dev disappears from the distribution. Here's a list of the affected packages from main/i386 by maintainer; filing of grave bugs to follow once this happens. (Also, everybody correct any Build-Depends on xlibs-dev as well.) Ryuichi Arafune <[EMAIL PROTECTED]> libmagick9-dev Hakan Ardo <[EMAIL PROTECTED]> toolchain-source Thomas Bushnell, BSG <[EMAIL PROTECTED]> gdk-imlib11-dev imlib11-dev libgnome-dev A. Maitland Bottoms <[EMAIL PROTECTED]> libvtk4-dev Martin Buck <[EMAIL PROTECTED]> xviewg-dev Guenter Geiger <[EMAIL PROTECTED]> ivtools-dev Debian QA Group <[EMAIL PROTECTED]> libubit-dev Christian Hudon <[EMAIL PROTECTED]> iconc Aurelien Jarno <[EMAIL PROTECTED]> liblineak-dev Siggi Langauf <[EMAIL PROTECTED]> libxine-dev Steve M. Robbins <[EMAIL PROTECTED]> libsoqt-dev Jeff Teunissen <[EMAIL PROTECTED]> libdockapp-dev Chris Waters <[EMAIL PROTECTED]> itk3.0-dev itk3.1-dev tk8.0-dev tk8.3-dev Florian M. Weps <[EMAIL PROTECTED]> libooc-x11-dev Mathias Weyland <[EMAIL PROTECTED]> beep-media-player-dev (Btw, dd-list should probably have an option to suppress converting to source packages, for situations like this where a list of binary packages is more useful.) -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
My New Years' resolution: fix one RC bug a day
Le Mardi 03 Janvier 2006 21:24, Andreas Barth a écrit : > However, we need to start *now* to give the RC-bug count some more > attention. This means also that we're going to start again an everlasting > BSP: For RC-bugs, you can upload 0-days NMUs for RC-bugs open for more > than one week. However, you are still required to notify the maintainer > via BTS before uploading. And of course, you need to take care of > anything you broke by your NMU. I've had an idea on a good way to decrease the RC-bug count without burning myself out: I've resolved to fix one RC bug a day at least until there are no more trivial RC bugs left. I started Friday by NMU'ing libxklavier; over the weekend I worked on uploads for tcl8.* and tk8.* and then fortunately found the maintainer is working on fixing bugs for those packages. For today, unless I hear something on bug #335137 within a couple hours, I'll do an NMU for libwmf; and for tomorrow, I just noticed there's an RC bug against kdeedu for me to fix myself. I figure if I keep this up, I can take care of 30 RC bugs a month; and if just 9 other people join me, that will make 300 RC bugs a month. -- Daniel Schepler
Proposal: move /etc/{protocol,services,rpc} to base-files
Currently there are several packages which Build-Depend on netbase just to have /etc/protocol and /etc/services available to run tests. Unfortunately, this means that all of netbase's dependencies also need to be installed -- and because of bug #162581, pbuilder can't even block inetd from starting in its chroot, resulting in orphan inetd processes after the build is over. So I'd like to propose moving those data files from netbase to base-files. If it's decided that these files are inappropriate content for an essential package, I'd at least like to see something like netbase-data which could be installed without all the heavy dependencies of netbase. I'd especially like to hear the opinions of the netbase and base-files packages' maintainers on this. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: move /etc/{protocol,services,rpc} to base-files
Le Vendredi 03 Février 2006 13:30, Marco d'Itri a écrit : > On Feb 03, Daniel Schepler <[EMAIL PROTECTED]> wrote: > > So I'd like to propose moving those data files from netbase to > > base-files. If > > No. The correct solution is to fix netbase by moving update-inetd to > each *inetd package. > But aj does not want to do this until update-inetd will have been > rewritten, so if you care you need to fix this first. My main concern wasn't the orphan inetd issue, for which fixing #162581 would be the correct fix. It seems to me that currently netbase is a user package to ensure a reasonable networking environment -- which is much more than what most source packages Build-Depending on netbase need. If you're suggesting that with a move of update-inetd then netbase would become more like the netbase-data I was suggesting as an alternative, with minimal dependencies, that would be fine with me. -- Daniel Schepler
ITP: sjfonts -- Some Juicy Fonts handwriting fonts
Package: wnpp Severity: wishlist * Package name: sjfonts Version : 2.0.1-1 Upstream Author : Steve Jordi * URL or Web page : http://sourceforge.net/projects/sjfonts * License : GPL, with special exception (embedding the font doesn't in itself make a document GPL) Description : Some Juicy Fonts handwriting fonts This package contains two handwriting fonts created by Steve Jordi, Delphine and SteveHand, in TrueType format. (I'm mainly packaging this because the blinken package needs the SteveHand font.) (And sorry about the CC instead of an X-Debbugs-CC... my local mail relay is silently dropping anything I send through exim for some reason, direct connections to external SMTP ports are blocked, and I couldn't figure out how to get kmail to do an X-Debbugs-CC.) -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug #352041: ITP: sjfonts -- Some Juicy Fonts handwriting fonts
Le Jeudi 09 Février 2006 10:57, Daniel Schepler a écrit : > (And sorry about the CC instead of an X-Debbugs-CC... my local mail relay > is silently dropping anything I send through exim for some reason, direct > connections to external SMTP ports are blocked, and I couldn't figure out > how to get kmail to do an X-Debbugs-CC.) For future reference, the bug number assigned is #352041. -- Daniel Schepler
Re: pbuilder, xvfb and nonexisting /tmp/.X11-unix
Le Dimanche 12 Février 2006 20:04, Thomas Viehmann a écrit : > Hi, > > I'm seeking advice on the following problem: > - xvfb-run bails out on nonexistant / not root-owned /tmp/.X11-unix, > - a/my pbuilder chroot won't have /tmp/.X11-unix, > - I need some X (xvfb is fine) to build libaqbanking (glade-2 code > generation needs X bug). > > A working work-around is build-depending on fakeroot and calling > fakeroot xvfb-run. > > Any better ideas? Have you tried just recreating base.tgz with an up-to-date pbuilder? pbuilder (0.138) unstable; urgency=low * Bug fix: "pbuilder: please add x11-common to policy-rc.d", thanks to patch from Aurelien Jarno (Closes: #337541). Fixes interaction with xvfb. Please recreate base.tgz for this to take effect. -- Junichi Uekawa <[EMAIL PROTECTED]> Fri, 11 Nov 2005 08:46:38 +0900 -- Daniel Schepler
Re: May a package assume that builds are performed with root-like rights? (was: jadetex: FTBFS: mktexdir failed)
Le Jeudi 23 Février 2006 16:37, Frank Küster a écrit : > So the current state is: If pbuilder runs all commands inside the > chroot, everything is fine, and AFAIK the same is true for the buildds. > But if you su to some user in the chroot, near to every package that > Build-depends on tetex-bin will FTBFS, unless you specifically arrange > for that user to be in group "users" (or anything else we switch to, I > don't care much). FWIW, jadetex is the only TeX-using package to actually FTBFS so far for me because of this -- including some that use docbook-utils and thus jadetex indirectly. For example, I just tried running pbuilder on make_3.80+3.81.b4-1.dsc again, which does create some fonts during the build, and the build completes fine, except that I get error messages like kpathsea: Running mktexpk --mfmode ljfour --bdpi 600 --mag 1+264/600 --dpi 864 cmbx12 mkdir: cannot create directory `././var/cache/fonts/pk/ljfour': Permission denied mktexpk: mktexdir /var/cache/fonts/pk/ljfour/public/cm failed. kpathsea: Appending font creation commands to missfont.log. dvips: Font cmbx12 not found, characters will be left blank. (BTW, I think you forgot to send that message to [EMAIL PROTECTED] -- just as well, since you misspelled reassign. :) -- Daniel Schepler
Re: May a package assume that builds are performed with root-like rights?
Le Jeudi 23 Février 2006 17:20, Frank Küster a écrit :
> > For example, I just tried running pbuilder on
> > make_3.80+3.81.b4-1.dsc again, which does create some fonts during the
> > build, and the build completes fine, except that I get error messages
> > like kpathsea: Running mktexpk --mfmode ljfour --bdpi 600 --mag 1+264/600
> > --dpi 864 cmbx12
> > mkdir: cannot create directory `././var/cache/fonts/pk/ljfour':
> > Permission denied
> > mktexpk: mktexdir /var/cache/fonts/pk/ljfour/public/cm failed.
> > kpathsea: Appending font creation commands to missfont.log.
> > dvips: Font cmbx12 not found, characters will be left blank.
>
> Well, that's a problem and a bug, too.
Indeed. I hadn't even noticed this was happening until I tried that and
looked closely at the build log.
Here's a thought: how hard would it be to make TeX fall back to caching in a
directory under the user's home directory (maybe $HOME/.fonts/texmf or so) if
it can't write to /var/cache/fonts? pbuilder does have $HOME set up to work
all right with BUILDUSER{ID,NAME}.
--
Daniel Schepler
Re: cdrtools
On Friday 11 August 2006 14:48 pm, Joerg Schilling wrote: > The FSF GPL FAQ e.g. incorrectly claims: > > Linking ABC statically or dynamically with other modules is making a > combined work based on ABC. Thus, the terms and conditions of the GNU > General Public License cover the whole combination. > > The GPL does not contain the term "combined work", so this is an invalid > claim. > > The GPL rather talks about a "derived work" and simply linking two modules > together does definitely not make module B a "derived work" of module A > if module A calls code from module B but module B does not call code from > module A. Let's put aside for the moment that the FAQ is not meant to be a legal document as opposed to the GPL itself, and that the FAQ is not saying B would be a derived work of A, but rather that the combination would be... I have a general question about how the GPL is construed to cover the case of dynamic linking. According to the GPL, section 0: The act of running the Program is not restricted... And since dynamic linking is done at the time the program is run, this would appear to me to be what applies. In particular, it appears to me that you could satisfy the GPL and still dynamically link against a non-free library, and distribute both, by invoking the "mere aggregation" clause of section 2. (Of course, you would have to be very careful about any inline functions, etc., from the non-free headers...) As a hypothetical example, let's say that program A uses library B, both licensed under the GPL. Now the author of B decides he doesn't want anybody selling B at all, so he releases a newer version under a non-free license, and Debian decides to package the old version of B as B-free and the new version in non-free. Is Debian allowed to keep distributing A, while distributing B-nonfree at the same time, given that some users might not end up installing B-free? Suppose that later B-free is considered old and buggy enough that we refuse to support it, so B-free is removed from the archive. Now does Debian have to stop distributing A as well? Even if by this point nobody actually had B-free installed any more? (I think my answers would be: distributing A with B-free and B-nonfree is permissible, but once B-free went A would have to go as well. Of course, there would also be the solution we already have with B-free = lesstif and B-nonfree = libmotif, but let's say for the sake of argument B's maintainer doesn't take that course, and instead makes libB1-nonfree: Provides: libB1.) On the other hand, since the FSF is the author of the license, and their own FAQ states that they consider dynamic linking to fall under the terms of the license, distributing GPL programs dynamically linked against GPL-incompatible libraries would clearly be exploiting a loophole under any definition of that term that I know of. And exploiting a loophole in the GPL would hardly be a way to endear oneself to the free software community. Thus, I'm hoping that the above is more of an academic question than anything else. In any case, static linking clearly falls under the definition of a "work based on the Program" in section 0, so you cannot e.g. extend GPL'd program A to use non-free library B, then distribute a resulting binary with B statically linked in. (Which is not the same thing as saying this would make B a derived work of A.) -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL question [Was: Re: cdrtools]
On Friday 11 August 2006 18:10 pm, Goswin von Brederlow wrote: > I believe that the totaly interchangable option of specifying > "-static" or not should not change the free-ness of the source or > resulting binary. So if you link static and you agree that it is a > violation that way then you should not be able to get away with it by > linking dynamically. > > The GPL is viral in nature and specificaly made to work across linking > boundaries. People should not be able to add non-free portitons to the > source by hiding them in libraries. I agree, but then "should" and "is" sometimes disagree. But after thinking about it some more, I believe a dynamically linked binary together with the corresponding shared libraries should be considered as a distribution method for the complete program that gets assembled in a common address space. Consider for example the case of EvilCo, back before dynamic linking was widespread, trying to use a GPL'd library in their non-free program. They try to get around the GPL by distributing their compiled program code in a single .o file in a "mere aggregate" along with the GPL library .a file, and ask users to link the program themselves. This is obviously bogus; they've just created an alternate means of distribution of the resulting binary, and so the binary itself must be distributable under the terms of the GPL, which it isn't. And the case of a dynamically linked executable with shared libraries is almost exactly the same as this scenario, only it's the system dynamic linker doing the work instead of the user doing it manually. Anyway, as somebody else pointed out, this is off-topic for debian-devel, and I apologize. Please direct any replies to debian-legal (too bad kmail doesn't let me set Followup-To afaik). -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
On Wednesday 11 October 2006 14:12 pm, Gernot Salzer wrote: > Don't mechanisms like libpam_devperm grant exclusive access? > On login the ownership of the devices is set to the console user, > and only the owner is granted rwx-rights. On logout > ownership/permissions of the device revert to the old setting. That doesn't prevent a user from e.g. writing a program to keep /dev/dsp open after logout and then on request play a sound clip designed to embarrass the current user. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: malsync ready for adoption
On Sunday 15 October 2006 21:48 pm, Ludovic Rousseau wrote: > If you are interested you should also adopt libmal. It causes a problem > on kpilot and I offered the package to the kpilot maintainer without an > answer from him. See #389353. > > If no one adopt it I will request the removal of malsync from unstable. Sorry, I missed that message. I'm not interested in maintaining libmal; it's just an optional add-on to kpilot. If libmal were removed from unstable, I would most likely just recompile kdepim with the libmal-dev build-dep cut out. By the way, where did you get the idea that the submitter of #389353 and the kpilot maintainer were the same person? I'm not "Peter Robin". :) -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#322762: no blocking bugs anymore
On Friday 05 January 2007 20:56 pm, Thijs Kinkhorst wrote: > Hi, > > > Set any bugs about /usr/doc stuff to being blockers of this bug report. > > Use this as a tracking/coordination bug for the remainder of the > > transition. > > > > Note that once this transition is complete we will need to do something > > in base-files to remove the /usr/doc directory, if it is empty. It won't > > be empty in all cases, for example a user might have non-debian or old > > packages that have not transitioned still installed. This bug can be > > reassigned to base-files to deal with that last step once it is no > > longer blocked by any other bugs. > > Well, today I have fixed the last two remaining bugs that blocked this > bug (I'll have to followup to them to see whether the fixes will get to > Etch, but that is not really on topic for this bug per se). > > Hence, I think now is the time to continue with the next steps as > outlined in the first message in the bug, right? It appears that inform's postinst still creates a /usr/doc symlink, and this seems to have been missed. What's the appropriate severity for a bug to be filed against inform? -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building the whole Debian archive with GCC 4.1: a summary
Le Samedi 25 Mars 2006 22:54, Martin Michlmayr a écrit : > Obviously, compiling the archive from source leads to many important > insights. What I found out over the last two weeks is just how much > work it actually is. We should try to create better infrastructure > to make manual compilation of the whole archive easier. It seems > that Roland Stigge has done some work on this already with his DARTS > project [5] but I have yet to take a look at it. I've been working on a Perl script to use pbuilder to do a recompilation of the archive off and on for a few years now. There are a few packages, such as gnat, which obviously cannot be compiled from scratch, but otherwise I've managed to create an accompanying set of "cycle-breaker" scripts to work around circular Build-Depends, so that bootstrapping from just the build-essential packages should be possible. On the other hand, these break frequently, and it would be nice if the involved packages could somehow support doing the reduced initial builds; but I haven't come up with a reasonable way of doing this yet. I've considered packaging the script as "pbuildd" several times, but at the moment setting up the build system is a lot of work, and the script itself is not very configurable (e.g. you'd have to modify it by hand if you wanted to try building testing instead of unstable, or include experimental and/or non-free packages). I guess an alternative is to put my work up on an alioth project, or maybe somewhere under the pbuilder alioth project, if there's interest. By the way: my latest experiment is putting in a hook script to build everything as if it were a binNMU, with a version of e.g. 1.2-3+pb1, in order to help apt distinguish those versions from the official ones. The good news is that most packages build with no problem like this; on the other hand, a few of them FTBFS or break. What would be the appropriate severity for such bugs? I'm leaning towards "serious" myself, since the release team should expect to be able to schedule binNMU's without worrying whether they'll work. (And I'm impatiently waiting for XOrg 7.0 to enter unstable, to see how that will affect the number of cycle-breaker scripts needed. :) -- Daniel Schepler
Re: Building the whole Debian archive with GCC 4.1: a summary
Le Lundi 27 Mars 2006 11:54, vous avez écrit :
> On Mon, 27 Mar 2006, Daniel Schepler wrote:
> > By the way: my latest experiment is putting in a hook script to build
> > everything as if it were a binNMU, with a version of e.g. 1.2-3+pb1, in
> > order to help apt distinguish those versions from the official ones. The
> > good news is that most packages build with no problem like this; on the
> > other hand, a few of them FTBFS or break. What would be the appropriate
> > severity for such bugs? I'm leaning towards "serious" myself, since the
> > release team should expect to be able to schedule binNMU's without
> > worrying whether they'll work.
>
> Could you provide a list of affected packages (and maintainers)
> somewhere? (And yes, I think serious is probably the correct severity
> should you decide to file bugs)
I haven't gotten all the way through, so I don't have a complete list. I'm
planning to start filing bugs soon, though, and I could classify them with a
usertag if you like (once I figure out how assigning them works).
Just off the top of my head, some of the more notable ones are:
apt -- The only one in a pbuilder chroot to fail to build.
libsoup -- Builds but with a broken shlibs file, causing several other
packages to FTBFS locally.
pango1.0 -- The only one I've filed a bug on so far (#358127).
jfsutils -- The udeb for some reason gets built as a .deb instead, which I
noticed from its showing up in the new packages list in aptitude.
And by the way, I also won't catch versioned dependencies on
"foo-data (= ${Source-Version})", since I build the arch-indep packages here
too.
--
Daniel Schepler
Re: Building the whole Debian archive with GCC 4.1: a summary
Le Lundi 27 Mars 2006 14:57, j'ai écrit : > I haven't gotten all the way through, so I don't have a complete list. I'm > planning to start filing bugs soon, though, and I could classify them with > a usertag if you like (once I figure out how assigning them works). OK, I've started filing the bugs now, and I'll be adding usertags to put them under http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]:binnmu . By the way, is there a way to assign the usertag right when I file a bug, assuming I want to keep using [EMAIL PROTECTED] as the submitter address? -- Daniel Schepler
Re: Debian Light Desktop - meta package
Le Vendredi 14 Avril 2006 08:28, Kevin Mark a écrit : > Hi Linas, > what about /proc/cpuinfo to determine MHZ and /proc/meminfo to find MB. > does this provide some way to get this info accross all (or most) of the > archs/subarch? > And how about using /proc/* to guess what kind of storage is avalable to > determine which install will likely fill the HD? On laptops running powersaved, /proc/cpuinfo will show the current CPU speed instead of the maximum possible. So you need to be careful about depending on /proc/cpuinfo. -- Daniel Schepler
Re: Getting rid of circular dependencies, stage 4
Le Mardi 09 Mai 2006 22:49, Bill Allombert a écrit : > Debian Qt/KDE Maintainers ... > libkcal2b > libkdepim1a It looks like these two have circular dependencies because libkdepim depends on libkcal, while a couple of the standard libkcal plugins (namely kcal_kabc.so and kcal_remote.so) depend on libkdepim. I don't see any easy way to disentangle these. -- Daniel Schepler
Re: Getting rid of circular dependencies, stage 4
Le Mercredi 10 Mai 2006 17:09, Pierre Habouzit a écrit : > why do kaffe-[pj]threads depends upon gjdoc ? isn't a recommends > enough ? > > given its description, it looks like a developpement tool, and I don't > get why it's needed just for running java apps, I even don't really > understand why it should even *suggest* it. > > IMHO kaffe-dev should depends upon gjdoc, because it makes sense, but > not kaffee (or it's threaded implementations). This was already discussed in bug #328648 and #362769, where the kaffe maintainers say that kaffe is supposed to be a whole development kit. I don't understand myself why they can't just make kaffe be a metapackage depending on everything, and still make it possible to install just the runtime if you really want. -- Daniel Schepler
Re: Build failure with autoconf 2.60: "requires autoconf 2.53 or newer"
On Tuesday 25 July 2006 13:40 pm, Martin Michlmayr wrote: > Half of KDE and a number of other applications currently fail to build > > with a message similar to: > | *** YOU'RE USING autoconf (GNU Autoconf) 2.60. > | *** KDE requires autoconf 2.53 or newer > > Before I file bugs on these packages, I wanted to check whether this > is a known problem and/or whether the new autoconf reports its version > in an incompatible way (that could be changed to avoid these build > failures). > > Comments? I already knew this was an issue in kdeedu and kdegames. However, there's a new upstream version 3.5.4 of KDE due out soon, and I was planning to wait for that to make new uploads. (PS, a small comment on the patch that got applied on kdepim -- it's just going to break again once autoconf gets up to version 2.70, when it would have been just as easy to keep it working through version 2.99.) (PPS, I never got any email asking if I could handle the upload of kdepim myself, which I could have. But thanks anyway for taking care of that.) -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITP: tads
I'm planning to package TADS, which is a system for writing or playing text games similar to the Z-code system (inform, xzip/frotz/etc). The license is non-free. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Re: Proposal: removing libc5, altgcc and all their old-days dependencies
"Francesco P. Lovergine" <[EMAIL PROTECTED]> writes: > Someone could already know this amazing bug: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196015 I've seen this before; it seems that sometimes when the package is built from source, the resulting library is missing some symbols for some reason. AFAICT, this happens completely at random (i.e. if I use pbuilder twice on the package, it might be broken one time and fine the next). > IMO it's a good moment to drop all the following i386-specific packages > which are libc5 related: I agree, especially considering that ldso can't be built from source because of bug #168592. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Mass bug filing: Build-Depends on libgdbmg1-dev and/or imlib-dev
I don't know why my previous message on this topic didn't get through, so let me try again... I'm planning to file bugs against source packages which currently don't build in unstable because of build dependencies on libgdbmg1-dev or imlib-dev. Currently, the packages involved would be: For libgdbmg1-dev (excluding packages with Build-Depends on "libgdbm-dev | libgdbmg1-dev"): acm, am-utils, apache-perl, gauche, hypermail, inn, ipac-ng, jenova, jwhois, libapache-mod-perl, libgda, maildrop, mozart, nis, pdns, python1.5, python2.1, qpopper, ruby-beta, saml, sced, siag, skk, slpim, smail, tdb, xfmail, xkbsel, zmailer, zmailer-ssl with maintainers: Akira TAGOH <[EMAIL PROTECTED]> Daniel Jacobowitz <[EMAIL PROTECTED]> Debian QA Group <[EMAIL PROTECTED]> Enrique Zanardi <[EMAIL PROTECTED]> Florian Hinzmann <[EMAIL PROTECTED]> Gregor Hoffleit <[EMAIL PROTECTED]> Hatta Shuzo <[EMAIL PROTECTED]> Hector Garcia <[EMAIL PROTECTED]> Josip Rodin <[EMAIL PROTECTED]> Marco Kuhlmann <[EMAIL PROTECTED]> Marco d'Itri <[EMAIL PROTECTED]> Marek Habersack <[EMAIL PROTECTED]> Miquel van Smoorenburg <[EMAIL PROTECTED]> Noel Koethe <[EMAIL PROTECTED]> Peter Karlsson <[EMAIL PROTECTED]> Phil Brooke <[EMAIL PROTECTED]> Philippe Troin <[EMAIL PROTECTED]> Scott James Remnant <[EMAIL PROTECTED]> Takao KAWAMURA <[EMAIL PROTECTED]> Vikram Aggarwal <[EMAIL PROTECTED]> Wichert Akkerman <[EMAIL PROTECTED]> Yu Guanghui <[EMAIL PROTECTED]> akira yamada <[EMAIL PROTECTED]> For imlib-dev: chameleon, enlightenment, epplets, kdegraphics, motioneye, mozart-gtk, pixelize, qvwm, vertex, w3m, xteddy with maintainers: Andreas Tille <[EMAIL PROTECTED]> Arto Jantunen <[EMAIL PROTECTED]> Christophe Le Bars <[EMAIL PROTECTED]> Christopher L Cheney <[EMAIL PROTECTED]> Eduardo Marcel Macan <[EMAIL PROTECTED]> Fumitoshi UKAI <[EMAIL PROTECTED]> Laurence J. Lane <[EMAIL PROTECTED]> Marco Kuhlmann <[EMAIL PROTECTED]> Shuichi OONO <[EMAIL PROTECTED]> Stephen Frost <[EMAIL PROTECTED]> Uwe Hermann <[EMAIL PROTECTED]> -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Re: Mass bug filing: Build-Depends on libgdbmg1-dev and/or imlib-dev
Adam Heath <[EMAIL PROTECTED]> writes: > On Sat, 28 Jun 2003, Daniel Schepler wrote: > >> I don't know why my previous message on this topic didn't get >> through, so let me try again... > > murphy has been having load issues, amoung other things. > >> I'm planning to file bugs against source packages which currently >> don't build in unstable because of build dependencies on libgdbmg1-dev >> or imlib-dev. Currently, the packages involved would be: > > Why? Because they don't build from source anymore. Which creates problems for people trying to use pbuilder, apt-build, etc. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Bug#213964: ITP: qtads -- Qt TADS interpreter
Package: wnpp Severity: wishlist * Package name: qtads Version : 1.3a Upstream Author : Nikos Chantziaras <[EMAIL PROTECTED]> * URL or Web page : http://qtads.sourceforge.net/ * License : GPL Description : Qt text-only interpreter for TADS This package provides an interpreter for TADS game files, using a Qt interface. It can run either TADS 2 games (which have an extension of .gam) or TADS 3 games (which have an extension of .t3). See http://www.ifarchive.org/indexes/if-archiveXgamesXtads.html for a large collection of available TADS games. . This interpreter only supports text output. Games using HTML-TADS multimedia features will still work, but you won't see graphics or hear sounds. Other features include: * Full Unicode support for TADS 3 and HTML TADS games. * Full text justification. * Support for multiple user configurations, which you can switch between at runtime. . TADS, the Text Adventure Development System, is a system for writing and playing interactive fiction games. This means that the primary method for interacting with the game is to type in commands and read the game's responses -- similar to Infocom's games from the 1980's. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Gradual mass bug filing for C++ transition / gcc-4.0 issues
I'm planning to start making sure every package which fails to build with the current toolchain has an RC bug submitted against it. In most cases, this should simply involve setting Andreas Jochens' already existing bugs to serious, although I'll confirm each before doing this. Exceptions will include: - Packages waiting on other packages to transition. - Failures clearly due to glibc issues (e.g. invalid lvalue errors caused by ). I might also do NMU's for some of the more important packages, with a delay of 2 days, or 5 days minus the time since the last dependent package transitioned, whichever is longer. Right now I have my eyes on jade/opensp/openjade, and possibly db*. By the way, any estimates on how long it will be before we get a glibc upload correcting the problems mentioned above? -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gradual mass bug filing for C++ transition / gcc-4.0 issues
Aurelien Jarno <[EMAIL PROTECTED]> writes: > On Fri, Jul 15, 2005 at 11:00:08AM -0700, Daniel Schepler wrote: >> package transitioned, whichever is longer. Right now I have my eyes >> on jade/opensp/openjade, and possibly db*. > > I have already NMUed opensp, but it is still in incoming because of the > new libosp4c2 package. All right, I guess I should have checked that first. Anyway, jade is now in DELAYED/2-day/. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libcurl3-dev's reverse Build-Depends
Since libcurl3-dev was removed from unstable, suddenly a lot of packages are now FTBFS because their Build-Depends on libcurl3-dev cannot be satisfied. Would you consider providing a transition libcurl3-dev package for now, or making libcurl3-openssl-dev provide libcurl3-dev? -- Unless it's your intention to force all maintainers to choose explicitly between the openssl and gnutls versions immediately, in which case there should be a mass bug filing. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: missing package conflicts
On Wednesday 16 April 2008 02:58:52 pm Ralf Treinen wrote: > Hi, > > The following list contains packages that fail to install at the same time > since one package tries to overwrite a file owned by the other package: > > http://edos.debian.net/missing-conflicts/ > > In these package pairs, (at least) one of the two packages must declare > a conflict with the other package. > > I will file bugs soon (hopefully before leaving on [VAC] on 18/4). One > interesting question is: against which of the conflicting packages > should the bug be filed? The less popular one according to popcon? The > more recent one in the archive? The one with the more active > maintainer? > > Here is how the clashes were detected: > 1) generate from the Contents file a list of package pairs that contain >at least one common file. > 2) use pkglab (one of the EDOS tools, debian packages are pending) to > select from the list obtained in (1) those pairs of packages that are > installable at the same time when looking only at dependency relationships. > 3) try installing the packages obtained from (2) in a sid chroot. > > Some statistics for amd64/sid: > - 2432104 files listed in the Contents file > - 867 package pairs that contain at least one common file > - 102 package pairs that contain at least one common file, and that are > co-installable according to the EDOS criteria > - 27 package pairs that fail to install together due to attempted file > overwrite > > -Ralf. I'd be interested in seeing how there can be 75 package pairs with shared file names which coinstall successfully. In the case of a Replaces making that possible, I'd say that the package with files being replaced should usually have a bug report submitted to get those obsolete files removed. On the other hand, if there's a diversion involved, that seems fine. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Mass bug filing: FTBFS because of using imake without Build-Depends on xutils-dev
From the changelog for xorg 1:7.3+11: * Remove the dependency of xutils against xutils-dev, it was only useful for transitional purpose in Etch, closes: #418123. This means that any package which used xmkmf/imake and had xutils, instead of xutils-dev, for the Build-Depends will now FTBFS. It seems there were several packages which fall into this category (at this point, I've found 11 packages starting with [0-9a-d]). So unless there are any objections, I'll start filing bugs as I find them. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mass bug filing: FTBFS because of using imake without Build-Depends on xutils-dev
On Sunday 08 June 2008 02:55:23 am Julien Cristau wrote: > On Sun, Jun 8, 2008 at 09:24:45 +0200, Lucas Nussbaum wrote: > > I found those issues as well (there are 84 packages failing to build > > because of that). I discussed this briefly on #debian-x, but it's not > > clear yet if the X maintainers want to revert this change. > > > > I would personally prefer if this change was reverted and done after > > lenny. We don't really need 84 new RC bugs... > > I think I told you I'd revert it. But it would be nice if the mass bug > filing was done anyway, at important severity, so people have a chance > to fix that before it becomes RC when we drop the dependency again after > lenny. > > Anyway, a serious bug against xutils 1:7.3+11 is in order for now. > > Cheers, > Julien OK, that sounds like a good plan. I'll file the bug against xutils and then start filing important severity bugs against the affected packages. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
texi2html -split_chapter destination changed
Hi, with the current version of texi2html (1.82-1), I'm getting lots of build failures like (from diffutils-doc): ... debian/rules build /usr/bin/make make[1]: Entering directory `/tmp/buildd/diffutils-doc-2.8.1' makeinfo --output=diff.info diff.texi texi2html -split_chapter diff.texi make[1]: Leaving directory `/tmp/buildd/diffutils-doc-2.8.1' touch build fakeroot debian/rules binary rm -rf debian/tmp debian/diff-doc install -d debian/tmp/DEBIAN debian/tmp/usr/share/doc/diffutils-doc \ debian/tmp/usr/share/doc-base debian/tmp/usr/share/info install -m 644 debian/diffutils-doc debian/tmp/usr/share/doc-base cp -p diff/*.html debian/tmp/usr/share/doc/diffutils-doc cp: cannot stat `diff/*.html': No such file or directory make: *** [binary-indep] Error 1 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 It looks like it put the html files in diff before, but now it's putting them just in the current directory. Before I started filing bug reports, I wanted to know: is this an intentional change in behavior, or is it a bug in texi2html? -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Filing FTBFS bugs and packages in NEW
On Friday 01 June 2007 05:59:14 am Kari Pahula wrote: > I'd like to file a wishlist bug on people who file FTBFS bugs. > > It would be nice if you checked first whether there's a package > pending in NEW or incoming and see if that might resolve the issue > already. > > I'm looking at you, #426867. > > Thank you. Sorry about that. I usually try to search in NEW and in incoming.debian.org before filing those bugs, but I must have missed it in this case. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can we require build-arch/indep targets for lenny?
On Monday 18 June 2007 04:30:55 am Goswin von Brederlow wrote: > Hi, > > I would like to gather up some momentum for a policy change. Namely > that the build-arch/indep targets in debian/rules become required > instead of being optional. > > The reason for this is that dpkg-buildpackage can't reliable detect > the existance of the build-arch/indep targets and must call 'build' > instead. This forces every source to compile both architecture > specific and architecture independent code on all buildds and > increases the Build-Depends of packages a lot. How about instead requiring something like: the build-arch target must return successfully or with a status of 2 (the standard make error status for "target not found"), and in the latter case the build target must return successfully. That is, if Build-Depends but not necessarily Build-Depends-Indep are installed, the shell snippet debian/rules build-arch || (test $? -eq 2 && debian/rules build) must work and exit with a status of 0. This would make it possible for dpkg-buildpackage -B to be reliable while allowing most (or even all?) of the current packages to stay as they are until maintainers can add the recommended build-arch target. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Help] Autoconf problems when trying to build WordNet 3.0 package
On Wednesday 27 June 2007 16:45:06 pm Andreas Tille wrote: > On Wed, 27 Jun 2007, Ben Pfaff wrote: > > OK, I can see now that /usr/lib/tk8.4/tkConfig.sh sets TK_PREFIX > > in the environment of "configure". But what is meant to > > propagate this environment variable into the Makefile? I don't > > see anything intended to do that. Autoconf does not > > automatically propagate all environment variables from > > "configure" into Makefiles (nor should it). > > > > It looks to me like there's a missing piece in the build system. > > Yes, you both seem to come to the same conclusion as I myself - but > I have no idea how to fix this. There must be some trick to propagate > these variables, but how? I've got no clue out of reading the > texinfo docs. For example, AC_SUBST(TK_PREFIX), then make sure Makefile.in has a line TK_PREFIX = @TK_PREFIX@ -- unless it's generated by automake, which will put in lines like that automatically. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
I've been unable to reproduce any of the "One Definition Rule" bugs you filed. Jigdo builds fine; apt builds successfully apart from #428623 (and #359634 on my local setup); and gnome-vfsmm2.6 is fine until it hits #422813. It looks like something was either fixed or reverted. I also tried compiling jigdo using the current gcc-snapshot, and it built fine after I added some missing #includes. So with your permission, I'd like to close those three bugs. BTW: anybody more versed in the bts system than I am, how can I get #359634 marked as not actually being fixed? My clumsy attempts just ended up making things more confused. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problems with closing certain bugs
I appear to be unable to close certain bugs lately, while others work fine. One earlier example was #205163, which I was trying to close as it was fixed a long time ago. Then yesterday closing #379237 and #387587 worked, but in the same message my attempt to close #378102 was rejected. With both #205163 and #378102 I got a bounce message saying that [EMAIL PROTECTED] was an "unknown user". I tried sending a mail to [EMAIL PROTECTED] about #205163 several days ago, which I haven't gotten any response to yet. Does anybody else have any idea what's going on? Anybody else who's run into this? Maybe, just a random guess, it's not working on bug numbers containing a 0? -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Friday 29 June 2007 08:21:18 am Philippe Cloutier wrote: > > BTW: anybody more versed in the bts system than I am, how can I get > > #359634 marked as not actually being fixed? > > Does a simple reopen not work? I guess it does. But I thought reopen was deprecated since the versioning stuff was added to the BTS. However, the "notfixed" command issued earlier didn't completely remove the "done" status from the bug... (And I thought I'd tried notfixed earlier -- how come it worked for Touko Korpela but not for me when afaict I tried exactly the same command?) So my question remains: what's the officially sanctioned, nondeprecated way to revert the effects of a versioned message to [EMAIL PROTECTED] -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with closing certain bugs
On Friday 29 June 2007 13:32:44 pm Adam D. Barratt wrote: > FWIW, I'm guessing the two bug numbers may have been typos as #378102 is > a mysql security bug and #205163 a translation for gnapster whereas your > closure message refers to gcc. OK, sorry for the noise. You're completely correct, I actually meant #378012 and #215063. I guess I should have checked more carefully before putting my foot in my mouth. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Mass bug filing: Versioned Build-Depends on linux-kernel-headers
I intend to do a mass bug filing soon on packages that FTBFS because they have a versioned Build-Depends on linux-kernel-headers, which has been removed from sid. (Unversioned Build-Depends are fine for now, since linux-libc-dev Provides it.) According to a quick search through the index files, no binary packages are affected, at least on i386, and the source packages affected are: Guenter Geiger (Debian/GNU) <[EMAIL PROTECTED]> gem Paul Bame <[EMAIL PROTECTED]> palo Ben Collins <[EMAIL PROTECTED]> silo Paul Cupis <[EMAIL PROTECTED]> eagle-usb Debian multimedia packages maintainers <[EMAIL PROTECTED]> libdvb vls Rene Engelhard <[EMAIL PROTECTED]> wavemon Eric Evans <[EMAIL PROTECTED]> xsupplicant Matthew Garrett <[EMAIL PROTECTED]> hotkey-setup Debian QA Group <[EMAIL PROTECTED]> toshset Daniel Jacobowitz <[EMAIL PROTECTED]> bogl Peter Makholm <[EMAIL PROTECTED]> inotify-tools Noah Meyerhans <[EMAIL PROTECTED]> iputils Josselin Mouette <[EMAIL PROTECTED]> gnome-vfs2 -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mass bug filing: Versioned Build-Depends on linux-kernel-headers
On Saturday 14 July 2007 17:20:42 pm Daniel Schepler wrote: > I intend to do a mass bug filing soon on packages that FTBFS because they > have a versioned Build-Depends on linux-kernel-headers, which has been > removed from sid. (Unversioned Build-Depends are fine for now, since > linux-libc-dev Provides it.) According to a quick search through the index > files, no binary packages are affected, at least on i386, and the source > packages affected are: Now submitted. Check http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]:build-dep-linux-kernel-headers if interested in tracking. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
On Wednesday 08 August 2007 01:24:06 pm Tim Hull wrote: > > I guess that is a bug in iceweasel wrt. the default parameters. > > > > Anyway, you should use epiphany instead, which doesn't have this issue > > in etch :) > > It's not just etch - this happens on lenny/sid as well. > I guess I should file a bug on this - it appears to be fixed in Ubuntu, so > maybe there's a patch there that could be used. > > Regarding drivers, I know there are source packages in non-free (and main, > for some free but out-of-tree drivers) and the module-assistant will build > these. I was just suggesting a more GUI-oriented approach (like Ubuntu > Restricted Manager) - though non-free drivers would ONLY be displayed when > non-free is in sources.list. > > Regarding frequency scaling - it didn't work for me (I had to manually > enable it, though I didn't need a custom kernel or anything like that). > I'll investigate further and possibly file a bug. At least with debian.org, it appears the CSS specifies a font of "Arial, Helvetica, sans-serif", which means if msttcorefonts isn't installed, it falls back to the ugly bitmap Helvetica fonts. Which seems more like a bug in the CSS for a website for free software, than in the web browsers obeying this directive. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Testing parallel builds
Inspired by today's new upload of dpkg, I'm going to try doing a rebuild of the archive using "dpkg-buildpackage -j3" and submit bugs as I find them. The bugs will be wishlist for now, and I'll assign usertag [EMAIL PROTECTED]:ftbfs-parallel to those bug reports for those interested in tracking the issue. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing parallel builds
On Monday 08 October 2007 07:49:09 am Pierre Habouzit wrote: > On Mon, Oct 08, 2007 at 10:53:05AM +0000, Daniel Schepler wrote: > > Inspired by today's new upload of dpkg, I'm going to try doing a rebuild > > of the archive using "dpkg-buildpackage -j3" and submit bugs as I find > > them. The bugs will be wishlist for now, and I'll assign usertag > > [EMAIL PROTECTED]:ftbfs-parallel to those bug reports for those > > interested in tracking the issue. > > Err please just don't. Many upstreams won't build properly with > parallel builds because their makefile just don't support it. Most > importantly, I believe that only the biggest packages benefit from a > parallel build, hence it should be an opt-in option that packagers may > use if their package support it, and if they believe it matters > (packages where build time is under the few minutes won't benefit from > it a lot e.g., as it's probable that most of the time is lost in the > configure and Debianization stages). Then isn't that something that should be fixed? With dual-core processors becoming more and more common, I would expect some users (myself included) to be in the habit of typing `make -j2' or `dpkg-buildpackage -j3' to take advantage, and then get annoyed if it doesn't work. Especially when the easy work-around, if you don't want to bother adding the proper dependencies to the make targets, is just to add ".NOPARALLEL:" somewhere in the Makefile. Anyway, I'm aware a lot of packages will probably break at the moment, which is why I'm using wishlist. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing parallel builds
On Monday 08 October 2007 07:50:58 am Domenico Andreoli wrote: > On Mon, Oct 08, 2007 at 06:53:05AM -0400, Daniel Schepler wrote: > > Inspired by today's new upload of dpkg, I'm going to try doing a rebuild > > of the archive using "dpkg-buildpackage -j3" and submit bugs as I find > > them. The bugs will be wishlist for now, and I'll assign usertag > > [EMAIL PROTECTED]:ftbfs-parallel to those bug reports for those > > interested in tracking the issue. > > hmm... i was just trying to understand how to enhance my packges for > parallel build. (BTW how do you rebuild the whole archive?) I personally use a perl script called "pbuildd" to make sure the new packages work ok for their reverse-build-depends, with a few hand-written scripts thrown in to break cycles in the build-depends graph. A somewhat out-of-date version is somewhere in the pbuilder alioth CVS, I think, or you can write me if you want a more up-to-date version. Or there's a script in the pbuilder source package which just goes through every available package one by one and calls pbuilder on each. > if i got it right, those packages built using make & co should not need > any modification, while others (eg boost) which use other build systems > (eg bjam) may need some more work. Well, as long as the Makefiles are properly written. But if you do something like foo: bar baz bar: touch $@ baz: cp bar $@ (i.e. without proper dependencies) that will potentially break on parallel builds but won't on regular builds. > in the latter case, is there any conventional way to parse > DEB_BUILD_OPTIONS? last time i read about it there were a couple of ways > both having dark sides... ah.. BTW google is not able to provide me any > documentation of DEB_BUILD_OPTIONS. where is it documented? It's documented in Debian policy, but parallel hasn't been added there yet. I think the new dpkg-buildpackage -j passes DEB_BUILD_OPTIONS="parallel=". -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing parallel builds
On Monday 08 October 2007 08:07:12 am Daniel Schepler wrote: > Especially when the easy work-around, if you don't want to bother adding > the proper dependencies to the make targets, is just to add ".NOPARALLEL:" > somewhere in the Makefile. Sorry, that should be ".NOTPARALLEL:". -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing parallel builds
On Monday 08 October 2007 08:30:53 am Pierre Habouzit wrote: > On Mon, Oct 08, 2007 at 12:07:12PM +0000, Daniel Schepler wrote: > > On Monday 08 October 2007 07:49:09 am Pierre Habouzit wrote: > > > On Mon, Oct 08, 2007 at 10:53:05AM +0000, Daniel Schepler wrote: > > > > Inspired by today's new upload of dpkg, I'm going to try doing a > > > > rebuild of the archive using "dpkg-buildpackage -j3" and submit bugs > > > > as I find them. The bugs will be wishlist for now, and I'll assign > > > > usertag [EMAIL PROTECTED]:ftbfs-parallel to those bug reports > > > > for those interested in tracking the issue. > > > > > > Err please just don't. Many upstreams won't build properly with > > > parallel builds because their makefile just don't support it. Most > > > importantly, I believe that only the biggest packages benefit from a > > > parallel build, hence it should be an opt-in option that packagers may > > > use if their package support it, and if they believe it matters > > > (packages where build time is under the few minutes won't benefit from > > > it a lot e.g., as it's probable that most of the time is lost in the > > > configure and Debianization stages). > > > > Then isn't that something that should be fixed? With dual-core > > processors becoming more and more common, I would expect some users > > (myself included) to be in the habit of typing `make -j2' or > > `dpkg-buildpackage -j3' to take advantage, and then get annoyed if it > > doesn't work. > > Well, try to fix the ocaml build-system to work in parallel, if you > are able to do it, I'll gladly fix the rest of Debian makefiles :P OK, I'll look into that when I get some free time. > > Especially when the easy work-around, if you don't want to bother adding > > the proper dependencies to the make targets, is just to add > > ".NOPARALLEL:" somewhere in the Makefile. > > This is a GNU extension. So is -j, I think. It shouldn't break anything if the system make doesn't recognize it. > > Anyway, I'm aware a lot of packages will probably break at the moment, > > which is why I'm using wishlist. > > I still believe that you should not file such bugs, I still fail to > see how it improves debian, as if we really need to build more packages > at the same time, we could run many sbuild instances on the same > machine. What about the case of someone wanting to debug a large package that hasn't "opted in" under your model? Then either I have to try calling dpkg-buildpackage with -j and run the risk that it might silently break somehow, or else put up with a longer build time. Also, adding the -j flag to dpkg-buildpackage IMHO creates the expectation that it should work on most packages. Are you going to file a bug on dpkg-dev asking for that to be removed? -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing parallel builds
On Monday 08 October 2007 08:39:21 am Bernd Zeimetz wrote: > > It's documented in Debian policy, but parallel hasn't been added there > > yet. I think the new dpkg-buildpackage -j passes > > DEB_BUILD_OPTIONS="parallel=". > > this sounds like it should not break things, as you have to evaluate > that manually. Or is there some magic which results into $(MAKE) beeing > make -j ? The question I was answering was about DEB_BUILD_OPTIONS, so I didn't see any reason to mention that it also sets MAKEFLAGS=-j. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing parallel builds
On Monday 08 October 2007 08:30:53 am Pierre Habouzit wrote: > I still believe that you should not file such bugs, I still fail to > see how it improves debian, as if we really need to build more packages > at the same time, we could run many sbuild instances on the same > machine. OK, how about this: I'll submit patches for all the bugs I've filed so far on this issue, and for any bugs I submit in the future. That way, the only person's time I'm wasting (according to you) will be my own. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Testing parallel builds, again
It looks like there are even more problems than I thought with the parallel builds, so I won't be able to submit bugs on them all in a timely manner. So for now, I've posted the build logs so far at http://people.debian.org/~schepler/build-logs/ if you want to see the results sooner. At this point, I've gotten through roughly the packages that Build-Depend only on debhelper, and I'll try to keep updating those pages regularly. One comment: if the page lists "succeeded but with jobserver warnings", that's because the script found warnings like make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. in the build log. But contrary to what the message says, the correct fix is usually to replace an explicit call to make with $(MAKE). -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver
On Wednesday 10 October 2007 02:57:59 pm Robert Edmonds wrote: > The only rationale for removing the *firmware* is compliance with GR > 2006-004... Reading this feels about like reading someone write, "The only rationale for not smoking cigarettes in this restaurant is compliance with state law." How about not suggesting that the majority of Debian developers who voted for that GR were crazy people making a decision with no rational basis? You might disagree with it, but at least try to understand that there was a reason for it that seemed valid to a lot of people. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packages with empty directories
I recently noticed that many of the binary packages in Debian have unnecessary empty directories in them, so I wrote a script to find all packages with any empty directories. The results are too numerous to post on the list. The list by maintainer/uploader is at http://people.debian.org/~schepler/empty-dirs-maint.txt and the full list of empty directories found is at http://people.debian.org/~schepler/empty-dirs.txt . Obviously, a lot of these will be false positives, so I definitely won't file mass bugs based on this list without checking the full details first. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages with empty directories
On Tuesday 20 November 2007 10:26:39 pm Cyril Brulebois wrote: > On 21/11/2007, Daniel Schepler wrote: > > Obviously, a lot of these will be false positives, so I definitely > > won't file mass bugs based on this list without checking the full > > details first. > > Maybe suggesting a lintian check would be a good idea? > > Cheers, It would be hard to write a check without numerous false positives. Under those circumstances I think they would be classified as "I:" messages, which hardly anybody would see anyway. I suppose it would be possible to write a check for empty /usr/sbin, /usr/bin, /etc, ... in packages != base-files, but that would miss a lot of cases. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages with empty directories
On Wednesday 21 November 2007 04:08:44 am Josselin Mouette wrote: > Hi, > > Le mercredi 21 novembre 2007 à 05:20 +0100, Michael Biebl a écrit : > > Imho adding a lintian check for empty /usr/bin, /usr/sbin, /usr/lib and > > /usr/include directories (as created by dh-make) would be a good start. > > Maybe we could check for empty directories except for a number of common > false positives (like the python-support directories or /var/games), and > for the rest, grep in the maintainer scripts. Some of the common false positives are /var/lib/ or /etc/, or subdirectories under one of those. Since often doesn't match the binary package name exactly, I don't see any easy way to detect these cases. -- Daniel Schepler
Re: Packages with empty directories
On Tuesday 20 November 2007 11:20:17 pm Michael Biebl wrote: > Imho adding a lintian check for empty /usr/bin, /usr/sbin, /usr/lib and > /usr/include directories (as created by dh-make) would be a good start. I wrote a lintian check implementing the conservative approach, and submitted a patch as bug #452316. It lists empty directories matching directories from base-files, as well as any empty subdirectories of /usr/include, /usr/share/man, and some others where they clearly make no sense. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Parallel build results
I finally got through the test builds of all the source packages in sid for i386 using dpkg-buildpackage -j3 on a dual core machine. The results as before are at http://people.debian.org/~schepler/build-logs/bymaint.html . Some statistics: 204 built BROKEN packages 1408 FAILED 230 FAILED, even with regular build 8986 succeeded 1014 succeeded, but with jobserver warnings These are not encouraging statistics, especially considering the fact that there are undoubtedly many false negatives, so I'll hold off on submitting bug reports for now. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Parallel build results
On Sunday 02 December 2007 02:12:40 pm Patrick Schoenfeld wrote: > Relevant parts for detox are: > /usr/bin/install -c -d /tmp/buildd/detox-1.1.1/debian/tmp/etc > /usr/bin/install: cannot create regular file > `/tmp/buildd/detox-1.1.1/debian/tmp/etc/detoxrc.sample': No such file or > directory > make[1]: *** [install-sample-config] Error 1 > make[1]: *** Waiting for unfinished jobs > /usr/bin/install: `/tmp/buildd/detox-1.1.1/debian/tmp/etc' exists but is > not a directory > make[1]: *** [install-base] Error 1 > make[1]: Leaving directory `/tmp/buildd/detox-1.1.1' Earlier, the Makefile is trying to execute /usr/bin/install -c detoxrc /tmp/buildd/detox-1.1.1/debian/tmp/etc/detoxrc.sample which failed because debian/tmp/etc was not yet created. So it appears the upstream package's Makefile is not parallel-safe, at least with regards to the install target. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Parallel build results
On Monday 03 December 2007 05:11:35 am Tim Cutts wrote:
> Well, am-utils lists as building broken packages, but when I looked at
> the log, it was just that the parallel build had produced the multiple
> binary packages in a different order from the serial build. At least,
> that's my interpretation of the following from debdiff:
>
> Files moved or copied from at least TWO packages or to at least TWO
> packages
> ---
>- -rw-r--r-- root/root DEBIAN/control
> From packages: am-utils-doc, am-utils, libamu4, libamu-dev
> To packages: am-utils-doc, libamu4, libamu-dev, am-utils
> -rw-r--r-- root/root DEBIAN/md5sums
> From packages: am-utils-doc, am-utils, libamu4, libamu-dev
> To packages: am-utils-doc, libamu4, libamu-dev, am-utils
> -rwxr-xr-x root/root DEBIAN/postinst
> From packages: am-utils-doc, am-utils, libamu4
> To packages: am-utils-doc, libamu4, am-utils
> -rwxr-xr-x root/root DEBIAN/postrm
> From packages: am-utils, libamu4
> To packages: libamu4, am-utils
>
> Or does that mean something more basic that's wrong with the packages?
The relevant difference is actually:
Control files of package am-utils: lines which differ (wdiff format)
Depends: libamu4 (= 6.1.5-7), portmap, {+libamu4,+} libc6 (>= 2.6.1-1),
libgdbm3, libhesiod0, libldap2 (>= 2.1.17-1), libwrap0, perl, debconf (>=
1.2.0), ucf, debianutils (>= 1.6)
So the Depends line got changed in the parallel build.
--
Daniel Schepler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Parallel build results
On Tuesday 01 January 2008 07:36:34 pm Aurelien Jarno wrote: > Did you compare the contents of the package with and without -j? I am > almost sure some of the successfully built packages are actually not > correctly built and some files are missing. > > For example I remember having seen some python packages building one > flavour after the other in different targets. I imagine this could > result in one of the flavour being overwritten by the other, and thus > not present in the resulting .deb file. I compared the control files and file lists from the packages and marked the build "broken" if it found significant differences. So that would have caught the case above. But not a case where, for example, the compiler runs were started before patches were completely applied, probably resulting in a mix of patched and non-patched code. However, due to the issues raised in the previous thread about 100% bit-by-bit reproducibility of package builds, I don't see any good way to detect that case automatically. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Parallel build results
On Monday 31 December 2007 04:07:15 pm Robert Millan wrote: > On Sat, Dec 01, 2007 at 09:21:33PM -0500, Daniel Schepler wrote: > > I finally got through the test builds of all the source packages in sid > > for i386 using dpkg-buildpackage -j3 on a dual core machine. The results > > as before are at > > http://people.debian.org/~schepler/build-logs/bymaint.html . > > Why -j3 ? It's already quite an effort to aim for -j2. Shouldn't we try > to fix those first? That's just my habit, the idea being to increase the probability that both CPUs have work to do while I/O is going on. And besides, I don't see that much of a qualitative difference between -j2 and -j3, for reasons already pointed out by others in the thread. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#156346: [ITP]: tads2-mode -- Emacs mode for editing TADS code
Package: wnpp Severity: wishlist * Package name: tads2-mode Version : 1.2 Upstream Author : Stephen Granade * URL : http://www.ifarchive.org/if-archive/programming/editors/tads2-mode.el * License : GPL Description : Emacs mode for editing TADS code This package provides an (X)Emacs mode which makes it easier to edit source code for TADS games. TADS implements a programming language especially designed for writing text adventures; interpreters for the resulting byte-code are available for most operating systems (including Debian GNU/Linux, in the tadsr package). -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Re: Bug#159037: general: Time Problem
(Already sent to the bug report address -- I accidentally Cc'ed to [EMAIL PROTECTED] the first time.) "Matt Filizzi" <[EMAIL PROTECTED]> writes: > Package: general > Version: N/A; reported 2002-08-31 > Severity: normal > Tags: sid > > I don't know what is causing this problem but all I know is that I have > narrowed it down to being caused either by a package or by the install > system. I installed from the woody install disks then upgraded to sid. > What happenes is that the time jumps ahead then back, eg (this is output > from "while true; do date;done" > > Sat Aug 31 19:07:26 EDT 2002 > Sat Aug 31 19:07:26 EDT 2002 > Sat Aug 31 19:07:26 EDT 2002 > Sat Aug 31 19:07:26 EDT 2002 > Sat Aug 31 20:19:01 EDT 2002 > Sat Aug 31 20:19:01 EDT 2002 > Sat Aug 31 20:19:01 EDT 2002 > Sat Aug 31 19:07:27 EDT 2002 > Sat Aug 31 19:07:27 EDT 2002 > > The only thing I did differently then previous installs was I told the > installer that it could set the bios go UTC. The only time it is really > noticable is when in X, the screensaver kicks in when it jumps. I can confirm that this bug happens on my system as well, even as far as the time jump being approximately 71.5 minutes. I had ntpd installed. I've recently tried disabling ntpd, but since it happens very sporadically for me, I can't tell yet whether disabling that works -- it sometimes takes on the order of a couple weeks of uptime before it happens. My bios clock is also set to UTC. I didn't even think of that as a possible cause before, but I don't see how this could be the cause since, as far as I know, the bios clock is only read or set at boot time or shutdown. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Bug#159037: general: Time Problem
"Matt Filizzi" <[EMAIL PROTECTED]> writes: > Package: general > Version: N/A; reported 2002-08-31 > Severity: normal > Tags: sid > > I don't know what is causing this problem but all I know is that I have > narrowed it down to being caused either by a package or by the install > system. I installed from the woody install disks then upgraded to sid. > What happenes is that the time jumps ahead then back, eg (this is output > from "while true; do date;done" > > Sat Aug 31 19:07:26 EDT 2002 > Sat Aug 31 19:07:26 EDT 2002 > Sat Aug 31 19:07:26 EDT 2002 > Sat Aug 31 19:07:26 EDT 2002 > Sat Aug 31 20:19:01 EDT 2002 > Sat Aug 31 20:19:01 EDT 2002 > Sat Aug 31 20:19:01 EDT 2002 > Sat Aug 31 19:07:27 EDT 2002 > Sat Aug 31 19:07:27 EDT 2002 > > The only thing I did differently then previous installs was I told the > installer that it could set the bios go UTC. The only time it is really > noticable is when in X, the screensaver kicks in when it jumps. I can confirm that this bug happens on my system as well, even as far as the time jump being approximately 71 minutes. I had ntpd installed. I've recently tried disabling ntpd, but since it happens very sporadically for me, I can't tell yet whether disabling that works -- it sometimes takes on the order of several weeks of uptime before it happens. My bios clock is also set to UTC. I didn't even think of that as a possible cause before, but I don't see how this could be the cause since, as far as I know, the bios clock is only read or set at boot time or shutdown. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Another mass bug filing: get rid of xlib6g*
As discussed previously, I'll be filing bugs against any source or
binary packages which still depend on the obsolete xlib6g* packages.
These will be normal severity for now, but will be raised to serious
severity (for source packages) or grave severity (for binary packages)
once these packages disappear.
The currently affected packages include:
Source packages: 3dchess, ax25-tools, bbdate, cheops, chimera2, clara,
clips, cpanel, crossfire-client, dfm, directory-administrator,
doxygen, ecawave, erlang, everybuddy, evolver, floatbg, geg,
gkrellm-mailwatch, gkrellm-radio, gkrellm-volume, gkrellmwireless,
gkrellweather, gmgaclock, gnome-ruby, gnome-system-tools, gretl,
gtkfontsel, icon, ion, ircii-pana, karpski, mp, nase-a60, nte,
octave-forge, openuniverse, openvrml, pcmcia-cs, pdl, postilion,
qbrew, rat, roxen, sabre, scrot, smurf, sourcenav, stardic,
svncviewer, sylpheed, sylpheed-claws, synaesthesia, vnc, vstream,
wmix, wmmon, wmmount, wmusic, workman, x2vnc, xarchon, xautolock,
xbreaky, xbuffy, xcal, xcin2.3, xeji, xflip, ximian-setup-tools,
xinput, xinv3d, xjig, xkbsel, xli, xlife, xmailbox, xmms-crossfade,
xmms-status-plugin, xmountains, xmpi, xpat2, xplanet, xscavenger,
xsok, xtet42, xzoom
Source packages specifying xlib6g-dev|xlibs-dev (in that order):
buici-clock, gmod, phaseshift, tclx8.2, tclx8.3, wdm, xlassie. These
will have wishlist bugs filed asking them to reverse the order.
Binary packages (excluding those in source packages listed above):
axyftp-gtk, axyftp-lesstif, codebreaker, gfpoken, glbiff, glotski,
gnome-think, gnosamba, gtk-theme-switch, gwm, gwml, libvdkbuilder-dev,
libvdkbuilder2-dev, lightspeed, mountapp, multimon, oneliner, perspic,
quickplot, sclient, spacechart, vdkbuilder, vdkbuilder2, wmmatrix,
wmmoonclock, xaw3dg-dev, xcin2.3, xdigger, xdkcal, xgraph, xsol,
xtoolwait, xtranslate, xtv.
These lists don't include packages from contrib or non-free.
The proposed text for a source package bug:
(This is an automatically generated bug, based on the current contents
of the Sources file for the main section.)
This source package contains a build dependency on xlib6g-dev. This
needs to be updated since the xlib6g* packages will disappear by the
time of the next release.
Be aware that, in addition to xlibs-dev, you may also need to specify
libxaw7-dev. Also, if your source package uses imake, you will need
to specify xutils as well.
The proposed text for a binary package bug:
(This is an automatically generated bug, based on the current contents
of the Packages file for the main section.)
This package still depends on xlib6g; this needs to be updated since
the xlib6g* packages will disappear by the time of the next release.
(If this was pulled in by ${shlibs:Depends}, all you should need to do
to fix this bug is rebuild the package. However, if your source
package is missing Build-Depends, you may need to add these for the
autobuilders to work.)
--
Daniel Schepler "Please don't disillusion me. I
[EMAIL PROTECTED]haven't had breakfast yet."
-- Orson Scott Card
Re: Another mass bug filing: get rid of xlib6g*
Josip Rodin <[EMAIL PROTECTED]> writes: > On Thu, Nov 21, 2002 at 02:03:06PM -0800, Daniel Schepler wrote: > > Binary packages (excluding those in source packages listed above): > > wmmoonclock, xaw3dg-dev, xcin2.3, xdigger, xdkcal, xgraph, xsol, > > I'm not sure how you gather that data, but xsol binary package is built from > the xsol source package... Umm, xsol wasn't "listed above"... "xsok" in the source package list was not a misspelling. BTW, let me register my preference that people don't Cc me on replies to the list. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Should pure virtual dependencies be allowed?
I'm forwarding this message to the list with the permission of the author, since it relates to the recent thread about mass filing of bugs regarding libxaw-dev. --- Begin Message --- On Wed, Nov 20, 2002 at 10:27:25PM -0800, Daniel Schepler wrote: > Package: acfax > Severity: normal > > This package Build-Depends on libxaw-dev, which is wrong because it's > a pure virtual package. You need to specify a specific version of > libxaw-dev to be used. Why do I need to specify a specific version? Which part of policy says so? The same applies to normal depends. Some people believe that any dependency on a virtual package must be expressed as "a real package | the virtual package". However this is a workaround for a limitation of apt-get (that it can't choose a default for a virtual package). The correct solution is to fix the package management tools, not to kludge around the problem. Debian does not have a history of kludging around the problems so let's not start now. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> --- End Message --- -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Re: SASL/LDAP/DB dependency hell. (was: Accepted cyrus-sasl 1.5.27-3.4 (i386 source))
Andreas Metzler <[EMAIL PROTECTED]> writes: > On Tue, Apr 08, 2003 at 07:07:33PM -0400, Richard A Nelson wrote: > > Why was this rebuilt with libdb2-dev ? Shouldn't we be trying to > > get things to db4.1 at this point ? I'd think db3 at a minimum. > > > This isn't just idle curiosity either, SASL impacts MANY packages - > > most MTAs and anything using OpenLDAP. > > > If we don't agree on a minimum, or at least a preferred lib... we're > > going to have packages linked against 3 different levels - not fun > > Hello, > Actually it is much simpler, many packages are simply not compileable > anymore: > > libldap2-dev depends on libsasl-dev [1] > libsasl-dev depends on libdb2-dev (>= 2.7.7.0-7) [2] > libdb3-dev conflicts with libdb2-dev > > [1] introduced in response to #164791 > [2] introduced in response to #168993 > > libtool strikes again, quoting from the report > | /usr/lib/libsasl.la contains -lpam as a dependency, so -lsasl can't be > | linked using libtool without libpam0g-dev being installed. > > This hits almost anything linking against libldap2, including postfix > (db3), apache2 (db4.1), xemacs21(db3), sendmail (db3), KDE (db4.0), I'm going to prepare a new NMU in which libsasl-dev has that dependency changed to "libdb2-dev | libdb-dev", which should satisfy the libtool issue while still allowing libdb4.0-dev, etc. Hopefully because of the versioned symbols in libdb2 this won't result in breakage. I'll hold off uploading it until about 11 AM Pacific daylight time Thursday morning, though, so somebody can tell me if I'm wrong. Actually, though, it seems libdb4.0 and libdb4.1 don't have versioned symbols -- so if a program links against -lsasl and -ldb4.0 there's still a possibility of problems afaict. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Re: SASL/LDAP/DB dependency hell.
Andreas Metzler <[EMAIL PROTECTED]> writes: > > Actually, though, it seems libdb4.0 and libdb4.1 don't have versioned > > symbols -- so if a program links against -lsasl and -ldb4.0 there's > > still a possibility of problems afaict. > > Iirc versioned-symbols in db2 and db3 were introduced by the > respective debian maintainers, and db4 shipped them with upstream but > my memory might be wrong. This was based on running objdump -p on the libdb libraries. For db2 and db3 the output included entries like Version definitions: 1 0x01 0x05477ab2 libdb2.so.2 2 0x00 0x4852 DB2 For db4.0 and db4.1 there was no such output. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Re: Are build-dependancies mandatory?
Marcin Owsiany <[EMAIL PROTECTED]> writes: > On Fri, Apr 27, 2001 at 06:00:07AM -0500, BugScan reporter wrote: > > > > Package: cvs (debian/main) > > Maintainer: Eric Gillespie, Jr. <[EMAIL PROTECTED]> > > 95263 missing build dependency > > The policy says: > > A source package may declare a dependency or a conflict > on a binary package. > > Then why is missing build dependency considered an RC bug? > I know build-depends is a good thing, but shouldn't the policy > be changed then? Hmm, it also says (in section 2.4.2): (emphasis mine) Source packages _should_ specify which binary packages they require to be installed or not to be installed in order to build correctly. ... _If_ build-time dependencies are specified, it _must_ be possible to build the package and produce working binaries on a system with only essential and build-essential packages installed and also those required to satisfy the build-time relationships (including any implied relationships). So officially, completely missing build-depends is a normal bug; incomplete build-depends is RC. Is this an inconsistency with the above quote from section 7.6, which uses the word "may"? -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Bug#752189: ITP: mariadb-client-lgpl -- LGPL version of MariaDB client libraries
Package: wnpp Severity: wishlist Owner: Daniel Schepler * Package name: mariadb-client-lgpl Version : 2.0.0 Upstream Author : MariaDB Foundation * URL : https://mariadb.org/ * License : LGPL 2.1 Programming Lang: C Description : LGPL version of MariaDB client libraries I would like to package the version of MariaDB client libraries from mariadb_client-2.0.0-src.tar.gz, for the situations where an LGPL client library is required. Off the top of my head, there would be at least libmariadb2, libmariadb-client-lgpl-dev, and possibly libmariadb-client-lgpl-compat-dev with the compatibility symlinks for libmysqlclient.so, libmysql.so, etc. Of course, if somebody else in the MySQL Maintainers group is already working on this and just hasn't filed the ITP yet, I'd be happy to defer to them. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140620201943.30187.46068.report...@deb-dschepler.snt.loc
Re: x32 “half” arrived… now what?
(Sorry about the lack of threading... for some reason I'm unable to find the
links to download mbox archives for replying to the messages.)
In response to Adam's comments about debootstrap not working because findutils
FTBFS: Yes, I'm aware of that, and for now you have to include "unreleased" as
well using multistrap with the instructions at http://wiki.debian.org/X32Port
. (And apologies for the inconvenience... That will also get you a newer
version of binutils:x32 which makes elf32_x86_64 the default target -- which
is really only important if your source package is using "ld -r" or otherwise
running ld manually.)
For the reason we still have multilib packages instead of relying on
multiarch, see the thread starting at
http://lists.debian.org/debian-devel/2013/05/msg00692.html . (The one good
argument there IMO is that dropping libc6-i386 in favor of libc6:i386 could
cause difficulties autobuilding gcc-multilib when e.g. libgcc1:i386 and
libgcc1:amd64 get out of sync because of buildd delays. I still don't see any
good reason to keep the other multilib packages like lib32gmp10.)
In answer to Russ's concerns about sizeof(time_t) > sizeof(long): that hasn't
really been a major concern in my experience (the biggest impact is that it
causes gobject-introspection to FTBFS -- #699024). The bigger porting
concerns are code using x86_64 asm, and the fact that x32 doesn't support the
sysctl(2) interface. On the latter point, I get the feeling that might be a
result of another of Linus' decrees ("new architectures shall not support this
interface which was obsolete from the moment it was introduced"), though
that's just a pure guess. Oh, and then there's the multitude of build
failures because of the package's copy of libtool being out of date.
--
Daniel Schepler
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2694027.5QWCrBo70u@frobozz
Re: x32 “half”arrived… now what?
Matthias Klose wrote: >Multi-Arch isn't there yet. And even if it is, the multilib builds should be >kept for some more releases. There is a lot to do on the Debian side, and on >the upstream side. So maybe it helps your understanding to get the required >patches upstream to get multilib working with a multiarch setup. OK, maybe this weekend I'll work on creating patches to the gcc packaging to allow gcc-multilib to use multiarch libraries. My basic idea right now would be something like: * Both lib32gcc1:amd64 and libgcc1:i386 provide an alternative for /usr/lib/gcc/i386-linux-gnu/libgcc_s.so pointing to its version of libgcc_s.so.*, with libgcc1:i386 having the higher priority. * The gcc-4.8 packaging (for lib32gcc-4.8-dev:amd64) makes /usr/lib/gcc/x86_64-linux-gnu/4.8/32/libgcc_s.so a symlink to /usr/lib/gcc/i386-linux-gnu/libgcc_s.so. * Then the rest is just adjusting dependencies on lib32gcc1 to alternatives libgcc1:i386 | lib32gcc1, etc. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2985791.MzHV9NCblm@frobozz
Re: x32 “half”arrived… now what?
Adam Borowski wrote: > Wouldn't it be easier to have lib32gcc1:amd64 merely depend on libgcc1:i386? > It'd save a massive amount of complexity. But that reintroduces the problem which convinced me there's a reason to keep lib32gcc1 in the first place: suppose libgcc1:i386 and libgcc1:amd64 get out of sync. That makes it impossible to autobuild gcc on the out-of-date architecture to correct the situation. (That's probably more of an issue on other slower architectures like mips/mipsel.) -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2939148.PGM52SdYmI@frobozz
Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))
Johannes Schauer wrote:
> Indeed, none of the Type 1 Self-Cycles are needed to bootstrap the core of
> Debian. Unfortunately though, most of the Type 2 Self-Cycles are. You will
find
> many surprising (at least to me) examples in the section of "Type 2
> Self-Cycles" under the above link.
On the other hand, if you count Build-Depends-Indep and Architecture: all
packages as part of what you want to bootstrap, then gnat-4.6 does get pulled
in...
gzip Build-Depends-Indep: mingw-w64
mingw-w64 Build-Depends: gcc-mingw-w64-{i686,x86_64}
gcc-mingw-w64 Build-Depends: gnat-4.6
(And also, you have the issue that gcc-4.8 Build-Depends on libantlr-java and
libecj-java, whose builds require either gcj-4.8 from the same source package,
or openjdk-7-jdk which also Build-Depends on ecj.)
I realize that these sorts of issues aren't as important for the practical
problem of bootstrapping a new port; but ideally, from a philosophical point
of view we should be able to bootstrap all our packages. (To be honest, the
Java packages are such a tangled mess that I've given up on trying to
bootstrap that part of the archive for now -- and many of those do get pulled
into the minimal set of ca. 1473 source packages I get with my criteria.)
--
Daniel Schepler
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2085384.4n0ClPvkx6@frobozz
Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))
On Monday, October 28, 2013 12:15:09 PM Emmanuel Bourg wrote: > Le 27/10/2013 16:30, Daniel Schepler a écrit : > > (To be honest, the > > Java packages are such a tangled mess that I've given up on trying to > > bootstrap that part of the archive for now -- and many of those do get > > pulled into the minimal set of ca. 1473 source packages I get with my > > criteria.) > Hi Daniel, could you elaborate on the tangled mess of the Java packages? > As someone who cares about the Java packages in general I'd be > interested in hearing what could be improved. (Let's take any more detailed discussions on this off debian-devel and leave it just on debian-java.) The first task would be to bootstrap gcj and then openjdk (and the latter's binary dependencies on libatk-wrapper-java-jni, ca-certificates-java, tzdata- java). Then I have to bootstrap ant, which is made difficult by the fact that there are so many Build-Depends needed before it's possible to build a full version of ant-optional. In the past I've done that by first building just ant from that package, and then whenever one of the indirect Build-Depends of ant- optional has a Build-Depends on ant-optional itself, I build a throwaway version of ant-optional against whatever I have available at that point. But now, with libgnumail-java having a Build-Depends on bnd which Build-Depends on some packages from eclipse, I don't really have any idea how to handle that, other than to drop the call to bnd and cross my fingers hoping nothing needs whatever the bnd call adds to that package. Mixed in with that, I also have to bootstrap maven-repo-helper, and for a few packages that I need before I'm able to do that, I do the ugly thing of just taking the metadata files from existing packages and installing them by hand into bootstrapped packages. Then, the next major hurdle is that many packages that are part of the Maven build system or its binary dependencies have Build- Depends on maven-debian-helper themselves. A while ago I figured out a way to bootstrap this using maven-ant-helper, but that's a long drawn-out process involving probably hundreds of packages. And I'm not sure that my process will still work, as there are even more packages that have switched to using maven-debian-helper to build in the meantime, including libjaxen-java which has always been a headache because of its circular Build-Depends with dom4j, libjdom1-java, xom. (Also, maven-ant-helper itself isn't necessarily that easy to bootstrap, as it Build-Depends on ant-contrib, which Build-Depends on ivy, which Build-Depends on libcommons-vfs-java, which needs maven-debian- helper.) And yes, maven-debian-helper is part of that set of ca. 1473 source packages, for example via the chain x11proto-core -> fop -> xmlgraphics- commons -> mockito -> objenesis -> maven-debian-helper. Anyway, that's just an overview of the main issues I face with a bootstrap of the Java packages. If you want, I could restart my bootstrap process and let you know in more detail what Build-Depends cycles I run into (and solutions where I've been able to find them in past iterations). Obviously, though, very little of this will be relevant for the case of bootstrapping a new port, using the existing Architecture: all packages. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2411641.bXzH0chkUq@frobozz
Where could I upload x32 port bootstrap?
I've asked a couple people in private mail about this, and haven't gotten any answer, so I thought I'd ask here for ideas. Where would be a good place to upload what I have so far from bootstrapping an x32 port of Debian? So far I have over 13000 source packages built, so the total size is likely to be in the dozens of GB... which means probably putting it on people.debian.org would be too much. Might alioth.debian.org have enough storage space for this? -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadf0c443jajm-usbup0_czvyzmscrjfq_uehuhacbsholwn...@mail.gmail.com
Re: Where could I upload x32 port bootstrap?
(Sorry for broken threading, I'm not currently subscribed to debian-devel.) At some time in the past, Henrique de Moraes Holschuh wrote: > Can someone give us numbers? Using VMs or even the bare metal, it should be > possible to gather some statistics about memory usage for x32 versus amd64 > for: > > 1) Desktop running gnome or kde (or both, whatever) with iceweasel open on > the www.debian.org page. Well, currently, neither gnome nor kde is fully installable, and iceweasel doesn't build at all. > 2) Maximum memory usage for a kernel, x.org or libreoffice build run. libreoffice also doesn't build, waiting for dependencies. (I was surprised x.org builds successfully for x32, but I haven't actually tested the resulting server.) > 3) Memory usage of some common server workload. E.g. email with > amavisd-new+spamassassin (perl is a memory pig in amd64), or a LAMP stack > with some common web application. mysql builds successfully, but looking at the log from the testsuite, it looks like at least the server is probably totally broken. Also, php5 fails to build because of the previously mentioned assumption that __x86_64__ means x86_64 asm assuming 64-bit pointers will work. > This should give us a pretty clear idea, and could go a long way to prove > the case for x32 as a full arch as far as memory goes. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADf0C46D2JzbAUhUAtnr3gXYkWrBuS5WE5z1vsu=xnaz6s0...@mail.gmail.com
Re: Where could I upload x32 port bootstrap?
On Sun, Nov 11, 2012 at 10:59 AM, Wouter Verhelst wrote: > On Fri, Nov 09, 2012 at 02:06:15PM -0800, Daniel Schepler wrote: >> I've asked a couple people in private mail about this, and haven't >> gotten any answer, so I thought I'd ask here for ideas. Where would >> be a good place to upload what I have so far from bootstrapping an x32 >> port of Debian? > > Have you talked to the debian-ports.org people? They have a (secondary) > mirror and buildd network that all our no longer active ports have moved > to, as well. Yes, I've emailed ad...@debian-ports.org as Guillem Jover suggested. I'll wait until the end of the day tomorrow to see if I get a response, and if not, I might take up Thomas Goirand on his offer of temporary hosting. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADf0C46hL2753aK_E2Dx_qWr8H=r7-gbxte5cjf6wstcaqt...@mail.gmail.com
Re: History of Debian bootstrapping/porting efforts
I read your recent post to debian-devel with great interest, as I've done some bootstrapping efforts in the past, and I'm currently in the middle of a "port" for the x32 ABI. In the past, what I've done (mostly privately) was to develop a script I called "pbuildd" which essentially just runs through the list of currently unbuilt packages and tries running pbuilder on them all, then installs anything that succeeds into a local repository and starts up the loop again. Then, when things got stuck, I just did a manual inspection of the unsatisfied dependencies to find the cycles, and chose one to break. In fact, I've just started uploading my current iteration of this to http://87.98.215.228/debian/ -- you might want to especially look at scripts/pbuildd which is the central script to run this loop. (And over time, it's gathered various optimizations to speed up the "installation into local repository" step, try to avoid invoking pbuilder if it can easily determine that certain Build-Depends aren't present at all, etc.) Initially, when I needed to break a cycle, I would just build something by hand and stick it into the "partial" directory, but over time I started developing automated cycle-breaker scripts, which are currently under scripts/cb.inactive (the pbuildd script looks for them under scripts/cb). The scripts tend to become outdated over time, though, with a moving target, and I'm sure the current state is no exception. My personal heuristics for what I preferred were: first, prefer cycle-breaking which just removes Build-Depends which are there to build documentation. Then, prefer cycle-breaking which ignores Build-Depends on one or a few libraries which provide purely optional features. If I couldn't find anything of this sort, I'd just try to find the cycle-breaking point which would be (fuzzily) "least invasive" and "least likely to break the resulting packages, at least as far as packages that Build-Depend on them". In the past, pbuildd was mainly geared towards trying to build all of Debian (including the binary-indep packages) starting from a minimal chroot and with minimal extra package downloads, but on an established architecture. It was only recently that I started applying it to bootstrapping x32. The way I started that was actually: I started off mainly following the instructions from Linux From Scratch, though of course adjusting it to "cross-building" to x32 as necessary. I also inserted dpkg into the process as soon as possible after the first LFS stage creating the chroot with /tools, and from then on ran installs into temporary directories, and built dummy dpkg packages with no dependencies. Then, after the LFS builds were over, I started building real Debian packages from the actual .dsc source packages, and eventually had enough packages built in this way that I was able to do a debootstrap, and start the pbuildd process. (So yes, x32 might be a special case in that it runs on already widely available hardware, and I could develop from an existing Debian installation. But I'd imagine that was probably the case as well, though possibly to a smaller degree, for the amd64 and ia64 ports, and possibly other recent ports to new ABIs on existing hardware (armhf?).) As for specifics on the x32 port -- currently the most common issues I see (roughly from most common to least common) are: * Outdated libtool, which causes it to want to ld -r with the wrong -m target type. (And also ld -r more often than usual, because "getconf ARG_MAX" outputs "undefined" on x32 in certain circumstances, which the outdated libtool can't handle properly.) Of course this isn't an issue for packages that autoreconf at build time. * Issues which will hit every architecture once we switch to eglibc 2.16. Out of this, by far the most common is gnulib (other than very recent git versions) wanting to attach a warning to the "gets" prototype, which is no longer exported by default in eglibc 2.16. * Code still using sysctl(2), which is no longer supported in x32. * Code which unconditionally uses 64-bit asm snippets if __x86_64__ or __amd64__ is defined -- which causes assembler failures if one of the inputs or outputs is a long or a pointer type, and the asm snippet uses explicit "q" sizing suffixes (or there are other mismatches). -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADf0C45igv-SnQcEz8v_A0vH=VKRJ+eFc7cwt2j5U=8rcyf...@mail.gmail.com
x32 port bootstrap is uploaded
I've finally finished the initial upload of my current x32 bootstrap archive, which is now available at http://87.98.215.228/debian/ . Assuming you're running an amd64 kernel with x32 support (3.4.0 or later with CONFIG_X86_X32=y, can download my build of 3.6.4 from http://87.98.215.228/debian/byhand/l/linux/ ), you should be able to debootstrap using something like wget http://87.98.215.228/debian/dists/archive.pub debootstrap --arch=x32 --components=main,byhand,partial \ --keyring=`pwd`/archive.pub \ sid /root/x32-chroot/ http://87.98.215.228/debian/ Later I'll try to document this a bit more on the wiki, create a stub root index.html redirecting to the wiki, and possibly create an x32.debian.net alias. Many thanks to Thomas Goirand and gplhost.com for hosting this archive. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADf0C45pX_Zk3J5uUw_vZBkVOfL=Bk0AsArV1Ojg=zuz76o...@mail.gmail.com
Re: x32 port bootstrap is uploaded
On Mon, Nov 19, 2012 at 11:47 AM, Daniel Schepler wrote: > Later I'll try to document this a bit more on the wiki, [snip] OK, I've now created http://wiki.debian.org/X32Port . -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADf0C46P44e4Tr1R2NkDgLPHuQ3jRQ5K5pW+6h0RD9==zrh...@mail.gmail.com
Re: jessie release goals
Maybe we could have a release goal of dropping as many lib32* and lib64* packages as possible in favor of multi-arch. (And also as many package dependencies on libc6-[i386|amd64] as possible, which would in addition mean limiting some packages to arch:i386 if they currently provide a fake arch:amd64 package with an i386 binary.) Of course, to completely get rid of everything including libc6-* and lib32gcc1, etc., we'd need special configuration on the buildds to continue building gcc with multilib support; and the GCC maintainer has expressed resistance to being that radical even if we could get this buildd support. -- Daniel Schepler
Re: jessie release goals
On Sun, May 12, 2013 at 8:06 AM, Matthias Klose wrote: > Am 12.05.2013 16:18, schrieb Daniel Schepler: > > Maybe we could have a release goal of dropping as many lib32* and lib64* > > packages as possible in favor of multi-arch. (And also as many package > > dependencies on libc6-[i386|amd64] as possible, which would in addition > > mean limiting some packages to arch:i386 if they currently provide a fake > > arch:amd64 package with an i386 binary.) > > > > Of course, to completely get rid of everything including libc6-* and > > lib32gcc1, etc., we'd need special configuration on the buildds to > continue > > building gcc with multilib support; and the GCC maintainer has expressed > > resistance to being that radical even if we could get this buildd > support. > > Well, GCC should keep building with a sane amount of effort. And that > currently > means not depending on a "foreign" architecture on the buildds. So before > this > can happen: > > - get dpkg ready to accept b-d's on foreign architectures. > > - get GCC ready to search for gcc_lib_dir for foreign multilibs. >and get this submitted upstream before getting it to the Debian >packages. > I didn't need to do anything special on this back when I did the proof of concept. All I had to do was adjust the /32/libgcc_s.so symlink created in the packaging to point to the multiarch location. > > - find a solution for multilibs which are not fully supported > architectures, >but only partial ports, or ports maintained outside the archive. > That case could continue to use multilib without creating the (admittedly minor) redundancy that multilib + multiarch creates. > > - get the buildd infrastructure ready. > > - find a solution that GCC's b-d's may not be installable anymore with >the current approach to binNMUs. > OK, that's a good point that I hadn't thought of before. So, it does make sense to keep libc6-i386 and lib32gcc1 if only for cross-architecture version skew issues. But I also think for most users it would make sense to allow for the option of satisfying gcc-multilib's dependencies using multiarch, and to make this the default option on multiarch systems. Though that would probably involve adding alternatives somewhere which might be more trouble than it's worth... > > It is wrong to drop the current multilib support before these are > implemented > and in place. > > So what do you commit to work on? > > I don't think that there are that many packages where you can or should > drop > multilib support. So it would be wrong to drop multilib support for zlib > (GCC, > gdb), ncurses, readline, expat (gdb) now. And there are not that many more > packages providing multilib support. > Umm, maybe this is a stupid question, but why would we need to support uploading packaged cross-compiled versions of gdb? As for the others you listed, I've gotten by just fine on x32 without any lib[32|64]z1 etc. packages. (Also, on a side note: do you have any idea why expat provides lib64expat1 but no lib32expat1?) -- Daniel Schepler
Is running dpkg-buildpackage manually from the command line forbidden?
I've been running a manual test bootstrap of Debian (starting with cross-compiled packages amd64 -> i386 up to the point I was able to install debhelper), and posting a few bugs I've found along the way. These are where I found that having extra packages installed during the dpkg-buildpackage run either failed or resulted in broken packages. (Some examples of the type of thing I mean: #948522, #887902.) However, I've been getting push back on some of these, with maintainers of the opinion that it isn't actually a bug. So, I thought I'd consult here to get more opinions on whether these are true bugs, or whether I'm at fault for trying to run dpkg-buildpackage manually instead of using it through pbuilder or sbuild. My arguments in favor of such things being bugs: 1. I've been using Debian since before pbuilder or sbuild even existed, and I don't remember ever seeing any announcements along the lines of "using pbuilder or sbuild is now mandatory, running dpkg-buildpackage manually is forbidden". (Just announcements that of course, testing package builds using one of those before uploading is strongly encouraged.) 2. The mere existence of the Build-Conflicts field. 3. The general principle that the Build-Depends are meant not to describe every possible way the package *could* be built, but to pin down the exact environment in which the package *should* be built, in order to avoid unnecessary differences in the resulting packages between architectures. 4. The build-essential package set could evolve over time, and in a few cases that could come back to bite maintainers. For a hypothetical example: what if Debian eventually decided to add cmake, ninja, and meson to the build-essential set? Or, what if there were a source package that made a build time check of whether a libpopt.so.2 file exists to be dlopen()ed, but if it's found enabled broken code; and then, eventually, one of the build-essential packages added a dependency on libpopt? Possible arguments I can anticipate against such things being considered bugs: 1. It would be very difficult to impossible to test for every possible combination of packages that satisfy the Build-Depends. (Though I would think a vast majority of such bugs would be detected by a reproducible-builds type setup with one build being the standard minimal chroot, and the other build using a chroot with as many packages as possible installed.) 2. It would be pointless to worry about such things, especially now that all uploads to the archives must be source only. (To which my answer would be: requiring use of pbuilder or sbuild would place a burden on users who previously would have made local patches by a sequence of "apt-get source package; cd package-*/; edit; dpkg-buildpackage -b -uc; sudo apt-get install ../*.deb ) (Somewhat related to this: I've also found a few packages that hang when building from the command line, waiting for input from stdin; whereas in pbuilder or sbuild, with input redirected to /dev/null or similar, the builds succeed. Would these be considered bugs as well? Of course, in some situations it looks like it detects an incontrovertible bug, such as when an "rm" command hangs on the prompt for confirmation on a read-only file, and the /dev/null stdin case would just result in those files being left in place. I've especially been seeing the latter sort of thing related to Perl packages now that recent Perls install lots of files as read only.) -- Daniel Schepler
Re: Is running dpkg-buildpackage manually from the command line forbidden?
On Thu, Jan 16, 2020 at 11:18 AM Ondřej Surý wrote: > while your effort is valiant, I see a little value in it as there’s no real > world use case. While your arguments are valid, you are imposing additional > work on generally already overloaded maintainers with unclear goal and > purpose. > > Perhaps your energy and enthusiasm (which I appreciate) could be spent on > helping fixing reproducible builds in packages or cross-building. Those are > practical and you won’t find any resistance in accepting patches for these > two use cases. OK, makes sense. This was, in fact, an offshoot of the beginning stages of a project to create some way to automate bootstrapping an architecture starting with automated cross builds of the core packages. (Incidentally, another offshoot was creating local patches to sbuild which add an operation mode using systemd-nspawn --ephemeral to start a container (along with the base being a BTRFS subvolume to speed up the cloning), systemd-run -M debian-sid-amd64-xxx [--property=PrivateNetwork=yes] cmd..., etc. When I sent a message to sbu...@packages.debian.org there didn't seem to be any interest in having me clean up the patches and send them on. Still, do you think if I posted bug reports for issues I found due to the builds running under seccomp filters, as wishlist bugs and with either suggested patches or a request for advice on further debugging it myself where I got stuck, that maintainers might be willing to consider them? Also, by the way, the amd64 -> i386 cross built core packages largely worked OK, with the exception of gcc-9, which ended up with incorrect include-fixed/limits.h, and with a compiler that required -lssp when building with -fstack-protector-strong or -fstack-protector as almost all Debian packages do. To anybody on the list: is there something I did wrong with the cross build there, which was to run "dpkg-buildpackage -a i386 -B -Pcross"?) -- Daniel Schepler
Re: Is running dpkg-buildpackage manually from the command line forbidden?
On Fri, Jan 17, 2020 at 2:05 AM Johannes Schauer wrote:
> yes, probably a communication problem. I think you are talking about [1] from
> August 11 last year? I replied the same day, telling you to please file a bug
> with your patches to continue discussion there. But then there was no response
> from you anymore and I don't find your bug in the BTS. Maybe my mail got lost
> somehow or I fail finding the bug you filed?
It seems the reply must have gotten lost somehow - I don't see it anywhere.
> I'm also very excited about having yet another chroot backend being integrated
> into sbuild! Though my first comment would be the same as I gave those asking
> for a docker backend in #867176: maybe try adding that backend to autopkgtest
> first. Then more people would profit from having that type of backend
> available
> and no additional changes would be needed in sbuild because sbuild can already
> use autopkgtest backends for package building.
OK, I'll try to get the patch submitted either tonight or tomorrow.
(What I need to clean up is that it's interspersed with changes I made
to have it run with a personal distribution build I've been tinkering
with. On a quick review, I now notice it's also interspersed with
changes to support using eatmydata only on the apt install commands
and only if not in schroot-update mode, instead of having to put it
into schroot config to apply to all commands - which seems reasonable
to split out into a separate patch to submit. I also haven't yet
updated documentation files.)
One quick question: I don't see any mention of
$options->{'DISABLE_NETWORK'} in lib/Sbuild/ChrootAutopkgtest.pm,
whereas my new lib/Sbuild/ChrootNspawn.pm does support it. If I'm not
missing something, then I wonder what it would take to add
DISABLE_NETWORK support to the autopkgtest sbuild engine.
--
Daniel Schepler
