[01:59] <Kano> hi,did you patch busybox in order to boot from ext4?
[02:16] <MattJ> http://paste.ubuntu.com/165234/
[02:17] <MattJ> Anyone an idea of what might be going wrong?
[02:20] <andersk> Maybe your pbuilder chroot is missing universe?
[02:21] <MattJ> Any idea how to add/check that? :)
[02:22] <MattJ> I've had pbuilder working before, and I think I did exactly the same as last time
[02:23] <andersk> `pbuilder --login` might be the easiest way.
[02:23] <MattJ> libidn11-dev is in main
[02:23] <MattJ> Ah
[02:23] <andersk> txt2man is not.
[02:32] <MattJ> Is there something I can do to make it persist? Changes seem to be lost as soon as I log out
[02:32] <MattJ> I guess I should go find some pbuilder manual :)
[02:32] <MattJ> I was following the packaging guide on the wiki
[02:34] <Hobbsee> use --save-after-login
[02:34] <Hobbsee> !pbuilder
[02:35] <MattJ> Thanks
[02:42] <MattJ> andersk: Looks like you were right, thanks :)
[02:50] <pedahzur> Hi!  Is there a similar kubuntu-devel list, or is it all done on this channel?
[02:51] <Hobbsee> pedahzur: sure, #kubuntu-devel
[02:52] <Hobbsee> and there's a kubuntu devel mailing list, in the same place as the ubuntu devel list
[02:52] <pedahzur> Hobbsee: Thanks...for some reason it didn't come up when I listed channels.  I should have just tried to join it. Sorry for the noise.
[02:52] <Hobbsee> pedahzur: no problem.  good luck!
[02:53] <pedahzur> Thanks!
[03:35] <the_dark_warrio> What is the Image Magick package for ubuntu?
[03:35] <TonyTheTiger> hello is this channel for development of ubuntu?
[03:36] <Pici> TonyTheTiger: yes.
[03:36] <Hobbsee> the_dark_warrio: apt-cache show imagemagick
[03:36] <TonyTheTiger> I am interested in writing a driver for a device i have, I dont mind taking time to learn how to do it.
[03:38] <the_dark_warrio> Hobbsee: Sorry, I'm looking for the dev packages.. I tried installing libmagick-dev, libmagick++-dev, libmagic-dev, etc. But everytime I install a new lib, I get another error trying to compile the code
[03:43] <TonyTheTiger> is there a channel for driver development for ubuntu?
[03:43] <Hobbsee> the_dark_warrio: i don't know, you'd have to give a pastebin of the errors
[03:44] <the_dark_warrio> Hobbsee: I'm getting help on Inkscape channel, I will see if they know what is the bug
[03:45] <Hobbsee> the_dark_warrio: OK, cool.  They'd probably know better anyway
[03:51] <the_dark_warrio> Hobbsee: thanks, I think I got it working now
[03:52] <Hobbsee> the_dark_warrio: hurrah!
[03:52] <the_dark_warrio> Hobbsee: ;) cia!
[03:59] <calc> can i get someone to process libbase-openoffice.org it is a new package that has built
[03:59] <calc> Hobbsee: do you have access for that? :)
[05:57] <calc> ooo 3.1.0~rc2-1ubuntu1 in process of uploading now :)
[05:58] <jdong> shiny!
[05:58] <jdong> will there be a PPA build?
[05:59] <calc> yea for h/i/j
[05:59] <calc> now i just have to upload around 600MB over my crap dsl
[05:59] <TheMuso> ouch
[06:01] <nixternal> dput-torrent :p
[06:02]  * calc wished he had access to somewhere will really good upload speed for times like this
[06:02]  * nixternal has 6mb up
[06:02] <calc> i have 512k :\
[06:03] <nixternal> though you can't tell when doing dput
[06:03] <nixternal> ya, 512 wouldn't cut it for me after getting used to 6mb
[06:04] <StevenK> calc: Get a VPS and rsync your uploads to it?
[06:08] <StevenK> % sudo rm -f /dev/sdb
[06:08]  * StevenK twitches a little
[06:08] <calc> StevenK: well i do upload to a server before dput but it still takes forever, i guess if i did all my building on a remote server it would be faster but then i would have to download any time i needed to test the packages
[06:09]  * calc just needs to move somewhere with fios
[06:09] <StevenK> calc: If your downstream connection is much faster, that sounds worthwhile
[06:10] <calc> well downstream is only 3M so not too much better
[06:10] <StevenK> calc: Find a better wet string?
[06:13] <Amaranth> hahahaha
[06:13] <calc> i'm about 800ft too far away to get 18/1
[06:13] <Amaranth> ouch
[06:14] <calc> i had faster internet than this 9 years ago :\
[06:14] <calc> back then i had 8/1 dsl
[06:14] <Amaranth> i've got 5/0.5
[06:15] <StevenK> Mine is roughly 6/256k
[06:16] <Amaranth> I used to have 3/256k so I'm moving up
[06:27] <Keybuk> cjwatson: heh, forgot to upload ;)
[06:27] <pitti> Good morning
[06:27] <pitti> NCommander: hi
[06:27] <NCommander> hey pitti, what's up?
[06:28] <pitti> NCommander: you pung me over night
[06:28] <TonyTheTiger> Hello guys how hard is it to write a driver for a device? (assuming I have programming background, but no experience in this topic)
[06:28] <NCommander> pitti, I think I was curious if I needed something spnsored but I don't remember
[06:31] <calc> pitti: can you approve libbase-openoffice.org (its stuck at new)
[06:37] <TonyTheTiger> Where can I view the source code to a driver?
[06:48] <maxb> i386 buildd has caught up :-)
[06:48] <lifeless> maxb: :)
[06:48] <lifeless> maxb: are you still contributing to cygwin?
[06:49] <pitti> TonyTheTiger: most device drivers are in the linux kernel nowadays (you can browse it in gitweb, or apt-get source linux); but there are all kinds of other drivers around (such as libgphoto for PtP cameras) which live in userspace; you have to be more concrete
[06:50] <maxb> lifeless: No, I fully extricated myself from Windows a while back
[06:51] <lifeless> I appear to have finally done that today
[06:51] <TonyTheTiger> pitti, I want to get my controller supported in ubuntu so I thought Ill go ahead and add support for it myself. Sick and tired of people tell me "do it yourself".
[06:53] <calc> ok in about 5 hours all 4 copies of OOo should magically appear, the three in the ppa and in karmic
[06:53]  * calc is headed to bed now
[07:18] <YokoZar> "All right here's a weird "bug" for you, if you want to call it that. The notifications cause my clock radio, which is about 5 feet away from my tower, to emit an audible vibration and buzzing noise. "
[07:24] <pwnguin> hahahaha
[07:28] <savvas> is it usb connected or wireless :p
[07:32] <dholbach> good morning
[08:37] <smb> Anybody knows by heart what method/config normally should start metacity and gnome-panel? After playing around with the desktop-switcher this does not happen automatically...
[08:40] <pitti> smb: gnome-session usually starts those through some .desktop files; seb128 would know more details
[08:40] <pitti> smb: ah, nevermind
[08:40] <pitti> smb: it's a gconf setting in gnome-session, /desktop/gnome/session/required_components_list
[08:41] <pitti>          <default>[windowmanager,panel,filemanager]</default>
[08:41] <seb128> right
[08:41] <seb128> the base composents are in gconf keys
[08:41] <seb128> autostart is for everything else
[08:41] <smb> Hm, I thought I saw those being there...
[08:48] <smb> seb128, Looking into the gconf-editor I find those keys. But it does not seem to happen. Any log files I might look into?
[08:48] <seb128> what did you change to break it ?
[08:48] <seb128> does it work for an another use on your box ?
[08:49] <smb> repeatedly using the desktop-switcher to go from the unr desktop to the standard and back
[08:49] <smb> seb128, let me add one and try
[08:49] <seb128> you can use the guest session to try
[08:50] <seb128> njpatel: ^ what is that desktop switcher doing?
[08:50] <seb128> it seems smb managed to unset required gconf keys by using it
[08:50] <njpatel> seb128: apart from screwing up some peoples desktops in it's current version in jaunty, it switches from netbook mode to classic mode (normal ubuntu look)
[08:51] <njpatel> seb128: I've already fixed the bug, and StevenK was going to help with an SRU
[08:51] <smb> njpatel, So it is a known "feature" then? :)
[08:51] <njpatel> (i've fixed it in a way that it repairs existing breakage too)
[08:51] <njpatel> smb: unfortunately. Couldn't get it in before release
[08:51] <njpatel> i hope we can get an sru soon
[08:52]  * njpatel hasn't done sru before, so any help would be appreciated
[08:52] <pwnguin> got the bug number handy?
[08:52] <seb128> njpatel: can you explain what to do change to manually fix it?
[08:52] <StevenK> njpatel: Step one: Fix it in Karmic
[08:52] <smb> Just was about to ask
[08:53] <njpatel> https://bugs.edge.launchpad.net/desktop-switcher/+bug/349519
[08:54] <njpatel> seb128: pwnguin ^
[08:54] <njpatel> StevenK: I've already made a release of desktop-switcher with the bug fixed, could we get that into karmic?
[08:54] <StevenK> njpatel: It's on LP?
[08:55] <pwnguin> heh
[08:55] <njpatel> StevenK: yep,it should be
[08:55] <StevenK> njpatel: Certainly, I'll do it tomorrow.
[08:55] <pwnguin> is stevenK still allergic to lp?
[08:55] <njpatel> StevenK: thanks!
[08:55] <StevenK> I was allergic?
[08:55] <pwnguin> perhaps my memory is foggy
[08:56] <pwnguin> it is 3am here
[08:56] <smb> njpatel, Thanks for the link. Looking at the runes now
[08:56] <njpatel> awesome, thanks
[08:57] <pwnguin> this raises a question for me
[08:57] <pwnguin> if a bug is known upstream and affects ubuntu
[08:57] <pwnguin> hmm. i should find, read and then quote what i saw earlier
[08:58] <pwnguin> rather than attempt to do anything from memory right now
[08:58] <StevenK> njpatel: Doing it now, since ... I don't know :-P
[08:58] <njpatel> :)
[09:00] <pwnguin> ""
[09:00] <pwnguin> thanks for the report, but there's no need to open the bug on Ubuntu if there's already one on the upstream bug tracker, it only creates extra work for developers and triagers, thanks.
[09:01] <pwnguin> how does that mesh with the SRU process?
[09:01] <StevenK> It should be tracked in Ubuntu Karmic and Ubuntu Jaunty for the SRU process
[09:02] <pwnguin> https://bugs.launchpad.net/ubuntu/+source/evolution-mapi/+bug/351493
[09:02] <pwnguin> i guess i dont understand what the triager is asking for on this bug
[09:02] <pwnguin> dont report bugs in LP if they're already upstream in bugzilla?
[09:03] <StevenK> njpatel: I'm going to twiddle that bug to add a desktop-switcher task for Karmic and Jaunty.
[09:03] <StevenK> njpatel: The Karmic task will get closed after I upload
[09:03] <njpatel> okay, thanks. and I'll hassle seb128 later on today :)
[09:04] <maxb> Well, there's no real point reporting to LP if it's already upstream, *unless* it's for the specific purpose of nominating for SRU
[09:06] <seb128> pwnguin: there is no need to report upstream bugs in launchpad if they are already known upstream yes
[09:06] <StevenK> njpatel: Uploading
[09:06] <StevenK> s/ing/ed/
[09:09] <smb> njpatel, cool, manually fixed it here. thanks
[10:04] <cjwatson> pitti: would you mind if I disabled pkgsanitychecks for udebs? http://launchpadlibrarian.net/26375427/buildlog_ubuntu-karmic-i386.rootskel-gtk_1.15ubuntu1_FAILEDTOBUILD.txt.gz is an interesting build failure - the udeb just installs a /usr/local/etc symlink to work around some problem elsewhere
[10:05] <pitti> cjwatson: no problem at all
[10:05] <cjwatson> pitti: while this should probably be dealt with so it doesn't need to do that, none of the checks in pkgsanitychecks really seem all that important for udebs; it's not as though it's important to provide the sysadmin with an area where his local changes will be preserved :-)
[10:05] <pitti> exactly
[10:05] <cjwatson> (I've uploaded rootskel-gtk with NO_PKG_MANGLE=1 for now, but ...)
[10:06] <pitti> I think udebs just weren't taken into consideration when this was written
[10:06] <cjwatson> this is the first time I've noticed it failing
[10:06] <cjwatson> is there a bzr branch for pkgbinarymangler?
[10:06] <pitti> no, this isn't in bzr
[10:06] <cjwatson> ok
[10:17] <pitti> Keybuk: \o/ system-tools-backends finally dropped its init script
[10:50] <pitti> cjwatson: intrepid-proposed doesn't have a matching d-i for the -14 kernel; how important is it to be in sync?
[10:51] <pitti> cjwatson: the kernel team asked me to move the -proposed kernel to -updates, but I stalled it because I wasn't sure about the impact of this
[10:57] <cjwatson> pitti: there's one in the queue ...
[10:58] <cjwatson> the problem with them getting out of sync is that the installer images previously published in intrepid-updates will break
[10:59] <cjwatson> it won't break people using the images in dists/intrepid/, but I know there are some people using the images in intrepid-updates, due to bug 293586 if nothing else
[10:59] <cjwatson> so I like to keep them in sync
[10:59] <cjwatson> people would still have to download fresh installer images; there isn't much to be done about that
[11:04] <pitti> cjwatson: ok, I'll accept the upload for that (thanks), and let it build, before I move it then
[11:05] <pitti> cjwatson: also, I was told that after copy-package'ing d-i for hardy, there's some extra magic necessary to copy the netboot images; is that documented somewhere?
[11:05] <pitti> I'm sure I did that once like a year ago, but I'm afraid I forgot it
[11:24] <ebroder> pitti: for bug #362691, I guess I need to get approval from ubuntu-sru again?
[11:25] <pitti> ebroder: haven't looked at the patch yet
[11:25] <ebroder> Ah, ok. No worries, then
[11:25] <pitti> ebroder: but usually, it's more a question of finding a sponsor to upload it
[11:25] <cjwatson> pitti: documented on ArchiveAdministration now
[11:25] <pitti> (someone from server team, preferably)
[11:25] <pitti> cjwatson: thank you
[11:29] <pitti> ebroder: commented now
[11:31] <ebroder> pitti: The version numbering still needs to be consistent, right? So this would still be 3.3.0-1ubuntu9.2, not 3.3.0-1ubuntu9.1?
[11:32] <pitti> ebroder: right, 9.1 got burned now
[11:45] <Keybuk> pitti: sweet
[13:12] <lamont> Keybuk: debian bug 527229
[13:23] <soren> Why is it that /etc/localtime is a copy of a timezone file rather than a symlink to it? Is it to make sure things don't fall apart before /usr is mounted or is there more to it than that?
[13:23] <cjwatson> soren: your hypothesis is correct
[13:25] <ion_> Let’s get rid of /usr already. :-P
[13:27] <directhex> ion_, http://gobolinux.org/?page=at_a_glance
[13:28] <cjwatson> note how it has no users ;-)
[13:28] <cjwatson> (to a first approximation)
[13:28] <ion_> directhex: Capital letters in filenames are just bad as long as we have a case-sensitive filesystem. Or have they changed that as well?
[13:31] <directhex> dunno
[13:31] <directhex> but points for doing something different!
[13:31] <directhex> not sure how LSB-compliant they are ;)
[13:47] <Keybuk> lamont: oh?
[13:47] <Keybuk> lamont: well, firstly I sent you a patch to use /dev/rtc0 rather than /dev/rtc <g>
[13:48] <Keybuk> lamont: ask them what hwclock --debug --rtc=/dev/rtc0 says?
[13:48] <soren> cjwatson: Lovely, thanks.
[14:28] <Keybuk> seb128: how do I debug telepathy/jabber not working?
[14:28] <Keybuk> it just says "Network error"
[14:28] <Keybuk> but it doesn't even look like it's starting telepathy-gabble
[14:30] <cjwatson> mvo: funky apt-ftparchive failure in http://launchpadlibrarian.net/26391921/buildlog_ubuntu-karmic-armel.debian-installer_20081029ubuntu35_FAILEDTOBUILD.txt.gz
[14:30] <cjwatson> apt-ftparchive: symbol lookup error: /usr/lib/libstdc++.so.6: undefined symbol: __sync_fetch_and_add_4
[14:31] <mvo> cjwatson: sweet
[14:31] <mvo> cjwatson: I have a look
[14:32] <cjwatson> ta
[14:32] <seb128> Keybuk: http://telepathy.freedesktop.org/wiki/Debugging
[14:32] <cjwatson> slangasek: d-i is in place on i386 now; awaiting build on amd64
[14:33] <ogra> oooh, there is an image build attempt from last night !
[14:33]  * ogra didnt notice yet
[14:33] <cjwatson> it won't be very useful
[14:33] <ogra> the desktop one ?
[14:33] <cjwatson> err, and where do you see this attempt? :)
[14:33] <ogra> http://cdimage.ubuntu.com/ports/daily-live/20090506
[14:34] <seb128> Keybuk: or ask Zdra or cassidy on the #ubuntu-desktop channel ;-)
[14:34] <cjwatson> oh, a livefs build attempt
[14:34] <cjwatson> http://cdimage.ubuntu.com/ports/daily-live/20090506 is pretty useless since it was still trying to build for jaunty
[14:34] <ogra> yeah, i just see that
[14:34] <ogra> old kernel and all
[14:35] <cjwatson> I changed cdimage to default to karmic this morning
[14:35] <ogra> ah
[14:35] <ogra> ok, waiting for the explosion of the image with teh next build then :)
[14:35] <cjwatson> mvo: FWIW, apt-xapian-index is currently uninstallable due to insufficient versions of python-apt and python-debian
[14:36] <james_w> there is a sponsor request open for the python-debian merge
[14:39] <mvo> cjwatson: thanks
[14:39] <mvo> cjwatson: I take care of this too (the python-apt merge is almost ready)
[14:40] <cjwatson> hyperair: I'm syncing nautilus-share, since it seems possible now and the older version causes livefs build problems (http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu/latest/livecd-20090506-i386.out)
[14:45] <calc> hmm really uploading now, i forgot that i needed to adjust the at time due to uploading from a server not in my own timezone :-\
[15:10] <hyperair> cjwatson: sure.
[15:11] <xaaab> Hi. I've been using 8.04 for a long time without problems. but since my upgrade to 9.04, my xorg has a memory leak. when I leave it running for several hours it consumes almost 5 gb of ram and it consumes a lot of CPU time, although I'm not at my PC. is this a known issue? any fixes?
[15:12] <pitti> xaaab: it certainly doesn't happen for everyone in that magnitude
[15:13] <cjwatson> you might want to use xrestop to find out whether it's actually the X server's fault directly or whether it's due to some application leaking pixmaps into X
[15:14] <soren> xrestop, eh?
[15:14]  * soren apt-gets
[15:14]  * xaaab just did
[15:15] <xaaab> cjwatson, so... when I start xrestop, I just have to watch what the "total" column says and identify the culprit?
[15:17] <cjwatson> it's a place to start to avoid embarrassingly claiming that it's the X server's fault when it's actually a particular application, anyway. I'm no expert so have no more help to offer :)
[15:26] <calc> ok all of OOo is uploaded now and waiting to build
[15:55] <mok0> Why does "Build-Depends: a | b" fail, even though b is available?
[15:59] <mok0> Ah sbuild does that by default.
[16:00] <slangasek> cjwatson: yippee :)
[16:07] <directhex> mok0, s/by default/because it hates humans/
[16:08] <directhex> mok0, as far as sbuild is concerned, anything after a | in a build-dep may as well be a comment
[16:08] <mok0> directhex: it appears you can change its behaviour... but I can't get that to work either
[16:09] <TheMuso> dtchen: we have 1.0.20 of alsa. I will check tomorrow to see if there are any kernelspace/userspace differences that need to be sorted before we can bump to 1.0.20.
[16:09] <mok0> directhex: sbuild -d karmic --check-depends-algorithm=alternatives
[16:09] <mok0> grrrrr
[16:10] <directhex> mok0, convince all the debian buildd admins to make that happen and we'll talk
[16:10] <mok0> directhex: sounds like you know something I don't
[16:12] <cjwatson> we hacked it in Ubuntu to fall back to non-primary alternatives
[16:12] <cjwatson> but that was precisely because we weren't Debian
[16:13] <cjwatson> I mean, the fact that it's done in Ubuntu is not a demonstration that it should be done in Debian - we were doing it because in places we wanted to specifically avoid the primary alternative in Ubuntu
[16:13] <mok0> cjwatson: it seems that doesn
[16:13] <mok0> t work...
[16:13] <cjwatson> in Debian, I fail to see why you wouldn't just put the alternative you want first!
[16:13] <mok0> cjwatson: right
[16:13] <cjwatson> mok0: used to, talk to infinity if you have a clear demonstration of the problem
[16:14] <mok0> cjwatson: "infinity" is a nick, right? :-)
[16:14] <ogra> heh
[16:14] <cjwatson> yes
[16:14] <ogra> for a person, yes
[16:15]  * apw goes a bit mad ... anyone know what is driving OSD for volume?
[16:15] <mok0> infinity: are you here?
[16:15] <apw> (audio volume)
[16:15] <ogra> apw, hal ?
[16:15] <ogra> (just a guess)
[16:15] <apw> i can't see it doing it ...
[16:16] <apw> it seems to generate a hal event for the volume-up key
[16:16] <ogra> dbus-monitor should show where its coming from
[16:17] <ogra> apw, gnome-settings-daemon it seems
[16:17] <ogra> at least for my system here
[16:17] <apw> hrm ... obviously
[16:17] <apw> thanks ogra
[16:17] <slangasek> cjwatson: the libgnomecanvas2-dbg binary on amd64 is timestamped May 6 01:05, which seems to postdate your new-binary-debian-universe fix; strange
[16:18] <cjwatson> any archive admin remember accepting libgnomecanvas/amd64?
[16:20] <seb128> I didn't
[16:29]  * pitti didn't
[16:33] <directhex> wasn't me
[16:43] <jdstrand> pitti: hi! can you look at the debdiff I attached in bug #224365? I'd like to upload, but wanted to make sure I didn't step on your toes. :)
[16:45] <pitti> jdstrand: well, someone already uploaded an ubuntu specific package, so that's fine
[16:46] <pitti> jdstrand: I'll commit the changes to bzr and sync them back from debian soon
[16:46] <pitti> jdstrand: so please go ahead
[16:48] <jdstrand> pitti: thanks! :)
[16:50] <jdstrand> pitti: looking at this, would you prefer I upload based off of jaunty's ubuntu3?
[16:50] <jdstrand> pitti: karmic still has the sync'd version from jaunty
[16:50] <jdstrand> (ubuntu1)
[16:50] <pitti> jdstrand: you can, but it really doesn't matter much; I'll thrash the ubuntu specific version soon anyway :)
[16:51] <pitti> jdstrand: so in fact, if you don't consider it super-urgent, just add the debdiff to the bug and assign it to me
[16:51] <pitti> and I'll get it done tomorrow
[16:52] <jdstrand> pitti: no, it isn't super urgent. I'll assign it to you to reduce archive churn
[16:52] <pitti> jdstrand: argh, I'm not going to apply that -- dac_override?
[16:53] <pitti> jdstrand: that's precisely what I don't want to give to hacks like cups-pdf
[16:53] <jdstrand> pitti: yeah, it is required when $HOME is 700
[16:53] <pitti> *shrug* then don't set it to 700 :)
[16:53] <pitti> 701 is fine as well, you also need it for public_html and such
[16:53] <jdstrand> pitti: sure, but the problem is that the error message is totally cryptic for the end user
[16:53] <pitti> jdstrand: I really wouldn't like to see cups-pdf getting more privs that it absolutely needs
[16:54] <pitti> jdstrand: that should probably be improved then, yes
[16:54] <jdstrand> pitti: basically, the user sees nothing in the ui
[16:54] <jdstrand> pitti: and then in kern.log, has:
[16:55] <jdstrand> kernel: [33228.304167] type=1503 audit(1241581234.818:31): operation="capable" name="dac_override" pid=4905 profile="/usr/lib/cups/backend/cups-pdf"
[16:55] <jdstrand> to me, that doesn't scream 'you need to chmod 701 your directory' :)
[16:58] <jdstrand> pitti: also, this isn't as simple as "don't chmod 700 your directory" because encrypted home directories via ecryptsfs do precisely that, and I think in karmic, kirkland is hoping to make this generally available
[16:59] <jdstrand> of course, he could 701 it...
[16:59] <pitti> jdstrand: can we just kill cups-pdf then? :-)
[17:00] <kirkland> jdstrand: sorry, do i need to catchup with this conversation?
[17:00] <jdstrand> pitti: well, interestinly enough, I tried to do that with an important user of mine (my wife) who has an application that doesn't use the gnome print UI, and had no way to print to pdf without cups-pdf. I tired to kill it locally...
[17:00] <jdstrand> kirkland: no
[17:00] <jdstrand> s/tired/tried/
[17:01] <kirkland> jdstrand: ;-)
[17:02] <jdstrand> pitti: regardless, I've assigned the bug to you per your request. Feel free to 'Invalid'ate if you think that is the best course (I certainly see your point of view)
[17:03] <pitti> jdstrand: well, I'll ponder it
[17:03] <pitti> jdstrand: if the apparmor rules restrict access to /home thoroughly, it's probalby not too bad
[17:03] <pitti> but it would be able to write stuff into /etc or other places which teh profile doesn't cover
[17:05] <lamont> slangasek: default-mta provides and exim4/postfix... le sigh, and yeah, I guess their argument wins
[17:05] <lamont> sadly
[17:05] <slangasek> which argument?
[17:06] <slangasek> I think default-mta as a stand-alone package would be a little better for derivs
[17:06] <jdstrand> pitti: I'm looking at the profile, and I don't see that you gave rw to anything in /etc, so I don't think that is a problem
[17:21] <slangasek> mvo: hmm; using the update-manager in jaunty-updates, I just had a weird experience where update-manager wanted me to have 50MB free on /usr when the actual update only required 123KB additional space
[17:22] <mvo> slangasek: 123kb addtional diskspace + 49mb downloaded debs? or were allt the debs downloaded already?
[17:22] <mvo> slangasek: is it reproducable?
[17:23] <slangasek> mvo: the .debs added up to < 5MB in size
[17:23] <slangasek> dunno; I can try downgrading those packages later to see
[17:24] <mvo> slangasek: right, sorry, I just checked the source and it has this as a safety buffer (min 50mb free) - I admit its a bit much
[17:24] <slangasek> ah
[17:25] <mvo> slangasek: its a leftover from the days when the free space checker would only check for release upgrades, then 50mb extra was ok, but for normal updates with just 4 pkgs its not
[17:25]  * mvo adds it to his todo list
[17:25] <slangasek> want a bug report? :)
[17:25] <mvo> slangasek: feel free :)
[17:25] <mvo> slangasek: otherwise I will file it to my postit notes :)
[17:26] <slangasek> ok :)
[17:30] <kees> asac: how do I get n-m TO manage my wired interface?  it seems to ignore it now
[17:36] <asac> kees: guess you havent configured that in /etc/network/interfaces?
[17:47] <kees> asac: in /etc/network/interfaces it says: auto eth6  and   iface eth6 inet dhcp
[17:48] <kees> aarg
[17:48] <asac> kees: so eth6 is the device you want to see managed by NM?
[17:48] <kees> asac: right
[17:49] <asac> kees: do you need it to be configured in there? otherwise just remove the eth6 entry from interfaces
[17:49] <kees> asac: ah, no, don't need it in there.  removing it will fix n-m to use it again?
[17:50] <asac> kees: yeah. NM runs in ifupdown-unmanaged mode by default. so everything configured in there will be ignored. two ways to fix this: a) remove that configureation (preferred), b) enable managed mode in /etc/NetworkManager/nm-system-settings.conf
[17:51] <kees> ah-ha, yes, I see the "managed=false" setting now.  the semantics for what n-m keeps changing.  :)  thanks, I'll give "a)" a shot.
[17:51] <asac> kees: that didnt change since it was introduced ;)
[18:39] <jdstrand> pitti: ok, I played with dac_override a little bit to make sure my understanding is correct
[18:40] <jdstrand> pitti: if dac_override is not set, then DAC is checked first. if DAC doesn't permit it, then no access. if DAC does allow it, then the profile is checked and access is determined there
[18:40] <jdstrand> pitti: if dac_override is set, then DAC simply is not consulted and only the profile is checked
[18:41] <pitti> jdstrand: right; root has DAC_OVERRIDE usually, which is what allows him to ignore file permissions
[18:41] <pitti> so if we give that priv, the policy can't rely on DAC any more, and needs to be super-tight
[18:41] <jdstrand> pitti: apparmor requires explicitly allowing access to files, so unless the profile is too loose to begin with, there shouldn't be a problem
[18:41] <jdstrand> pitti: correct
[18:42] <jdstrand> pitti: however, looking at the cups-pdf policy, it looks super-tight anyway
[18:43] <jdstrand> pitti: so, I'll defer to your judgement, but adding dac_override seems ok to me based on the current profile
[18:43] <pitti> jdstrand: I'll look at it again
[18:43] <pitti> jdstrand: sorry, have to run to sports now
[18:43] <jdstrand> pitti: np. have fun! :)
[18:43] <pitti> jdstrand: thanks for the investigations!
[18:45] <jdstrand> pitti: sure! this actually served as dual-purpose cause I'm going to be working on a test-apparmor.py script this week and dac_override will be part of the tests :)
[19:47] <slangasek> mvo: do you have plans to merge python-apt soon?  (breaks apt-xapian-index)
[20:15] <mvo> slangasek: yes, its almost ready
[20:16] <calc> is there a lpia live cd somewhere?
[20:33] <slangasek> mvo: cool, thanks
[20:37] <chrisccoulson> if i propose to merge a bzr branch in to another one (say, my branch in to an ubuntu-core-dev branch), should i assign a reviewer to it? does anyone get notified of the merge proposal if i don't specify a reviewer?
[20:42] <ScottK> Every core-dev gets notified.
[20:42] <chrisccoulson> ScottK - thanks:)
[20:51] <james_w> chrisccoulson: the default reviewer of an ubuntu-core-dev branch is ubuntu-core-dev which leads to a mail to ubuntu-devel@ now, so plenty of people see it
[20:51] <james_w> however, we need to do better at having a list of outstanding requests, which is something I am working with the LP team on
[20:52] <chrisccoulson> james_w - thanks. perhaps i would have been better off assigning a reviewer rather than spamming the whole list;)
[20:53] <james_w> chrisccoulson: it makes sense if there is a particular person. It would be a bit like subscribing that person directly to a sponsorship bug instead of u-m-s, except that u-m-s doesn't cause a mail to ubuntu-devel@
[20:54] <ScottK> james_w: I'm glad to hear you are working on this.  Thanks.
[20:55] <james_w> np
[20:55] <james_w> I'd like to have a better system that what we currently have
[20:55] <james_w> it's just not that easy because we are slightly odd :-)
[20:57] <ScottK> I think distro 'development' is different in many respects than upstream development and LP seems more focused on the latter use case than the former.
[20:57] <james_w> yeah
[20:57] <james_w> especially for merge proposals so far, as it wasn't available for distributions before
[20:57] <james_w> they are keen to fix that, there just aren't obvious answers
[20:59] <mweichert> hello, I'm trying to preseed a hardy installation. I want to slipstream all of the hardy updates on the cd so that after I finish the installation, I'm not left with 200+ packages to upgrade.
[20:59] <mweichert> to do this, do I just replace /dists and /pool on the live cd with those that are in archive.ubuntu.com ?
[20:59] <james_w> mweichert: nope, the live install doesn't install from debs
[21:00] <james_w> you would need to build a new live environment with the updates
[21:00] <mweichert> james_w, okay, in the squashfs image?
[21:00] <mweichert> james_w, what's /dists and /pool for then?
[21:00] <james_w> yeah
[21:01] <james_w> extra packages that are available, but not actually installed
[21:01] <mweichert> hmm, ok
[21:01] <mweichert> james_w, so the installer just copies the squashfs to /target, is that right?
[21:02] <james_w> not "just", no, but to a first approximation, yes
[21:04] <mweichert> james_w, sorry - that was over-simplifying.. I guess what I'm trying to determine is that if I edit the squashfs by installing the debs I want, those debs will get installed on /target.
[21:04] <mweichert> james_w, is that a safe assumption you think?
[21:04] <james_w> I've no idea whether it will work, sorry
[21:08] <MattJ> Hmm, does anyone know if it is possible to build for etch using the Ubuntu pbuilder?
[21:08] <MattJ> The wiki suggests it should be, but I'm having problems
[21:08] <james_w> it should be
[21:09] <mweichert> james_w, okay, thanks for your help. I really appreciate it. I've been having a hard time trying to find this information.
[21:09] <mweichert> james_w, to be sure though, you're certain that /pool just contains extras?
[21:10] <james_w> mweichert: I guess there aren't enough debs in there to make a full system?
[21:10] <ScottK> MattJ: Yes.  I do it all the time.
[21:10] <MattJ> From: https://wiki.ubuntu.com/PbuilderHowto it says use: sudo DIST=etch pbuilder create, but the first line pbuilder prints is "Distribution is jaunty."
[21:10] <james_w> if there were then you would only be able to use the half the space on the CD for the live environment.
[21:11] <MattJ> ScottK: I'm using 8.04, could that be an issue?
[21:11] <james_w> mweichert: #ubuntu-installer is the dedicated channel for this stuff
[21:11] <ScottK> MattJ: I did it with that too, so I don't think so.
[21:12] <MattJ> ScottK: I see: Failed getting release file http://gb.archive.ubuntu.com/ubuntu/dists/etch/Release
[21:12] <MattJ> I tried --othermirror, but it seems to have no effect
[21:12] <ScottK> MattJ: http://pastebin.com/f78072aa4 is the pbuilder wrapper script I use.  If you name that pbuilder-sid it should just work.
[21:13] <MattJ> Hmm, I'll try it... thanks :)
[21:15] <MattJ> ScottK: Excellent, it appears to be working :)
[21:16] <ScottK> MattJ: Glad to hear it.
[21:21] <calc> kees: can you process bug 372756 for me? pitti told me it didn't need a MIR
[21:24] <ScottK> Did we decide 1.37 is the target boost for Karmic?
[21:24] <calc> ScottK: well we really need to be targeting 1.38 for Karmic but its FTBFS atm
[21:24] <ScottK> Since Debian is planning on 1.38 for Squeeze, I wonder if it might be better.
[21:24] <ScottK> Agreed.
[21:24] <calc> and 1.35 also seems to cause other things to FTBFS if they attempt to use it due to gcc 4.4 (afaict)
[21:25] <kees> calc: one sec...
[21:25] <calc> kees: thanks
[21:26] <kees> calc: approved
[21:26] <calc> thanks :)
[21:26] <kees> np
[21:33] <calc> http://cdimage.ubuntu.com/daily-live/current/ <- is that actually karmic or are we doing new dailys of jaunty?
[21:34] <james_w> karmic
[21:34] <calc> probably the description needs updating then :)
[21:35] <calc> and filenames, etc
[21:36] <james_w> oh, maybe the ones there aren't karmic then
[21:36] <james_w> there was a karmic CD build last night though
[21:37] <slangasek> daily-live/current isn't karmic in any meaningful sense
[21:37] <slangasek> we don't have successful livefs builds yet
[21:40]  * calc wonders why ubuntu-mir doesn't also have archive access to do the promotions, heh
[21:41] <calc> slangasek: so since 327756 is approved now... could you maybe promote it for me, please? 8-)
[21:41] <slangasek> calc: wrong bug #?
[21:42] <calc> er 372756
[21:42] <slangasek> calc: anyway, the process is MIR approval -> reference the package from main -> ends up on component-mismatches -> ubuntu-archive cleans it up
[21:43] <calc> the references from main is a package depending on it, or something else?
[21:43] <slangasek> depends, build-depends, or seeded
[21:44] <calc> ok, so yea OOo 3.1.0~rc2-1ubuntu1 already does that via build-depends
[21:44] <calc> i somehow forgot to add that to bug report
[21:45] <calc> added to the bug report
[21:50] <james_w> calc: it's already on component-mismatches, it should get cleaned up next time an archive admin processes the list
[21:51] <calc> ok
[22:02] <bigon> http://launchpadlibrarian.net/26409322/buildlog_ubuntu-karmic-i386.telepathy-farsight_0.0.6-1_FAILEDTOBUILD.txt.gz << I know I've already asked but why this packages build cleanly inside a pbuilder?
[22:03] <bigon> hahah
[22:04] <bigon> obscédé par la repression
[22:05] <james_w> bigon: different versions of cdbs installed?
[22:05] <bigon> oups wrong channel for the 2last sencence :p
[22:05] <bigon> james_w: I don't think so
[22:06] <NCommander> james_w, its also pkgbinmanagler doing something it shouldn't
[22:06] <ajmitch> NCommander: it's nor very verbose about it
[22:06] <NCommander> Hrm
[22:07] <NCommander> bigon, which PPA is that package in?
[22:07] <NCommander> Oh, thats a distro upload, isn't it :-P
[22:07] <james_w> NCommander: what is pkgbinarymangler doing that it shouldn't?
[22:08] <bigon> NCommander: yeah
[22:08] <NCommander> james_w, I dunno, I'm going to try and reproduce with a buildd chroot and a normal pbuilder chroot
[22:08] <james_w> bigon: do you have pkgbinarymangler installed in your pbuilder?
[22:09] <NCommander> james_w, there are other pieces of voodoo in the chroots :-/
[22:10] <bigon> james_w: I don't think so
[22:10] <james_w> NCommander: yeah, but this seems to be a simple case of a file being installed in the wrong place and pkgsanitychecks complaining
[22:10] <james_w> bigon: well, that's the reason then
[22:10] <NCommander> james_w, I've *never* seen a build fail because of that before
[22:11] <james_w> well, we fixed most of them
[22:11] <NCommander> james_w, we should provide a set of instructions on how to reproduce buildd chroots
[22:11] <james_w> true
[22:11] <NCommander> (there is a lot of voodoo with the lpia especially)
[22:12] <james_w> it needs autoreconfing
[22:12] <james_w> that should fix it
[22:14]  * NCommander continues to work on merges
[22:14] <james_w> nope, that's not right
[22:15] <NCommander> james_w, ?
[22:16] <calc> can someone process a couple NEW packages for me (there is a long chain of build depends) - libloader-openoffice.org and libformula-openoffice.org
[22:19] <DktrKranz> bigon, that's because python2.6 expects to find modules in dist-package, not site-packages and pkgbinarymangler rejects it
[22:24] <bigon> DktrKranz: yeah but on my pbuilder without pkgbinarymangler I get an explicit message saying that the files inside the site-packages have been moved to dist-packages
[22:27] <DktrKranz> bigon, weird. did you use python.mk macros?
[22:28] <DktrKranz> $(call py_libdir, <python version>) and thelike
[22:29] <bigon> http://pastebin.com/f7bc52325
[22:30] <DktrKranz> it doesn't seem to use distutils, right?
[22:32] <bigon> no autotools
[22:33]  * DktrKranz tries to build it in a karmic pbuilder
[22:34] <bigon> already done
[22:34] <bigon> same result it works inside it
[22:39] <slangasek> calc: will you be coordinating getting the other reverse-deps of boost1.35 transitioned, too, so we don't have to continue carrying that one?
[22:42] <james_w> heh, it's some quoting weirdness
[22:43] <james_w> bigon: it does $PYTHON -c "from distutils import sysconfig; print sysconfig.get_python_lib(0,0,prefix='$PYTHON_PREFIX')"
[22:44] <james_w> which is supposed to return ${prefix}/lib/python2.6/dist-packages
[22:44] <james_w> but returns site-packages instead
[22:44] <bigon> mmm
[22:44] <james_w> well, not quoting weirdness, but that confused my investigation
[22:45] <james_w> will it want ${prefix} in the path, or is that supposed to be expanded in this path?
[22:46] <bigon> I can confirm that inside my pbuilder it FTBFS with pkgbinarymangler installed
[22:46] <james_w>         elif is_default_prefix and 'PYTHONUSERBASE' not in os.environ and 'real_prefix' not in sys.__dict__:
[22:46] <james_w>             return os.path.join(libpython, "dist-packages")
[22:46] <james_w>         else:
[22:46] <james_w>             return os.path.join(libpython, "site-packages")
[22:46] <james_w> in distutils
[22:46] <BUGabundo> hi everyone
[22:46] <rrp81> hi!
[22:46] <BUGabundo> so todays backport-modules reverted all the good of rt2500 pci??
[22:46] <BUGabundo> on jaunty
[22:46] <james_w> so if you pass it /usr as the path, not '${prefix}' you get dist-packages, otherwise you get site-packages
[22:47] <james_w> which seems to be what python wants
[22:47] <BUGabundo> apw: ping
[22:47] <rrp81> today's updates screwd up backport-modules, I can't update them or revert them
[22:47] <rrp81> I need them for my rt2500 pci
[22:47] <BUGabundo> rrp81: you can downgrade it.
[22:48] <BUGabundo> just get the previous version from LP cache
[22:48] <rrp81> no, i can't, it won't let me
[22:48] <james_w> so telepathy-farsight trying to preserve '${prefix}' leads to the wrong path being used, and as distutils isn't used cdbs' disutils.mk can't clean it up
[22:48] <james_w> bigon: does that make sense?
[22:48] <BUGabundo> $ sudo dkpg -I linux.......deb
[22:52] <bigon> james_w: I've not followed everything :o
[22:52] <james_w> bigon: you have two easy options, either make it expand ${prefix} before passing it in there
[22:53] <james_w> or add a mv in debian/rules (or something with .install) to fix it up
[22:53] <james_w> I'm not clear on what the effects of the first will be given the fact that it is done that way currently
[22:54] <bigon> james_w: yeah but without binpkgmangler the file are automagically moved
[22:54] <james_w> by what?
[22:55] <james_w> pkgbinarymangler is throwing it out at dpkg-deb time, so it's too late to move by then isn't it?
[22:55] <james_w> I'm not sure that it interferes before
[22:55] <bigon> let me check again
[22:58] <calc> slangasek: i'm not really in platform (more or less) for the next 6 months
[22:58] <slangasek> oh?
[22:58] <slangasek> I guess I missed that memo
[22:58] <calc> slangasek: moved to oem with doko and persia
[22:59] <slangasek> ... but still dealing with OOo? :)
[22:59] <calc> i have 20% time for OOo but i doubt that would be enough to do OOo and boost traisntion, not even enough to do bug triage really :\
[22:59] <slangasek> ok
[22:59] <calc> gah typing too fast to see my words leads to typos, heh
[22:59] <BUGabundo> sorry to hear calc! I did a great job up until now
[23:00] <calc> slangasek: but ideally we will be doing a transition from 1.35/1.37 to 1.38
[23:00] <slangasek> ah
[23:00] <calc> 1.38 currently FTBFS though :\
[23:03] <calc> slangasek: aiui 1.37 is supposed to be removed from Debian sometime soon
[23:03] <slangasek> hmm, ok
[23:03] <slangasek> I'll have a look at the 1.38 ftbfs, then
[23:03] <NCommander> calc, thats a nasty FTBFS :-/
[23:12] <directhex> boost?
[23:16] <calc> directhex: yea
[23:16] <directhex> have fun. extra fun thanks to apps build-depending on specific versions of boost rather than the un-abi'd -dev packages
[23:18] <BUGabundo> ok, what's boost?
[23:20] <calc> directhex: iirc the un-abi'd version is 1.34
[23:20] <calc> yea 1.34.1
[23:20] <calc> BUGabundo: http://www.boost.org/
[23:23] <directhex> calc, i'll bite: "why is the default (un-ABI'd version) neolithic?"
[23:24] <dtchen> TheMuso: from a prelim glance, current git HEAD of linux-2.6 is nearly 1.0.20 without some quirks, but the core and mid-layer are identical
[23:25] <calc> directhex: no idea
[23:25] <calc> directhex: probably for historical reasons
[23:25] <dtchen> TheMuso: i'm chasing a -plugins sig11 atm
[23:25] <directhex> calc, historical raisins be damned, this is ubuntu, not debian!
[23:25] <calc> directhex: it may be versioned for newer ones due to api changes (my guess anyway)
[23:26] <calc> directhex: if is the case it explains why they didn't bother to fix it for 1.34 since the proper fix would be to have no libboost-dev at all
[23:26] <slangasek> nono, the proper fix would be to have no libboost.* at all ;)
[23:27] <directhex> slangasek, <partisan> oh dear, then no gnote. what a dreadful shame!
[23:27] <mathiaz> slangasek: hm - IIUC there is a library transition (or something like that) currently hapening in debian wrt to the upload krb5 1.7 to unstable
[23:27] <directhex> calc, that seems horribly broken to me - version the deps, fix the software
[23:27] <mathiaz> slangasek: what does this mean for Ubuntu?
[23:28] <mathiaz> slangasek: ie - I'd like to get krb5 1.7 synced in karmic.
[23:28] <slangasek> mathiaz: should just require rebuilds, I think
[23:29] <mathiaz> slangasek: IIUC the main point is that krb4 is dropped
[23:29] <slangasek> yep
[23:30] <mathiaz> slangasek: so - what should I do to get things moving? Ask a sync request and upload all necessary packages?
[23:30] <slangasek> mathiaz: sounds right :)
[23:31] <mathiaz> slangasek: should I test that all necessary packages build before asking for the sync to happen?
[23:31] <mathiaz> slangasek: or ask for the sync and start uploading once the new krb5 is published?
[23:31] <slangasek> mathiaz: the latter is fine
[23:32] <mathiaz> slangasek: great - thanks. I'll go get the list of packages to rebuild :)
[23:32] <directhex> what's the policy on upstream versions for gnome? gnome 2.28 seems to be coming out terribly close to release
[23:33] <ajmitch> directhex: usually gnome releases at the same time as the beta release for ubuntu
[23:34] <ajmitch> afaik there's a standing exception for getting new upstream releases of gnome in
[23:34] <directhex> ajmitch, short version: will tomboy 1.0.0 (part of gnome 2.28) definitely be allowed in, and if so, is it worth making a 0ubuntu1 of the latest development release?
[23:35] <ajmitch> directhex: ask an RM :)
[23:35] <directhex> slangasek, i think he means you!
[23:36] <slangasek> directhex: if tomboy is releasing on time with GNOME 2.28, then yes, please track its dev releases
[23:36] <directhex> gotcha
[23:42] <mathiaz> slangasek: hm - I'm not sure I completely understand how the libkrb53 is done in debian.
[23:42] <mathiaz> slangasek: relevant changelog entries are 1.6.dfsg.4~beta1-7, 1.6.dfsg.4~beta1-8, 1.7dfsg~beta1-2 and 1.7dfsg~beta1-3
[23:43] <mathiaz> slangasek: the last entry mentioned an change that will be reverted before end of may 2009.
[23:55] <apachelogger> james_w: do you know if there is any script to create released branches of a given set of development branches (i.e. branch /ubuntu to /jaunty)?
[23:55] <james_w> "bzr branch"? :-)
[23:56] <slangasek> mathiaz: hmm, I'm quite confused by that last entry
[23:57] <slangasek> may have been a no-op, really