[00:39] jibel: hmm, https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/ shows no updates? [00:47] slangasek: doh, daily builds are breaking because of resolvconf :( [00:49] slangasek: if I interpret the log correctly, live-build is trying to copy something to /etc/resolv.conf at a time where it's a dangling symlink [00:50] stgraber: hmm [00:51] stgraber: are you looking into it? [00:52] slangasek: not really, I've people over at the moment, just got e-mail notifications for Edubuntu build failures on my phone. I can have a look at it possibly later today (in 3-4 hours) otherwise it'll have to wait till tomorrow [00:53] I'm not familiar with what live-build try to do exactly, my guess is that it wants to copy the builder's resolv.conf when building the livefs which could be done by first removing /etc/resolv.conf, then copying it and making sure to turn it back into a symlink at the end of the build [00:54] stgraber: ok; I'll have a look, but it's going to be a couple hours for me as well [01:24] slangasek: just found a few minutes to hack around what looks like a potential fix: http://paste.ubuntu.com/818363/ [01:25] I think that should work but I wouldn't mind someone reviewing (even better if someone can actually test) [02:21] hallyn: It passed for me back when this first came up, yeah. [03:06] stgraber: looks sane to me (reviewed, not tested) [03:13] slangasek: k. I'm going to assume it can't get worse than what we have currently anyway, uploading now [03:14] slangasek: do you know if updating live-build on the builders need some manual action or if it's always using whatever is in the archive? [03:14] stgraber: it's supposed to be automatic [03:18] slangasek: ok, uploaded. Hopefully most of the other livefs will build with the new version. IIRC Edubuntu is one of the first livefs to build, the others build much later. [03:20] pitti: Would be nice if you could trigger manual rebuilds of what failed when you're around (at least Edubuntu, maybe some others). thanks [03:21] stgraber: The live chroots are upgraded as the first step in a build, no need to worry about intervention. [03:22] stgraber: (The exception to that rule being if you update BuildLiveCD from livecd-rootfs, because it lives outside the chroot) [03:25] infinity: ah right, that was the one I was thinking about. Last time I had to poke at the LiveFS builders was to add an LTSP chroot to the Edubuntu DVDs (which needed some copying of stuff outside the chroot) [05:36] Hi guys can someone tell me how I can get the latest gtk+3 ubuntu source? [05:37] apt-get source gtk+3.0 [05:37] I mean from bzr [05:37] oh [05:37] the current list sources here: https://code.launchpad.net/ubuntu/+source/gtk+3.0 [05:37] * hyperair shrugs [05:38] how about lp:ubuntu/gtk+3.0? [05:38] the current trunk is old [05:38] * hyperair shrugs [05:38] i don't use bzr personally [05:39] I've wasted many hours compiling old code, the oneiric code is old also [05:39] define old. [05:39] https://code.launchpad.net/~ubuntu-desktop/gtk/ubuntugtk3 [05:40] it seems to have only been updated to 3.1.8 [05:40] hmm [05:40] 'apt-cache showsrc gtk+3.0' shows that branch as the one to use, with changes made to it 7 hours ago [05:40] weird, isn't lp:ubuntu/$pkg supposed to automatically update itself? [05:41] hyperair: only if that's the branch used, somehow some teams set it differently [05:41] * hyperair sighs [05:41] which leads to issues like this where you have to look up the branch from the source package record [05:41] debcheckout ftw. [05:42] imo we should just ditch bzr and go git. [05:42] but that's probably not going to happen. [05:42] yeah, good luck with that :) [05:42] :) [05:43] ok so that the precise version thanks [05:43] any idea where I can get the oneiric branch? [05:44] lp:ubuntu/oneiric/gtk+3.0? That *should* work, if all the infrastructure is working right. [05:45] RAOF: should, but gtk+3.0 is one of the failures on the package importer status page [05:46] Ah. Boo. [05:46] nar its old [05:50] ok looks like I'll have to use the source package for now, thanks guys [06:18] Good morning [06:18] micahg: I'm here now [06:18] Morning pitti! [06:19] hi pitti [06:25] micahg: ah, so time to copy over all langpacks as well now [06:31] micahg: ... or not; the tracking bug has the firefox task closed, but I don't see it in -updates [06:34] pitti: There are a couple of KDE lang packs hung up in component mismatches: kde-l10n-fa/vi. It'd be nice if you couple promote them. [06:34] Thanks and good night. [06:35] ScottK: sure; seems they were NEWed wrongly [06:35] ScottK: good night! [06:35] I also do the binary-only calligra stuff [07:05] stgraber: I still get incoming image build failures due to resolv.conf, so either that live-build update didn't do the trick, or it does need manual action to get deployed to the builders? [07:08] micahg: I'm confused -- https://launchpad.net/ubuntu/+source/firefox/+changelog says that firefox 9.0 is in lucid/maverick -updates; published for maverick and pending for lucid [07:08] micahg: something wrong with the publisher? [07:08] "Pending in lucid-updates since 2012-01-27 04:31:40 CET" [07:09] ah, for maverick it's published on cocoplum now, copying maverick langpacks [07:24] stgraber: ah, same publisher problem that affected lucid's firefox? it just got published 19 mins ago [07:33] pitti, hi [07:56] micahg: it's in now for lucid, copying langpacks [07:56] hey tkamppeter [08:00] pitti, cups-filters is released upstream now. [08:00] pitti, but I have another problem, LightDM does not start any more on my Precise VM. === smb` is now known as smb [08:03] good morning [08:11] hey dholbach [08:11] tkamppeter: what do you see exactly? do you land in a text VT? [08:11] hi pitti [08:13] pitti, it tries to restart repeatedly, the screen is flickering all the time until I SSH in and do "sudo stop lightdm". [08:13] tkamppeter: could you copy/pastebin /var/log/lightdm/lightdm.log and /var/log/Xorg.0.log somewhere? [08:13] the latter is probably more interesting [08:14] pitti, "sudo startx" from a text console opens a desktop though. [08:14] How can I tell do-release-upgrade to never ask me any questions? I've tested the upgrade on an identical system, I know it'll ask me about a conffile change, and I just want it to accept the one from the updated package. [08:15] tkamppeter: ok, lightdm.log then [08:16] pitti http://pastebin.ubuntu.com/818557/ [08:17] tkamppeter: ok, no error there; let's look at lightdm.log [08:20] pitti, http://pastebin.ubuntu.com/818561/ [08:22] Got signal 15 from process 1 [08:22] seems some upstart job is killing it immediately again!? [08:22] pitti, probably the first Xorg.0.log was wrong, here is a new one: http://paste.ubuntu.com/818564/ [08:23] tkamppeter: no error there, either [08:23] tkamppeter: does a manual "start lightdm" also give this effect? [08:23] pitti, yes. [08:23] tkamppeter: at this point I don't know how to debug upstart and check where the "stop" signal comes from [08:24] tkamppeter: jhunt should come online soon, perhaps you can debug it with him? [08:24] pitti, who is the expert? [08:24] tkamppeter: in the meantime, "startx" should give you a desktop [08:24] tkamppeter: jhunt is our upstart maintainer [08:24] stop on runlevel [016] [08:24] this seems fairly normal [08:25] tkamppeter: does "runlevel" say "N 2"? [08:25] tkamppeter: if you just do "sudo lightdm", does it still happen? [08:30] pitti, a simple "startx" as normal user falls into an infinte loop, showing "No protocol specified". [08:31] pitti, it is messed up now, I reboot the VM. [08:33] pitti, "runlevel" is "N 2". [08:34] tkamppeter: ok, that's fine; can you try "sudo stop lightdm" and then "sudo lightdm"? [08:34] the latter avoids upstart [08:35] pitti, I tried this now, lightdm tries to start X repeatedly again and does not succeed. [08:35] pitti, like with upstart-started lightdm. [08:35] tkamppeter: can you please pastebin lightdm.log again? [08:37] pitti, ssh -X 192.168.122.228 (the VM) gives [08:37] /usr/bin/xauth: error in locking authority file /home/till/.Xauthority [08:37] pitti, how do I fix that? [08:37] tkamppeter: perhaps it's owned by root? or at leats not by you? [08:38] tkamppeter: sudo chown till:till ~/.Xauthority should help [08:39] pitti, thanks. Does an X startup switch it to root and if it fails not switch back to original ownership? [08:40] tkamppeter: ah, perhaps because you did "sudo startx" before, that created a root-owned .Xauthority? [08:40] that started an X session as root with your $HOME [08:40] pitti, http://pastebin.ubuntu.com/818574/ [08:40] pitti, that is possible. [08:41] Got signal 15 from process 3875 [08:41] what is pid 3875? [08:42] tkamppeter: do you have autologin enabled on this? [08:42] tkamppeter: and if not, do you see the greeter? [08:42] i. e. does it fail to display the greeter, or fail to start a session for you? [08:43] no autologin, normally I get the greeter. [08:43] PID 3875 does not exist any more. [08:44] pitti, trying again. [08:48] pitti, http://paste.ubuntu.com/818578/ [08:48] Note that I have killed the process in the end due to the infinite loop (from an SSH console). [08:49] pitti, give me the PID of the offending process quickly, perhaps it is still living. [08:49] Got signal 15 from process 5453 [08:50] it's not the X.org process (that was 5449) [08:50] I guess it's something else that gets started in between [08:50] tkamppeter: so, I guess at this point this needs robert_ancell to debug, but he's already offline [08:51] somethign is sending a sigterm to it, but I don't know which [08:51] tkamppeter: you could try [08:51] sudo strace -fvvs1024 -o /tmp/trace lightdm [08:52] tkamppeter: then look at the log again ("got signal 15 from..."), and then /tmp/trace will tell us what that process was [08:52] and perhaps a whole lot of other things [09:00] pitti, I will send you the /tmp/trace by e-mail, pasting through a browser does not work, a browser seems to turn each byte into 1 MB of local RAM ... [09:01] tkamppeter: put it on chinstrap? [09:02] micahg: seems ubufox is uninstallable now, was that missed in the transition? [09:03] micahg: same for mozvoikko [09:03] (see http://people.canonical.com/~ubuntu-archive/testing/lucid-updates_probs.html) [09:14] pitti, needed to reboot, my Firefox had eaten up all memory. [09:16] pitti, sent bzipped trace by mail. [09:17] pitti, is chinstrap Canonical-internal or also publicly available? [09:17] tkamppeter: Canonical internal [09:18] pitti, perhaps in 2 weeks I will have chinstrap access then ... [09:19] https://code.launchpad.net/~bkerensa/ubuntu/natty/libnotify4/fix-for-748560/+merge/90292 [09:31] pitti, did you receive the trace? [09:31] yes, got it [09:33] tkamppeter: still a mystery; nowhere in the strace is a process 5958, which is the one sending theh SIGTERM that time [09:46] pitti: apt-get says linux-omap4 is "kept back", what's up? [09:46] ppisati: which release and component? [09:46] err, pocket? [09:46] pitti: P/omap4 [09:47] I don't know, looks okay from here [09:47] (just by rmadison) [09:48] not on http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html eithe [09:48] ppisati: whats' the apt output if you sudo apt-get install linux-image-omap4 ? [09:49] pitti: now it works... [09:49] pitti: sorry [09:49] pitti: but shoudln't an "upgrade" handle it? [09:49] no [09:49] dist-upgrade should [09:50] upgrade will never install new or remove existing packages [09:50] "upgrade" is not very useful in most cases [09:50] it is if dist-upgrade wnats to remove half of your desktop due to archive skew, then "upgrade" will give you a safe subset [09:50] uhm ok, thanks [09:53] pitti, is the SIGTERM from process 5958 at the end of the trace? Then this would be my manual breaking of the infinite loop via "killall lightdm" command. [09:53] tkamppeter: aah; that would be it then [09:53] pitti, you must find an irregularity happening in every round of the loop. [09:56] I don't see any other message which looks weird; it's all just "DEBUG" [09:56] this needs robert now, I think; I'm out of ideas :( [09:58] tkamppeter: it seems the unity-greeter process starts, but then stops immediately again with exit code 0 [09:58] tkamppeter: ah, could you pastebin /var/log/lightdm/x-0-greeter.log ? [09:59] maybe that has an error message [09:59] * pitti learning this as he goes, by reading lightdm.log [10:00] probably not the most exciting of reads. === doko_ is now known as doko [10:15] pitti, here we go: http://paste.ubuntu.com/818650/ [10:17] WARNING: File '/usr/lib/indicators3/7/libdatetime.so' does not exist. [10:17] tkamppeter: are you sure this VM is up to date? [10:17] looks like a half-broken upgrade [10:18] tkamppeter: try dist-upgrade and then sudo apt-get install ubuntu-desktop? [10:18] pitti, solved. indicator-datetime was not installed, probably a missing dependency in some package. [10:19] dist-upgrade I did before, and ubuntu-desktop was already installed. [10:20] tkamppeter: ah, unity-greeter should probably depend on it [10:20] pitti, it should rather handle it fine when it's not there [10:20] or that [10:21] right now it trips over a NULL pointer and then exits with 0 (!) [10:21] not good [10:21] could be bug #918401 [10:21] Launchpad bug 918401 in lubuntu-meta (Ubuntu) "Unity-greeter installed by default on Lubuntu, crashing on start" [Undecided,Confirmed] https://launchpad.net/bugs/918401 [10:23] @pilot in [10:24] I guess the bot is asleep === cjwatson changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cjwatson [10:30] Anyone have any idea how sslv2 is somehow enabled in lucid? Even though the package has it set so it's not even compiled with sslv2 [10:33] if package has -dbg and -dbgsym (like zlib) then which one has higher value for debugging? [10:34] hrw, they should be identic in most cases but I guess "dbg" since those might be special builds [10:34] where the dbgsym are just stripped symbols [10:34] thx [10:40] can somebody please reject https://code.launchpad.net/~wibblymat/ubuntu/oneiric/ettercap/merge-debian-0.7.3-2.2/+merge/71435? we synced a newer version into Ubuntu already [10:44] dholbach: done [10:44] thanks cjwatson [10:46] I wrote small python script to generate list of -dbgsym/-dbg packages for list of packages. someone need? === _salem is now known as salem_ [11:01] hi guys !!! [11:02] hrw: What benefits does it have over the script on the wiki? [11:02] is anyone from the appmenu/debusmenu team in here ? [11:06] RAOF: different usecase - I needed a way to get lsit of dbgsym for all packages to create sick rootfs images [11:06] hrw: Aah. Cool! [11:28] pitti, i wonder if you might be able to look over the precise linux pending in the new queue [11:28] apw: sure! NEWed [11:39] mvo! [11:39] hey mpt [11:40] mvo, so, I have this work item: "[mpt] Invite people to port release-upgrader to aptdaemon" [11:40] mvo, what good things would happen if someone did that porting? [11:41] One, that I've just observed (informal usability test), is that it would no longer use the ugly gksudo prompt [11:41] I'm sure there are others though :-) [11:42] mpt: right, there are few direct benefits, one if the gksu prompt, the other is that its more inline with the tools we use these days, but its mostly under-the-hood [11:42] Would the upgrade start queueing nicely if someone happens to be installing/uninstalling an application at the moment they choose to do the upgrade? [11:42] mpt: yes! [11:42] (i.e. wait for that to finish) [11:42] ok [11:43] mvo, and if someone wants to do it, which project should they be branching? Is it part of update-manager? [11:43] mpt: yes, branching u-m and possible creating a new repository too to make it more seperate (as its really its own project nowdays) [11:44] mpt: sorry, I have to leave for lunch now, but I will read scrollback and answer when I'm back [11:44] ok, thanks mvo [11:44] yw [11:47] smoser, pitti: please could you recheck http://people.canonical.com/~doko/tmp/eglibc-2.15/install/ (lightdm on amd64 works for me with this one) [11:48] doko: sure [11:48] I might just have a cpu which doesn't expose this [11:50] doko: meh, seems I need the :i386 variants as well; multiarch.. [11:50] ahh, ok. then building in the ppa [11:50] doko: but at least in installed/unpacked state, it doesn't crash any more [11:50] pitti: so you did see that dlopen issue on i386? [11:51] doko: unknown; I'm on amd64 [11:51] ok, building in the ppa [11:51] doko: I'm just purging all :i386 bits from my system, then it should configure [11:51] easier than waiting [11:51] hijacking the fast buildds [11:52] pitti: Thanks. [11:53] doko: ok, i386 stuff purged, your versino configured, libpixbufloader-svg crash seems fixed [11:53] doko: I'll keep that version installed, and yell if I see other problems [11:53] pitti, I am currently working on the packaging of cups-filters. While doing that I have found out that CUPS ships a lot of filters, like ooopstops, textonly, ... which never shipped in CUPS usptream and also are not added by me. Now there is the question whether I should add them to cups-filters upstream and independent of this move them from the cups Debian package to the cups-filters Debian package? [11:55] tkamppeter: I think we can leave them in cups' debian/local for now [11:55] tkamppeter: one step at a time [11:55] pitti, I have somewhat reorganized them and get http://pastebin.ubuntu.com/818724/ [11:55] pitti, I could aply this organizing also to the cups package. [11:55] tkamppeter: I have no idea about oopstops; textonly might be something which could eventually go into cups-filters [11:56] tkamppeter: but for now, I'd suggest to not put anything into cups-filters whic looks suspicious or obsolete [11:56] pitti, advantage of moving them now is to only once have the complex dependencies when spinning out a part of the cups package. [11:56] tkamppeter: moving one more filter to cups-filters is easy; we just need to bump the Breaks/Replaces: version [11:57] tkamppeter: so, your call in the end, doesn't make much difference [11:57] pitti, I can do the move distro-only for now and later on make the decision about upstreamize or drop altogether. [11:57] tkamppeter: but are the *tops filters still that relevant, given that we are using PDF now? [11:57] pitti, yes, I see, 3 of them are .../tops. [11:58] # oopstops prefilter to sanitize PostScript jobs generated by OpenOffice 2.x [11:58] pitti, oopstops is already obsolete as LO emits PDF. [11:58] tkamppeter: I think we should first try whether this is still actually relevant with LibO 3.4 [11:58] tkamppeter: so, let's just kill that one [12:02] pitti, dvipipetops is not installed with cups' binary packages, also not samba-to-ps ... [12:03] So from the filters only textonly stays ... [12:03] tkamppeter: yay spring cleaning :) [12:03] pitti, early spring, but FF requires it ... [12:04] pitti, the mailto backend is also not installed, not even in /usr/lib/cups/backend-available/. [12:05] pitti, after throughing all this awy, we stay with [12:05] does someone know does germinate is able to track ddebs or not? [12:06] debian/local/filter/textonly [12:06] debian/local/mime/text.convs [12:07] debian/local/ppd: pdf.ppd postscript.ppd textonly.ppd [12:07] qmc [12:07] (sorry) [12:08] pitti, from these debian/local/ppd/pdf.ppd will also die as it is a sample for a PDF printer PPD in the PS workflow, obsolete. === jelmer_ is now known as jelmer [12:10] pitti, so only the files of the textonly printer driver stay, which could move into cups-filters upstream and postscript.ppd, the generic PostScript PPD of CUPS, there we must check whether CUPS is not also shipping its own. [12:11] tkamppeter: right, if cups ships its own in the meantime, I think we should use that [12:12] tkamppeter: text seems harmless and useful enough to include in cups-filters/ [12:12] * pitti lunch, bbl [12:14] pitti, CUPS has one, in sample.drv (PPD generator), so good bye postscript.ppd, textonly goes to cups-filters upstream, cups package cleaned up! === MacSlow is now known as MacSlow|lunch [12:34] pitti, could you sponsor lp:~ubuntu-audio-dev/pulseaudio/ubuntu.precise for me some time today? === yofel_ is now known as yofel [12:57] diwic: sure! want to do/commit the dch -r/debcommit -r now, as I can't push? [12:58] pitti, you can push [12:58] pitti, core-devs are audio-devs [12:58] ah, good [12:59] pitti, but I can do it anyway if you like? [12:59] diwic: pushed and uploaded, thanks! [12:59] pitti, \o/ thanks === JackyAlcine_ is now known as JackyAlcine === MacSlow|lunch is now known as MacSlow [14:01] diwic: i have to go to 1/2 day meeting, but in about four hours can we talk about pulseaudio <-> jack integration and hand-off later? [14:02] i just want to understand the current state and what we need to test and/or do to improve it [14:02] scott-work, hmm, I'm in a european time zone, but I'll try to be around [14:03] diwic: tomorrow morning (my time, about +24 hours) would be fine as well :) [14:03] 4 hours from now works better [14:17] pitti: hi! yeah, I figured it might take a while because of jdstrand playing with the publisher ;) did my fix work once it actually got published? [14:18] doesn't look like pitti tried again [14:18] I rebuilt Ubuntu desktop, apparently successfully [14:18] I guess I can try the others in a bit ... [14:18] cool, yeah, that'd be great. thanks [14:18] stgraber: looks like, http://cdimage.ubuntu.com/mythbuntu/daily-live/20120127/ built [14:19] (that was auto-launched) [14:19] stgraber: sorry, forgot to check/try again [14:30] slangasek: that didn't take long: bug 922578 :) [14:30] Launchpad bug 922578 in ubuntu-meta (Ubuntu) "please remove 'resolvconf' from ubuntu-minimal Depends" [High,New] https://launchpad.net/bugs/922578 === bladernr_afk is now known as bladernr_ [14:59] stgraber: what do you think about importing/syncing nx-libs-lite from unstable to precise? [14:59] ubuntu-mir: would appreciate a quick look at bug 922631, since there are packages currently uninstallable in main because of this (I didn't notice the new dependency before syncing libbsf-java, sorry) [14:59] Launchpad bug 922631 in apache-pom (Ubuntu) "[MIR] apache-pom" [Undecided,New] https://launchpad.net/bugs/922631 [14:59] stgraber: If things work out, I'll upload x2goclient to unstable later today [15:00] siretart: I think that'd be a good idea, as they are new packages, they won't break anything and will likely be useful for quite a few people [15:00] stgraber: they replace the existing libxcomp3* and nxproxy packages [15:01] siretart: ah, now you're starting to scare me ;) [15:01] siretart: are they compatible with NX? (mostly interested in qtnx) [15:02] (as in, they were tested with it) [15:02] stgraber: I've never tried qtnx myself, but Mike (the x2go mike) integrated a lot of patches so that you can install both x2go and freenx on the server using these libs [15:02] stgraber: so AFAIUI, yes, they are supposed to be compatible with NX [15:03] siretart: can you push just the packages you want to sync into Ubuntu to a PPA, I can then do a quick test run of weblive with both x2go and qtnx and make sure everything works before that lands in the archive. [15:04] stgraber: I can try [15:10] mvo: I could use help or workaround suggestions with bug 922639, if you have a moment ... [15:10] Launchpad bug 922639 in apt-clone (Ubuntu) "apt-clone: "Could not exec dpkg"" [Undecided,New] https://launchpad.net/bugs/922639 [15:12] cjwatson: looking [15:13] cjwatson: this is with the apt-clone from lucid-backports? or the current one in precise ? [15:15] mvo: precise [15:15] 0.2.2 [15:16] hi - this morning my virbr0 didn't show up, and log showed that adding msq rule got -EINTR (not sure if that was cause or effect). anyone ever seen that? [15:16] cjwatson: thanks, let me try to reproduce [15:17] mvo: I'm guessing any 'apt-clone restore --destination=/blah' should do it ... [15:17] oops - sorry, wrong chan [15:18] pitti: neither one should be uninstallable (except for maybe on ia64/sparc) [15:18] * micahg checks in a chroot [15:20] cjwatson: yeah, this should be covered by the tests actually :/ [15:21] cjwatson: heh :) I actually suspect its a apt bug [15:21] pitti: not sure, a chroot seems to be fine [15:22] micahg: oh, I know; it's in universe, promoting [15:23] ah, right, new binary [15:23] same for xul-ext-ubufox [15:24] right, same for xul-ext-mozvoikko in lucid/maverick [15:24] mvo: yeah, I thought it might be given that it already has some workarounds for this kind of thing; but I couldn't work out why it was getting that path for Dir::Bin::dpkg [15:24] pitti: can you also please promote firefox-locale-* in both lucid and maverick [15:26] running [15:28] stgraber: testpackages uploaded to ppa:siretart/x2go [15:31] cjwatson: I think I commited a fix (lp:apt-clone) - I'm testing it right now, will take a moment [15:32] micahg: done [15:32] siretart: thanks [15:32] stgraber: O [15:33] stgraber: I've just talked to mike on jabber. it seems that there are no patches to nxcomp and nxproxy at all, so the packages should be pretty safe wrt. qtnx/nxclient [15:33] pitti: thanks [15:33] stgraber: it's more or less "just" an update to the latest nomachine upstream release [15:35] siretart: ok, bumped the score on these builds so I can test now :) [15:36] :-) [15:38] mvo: python-apt seems to set Dir::Bin::dpkg, not Dir::Bin - is that important? [15:38] cjwatson: I've got some germinate/seed confusion when you have a moment. According to http://people.canonical.com/~ubuntu-archive/germinate-output/kubuntu.precise/_germinate_output python-gi is being pulled in to satisfy python-dbus, but python-dbus dropped that as a recommends 10 days ago. [15:39] Is the p.c.c output out of date or ??? [15:40] cjwatson: good catch, I think we need to do both [15:40] ScottK: Doesn't look out of date; check the timestamp [15:40] ScottK: that "to satisfy" message means that it's satisfying a Provides, usually [15:40] Hmm. OK. [15:41] cjwatson: On http://people.canonical.com/~ubuntu-archive/germinate-output/kubuntu.precise/all it also lists python-gi as being pulled in by python-dbus. [15:41] or rather a virtual dep [15:41] So I'm confused. [15:41] Ah, wait. [15:42] Precise resolvconf is breaking my rice bowl on precise schroots. /etc/schroot/setup.d/20copyfiles breaks when it tries to copy the host /etc/resolv.conf to the schroot. Maybe its because the schroot hasn't got a mount for /run ? Has anyone else encountered this yet ? [15:42] Recommends: python-gi | python-gobject-2 | python-qt4-dbus [15:42] Yeah. [15:42] (so not virtual, sorry, the message indicates alternatives) [15:42] So i just need to seed the Qt one. [15:42] Yep, that would do it. [15:43] I forgot Debian solved the problem a bit differently than we did. [15:43] ScottK: apport depends on python-gi so we can't get rid of it [15:43] Thanks. [15:43] * apw notes that the link in the chroot is /etc/resolv.conf -> /run/resolvconf/resolv.conf ... is that allowed to be absolute rather then -> ../run/resolvconf/resolv.conf ? [15:43] debfx: I'm picking them apart one at a time. [15:43] It is required to be absolute [15:43] In general, symbolic links within a top-level directory should be [15:43] relative, and symbolic links pointing from one top-level directory [15:43] into another should be absolute. (A top-level directory is a [15:43] sub-directory of the root directory `/'.) [15:43] policy 10.5 [15:44] that makes life very painful with chroots ... [15:44] if you touch the chroot from outside [15:44] stgraber: ^- looks like schroot should be adjusted [15:44] apw: in this case I think it's generally *desirable* when touching the chroot from outside, because you get current name server resolution data without having to copy things manually [15:45] apw: but schroot will need to cope [15:45] it seems like its a namespace collision on the symlink [15:45] cjwatson, though from outside you'd use the real /etc/resolv.conf link, and inside you'd get the inside one [15:45] and generally speaking inside you ought to have /run bind-mounted [15:46] it's just the setup that breaks [15:46] ahh so we are just missing /run mount rather than anything else [15:46] are we, or is this setup code that runs before the bind-mounts? [15:46] though of course, if you don't have precise outside you will pollute your real /run [15:46] which doesn't seem desirable [15:47] how will you pollute it by having a symlink into it? [15:47] because outside doesn't have resolvconf at all cause we don't use it before precise by default [15:47] oh, if resolvconf runs. but who cares, nothing will touch it ... [15:47] which is why rtg even noticed [15:48] and the copy in will still fail as the link points to somethign which doesn't exist [15:48] * cjwatson bows out of this conversation, I'll let stgraber/slangasek fix it [15:48] even if we are happy to have real /run end up polited [15:48] sounds fair to me :) [15:49] tgardner,apw,cjwatson: would removing /etc/resolv.conf and replace it by the content of /etc/resolv.conf (so cat /etc/resolv.conf > $target/etc/resolv.conf, instead of a cp), work for you or do we want to bind-mount /run/resolvconf (sounds like a bad idea to me)? [15:50] stgraber, i don't think we care what happens as long as its safe in the inside chroot [15:50] stgraber, as in our case outside is older than precise and doesn't have /run/resolvconf at all [15:51] and /run isn't bind mounted within the chroot [15:51] only /proc [15:51] apw: right, safest way is to rm /etc/resolv.conf in the chroot and replace by the content of /etc/resolv.conf outside of it. This will work whatever the release is outside the chroot. [15:51] slangasek: thoughts ^ [15:52] sounds safe assuming resolvconf inside will do something sensible should it get run/upgraded/etc after the link is replaced [15:52] stgraber, won't /bin/resolvconf complain? It checks that /etc/resolv.conf is a symlink === bladernr_ is now known as bladernr_afk [15:53] stgraber, i guess we could check if the filename is a link, and if so resolve it, and then fix the result to point to the chroot, and ... [15:53] tgardner, apw: the reason why we made resolvconf a depends and not a recommends of ubuntu-minimal is because it's supposed to properly deal with /etc/resolv.conf being converted back to a file and never try to make it a symlink again. It's the "supported" way of disabling it. [15:53] if that fails for some reason, we need to fix it then :) [15:53]