[00:00] <dieselmachine> do i run that from the root of the source directory? Don't I need to do ./configure, or make or something?
[00:00] <cjwatson> debuild -b (etc.) runs debian/rules build as one of its steps, which does ...
[00:01] <dieselmachine> I do not have that package currently installed, and apt-get hasn't heard of it. What package do I need inorder to get access to debuild?
[00:02] <dieselmachine> oh, disregard, it provided the answer in the error message
[00:02] <dieselmachine> Sorry for the uninformed question
[00:06] <ion> I tend to dpkg --unpack the resulting binaries and then apt-get -f install.
[00:07] <dieselmachine> what does the -f parameter do?
[00:08] <ion> man apt-get
[00:09] <dieselmachine> How helpful
[00:10] <dieselmachine> ls -al
[00:10] <dieselmachine> oops
[00:12] <dieselmachine> where does debuild dump the binaries?
[00:13] <dieselmachine> a straight answer instead of linking me to a page with the answer would be great
[00:13] <directhex> ..
[00:13] <dieselmachine> awesome, thanks
[00:30] <soren> cjwatson: Ah, right. Good catch. Thanks for the review!
[00:32] <mathiaz> slangasek: could you add another test case for UEC images (last section from http://testcases.qa.ubuntu.com/System/CloudImages)?
[01:04] <rndm_> karmic alpha 3 seems busted on modern imacs, there's no fb device in /dev. the live-cd doesn't go to anything graphical. It sounds like this: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nv/+bug/404577
[01:05] <TheMuso> rndm_: How modern is modern?
[01:06] <rndm_> TheMuso: has 9400m. the current production model i believe
[01:08] <rndm_> i tested against the daily livecd actually, so newer than alpha 3
[01:09] <TheMuso> rndm_: ah ok
[01:10] <rndm_> it's model #A1224, the current 20inch if that means anything to you
[01:15] <rndm_> if someone more experienced with development in this area would like to guide me on what may be relevant i'll file a report
[02:25] <dave-ubuntu1> ive been looking for an answer to this question for days
[02:25] <dave-ubuntu1> https://answers.launchpad.net/ubuntu/+question/81467
[02:26] <dave-ubuntu1> i have tried #ubuntu for many hours also
[02:37] <ScottK> mathiaz: They just needed a retry.  The failed to upload ones were ones that finished building (in Multiverse) before Soyuz noticed they'd moved.  I retried several of them, but I doubt I got them all.
[02:46] <cjwatson> dave-ubuntu1: I'll answer on Launchpad
[02:49] <virtuald> dave-ubuntu1: i think it uses LUKS default options, see man 8 cryptsetup
[02:51] <cjwatson> virtuald: I have given an answer in LP based on what the code does
[02:52] <virtuald> great
[03:21] <lamont> Keybuk: bug 393656 - thoughts?
[04:03] <MindVirus1> Hello. I have some suggestions, if anyone cares.
[04:11] <MindVirus1> Don't know if anyone's listening. Here are my ideas.
[04:12] <MindVirus1> Since I'm running a netbook and don't like netbook-remix, I keep my panel on the right side of the screen.
[04:12] <MindVirus1> The window picker applet won't render text vertically though, like the Clock applet does.
[04:12] <MindVirus1> I recommend that it should, instead of showing "..".
[04:13] <cjwatson> MindVirus1: suggestions on IRC are likely to be lost, as chances are that the right people aren't paying attention, or can't fix things *right now*; it's much better to file bugs, or for ideas that aren't well-enough-formed for bugs you can use brainstorm.ubuntu.com
[04:13] <MindVirus1> OK. :)
[05:39] <MindVirus1> I don't mean to bother you guys. Does anyone have access to ubottu?
[06:33] <MindVirus1> !hal
[06:34] <MindVirus1> Should say "deprecated" instead of "depreciated". That is all.
[06:43] <dholbach> good morning
[06:43] <dholbach> morning pitti
[06:44] <dholbach> pitti: I just sponsored a tangerine-icon-theme change and used the same build system you used in human-icon-theme :)
[06:44] <dholbach> great work :)
[07:15] <pitti> Good morning
[07:15] <pitti> dholbach: \o/
[07:15] <StevenK> Morning pitti
[07:15] <pitti> plain make FTW :)
[07:16] <dholbach> pitti: you know... I was young, didn't know any better and needed the money
[07:29] <pitti> lol
[07:29] <kagou> Hi
[07:31] <kagou> bryce, I have subscribed you to bug #421225 . Hoping that you can detect if it's a Xorg bug.
[07:31] <kagou> bryce, sorry if it's not the right way to do that. Regards
[08:06] <tkamppeter> pitti, hi
[08:09] <pitti> hi tkamppeter
[08:11] <slangasek> mathiaz: so the first two test cases only apply to EC2, and the third only applies to UEC, right?
[08:13] <tkamppeter> pitti, the FTBFS of CUPS got fixed upstream, so we can get a fixed CUPS into alpha 5.
[08:14] <tkamppeter> pitti, yesterday I have applied the upstream patch for the USB backend hang.
[08:17] <StevenK> ArneGoetje: Does ibus really need a .desktop entry under /usr/share/applications? It's being picked up by netbook-launcher and put into an "Other" category
[08:17] <StevenK> ArneGoetje: (care of bug 420282)
[08:17] <tkamppeter> pitti, one other thing of yesterday: I tested the suggested udev rule and it did not work for me. I had uploaded udevadm output to http://pastebin.ubuntu.com/262600/.
[08:18] <pitti> tkamppeter: thanks; I saw the poppler API fix, I'll apply that as well
[08:19] <mdke> cjwatson: ok, well I've fixed it on help.u.c in all versions but I don't think it's necessarily essential to keep the packages in line with that. I'll reject the other bugs tasks and we'll regard it as fixed
[08:26] <pitti> tkamppeter: sorry, did you say something after my "you need /devices.."? DSL reconnect..
[08:30] <tkamppeter> pitti, one other thing of yesterday: I tested the suggested udev rule and it did not work for me. I had uploaded udevadm output to http://pastebin.ubuntu.com/262600/.
[08:31] <pitti> tkamppeter: I still got that
[08:31] <pitti> pitti| tkamppeter: thanks; I saw the poppler API fix, I'll
[08:31] <pitti>        apply that as well
[08:31] <pitti> pitti| tkamppeter: ah, I see what's wrong
[08:31] <pitti> pitti| tkamppeter: you ran udevadm info on the interface,
[08:31] <pitti>        not on the device
[08:31] <pitti> pitti| tkamppeter: you need /devices/pci0000:00/0000:00:1d.
[08:31] <pitti>        1/usb3/3-1/3-1.4/3-1.4.3/3-1.4.3.4 for the device
[08:31] <pitti>        (the one with DEVNAME=/dev/bus/usb/003/016)
[08:37] <seb128> jdstrand, pitti: you might want to have a look to bug #414506
[08:37] <seb128> jdstrand, pitti: you might want to have a look to bug #414506
[08:38] <seb128> ups
[08:38] <pitti> seb128: the entire guest session is broken anyway..
[08:38] <pitti> still on my TODO list
[08:38] <seb128> pitti, ok thanks
[08:39] <pitti> seb128: oh, that; I alrady discussed that with Martin-Eric
[08:39] <seb128> pitti, speaking of guest-session somebody mentioned yesterday that only a  +x is to change or something
[08:39] <seb128> I think that was dbarth
[08:40] <pitti> bug updated
[08:40] <pitti> tkamppeter: meh, with the pdftopdf fix, it doesn't build any more with poppler 0.10 in Debian; so more magic dpatching required..
[08:49] <tkamppeter> pitti, for the Alpha 5 we can use a "magic" dpatch, but later we need conditional compiling with switch in ./configure, as the filters are upstream code and they should work with all incarnations of the daily changing API of Poppler.
[08:51] <tkamppeter> pitti, new udevadm test: http://pastebin.ubuntu.com/262959/
[09:10] <tkamppeter> pitti, can you upload bluez to get bug 418465 fixed for Alpha 5? superm1 will still be sleeping when Alpha 5 freeze happens.
[09:17] <ArneGoetje> StevenK: no, it doesn't. As long as the settings are accessable from the System/Preferences Menu, other entries are not needed.
[09:55] <al-maisan> I have a Samsung Q45 laptop running karmic and the screen brightness control keys don't work at all (no reaction when pressed); can somebody please explain how to fix this or point me to existing documentation?
[10:03] <AnAnt> Hello, can someone merge console-setup from Debian, since it would close LP 390292
[10:06] <Trewas> al-maisan: probably same bug 409889, it mentions a workaround
[10:06] <al-maisan> Trewas: thanks for the pointer!
[10:06]  * al-maisan takes a look.
[10:18] <jjardon> hello, someone can take a look at https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/418401 and https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/418981 ? I think they are important to https://wiki.ubuntu.com/Halsectomy
[10:24] <al-maisan> Trewas: the workaround described in the bug did work. Thank you very much!
[10:46] <pitti> tkamppeter: no, the patched filter was in debian/local/
[10:46] <pitti> tkamppeter: (pdftopdf)
[10:46] <pitti> tkamppeter: bluez> looking
[10:48] <pitti> tkamppeter: hm, what's the exact rule you have now?
[10:55] <ojwb> mvo: the xapian-core build failed on most platforms, due to running out of fds in the tests
[10:57] <pitti> tkamppeter: new cups uploaded to experimental and karmic
[10:58] <tkamppeter> pitti, have you seen my last comments here?
[10:59] <tkamppeter> pitti, have you checked my new  udevadm test: http://pastebin.ubuntu.com/262959/?
[10:59] <pitti> tkamppeter: pitti| tkamppeter: hm, what's the exact rule you have now?
[11:05] <mvo> ojwb: heh :) impressive - is that a buildd configuration problem? should I talk to the buildd admins aobut it?
[11:11] <tkamppeter> pitti: /lib/udev/rules.d/70-cups.rules:
[11:11] <tkamppeter> pitti: ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{bInterfaceClass}=="07", ATTR{bInterfaceSubClass}=="01", GROUP="lp", MODE="660"
[11:12] <pitti> tkamppeter: and can you please check /sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.3/3-1.4.3.4
[11:12] <pitti> oops
[11:12] <pitti> tkamppeter: and can you please check /sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.3/3-1.4.3.4/bInterfaceClass ? is that really "07"?
[11:13] <pitti> tkamppeter: and likewise for bInterfaceSubClass ?
[11:13] <tkamppeter> pitti, debian/local/filters stuff is upstream at http://www.openprinting.org/download/printing/pdf-printing/ and also at http://opfc.sf.jp/.
[11:27] <ojwb> mvo: sorry, the phone rang!
[11:28] <ojwb> mvo: i'm not sure what the cause is, but one of the debian alpha buildds does it too (and another doesn't)
[11:28] <ojwb> i guess sbuild sometimes has more fds open itself or something like that?
[11:29] <ojwb> if you fancy fixing it, just kill the ulimit as the patch does, but globally
[11:29]  * ojwb can file a bug if that's better
[11:32] <tkamppeter> pitti: cat /sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.3/3-1.4.3.4/3-1.4.3.4:1.0/bInterfaceSubClass
[11:32] <tkamppeter> pitti: 01
[11:32] <tkamppeter> pitti: cat /sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.3/3-1.4.3.4/3-1.4.3.4:1.0/bInterfaceClass
[11:32] <tkamppeter> pitti: 07
[11:32] <pitti> tkamppeter: ah, that woudl be it; that's again the interface, not the device
[11:32] <pitti> so I see why that rule doesn't work
[11:33] <pitti> tkamppeter: hang on
[11:35] <pitti> tkamppeter: https://bugs.edge.launchpad.net/ubuntu/+source/cups/+bug/420015/comments/53
[11:36] <cjwatson> AnAnt: I don't think it's a good idea to merge console-setup (and please leave that kind of decision up to the installer team). I'll backport the fix
[11:37] <cjwatson> if only because it will stop people thinking it causes other random bugs
[11:38] <AnAnt> cjwatson: actually, I do have a problem with console-setup LP 416949
[11:38] <tkamppeter> pitti, that's it, it works now. Thanks.
[11:39] <AnAnt> cjwatson: and indeed, I thought that maybe 390292 is related to it
[11:39] <tkamppeter> pitti, can you ap[ply the rule to the appropriate package to get it fixed in Alpha 5?
[11:39] <pitti> tkamppeter: not necessary for alpha-5, since the usb backend runs as root, it should work now; I'll just commit it
[11:39] <pitti> ... to udev upstream
[11:39] <pitti> and once it's in, revert the "root backend" change
[11:39] <tkamppeter> pitti, OK, thanks.
[11:42] <AnAnt> cjwatson: I even thought of trying Debian's console-setup on karmic after I found a hard time trying to merge Ubuntu's changes
[11:43] <AnAnt> cjwatson: do think that's a good idea, just to see if my problem goes ?
[11:45] <cjwatson> AnAnt: terrible idea, I think :)
[11:45] <cjwatson> AnAnt: I'm not merging it because it's really complex and will require other installer changes
[11:45] <AnAnt> yes, it is complex indeed
[11:46] <cjwatson> anyway, I'll backport the change and you can see
[11:46] <AnAnt> ok
[11:47] <mvo> ojwb: a bug would be prefered, fortunately it build on i386 and amd64 so at least the "big" arches are good :)
[11:47] <tkamppeter> pitti, thanks for uploading bluiez.
[11:52] <jjardon> pitti, about https://wiki.ubuntu.com/Halsectomy
[11:53] <jjardon> Could you take a look at t https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/418401 and https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/418981 ?
[12:11] <ojwb> mvo: LP#422493
[12:11] <ojwb> hope it's coherent, I have a cold atm
[12:14] <pgraner> pitti: have a min to discuss the dvb firmware stuff?
[12:17] <pitti> jjardon: looking, will comment in the bugs
[12:17] <pitti> pgraner: hey
[12:17] <jjardon> pitti, great, thanks!
[12:18] <pgraner> pitti: after talking with mdz he feels it would be better to move the questionable firmware into a package than can be put in multiverse and have jockey pull from that. Thoughts?
[12:19] <pgraner> pitti: the main rationale is that the firmware files keep changing URLs quite often and having them in a package ensures things "just work"
[12:21] <pitti> pgraner: if the problem is just non-freeness, that sounds great, and much easier than URL fishing
[12:21] <pitti> pgraner: however, if some of the firmware lacks a license completely, or explicitly forbids redistribution (like b43), this won't work either
[12:22] <pgraner> pitti: lack of license is the issue and mdz felt that it was ok to do it that way.
[12:22] <pitti> no, we can't, sorry
[12:22] <pitti> we cannot redistribute stuff without a license
[12:23] <pgraner> pitti: if thats the case then we will have to remove it and regress the dvb users
[12:23] <pgraner> pitti: I suggest we talk to mdz when he comes online in a few hours
[12:27] <pitti> pgraner: otherwise we could just leave it in restricted as it is now, and we wouldn't need to go through all this dance
[12:28] <pgraner> pitti: its in the linux-fw package not in restricted
[12:29] <pitti> ok, but at least we could move l-firmware to restricted if needed, and still install it by default
[12:29] <pitti> but without permission to redistribute we can't stick it into the archive at all
[12:30] <pgraner> pitti: ok, I'm not sure whats best but we have to do something. I sent an email to mdz & you we can hash it out there. mdz is in the US and I'm in Taiwan and tz's will kills us on IRC
[12:32] <Mez> so, seems that gnome is a bit broken right now.
[12:33] <Mez> I think I may have upgraded half way through a transition
[12:34] <davmor2> Mez: sounds about right :)
[12:36] <Mez> davmor2: not fun ... gnome-panel-data installed, gnome-panel not.
[12:36]  * Mez steals the deb from LP and reboots X
[12:37] <pitti> jjardon: bugs and Halsectomy page updated, thanks
[13:08] <jjardon> pitti, Can I rename https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/418401 to "Upgrade gnome-bluetooth to drop libhal dependency" ?
[13:26] <NCommander> stgraber, ping, if you have a moment, I'd like to talk to you on adding armel+dove images to the ISO tracker
[13:27] <ogra> NCommander, slangasek can do that as well, but there is a prob in pointing the download location to ports iirc
[13:27] <NCommander> ogra, ugh, what's the problem?
[13:28] <ogra> i dont remember off the top of my head and the tracker is empty atm
[13:29] <ogra> it was either a prob with .img files or a prob pointing to the right image location
[13:30] <NCommander> ogra, doesn't sound like a show stopper ... */2 cents*
[13:30] <ogra> it isnt
[14:03] <pitti> jjardon: sure, go ahead
[14:07] <blackxored> h3ll0 x 4all
[14:15] <directhex> cjwatson, if you're still in a mouseemu bug-squashing mood, #362500 appears to be a real bug along similar lines
[14:34] <cjwatson> directhex: probably not just at the moment ...
[14:38] <jjardon> pitti, done
[14:39] <jjardon> also upstream buf filled for GDM: http://bugzilla.gnome.org/show_bug.cgi?id=593787
[14:40]  * pitti chuckles at http://xkcd.com/619/
[14:41] <pitti> jjardon: thanks!
[14:54] <dayanandasaraswa> Hello all, I want to know all about ext2 filesystem. I want to know its superblock structure and where all the information is stored..Where can I get all these?
[14:56] <cjwatson> dayanandasaraswa: the kernel source - include/linux/ext2_fs.h, include/linux/ext2_fs_sb.h, fs/ext2/
[14:57] <cjwatson> and Documentation/filesystems/ext2.txt of course
[14:57] <jdstrand> seb128: re bug #414506> yeah, pitti is right. it also happens to be a dupe of bug #412551 (marked as such)
[14:57] <dayanandasaraswa> cjwatson: Oh thank you..I'll take a look at them..:D
[14:57] <seb128> jdstrand, ok thanks
[14:58] <dayanandasaraswa> I'm actually in need of copying the whole ext2 filesystem's datastructures. Will e2image do that reliably? I actually want a replica of my HDD's filesystem's datastructures so that I can examine them separately for my project..
[14:59] <cjwatson> have you read the documentation? :-)
[15:00] <dayanandasaraswa> cjwatson: No, I have not :{
[15:00] <dayanandasaraswa> :P
[15:00] <dayanandasaraswa> cjwatson: I'm just now going to do that..But wanted to know the tools before hand :D
[15:00] <cjwatson> e2image is probably the right tool
[15:01] <dayanandasaraswa> cjwatson: Thank you so much :D
[15:08] <mathiaz> slangasek: yes - two test cases are for EC2 and one for UEC
[15:09] <mathiaz> slangasek: thanks for setting things up on the tracker
[15:10] <robbiew> cjwatson: with evand on vacation, do we have anyone else familiar with usbcreator?  bug 422071 is a pain in the @$$
[15:11] <cjwatson> robbiew: nobody really directly, although I should think anyone familiar with Python could sort it out
[15:12] <robbiew> cjwatson: not a big deai...can wait
[15:12] <robbiew> he's back tomorrow
[15:13] <robbiew> thanks
[15:13] <teknico> superm1, hi, may I ask you something about a malfunctioning fglrx driver?
[15:13] <superm1> teknico, AMD hasn't published a supported driver for karmic yet AFAIK
[15:14] <teknico> superm1, oh, it's curious, the latest Catalyst also builds deb packages for karmic
[15:14] <teknico> but it doesn't work, so I guess you're right :-)
[15:14] <superm1> teknico, the packaging is ready to go, they just need the appropriate code changes
[15:15] <teknico> superm1, thanks, how will I know when it's ready?
[15:15] <superm1> teknico, it will be uploaded to karmic when it's ready
[15:16] <seb128> robbiew, I can fix that I know what the issue is
[15:16] <teknico> superm1, right, which reminds me that version 2:8.632-0ubuntu1 is already in restricted (and not working either)
[15:17] <robbiew> seb128: cool...thanks a lot
[15:17] <seb128> you're welcome
[15:17] <teknico> I'll wait for a new version
[15:20] <cjwatson> robbiew: fixed in bzr
[15:20] <cjwatson> seb128: oh, sorry, beat you to it :)
[15:20] <cjwatson> I didn't look back at this channel in the meantime ...
[15:20] <robbiew> lol
[15:20] <robbiew> thanks all
[15:21] <seb128> cjwatson, no problem, thanks
[15:21]  * robbiew thinks about throwing random bug numbers into the channel to see how quickly they get fixed :P
[15:22] <cjwatson> hmm, question is should I try to upload something for a5
[15:22] <cjwatson> I'm not sure of the state of the rest of the bits in bzr
[15:22] <cjwatson> I think I'd rather that wait for evand to return
[15:22] <sgallagh> mathiaz:
[15:22] <sgallagh> mathiaz: ping, rather
[15:22] <robbiew> cjwatson: sounds fine to me
[15:22] <mathiaz> sgallagh: hi
[15:23] <cjwatson> robbiew: http://bazaar.launchpad.net/~usb-creator-hackers/usb-creator/trunk/revision/142 if you just want to get the fix locally
[15:23] <seb128> cjwatson, I would upload a version based on the karmic one with only this change
[15:23] <seb128> that's what I did with update-manager yesterday
[15:23] <sgallagh> mathiaz: I wanted to let you know, we found, fixed and pushed a real change for that startup problem you were seeing (I gave you the band-aid patch for your beta release)
[15:23] <cjwatson> seb128: mm, might be best, will do
[15:23] <mathiaz> sgallagh: right - I saw the commit
[15:23] <seb128> cjwatson, thanks
[15:24] <mathiaz> sgallagh: thanks for working on this. I'll push a new package.
[15:24] <sgallagh> mathiaz: Ok, just wanted you in the loop.
[15:24] <mathiaz> sgallagh: thanks
[15:24] <sgallagh> mathiaz: Well, I'm still investigating the provider=legacy problem that's hanging the SSSD on ubuntu
[15:24] <ScottK> cjwatson: If your considering a usb-creator upload, rgreening has some usb-creator-kde changes too.
[15:24] <ScottK> He was waiting for evand to get back.
[15:24] <sgallagh> mathiaz: So you may want to wait until that's in before rolling a new package (though I don't know Ubuntu's process)
[15:25] <ScottK> It's (I understand it) broken now, so there's no downside risk to updating.
[15:25] <cjwatson> ScottK: I'm not qualified to review them
[15:25] <mathiaz> sgallagh: that's fine. we can fix bugs in different uploads
[15:25] <rgreening> ScottK, cjwatson: My changes have been uploaded to bzr branch. Just need to release 0.2.4 from bzr
[15:25] <cjwatson> ScottK: and there's other stuff in bzr too so it's rather a mess
[15:25] <cjwatson> sigh, ok, I'll attempt to review the lot :P
[15:25] <ScottK> cjwatson: Your call of course, but rgreening did the KDE port to start with, so I'd expect it's reasonable.
[15:26] <cjwatson> there's more than just his changes
[15:26] <ScottK> right
[15:26] <cjwatson> and I don't know if Evan's changes are pending some other dependency or something
[15:26]  * ScottK steps back and lets the guy who's doing the work decide.
[15:27] <rgreening> cjwatson: my changes make usb-creator-kde work again (mostly). There are some unimplemented bits in the backend evand wrote which cause FOrmat, and .iso images to not work, so I addressed in usb-creator-kde by temporarily disabling those buttons. CD-ROM install works.
[15:27] <rgreening> which is better than it is currently.
[15:28] <rgreening> also, I don't think the usb-creator-gtk works in either case (current or trunk), at least in my testing.
[15:28] <rgreening> cjwatson: I get "An unhandled exception occurred:
[15:28] <rgreening> Duplicate object id 'alignment3' on line 630 (previously on line 287)"
[15:29] <cjwatson> yes, I just fixed that in bzr, that's where we came in :)
[15:29] <rgreening> ok cool. then we should be able ot release.
[15:29] <rgreening> I've been testing from trunk on the kde one.
[15:32] <rgreening> cjwatson: I can confirm gtk version works now and did not impact kde version locally with the updated bzr.
[15:34] <cjwatson> rgreening: cool, that saves me some testing time, thanks :)
[15:34] <rgreening> np
[15:34] <rgreening> Im here to serve cjwatson :P
[15:35] <cjwatson> ok, uploading
[15:41] <Keybuk> cjwatson: thought of the day: the PPA system should allow you to upload to UNRELEASED
[15:44] <cjwatson> cr3: what are all these checkbox-generated reports landing on kbd? seems to be something to do with chvt failing, but it seems astonishingly unlikely that the problem is actually in the chvt program itself
[15:45] <cr3> cjwatson: kbd?
[15:51] <cr3> cjwatson: I see the problem, which package should it land against?
[15:53] <seb128> cody-somerville, urg, you want to get the old gdm back in karmic?
[15:53] <cody-somerville> seb128, Yes, as discussed.
[15:53] <seb128> discussed when where?
[15:54] <cody-somerville> seb128, here and several weeks ago
[15:54] <seb128> I don't think it's a good idea, it's going to create configuration handling issues for user switching between version
[15:55] <seb128> and it means we will have to reopen and reassign bugs and maintain old buggy code
[15:56] <cody-somerville> I don't like this anymore then you do. However, gdm has taken a different direction that doesn't make it suitable as desktop agnostic display manager.
[15:57] <seb128> what about trying to pick one of the other available?
[15:57] <seb128> ie xdm
[15:57] <cody-somerville> None of them are suitable
[15:57] <seb128> rather than pushing an unmaintained version of gdm back there
[15:57] <cody-somerville> Those other options aren't maintained either
[15:57] <seb128> why not?
[15:57] <cody-somerville> seb128, numerous security issues
[15:58] <seb128> who is going to assure the security of the old gdm codebase?
[15:58] <seb128> is that something you discussed with the security team already?
[15:58] <cody-somerville> seb128, The Xubuntu team will take responsibility for maintaining the package
[15:58] <seb128> that's going to be costy
[15:59] <cody-somerville> seb128, We're hoping to have the new gdm working for karmic+1
[15:59] <seb128> will you also be responsible for fixing issues due to switch between versions in both sides?
[15:59] <cody-somerville> seb128, We'll try our best to resolve any critical issues that presents.
[15:59] <cody-somerville> seb128, I've tried it out myself and I didn't run into too any trouble
[16:00] <seb128> what is not suitable in the new gdm?
[16:00] <seb128> the option taken there seems far to be optimal
[16:00] <seb128> I would rather spend efforts fixing the new ones than trying to bring both version together
[16:01] <cody-somerville> seb128, The issue isn't bugs, the issue is that they've decided to depend on other gnome components
[16:01] <seb128> how do you plan to fix that in karmic+1?
[16:02] <cody-somerville> seb128, I'm hoping to use our relationship with Xfce to have changes made to different Xfce components that will enable us to be able to drop them in place of the gnome ones.
[16:02] <mr_pouit> (so there is no plan)
[16:02] <seb128> hum, I think trying to bring previous gdm in karmic is not a good move
[16:03] <seb128> but shrug
[16:03] <seb128> if other people are fine with that
[16:03] <seb128> pitti, ^ opinion on that?
[16:06] <pitti> seb128: hm, cody-somerville's choice in the end; if there's no other option, xubuntu doesn't have much choice, I guess
[16:06] <pitti> however, I'm interested in the particular reasons
[16:06] <pitti> the alternative dependencies and components weren't enough? what was missing?
[16:07] <superm1> yeah, what particularly?  for the mythbuntu case, it appears to not be pulling in exorbitant amounts of gnome now, and working fine
[16:10] <cjwatson> cr3: problems changing tty are usually kernel bugs, AIUI
[16:10] <cody-somerville> Theres no way to set a system wide default session
[16:10] <cr3> cjwatson: I'll make the necessary changes, thanks
[16:10] <cody-somerville> People would login to xterm instead of xfce4 by default
[16:10] <superm1> oh, we're cheating with that for now, but i agree that's a problem
[16:11] <superm1> for mythbuntu, we're providing a gnome.desktop in mythbuntu-default-settings
[16:11] <ScottK> Maybe cody-somerville could use your cheat this cycle?
[16:11] <pitti> cody-somerville: that doesn't seem excessively hard to add, though
[16:12] <pitti> it could use "default.desktop" if present, and prefer that
[16:13] <superm1> there is a bug filed for that, bug 403291
[16:15] <cody-somerville> How about we accept gdm-2.20 and I'll continue to work out the kinks with the new gdm. If I'm satisfied by beta, we can remove gdm-2
[16:15] <cody-somerville> This is just a backup plan
[16:16] <superm1> isn't the autologin code in ubiquity (user-setup ?) already transitioned to the new gdm?
[16:16] <pitti> superm1: yes, it is
[16:16] <pitti> cody-somerville: was there any other blocker?
[16:17] <pitti> cody-somerville: sorting out the configuration issues seems to be more work to me than to teach gdm about a preferred session
[16:17] <cody-somerville> pitti, I found that the busy cursor was always present
[16:17] <pitti> I don't mind having gdm-2 in universe, but I feel it'd create more problems than it solves
[16:17] <cody-somerville> pitti, and I need to take care of theming as right now it looks like crap
[16:17] <pitti> right, we share _that_ problem :)
[16:18] <cody-somerville> which one? the busy cursor or the theming?
[16:19]  * cody-somerville goes to eat lunch.
[16:23] <pitti> cody-somerville: the theming; I don't see a busy cursor here
[16:42] <dholbach> Ubuntu Developer Week starting in 19 minutes in #ubuntu-classroom
[16:49] <kirkland> liw: ping
[16:50] <kirkland> liw: you asked once about changing the screen size of a kvm vnc window
[16:50] <kirkland> liw: in karmic, you now have 2 options
[16:50] <kirkland> liw: the window itself is dynamically resizable, doing the scaling/stretching of the bitmaps of the virtualized system
[16:51] <kirkland> liw: also, bryce committed a couple of fixes (hacks) to the xserver that should allow more different actual screen resolutions
[16:51] <kirkland> liw: enjoy ;-)
[17:03] <RainCT> :)
[17:03] <RainCT> (oops)
[17:03] <RainCT> seb128: Any plans to update gnome-shell & co?
[17:04] <seb128> RainCT, it's on my list but I just came back from vac yesterday
[17:04] <seb128> and I had other things I wanted to get on the coming alpha
[17:05] <seb128> RainCT, you can do it if you want or I will do it later this week
[17:06] <RainCT> seb128: Okay, I may take a look at it. I'm also wondering whether seed will be in Karmic (or rather, if there's any reasons why it isn't in Karmic and it can get a FFe)?
[17:07] <seb128> RainCT, I would just say ETOOMUCHTODO
[17:07] <seb128> RainCT, but it's in debian now I will sync it
[17:09] <RainCT> seb128: Oh, right - Cool! There's also an updated gobject-introspection there.
[17:10] <seb128> RainCT, will look into that too
[17:56] <fbond> What are the ballpark odds that Ubuntu will switch to connman from NetworkManager?
[17:57] <pitti> fbond: for karmic? 0
[17:57] <pitti> fbond: (feature freeze)
[17:59] <fbond> pitti: No, not for karmic, for karmic+1, karmic+2, etc...
[18:00] <fbond> Mostly trying to get a sense for the developer sentiment.
[18:00] <pitti> fbond: I think it's safe to say that it won't happen for karmic+1, since it's LTS and we won't change infrastructure much; beyond that, nothing is decided yet
[18:00] <pitti> fbond: asac might have a qualified feeling, though
[18:00] <fbond> pitti: Okay, thanks.
[18:00] <fbond> asac: thoughts on ConnMan?
[18:02] <asac> fbond: well. so far there is not even a UI ... except for netbooks.
[18:03] <asac> connman is really young projects. so i would lean towards saying it wont be ready for serious karmic+1 consideration
[18:03] <asac> but you never know
[18:03] <asac> we keep our eyes open
[18:03] <fbond> asac: Hm, I thought there was a connman-gnome project.  That is for netbooks only?
[18:03] <pitti> YokoZar: hey!
[18:04] <pitti> YokoZar: we were wondering about the status of desktop-karmic-wine-integration; is that still likely to hit karmic (with some FF), or should we call it postponed for Karmic+1?
[18:06] <asac> fbond: thats abandoned upstream atm
[18:06] <asac> fbond: we even have the package, but its not developed upstream for the time being.
[18:06] <mvo> apachelogger: many thanks for the apturl kde frontend, I'm uploading now
[18:07] <apachelogger> \o/
[18:07]  * asac dances
[18:07] <Riddell> yay
[18:08] <asac> so i can now depend on apturl without pulling in gnome?
[18:08] <asac> mvo: ?
[18:08] <mvo> asac: apturl-kde
[18:08] <asac> Riddell: will you install that by default?
[18:08] <mvo> asac: or how do you mean? you can depend on apturl | apturl-kde
[18:08] <asac> otherwise i cannot say "apturl | apturl-kde"
[18:08] <asac> which would pull in apturl still
[18:09] <asac> mvo: if apturl-kde isnt installed by default it would be better to put it into the same package i guess ... and make that to only depend on stuff thats already there
[18:09] <asac> but i guess it should just be seeded
[18:10] <mvo> asac: yeah, having it in a single package is not very elegant
[18:17] <sgallagh> mathiaz: ping
[18:18] <apachelogger> asac: yeah, should be seeded, especially since it integrates with konqueror anyway
[18:18] <apachelogger> + it doesn't introduce any new deps
[18:19] <sebner> apachelogger: first is has to build though :P
[18:19] <asac> apachelogger: ok. will you take care of the seeding?
[18:19] <asac> or rather Riddell ?
[18:19] <apachelogger> can do
[18:19] <asac> anyway. let me know when thats done so i can adjust the depends of ubufox
[18:20] <Riddell> one of us will
[18:20] <asac> thx
[18:20] <asac> oh
[18:20] <asac> do apturl and apturl-kde conflict?
[18:20] <asac> or are you parsing some env to call the right backend if both are installed?
[18:20] <apachelogger> Riddell: first you need to poke apturl-* through binary new anyway :P
[18:20] <sgallagh> mathiaz: What configure flags do you use for SSSD when packaging?
[18:21] <apachelogger> asac: apturl binary in apturl-common package looks for KDE_FULL_SESSION and starts -kde if that is set
[18:21] <apachelogger> if someone wants to enforce a certain frontend they might call apturl-kde or apturl-gtk directly
[18:21] <asac> apachelogger: good. i assume it falls back to any (if available) if the right desktop variant is not installed?
[18:23] <apachelogger> asac: if desktop is not proofen to be KDE it will use -gtk if it is installed, otherwise it starts whining
[18:24] <apachelogger> I suppose that could be made if ENVAR;elif -x -gtk; elif -x -kde; else; fi ... that way it would also try -kde if desktop is not kde which might make sense after all :)
[18:24] <asac> yeah. i think we should try all combinations if there is no match
[18:24] <asac> order probably doesnt really matter
[18:26] <mathiaz> sgallagh: hi - http://launchpadlibrarian.net/30797006/buildlog_ubuntu-karmic-amd64.sssd_0.5.0-0ubuntu1~ppa1_FULLYBUILT.txt.gz
[18:27] <mathiaz> sgallagh: ^^ this is the build log - you should be able to find the configure flags in there
[18:27] <sgallagh> mathiaz: Great, thanks. I just wanted to set up a script in my VM environment to build it equivalently to how you would
[18:29] <mathiaz> Riddell: hey - are you planning to process the NEW source queue today?
[18:32] <Riddell> mathiaz: yes, any requests?
[18:32] <mathiaz> Riddell: sssd would be interesting to process
[18:34] <ogra> pitti, kees, congrats for joining the TB !!!!
[18:36] <sgallagh> mathiaz: What does "processing" entail?
[18:36] <kees> ogra: thanks!  :)
[18:37] <mathiaz> sgallagh: review the source package and accept in the karmic archive
[18:37] <strider_> hi everyone
[18:37] <sgallagh> mathiaz: Ok, any issues you come up against, please log a bug.
[18:38] <mathiaz> sgallagh: sure
[18:38] <strider_> what's the best way to keep track of what is being done in the development of Ubuntu ?
[18:39] <sgallagh> strider_: Become a developer :)
[18:39] <strider_> well i am a developer, you mean an official Ubuntu developer ?
[18:40] <sgallagh> strider_: It was something of a joke. I meant that if you were a developer, then you can keep track of yourself :-P
[18:43] <slangasek> mvo: I don't see any reason bug #353534 should be a blocker for alpha-5 - is it in progress currently?
[18:45] <strider_> actually, i'm thinking about building a web platform to ease collaboration between developers , but I wanted to know how the things worked at the present moment. I'm missing a piece of the puzzle I guess
[18:48] <sgallagh> strider_: What sort of a platform?
[18:48] <sgallagh> strider_: Something like Fedora Community?
[18:48] <strider_> let's take a simple example, I just updated karmic, and  i saw that empathy was removed from the system, i was wondering "where does that come from ? who made that decision ? where can i find it on the web"
[18:49] <sgallagh> strider_: Yes please :)
[18:49] <strider_> well, something based on Google wave, so there's no equivalent at the moment ;)
[18:52] <strider_> Fedora community looks interesting
[18:54] <jcastro> strider_: we call it launchpad. :D
[18:54] <ogra> yeah
[19:00] <strider_> Launchpad is a great tool, but when interaction between developers is concerned there is obviously something missing
[19:00] <mvo> slangasek: no need to block - it was my target date, but we can move that to a6
[19:09] <ogra> seb128, do you plan more uploads during the freeze ?
[19:12] <robbiew-afk> slangasek: Ubuntu Repository of Software...UR Software for short
[19:12] <robbiew-afk> lol
[19:12] <slangasek> heh
[19:12]  * robbiew never left
[19:13] <sgallagh> How does one install the debuginfo for an ubuntu package to debug it?
[19:13] <ogra> there is a wikipage about that
[19:19] <pitti> ogra: thanks!
[19:19] <ogra> :)
[19:22] <Lutin> Compiling /usr/lib/pymodules/python2.5/ubuntutools/requestsync/lp.py ...
[19:22] <Lutin>   File "/usr/lib/pymodules/python2.5/ubuntutools/requestsync/lp.py", line 25
[19:22] <Lutin>     from ..lp.udtexceptions import *
[19:22] <Lutin> SyntaxError: 'import *' not allowed with 'from .'
[19:22] <Lutin> geser: when upgrading ubuntu-dev-tools ^
[19:25] <pitti> that might be a 2.6ism
[19:28] <pitti> tkamppeter: bug 419834 -- nice!
[19:28] <slangasek> bwuh, who switched ubuntu-dev-tools from python-central to python-support?
[19:29] <slangasek> DktrKranz: what does python-support have to do with "easing initial import into Debian"?
[19:30] <DktrKranz> slangasek: there are plans to migrate almost every package to pysupport
[19:31] <slangasek> whose plans?
[19:31] <DktrKranz> some discussions in debian-python
[19:32] <slangasek> there's a group of python package maintainers who think python-support is great and eschew python-central.  Just because they have plans doesn't make them relevant.
[19:32] <seb128> ogra: yes, why?
[19:33] <DktrKranz> even if pycentral will be dropped one day?
[19:33] <seb128> ogra: do you plan to ask other meaningless questions?
[19:33] <slangasek> DktrKranz: who is dropping pycentral?
[19:34] <slangasek> the maintainer isn't dropping it, so long as python-support's maintainer fails to address its known problems
[19:34] <rndm_> so /dev/fb0 isnt being created on aluminum 20inch imacs. the current livecd doesnt make it into x
[19:35] <slangasek> recent discussion on debian-python consists of "we should have a single tool; neither python-support nor python-central is it"
[19:35] <ogra> seb128, well, the armel buildds are 100% busy with kde stuff that was coming in yesterday, and i'd like to make A5 with arm given that we couldnt make A4 already and i'd like to match my deliverables at some point
[19:36] <seb128> ogra: I did read the freeze email after this upload and I don't plan to break CD builds no
[19:37] <ogra> thanks a lot
[19:37] <ogra> (i dont mean to attck you or something with these questions, i just want to be prepared what to expect)
[19:37] <DktrKranz> there are indeed open issues for both tools
[19:38] <rndm_> not sure what to file a bug report against. installing from alternate and then installing the nvidia drivers works as a work around but you have to manually supply an xorg.conf to get around x barfing over no fb dev
[19:39] <DktrKranz> Many sponsors will prefer pysupport over pycentral because the latter is known to have some more problems
[19:39] <seb128> ogra: I usually try to not disturb things too much but to not block work or changes too much either
[19:39] <ogra> seb128, yeah, i know and i know you enough to know that :)
[19:40] <DktrKranz> and *I* (this won't mean *all*) think (based on practice) pysupport behaves well.
[19:41] <slangasek> ArneGoetje, pitti: what are these language-pack-gnome-* packages that have been lingering in the uninstallable list, with no corresponding language-pack-*?  (ig,ks,pap,sa,shs,tk)
[19:43] <pitti> slangasek: ah, I bet langpack-o-matic doesn't create empty language-pack-*; however, -gnome isn't actually supposed to have a hard depends: on the common langpack
[19:44] <slangasek> DktrKranz: it behaves in ways that work most of the time, are pathological some of the time, and the maintainer has shown himself unwilling to address those cases.
[19:44] <slangasek> pitti: well, even a Recommends: would show up on the report, we want Recommends to be fulfilled as well :)
[19:45] <pitti> slangasek: seems we need to teach langpack-o-matic to create empty common langpacks then, or drop the depends
[19:45] <slangasek> DktrKranz: anyway, maybe you'll find sponsors into Debian more easily that way, but I won't be one of them <shrug>
[19:51] <DktrKranz> slangasek: I always found joss very collaborative, but that's probably just me. Are there issues with that change? If so, I will invest time fixing my mistakes.
[19:55] <pitti> slangasek: bug 422760
[19:58] <slangasek> DktrKranz: I don't see any technical problems with it, I just noticed the change when looking at the install-time bug mentioned above
[19:58] <slangasek> DktrKranz: I'm just generally dismayed by the convergence on an imperfect tool that doesn't seem to be getting any better
[19:59] <slangasek> pitti: cheers
[20:09] <DktrKranz> slangasek: I was just trying to improve things (at least from my POV). If that will turn to be a bad decision, I will fix my errors. By the way, thanks for sharing your thoughts! :)
[20:15] <slangasek> DktrKranz: well, now that we've had this conversation I understand your reason for the change; it doesn't make me happy, but I can't claim that it's wrong ;)
[20:16] <slangasek> DktrKranz: fwiw, in a sense ubuntu-dev-tools is now still blocked on "solving" the python politics in Debian anyway
[20:16] <slangasek> because requestsync now uses python 2.6-specific syntax, and python 2.6 being the default in Debian depends on resolving certain compatibility issues
[20:18] <slangasek> (you're welcome to fix the 2.6-specific syntax problem, if you prefer, but in the meantime I'm making the package installable again :)
[20:22] <pitti> ttx: euca needs a Java Excel API? interesting...
[20:25] <tkamppeter> pitti: HP is really the best printer manufacturer in terms of supporting Linux.
[20:26] <pitti> tkamppeter: :)
[20:26] <pitti> it actually seems that we can ship Karmic without any old PK stuff except for hal (which we don't even use any more)
[20:26] <pitti> the only reason why we still need the old PK is because KDE still uses hal to mount internal drives
[20:27] <pitti> but well, we'll settle that in karmic+1, I hope
[20:32] <slangasek> mathiaz: you merged squid three weeks ago, but haven't been bothered that it's been uninstallable since? :-)
[20:47] <ttx> pitti: not really. It needs drools, and drools provides some statistics thing that can output Excel, I suppose. But Euca doesn't make use of that specific drool feature
[20:47] <pitti> ttx: it's just funny how it manages to pull in so much stuff it doesn't need
[20:48] <ttx> pitti: it's the miracle of java libraries build dependencies. Multiplication of packages.
[20:49] <ttx> <insert biblic reference here>
[20:57] <YokoZar> pitti: If I work like crazy this week, I think it can go in
[20:58] <YokoZar> The actual Wine 1.2 release won't be until Karmic +1 though, so I need to tweak all the dialogs and handle the dual-install case and such (since we need to ship both wine 1.0 and the latest beta, the "wine1.2" package)
[21:09] <mathiaz> slangasek: where did you notice the squid package was uninstallable?
[21:09] <slangasek> mathiaz: http://people.canonical.com/~ubuntu-archive/testing/karmic_probs.html
[21:10] <slangasek> mathiaz: squid-langpack is a new source package that hasn't been synced; I'm doing that now
[21:10] <mathiaz> slangasek: ok - thanks for taking care of this.
[21:11] <slangasek> or at least, I'm trying to do that, if it ever bothers to show up in the queue :)
[21:16] <ttx> pitti, about bug 422788: my understanding was that we should fix the packages so that they don't use the deprecated java-*-compat-* virtuals but properly depend on the new *-jdk stuff instead. That is, if something only builds with gcj, it should build-dep on gcj-jdk. See https://wiki.ubuntu.com/JavaTeam/LibraryPackaging
[21:17] <pitti> ttx: hm, I'm afraid I don't know that; doko?
[21:17] <pitti> hm, -ENODOKO
[21:17] <ttx> pitti: I don't think we *need* to migrate all gcj-jdk stuff to build with openjdk for this release
[21:17] <pitti> I thought doko was trying to get rid of gcj
[21:17] <ttx> pitti: I can try, obviously, but I wouldn't make that a blocker
[21:17] <pitti> but ICBW
[21:18] <ttx> pitti: in karmic+1, methink
[21:18] <pitti> ttx: so if you think gcj is correct, leave it like it is now, make a comment on the bug, and WONTFIX the karmic task
[21:18] <pitti> (main task shuold still be kept open, I think)
[21:18] <ttx> yes.
[21:22] <jono> bryce, have you had any reports of current Karmic crashing when alt-tabbing with compiz switched on?
[21:22] <bryce> jono, yes
[21:22] <bryce> jono, not crashing so much as locking up
[21:22] <jono> bryce, yeah, it locked my machine, I had to perform a hard reset
[21:22] <jono> and now I can't switch compiz back on
[21:22] <jono> cool, just wanted to check if you were aware
[21:23] <bryce> jono, I have a fix, one sec
[21:23] <jono> bryce, no rush, I can run without compiz until the fix is in
[21:23] <bryce> jono, install this:  http://people.canonical.com/~ogasawara/lp419264/
[21:24] <jono> thanks bryce :)
[21:24] <ogasawara> bryce: fyi looks like this patch also got merged upstream
[21:24] <bryce> jono, as a workaround when it locks up, do ctrl-alt-f1 and then kill the compiz process and you can recover your session
[21:24] <bryce> ogasawara, excellent news
[21:24] <ogasawara> bryce: tim just pulled my backport but we'll only need to carry it shortly until the next upstream rebase
[21:24] <bryce> great
[21:25] <bryce> ogasawara, thanks again for quick work with that patch :-)
[21:25] <jono> thanks bryce, ogasawara :)
[21:25] <ogasawara> bryce: no worries, it's easy when they're already on their way upstream
[21:33] <sivang> anybody remember what's simon law's nick ?
[21:34] <jono> sflaw?
[21:36] <slangasek> seb128: empathy's .pc file references telepathy-glib, but the -dev package doesn't depend on it; this breaks rebuilding desktop-data-model - should I just commit a fix to bzr and let you pick it up for next upload?
[21:37] <slangasek> no, wait, this branch is ~ubuntu-desktop, I guess I can't commit there... and the branch isn't up to date anyway
[21:38] <seb128> slangasek, you can commit there
[21:38] <slangasek> oh, ok
[21:38] <geser> Lutin: bah, another error :( I guess pitti is right, relative imports are a 2.6ism
[21:38] <slangasek> seb128: still, the branch doesn't seem to be up-to-date with the archive?
[21:38] <seb128> slangasek, let me push my changes
[21:38] <slangasek> seb128: ok
[21:39] <slangasek> seb128: thanks :)
[21:39] <taavikko> what controls usb devices in *.31 kernels*? in jaunty one could "rmmod uhci" and reload to gain function
[21:42] <seb128> slangasek, changes pushed to bzr now
[21:47] <mkoehler> hey guys, I've got a quick question for ya'll.  I'm looking to work on making some patches for some bugs on launchpad, but I'm not sure exactly which ones to go after.
[21:47] <mkoehler> I was looking at a few programs (e.g. nautilus), but a lot of the bugs are marked as upstream bugs
[21:48] <mkoehler> I was just wondering when something should be marked as an upstream bug (I've read the wiki a couple of times) and if there's a good project to work on
[21:50] <ulaas> mkoehler, add quick view to nautilus
[21:50] <mkoehler> is that related to a bug (wishlist or otherwise) that I can look at?
[21:51] <ulaas> mkoehler, nope. but i think your name will be remembered if you make it work :)
[21:51] <seb128> mkoehler, ubuntu doesn't write most of the softwares it distribute
[21:51] <johanbr> mkoehler, I guess the "papercut" bugs would be a good place to start
[21:51] <johanbr> https://wiki.ubuntu.com/PaperCut
[21:51] <seb128> bugs in the upstream code are upstream issue
[21:51] <mkoehler> yeah
[21:52] <mkoehler> is there any way to just see those in launchpad
[21:57] <ulaas> gnome-shell !!!! yay
[22:28] <Kamusin> I sent an email about next ubuntu hugday (is waiting for moderation), can anyone take a look  please :)
[22:32] <Kamusin> (this email was sent to ubuntu devel list!, I forgot say that heeh)
[22:34] <slangasek> mathiaz: oh; turns out squid-langpack was already in, but had been left in universe, heh that's why it didn't hit the queue
[22:54] <lifeless> slangasek: haha
[23:08] <cody-somerville> Does anyone know how to use python apt to get information about a specific version of a package?
[23:09] <lifeless> cody-somerville: yes
[23:09] <slangasek> lifeless: "haha" on squid?
[23:09] <lifeless> slangasek: yes
[23:09] <lifeless> slangasek: not in a hostile fashion :)
[23:09] <lifeless> cody-somerville: what do you need to do vis a vis package data?
[23:11] <arpu> hello
[23:11] <cody-somerville> lifeless, err.... say again? :)
[23:11] <arpu> anyone know an ubuntu ppa kernel with this Patch ? http://bugzilla.kernel.org/attachment.cgi?id=22180
[23:11] <lifeless> cody-somerville: 08:08 < cody-somerville> Does anyone know how to use python apt to get information about a specific version of
[23:11] <lifeless>                          a package?
[23:12] <cjwatson> http://en.wikipedia.org/wiki/Vis-%C3%A0-vis
[23:12] <cjwatson> if the problem is comprehension
[23:14] <cody-somerville> ah
[23:15] <cody-somerville> lifeless, I just want to grab the file path
[23:15] <lifeless> of the deb ? in the repo ?
[23:16] <cody-somerville> lifeless, yes
[23:16] <lifeless> cjwatson: thanks :)
[23:17] <lifeless> gimme a sec, just grabbing the code conflict checker uses
[23:21] <lifeless> cody-somerville: do you want to be using the local packages cache for metadata; the code I have handy reads packages.gz and goes from there
[23:22] <cody-somerville> lifeless, I generate an "apt tree" and instruct python-apt to use that.
[23:22] <lifeless> ok
[23:22] <lifeless> 291 		
[23:22] <lifeless>                 sections = parser.Section
[23:22] <lifeless> 292 		
[23:22] <lifeless>                 info = self._extract_package_identity(sections)
[23:22] <lifeless> 293 		
[23:22] <lifeless>                 url = mirror + sections['filename']
[23:22] <lifeless> bah, loggerhead fail.
[23:22] <lifeless> anyhow, thats how I'm doing it at the moment
[23:23] <lifeless> thats inside a loop on the parser
[23:23] <lifeless>             parser = apt_pkg.ParseTagFile(local_file)
[23:23] <lifeless> 290 		
[23:23] <lifeless>             while parser.Step() == 1:
[23:23] <lifeless> you may be using a higher level, in which case this will be possibly useless :(
[23:24] <cjwatson> if you have an apt.Cache object, then cache[pkgname].candidate.filename
[23:27] <cjwatson> >>> import apt
[23:27] <cjwatson> >>> cache = apt.Cache()
[23:27] <cjwatson> >>> cache['man-db'].candidate.filename
[23:27] <cjwatson> 'pool/main/m/man-db/man-db_2.5.6-1_i386.deb'
[23:28] <cody-somerville> cjwatson, Thats what I'm doing but there are multiple versions of the package available.
[23:29] <cody-somerville> cjwatson, so I want to get the filename of the older version
[23:29] <cjwatson> >>> cache['man-db'].versions
[23:30] <cjwatson> <VersionList: ['2.5.6-1', '2.5.5-3']>
[23:30] <cjwatson> though only as of python-apt 0.7.9, I forget what one did before that
[23:31] <mathiaz> cjwatson: while trying to install uec node, there is a prompt for the username and password
[23:31] <mathiaz> cjwatson: would it make sense to preseed that as well?
[23:31] <mathiaz> cjwatson: in order to get the most automated installation experience?
[23:32] <cjwatson> mathiaz: it should already be preseeded to the same as was provided when installing the cloud controller
[23:32] <cjwatson> mathiaz: modulo the node preseeding stuff actually working, of course
[23:33] <cjwatson> mathiaz: see if http://CLUSTER-IP/node-preseed works
[23:43] <mathiaz> cjwatson: hm - passwd/user-password-crypted is preseeded
[23:43] <mathiaz> cjwatson: is the username automatically chosen?
[23:45] <cjwatson> the username should be preseeded too
[23:45] <cjwatson> question d-i passwd/user-fullname string
[23:45] <cjwatson> question d-i passwd/username string
[23:47] <mathiaz> cjwatson: neither in cloud.seed nor in node-preseed.conf
[23:47] <mathiaz> cjwatson: node-preseed.conf has passwd/user-password-crypted and preseed/late_command commented out
[23:49] <cjwatson> mathiaz: what does passwd/username look like in /var/log/installer/cdebconf/questions.dat?
[23:51] <mathiaz> cjwatson: it says that the value is set to ubuntu
[23:51] <mathiaz> cjwatson: we had to enter it manually though
[23:51] <mathiaz> cjwatson: I'll double check that we're prompted for username
[23:52] <mathiaz> cjwatson: the main bug we're run into is bug 422876
[23:57] <cjwatson> mathiaz: I just fixed that in bzr
[23:57] <mathiaz> cjwatson: great - thanks
[23:57] <cjwatson> mathiaz: the main *main* bug is that eucalyptus-cloud doesn't start on a fresh install
[23:57] <mathiaz> cjwatson: right - this is being worked on
[23:58] <cjwatson> I'm completely blocked on that at this point
[23:58] <cjwatson> more or less, anyway
[23:59] <cjwatson> mathiaz: ah, I see the problem with preseed file generation, fixing