[00:03] <mathiaz> slangasek: I don't think it's a no-op
[00:03] <mathiaz> slangasek: http://git.debian.org/?p=pkg-k5-afs/debian-krb5.git
[00:03] <mathiaz> slangasek: the last two commits show some version changes in debian/libgssapi-krb5-2.symbols, etc...
[00:05] <slangasek> mathiaz: changes, yes; but if as stated there's nothing yet using the new symbols, then there's no need to relax the versioned dep...
[00:10] <TheMuso> dtchen: hrm ok.
[00:12] <mathiaz> slangasek: ok - I'm gonna ask the debian maintainer what's the purpose of the last change
[00:13] <mathiaz> slangasek: may be we should go with 1.7dfsg~beta1-2 instead of 1.7dfsg~beta1-3
[00:15] <andersk> My understanding is that it allows packages built against krb5 1.7dfsg~beta1-3 in unstable to migrate to testing before krb5 migrates to testing itself.
[00:17] <andersk> Since this doesn't apply to Ubuntu and the change will be reverted in Debian by the end of the month, it may indeed be better to sync -2 rather than -3 (and prevent -3 from being synced automatically).
[00:21] <slangasek> as best I can tell, the symbol versions in -3 are /correct/ (all these symbols are also provided by the libkrb53 we currently have)
[00:22] <andersk> The Debian changelog mentions "new functionality", which I assume refers to new functionality in the existing symbols.
[00:22] <slangasek> which is out of scope for symbol versioning anyway...
[00:22] <andersk> So it is not in general the case that a package built against krb5 1.7 will work with libkrb53 1.6, even if the package uses only the existing symbols.
[00:23] <andersk> This just happens to be the case for all packages currently in Debian.
[00:28] <directhex> what's the current fashion for 0ubuntu1 upstream updates - a mahoosive debdiff, or a new diff.gz?
[00:33] <andersk> BTW, you're aware that uploading krb5 1.7dfsg before all its rdeps are rebuilt against 1.6.dfsg.4~beta1-7 or higher will break those rdeps, right?
[00:33] <Ampelbein> directhex: i usually attach diff.gz when it's a -0ubuntu1, debdiff only if we have the same base version in ubuntu as in debian.
[00:34] <Ampelbein> also i use debdiff when merging
[00:45] <james_w> directhex: diff.gz and pointer to the upstream tarball please
[00:46] <james_w> some sponsors ask for .dsc as well
[00:46] <james_w> the pointer can be in a watch file in the version currently in the archive, but I find that a bit more of a pain
[00:47] <calc> what is the program that can tell you what nautilus thinks the file type is of a file?
[00:49] <mathiaz> andersk: yes - the plan is to upload krb5 1.7 and then upload all relevant rdeps
[00:49] <james_w> calc: "xdg-mime query filetype <file>"?
[00:50] <andersk> Okay, as long as you're fine with temporarily making lots of Karmic packages uninstallable, skipping 1.6 should be okay.
[00:52] <mathiaz> andersk: right - karmic is a development release and we're very early in the release cycle
[00:53] <mathiaz> slangasek: ^^ I think that's ok in the current position in the release cycle
[00:54] <slangasek> mathiaz: eh, what packages are going to be made uninstallable?
[00:54] <slangasek> we do have an alpha release next week :)
[00:54] <andersk> 270 of them. `aptitude search '~D^libkrb53$'`
[00:55] <pochu> calc, james_w: I'd say gvfs-info, but am not sure
[00:56] <james_w> sounds more likely
[00:56] <slangasek> andersk: they're not going to be uninstallable immediately.  We don't remove old binary packages until the reverse-deps get rebuilt
[01:10] <andersk> Well, right, they'll become uninstallable as soon as the first package depends on libkrb5-3, since you can't install the old libkrb53 along with the new libkrb5-3.
[01:35] <slangasek> andersk: yes, they can; libkrb5-3 Replaces: libkrb53, but doesn't have a Conflicts: with it
[01:35] <slangasek> so everything should work fine
[01:35] <slangasek> mathiaz: ^^ so krb5 sync is no problem for the alpha
[01:35] <andersk> Hmm, okay.  I didn't notice that.
[01:36] <mathiaz> slangasek: ok - the remaining question is whether to sync -2 or -3
[01:36] <slangasek> I think -3 is fine
[01:36] <slangasek> (and -2 would have to be a fakesync)
[01:37] <mathiaz> slangasek: ok - so the plan is: 1. ask for a sync of -3. 2. once -3 is built, upload new packages for all rdeps of libkrb53
[01:37] <slangasek> yeppers
[01:40] <mathiaz> slangasek: cool - thanks for your input on that issue :)
[01:40] <slangasek> n/p :)
[01:41] <hartmans> anders suggested I might want to comment on whether Ubuntu wants krb5 1.7~beta1-2 or -3.
[01:42] <mathiaz> hartmans: hi - sure. Your input would be useful
[01:42] <hartmans> -3 was uploaded only  to avoid autobuilders making the transition harder in Debian. -2 will give  more correct symbol versions
[01:43] <hartmans> OTOH, -3 is relatively harmless as well, so it doesn't matter much
[01:44] <mathiaz> hartmans: IIUC in a few weeks -4 will be uploaded with the symbol versions reverted to -2?
[01:44] <hartmans> mathiaz: Correct.
[01:45] <mathiaz> hartmans: ok. And packages built against -3 won't need to be rebuilt with -4?
[01:46] <hartmans> mathiaz: I believe that is true for everything in Debian. If you have a package that uses some of the 1.7 extensions  to symbols that exist in 1.6, but uses no new 1.7 symbols, you will get incorrect dependencies generated. For ubuntu that's probably not actually an issue because you will never had had the 1.6 libraries with new names
[01:48] <hartmans> Such a package would of course work provided that you had the 1.7 libs installed, but might produce strange results (although not a segfault) if you pulled the 1.6 packages that never appeared in Ubuntu
[01:49] <mathiaz> hartmans: ok. So the easiest option for ubuntu is to use -3 so that ubuntu is kept in sync with debian.
[01:49] <hartmans> mathiaz: that certainly is a sane thing to do
[01:49] <mathiaz> Using -2 would require a fake sync and some manual work to get -4 in ubuntu once it's available in debian
[01:53] <hartmans> Well, feel free to drop me e-mail or give me a call if you run into any questions about the krb5 package now or in the future. I don't currently happen to use Ubuntu much myself, although I've used it more in the past and may well again in the future, but I'm certainly happy to answer questions or coordinate
[01:54] <mathiaz> hartmans: sure. Thanks for stopping by and giving your input on this.
[02:35] <calc> doko: do you know why unixodbc-dev is not installable on armel even after depending on libltdl7-dev ?
[02:36] <calc> gah launchpad is hosed its always giving me error screens :\
[03:14] <orangey> hello all
[03:14] <orangey> I'm trying to install martian-modem modules on jaunty, but I'm getting the following:
[03:14] <orangey> mport.c:8:41: error: asm/page.h: No such file or directory
[03:15] <orangey> how can I beat that?
[03:15] <cody-somerville> orangey, Install linux header files
[03:15] <orangey> cody-somerville: naturally, they are all already installed..
[03:15] <orangey> then what?
[03:15] <orangey> I've installed them
[03:15] <orangey> then done make oldconfig in them
[03:15] <orangey> I installed the source
[03:16] <orangey> I followed : https://help.ubuntu.com/community/Kernel/Compile
[03:16] <orangey> needless to say linux-kernel-devel doesn't appear to exist any more though
[03:16] <StevenK> linux-libc-dev
[03:18] <orangey> appears already installed or whatnot.
[03:18] <orangey> anyhow, can somebody with the right setup maybe try?
[03:19] <orangey> sudo apt-get source martian-modem
[03:19] <orangey> then get into the dir and make
[03:59] <calc> doko: is libgcj.spec missing on lpia, i got a build failure for OOo because gcj couldn't find that file on lpia
[03:59] <calc> doko: or at least it claims that is why it failed
[04:00] <calc> doko: hmm make that i think that is what it is saying
[04:02] <calc> hmm maybe it was just aot-compile.py that broke somehow
[04:06] <calc> whatever is wrong it worked fine on amd64 :\
[05:54] <dholbach> good morning
[06:12] <robert_ancell> dholbach: hello
[06:12] <dholbach_> hiya robert_ancell
[06:12] <dholbach_> how are you doing?
[06:13] <robert_ancell> not bad.  Upgrading to Karmic currently so will be able to tell you in a few minutes :)
[06:13] <dholbach> robert_ancell: enjoy :-)
[06:13] <dholbach> robert_ancell: I'm still running it in a VM :)
[06:14] <robert_ancell> i'm living life on the edge! (not enough space for the VM at the moment)
[06:15] <dholbach> robert_ancell: I'll start collecting some money for a new harddrive for you :)
[06:16] <robert_ancell> dholbach: I really just need to get around to resizing the windows partition on it - and you can never have enough space for VMs!
[06:16] <robert_ancell> dholbach: where are you based?
[06:16] <dholbach> Berlin, Germany
[06:17] <robert_ancell> nice city, I look forward to going back sometime
[06:17] <dholbach> we should pester Mark about having the next summer UDS in Berlin :)
[06:17] <robert_ancell> +1 from me
[06:18] <dholbach> woohoo!
[06:18] <robert_ancell> (I think it's going to take a lot of pestering to get a UDS down under)
[06:18] <StevenK> One has happened
[06:18] <dholbach> we had one there... after hoary I think
[06:19] <robert_ancell> StevenK: and that's why it will be hard to pester again I think :) Especially with the size of the company now
[06:19] <StevenK> dholbach: Breezy's UDS was UDU
[06:19] <dholbach> I wouldn't mind going to someplace in Asia - at least you guys down there probably wouldn't have to travel that far :)
[06:20] <StevenK> (Ubuntu Down Under)
[06:20] <dholbach> StevenK: so after hoary :)
[06:20] <dholbach> StevenK: I was there
[06:20]  * StevenK wasn't
[06:20] <lifeless> dholbach: asia is very big :P
[06:20] <dholbach> lifeless: that's why I said "probably" :)
[06:20] <lifeless> dholbach: hell, spain nearly is asia :>
[06:20] <robert_ancell> yeah asia would be good.  Could do Dubai as that's not too far from Europe
[06:21] <dholbach> lifeless: you're exaggerating a fair bit my friend :)
[06:21] <lifeless> dholbach: a tad ;)
[07:03] <pitti> Good morning
[07:04] <Hobbsee> morning pitti!
[07:04]  * pitti hugs Hobbsee, good morning!
[07:04] <Hobbsee> :)
[07:06] <StevenK> Morning pitti
[07:08]  * NCommander sighs
[07:23] <dholbach> ArneGoetje: is ibus the way to go in the future?
[07:28] <NCommander> hey pitti
[07:30] <tkamppeter> pitti, can you have a look at bug 369850? Why does parport_pc not get loaded automatically any more?
[07:31] <pitti> tkamppeter: it should, it has plenty of modaliases; I'll ask for some debugging
[09:16] <geser> how detailed should a MIR for dh-ocaml (helper tools for maintaining OCaml-related Debian packages) be? it's needed to build ocaml
[09:16] <pitti> geser: I'd say a bug report with the most important QA data is enough
[09:16] <pitti> geser: it sounds trivial
[09:16] <pitti> geser: don't waste time on a complete wiki page
[09:17] <pitti> geser: so, security/i18n/etc. isn't an issue, just maintenance and pacakging standard
[09:38] <geser> pitti: filed as bug 373149. Anything missing?
[09:38] <pitti> geser: looks good to me
[10:17] <pitti> yay, I managed to push a git branch to people.u.c., and it only took me 20 minutes until it worked
[10:17]  * pitti *headdesk*
[10:18]  * dholbach hugs pitti :)
[10:20] <directhex> git's a git
[10:24] <soren> pitti: Why not put it on kernel.ubuntu.com?
[10:24] <soren> pitti: ...let's just say that you wouldn't be the first to put non-kernel-related git branches on there. :)
[10:27] <pitti> soren: I don't have an account there
[10:27] <pitti> soren: yes, I have a branch of udev-extras, whose trunk is on git.k.o.
[10:31] <soren> pitti: Ah, ok.
[10:31] <directhex> ember, i prepped a 0ubuntu1 for the latest development release of tomboy, hopefully that helps. looks like you've been the one touching that package lately
[10:35] <pitti> gosh, and it still doesn't work properly
[10:35] <pitti> this is just plain madness
[10:35]  * pitti will just use format-patches
[10:59] <ogra> cjwatson, is it deliberate that armel live images were not built today ? (i cant find a log under http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu/latest/)
[11:08] <NCommander> ogra, I got a build failure when Xubuntu/armel tried to build; probably something gone wrong w/ the build environment :-/
[11:10] <ogra> well, then there should be a log at least ... to me it looks like it wasnt attempted ... /me checks antimony directly
[11:11] <ogra> oh, right, looks like there is no livefs on manoao
[11:12] <NCommander> ogra, I can run the livefs build script and see what went boom
[11:13] <NCommander> ogra, (I'm running it now, it takes about an hour on my Babbage to do a full run so I'll know then)
[11:22] <Keybuk> /usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory
[11:22] <Keybuk> ...
[11:22] <Keybuk> I'm guessing there are some issues with the buildds today <g>
[11:22] <pitti> ah, that's why everything is just blowing up here
[11:23] <pitti> asm/ seems completely gone from linux-libc-dev
[11:23] <Keybuk> yeah
[11:25] <cjwatson> ogra: please don't stress about images
[11:25] <cjwatson> ogra: we haven't got *anything* working for karmic image-wise yet
[11:25] <cjwatson> ogra: expecting armel to be the first is ... optimistic!
[11:26] <ogra> cjwatson, right, but i'm supposed to make 100% sure all mobile images are there for A1 ... sorry if i'm a PITA through checking and asking every day
[11:26] <ogra> i wont push more but will still check
[11:26] <cjwatson> feel free to check, just please don't nag about it. everything is already on the list.
[11:26] <ogra> ok
[11:26] <NCommander> cjwatson, I've built a few live rootfs's so hopefully when the scripts updated, it should all just work :-)
[11:27] <cjwatson> what script updated how?
[11:27] <NCommander> cjwatson, whatever crontabs need to be updated to generate karmic images (if any, I'm not too familar with cdimage's crontabs)
[11:27] <cjwatson> they already were
[11:28] <ogra> NCommander, just leave it to cjwatson, he knows whats missing and what needs adding
[11:28] <ogra> i'm sure we'll be pinged to check if its supposed to work ;)
[11:28] <NCommander> ogra, oh, I trust cjwatson 100%, I was just noting that from the perpsective of building live rootfs's things seem to look OK-ish
[11:29] <cjwatson> there's no indication of why it wouldn't have tried to do a build
[11:30]  * NCommander notes that a few packages are uninstallable on armel :-/
[11:31] <cjwatson> ah, BuildLiveCD needs to be updated to default to karmic
[11:31] <elmo> on the buildds?
[11:31] <cjwatson> yes
[11:32] <cjwatson> it's clearly already been done on some of them
[11:32] <cjwatson> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/jaunty/ubuntu/latest/ shows that at least manoao, weddell, and royal need to be fixed, though
[11:34] <elmo> cjwatson: it was only done on i386/amd64; I've done the rest now
[11:35] <elmo> (lpia, hppa, powerpc, sparc, ia64 and armel)
[11:35]  * ogra hugs elmo
[13:04] <ogra> Keybuk, blkid ? i thought using it was a bad thing because of the chache it uses
[13:05] <ogra> (/me sees the initramfs-tools upload)
[13:06] <Keybuk> it doesn't anymore
[13:06] <Keybuk> it now looks in /dev/disk/by-uuid etc. instead
[13:06] <ogra> ah, great
[13:06] <ogra> so it doesnt matter what i use ? or should my scripts also switch over ?
[13:07] <Keybuk> you should use blkid
[13:07] <ogra> ok
[13:08] <ogra> thanks
[13:10] <cjwatson> elmo: cool, thanks
[13:46] <cjwatson> superm1: could you change 'include platform.jaunty' in lp:~mythbuntu/ubuntu-seeds/mythbuntu.karmic/STRUCTURE to 'include platform.karmic', please?
[13:48] <cjwatson> Keybuk,pitti: are either of you chasing up the linux-libc-dev asm/ bug?
[13:49] <Ampelbein> hi. i got a problem with building jabberd2 in pbuilder. I can't get the current version in the archives to be successfully built. The problem seems to be that configure does not find the headerfile resolv.h. but it is there if i login to the pbuilder environment. can someone give me a hint on where to start debugging this?
[13:50] <Ampelbein> and building the package with 'fakeroot debian/rules build' works
[13:51] <cjwatson> Ampelbein: what release?
[13:52] <Ampelbein> cjwatson: karmic
[13:52] <Ampelbein> cjwatson: and jabberd2 version is 2.2.1-1.1ubuntu1, grabbed from the source-package's page.
[13:53] <cjwatson> Ampelbein: probably due to linux-libc-dev being totally busted at the moment in karmic then - it's missing /usr/include/asm/
[14:01] <devfil_> seb128: can you take a look at bug 372833 please?
[14:02] <seb128> the sponsor team seems to be subscribed it will get reviewed
[14:02] <seb128> I'm attending a sprint right now and I'm too busy to do reviews
[14:03] <seb128> is there anything specially urgent there than you ping on IRC?
[14:04] <devfil_> seb128: no, don't worry
[14:05] <seb128> commented on the bug
[14:05] <seb128> I'm not sure where this list come from but there should be an upstream pointer there
[14:05] <seb128> that will not change in jaunty and if the next pidgin version fixes the bug mentioned that will be fixed in karmic
[14:06] <amitk> cjwatson: I am looking at bug 373214 right now
[14:07] <cjwatson> amitk: thanks
[14:07] <amitk> discussion on #u-k
[14:07] <Ampelbein> cjwatson: thanks! that was indeed the problem. i reverted the version in the pbuilder-chroot and now it works.
[14:10] <ogra> mumble, nautilus-share FTBFS on lpia and arm ...
[14:10] <ogra> ah, its gnomecanvas
[14:11] <ogra> and gnomeui
[14:11]  * hyperair hears nautilus-share
[14:12] <devfil_> seb128: replied, thanks
[14:14] <superm1> cjwatson, sure. switched. thanks for reminding
[14:14] <ogra> hmm...
[14:14]  * ogra gives back nautilus-share on armel
[14:15] <hyperair> /usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory
[14:16] <hyperair> this is the error on ppc.
[14:16] <cjwatson> ogra: while that particular error is fixed, there's really not much point giving stuff back right now
[14:16] <cjwatson> the linux-libc-dev bug means that lots of builds are completely busted
[14:17] <ogra> well, there is a weird bonmobo dep issue in the ftbfs log i would like to see if its fixed ... i know it will fail on linux-libc-dev but would like to see it surviving up to there at least :)
[14:17] <cjwatson> hyperair: ^- this isn't just you and it's being investigated
[14:18] <hyperair> cjwatson: that's from the build log
[14:18] <ogra> hyperair, right and its being worked on
[14:18] <hyperair> i see
[14:19] <ogra> mvo, any idea about http://launchpadlibrarian.net/26407435/buildlog_ubuntu-karmic-armel.python-apt_0.7.10.3ubuntu1_FAILEDTOBUILD.txt.gz ?
[14:19] <ogra> ln -sf ../../../../javascript/jquery/jquery.js debian/python-apt/usr/share/doc/python-apt/html/_static/jquery.js
[14:19] <ogra> ln: creating symbolic link `debian/python-apt/usr/share/doc/python-apt/html/_static/jquery.js': No such file or directory
[14:20] <mvo> ogra: impressive, I have seen something similar yesterday for debian-installer
[14:20] <ogra> oh, wait there is a former error further up
[14:20] <mvo> ogra: the package in jaunty seems to be ok, but a recompile seems to be not ok
[14:20] <ogra> Exception occurred:
[14:20] <ogra>   File "/usr/lib/pymodules/python2.6/debian_bundle/debian_support.py", line 25, in <module>
[14:20] <ogra>     import apt_pkg
[14:20] <ogra> ImportError: /usr/lib/libstdc++.so.6: undefined symbol: __sync_val_compare_and_swap_4
[14:21] <ogra> hrm
[14:22] <cjwatson> hyperair: yes, we're aware
[14:22] <hyperair> right
[14:30] <mvo> ogra: I log into the porting machine to have a closer look, but that looks pretty strongly like a libstd++/g++ issue
[14:30] <ogra> mvo, seems totem has the same prob ... so its /usr/lib/libstdc++.so.6
[14:30] <ogra> /usr/lib/libstdc++.so.6: undefined reference to `__sync_lock_test_and_set_1'
[14:30] <ogra> /usr/lib/libstdc++.so.6: undefined reference to `__sync_sub_and_fetch_4'
[14:30] <ogra> /usr/lib/libstdc++.so.6: undefined reference to `__sync_lock_test_and_set_4'
[14:30] <ogra> /usr/lib/libstdc++.so.6: undefined reference to `__sync_add_and_fetch_4'
[14:30] <ogra> /usr/lib/libstdc++.so.6: undefined reference to `__sync_val_compare_and_swap_4'
[14:30] <ogra> /usr/lib/libstdc++.so.6: undefined reference to `__sync_fetch_and_add_4'
[14:30] <ogra> collect2: ld returned 1 exit status
[14:30] <ogra> ^^^ from the totem log
[14:31] <mvo> ogra: cjwatson had a similar one with debian-installer too
[14:31] <ogra> hmm
[14:32] <mweichert> is there a way to suppress or preseed options to "dpkg --configure" when using "apt-get install" in a script?
[14:32] <mvo> mweichert: what problem do you try to solve this way?
[14:34] <mweichert> mvo, I'm preseeding an installation. We have a standard config that we deploy and I'm trying a script that gets called as d-i's late command
[14:34] <pitti> cjwatson: I'll file a bug about it and talk to the kernel team
[14:35] <mvo> mweichert: thanks, sorry I don't know a great deal about the installer preseeding
[14:36] <ogra> pitti, happening already bug 373214
[14:36] <mweichert> mvo, ok, thanks for your help. Though my questions is more about dpkg/apt-get then preseeding.
[14:36] <pitti> ogra: ah, thanks
[14:36] <ogra> doko, any idea about the /usr/lib/libstdc++.so.6 stuff above ?
[14:37] <cjwatson> 15:14 <doko> infinity: libstdc++6 is currently broken on armel. new gcc-4.4 (4.4.0-3ubuntu3) won't build with the 4.4.0-3ubuntu1 version in the archive. any earlier version will do. so one manual build will be
[14:37] <cjwatson>              needed ...
[14:38] <cjwatson> 15:15 <cjwatson> ah, is that why apt-ftparchive is busted
[14:38] <cjwatson> 15:45 <doko> cjwatson: yes, likely
[14:38] <cjwatson> 15:46 <doko> I hate symbols files for C++ libs
[14:38] <ogra> cjwatson, TA !
[14:38] <mvo> mweichert: there is "-o Dpkg::Post-Invoke"
[14:38] <mweichert> mvo, oh - I'll take a look at that.
[14:38] <doko> ogra: you could use the debs from rimu:~doko/gcc/install
[14:39] <ogra> doko, i'm checking whats missing to build a livefs on armel atm i guess that wont help much :)
[14:39] <ogra> just looking at the broken deps etc, if it gets fixed in the archive within the next 6 days i'm fine
[14:39] <doko> ogra: not really, lamont is currently working on the manual build
[14:40] <ogra> good then, thats enough
[14:43] <apachelogger> james_w: I was thinking about something more productive ;-)
[14:43] <apachelogger> I guess I'll just have to create one
[14:43] <james_w> apachelogger: can you explain a bit more about what you want to achieve?
[14:44] <apachelogger> james_w: branch all the kde packaging branches to /jaunty for SRU use
[14:44] <james_w> ah, ok
[14:44] <james_w> I don't think there is anything pre-canned
[14:45] <apachelogger> james_w: well, shouldn't be a problem to enhance our existing batch-action-script to do that as well
[14:45] <apachelogger> thanks anyway :)
[14:46] <james_w> do you really want to pre-populate the branches?
[14:46] <james_w> wouldn't use just branch when you first want to do something with an SRU?
[14:50] <apachelogger> james_w: that would mean that $developer needs to know how to branch a revision and how to push it to the proper path ... you really don't want them have to worry about that ... they certainly won't ;-)
[14:51] <james_w> true
[15:49] <Unggnu> hi all
[16:15] <primes2h> jdong: There are a lot of bugs to close about gutsy https://bugs.edge.launchpad.net/gutsy-backports/ but I can't set them as "Won't Fix" because they are backports. Can I set them as "Invalid" instead?
[18:30] <Scrye> hello, is the quagga maintainer here?
[18:30] <soren> -> #ubuntu-server, probably.
[18:38] <Scrye> thank you
[18:51] <tacone> hello, I'm experiencing freezes on jaunty with gksu2.ask_password_full() (python stuff). everything worked on Intrepid. any clue ?
[18:58] <imachine> hi
[18:58] <imachine> I was wondering, are we getting 180.51 nvidia drivers in the repos any time soon?
[18:59] <imachine> I'm having numerous issues with memleaks, could help testing the new drivers on 64bit too.
[18:59] <imachine> running jaunty.
[19:09] <jdong> calc: out of pure curiousity, are the OOo3.1 jaunty packages in ~openoffice-pkgs PPA usable?
[19:11] <imachine> maybe there's a ppa about nvidia drivers too?
[19:11] <jdong> imachine: the x-updates PPA you mean?
[19:12] <jdong> calc: well I guess the two FTBFSes answer my question :)
[19:17] <imachine> es!
[19:17] <imachine> jdong, just found it ;-P
[19:17] <imachine> thanks ;-)
[19:58] <calc> jdong: hmm?
[19:58] <calc> jdong: well the ooo-l10n ftbfs yea
[20:13] <slangasek> calc: just saw the same gcj "libgcj.spec: no such file or directory" error on an amd64 build
[20:16] <slangasek> seems that the .spec file has moved from libgcjNN-dev to gcj-4.4-jdk?
[20:17] <mathiaz> sbeattie: hi - re bug 326768 - I'd rather not get this update go to -updates for now
[20:17] <mathiaz> sbeattie: it has already landed in -proposed
[20:17] <slangasek> but that's installed for the build in question here, and there doesn't appear to be any version skew, so no idea why it's not working
[20:18] <mathiaz> sbeattie: I've remove the verification-needed tag and set back the bug status to confirmed
[20:18] <mathiaz> sbeattie: however I cannot unsubscribe ubuntu-sru and the sru-verification team
[20:18] <mathiaz> sbeattie: is there anything else I should do?
[20:19] <sbeattie> mathiaz: do you still want it in -proposed?
[20:19] <mathiaz> sbeattie: it's already in -proposed
[20:19] <mathiaz> sbeattie: I'd rather not get it in -updates
[20:20] <sbeattie> mathiaz: I'm asking do you want it pulled from proposed?
[20:21] <mathiaz> sbeattie: ah - yes if that's possible
[20:24] <sbeattie> slangasek: ^^^
[20:25] <slangasek> mathiaz: you could set the 'verification-failed' tag?
[20:25] <slangasek> or is that not actually the issue?
[20:32] <mathiaz> slangasek: well - technically it's not a verification failed - the proposed solution fixes the symptoms
[20:33] <mathiaz> slangasek: however I'm not confident enough to push it directly to -updates
[20:33] <mathiaz> slangasek: I'd have more time to spend debugging the issue
[20:34] <mathiaz> slangasek: so I wanna make sure it doesn't get in -updates by mistake
[20:34] <slangasek> well, I'll use the verification-failed tag for that then; I don't think we should retract updates from -proposed if we don't have to
[20:34] <mathiaz> slangasek: ok - I'll use the verification-failed tag
[20:35] <mnemo> what happens if a user has a custom PPA version of something and ubuntu issues a security fix? does it uninstall his PPA version or does he miss the security fix?
[20:37] <ScottK> It depends on how the PPA pacakge is versioned, but generally you miss the security fix.
[20:38] <mnemo> are security fixes using the same incremental counter as SRU's ??
[20:38] <mnemo> for example if the current SRU version is BLAH.2 will a security fix be called BLAH.3 then?
[20:38] <kees> mnemo: generally, yes.
[20:39] <mnemo> ok
[20:39] <ScottK> mnemo: There's no guarantee at all about anything about a PPA package, so except for from people you trust, you're already accepting some risk if you use them.
[20:40] <calc> slangasek: yea i thought it might have been somehow related to the linux-libc-dev mess, but i am not sure
[20:40] <slangasek> I can't imagine why that would be the case
[20:41] <slangasek> anyway, your comments were before the broken linux-libc-dev got published, AFAICS
[20:41] <calc> slangasek: i was going to do a test build locally but by the time i got my build setup it was failing due to the cups issue on i386 also
[20:41] <slangasek> "the cups issue"?
[20:41] <calc> slangasek: cups headers can't be "found" now for several archs
[20:42] <slangasek> url?
[20:43] <calc> slangasek: see build failure for powerpc: http://launchpadlibrarian.net/26415416/buildlog_ubuntu-karmic-powerpc.openoffice.org_1%3A3.1.0~rc2-1ubuntu1_FAILEDTOBUILD.txt.gz
[20:43] <calc> slangasek: same thing happens for me when i try to build it on i386
[20:43] <calc> slangasek: the fact i386 previously failed from the gcj bit makes me think that the cups bit at least is related to the linux-libc-dev header mess
[20:44] <slangasek> calc: yes, that's almost certainly just linux-libc-dev
[20:44] <calc> ok
[20:44] <calc> i'm not sure what the issue is with the armel OOo build failure
[20:45] <calc> it claims unixodbc-dev can't be installed
[20:46] <calc> whatever is causing the gcj problem on i386/lpia didn't happen on amd64 which was why i was looking into it when i saw it failed due to cups now :\
[20:48] <cjwatson> I'm making good progress on the linux-libc-dev bug, and have more or less found what's wrong - just trying to construct a minimal test case for upstream now
[20:49]  * calc hugs cjwatson 
[20:50] <slangasek> calc: unixodbc-dev> another instance of a package winding up in the wrong section out of NEW, WTF
[20:51] <calc> ah
[20:51] <slangasek> (http://people.ubuntu.com/~ubuntu-archive/architecture-mismatches.txt)
[20:52] <calc> so i only have on real failure issue to look into, thats much better :)
[20:52] <slangasek> cjwatson: armel binaries of libtool landed 24h after all the other archs; if libtool was NEWed on those archs before it was available on armel, what happens/is supposed to happen?
[20:53] <cjwatson> slangasek: each architecture should show up in NEW separately
[20:53] <cjwatson> (not that this is ideal from the POV of archive admin workflow, and dak was more reasonable about it, but that's how Soyuz has always done it)
[20:59] <slangasek> kirkland: yesterday was your archive day; do you recall putting a libtool-dev package through NEW on armel?
[20:59] <slangasek> kirkland: libltdl-dev, rather
[21:00] <kirkland> slangasek: i did work on archive stuff yesterday, spent my whole day doing sync's, didn't get to any NEW's
[21:00] <slangasek> ok
[21:00] <kirkland> slangasek: need help with something?
[21:00] <slangasek> Riddell: did you do any NEWing yesterday?
[21:01] <slangasek> kirkland: I'm trying to figure out what's going wrong that's causing all these new packages to end up in the wrong section
[21:02] <kirkland> slangasek: hmm, sorry, i don't know
[21:02] <slangasek> given that it's happened all of a sudden, I really suspect (worry) that it's a soyuz behavior change
[21:05] <kirkland> slangasek: on an unrelated note ...  I need an arch admin to process the rename of the screen-profiles source/binary package to it's new name, byobu
[21:06] <kirkland> slangasek: any idea where i need to request that?
[21:06] <slangasek> packages don't get renamed
[21:06] <kirkland> slangasek: just file a bug, and subscribe arch admin?
[21:06] <slangasek> you upload a new one under the new name
[21:06] <kirkland> slangasek: okay, i did that
[21:06] <kirkland> slangasek: and it's in the new queue
[21:06] <slangasek> then whoever processes NEW next will get it
[21:06] <kirkland> slangasek: oh, okay, that's surprisingly easy
[21:41] <slangasek> infinity, james_w, jdstrand, Riddell, pitti, mdz, Hobbsee, ScottK, StevenK: do any of you remember having done NEW processing of libltdl-dev on armel yesterday (May 6)?
[21:41] <mdz> slangasek: I don't think I even have an account on the appropriate machine anymore
[21:41] <ScottK> slangasek: I did not do any.
[21:42] <slangasek> mdz: can be done through the web interface these days, but ok :)
[21:42] <mdz> slangasek: ooh, shiny
[21:43] <jdstrand> slangasek: not I
[21:44] <jdstrand> or even me...
[21:46] <james_w> slangasek: nope
[21:48] <xee> is there a channel for Ubuntu re-branding and derivatives?
[21:48] <Riddell> slangasek: yes that was probably me
[22:01] <slangasek> Riddell: ok - just trying to get a handle on why all these NEW binary packages have been landing in universe
[22:02] <lamont> dear oo.o, more, smaller packages.  srsly. kthx
[22:02] <slangasek> we can obviously fix them up after accept if we're not sure at first where they belong, but I've been worried there's some systemic problem
[22:18] <cjwatson> lamont: yes, the findutils bug will get in the way of libstdc++. I'm about to upload a fix which will probably need to be built manually against an older linux-libc-dev
[22:18] <lamont> yay
[22:18] <lamont> I see my morning going wonderfully manual
[22:22] <cjwatson> lamont: OK. I've uploaded findutils 4.4.1-1ubuntu2. That needs to be built with the old linux-libc-dev. Then linux and linux-ports need to be reuploaded (hi, Tim ...) and once findutils is published they need to be built against new findutils and old linux-libc-dev
[22:22] <lamont> hooray for no-change uploads, eh?
[22:23] <cjwatson> I'm sure the kernel guys have something to put in there
[22:23] <lamont> cjwatson: which means I'm most likely to pin linux-libc-dev in the tarball and put the buildds on manual while we cycle through
[22:23] <lamont> the always do
[22:23] <lamont> they
[22:23] <cjwatson> pinning linux-libc-dev in the tarball will let other stuff build anyway
[22:23] <cjwatson> but yes
[22:24] <lamont> when I bastardize the production tarball, the buildds go manual... iz RULE.
[22:24] <cjwatson> lamont: WFM
[22:26] <lamont> cjwatson: and I'm totally EOD, with family obligations for a few hours... with any luck, I'll manage to smack things a bit this evening wearing my ubuntu-hat, but it might be 1000 UTC before I actually get there :-(
[22:26] <cjwatson> lamont: right :-/
[22:26] <cjwatson> lamont: if you can at least stick the buildds on manual so that we stop getting build failures, that would probably be good
[22:26] <cjwatson> pull the big shutdown switch
[22:27] <lamont> oh, that's easy
[22:27] <lamont> but if I kill the buildd sequencer, then we get alarms... I think I'll go the manual route. :-D
[22:27] <lamont> cjwatson: just to confirm, all buildds, all architectures, but not ppa buildds
[22:27] <cjwatson> correct
[22:28] <cjwatson> no PPAs for karmic yet
[22:28] <cjwatson> oh, hmm
[22:28] <cjwatson> shutting down all the buildds will kill non-karmic builds too
[22:28] <cjwatson> maybe best leave them going in case there's something for security :-/
[22:28] <lamont> ah, right
[22:28] <cjwatson> or even -proposed/-updates
[22:28] <lamont> keeps the DC warmer and all that
[22:28] <cjwatson> we'll just have to cope with the failure mails
[22:28] <lamont> and then we just mass-give-back karmic when fixed
[22:31] <imachine> jdong, it's so much better after upgrading to the X.org+friends from ubuntu-x-updates ppa
[22:31] <imachine> jdong, spot on
[22:31] <imachine> cheers
[22:31] <mbana> what's this tracker applet about?
[22:32] <mbana> i just had a prompt about a corrupt index
[22:35] <ScottK> cjwatson: There are PPAs for Karmic.
[22:35] <cjwatson> ScottK: I was told recently that they hadn't been enabled yet, but I didn't check; if they have been, I stand corrected
[22:36] <ScottK> cjwatson: ubuntu-clamav PPA has one Karmic package in it, so it appears they are.
[22:36] <cjwatson> fair enough
[22:37] <slangasek> yes, they're up, with refreshed documentation in NewReleaseCycleProcess
[22:39] <cjwatson> for anyone who's interested, http://launchpadlibrarian.net/26447089/findutils_4.4.1-1ubuntu1_4.4.1-1ubuntu2.diff.gz is the basic fix; a more complete patch with a test case is on its way upstream
[22:56] <mheld> anybody know if the 64 bit packages for ubuntu are compiled with SSE2 or SSE3 flags?
[23:36] <doko> cjwatson, pitti: now that java-gcj-compat is gone, there's a very nice list of java packages ready for demotion :-)
[23:39] <calc> some of those demotion also are due to OOo needing a different set of packages
[23:40] <calc> once linux-libc-dev is fixed i will be uploading a new OOo with the new build-deps added
[23:42] <calc> that reminds me to write the bug report
[23:47] <calc> erm how do i add another package to a bug report
[23:47] <calc> i used to replace the previous package name in the url with the new one and a 'also report here' dialog would show up, but it seems to no longer do this
[23:48] <calc> now it seems too 'smart' and goes back to the previous url
[23:49] <calc> slangasek: do you happen to know? ^
[23:50] <slangasek> calc: 'also affects distribution'?
[23:50] <Ampelbein> calc: 'also affects distribution' -> ubuntu -> packagename
[23:50] <calc> wow that sucks
[23:51] <calc> so they now made it from one step into several
[23:51] <calc> thanks for the workaround though :)
[23:52] <Ampelbein> calc: i think the 'also report here' caused some trouble so they changed it. i remember seeing a discussion in IRC, probably in #launchpad
[23:52] <calc> ok