[00:10] <barry> lifeless: not sure, but at least as far back as 2.4
[00:10] <lifeless> cool
[01:50] <kklimonda> hmm, interesting - I have a patch in the maverick package that enables launchpad-integration
[01:51] <kklimonda> it doesn't add any additional CFLAGS to the Makefile, and it worked fine during maverick development
[01:51] <kklimonda> but now, that I try to make an SRU compilation fails - it can't find <launchpad-integration.h>
[02:03] <kklimonda> I wonder whether I have broken my maverick pbuilder.. hmm..
[02:03] <kklimonda> oh well, I'll work on that tomorrow
[02:06] <TheMuso> /c/
[05:46] <linuxfreaker> Is 2.6.37 Kernel expected in 11.04 Alpha2
[05:50] <JackyAlcine> I doubt it, linuxfreaker.
[05:50] <JackyAlcine> Maybe 2.6.36 but not 2.6.37
[05:50] <micahg> 2.6.37 is already in natty
[05:54] <linuxfreaker> 2.6.37-rc4 is there in natty, 2.6.37 just released yesterday
[05:55] <micahg> I was commenting on the 2.6.36 vs 2.6.37 comment
[05:56] <micahg> linuxfreaker: rc8 is in now
[05:56] <linuxfreaker> Not rc8...GA already announced
[05:56] <micahg> actually, it's 2.6.37 final https://lists.ubuntu.com/archives/natty-changes/2011-January/004719.html
[05:56] <linuxfreaker> Check the kernel.org
[05:56] <linuxfreaker> I compiled it yesterday..sounds better
[05:56] <micahg> linuxfreaker: it's already in natty :P
[05:56] <StevenK>   * rebase to v2.6.37 final
[05:57] <linuxfreaker> ahh great
[05:57] <linuxfreaker> So does it mean that Alpha2 will have 2.6.37 GA kernel
[05:59] <StevenK> It's in about 3 weeks, but yes
[06:00] <StevenK> Well, Ubuntu doesn't use kernel.org kernels, but it will be based on 2.6.37 final
[06:03] <Keybuk> StevenK: well, we do use kernel.org kernels
[06:03] <Keybuk> we just add things to it
[06:30] <dholbach> good morning
[06:31] <dholbach> bryceh, chrisccoulson: happy new year and happy patch pilot day (if you're back from holidays already :-))
[07:10] <linuxfreaker> I want to raise a bug
[07:10] <linuxfreaker> in Launchpad
[07:10] <linuxfreaker> I created an a/c
[07:10] <linuxfreaker> how can I raise a bug
[07:10] <linuxfreaker> I dont see "
[07:10] <linuxfreaker> Create new bug" section anywhere
[07:12] <micahg> linuxfreaker: run 'ubuntu-bug PKGNAME' from the cli
[07:12] <akshatj> linuxfreaker: is it a bug in a different package or launchpad itself?
[07:13] <micahg> ah, that's a good question...
[07:52] <pitti> Good morning
[07:55] <JackyAlcine> Morning, pitti
[07:59] <chrisccoulson> hi dholbach, and happy new year to you too :)
[08:00] <chrisccoulson> am i patch pilot today? i'm still officially on vacation until monday ;)
[08:00] <chrisccoulson> (although, i'll be hanging around for most of the day)
[08:01] <dholbach> chrisccoulson, nevermind then - take it easy :)
[08:03] <pitti> bryceh, Sarvatt: are you on the current xserver-xorg-core uninstallability? it depends on "keyboard-configuration" which doesn't exist
[08:04] <pitti> and it's not in NEW either
[08:14] <linuxfreaker> akshat: Pretty Funny
[08:14] <linuxfreaker> But I am not on Ubuntu machine
[08:14] <linuxfreaker> I want to file a bug through website
[08:14] <linuxfreaker> launchpad.ubunut.com
[08:15] <linuxfreaker> launchpad.ubuntu.com
[08:15] <akshatj> linuxfreaker: its launchad.net
[08:16] <akshatj> oops
[08:16] <akshatj> launchpad.net
[08:17] <linuxfreaker> akshatj: Cannot see File or Create a bug option
[08:17] <linuxfreaker> whers that?
[08:17] <didrocks> good morning
[08:18] <linuxfreaker> gm
[08:18] <linuxfreaker> didrocks: How r u?
[08:18] <akshatj> linuxfreaker: there is 'Report a Bug' under 'Get Involved' in the right
[08:18] <didrocks> linuxfreaker: I'm fine, thanks, and you?
[08:20] <linuxfreaker> akshatj: I am unable to see anywhere..can yu send me the complete link
[08:21] <linuxfreaker> I can browse the bugs but dont see where I can sumbit new bug
[08:22] <cjwatson> pitti: that's my problem
[08:22] <cjwatson> (pending MIR promotion, then keyboard-configuration will be in NEW shortly afterwards)
[08:24] <akshatj> linuxfreaker: you can't see this http://imgur.com/3S2e6 ?
[08:24] <cjwatson> linuxfreaker: https://help.ubuntu.com/community/ReportingBugs
[08:25] <cjwatson> especially https://help.ubuntu.com/community/ReportingBugs#Filing%20bugs%20at%20Launchpad.net
[08:30] <linuxfreaker> akshatj: thanks
[08:57] <apw> is there something wrong with the launchpad build farm?  i have builds which claim to have finished 9 hours ago which are still 'uploading build'
[08:57] <apw> https://launchpad.net/ubuntu/+source/linux/2.6.37-12.26/+build/2125799
[08:58] <cjwatson> #launchpad would have better ability to check ...
[08:59] <cjwatson> I hadn't heard of a general problem
[08:59] <apw> cjwatson, thanks
[09:00] <apw> cjwatson, am not the only one affected, so i guess a generic problem
[09:02] <apw> cjwatson, seemes everything finishing since the 'deployment this morning' are stuck and not uploading
[09:02] <apw> cirtainly some 8 hours or so ago at least
[09:17] <Riddell> cjwatson: can we chat about kubuntu seeds today?
[09:18] <Riddell> we need to work out if kubuntu mobile bits should be in an entirely separate seed
[09:20] <Riddell> !regression-alert
[09:20] <Riddell> goodness
[09:20] <Riddell> bug 696675 is the issue, fix uploaded to -proposed awaiting approval
[09:22] <pitti> hey Riddell
[09:22] <pitti> Riddell: ah, will do right away
[09:22] <Riddell> thanks
[09:23] <pitti> uh, *all* those? ok
[09:31] <bdrung> is there an problem with the archive? various builds are on "uploading build" for hours. e.g. https://launchpad.net/ubuntu/+source/pwdhash/1.7-9/+build/2126172
[09:33] <dholbach> bdrung, see conversation between apw and cjwatson above
[09:33] <apw> bdrung, #launchpad released something last night and its broken binary uploads by the seems of it
[09:46] <mvo> cjwatson: I just booted into a btrfs boot via the new grub, pretty impressive :) it seems like grub-probe is unhappy and cant identify /boot but from the grub shell at boot its all good
[09:51] <dupondje> Hi guys, can we mark bug https://bugs.launchpad.net/ubuntu/+source/php5/+bug/697181 as critical ?
[09:51] <dupondje> needs some fast attention :)
[09:58] <apw> bdrung, looks like things are uploading now
[10:09] <linuxfreaker> I was running a NIC Hot-Add script on Ubuntu 10.10 VM and the script failed at the stage where in it checks the entries under /etc/udev/rules.d/70-persistent-net.rules  for the MAC address
[10:10] <linuxfreaker> The script was checking for the Mac address entry for the newly added NIC under this file but there wasn’t any entry!
[10:11] <linuxfreaker> It was working in 9.10
[10:11] <linuxfreaker> I tried to run the same script under Ubuntu 9.10 32bit VM, and after the NIC hot-add operation, the MAC address details were logged under the 70-persistent-net.rules file
[10:11] <linuxfreaker> Pls Suggest..
[10:43] <cjwatson> Riddell: is kubuntu-mobile still a universe thing?
[10:44] <cjwatson> mvo_: can you get a -v log from grub-probe?
[10:44] <cjwatson> mvo_: it's odd for it to work at boot but for grub-probe not to work; usually, by design, those two go together
[10:45] <mvo_> cjwatson: sure, to me its inconclusive, but I'm happy to post it in a sec. it might be some oddness because this was a /boot on ext2 before that I manually converted (well, copied over)
[10:45] <Riddell> cjwatson: well no, it got moved to main because keeping it in universe was too fiddly
[10:45] <Riddell> cjwatson: but really it should be in universe
[10:48] <mvo_> cjwatson: http://paste.ubuntu.com/551019/ (i can do one of / for comparison if that helps and/or strace it
[10:50] <cjwatson> Riddell: if it's a pain to move it to a separate seed, I think I can perhaps manage to nobble component-mismatches to not consider the mobile part of the tree
[10:50] <cjwatson> er, to a separate collection
[10:51] <cjwatson> mvo_: what were the arguments for that?
[10:51] <cjwatson> mvo_: actually, I should have asked for -vv
[10:53] <cjwatson> Riddell: the component-mismatches change looks quite difficult though, and might need a Launchpad change.  How much of a pain would it be to move mobile to a separate seed collection?
[10:56] <mvo_> cjwatson: http://paste.ubuntu.com/551020/ (this time with the commandline)
[10:58] <cjwatson> mvo_: could you paste /proc/self/mountinfo?
[10:59]  * cjwatson has a suspicion ...
[11:00] <mvo_> cjwatson: sure http://paste.ubuntu.com/551022/
[11:01] <sebner> Riddell: mind accepting monobristol into maverick updates? bug #688847
[11:05] <Riddell> cjwatson: I think a separate seed collection would be the easiest thing to do
[11:06] <Riddell> sebner: that tends to be pitti's domain
[11:06] <sebner> Riddell: ah, sorry. Just saw that you are on duty today
[11:06] <pitti> sebner: it needs to be fixed in natty first
[11:06] <sebner> pitti: done ;)
[11:06] <Riddell> sebner: I am?
[11:07] <pitti> sebner: ah, so the natty task should be closed?
[11:07] <sebner> Riddell: Tuesday: JonathanRiddell
[11:07] <pitti> today is Thursday..
[11:07] <sebner> Riddell: as long as the wiki isn't outdated
[11:07] <sebner> argh
[11:07]  * sebner = confused
[11:07] <sebner> xD
[11:07] <sebner> Riddell: I'm sorry
[11:08] <sebner> pitti: done
[11:09] <pitti> sebner: thanks, moving to -updates
[11:09] <cjwatson> mvo_: thanks - fixed upstream, http://paste.ubuntu.com/551023/
[11:10] <sebner> pitti: thank you :)
[11:11] <sebner> pitti: you know, when one is student and still on holidays one tend to confuse thuesday with thursday :D
[11:16] <pitti> sebner: I know the feeling; I mixed them up during my two weeks of christmas holidays, too :)
[11:16] <sebner> heh =)
[11:17] <mvo_> cjwatson: rock! thanks
[12:07] <cjwatson> pitti: do you think you could NEW keyboard-configuration, since you asked about it earlier? :-)
[12:07] <pitti> cjwatson: sure, looking
[12:08] <pitti> cjwatson: is this a splitout of some kind, or does it need to go through MIR?
[12:08] <cjwatson> it's binary NEW
[12:08] <pitti> oh, just a new binary
[12:08] <cjwatson> console-setup was split into a couple of pieces binary-wise
[12:09] <pitti> cjwatson: is not having a Replaces: to go with the Conflicts: intented?
[12:10] <cjwatson> hmm, I suspect there were no overlapping files upstream
[12:11] <cjwatson> let me adjust that before you process it
[12:11] <pitti> 'k
[12:12] <pitti> cjwatson: there are a couple of bashisms in config and postinst; aside from that conflicts: it looks fine to me
[12:12] <cjwatson> looks like I have to think a bit about how to handle console-setup-tty
[12:13] <cjwatson> pitti: which bashisms?
[12:13] <pitti> W: keyboard-configuration: possible-bashism-in-maintainer-script config:26295 'if type '
[12:13] <pitti> W: keyboard-configuration: possible-bashism-in-maintainer-script config:26831 '& type '
[12:13] <pitti> that's what lintian says anyway
[12:13] <cjwatson> well
[12:13] <pitti> not quite sure why, type exists in dash, too
[12:13] <cjwatson> that's technically nonportable but all the /bin/sh implementations I know of support it
[12:13] <pitti> right
[12:13] <pitti> so let's ignore that one
[12:14] <AnAnt> Hello, would someone comment on LP 697538 ?
[12:15] <cjwatson> right, I think console-setup-tty simply belongs in console-setup, not k-c
[12:17] <cjwatson> and the initramfs stuff too.  (keyboard-configuration basically exists to be a lighter dependency for X ...)
[12:18] <pitti> so that you can have a downsized system with just X, and no VT font config and the like?
[12:21] <cjwatson> oh, wait, they go in keyboard-configuration because they're meant to be shared with console-setup-mini (which Ubuntu doesn't really use but nevertheless if we build it we should make it work)
[12:23] <cjwatson> so in fact it *is* meant to have the init stuff
[12:23] <cjwatson> (sorry, this split was done upstream, I'm following alongg)
[12:24] <pitti> cjwatson: I need to run out for about two hours; I'm happy to have a look afterwards unless someone else beats me to it
[12:24] <cjwatson> I think I'll just add the Replaces
[12:25] <pitti> cjwatson: ok; feel free to NEW it yourself then
[12:25] <pitti> I can imagine how it'll look like :)
[12:27] <mok0> I am puzzled that the debian policy says that the get-orig-source rule should leave the tarball in the current directory. When run from $topdir, it is then necessary to manually move the tarball one notch up
[12:28] <cjwatson> pitti: http://bazaar.launchpad.net/~ubuntu-core-dev/console-setup/ubuntu/revision/165
[12:29] <cjwatson> mok0: it also says "This target may be invoked in any directory", so I think the idea is that you *call* it from one level up
[12:29] <tumbleweed> cjwatson: practically that invoking from any directory bit is hard to implement (if you are going to use dpkg-parsechangelog to determine the version)
[12:30] <tumbleweed> I've always ignored it
[12:30] <mok0> cjwatson: yes... but don't the tools always run from $topdir?
[12:30] <apw> cjwatson, i assume seeds do not get turned into packages ?
[12:30] <mok0> cjwatson: I can see that leaving files in $cwd is the most logical behaviour though
[12:30] <cjwatson> mok0: get-orig-source is run by hand though, not via "the tools"
[12:31] <mok0> cjwatson: afaik bzr-buildpackage tries to run it
[12:31] <cjwatson> heh, its problem then :)
[12:31] <tumbleweed> yeah, it runs it in the root of the package
[12:31] <cjwatson> that seems like a bug on the face of it
[12:31] <cjwatson> tumbleweed: get-orig-source doesn't need dpkg-parsechangelog information
[12:32] <cjwatson> apw: some seeds do.  what do you mean?
[12:32] <tumbleweed> cjwatson: how do you know which versino to download then (unless you change it on every upstream release)
[12:32] <mok0> I am not sure though bzr-buildpackage might move it to its build-area
[12:32] <apw> cjwatson, oh i was looking at platform.natty, to see what happened to it after it was changed
[12:32] <cjwatson> tumbleweed: "the most recent version"
[12:33] <apw> cjwatson, and it doesn't seem to have releases or tags, or indeed a changelog
[12:33] <tumbleweed> hmm, that is a point, still that's not what one normally wants
[12:34] <cjwatson> apw: phone, brb
[12:41] <apw> anyone seen 'different serializers' errors when pushing a new branch to launchpad ?
[12:47] <cjwatson> apw: some packages use the seeds to generate dependencies and the like, for example the ubuntu-meta source package
[12:47] <cjwatson> apw: the changelog is 'bzr log'
[12:48] <apw> cjwatson, so used in consumer packages, but the branch itself is just a repo
[12:49] <cjwatson> correct
[12:49] <apw> cjwatson, looking at platform.natty there are a lot of arm kernels listed which i don't believe exist
[12:49] <apw>  * Kernel-Version: 2.6.32-410-dove 2.6.37-12-omap 2.6.35-1101-omap4 2.6.31-800-st1-5 2.6.37-11-iop32x 2.6.37-10-ixp4xx 2.6.37-11-orion5x 2.6.37-12-versatile
[12:50] <apw> ixp4xx and orion5x particularly i am wondering about there
[12:50] <ogra> yeah, we need to clean that up at some point
[12:50] <cjwatson> it doesn't cause a problem though
[12:50] <ogra> ixp is a leftover from jaunty
[12:50] <cjwatson> iop32x as well
[12:51] <ogra> our first arm images were for nslu2
[12:51] <ogra> yep
[12:52] <cjwatson> apw: BTW it's best to change those entries only in sync with a debian-installer upload
[12:52] <cjwatson> I usually just use sed
[12:53] <cjwatson> apw: if you want to do that in an hour's time (once the kernel's in the archive) by way of practice, I can merge/sponsor
[12:53] <apw> cjwatson, yeah i've been doing the d-i changes too (https://code.launchpad.net/~apw/debian-installer/kernel-update) for the practice
[12:53] <apw> cjwatson, thanks
[12:54] <cjwatson> sed -i 's/2.6.37-11/2.6.37-12/g' *installer*
[12:55] <cjwatson> apw: that's fine except that it's good practice to have the changelog say UNRELEASED instead of natty until it's actually uploaded
[12:56] <apw> cjwatson, oh yeah i pushed it after playing with debcommit -r, ooops
[14:15] <apw> cjwatson, ok those binaries are now 'in', and i've also uploaded meta (not sure that you care for this), i've pushed the d-i changes here: https://code.launchpad.net/~apw/debian-installer/kernel-update and the platform.natty changes here: https://code.launchpad.net/~apw/ubuntu-seeds/platform.natty-kernel-update
[14:37] <pitti> cjwatson: re; looks fine; should I review it again?
[14:40] <pitti> ah, it's in the queue, doing
[14:42] <pitti> cjwatson: accepted
[15:20] <cjwatson> apw: thanks, will review in a minute then
[15:20] <cjwatson> pitti: great, thank you
[15:20] <apw> cjwatson, whenever you have time, thanks :)
[15:21] <cjwatson> it isn't necessary for linux-meta to be in place before building a new installer, but it does mean that the installer will actually install the new kernel
[15:32] <benste> I'd need a review for https://code.launchpad.net/~benste/kdeedu/bugfix-lp-698056_b/+merge/45397 but kubuntu-dev list rejects my message
[15:54] <pitti> Hah - "Committed revision 666."
[15:54]  * pitti says "All hail to the creator of Linux" before he gets a penalty card
[16:03] <shadeslayer> asac: poke ... around?
[16:05] <asac> shadeslayer: whats up?
[16:05] <shadeslayer> asac: hi, so i saw your post on android + Linaro
[16:05] <shadeslayer> asac: and kubuntu has something called plasma-mobile running on the N900, is it possible to run that on my android device as well? ( HTC Desire )
[16:05] <shadeslayer> plasma-mobile is already in the archives
[16:06] <shadeslayer> the only possible way right now is to boot a lucid chroot off my phone and install the binaries
[16:06] <shadeslayer> from here : http://code.google.com/p/android-cruft/wiki/LucidWithAndroid
[16:07] <dholbach> debconf questions by keyboard-configuration?
[16:08] <dholbach> "Method for toggling between national and Latin mode"
[16:08] <dholbach> ???
[16:08] <dholbach> :)
[16:08] <cjwatson> shouldn't ask new questions, that's a bug.
[16:08] <cjwatson> can you please STOP HERE
[16:08] <cjwatson> and capture /etc/default/console-setup before it overwrites it
[16:08] <cjwatson> and ideally also /var/cache/debconf/config.dat and /var/cache/debconf/templates.dat
[16:09] <cjwatson> then carry on and record all the questions it asks
[16:09] <dholbach> will do
[16:10] <cjwatson> it's odd because it should have copied that one from console-setup/toggle, looking at the code
[16:11] <cjwatson> though, hm, console-setup/toggle only used to be asked for non-Latin layouts
[16:12] <cjwatson> and that still ought to be the case, so for some reason it thinks you have a non-Latin layout
[16:12] <dholbach> https://bugs.launchpad.net/ubuntu/+source/keyboard-configuration does not seem to exist?
[16:12] <Laney> source: console-setup
[16:12] <dholbach> oops
[16:12] <dholbach> sorry about that :)
[16:22] <hallyn> Daviey: would you mind taking a look at https://code.launchpad.net/~serge-hallyn/ubuntu/natty/multipath-tools/backport-fixes/+merge/45410 if you get a chance?
[16:23] <asac> shadeslayer: hmm ... the problem are drivers/kernels etc.
[16:23] <shadeslayer> asac: well ... cyanogenmod has the kernel source code ... and it works, so can we not use that?
[16:23] <dholbach> cjwatson, if there's any more information I can put into bug 698177, let me know
[16:24] <shadeslayer> HTC Provides the kernel source code as well
[16:24] <asac> shadeslayer: the kernel might be a bit crippled, but it would be worth a try ;)
[16:25] <hallyn> cjwatson: (just fyi) since the sync is gonna take me a little while for multipath-tools, I'm trying to push the fixes I've got sitting around for exsting bugs to natty separatley first, since that seems to make sru easier afterwards.
[16:25] <shadeslayer> :)
[16:27] <smoser> cjwatson, i now there isn't much information, but do you have thoughts on what might be causing bug 697493
[16:40] <cjwatson> dholbach: ok, will queue it up
[16:40] <cjwatson> hallyn: thanks
[16:40] <dholbach> thanks a lot cjwatson
[16:40] <cjwatson> smoser: can you reproduce it under valgrind?
[16:40] <smoser> i haven't tried, and i figured that was what you were going to ask :)
[16:40] <smoser> but i'm guessing that i can.
[16:41] <smoser> i was just hoping you'd say "oh, i know what changes would have caused that"
[16:43] <cjwatson> smoser: the most likely candidate is probably the btrfs patch, but I don't have a specific thing to point to there (having just read through it)
[16:53] <lool> pitti: Hey there
[16:53] <pitti> hey lool, bonne annee! ca va?
[16:54] <lool> pitti: I'm trying to track what happened with the linux-linaro-omap dbgsyms
[16:54] <lool> pitti: Ein frohes Jahr 2011 zu dir!  :-)
[16:54] <lool> pitti: Going alright -- happy to see you next week :)
[16:54] <pitti> \o/ likewise
[16:54] <pitti> lool: so, they don't exist?
[16:54]  * pitti checks
[16:55] <lool> pitti: The linux-linaro-omap upload log shows the dbgsym in the .changes, but they don't appear in http://ddebs.ubuntu.com/pool/main/l/linux-linaro-omap/
[16:55] <lool> and linux-linaro-omap is in main for some reason
[16:55] <pitti> we currently have all kernel packages in main
[16:55] <lool> 17:54 < pm215> lool: is it expected that the dbgsym package doesn't appear in  the Checksums-* sections?
[16:55] <pitti> lool: ah, it's new in natty
[16:56] <lool> pitti: I think similar issues occured in maverick, but I don't have specific packages to point out; yes, it's new in natty
[16:56] <pitti> lool: so, sometimes the ddeb retriever hangs a long time because a buildd's apache is acting up
[16:56] <pitti> in these cases I need to kill and manually restart it; also, there are other cases where the ddeb-retriever is dropping packages :-(
[16:56] <pitti> i. e. it's possible that it just fell through the cracks
[16:56]  * pitti really wants soyuz ddeb support *sigh*
[16:57] <lool> pitti: How does one usually go with such issues?  ping you?  rt ticket?
[16:57] <pitti> lool: right, so it built around christmas
[16:57] <pitti> lool: ping me
[16:57] <pitti> lool: the buildds keep ddebs for 7 days
[16:58] <pitti> lool: so if a ddeb doesn't appear after build, I can rescue it within a week
[16:58] <pitti> but then it's gone :-/
[16:58] <lool> I see
[16:58] <lool> pitti: Can you confirm that what happened was that the ddeb retriever was borken?
[16:58] <pitti> no, I can't
[16:58] <lool> pitti: Maybe we should send a weekly summary of ddeb copied to ddebs.u.c to some list of people so that we can react if it's empty?
[16:59] <pitti> "nothing last as long as a makeshift"
[16:59] <pitti> (which ddeb-retriever is)
[16:59] <lool> eh
[16:59] <pitti> wgrant: ^ OOI, is there an update for this? I thought soyuz got ddeb support ages ago, and it's 90% there?
[17:02] <pitti> lool: http://ddebs.ubuntu.com/pool/main/l/linux/ does have armel ddebs, so it's not a general problem with the hack for linux (earlier releases had broken package names) or armel
[17:03] <pitti> lool: so I'm afraid the only practical solution right now is to upload a rebuild, and then I watch what happens in the retriever
[17:03] <pitti> lool: I guess you want to update to .37 final anyway?
[17:06] <lool> pitti: Ok
[17:07] <lool> pitti: We will have other uploads, I'll try to think of pinging when it happens  :-)
[17:07] <pitti> lool: merci
[17:07] <lool> pitti: i'll check with jcrigby to arrange that
[17:07] <lool> pitti: thanks to /you/!
[17:10] <pitti> lool: ah, now that macquarie is on lucid, I could even re-enable my timeout patch, to avoid the endless hangs
[17:11] <pitti> hardy's python didn't support that yet
[17:13] <pitti> lool: done
[17:13] <lool> pitti: thanks
[17:13] <pitti> lool: so, this ping was at least good to improve it in the future :)
[17:14] <lool> Eh
[17:22] <pitti> tkamppeter: hah! I just got Jockey to install the Epson printer driver from the op.o repository, with all the GPG fingerprint and trusted repository checking \o/
[17:23] <superm1> pitti, hi. did you have thoughts about how you were planning on blocking nvidia and fglrx driver being offered in the live environment?  I was hoping there will be a way to control this.  at least for my purposes i'd like to have a way to make sure all drivers can still be offered in some fashion
[17:24] <pitti> superm1: I was going to add a two-liner to both handlers to check for /rofs/, and fail if it exists
[17:24] <pitti> superm1: so that you can still install wl, etc.
[17:24] <pitti> I think ev heroically fixed that initramfs update problem, so that should work again
[17:25] <pitti> superm1: what do you mean with "control"?
[17:25] <superm1> pitti, well for my purposes i'd still like to offer them as potential targets when i run jockey during post install
[17:25] <pitti> superm1: there might also be a more elegant way with putting an empty modalias override file into /usr/share/jockey/modaliases/ for fglrx and nvidia in casper
[17:26] <pitti> superm1: what is "post install" in your case?
[17:26] <superm1> pitti, but aren't they both now controlled by the debian package header for modaliases not the modaliases file?
[17:26] <pitti> superm1: wouldn't you call that in chroot /target ?
[17:26] <pitti> superm1: they are, but the modaliases/ dir is still supported
[17:27] <superm1> pitti, so a blank file takes precendence?
[17:27] <pitti> superm1: you'd need to add a "reset nvidia" line to it to purge the ones collected from modinfo and the package headers
[17:27] <superm1> oh but you're right that I do call the backend and jockey text in the chroot, so it is likely a moot point
[17:27] <superm1> there would be no /rofs in that chroot
[17:27] <pitti> superm1: I don't know whether I got the ordering of those right, but I can ensure that this works
[17:27] <pitti> superm1: my thought
[17:28] <elif> Hi, how kickstart works ? it is translated to a preseed file ? what package source should I look for ?
[17:28] <pitti> superm1: we want to disable it because there's usually too little RAM to download all the pacakges, build and install them
[17:28] <superm1> pitti, right, makes sense to me.  then no worries from my side :)
[17:28] <pitti> superm1: in /target/ that's not a problem of course, and it should just work
[17:28] <pitti> superm1: ok, cool ;)
[17:31] <sm> g'day all. When might the fix for https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/67235 become available for regular maverick users ?
[17:42] <ebroder> pitti, superm1: there's no point in installing new X drivers in an actual live cd environment, since there's no persistance. but if you do a usb-creator install with persistance, then it does make sense
[17:42] <ebroder> and hopefully you have enough disk space in the persistance file and RAM to support doing that
[17:42] <superm1> you'd need to reboot though for that to even work most likely
[17:42] <ebroder> so maybe the test should be more "if os.path.exists(/rofs") and 'persistant' not in open('
[17:43] <ebroder> err... os.path.exists('/rofs') and 'persistant' not in open('/proc/cmdline').read()
[17:43] <superm1> i doubt you'd be able to stop X, unload nouveau/radeon, load nvidia/fglrx safely
[17:43] <ebroder> superm1: rebooting is fine. there's code to pull the new initrd out of the aufs filesystem into /cdrom, so that should all work
[17:43] <barry> doko_: chinstrap:~barry/ethos*
[17:48]  * sm meant https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/672352 , oops
[17:52] <cjwatson> sm: it looks as though it's available right now.       libc6 | 2.12.1-0ubuntu10 | maverick-updates | amd64, armel, i386, powerpc
[17:52] <cjwatson> you do of course have to have updates enabled ...
[18:06] <apw> cjwatson, has anything significant changes in grub graphics handing since 20101126 ?
[18:08] <cjwatson> apw: preferred VBE resolution detection; vt.handoff=7
[18:09] <cjwatson> oh, and a fix for PCI probing, I suppose that's tangentially related
[18:09] <apw> cjwatson, so even when =text is deployed we would still have done more graphics fiddling
[18:09] <cjwatson> yes, though it ought to have been set back to VGA text
[18:10] <cjwatson> GRUB_GFXMODE=640x480 should avoid the VBE resolution detection
[18:10] <apw> i think i'll punt till i can get my hands on the machine as it will be in dallas
[18:12] <sm> cjwatson: thanks, good to know
[18:12] <cjwatson> apw: *nod*
[18:14] <sm> cjwatson: any idea why that didn't show up on the bug page like maverick-proposed and natty ?
[18:16] <cjwatson> sm: not sure I understand your question
[18:17] <sm> launchpad-janitor posted on the bug page when the fix arrived in those repos/pools/releases, but not when it arrived in maverick-updates
[18:18] <cjwatson> actually, it posted when it arrived in -updates
[18:18] <cjwatson> it's just that the changelog was written when it was uploaded to -proposed, so says "maverick-proposed"
[18:18] <cjwatson> but that's misleading
[18:19] <sm> it sure is. I wonder if that's why I failed to help someone install it from -proposed recently
[18:20] <cjwatson> we remove things from -proposed after they reach -updates
[18:20] <cjwatson> you can see where something's published in Launchpad
[18:20] <cjwatson> https://launchpad.net/ubuntu/+source/eglibc in this case
[18:21] <sm> I had a little extra trouble figuring things out because the source and binary packages have difference names ? eglibc/libc6 I think
[18:21] <cjwatson> yes
[18:21] <cjwatson> but the bug URL you posted above had the source package name in, which is what you need in this case
[18:21] <cjwatson> in fact, just go to the bug page and follow the "Overview" link at the top
[18:22] <cjwatson> the eglibc source package produces quite a few binary packages - libc6 is just arguably the most important one of them
[18:22] <sm> I see.. clear now, and that's a useful link.. thanks!
[18:22] <cjwatson> there are development packages, cross-architecture stuff, ...
[18:33] <cody-somerville> cjwatson, You don't happen to know of a way off the top of your head to prevent cdrom being added to sources.list during d-i install?
[18:34] <cjwatson> cody-somerville: not OTTOMH, no, which isn't to say it's not possible
[18:52] <lifeless> pitti: still around per-chance?
[18:52] <pitti> lifeless: yes, but on the phone
[18:52] <lifeless> ok cool
[18:52] <lifeless> I'll type some stuff and you can reply whenever ;)
[18:53] <lifeless> I wanted to upload blobs to lp.net/+storeblob but the implementation in apport is a bit tightly coupled
[18:53] <lifeless> I found http://pypi.python.org/pypi/poster/ which isn't packaged
[18:54] <lifeless> *if* it gets packaged, would apport be able to switch to using that? [is there anything over and above a code-change at issue?]
[18:54] <pitti> lifeless: apport/crashdb_impl/launchpad.py has a separate upload_blob() function; that doesn't work for you?
[18:55] <lifeless> pitti: apport isn't widely available e.g. on windows
[18:55] <pitti> lifeless: not a principal problem, just that I'd like to avoid yet another dependency
[18:55] <pitti> lifeless: ideally it'd go into launchpadlib (bug 315358)
[18:55] <lifeless> pitti: copying the code out seems undesirable (and the project I want it in is BSD anyhow)
[19:01] <lifeless> pitti: sounds like you'd be happy if launchpadlib used posted and you use launchpadlib ?
[19:02] <pitti> lifeless: yes, that'd be fine
[19:29] <Dawgmatix> I just cross compiled some libraries using the mingw32 toolchain for running on windows. these create files with a .dll.a and .la extensions. any ideas on how to use these with visual studio?
[19:36] <directhex> yikes... i'd be amazed if you could
[19:39] <Dawgmatix> i see
[19:58] <wgrant> pitti: DDEB support is 90% there. But disk space is not.
[20:04] <bryceh> @pilot in
[20:13] <ebroder> hmm...does unity on natty not like monitor resolution changes?
[20:21] <bryceh> ebroder, haven't tried it, but wouldn't surprise me if it's bugged
[20:28] <cnd> I'm trying to use requestsync to request a sync of rinputd 1.0.4-1 which fixes ftbfs in natty for 1.0.3-6, for which the package was patched and reuploaded as 1.0.3-6ubuntu1 by someone else
[20:28] <cnd> I'm stuck trying to figure out if I should use the '-e' option of requestsync
[20:29] <cnd> "  -e          Use this after FeatureFreeze for non-bug fix syncs, changes
[20:29] <cnd>               default subscription to the appropriate release team."
[20:29] <ebroder> cnd: no, we're not past featurefreeze
[20:29] <cnd> 1.0.4-1 fixes the ftbfs correctly, whereas 1.0.3-6ubuntu1 papers it over with a gcc switch
[20:29] <cnd> zurgh, I thought that said import freeze
[20:29] <cnd> ebroder, thanks!
[20:30] <bryceh> that option seems like something that ought to be automatically detected...
[20:30] <ebroder> is the release schedule actually listed in a machine parseable form anywhere? all i know of is the wiki page
[20:31] <bryceh> yeah don't think so.  it ought to be though.
[20:32] <bryceh> probably could be hacked into launchpad and exposed through launchpadlib in some fashion
[20:32] <bryceh> (no I'm not volunteering!)
[20:33] <bryceh> hmm, a really easy approach would be to just provide a JSON version of the schedule at some official-ish url, that scripts could snag.  THAT wouldn't be hard.
[20:34] <cnd> parse the wiki page? :)
[20:35] <bryceh> cnd, I think by 'machine parsable' he was excluding that option ;-)
[20:35] <cnd> heh
[21:33] <mterry> kees, you still around?
[21:34] <kees> mterry: yup!
[21:34] <mterry> kees, I updated the glib2.0 packaging branch to fix bug 698131, but belatedly realized that glib2.0 isn't in the ubuntu-desktop set, so I couldn't push it
[21:34] <mterry> kees, can I impose upon you to do a quick review and push it for me?
[21:34] <kees> oh! sure thing
[21:34] <mterry> kees, (asking you since you commented on the bug :))
[21:35] <mterry> kees, thanks!
[21:36] <kees> mterry: is the blank line 8 in debian/patches/series intentional? (not that it matters)
[21:37] <mterry> kees, huh, odd.  I did an quilt import and quilt rename, didn't hand-edit it
[21:37] <kees> no worries, it was there from before. quilt just appended.
[21:37] <mterry> ah, that makes sense
[21:37] <kees> mterry: everything looks great. I'll upload it now. thanks for finding/fixing it! :)
[21:38] <mterry> kees, eh, seb128 pointed me at the patch, easy enough to download and stuff in the series.  ;)
[21:38] <kees> :)
[22:01] <tkamppeter> pitti, still there?
[22:08] <kees> mterry: uploaded now. thanks again!
[22:08] <mterry> kees, cool
[22:53] <bdmurray> Amaranth: should bug 301174 really be triaged for compiz?
[22:53] <Amaranth> bdmurray: Yeah, we know of a way to work around the issue in compiz
[22:53] <Amaranth> bdmurray: upstream doesn't want to do it the straightforward way though so it hasn't happened yet :)
[23:25] <cjwatson> apw: version bump stuff all merged and uploaded now, belatedly
[23:44] <apw> cjwatson, thanks a lot
[23:45] <apw> cjwatson, just in time for the cds which will make the arm peeps happy