[00:36] <cjwatson> argh, debian/control.in
[00:36]  * cjwatson fixes gnome-pkg-tools for real
=== apachelogger is now known as SirPatchalot
[02:07] <wgrant> pitti: Looking more at the copy timeout I found last night, it actually spent a lot of time sending mail about a question that was attached to one of the bugs. That was made asynchronous yesterday, so it may be better now.
=== SirPatchalot is now known as apachelogger
=== dendro-afk is now known as dendrobates
[03:42] <psusi> cgroups sound nice and all, but weren't process session IDs created for the same purpose?  privileged login process creates new sid, and all processes descended from there are part of it?
[03:56] <ohsix> no
[03:57] <ohsix> that's not even a distinguishing feature pf cgroups
[03:58] <psusi> I'm reading http://0pointer.de/blog/projects/systemd.html and it talks about cgroups as a way to for init to group an entire set of children from which they can not escape... I thought that's what SID was created for, since normal processes can always start a new process group?  and since they can't escape from their session, you can always kill the entire session?
[04:01] <ohsix> you can trivially lose parentage of processes
[04:02] <ohsix> cgroups let you group threads with controllers for memory & cpu time and more; that they stay in their groups is just a function of its grouping
[04:04] <psusi> yea... but normal processes can't change their sid, so even if you aren't their parent anymore, you can still find them can't you?
[04:10] <ohsix> i think you can, but programs can start a new sid & spawn children at any time
=== dendrobates is now known as dendro-afk
[04:10] <ohsix> if you're not wait4()'ing on children you can't really get ahold of it
[04:11] <ohsix> the reaper would have to resort to scanning periodically
[04:12] <psusi> I thought that was the big difference between sid and pgrp?  that only root can make a new sid?
[04:13] <ohsix> but with respect to that you can be informed when a group is empty and you directly know whats in that group
[04:13] <ohsix> any caller can start a new group
[04:14] <psusi> a new process group, but not a new session I thought?
[04:15] <ohsix> you should probably say what you mean by a new session if theres a misunderstanding, i'm thinking of setsid(3)
[04:15] <psusi> so bash can make a new group for task management, but only login can make a new session.. I thought that was the purpose of sessions
[04:16] <ohsix> there aren't really sessions as you describe them, iirc either the setsid or pgrp stuff just give the leader a pass at the children before it'd be reparented directly to init
[04:17] <psusi> hrm.. I don't have setsid in section 3 for some reason... but I thought that was root only
[04:17] <ohsix> you need exttra man pages, sec
[04:18] <ohsix> manpages-dev & manpages-posix-dev
[04:19] <psusi> ahh, was missing the posix pages
[04:21] <ohsix> but just the same, theres not really much overlap
=== fabbione_vac is now known as fabbione
=== _LibertyZero is now known as LibertyZero
[08:32] <fo0bar> Hey.  I'll preface this saying I have yet to even try to reproduce this; just looking for a quick visual sanity check.  I don't see how bug#771038 is possible.  from looking at the linker errors, it's like GCC is just ignoring -lpopt
[08:33] <ohsix> bug 771038
[08:33] <ubottu> Launchpad bug 771038 in isomd5sum (Ubuntu) "isomd5sum version 1:1.0.5-1 failed to build on amd64 with GCC-4.6/oneiric" [High,New] https://launchpad.net/bugs/771038
[08:35] <fo0bar> (from doko's build logs, it appears i386 is failing too, not just amd64)
[10:02] <cjwatson> doko_,lamont: armel builders back on auto
[10:03] <cjwatson> (current main uninstallables: amd64:127, armel:289, i386:127, powerpc:132.  that's good enough to restart autobuilds)
[10:17] <natschil> Hello. I'm trying to make some changes to ubiquity. I noticed that though ubiquity copies everything in the read-only fs of the livecd, it does not copy things such as the ubiquity program etc. Does it actually copy it, and then remove it, or is there some other process involved?
[10:18] <cjwatson> it copies it and then removes it
[10:19] <cjwatson> specifically it removes packages that are in /casper/filesystem.manifest on the CD but not in /casper/filesystem.manifest-desktop
[10:19] <cjwatson> (scripts/plugininstall.py:remove_extras)
[10:20] <cjwatson> we do also try to save time by not copying files belonging to packages we're just going to remove anyway, although we can only do that in limited circumstances.  I forget whether that's the case for ubiquity
[10:20] <fo0bar> BTW, regarding bug 771038, I figured it out.  newer binutils apparently care about the linking order.  Moving -lpopt toward the end of the line fixes it
[10:20] <ubottu> Launchpad bug 771038 in isomd5sum (Ubuntu) "isomd5sum version 1:1.0.5-1 failed to build on amd64 with GCC-4.6/oneiric" [High,New] https://launchpad.net/bugs/771038
[10:21] <fo0bar> now....  I am a Debian maintainer with a Ubuntu bug (soon to be) fixed.  is there a procedure for saying "you should totally pull this updated deb down from sid to close this bug"?
[10:21] <cjwatson> https://wiki.ubuntu.com/SyncRequestProcess
[10:22] <fo0bar> thanks
[10:22] <cjwatson> that's if there are no outstanding Ubuntu changes
[10:22] <natschil> cjwatson: thanks a lot!
[10:22] <cjwatson> if there are, somebody needs to merge it
[10:22] <fo0bar> cjwatson: no, I think MOTU keep it vanilla from debian
[10:22] <cjwatson> fo0bar: until Debian import freeze (https://wiki.ubuntu.com/OneiricReleaseSchedule), we sync all packages that don't have Ubuntu modifications from Debian unstable automatically
[10:23] <cjwatson> so if it's in that category, you don't need to do anything at the moment
[10:23] <fo0bar> ahh.  so worst case scenario, I do nothing and it resolves itself?
[10:23] <cjwatson> I'd call that the best case, but yes :)
[10:23] <fo0bar> hehe
[10:24] <fo0bar> 5 various bugs fixed in one night.  getting laid off has increased my productivity tremendously!
[10:52] <lucidfox> Hmm, I'm now wondering
[10:52] <lucidfox> so the Ubuntu 11.10 CD will include GTK2, GTK3, *and* Qt4?
[10:52] <lucidfox> that's one crowded CD -_-
[10:54] <cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-great-cd-debate
[10:54] <cjwatson> (scheduled for UDS discussion)
[10:55] <ogra_> not that we arent discussing it every release :)
[10:57] <cjwatson> as it mentions in the spec summary ...
[10:57] <ogra_> ah, didnt read it :)
[11:02] <cjwatson> pitti: I'm noticing lots of:
[11:02] <cjwatson> E: libqtscript4-svg: md5sums-lists-nonexisting-file usr/share/doc/libqtscript4-svg/changelog.Debian.gz
[11:03] <cjwatson> pitti: I don't suppose that's a consequence of your recent pkgbinarymangler changes?
[11:06]  * ogra_ wonders why btrfs seems to be permanently loaded on his system
[11:06] <ogra_> apparently the initrd loads it regardless if i have btrfs partitions or not
[11:10] <cdbs> cjwatson: Can I do lintian and telepathy-haze perl 5.10 rebuilds or you have done that already?
[11:12] <cdbs> wait, not lintian, but libnet-dns-perl
[11:21] <cdbs> cjwatson: Okay leave it, I'm not rebuilding 'em, all of those are in main, and I'm too lazy to request sponsorship for 20+ rebuilds which will be done by others for sure in a few days
[11:37] <bdrung_> jcastro: is it enough to propose a blueprint for discussion at uds-o or do i have to do additional steps to get in on the agenda?
[11:59] <cjwatson> cdbs: certainly there's no point in doing any that you need sponsorship for - I can do those in bulk a lot more easily
[11:59] <cjwatson> cdbs: I don't mind if you want to do ones that you can upload directly
[12:03] <cjwatson> cdbs: I can't upload libnet-dns-perl until libdigest-sha1-perl has built and published on all architectures
[12:03] <cjwatson> otherwise I'll just have to reupload it for armel later
[12:04] <cjwatson> (potentially, anyway - it might just FTBFS, but I'd rather be economical with uploads where possible)
[12:07] <cjwatson> cdbs: it'll generally be easier once armel has caught up - I expect I can then just upload all the level-2 stuff in bulk
=== axp2__ is now known as axp2
[13:42] <MonkeyDust> folx, these are some issues i encountered in Unity http://paste.ubuntu.com/604430/
[14:38] <SpamapS> lifeless: you're not joining us in Budapest?
[15:35] <jcastro> bdrung_: it needs to be named right and then the track lead for that track needs to accept it, then it gets autoscheduled
[15:35] <jcastro> bdrung_: https://lists.ubuntu.com/archives/ubuntu-devel/2011-March/032813.html
[15:41] <bdrung_> jcastro: thanks. i didn't set the approver. who is the approver for the "other" track?
[15:43] <jcastro> bdrung_: those just go in a pile, any track lead can approve those, so you'd want to ping either slangasek or robbiew or jasonwarner
[15:44] <bdrung_> slangasek: ^ ping for https://blueprints.launchpad.net/ubuntu/+spec/other-o-eclipse-3.6/
[16:34] <geser> jelmer: thanks for those bzr-* FTBFS fixes. Did you miss bzr-xmloutput or is there an other reason that you didn't update it?
=== hunger_ is now known as hunger
[17:15] <jelmer> geser: there's two things I'd like to see merged upstream to fix the testsuite (which is run by the packaging)
[17:15] <jelmer> I've submitted MPs, waiting for upstream atm
=== Quintasan_ is now known as Quintasan
[18:41] <ximion> hi!#could someone please tell me why there are two libnotify packages in Ubuntu?
[18:42] <ximion> libnotify4-dev and libnotify-dev
[18:42] <ximion> Debian has only libnotify-dev, and I maintain a package depending on libnotify-dev >= 0.7
[18:42] <ximion> ...which does not build on Ubuntu
[18:44]  * ScottK looks
[18:45]  * Laney is searching for his passport
[18:48] <ScottK> ximion: debian/changelog for libnotify4 says "  * Rename source package and -dev binary to be versioned, so that we can install both in parallel for a while."
[18:49] <ScottK> So it looks like the Ubuntu desktop people needed a newer version but didn't want to do a full transition so they made a secnod one.
[18:50] <ximion> ScottK: This seems to be unnecessary for Debian: http://packages.debian.org/experimental/libnotify-dev
[18:50] <ximion> do you know if this will be changed back for Oneiric?
[18:50] <ximion> if so, I'll not do anything to be Ubuntu-compliant in this case and just wait
[18:51] <ScottK> ximion: I would guess it's likely.  I will file a bug about it.
[18:52] <ximion> ScottK, thanks! btw, the package in question is http://packages.debian.org/unstable/gnome-packagekit
[18:52] <ximion> ..which is named packagekit-gnome for whatever reason
[18:53] <ximion> should I  file a request to remove packagekit-gnome from Oneiric, so there are no conflicts with the gnome-packagekit package, when it gets merged?
[18:53] <ScottK> Yes.
[18:55] <ScottK> FWIW it looks like the work was done in parallel of the Debian work (hit Ubuntu about a day apart from when 0.7 hit experimental), so when the decision was made to do this there wasn't anything in experimental to rely on.
[18:55] <ximion> ScottK, ok. The gnome-packagekit pkg breaks the packagekit-gnome anyway.
[18:55] <ximion> ScottK, maybe because Ubuntu Natty still ships GNOME2, while libnotify > 0.7 is a G3 component.
[18:56] <ximion> (AFAIK an external dependency)
[18:56] <ScottK> That's likely it.  There are some bits of Gnome3 stuff in Natty, but not all of it by any means.
[18:56] <geser> should we add a packagekit-gnome -> gnome-packagekit transitional package in Ubuntu?
[18:57] <ximion> geser, I don't think this is required. gnome-packagekit has a breaks field for packagekit-gnome, so older versions will get removed.
[18:57] <ximion> and there's no standard component depending on GPK in Ubuntu yet
[18:58] <ximion> (there might be one if e.g. the USC switches to PK, but I'm not sure if this will happen)
[19:05] <ximion> ScottK, files bug #779148
[19:05] <ubottu> Launchpad bug 779148 in packagekit-gnome (Ubuntu) "Removal request for packagekit-gnome from Oneiric" [Undecided,New] https://launchpad.net/bugs/779148
[19:05] <ximion> files -> filed
[19:10] <ximion> !info gnome-packagekit oneiric
[19:10] <ubottu> 'oneiric' is not a valid distribution: hardy, hardy-backports, hardy-proposed, jaunty, jaunty-backports, jaunty-proposed, karmic, karmic-backports, karmic-proposed, kubuntu-backports, kubuntu-experimental, kubuntu-updates, lucid, lucid-backports, lucid-proposed, maverick, maverick-backports, maverick-proposed, medibuntu, natty, natty-backports, natty-proposed, partner, stable, testing, unstable
[19:38] <natschil> Hello. I noticed that some of the oem parts of ubiquity remove cryptsetup if it is not used in the home folder. Does this get carried out on a "normal" ubuntu installation?
[19:44] <natschil> alternatively... are the "oem" ubiquity packages used at all on the ubuntu livecd?
[20:32] <superfly> who do I contact to tell them that perl-modules 5.10.1-17ubuntu4.1 is corrupt?
[20:32]  * superfly has tried downloading it from a few servers, and they all seem to be corrupt
[20:37] <yofel> it did download for me from de.archive.ubuntu.com today
[20:45] <superfly> yofel: yeah, it downloads, but aptitude fails with "hash sum mismatch" and when I downloaded it manually so that I bypassed the hash checksum, it failed to unpack it
[20:46]  * superfly hasn't tried the de server yet though
[20:48] <superfly> yofel: this is what I get if I download it separately and put the package in /var/cache/apt/archives (and I just downloaded it from de.archive.ubuntu.com) http://pastebin.com/P6mHqUJw
[20:51] <yofel> I'm clueless then, as for me 'dpkg-deb -x perl-modules_5.10.1-17ubuntu4.1_all.deb p-m/' works fine
[20:52] <yofel> someone else might know more
[20:52] <superfly> I'll try that (I'm a bit of a noob when it comes to packages)
[20:52] <superfly> thanks for the help yofel
[20:54] <infinity> superfly: Does grabbing it from the librarian result in the same (broken) file?
[20:55] <infinity> superfly: https://launchpad.net/~ubuntu-security/+archive/ppa/+build/2458088/+files/perl-modules_5.10.1-17ubuntu4.1_all.deb
[20:55] <superfly> infinity: I don't know, let me try...
[20:57] <superfly> infinity: ah yes, that package seems fine
[20:57] <superfly> thanks, that solves it for me
[20:57] <infinity> But not for the archive, I suspect.
[20:57] <infinity> Let me poke at this.
[20:57] <superfly> thanks
[20:59]  * superfly is glad he got it fixed, but thinks that others downloading the package would appreciate the same ;-)
[21:01] <infinity> superfly: Okay, so... The file on the mirrors matches the file in the librarian, so I suspect you're behind a clever (and broken) transparent proxy somewhere that's causing you occasional pain.
[21:02] <superfly> infinity: hrm, that might be the case
[21:02] <superfly> I'm in South Africa, and all the ISPs here run transparent proxies
[21:03] <infinity> superfly: That seems like the most likely explanation, then.  The archive itself is consistant.
[21:03] <superfly> infinity: thanks for the help
[21:03] <infinity> superfly: Anyhow, glad to help you get it sorted.
[21:08] <lifeless_> SpamapS: nope
=== tgall_foo is now known as Dr_Who
=== lifeless_ is now known as lifeless
[21:37] <mdke> pitti: when the langpacks are built for -updates, will they get translated xml which has been stripped out of packages going into -proposed and -updates?
[21:43] <mdke> chrisccoulson, ArneGoetje: not sure if you could also help with that ^ (Saw you are in ~ubuntu-langpack) - obviously appreciate it is a weekend and UDS upon us
=== bdrung_ is now known as bdrung_away