Bug#234772: Must be a bug in apt
reassign 234772 libice-dev thanks Thomas Hood <[EMAIL PROTECTED]> writes: > reassign 234772 apt > thanks a) DON'T ABUSE -QUIET. b) don't randomly reassign bugs if you don't know what you're talking about. This is NOT a bug in apt. It's (the indirect result) of a bug in the postrm of the X lib* packages in 4.3.0-2. -- James
Re: Changed library interface causing FTBFS of cernlib?
Branden Robinson <[EMAIL PROTECTED]> writes: > On Mon, Feb 23, 2004 at 06:24:31AM -0500, Kevin B. McCarty wrote: >> Hi, >> I've gotten a bunch of FTBFSes for cernlib 2003.09.03-4 which I assume are >> related to the new X release. The problem is that when linking a program >> with these flags, > > Yes, I'm getting a few strange reports like this. To be honest I don't > yet know if it's a package bug or some sort of weirdness inflicted on > the buildds due to kludge necessary to work around the fact that > xlibs-dev is now an architecture-independent pseudopackage. Err, the "kludge" was simply making xlibs-dev from 4.2.1 available to the buildds and hiding the arch:all 4.3.0 version. I can't conceive how that would cause any problems - never mind something like this. I haven't looked at the log, but I suspect this is probably just more fallout from the hanging postrm bug that's in -2[1]. -- James [1] As I explained on IRC: sbuild installs new X library packages, builds package, tries to remove them, postrm hangs due to missing argument to grep, sbuild times out and kills the dpkg process, dpkg gets confused and thinks the library package it was in the process of removing is still "installed but with no files"... next package that tries to use that library fails (often in bizarre ways) because the library's not actually there.
Re: Stupid build failures for XFree86 4.3.0-2
Michel Dänzer <[EMAIL PROTECTED]> writes:
>> James Troup, on IRC and a few of the porting lists, speculated that
>> this is a buildd problem, and gave instructions for working around
>> it.
Eh, I didn't mean to give the impression that it was a buildd problem
- I don't believe it is, not in the sense that the buildd software is
responsible anyway.
> Isn't the problem that xlibs{,-dev} are now Architecture: all, and
> their dependencies can't be satisfied on architectures where the
> split libraries haven't been built yet?
Yes; that and the fact that xfree86 has a circular build-depends on
itself.
I realise that the cicrcular build-depends is not trivial to fix and
that the xlibs split is a once off thing, so it's easier to work
around the problem which is what I meant when I said it wasn't your
fault/problem.
--
James
Re: X Strike Force XFree86 SVN commit: rev 930 - branches/4.3.0/sid/debian
Branden Robinson <[EMAIL PROTECTED]> writes: >> Fair enough, don't worry about it then. > > Well, I don't actually *like* to inconvenience buildd admins... I didn't mean to imply you did. > I see. Perhaps I am being optimistic, but maybe all the buildd > chroots have been updated to the requisite version by now: Yes, they probably will, especially since there's been other problems with gcc recently (C++ breakage) that have required chroots to be up-to-date. I mostly mentioned it as part of my knee-jerk reaction to << B-Conflicts and for (future) informaitonal purposes. -- James
Re: X Strike Force XFree86 SVN commit: rev 930 - branches/4.3.0/sid/debian
Branden Robinson <[EMAIL PROTECTED]> writes: > On Mon, Jan 19, 2004 at 10:51:26PM +0000, James Troup wrote: >> Branden Robinson <[EMAIL PROTECTED]> writes: >> >> >> > +Build-Conflicts: cpp-3.3 (<< 1:3.3.3ds1-0pre1) >> >> FWIW, Build-Depends on a >> version are much more buildd (admin) >> friendly than a Build-Conflicts. The B-C isn't wrong, of course, and >> the unfriendliness of a B-C for buildd (admins) is arguably an sbuild >> bug, so you may not care enough to change it (or have other reasons to >> not want to, etc.) *shrug* > > Oh, gah. Well, the main reason I went with this is because I'd still > like people to be able to build XFree86 with older GCCs. Fair enough, don't worry about it then. > Can you explain a little bit more about how Build-Conflicts are > painful for buildd admins? If a >> B-D isn't satisfied, sbuild will automatically try and install the latest version. If it can't (because that version isn't available yet, for example), it's a one/two keystroke reply for the admin to have the package put in "Dep-Wait" state until the necessary version becomes available. Once it does, the build will automatically be retried. For a << B-C, sbuild will just fail the build if the required version isn't installed/available yet. The admin has to [wait for the required version to become available and then] manually update the chroot(s) and retry the build. -- James
Re: X Strike Force XFree86 SVN commit: rev 930 - branches/4.3.0/sid/debian
Branden Robinson <[EMAIL PROTECTED]> writes: >> > +Build-Conflicts: cpp-3.3 (<< 1:3.3.3ds1-0pre1) FWIW, Build-Depends on a >> version are much more buildd (admin) friendly than a Build-Conflicts. The B-C isn't wrong, of course, and the unfriendliness of a B-C for buildd (admins) is arguably an sbuild bug, so you may not care enough to change it (or have other reasons to not want to, etc.) *shrug* -- James
Bug#220864: xserver-xfree86: dumps lot of 'Not loading .note.GNU-stack' messages on console
Branden Robinson <[EMAIL PROTECTED]> writes: > tag 220864 + moreinfo > thanks > > On Sat, Nov 15, 2003 at 08:31:28AM +0100, Jurriaan wrote: >> Package: xserver-xfree86 >> Version: 4.2.1-14 >> Severity: normal >> Tags: sid >> >> After typing 'startx', the VT I start X from becomes clogged with at >> least 60 lines of >> >> Not loading .note.GNU-stack >> Not loading .note.GNU-stack >> >> It's not continuous, after X starts up, no more messages appear. >> This didn't happen with the previous version -13. >> >> I hope I have the right package. > > Apart from generating a lot of messages to the console, does there > appear to be any practical difference in the way 4.2.1-14 works? Oh, err, FWI, this could be (and mostly like is) due to the patch that went into the most recent gcc-3.3... * Apply patch to emit .note.GNU-stack section on linux arches which by default need executable stack. It's a support patch for exec-shield and it's possible we need the X exec-shield-related patches to quiet these warnings. -- James
Re: #define rate period patch broken for 2.4 kernels
Daniel Stone <[EMAIL PROTECTED]> writes: > AFAICT, the only kernel headers on there are 2.4.21-sparc, and it should Err, no. All architectures use the linux-kernel-headers package now and it's 2.6 based. Anyway, don't worry, I've tracked down the problem with the help of the glibc folks and it's a l-k-h bug, not X's. -- James
xfree86_4.2.1-14(unstable/sparc): FTBFS
Hi, I haven't had a chance to investigate this yet, so no bug, but I thought I'd at least warn you. This was the 3rd attempt on vore. The first had an out-of-date linux-kernel-headers installed in the chroot, so I freshened the chroot and retried. #2 got bitten by the sparc32 fuckage (see sparc-utils changelog for details). #3 (below) was in an up-to-date chroot (with working sparc32) | Automatic build of xfree86_4.2.1-14 on vore by sbuild/sparc 1.170.4 | Build started at 20031114-1051 | ** [...] | ** Using build dependencies supplied by package: | Build-Depends: dpkg (>= 1.7.0), cpp-3.2, flex-old, bison, bsdmainutils, groff, zlib1g-dev | libz-dev, libncurses5-dev | libncurses-dev, libpam0g-dev | libpam-dev, libfreetype6-dev, libpaperg, libstdc++5-dev | libstdc++-dev, tetex-bin, po-debconf, debhelper (>= 4.1.16), html2text, libglide2-dev (>> 2001.01.26) [i386], libglide3-dev (>> 2001.01.26) [alpha i386], kernel-headers-2.4 | hurd | freebsd | netbsd | openbsd [...] | lnx_io.c: In function `KIOCSRATE_ioctl_ok': | lnx_io.c:128: error: structure has no member named `period' | lnx_io.c:130: error: structure has no member named `period' | lnx_io.c:131: error: structure has no member named `period' | make[8]: *** [lnx_io.o] Error 1 A complete build log can be found at http://buildd.debian.org/build.php?arch=sparc&pkg=xfree86&ver=4.2.1-14 -- James
Re: X Strike Force XFree86 SVN commit: rev 753 - people/branden/xlibs-and-xbase-clients-split/debian
X Strike Force SVN Repository Admin <[EMAIL PROTECTED]> writes: > Split xlibs-dbg package into one package per shared library. What's the rationale behind this? I understand the rationale for -dev and lib packages but not -dbg. AFAICS soname bumps don't affect -dbg packages and any split to a separate source package can be handled by a simple replaces. I'm probably missing something obvious, so apologies in advance if I am. -- James
Re: xfree86_4.1.0-16woody1_ia64.changes REJECTED
Branden Robinson <[EMAIL PROTECTED]> writes: > On Mon, Sep 08, 2003 at 06:02:24PM -0400, Debian Installer wrote: >> Mapping stable-security to proposed-updates. >> Rejected: no source found for xfree86 4.1.0-16woody1 >> (xlibmesa3_4.1.0-16woody1_ia64.deb). > [etc.] > > I was told on IRC by mdz and elmo that I didn't need to upload an > .orig.tar.gz to the SecurityQueue. > > Or does this even have anything to do with that? > > Is there something I can do to resolve this? It was a misdireced upload; I think you can ignore it. -- James
Re: xfree86_4.1.0-16woody1_ia64.changes REJECTED
Branden Robinson <[EMAIL PROTECTED]> writes: > On Mon, Sep 08, 2003 at 06:02:24PM -0400, Debian Installer wrote: >> Mapping stable-security to proposed-updates. >> Rejected: no source found for xfree86 4.1.0-16woody1 >> (xlibmesa3_4.1.0-16woody1_ia64.deb). > [etc.] > > I was told on IRC by mdz and elmo that I didn't need to upload an > .orig.tar.gz to the SecurityQueue. > > Or does this even have anything to do with that? > > Is there something I can do to resolve this? It was a misdireced upload; I think you can ignore it. -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force SVN commit: rev 392 - trunk/debian
X Strike Force SVN Admin <[EMAIL PROTECTED]> writes: > - debian/control: add build-conflict with gcc-3.3 (<< 3.3.2-0pre1) [...] > +Build-Conflicts: gcc-3.3 (<< 3.3.2-0pre1) Unfortunately this is missing the epoch, rendering the Build-Conflict ineffective... | auric$ madison gcc-3.3 | [...] |gcc-3.3 | 1:3.3.2-0pre1 | unstable | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc I caught i386, but it might be an idea if someone checked the logs for other architectures (any modern sbuild prints out toolchain versions before the start of the build). -- James
Re: X Strike Force SVN commit: rev 392 - trunk/debian
X Strike Force SVN Admin <[EMAIL PROTECTED]> writes: > - debian/control: add build-conflict with gcc-3.3 (<< 3.3.2-0pre1) [...] > +Build-Conflicts: gcc-3.3 (<< 3.3.2-0pre1) Unfortunately this is missing the epoch, rendering the Build-Conflict ineffective... | auric$ madison gcc-3.3 | [...] |gcc-3.3 | 1:3.3.2-0pre1 | unstable | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc I caught i386, but it might be an idea if someone checked the logs for other architectures (any modern sbuild prints out toolchain versions before the start of the build). -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86 compilation / gcc-3.3 strict aliasing
Matthias Klose <[EMAIL PROTECTED]> writes: > Looking at the build logs you'll see many warnings: > > dereferencing type-punned pointer will break strict-aliasing rules > > Is it safe to ignore these warnings? Please could you try to compile > using -O2 -fno-strict-aliasing to see if this is related to the recent > miscompilation using gcc-3.3? I did, it's not. -- James
Re: xfree86 compilation / gcc-3.3 strict aliasing
Matthias Klose <[EMAIL PROTECTED]> writes: > Looking at the build logs you'll see many warnings: > > dereferencing type-punned pointer will break strict-aliasing rules > > Is it safe to ignore these warnings? Please could you try to compile > using -O2 -fno-strict-aliasing to see if this is related to the recent > miscompilation using gcc-3.3? I did, it's not. -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force SVN commit: rev 172 - in branches/4.3.0/sid/debian: . patches
X Strike Force SVN Admin <[EMAIL PROTECTED]> writes: > + /* m68k has no 2.4 kernel yet */ > + # ifndef Mc68020Architecture > + #define HasLinuxInput YES > @@ -701,7 +714,7 @@ This seems out-of-date? -- James
Re: X Strike Force SVN commit: rev 172 - inbranches/4.3.0/sid/debian: . patches
X Strike Force SVN Admin <[EMAIL PROTECTED]> writes: > + /* m68k has no 2.4 kernel yet */ > + # ifndef Mc68020Architecture > + #define HasLinuxInput YES > @@ -701,7 +714,7 @@ This seems out-of-date? -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force SVN commit: rev 139 - trunk/debian
X Strike Force SVN Admin <[EMAIL PROTECTED]> writes: > Author: branden > Date: 2003-06-04 10:08:27 -0500 (Wed, 04 Jun 2003) > New Revision: 139 > > Modified: >trunk/debian/changelog >trunk/debian/rules > Log: > step compile optimization level down to -O from Policy-required -O2 for arm > architecture as well as powerpc, due to GCC 3.3 issues (see Debian bug > #195424) If you're going to work around the ICEs, maybe it'd be better to up(/down)grade the compiler that's used to gcc-3.2 rather than reducing the optimization? I'm not particularly bothered mind, it's just a thought... -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X Strike Force SVN commit: rev 139 - trunk/debian
X Strike Force SVN Admin <[EMAIL PROTECTED]> writes: > Author: branden > Date: 2003-06-04 10:08:27 -0500 (Wed, 04 Jun 2003) > New Revision: 139 > > Modified: >trunk/debian/changelog >trunk/debian/rules > Log: > step compile optimization level down to -O from Policy-required -O2 for arm > architecture as well as powerpc, due to GCC 3.3 issues (see Debian bug > #195424) If you're going to work around the ICEs, maybe it'd be better to up(/down)grade the compiler that's used to gcc-3.2 rather than reducing the optimization? I'm not particularly bothered mind, it's just a thought... -- James
Bug#191737: acknowledged by developer (Re: Bug#191737: xinerama.h is missing extern C { for C++ compiling)
Daniel Stone <[EMAIL PROTECTED]> writes: > Yes, but it's not Xinerama's problem, and I don't see why it should > be bending over backwards to support people using it from another > language. Err, because that's the way things are done? Have a look at the include files from any major library you have installed and chances are it'll use the 'extern "C"' vodoo. Even XPM does ... -- James
Re: xlibmesa naming and relationships
Daniel Stone <[EMAIL PROTECTED]> writes:
> On Sun, Feb 09, 2003 at 01:43:33AM +0100, Michel D?nzer scrawled:
>> A broken package name to compensate for broken assumptions? Right. Give
>> it the Mesa version then, or document it in the description, or
>> wherever.
>
> You obviously don't understand how Debian's packaging system works.
> Please come back when you understand the fact that all binary packages
> carry the version assigned to the source package, and that this is
> invariable.
Err, no, that's complete BS. Trivial counter-example: gcc-3.2.
(Search a Packages file for "Source:.*\(" for more examples)
--
James
Re: xlibmesa naming and relationships
Daniel Stone <[EMAIL PROTECTED]> writes:
> On Sun, Feb 09, 2003 at 01:43:33AM +0100, Michel D?nzer scrawled:
>> A broken package name to compensate for broken assumptions? Right. Give
>> it the Mesa version then, or document it in the description, or
>> wherever.
>
> You obviously don't understand how Debian's packaging system works.
> Please come back when you understand the fact that all binary packages
> carry the version assigned to the source package, and that this is
> invariable.
Err, no, that's complete BS. Trivial counter-example: gcc-3.2.
(Search a Packages file for "Source:.*\(" for more examples)
--
James
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please sign/upload successful autobuild of XFree86 4.2.1-3
Branden Robinson <[EMAIL PROTECTED]> writes: > According to buildd.debian.org, the arm autobuilder successfully > built xfree86 4.2.1-3 on October 20th. The machine it's on (and the two other .ca arm buildds) are down and awaiting TLC from local admin. -- James
Re: please sign/upload successful autobuild of XFree86 4.2.1-3
Branden Robinson <[EMAIL PROTECTED]> writes: > According to buildd.debian.org, the arm autobuilder successfully > built xfree86 4.2.1-3 on October 20th. The machine it's on (and the two other .ca arm buildds) are down and awaiting TLC from local admin. -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-build and xfree86
Branden Robinson <[EMAIL PROTECTED]> writes: > > > xfree86 4.2.1-4 will B-D on "kernel-headers-2.4.19-386 | > > > kernel-headers-2.4 | hurd | freebsd | netbsd | openbsd". This will of > > > course only help Linux/i386 people, but it's better than nothing. > > > > FYI that'll break auto-building; sbuild takes the first choice. > > G. Is that a bug in sbuild and/or should we clearly document this > in the Debian Policy Manual? Sorry, I should have said; it's a bug in sbuild. -- James
Re: apt-build and xfree86
Branden Robinson <[EMAIL PROTECTED]> writes: > > > xfree86 4.2.1-4 will B-D on "kernel-headers-2.4.19-386 | > > > kernel-headers-2.4 | hurd | freebsd | netbsd | openbsd". This will of > > > course only help Linux/i386 people, but it's better than nothing. > > > > FYI that'll break auto-building; sbuild takes the first choice. > > G. Is that a bug in sbuild and/or should we clearly document this > in the Debian Policy Manual? Sorry, I should have said; it's a bug in sbuild. -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-build and xfree86
Branden Robinson <[EMAIL PROTECTED]> writes: > xfree86 4.2.1-4 will B-D on "kernel-headers-2.4.19-386 | > kernel-headers-2.4 | hurd | freebsd | netbsd | openbsd". This will of > course only help Linux/i386 people, but it's better than nothing. FYI that'll break auto-building; sbuild takes the first choice. -- James
Re: apt-build and xfree86
Branden Robinson <[EMAIL PROTECTED]> writes: > xfree86 4.2.1-4 will B-D on "kernel-headers-2.4.19-386 | > kernel-headers-2.4 | hurd | freebsd | netbsd | openbsd". This will of > course only help Linux/i386 people, but it's better than nothing. FYI that'll break auto-building; sbuild takes the first choice. -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG and fonts [was: Bug#91856: Hello]
Branden Robinson <[EMAIL PROTECTED]> writes: > On Tue, Apr 03, 2001 at 12:18:46PM -0500, David Starner wrote: > > While the issues on unmodifiable non-software stuff in Debian are > > not as clear-cut as Branden has made them out to be (I know of at > > least a half dozen packages in main that are unmodifiable, that were > > put there knowing that) > > What are they? They need serious bugs filed against them. e.g. doc-rfc ? -- James
Re: DFSG and fonts [was: Bug#91856: Hello]
Branden Robinson <[EMAIL PROTECTED]> writes: > On Tue, Apr 03, 2001 at 12:18:46PM -0500, David Starner wrote: > > While the issues on unmodifiable non-software stuff in Debian are > > not as clear-cut as Branden has made them out to be (I know of at > > least a half dozen packages in main that are unmodifiable, that were > > put there knowing that) > > What are they? They need serious bugs filed against them. e.g. doc-rfc ? -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
