[04:00] Who do I need to annoy to get bug #369203 fixed? [04:00] Launchpad bug 369203 in python2.5 "Python2.5.4 curses.initscr() fails" [Undecided,Confirmed] https://launchpad.net/bugs/369203 [04:24] ebroder: Is there a patch and a test case? [04:25] Sure. The patch is attached in my comment. The test case is `python -c 'import curses; curses.initscr()'` [04:25] I can edit the bug description to more clearly link to my patch if you'd like [04:29] * ScottK didn't open the bug. Let me look. [04:31] doko: What do you think about the proposed fix in 369203? [04:31] Let's wait a bit and see what that brings us. [04:31] Sounds good === johe__ is now known as johe === CarlFK1 is now known as CarlFK [06:10] Good morning everyone! end of holidays, at last :) [06:11] Hey pitti! [06:13] hey TheMuso, how are you? [06:14] pitti: Well thanks. [06:15] anyone know the quality of the ati HD3450? [06:15] I'm looking at a new laptop and can have either this or on-board intel [06:15] wondering about upcoming KMS [06:19] bryce: if you read the scrollback, ATI radeon hd 3450, good or not, KMS? [06:39] good morning [06:53] good morning dholbach [06:53] heya highvoltage! [06:53] had a good weekend dholbach? [06:53] absolutely - we had some friends here from Austria [06:54] how about yours? [06:54] heh, I watched Sound of Music again Saturday afternoon, so saw some old Austria scenes and got an Austria fix as well [06:54] haha :-) [06:55] visited that computer lab in that poor area I told you about saturday morning, it was going better there than I expected. it was nice seeing it in use, there was a class running on how to use gmail and search things on the internet. [06:56] cool - so they had no specific complaints? [06:58] nope, there was a few computers that weren't set to boot from the network and that's why they weren't working, so I just showed them how to set the bios settings and that already fixed most of their problems [06:59] I got the relevent contact details, I'll put them in touch with the ngo-interviewers [06:59] rock and roll :) [07:21] In Bug #416778 lool has requested some further public discussion on including the Jack audio server in Main. I'm not sure where to initiate that discussion, is here appropriate? [07:21] Launchpad bug 416778 in libffado "main inclusion request for libffado" [Undecided,Incomplete] https://launchpad.net/bugs/416778 [07:21] or is the bug tracker the best place for that conversation? [07:22] stochastic: ubuntu-devel-discuss@lists.ubuntu.com would be my suggestion === tkamppeter_ is now known as tkamppeter [07:33] pitti, hi [07:33] <\sh> moins [07:37] hi tkamppeter [07:37] tkamppeter: BTW, we can change the pdftoopvp enabling to be an Ubuntu specific patch, then we can add it to the Debian trunk and drop the Ubuntu branch again [07:37] I'll do that soon [07:45] pitti, OK [07:47] pitti, I have discovered that CUPS now does not only have 2 libs (libcups, libcupsimage), but 4 new libs added (libcupscgi, libcupsdriver, libcupsmime, libcupsppdc). Do we need 8 additional binary packages (including -dev) now? [07:47] could someone please have a quick look at http://launchpadlibrarian.net/30714313/zlib_1.2.3.3.dfsg-13ubuntu2.debdiff if that looks ok? [07:47] (context is bug 402178) [07:47] Launchpad bug 402178 in zlib "gzopen64 implicitly converted to pointer" [Undecided,New] https://launchpad.net/bugs/402178 [07:50] tkamppeter: I think for now we can probably keep them in libcups, unless they have different SONAMEs (or likely to get different ones in the future) [07:51] tkamppeter: ah, just saw your 1.4 updates [07:51] libcups has SONAME 2, all the new ones SONAME 1. [07:52] That sounds like the SOVER, not SONAME [07:54] tkamppeter: then the new ones need a new package [07:54] StevenK: SOVER? [07:54] I have done everything to make the new CUPS build: adapted patches, taken a patch from Red Hat to make the new dnssd backend build (the original uses an API which is probably not available under Linux), adapted the PDF filter package to work with both 1.3 and 1.4, fixed small bugs in the new CUPS, ... [07:55] StevenK: pitti called this SONAME in a conversation with robert_ancell on #ubuntu_desktop. [07:55] tkamppeter: thanks muchly [07:57] pitti: Remaining is now to obsolete cupsddk and to distribute the files to the binary packages of CUPS and to package all the new libraries. [08:08] pitti, if you make a conditional patch to solve the pdftoopvp problem, can you make it in a way that it applies only to Debian and not to Ubuntu, this way one can have the debian/local/filters/pdf-filters being exactly the upstream tarball. [08:09] tkamppeter: yes, I can also do it the other way around ("disable-pdftoopvp.dpatch") [08:09] tkamppeter: I won't actually check for "Ubuntu", I'll check the version number of poppler [08:09] pitti, hmm... I have devicekit-disks 006-0ubuntu1 installed, but I still get the dialog that wants me to mount an unmounted partition on my hard disk [08:10] liw: right, that's expected; gvfs doesn't yet use the new "no interactive" option [08:10] there's a gvfs task still open [08:10] pitti, ok, then I'll wait some more [08:10] pitti, this is even better [08:12] lool: Hey. Thanks for your work on euca2ools! [08:13] lool: The binary depends on pyton-boto 1.8a, but we're at 1.7c. Can you sync 1.8a from Debian? [08:13] soren: he can't, but I can [08:13] pitti: Oh, lovely. Thanks! [08:13] * soren thought lool was archive admin [08:14] He's in ubuntu-mir, but he isn't an archive admin [08:14] Ah. [08:14] * soren is having trouble keeping up with people's hats. [08:15] is there a tool to compare two versions of the same lib*.so and see if there are changes in the exported symbols? [08:16] liw: hm, diff the nm -D output? [08:17] or use check-symbols from the ubuntu-dev-tools package? [08:17] pitti: \o/ Thanks for the boto sync. [08:17] soren: de rien [08:17] nm -D | cut -d' ' -f3 | sort -u > lib1; nm -D | cut -d' ' -f3 | sort -u > lib2; diff -u lib1 lib2 [08:18] dholbach: do you know bash's <() trick? [08:18] diff -u <(nm -D ...) <(nm -D ...) [08:18] how'd you rephrase it? [08:18] ah [08:19] * dholbach needs to try that [08:19] pretty handy to work without creating temporary files [08:19] <(command) runs command in a pipe and its stdout becomes a file name-like argument [08:19] although the mighty slangasek says that objdump -T or readelf -s would be better than nm -D [08:20] https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/184906 [08:20] Launchpad bug 184906 in ubuntu-dev-tools "check-symbols should use something other than nm -D" [Wishlist,Confirmed] [08:20] * pitti bows to slangasek's ELF skills [08:22] remember to pass -W to 'readelf' - otherwise long symbol names can get cut off! [08:23] . o O (nothing is ever easy with shared libs, is it?) [08:24] probably best to just read the diff ;-) [08:57] pitti, any suggestion about the library packaging for CUPS? [08:57] tkamppeter: as I said, if they have a different soname, they need a new package [08:58] tkamppeter: will any other program actually use these libraries, though? [08:58] pitti, that is the case. [08:59] pitti, currently most probably not. [09:03] soren, pitti: I had filed a sync request saturday though [09:09] lool: I wonder why I didn't see that.. [09:10] lool: Oh, right, I decided not to wait for Launchpad to load because I (mistakenly) "realised" that you were an AA and could have done it yourself if you wanted. [09:11] soren: I think I saw no subscriber to euca2ools bugmail either [09:11] lool: No, I hadn't gotten around to that yet. [09:12] (it was only synced on Friday) [09:12] I mean that explains you didn't see the sync bug [09:12] Oh, right, right. [09:12] I sent the changes to the euca folks in the changelog and at the top of /Makefile BTW [09:13] Didn't get any answer yet but that was over the WE [09:25] slangasek: what is your opinion on bug #414943 ? do you think its important enough to add code to update-manager to check for this situation (that the user has a old kernel as default in his grub.cfg?) [09:25] Launchpad bug 414943 in update-manager "update-manager/grub should warn about old kernels ahead of the automatically generated ones" [Low,Triaged] https://launchpad.net/bugs/414943 === dholbach_ is now known as dholbach [10:27] mvo: thanks for clearing up that lsb_release bug! [10:31] cjwatson: my pleasure :) === Guest77631 is now known as Zic [11:27] pitti, what about creating packages libcups-extra1 and libcups-extra-dev for the 4 extra CUPS libraries? [11:28] tkamppeter: they all have soname 1? "extra" sounds a bit weird, maybe pick one of the existing names? [11:29] They are all of soname 1, but picking one of the lib names is also not good, they are completely different. [11:29] tkamppeter: however, I don't really like "extra", it's a hack; either we put them all into an existing package, or we should package them properly [11:30] putting them into "cups" is bad, as then a program only needing one of the libs would pull in the CUPS daemon. [11:30] tkamppeter: there's no way to statically link them to cupsd, until other programs actually need them? [11:30] well, other binaries might need them as well [11:30] seems there's no really good way of avoiding 4 new libs :/ [11:30] pitti, they can also be used by CUPS clients on a daemon-less server [11:31] right [11:31] Or by PPD-generating programs, imagine the CUPS daemon would run on OpenPrinting, only because there is a program generating driver packages. === thumper is now known as thumper-zzz [11:36] pitti, now I discovered that there is a package named cups-common, I could put the libraries there. [11:37] tkamppeter: no, that's arch:all, and not meant for libraries [11:37] tkamppeter: let's just package them properly instead of wasting time on ugly and policy breaking hacks which we'll need to fix later anyway [11:37] pitti, I could switch that to arch:any [11:38] once one of the libs changes ABI, it would break everything [11:38] So I will make real library packages. Even if these libraries are not meant as API libs for apps, sooner or later someone will use them and then we have to change our packages to avoid side effects. [11:43] pitti, hey, what is supposed to provide IRC in the default install ? testing my armel images i cant find anyone [11:43] s/anyone/anything/ [11:44] * ogra wonders if armel is missing something, given that much of out user support is centered around IRC i cant imagine we dont have it by default [11:46] ogra: we don't have IRC right now; we'd need to install telepathy-idle for that [11:46] it's a known issue [11:46] you can install it in the live system, of course [11:46] * pitti -> lunch [11:46] pitti, but we'll pull it in ? [11:46] (later) [11:46] ogra: probably, yes [11:47] i would see it as a large regression to not have IRC by default [11:47] enjoy your lunkc, thanks [11:47] *lunch [12:18] Is there any way to retry a build which was attempted on a previous release, short of an upload? [12:20] Laney: you mean as in binNMU? [12:20] no, there was an FTBFS which was attempted in Jaunty [12:20] I was wondering if it could be tried again under Karmic [12:21] give-back [12:21] Laney: ah, no idea actually then [12:22] err, it ought to have had a karmic build record created, I'd've thunk [12:22] ask #launchpad? [12:23] doesn't seem to have [12:23] * Laney moves over there [12:47] does anyone see a reason why Arch: all packages wouldnt be built with a debian/control like: http://paste.ubuntu.com/258590/ [12:48] debian/rules is relevant too [12:48] well, rules is pretty empty [12:48] Hello, does anyone here know anything about the nvidia drivers in karmic a4? [12:48] http://paste.ubuntu.com/258615/ [12:49] For some reason, 185.18.31, 185.18.36 and 190.x.x give me artifacts, then system crashes (laptop resets itself). [12:49] ogra: debian.mvl-dove/rules then [12:49] follow the yellow brick road [12:50] I had to revert to 185.18.14. [12:50] You're speaking in riddles to eachother:O [12:50] http://paste.ubuntu.com/258616/ [12:50] not especially [12:50] right, the dove rules are a bit more intresting :) [12:51] ogra: now you need to find which of the included files defines the binary-indep target [12:51] It is an NVidia GeForce 8400M GT, inside of a Sony Vaio VGN-AR41E laptop [12:53] Cyberkilla: I don't know anything about this but perhaps generic advice is better than nothing. https://wiki.ubuntu.com/X/Reporting has general advice on reporting good-quality X bugs that contain a decent amount of information, and links to some pages with more details. #ubuntu-x may have more experts paying attention, although not necessarily right at this moment [12:53] Thanks a lot. I appreciate your response: ) [12:54] hmm, looks ok to me, it properly calls the dbheper commands with -i ... unless the package names dont get handed over i dont see why it wouldnt even attampt a build [12:55] though, hmm, i wonder if the "build-indep:" at the top prevents it somehow [12:55] http://paste.ubuntu.com/258619/ [12:56] pitti: are you ok if i upload the calibre stuff i've done? [12:56] seems to be an empty target [12:57] stefanlsd: sure; I need to commit all the changes back to the debian bzr branch anyway, a couple of more changes don't make a big difference [12:58] stefanlsd: we should have an Ubuntu branch probably, since I can't upload 0.6 to Debian right now (blocked on doko's magic --install-layout=deb change in python2.5)_ [12:59] pitti: ??? [12:59] pitti: ok, great. wont we get a branch now with james_w import stuff anyways? [12:59] oops, sorry, that was meant to be "2.6 available in experimental" [12:59] doko: sorry, the --install-layout=deb change was just blocking the cdbs distutils.mk fix [13:00] not calibre [13:00] stefanlsd: yes, but please don't use it [13:00] for packages which already have a bzr branch, the auto-import stuff is pretty useless [13:01] ahh, ok === MacSlow is now known as MacSlow|lunch [13:02] ogra: build-indep is probably irrelevant [13:02] well, the main file calls it, but comparing to the generic kernel package its identical [13:02] ogra: I suggest setting DH_VERBOSE=1 and going through the output with a fine tooth-comb [13:03] well, thats more than i want to do personally, its actually rtg's package, but he is "fixing" it by just dropping all Arch: all packages, i thought i could find something obvious to suggest [13:04] i dont mind losing Arch:all -headers ... and -docs should be identical to the mainline kernel anyway [13:05] -source concerns me a bit if users want to cross build kernels for armel SoCs though [13:05] I sympathise but am unlikely to have a chance to figure this out, sorry [13:06] of course the debhelper commands that are called with -i are not the only relevant parts; you need to make sure that something is actually installed into the package build directories too [13:06] yeah, i would have asked "cjwatson can you help with ..." if i really wanted you to help solving it ;) thanks a lot for the pointers though :) [13:07] dont want to keep you from your actual work ;) [13:07] i'll discuss with rtg [13:07] that's ok, I just wanted to make it clear that I was disengaging rather than just going silent :) [13:23] slangasek, rtg claims the "Arch: all" packages of linux-fsl-imx51 were not built because you objected, i dont see how you would technically have been able to prevent them from building nor why they wouldnt have at least been in the NEW queue, can you tell me anything about that ? === rmcbride_ is now known as rmcbride4 === rmcbride4 is now known as rmcbride [14:01] pitti, which maintainer scripts are needed for library packages? AFAIK one has to call "ldconfig" after installation and after removal. Or is this done automatically, without needing an explicit maintainer script? [14:01] tkamppeter: don't add explicit scripts, dh_makeshlibs will care about it [14:02] pitti, then I can perhaps remove some superfluous scripts from the CUPS package. [14:02] dh_makeshlibs> assuming that you have the #DEBHELPER# token in any explicit maintainer scripts you do have in the source package [14:03] (obviously if you don't have explicit maintainer scripts in the source package then there's no need to add them just for #DEBHELPER#) [14:04] pitti, debian/libcups2.postinst and debian/libcupsimage2.postinst do nothing more than providing #DEBHELPER#, so they can get removed. [14:05] tkamppeter: correct, they are just cruft === MacSlow|lunch is now known as MacSlow === rickspencer3-afk is now known as rickspencer3 [14:34] pitti: hi, I've replied to that bug about tor [14:54] Hey who's administering http://qa.ubuntuwire.com/ ? [14:54] I'd like to get a package or two installed to fix http://qa.ubuntuwire.com/uehs/no_updated.html [14:54] It's lacking the perl ssl support libs to use https [14:58] lool, i think that was siretart once, not sure thats still true though [14:58] lool: you can ask at #ubuntuwire or write a mail to admin@lists.ubuntuwire.com [15:00] lool: or ask wgrant [15:00] sistpoty|work: thanks [15:00] Too many people to ask :) [15:00] I prefer shooting an email [15:00] heh :) [15:01] why ? many people means many options to pick your favorite answer *g* [15:01] or many possibilities to say "no, I'm not responsible..." *g* [15:11] Riddell: heh, in Africa, "eina" means "ouch" [15:11] (just saw it coming through karmic-changes) [15:13] pitti, is bug 418097 really a CUPS bug? [15:13] Launchpad bug 418097 in cups "package cups-client 1.3.11-1ubuntu6 failed to install/upgrade: trying to overwrite `/usr/share/doc/ia32-libcups2/changelog.ia32-libs-tools', which is also in package cups-bsd" [Undecided,New] https://launchpad.net/bugs/418097 [15:14] pitti: Or is it of ia32-libs providing 32-bit libcups2? [15:15] tkamppeter: looks like an ia32-libs bug; cups itself doesn't build 32 bit libs on amd64 === dyfet` is now known as dyfet [15:33] pitti: hi, if only for hardy to karmic, or rather say in 4-5 releases, I can do it. === cprov is now known as cprov-lunch === The_Company is now known as Compant === Compant is now known as Company [16:37] NCommander: ping [16:37] NCommander: what's the status with the kvm backports to hardy/intrepid ? [16:37] NCommander: those have been sitting there for a while, now [16:40] kirkland, let me check, libvirt should have gone through, its been in the NEW queue for awhile [16:42] kirkland: I just took a glance at qemu-kvm... are the sources of the bios files in pc-bios somewhere in the package? I can't find the source for openbios-* for example [16:44] sistpoty|work: lemme check [16:44] kirkland: thx [16:45] sistpoty|work: i'm just responding to your email about qemu-kvm on -devel [16:46] kirkland: cool, thanks :) [16:46] sistpoty|work: thanks for looking at that package; i *welcome* more eyes on it :-) [16:46] sure thing, no problem ;) [16:48] sistpoty|work: the source is at http://www.openfirmware.info/OpenBIOS, though upstream qemu is releasing those as blobs in 0.11 [16:49] /join #python [16:49] nice! :) [16:49] kirkland: hm... that's gpl-2, right? can we distribute it that way in ubuntu then? [16:51] sistpoty|work: hmm, well qemu is GPLv2 and LGPL [16:51] cjwatson, any archive admin, can you please promote the linux-mvl-dove udebs so d-i can build? The kernel itself got kicked to main, but the udebs are still in universe [16:51] kirkland: yep, but I mean the bios... don't we as ubuntu have to make the sources available or offer s.th. written then? (I'm no licensing expert though) [16:52] NCommander: done [16:53] cjwatson, thanks, I'll have a revised branch that has been fully test built for you ASAP [16:54] ScottK: looks ok [16:54] doko: Thanks. [16:54] sistpoty|work: hmm, i'm not sure about that one ... qemu and kvm have always shipped at least some bios.bin's as prebuilt bios blobs; I'll have to check under what conditions this has been approved in the past [16:55] kirkland: I think if the source from which a prebuilt blob is available in the package, that would work... but as I wrote, I don't have too much clue with legalize ;) [16:56] is available along with the blob even. [16:57] sistpoty|work: so you're suggesting I grab that source, and drop it in the debian dir and debian/copyrights for good measure? [16:57] kirkland: yes, but the tough thing is to make sure that it matches the blob. and I'm suggesting to ask someone who knows for sure ;) [16:58] sistpoty|work: the other option is to add --disable-blobs to the ./configure optiosn [16:58] kirkland: and to remove it from the source tarball, yes, if it's still working then [16:59] sistpoty|work: well, it would break some of qemu's arches, IIUC [16:59] <_sick> anyone knows if the idb (intel debugger) works with the gdb machine interface ? [17:00] kirkland: hm... :/ [17:00] sistpoty|work: talking with the qemu maintainers privately right now, they feel that they're covered, because one of the qemu maintainers is also an openbios maintainer === marjomercado is now known as marjo [17:00] sistpoty|work: and their intention is to ship the source of the openbios blobs in 0.12 [17:01] kirkland: oh, cool :) [17:01] sistpoty|work: but 0.12 is karmic+1 [17:01] sistpoty|work: they're in 0.11-rc1 right now ... i just asked if they'd add the openbios sources to -rc2 ... discussing now [17:04] sistpoty|work: qemu upstream says shipping those sources in -rc2 is probably not going to happen; i'd need to drop them in our package [17:07] jdstrand: bug 407428 - this is a hard one [17:07] Launchpad bug 407428 in openssh "sshd zombie processes and strange behavior after karmic upgrade" [High,Confirmed] https://launchpad.net/bugs/407428 [17:07] mathiaz: yes it is. I haven't found a reproducer yet [17:07] mathiaz: I've tried for some time, off and on [17:08] jdstrand: yeah - I run into this one all the time [17:08] me too [17:08] jdstrand: when I clone vm [17:08] jdstrand: and they start for the first start, I run into this issue [17:08] jdstrand: but I haven't been able to reliably reproduce it [17:08] mathiaz: does it happen every time you clone a vm? [17:08] jdstrand: yes [17:09] jdstrand: if I reboot the vm, it's gone - sometimes [17:09] mathiaz: maybe the bug can be triggered when ssh notices a new interface and starts listening on it [17:09] mathiaz: oh, in the vm or the host do you see this? [17:09] jdstrand: in the vm only [17:09] ok, nm my comment then [17:16] pitti, I have completed the packaging of CUPS 1.4.0 now. [17:18] pitti, can you now add the conditional patch for deactivating pdftoopvp in Debian and then upload the resulting package to Debian and Ubuntu. Thanks. [17:18] tkamppeter: great, thanks! [17:18] tkamppeter: yup, on my list [17:23] pitti, another problem is that we now have to blacklist the usblp kernel module. How should this be done? Should CUPS add a config file to /etc/modules.d for doing that or should it simply be part of the default configuration for the kernel modules? [17:24] With the module loaded the "usb" CUPS backend does not see any printer. [17:25] tkamppeter: blacklist? why? [17:25] tkamppeter: oh, so that the module doesn't grab the raw device? [17:26] tkamppeter: ideally we'd just not build it at all in the kernel [17:26] tkamppeter: but that's an issue in Debian as well then [17:26] pitti: Yes. [17:26] it just seems like a bad design to me, though [17:27] tkamppeter: I guess for now we need to add it to the default blacklist in module-init-tools, yes [17:27] pitti, OK. [17:27] ok, need to run (dinner and Taekwondo), see you all tomorrow! [17:28] pitti, it is really a bad design, a good usb backend would work both with and without usblp kernel module. [17:32] cjwatson, publisher runs every hour, on :03, right? [17:39] Last I heard publisher runs were taking over an hour to finish though (this may have been fixed). === cprov-lunch is now known as cprov [17:43] james_w: hey - are you going through the NEW queue? [17:43] james_w: and rejected merb? [17:43] yeah [17:43] NCommander: yes [17:44] cjwatson, hrm, then the udeb should be in main now, no? [17:44] james_w: the reason for rejection was the inclusion of spec testing? [17:44] mathiaz: I rejected it as I sponsored a newer version in to NEW [17:44] james_w: oh - cool [17:44] james_w: does this mean that merb has been accepted now? [17:44] cjwatson, I'm just wondering if udebs are special w.r.t. to promotion and such [17:45] ScottK: that was fixed - they're down to a bit over half an hour now - but the publisher is crashing [17:45] cjwatson: Thanks. Good to know (the fixed part anyway). [17:45] NCommander: they're not special, the publisher's crashing [17:45] cjwatson, oh. bah :-/ [17:45] cjwatson, sorry for the noise, I was just wondering what was going on [17:46] mathiaz: no [17:46] mathiaz: I don't have time to complete the review today [17:47] james_w: ok - so there is a new version of merb in the NEW queue that fixes the issue you've found? [17:47] yeah [17:47] james_w: but you won't have to process the NEW queue today? [17:47] it's a repacking to remove all the embedded code [17:47] well, I've spent a few hours on it today [17:47] so it's that I want to do some other things today [17:47] james_w: sure :) [17:48] james_w: thanks for sponsoring a new upload of merb :) [17:48] np [17:48] jtimberman: ^^ - so your last upload to REVU for merb is already in the NEW queue (ie has been sponsored by james_w) ? [17:49] Guess so, I haven't seen an email about that from the system. [17:49] it is [17:49] mathiaz: i fixed the issue it was rejected for, and a new issue james_w found. [17:50] does that mean it still needs archive admin review and upload to the universe? [17:50] yeah [17:51] https://edge.launchpad.net/ubuntu/karmic/+queue [17:51] Ahh === beuno is now known as beuno-lunch [17:52] oh, stompserver is in the queue. [17:53] jtimberman: right - merb and stompserver are already in the queue [17:53] jtimberman: and chef needs another advocation [17:53] jtimberman: ^^ is that accurate picture of the chef packaging effort? [17:54] jtimberman: coderay and libsyntax are available in karmic [17:54] mathiaz: stompserver was rejected on Friday and I uploaded it fixed on REVU, is the one in the queue the right one? [17:55] mathiaz: stompserver was rejected, and i uploaded the new version to REVU that fixed the blocking issue. [17:55] mathiaz: i see it as rejected on the queue too, does it need a new upload to NEW? [17:57] jtimberman: meh - I don't know [17:57] jtimberman: the times are all different [17:57] one time zone to rule them all. [17:58] jtimberman: I can't figure out whether I've uploaded the latest [17:58] jtimberman: let me look into that a bit later. [17:58] mathiaz: okay. [18:00] ogra: er, I never said to not build the Architecture: all packages - are we playing telephone, here? [18:00] slangasek, well, something is wrong [18:00] the 300.4 package had three Arch: all packages [18:00] but they werent picked up anywhere for build it seems [18:01] doing a local armel build they appear [18:01] ogra@dove:~/linux-mvl-dove-2.6.31$ ls ../*.deb [18:01] ../linux-headers-2.6.31-200_2.6.31-200.4_all.deb ../linux-image-2.6.31-0-dove_2.6.31-0.1_armel.deb ../linux-mvl-dove-doc_2.6.31-200.4_all.deb [18:01] ../linux-headers-2.6.31-200-dove_2.6.31-200.4_armel.deb ../linux-image-2.6.31-200-dove_2.6.31-200.4_armel.deb ../linux-mvl-dove-source-2.6.31_2.6.31-200.4_all.deb [18:01] ogra: then you're not doing a proper local armel build the way the buildds do. The buildds only build Arch: all packages on the i386 buildd [18:01] i'll try buiulding the package on a i386 machine, but i suspect we hit a soyuz bug or some weird PAS wildcard setting [18:02] yes, i know how our infrastructure works :) [18:02] i did the local build to exclude packaging bugs [18:02] the relevant detail here is https://launchpad.net/ubuntu/karmic/+source/linux-fsl-imx51/2.6.31-100.7 showing only armel in the 'builds' tab [18:02] but our infrastructure seems to not like that setup [18:03] 100.7 has all ARCH: all packages dropped [18:03] that was rtg's workaround for now [18:03] 100.4 and 100.5 had them enabled [18:04] er [18:04] ah, no only 100.4 [18:04] there seem to be no build attempts on i386 for 100.4 [18:04] I don't see why he would have dropped the doc and source packages [18:04] and i think thats either soyuz or PAS [18:05] yes, i wanted to keep -source :( [18:05] (the headers package, yes, I did say there was no point in having the headers split between two packages) [18:05] for people cross compiling the kernel packages === cody-somerville_ is now known as cody-somerville [18:05] i dont care about .docs [18:05] *-docs [18:05] since i assume there is nothing added to the fsl version [18:06] keeping -source would have been nice and i'd like to see it coming back ... [18:06] it doesn't matter whether there's anything added - you want the -docs package built so that the -docs package matches the kernel package and can be pulled in via linux-meta [18:06] anyway, do you have an idea what blocks them from building on i386 ? [18:07] slangasek, well, rtg sees the issue as resolved and i couldnt convince him of the opposite [18:07] ogra: it's not P-a-s, so you'll have to ask soyuz folks [18:07] ok, thanks for looking [18:09] hmm, wasnt there a dedicated soyuz channel ? [18:09] ogra: yes, #soyuz [18:10] on the Canonical Ltd. server [18:10] heh, i meant a public one :) [18:10] doesnt seem like though [18:10] try #launchpad then, and ping cprov :) [18:12] the publisher seems like it might be running again, so we'll see [18:16] cjwatson: hi, is there anything special to watch out for with -di packages in NBS? [18:16] there's a whole bunch in there currently, and I didn't clear them out earlier with the rest as I didn't want to create havoc [18:19] james_w: don't process them yet, I have a d-i upload in the works to move to -6 [18:19] NCommander: are you waiting for this publisher run in order to do a test build? [18:19] so my wariness was well placed :-) [18:20] NCommander: you could just add universe/debian-installer to UDEB_COMPONENTS in build/config/common [18:20] cjwatson, now that the mvl and fsl kernel packages are in main, is there anything special we need to do for d-i to pick them up ? [18:20] cjwatson, ah [18:21] jtimberman: the stompserver package sitting in the NEW queue is the last one you've uploaded to REVU (fixing the issue from the first rejection) [18:21] they both should have the proper naming scheme now [18:21] ogra: stuff like what NCommander's doing for dove, presumably [18:21] mathiaz: cool, thanks for checking! [18:21] well, that had happened for imx51 already [18:21] unless you dropped it :) [18:23] * ogra hugs lamont for ARMv7 buildd love [18:23] and you even doubled the amount !!! [18:24] ogra: 4 -> 6 isn't double. :-p [18:24] one more inbound though - look forward to seeing korlan [18:24] and a rimu replacement [18:24] it was 3 for nearly all of the last 6 months [18:24] and then we get more [18:25] doh. The latest nvidia updates broke my X. [18:25] the fourth one was rarely seen online [18:25] cody-somerville, get proper hardware :P [18:26] ogra, whats considered proper hardware these days? :P [18:26] intel ? [18:26] no thanks [18:26]