[00:03] slangasek: I don't think it's a no-op [00:03] slangasek: http://git.debian.org/?p=pkg-k5-afs/debian-krb5.git [00:03] slangasek: the last two commits show some version changes in debian/libgssapi-krb5-2.symbols, etc... [00:05] 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] dtchen: hrm ok. [00:12] slangasek: ok - I'm gonna ask the debian maintainer what's the purpose of the last change [00:13] slangasek: may be we should go with 1.7dfsg~beta1-2 instead of 1.7dfsg~beta1-3 [00:15] 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] 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] 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] The Debian changelog mentions "new functionality", which I assume refers to new functionality in the existing symbols. [00:22] which is out of scope for symbol versioning anyway... [00:22] 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] This just happens to be the case for all packages currently in Debian. [00:28] what's the current fashion for 0ubuntu1 upstream updates - a mahoosive debdiff, or a new diff.gz? [00:33] 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] 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] also i use debdiff when merging [00:45] directhex: diff.gz and pointer to the upstream tarball please [00:46] some sponsors ask for .dsc as well [00:46] 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] what is the program that can tell you what nautilus thinks the file type is of a file? [00:49] andersk: yes - the plan is to upload krb5 1.7 and then upload all relevant rdeps [00:49] calc: "xdg-mime query filetype "? [00:50] Okay, as long as you're fine with temporarily making lots of Karmic packages uninstallable, skipping 1.6 should be okay. [00:52] andersk: right - karmic is a development release and we're very early in the release cycle [00:53] slangasek: ^^ I think that's ok in the current position in the release cycle [00:54] mathiaz: eh, what packages are going to be made uninstallable? [00:54] we do have an alpha release next week :) [00:54] 270 of them. `aptitude search '~D^libkrb53$'` [00:55] calc, james_w: I'd say gvfs-info, but am not sure [00:56] sounds more likely [00:56] andersk: they're not going to be uninstallable immediately. We don't remove old binary packages until the reverse-deps get rebuilt [01:10] 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] andersk: yes, they can; libkrb5-3 Replaces: libkrb53, but doesn't have a Conflicts: with it [01:35] so everything should work fine [01:35] mathiaz: ^^ so krb5 sync is no problem for the alpha [01:35] Hmm, okay. I didn't notice that. [01:36] slangasek: ok - the remaining question is whether to sync -2 or -3 [01:36] I think -3 is fine [01:36] (and -2 would have to be a fakesync) [01:37] 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] yeppers [01:40] slangasek: cool - thanks for your input on that issue :) [01:40] n/p :) [01:41] anders suggested I might want to comment on whether Ubuntu wants krb5 1.7~beta1-2 or -3. [01:42] hartmans: hi - sure. Your input would be useful [01:42] -3 was uploaded only to avoid autobuilders making the transition harder in Debian. -2 will give more correct symbol versions [01:43] OTOH, -3 is relatively harmless as well, so it doesn't matter much [01:44] hartmans: IIUC in a few weeks -4 will be uploaded with the symbol versions reverted to -2? [01:44] mathiaz: Correct. [01:45] hartmans: ok. And packages built against -3 won't need to be rebuilt with -4? [01:46] 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] 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] hartmans: ok. So the easiest option for ubuntu is to use -3 so that ubuntu is kept in sync with debian. [01:49] mathiaz: that certainly is a sane thing to do [01:49] Using -2 would require a fake sync and some manual work to get -4 in ubuntu once it's available in debian [01:53] 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] hartmans: sure. Thanks for stopping by and giving your input on this. === rickspencer3 is now known as rickspencer3-afk [02:35] doko: do you know why unixodbc-dev is not installable on armel even after depending on libltdl7-dev ? [02:36] gah launchpad is hosed its always giving me error screens :\ [03:14] hello all [03:14] I'm trying to install martian-modem modules on jaunty, but I'm getting the following: [03:14] mport.c:8:41: error: asm/page.h: No such file or directory [03:15] how can I beat that? [03:15] orangey, Install linux header files [03:15] cody-somerville: naturally, they are all already installed.. [03:15] then what? [03:15] I've installed them [03:15] then done make oldconfig in them [03:15] I installed the source [03:16] I followed : https://help.ubuntu.com/community/Kernel/Compile [03:16] needless to say linux-kernel-devel doesn't appear to exist any more though [03:16] linux-libc-dev [03:18] appears already installed or whatnot. [03:18] anyhow, can somebody with the right setup maybe try? [03:19] sudo apt-get source martian-modem [03:19] then get into the dir and make [03:59] 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] doko: or at least it claims that is why it failed [04:00] doko: hmm make that i think that is what it is saying [04:02] hmm maybe it was just aot-compile.py that broke somehow [04:06] whatever is wrong it worked fine on amd64 :\ === mcasadevall is now known as NCOmmander === NCOmmander is now known as NCommander === freeflyi1g is now known as freeflying === lamont` is now known as lamont === billisnice_ is now known as billisnice === maco_ is now known as maco [05:54] good morning [06:12] dholbach: hello [06:12] hiya robert_ancell [06:12] how are you doing? === dholbach_ is now known as dholbach [06:13] not bad. Upgrading to Karmic currently so will be able to tell you in a few minutes :) [06:13] robert_ancell: enjoy :-) [06:13] robert_ancell: I'm still running it in a VM :) [06:14] i'm living life on the edge! (not enough space for the VM at the moment) [06:15] robert_ancell: I'll start collecting some money for a new harddrive for you :) [06:16] 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] dholbach: where are you based? [06:16] Berlin, Germany [06:17] nice city, I look forward to going back sometime [06:17] we should pester Mark about having the next summer UDS in Berlin :) [06:17] +1 from me [06:18] woohoo! [06:18] (I think it's going to take a lot of pestering to get a UDS down under) [06:18] One has happened [06:18] we had one there... after hoary I think [06:19] StevenK: and that's why it will be hard to pester again I think :) Especially with the size of the company now [06:19] dholbach: Breezy's UDS was UDU [06:19] 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] (Ubuntu Down Under) [06:20] StevenK: so after hoary :) [06:20] StevenK: I was there [06:20] * StevenK wasn't [06:20] dholbach: asia is very big :P [06:20] lifeless: that's why I said "probably" :) [06:20] dholbach: hell, spain nearly is asia :> [06:20] yeah asia would be good. Could do Dubai as that's not too far from Europe [06:21] lifeless: you're exaggerating a fair bit my friend :) [06:21] dholbach: a tad ;) === robbiew-away is now known as robbiew [07:03] Good morning [07:04] morning pitti! [07:04] * pitti hugs Hobbsee, good morning! [07:04] :) [07:06] Morning pitti === crd1b is now known as crdlb [07:08] * NCommander sighs === tkamppeter_ is now known as tkamppeter [07:23] ArneGoetje: is ibus the way to go in the future? [07:28] hey pitti [07:30] pitti, can you have a look at bug 369850? Why does parport_pc not get loaded automatically any more? [07:30] Launchpad bug 369850 in linux "Cannot set up parallel port printer on Ubuntu 9.04" [High,New] https://launchpad.net/bugs/369850 [07:31] tkamppeter: it should, it has plenty of modaliases; I'll ask for some debugging [09:16] 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] geser: I'd say a bug report with the most important QA data is enough [09:16] geser: it sounds trivial [09:16] geser: don't waste time on a complete wiki page [09:17] geser: so, security/i18n/etc. isn't an issue, just maintenance and pacakging standard [09:38] pitti: filed as bug 373149. Anything missing? [09:38] Launchpad bug 373149 in dh-ocaml "Move dh-ocaml to main" [Undecided,New] https://launchpad.net/bugs/373149 [09:38] geser: looks good to me [10:17] 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] git's a git === azeem_ is now known as azeem [10:24] pitti: Why not put it on kernel.ubuntu.com? [10:24] pitti: ...let's just say that you wouldn't be the first to put non-kernel-related git branches on there. :) [10:27] soren: I don't have an account there [10:27] soren: yes, I have a branch of udev-extras, whose trunk is on git.k.o. [10:31] pitti: Ah, ok. [10:31] 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] gosh, and it still doesn't work properly [10:35] this is just plain madness [10:35] * pitti will just use format-patches [10:59] 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] ogra, I got a build failure when Xubuntu/armel tried to build; probably something gone wrong w/ the build environment :-/ [11:10] well, then there should be a log at least ... to me it looks like it wasnt attempted ... /me checks antimony directly [11:11] oh, right, looks like there is no livefs on manoao [11:12] ogra, I can run the livefs build script and see what went boom [11:13] 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] /usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory [11:22] ... [11:22] I'm guessing there are some issues with the buildds today [11:22] ah, that's why everything is just blowing up here [11:23] asm/ seems completely gone from linux-libc-dev [11:23] yeah [11:25] ogra: please don't stress about images [11:25] ogra: we haven't got *anything* working for karmic image-wise yet [11:25] ogra: expecting armel to be the first is ... optimistic! [11:26] 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] i wont push more but will still check [11:26] feel free to check, just please don't nag about it. everything is already on the list. [11:26] ok [11:26] cjwatson, I've built a few live rootfs's so hopefully when the scripts updated, it should all just work :-) [11:27] what script updated how? [11:27] cjwatson, whatever crontabs need to be updated to generate karmic images (if any, I'm not too familar with cdimage's crontabs) [11:27] they already were [11:28] NCommander, just leave it to cjwatson, he knows whats missing and what needs adding [11:28] i'm sure we'll be pinged to check if its supposed to work ;) [11:28] 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] 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] ah, BuildLiveCD needs to be updated to default to karmic [11:31] on the buildds? [11:31] yes [11:32] it's clearly already been done on some of them [11:32] 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] cjwatson: it was only done on i386/amd64; I've done the rest now [11:35] (lpia, hppa, powerpc, sparc, ia64 and armel) [11:35] * ogra hugs elmo === dpm_ is now known as dpm === davmor21 is now known as davmor2 [13:04] Keybuk, blkid ? i thought using it was a bad thing because of the chache it uses [13:05] (/me sees the initramfs-tools upload) [13:06] it doesn't anymore [13:06] it now looks in /dev/disk/by-uuid etc. instead [13:06] ah, great [13:06] so it doesnt matter what i use ? or should my scripts also switch over ? [13:07] you should use blkid [13:07] ok [13:08] thanks [13:10] elmo: cool, thanks [13:46] superm1: could you change 'include platform.jaunty' in lp:~mythbuntu/ubuntu-seeds/mythbuntu.karmic/STRUCTURE to 'include platform.karmic', please? [13:48] Keybuk,pitti: are either of you chasing up the linux-libc-dev asm/ bug? [13:49] 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] and building the package with 'fakeroot debian/rules build' works [13:51] Ampelbein: what release? [13:52] cjwatson: karmic [13:52] cjwatson: and jabberd2 version is 2.2.1-1.1ubuntu1, grabbed from the source-package's page. [13:53] Ampelbein: probably due to linux-libc-dev being totally busted at the moment in karmic then - it's missing /usr/include/asm/ [14:01] seb128: can you take a look at bug 372833 please? [14:01] Launchpad bug 372833 in pidgin "Pidgin doesn't show all MSN smileys using msn-pecan protocol" [Undecided,Confirmed] https://launchpad.net/bugs/372833 [14:02] the sponsor team seems to be subscribed it will get reviewed [14:02] I'm attending a sprint right now and I'm too busy to do reviews [14:03] is there anything specially urgent there than you ping on IRC? [14:04] seb128: no, don't worry [14:05] commented on the bug [14:05] I'm not sure where this list come from but there should be an upstream pointer there [14:05] that will not change in jaunty and if the next pidgin version fixes the bug mentioned that will be fixed in karmic [14:06] cjwatson: I am looking at bug 373214 right now [14:06] Launchpad bug 373214 in linux-ports "/usr/include/asm/* is not present in linux-libc-dev" [Critical,In progress] https://launchpad.net/bugs/373214 [14:07] amitk: thanks [14:07] discussion on #u-k [14:07] cjwatson: thanks! that was indeed the problem. i reverted the version in the pbuilder-chroot and now it works. [14:10] mumble, nautilus-share FTBFS on lpia and arm ... [14:10] ah, its gnomecanvas [14:11] and gnomeui [14:11] * hyperair hears nautilus-share [14:12] seb128: replied, thanks [14:14] cjwatson, sure. switched. thanks for reminding [14:14] hmm... === rickspencer3-afk is now known as rickspencer3 [14:14] * ogra gives back nautilus-share on armel [14:15] /usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory [14:16] this is the error on ppc. [14:16] ogra: while that particular error is fixed, there's really not much point giving stuff back right now [14:16] the linux-libc-dev bug means that lots of builds are completely busted [14:17] 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] hyperair: ^- this isn't just you and it's being investigated [14:18] cjwatson: that's from the build log [14:18] hyperair, right and its being worked on [14:18] i see [14:19] mvo, any idea about http://launchpadlibrarian.net/26407435/buildlog_ubuntu-karmic-armel.python-apt_0.7.10.3ubuntu1_FAILEDTOBUILD.txt.gz ? [14:19] ln -sf ../../../../javascript/jquery/jquery.js debian/python-apt/usr/share/doc/python-apt/html/_static/jquery.js [14:19] ln: creating symbolic link `debian/python-apt/usr/share/doc/python-apt/html/_static/jquery.js': No such file or directory [14:20] ogra: impressive, I have seen something similar yesterday for debian-installer [14:20] oh, wait there is a former error further up [14:20] ogra: the package in jaunty seems to be ok, but a recompile seems to be not ok [14:20] Exception occurred: [14:20] File "/usr/lib/pymodules/python2.6/debian_bundle/debian_support.py", line 25, in [14:20] import apt_pkg [14:20] ImportError: /usr/lib/libstdc++.so.6: undefined symbol: __sync_val_compare_and_swap_4 [14:21] hrm [14:22] hyperair: yes, we're aware [14:22] right === asac_ is now known as asac [14:30] ogra: I log into the porting machine to have a closer look, but that looks pretty strongly like a libstd++/g++ issue [14:30] mvo, seems totem has the same prob ... so its /usr/lib/libstdc++.so.6 [14:30] /usr/lib/libstdc++.so.6: undefined reference to `__sync_lock_test_and_set_1' [14:30] /usr/lib/libstdc++.so.6: undefined reference to `__sync_sub_and_fetch_4' [14:30] /usr/lib/libstdc++.so.6: undefined reference to `__sync_lock_test_and_set_4' [14:30] /usr/lib/libstdc++.so.6: undefined reference to `__sync_add_and_fetch_4' [14:30] /usr/lib/libstdc++.so.6: undefined reference to `__sync_val_compare_and_swap_4' [14:30] /usr/lib/libstdc++.so.6: undefined reference to `__sync_fetch_and_add_4' [14:30] collect2: ld returned 1 exit status [14:30] ^^^ from the totem log [14:31] ogra: cjwatson had a similar one with debian-installer too [14:31] hmm [14:32] is there a way to suppress or preseed options to "dpkg --configure" when using "apt-get install" in a script? [14:32] mweichert: what problem do you try to solve this way? [14:34] 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] cjwatson: I'll file a bug about it and talk to the kernel team [14:35] mweichert: thanks, sorry I don't know a great deal about the installer preseeding [14:36] pitti, happening already bug 373214 [14:36] mvo, ok, thanks for your help. Though my questions is more about dpkg/apt-get then preseeding. [14:36] ogra: ah, thanks [14:36] Launchpad bug 373214 in linux-ports "/usr/include/asm/* is not present in linux-libc-dev" [Critical,In progress] https://launchpad.net/bugs/373214 [14:36] doko, any idea about the /usr/lib/libstdc++.so.6 stuff above ? [14:37] 15:14 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] needed ... [14:38] 15:15 ah, is that why apt-ftparchive is busted [14:38] 15:45 cjwatson: yes, likely [14:38] 15:46 I hate symbols files for C++ libs [14:38] cjwatson, TA ! [14:38] mweichert: there is "-o Dpkg::Post-Invoke" [14:38] mvo, oh - I'll take a look at that. [14:38] ogra: you could use the debs from rimu:~doko/gcc/install [14:39] doko, i'm checking whats missing to build a livefs on armel atm i guess that wont help much :) [14:39] just looking at the broken deps etc, if it gets fixed in the archive within the next 6 days i'm fine [14:39] ogra: not really, lamont is currently working on the manual build [14:40] good then, thats enough [14:43] james_w: I was thinking about something more productive ;-) [14:43] I guess I'll just have to create one [14:43] apachelogger: can you explain a bit more about what you want to achieve? [14:44] james_w: branch all the kde packaging branches to /jaunty for SRU use [14:44] ah, ok [14:44] I don't think there is anything pre-canned [14:45] james_w: well, shouldn't be a problem to enhance our existing batch-action-script to do that as well [14:45] thanks anyway :) [14:46] do you really want to pre-populate the branches? [14:46] wouldn't use just branch when you first want to do something with an SRU? [14:50] 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] true === Nicke_ is now known as Nicke === quadrispro1 is now known as quadrispro [15:49] hi all [16:15] 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? === dendrobates_ is now known as dendrobates === ashayh is now known as ahuman === ScottK2 is now known as ScottK === robbiew is now known as robbiew-away === awe is now known as awe-lunch === awe-lunch is now known as awe [18:30] hello, is the quagga maintainer here? [18:30] -> #ubuntu-server, probably. [18:38] thank you [18:51] hello, I'm experiencing freezes on jaunty with gksu2.ask_password_full() (python stuff). everything worked on Intrepid. any clue ? [18:58] hi [18:58] I was wondering, are we getting 180.51 nvidia drivers in the repos any time soon? [18:59] I'm having numerous issues with memleaks, could help testing the new drivers on 64bit too. [18:59] running jaunty. [19:09] calc: out of pure curiousity, are the OOo3.1 jaunty packages in ~openoffice-pkgs PPA usable? [19:11] maybe there's a ppa about nvidia drivers too? [19:11] imachine: the x-updates PPA you mean? [19:12] calc: well I guess the two FTBFSes answer my question :) [19:17] es! [19:17] jdong, just found it ;-P [19:17] thanks ;-) === robbiew-away is now known as robbiew [19:58] jdong: hmm? [19:58] jdong: well the ooo-l10n ftbfs yea [20:13] calc: just saw the same gcj "libgcj.spec: no such file or directory" error on an amd64 build [20:16] seems that the .spec file has moved from libgcjNN-dev to gcj-4.4-jdk? [20:17] sbeattie: hi - re bug 326768 - I'd rather not get this update go to -updates for now [20:17] Launchpad bug 326768 in mysql-dfsg-5.0 "mysqld_safe thinks mysqld has crashed when it hasn't" [Undecided,Confirmed] https://launchpad.net/bugs/326768 [20:17] sbeattie: it has already landed in -proposed [20:17] 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] sbeattie: I've remove the verification-needed tag and set back the bug status to confirmed [20:18] sbeattie: however I cannot unsubscribe ubuntu-sru and the sru-verification team [20:18] sbeattie: is there anything else I should do? [20:19] mathiaz: do you still want it in -proposed? [20:19] sbeattie: it's already in -proposed [20:19] sbeattie: I'd rather not get it in -updates [20:20] mathiaz: I'm asking do you want it pulled from proposed? [20:21] sbeattie: ah - yes if that's possible === rickspencer3 is now known as rickspencer3-afk [20:24] slangasek: ^^^ [20:25] mathiaz: you could set the 'verification-failed' tag? [20:25] or is that not actually the issue? [20:32] slangasek: well - technically it's not a verification failed - the proposed solution fixes the symptoms [20:33] slangasek: however I'm not confident enough to push it directly to -updates [20:33] slangasek: I'd have more time to spend debugging the issue [20:34] slangasek: so I wanna make sure it doesn't get in -updates by mistake [20:34] 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] slangasek: ok - I'll use the verification-failed tag [20:35] 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] It depends on how the PPA pacakge is versioned, but generally you miss the security fix. [20:38] are security fixes using the same incremental counter as SRU's ?? [20:38] for example if the current SRU version is BLAH.2 will a security fix be called BLAH.3 then? [20:38] mnemo: generally, yes. [20:39] ok [20:39] 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] slangasek: yea i thought it might have been somehow related to the linux-libc-dev mess, but i am not sure [20:40] I can't imagine why that would be the case [20:41] anyway, your comments were before the broken linux-libc-dev got published, AFAICS [20:41] 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] "the cups issue"? [20:41] slangasek: cups headers can't be "found" now for several archs [20:42] url? [20:43] 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] slangasek: same thing happens for me when i try to build it on i386 [20:43] 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] calc: yes, that's almost certainly just linux-libc-dev [20:44] ok [20:44] i'm not sure what the issue is with the armel OOo build failure [20:45] it claims unixodbc-dev can't be installed [20:46] 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] 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] calc: unixodbc-dev> another instance of a package winding up in the wrong section out of NEW, WTF [20:51] ah [20:51] (http://people.ubuntu.com/~ubuntu-archive/architecture-mismatches.txt) [20:52] so i only have on real failure issue to look into, thats much better :) [20:52] 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] slangasek: each architecture should show up in NEW separately [20:53] (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] kirkland: yesterday was your archive day; do you recall putting a libtool-dev package through NEW on armel? [20:59] kirkland: libltdl-dev, rather [21:00] slangasek: i did work on archive stuff yesterday, spent my whole day doing sync's, didn't get to any NEW's [21:00] ok [21:00] slangasek: need help with something? [21:00] Riddell: did you do any NEWing yesterday? [21:01] 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] slangasek: hmm, sorry, i don't know [21:02] given that it's happened all of a sudden, I really suspect (worry) that it's a soyuz behavior change [21:05] 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] slangasek: any idea where i need to request that? [21:06] packages don't get renamed [21:06] slangasek: just file a bug, and subscribe arch admin? [21:06] you upload a new one under the new name [21:06] slangasek: okay, i did that [21:06] slangasek: and it's in the new queue [21:06] then whoever processes NEW next will get it [21:06] slangasek: oh, okay, that's surprisingly easy === rickspencer3-afk is now known as rickspencer3 [21:41] 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] slangasek: I don't think I even have an account on the appropriate machine anymore [21:41] slangasek: I did not do any. [21:42] mdz: can be done through the web interface these days, but ok :) [21:42] slangasek: ooh, shiny [21:43] slangasek: not I [21:44] or even me... [21:46] slangasek: nope [21:48] is there a channel for Ubuntu re-branding and derivatives? [21:48] slangasek: yes that was probably me [22:01] Riddell: ok - just trying to get a handle on why all these NEW binary packages have been landing in universe [22:02] dear oo.o, more, smaller packages. srsly. kthx [22:02] 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 === maco_ is now known as maco [22:18] 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] yay [22:18] I see my morning going wonderfully manual [22:22] 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] hooray for no-change uploads, eh? [22:23] I'm sure the kernel guys have something to put in there [22:23] 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] the always do [22:23]