| slangasek | jibel: hmm, https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/ shows no updates? | 00:39 |
|---|---|---|
| stgraber | slangasek: doh, daily builds are breaking because of resolvconf :( | 00:47 |
| stgraber | 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:49 |
| slangasek | stgraber: hmm | 00:50 |
| slangasek | stgraber: are you looking into it? | 00:51 |
| stgraber | 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:52 |
| stgraber | 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:53 |
| slangasek | stgraber: ok; I'll have a look, but it's going to be a couple hours for me as well | 00:54 |
| stgraber | slangasek: just found a few minutes to hack around what looks like a potential fix: http://paste.ubuntu.com/818363/ | 01:24 |
| stgraber | I think that should work but I wouldn't mind someone reviewing (even better if someone can actually test) | 01:25 |
| infinity | hallyn: It passed for me back when this first came up, yeah. | 02:21 |
| slangasek | stgraber: looks sane to me (reviewed, not tested) | 03:06 |
| stgraber | slangasek: k. I'm going to assume it can't get worse than what we have currently anyway, uploading now | 03:13 |
| stgraber | 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 |
| slangasek | stgraber: it's supposed to be automatic | 03:14 |
| stgraber | 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:18 |
| stgraber | 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:20 |
| infinity | stgraber: The live chroots are upgraded as the first step in a build, no need to worry about intervention. | 03:21 |
| infinity | stgraber: (The exception to that rule being if you update BuildLiveCD from livecd-rootfs, because it lives outside the chroot) | 03:22 |
| stgraber | 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) | 03:25 |
| timothyja | Hi guys can someone tell me how I can get the latest gtk+3 ubuntu source? | 05:36 |
| hyperair | apt-get source gtk+3.0 | 05:37 |
| timothyja | I mean from bzr | 05:37 |
| hyperair | oh | 05:37 |
| timothyja | the current list sources here: https://code.launchpad.net/ubuntu/+source/gtk+3.0 | 05:37 |
| * hyperair shrugs | 05:37 | |
| hyperair | how about lp:ubuntu/gtk+3.0? | 05:38 |
| timothyja | the current trunk is old | 05:38 |
| * hyperair shrugs | 05:38 | |
| hyperair | i don't use bzr personally | 05:38 |
| timothyja | I've wasted many hours compiling old code, the oneiric code is old also | 05:39 |
| hyperair | define old. | 05:39 |
| ajmitch | https://code.launchpad.net/~ubuntu-desktop/gtk/ubuntugtk3 | 05:39 |
| timothyja | it seems to have only been updated to 3.1.8 | 05:40 |
| hyperair | hmm | 05:40 |
| ajmitch | 'apt-cache showsrc gtk+3.0' shows that branch as the one to use, with changes made to it 7 hours ago | 05:40 |
| hyperair | weird, isn't lp:ubuntu/$pkg supposed to automatically update itself? | 05:40 |
| ajmitch | hyperair: only if that's the branch used, somehow some teams set it differently | 05:41 |
| * hyperair sighs | 05:41 | |
| ajmitch | which leads to issues like this where you have to look up the branch from the source package record | 05:41 |
| hyperair | debcheckout ftw. | 05:41 |
| hyperair | imo we should just ditch bzr and go git. | 05:42 |
| hyperair | but that's probably not going to happen. | 05:42 |
| ajmitch | yeah, good luck with that :) | 05:42 |
| hyperair | :) | 05:42 |
| timothyja | ok so that the precise version thanks | 05:43 |
| timothyja | any idea where I can get the oneiric branch? | 05:43 |
| RAOF | lp:ubuntu/oneiric/gtk+3.0? That *should* work, if all the infrastructure is working right. | 05:44 |
| ajmitch | RAOF: should, but gtk+3.0 is one of the failures on the package importer status page | 05:45 |
| RAOF | Ah. Boo. | 05:46 |
| timothyja | nar its old | 05:46 |
| timothyja | ok looks like I'll have to use the source package for now, thanks guys | 05:50 |
| pitti | Good morning | 06:18 |
| pitti | micahg: I'm here now | 06:18 |
| RAOF | Morning pitti! | 06:18 |
| ajmitch | hi pitti | 06:19 |
| pitti | micahg: ah, so time to copy over all langpacks as well now | 06:25 |
| pitti | micahg: ... or not; the tracking bug has the firefox task closed, but I don't see it in -updates | 06:31 |
| ScottK | 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 |
| ScottK | Thanks and good night. | 06:34 |
| pitti | ScottK: sure; seems they were NEWed wrongly | 06:35 |
| pitti | ScottK: good night! | 06:35 |
| pitti | I also do the binary-only calligra stuff | 06:35 |
| pitti | 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:05 |
| pitti | 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 |
| pitti | micahg: something wrong with the publisher? | 07:08 |
| pitti | "Pending in lucid-updates since 2012-01-27 04:31:40 CET" | 07:08 |
| pitti | ah, for maverick it's published on cocoplum now, copying maverick langpacks | 07:09 |
| pitti | stgraber: ah, same publisher problem that affected lucid's firefox? it just got published 19 mins ago | 07:24 |
| tkamppeter | pitti, hi | 07:33 |
| pitti | micahg: it's in now for lucid, copying langpacks | 07:56 |
| pitti | hey tkamppeter | 07:56 |
| tkamppeter | pitti, cups-filters is released upstream now. | 08:00 |
| tkamppeter | pitti, but I have another problem, LightDM does not start any more on my Precise VM. | 08:00 |
| === smb` is now known as smb | ||
| dholbach | good morning | 08:03 |
| pitti | hey dholbach | 08:11 |
| pitti | tkamppeter: what do you see exactly? do you land in a text VT? | 08:11 |
| dholbach | hi pitti | 08:11 |
| tkamppeter | pitti, it tries to restart repeatedly, the screen is flickering all the time until I SSH in and do "sudo stop lightdm". | 08:13 |
| pitti | tkamppeter: could you copy/pastebin /var/log/lightdm/lightdm.log and /var/log/Xorg.0.log somewhere? | 08:13 |
| pitti | the latter is probably more interesting | 08:13 |
| tkamppeter | pitti, "sudo startx" from a text console opens a desktop though. | 08:14 |
| soren | 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:14 |
| pitti | tkamppeter: ok, lightdm.log then | 08:15 |
| tkamppeter | pitti http://pastebin.ubuntu.com/818557/ | 08:16 |
| pitti | tkamppeter: ok, no error there; let's look at lightdm.log | 08:17 |
| tkamppeter | pitti, http://pastebin.ubuntu.com/818561/ | 08:20 |
| pitti | Got signal 15 from process 1 | 08:22 |
| pitti | seems some upstart job is killing it immediately again!? | 08:22 |
| tkamppeter | pitti, probably the first Xorg.0.log was wrong, here is a new one: http://paste.ubuntu.com/818564/ | 08:22 |
| pitti | tkamppeter: no error there, either | 08:23 |
| pitti | tkamppeter: does a manual "start lightdm" also give this effect? | 08:23 |
| tkamppeter | pitti, yes. | 08:23 |
| pitti | tkamppeter: at this point I don't know how to debug upstart and check where the "stop" signal comes from | 08:23 |
| pitti | tkamppeter: jhunt should come online soon, perhaps you can debug it with him? | 08:24 |
| tkamppeter | pitti, who is the expert? | 08:24 |
| pitti | tkamppeter: in the meantime, "startx" should give you a desktop | 08:24 |
| pitti | tkamppeter: jhunt is our upstart maintainer | 08:24 |
| pitti | stop on runlevel [016] | 08:24 |
| pitti | this seems fairly normal | 08:24 |
| pitti | tkamppeter: does "runlevel" say "N 2"? | 08:25 |
| pitti | tkamppeter: if you just do "sudo lightdm", does it still happen? | 08:25 |
| tkamppeter | pitti, a simple "startx" as normal user falls into an infinte loop, showing "No protocol specified". | 08:30 |
| tkamppeter | pitti, it is messed up now, I reboot the VM. | 08:31 |
| tkamppeter | pitti, "runlevel" is "N 2". | 08:33 |
| pitti | tkamppeter: ok, that's fine; can you try "sudo stop lightdm" and then "sudo lightdm"? | 08:34 |
| pitti | the latter avoids upstart | 08:34 |
| tkamppeter | pitti, I tried this now, lightdm tries to start X repeatedly again and does not succeed. | 08:35 |
| tkamppeter | pitti, like with upstart-started lightdm. | 08:35 |
| pitti | tkamppeter: can you please pastebin lightdm.log again? | 08:35 |
| tkamppeter | pitti, ssh -X 192.168.122.228 (the VM) gives | 08:37 |
| tkamppeter | /usr/bin/xauth: error in locking authority file /home/till/.Xauthority | 08:37 |
| tkamppeter | pitti, how do I fix that? | 08:37 |
| pitti | tkamppeter: perhaps it's owned by root? or at leats not by you? | 08:37 |
| pitti | tkamppeter: sudo chown till:till ~/.Xauthority should help | 08:38 |
| tkamppeter | pitti, thanks. Does an X startup switch it to root and if it fails not switch back to original ownership? | 08:39 |
| pitti | tkamppeter: ah, perhaps because you did "sudo startx" before, that created a root-owned .Xauthority? | 08:40 |
| pitti | that started an X session as root with your $HOME | 08:40 |
| tkamppeter | pitti, http://pastebin.ubuntu.com/818574/ | 08:40 |
| tkamppeter | pitti, that is possible. | 08:40 |
| pitti | Got signal 15 from process 3875 | 08:41 |
| pitti | what is pid 3875? | 08:41 |
| pitti | tkamppeter: do you have autologin enabled on this? | 08:42 |
| pitti | tkamppeter: and if not, do you see the greeter? | 08:42 |
| pitti | i. e. does it fail to display the greeter, or fail to start a session for you? | 08:42 |
| tkamppeter | no autologin, normally I get the greeter. | 08:43 |
| tkamppeter | PID 3875 does not exist any more. | 08:43 |
| tkamppeter | pitti, trying again. | 08:44 |
| tkamppeter | pitti, http://paste.ubuntu.com/818578/ | 08:48 |
| tkamppeter | Note that I have killed the process in the end due to the infinite loop (from an SSH console). | 08:48 |
| tkamppeter | pitti, give me the PID of the offending process quickly, perhaps it is still living. | 08:49 |
| pitti | Got signal 15 from process 5453 | 08:49 |
| pitti | it's not the X.org process (that was 5449) | 08:50 |
| pitti | I guess it's something else that gets started in between | 08:50 |
| pitti | tkamppeter: so, I guess at this point this needs robert_ancell to debug, but he's already offline | 08:50 |
| pitti | somethign is sending a sigterm to it, but I don't know which | 08:51 |
| pitti | tkamppeter: you could try | 08:51 |
| pitti | sudo strace -fvvs1024 -o /tmp/trace lightdm | 08:51 |
| pitti | tkamppeter: then look at the log again ("got signal 15 from..."), and then /tmp/trace will tell us what that process was | 08:52 |
| pitti | and perhaps a whole lot of other things | 08:52 |
| tkamppeter | 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:00 |
| pitti | tkamppeter: put it on chinstrap? | 09:01 |
| pitti | micahg: seems ubufox is uninstallable now, was that missed in the transition? | 09:02 |
| pitti | micahg: same for mozvoikko | 09:03 |
| pitti | (see http://people.canonical.com/~ubuntu-archive/testing/lucid-updates_probs.html) | 09:03 |
| tkamppeter | pitti, needed to reboot, my Firefox had eaten up all memory. | 09:14 |
| tkamppeter | pitti, sent bzipped trace by mail. | 09:16 |
| tkamppeter | pitti, is chinstrap Canonical-internal or also publicly available? | 09:17 |
| pitti | tkamppeter: Canonical internal | 09:17 |
| tkamppeter | pitti, perhaps in 2 weeks I will have chinstrap access then ... | 09:18 |
| bkerensa | https://code.launchpad.net/~bkerensa/ubuntu/natty/libnotify4/fix-for-748560/+merge/90292 | 09:19 |
| tkamppeter | pitti, did you receive the trace? | 09:31 |
| pitti | yes, got it | 09:31 |
| pitti | tkamppeter: still a mystery; nowhere in the strace is a process 5958, which is the one sending theh SIGTERM that time | 09:33 |
| ppisati | pitti: apt-get says linux-omap4 is "kept back", what's up? | 09:46 |
| pitti | ppisati: which release and component? | 09:46 |
| pitti | err, pocket? | 09:46 |
| ppisati | pitti: P/omap4 | 09:46 |
| pitti | I don't know, looks okay from here | 09:47 |
| pitti | (just by rmadison) | 09:47 |
| pitti | not on http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html eithe | 09:48 |
| pitti | ppisati: whats' the apt output if you sudo apt-get install linux-image-omap4 ? | 09:48 |
| ppisati | pitti: now it works... | 09:49 |
| ppisati | pitti: sorry | 09:49 |
| ppisati | pitti: but shoudln't an "upgrade" handle it? | 09:49 |
| pitti | no | 09:49 |
| pitti | dist-upgrade should | 09:49 |
| pitti | upgrade will never install new or remove existing packages | 09:50 |
| pitti | "upgrade" is not very useful in most cases | 09:50 |
| pitti | 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 |
| ppisati | uhm ok, thanks | 09:50 |
| tkamppeter | 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 |
| pitti | tkamppeter: aah; that would be it then | 09:53 |
| tkamppeter | pitti, you must find an irregularity happening in every round of the loop. | 09:53 |
| pitti | I don't see any other message which looks weird; it's all just "DEBUG" | 09:56 |
| pitti | this needs robert now, I think; I'm out of ideas :( | 09:56 |
| pitti | tkamppeter: it seems the unity-greeter process starts, but then stops immediately again with exit code 0 | 09:58 |
| pitti | tkamppeter: ah, could you pastebin /var/log/lightdm/x-0-greeter.log ? | 09:58 |
| pitti | maybe that has an error message | 09:59 |
| * pitti learning this as he goes, by reading lightdm.log | 09:59 | |
| Daviey | probably not the most exciting of reads. | 10:00 |
| === doko_ is now known as doko | ||
| tkamppeter | pitti, here we go: http://paste.ubuntu.com/818650/ | 10:15 |
| pitti | WARNING: File '/usr/lib/indicators3/7/libdatetime.so' does not exist. | 10:17 |
| pitti | tkamppeter: are you sure this VM is up to date? | 10:17 |
| pitti | looks like a half-broken upgrade | 10:17 |
| pitti | tkamppeter: try dist-upgrade and then sudo apt-get install ubuntu-desktop? | 10:18 |
| tkamppeter | pitti, solved. indicator-datetime was not installed, probably a missing dependency in some package. | 10:18 |
| tkamppeter | dist-upgrade I did before, and ubuntu-desktop was already installed. | 10:19 |
| pitti | tkamppeter: ah, unity-greeter should probably depend on it | 10:20 |
| seb128 | pitti, it should rather handle it fine when it's not there | 10:20 |
| pitti | or that | 10:20 |
| pitti | right now it trips over a NULL pointer and then exits with 0 (!) | 10:21 |
| seb128 | not good | 10:21 |
| seb128 | could be bug #918401 | 10:21 |
| ubottu | 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:21 |
| cjwatson | @pilot in | 10:23 |
| cjwatson | I guess the bot is asleep | 10:24 |
| === 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 | ||
| Mez | 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:30 |
| hrw | if package has -dbg and -dbgsym (like zlib) then which one has higher value for debugging? | 10:33 |
| seb128 | hrw, they should be identic in most cases but I guess "dbg" since those might be special builds | 10:34 |
| seb128 | where the dbgsym are just stripped symbols | 10:34 |
| hrw | thx | 10:34 |
| dholbach | 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:40 |
| cjwatson | dholbach: done | 10:44 |
| dholbach | thanks cjwatson | 10:44 |
| hrw | I wrote small python script to generate list of -dbgsym/-dbg packages for list of packages. someone need? | 10:46 |
| === _salem is now known as salem_ | ||
| DoctorPepper | hi guys !!! | 11:01 |
| RAOF | hrw: What benefits does it have over the script on the wiki? | 11:02 |
| DoctorPepper | is anyone from the appmenu/debusmenu team in here ? | 11:02 |
| hrw | RAOF: different usecase - I needed a way to get lsit of dbgsym for all packages to create sick rootfs images | 11:06 |
| RAOF | hrw: Aah. Cool! | 11:06 |
| apw | pitti, i wonder if you might be able to look over the precise linux pending in the new queue | 11:28 |
| pitti | apw: sure! NEWed | 11:28 |
| mpt | mvo! | 11:39 |
| mvo | hey mpt | 11:39 |
| mpt | mvo, so, I have this work item: "[mpt] Invite people to port release-upgrader to aptdaemon" | 11:40 |
| mpt | mvo, what good things would happen if someone did that porting? | 11:40 |
| mpt | One, that I've just observed (informal usability test), is that it would no longer use the ugly gksudo prompt | 11:41 |
| mpt | I'm sure there are others though :-) | 11:41 |
| mvo | 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 |
| mpt | 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 |
| mvo | mpt: yes! | 11:42 |
| mpt | (i.e. wait for that to finish) | 11:42 |
| mpt | ok | 11:42 |
| mpt | mvo, and if someone wants to do it, which project should they be branching? Is it part of update-manager? | 11:43 |
| mvo | 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:43 |
| mvo | mpt: sorry, I have to leave for lunch now, but I will read scrollback and answer when I'm back | 11:44 |
| mpt | ok, thanks mvo | 11:44 |
| mvo | yw | 11:44 |
| doko | 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:47 |
| pitti | doko: sure | 11:48 |
| doko | I might just have a cpu which doesn't expose this | 11:48 |
| pitti | doko: meh, seems I need the :i386 variants as well; multiarch.. | 11:50 |
| doko | ahh, ok. then building in the ppa | 11:50 |
| pitti | doko: but at least in installed/unpacked state, it doesn't crash any more | 11:50 |
| doko | pitti: so you did see that dlopen issue on i386? | 11:50 |
| pitti | doko: unknown; I'm on amd64 | 11:51 |
| doko | ok, building in the ppa | 11:51 |
| pitti | doko: I'm just purging all :i386 bits from my system, then it should configure | 11:51 |
| pitti | easier than waiting | 11:51 |
| doko | hijacking the fast buildds | 11:51 |
| ScottK | pitti: Thanks. | 11:52 |
| pitti | doko: ok, i386 stuff purged, your versino configured, libpixbufloader-svg crash seems fixed | 11:53 |
| pitti | doko: I'll keep that version installed, and yell if I see other problems | 11:53 |
| tkamppeter | 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:53 |
| pitti | tkamppeter: I think we can leave them in cups' debian/local for now | 11:55 |
| pitti | tkamppeter: one step at a time | 11:55 |
| tkamppeter | pitti, I have somewhat reorganized them and get http://pastebin.ubuntu.com/818724/ | 11:55 |
| tkamppeter | pitti, I could aply this organizing also to the cups package. | 11:55 |
| pitti | tkamppeter: I have no idea about oopstops; textonly might be something which could eventually go into cups-filters | 11:55 |
| pitti | tkamppeter: but for now, I'd suggest to not put anything into cups-filters whic looks suspicious or obsolete | 11:56 |
| tkamppeter | 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 |
| pitti | tkamppeter: moving one more filter to cups-filters is easy; we just need to bump the Breaks/Replaces: version | 11:56 |
| pitti | tkamppeter: so, your call in the end, doesn't make much difference | 11:57 |
| tkamppeter | pitti, I can do the move distro-only for now and later on make the decision about upstreamize or drop altogether. | 11:57 |
| pitti | tkamppeter: but are the *tops filters still that relevant, given that we are using PDF now? | 11:57 |
| tkamppeter | pitti, yes, I see, 3 of them are .../tops. | 11:57 |
| pitti | # oopstops prefilter to sanitize PostScript jobs generated by OpenOffice 2.x | 11:58 |
| tkamppeter | pitti, oopstops is already obsolete as LO emits PDF. | 11:58 |
| pitti | tkamppeter: I think we should first try whether this is still actually relevant with LibO 3.4 | 11:58 |
| pitti | tkamppeter: so, let's just kill that one | 11:58 |
| tkamppeter | pitti, dvipipetops is not installed with cups' binary packages, also not samba-to-ps ... | 12:02 |
| tkamppeter | So from the filters only textonly stays ... | 12:03 |
| pitti | tkamppeter: yay spring cleaning :) | 12:03 |
| tkamppeter | pitti, early spring, but FF requires it ... | 12:03 |
| tkamppeter | pitti, the mailto backend is also not installed, not even in /usr/lib/cups/backend-available/. | 12:04 |
| tkamppeter | pitti, after throughing all this awy, we stay with | 12:05 |
| hrw | does someone know does germinate is able to track ddebs or not? | 12:05 |
| tkamppeter | debian/local/filter/textonly | 12:06 |
| tkamppeter | debian/local/mime/text.convs | 12:06 |
| tkamppeter | debian/local/ppd: pdf.ppd postscript.ppd textonly.ppd | 12:07 |
| highvoltage | qmc | 12:07 |
| highvoltage | (sorry) | 12:07 |
| tkamppeter | 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. | 12:08 |
| === jelmer_ is now known as jelmer | ||
| tkamppeter | 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:10 |
| pitti | tkamppeter: right, if cups ships its own in the meantime, I think we should use that | 12:11 |
| pitti | tkamppeter: text seems harmless and useful enough to include in cups-filters/ | 12:12 |
| * pitti lunch, bbl | 12:12 | |
| tkamppeter | pitti, CUPS has one, in sample.drv (PPD generator), so good bye postscript.ppd, textonly goes to cups-filters upstream, cups package cleaned up! | 12:14 |
| === MacSlow is now known as MacSlow|lunch | ||
| diwic | pitti, could you sponsor lp:~ubuntu-audio-dev/pulseaudio/ubuntu.precise for me some time today? | 12:34 |
| === yofel_ is now known as yofel | ||
| pitti | diwic: sure! want to do/commit the dch -r/debcommit -r now, as I can't push? | 12:57 |
| diwic | pitti, you can push | 12:58 |
| diwic | pitti, core-devs are audio-devs | 12:58 |
| pitti | ah, good | 12:58 |
| diwic | pitti, but I can do it anyway if you like? | 12:59 |
| pitti | diwic: pushed and uploaded, thanks! | 12:59 |
| diwic | pitti, \o/ thanks | 12:59 |
| === JackyAlcine_ is now known as JackyAlcine | ||
| === MacSlow|lunch is now known as MacSlow | ||
| scott-work | 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:01 |
| scott-work | i just want to understand the current state and what we need to test and/or do to improve it | 14:02 |
| diwic | scott-work, hmm, I'm in a european time zone, but I'll try to be around | 14:02 |
| scott-work | diwic: tomorrow morning (my time, about +24 hours) would be fine as well :) | 14:03 |
| diwic | 4 hours from now works better | 14:03 |
| stgraber | 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:17 |
| cjwatson | doesn't look like pitti tried again | 14:18 |
| cjwatson | I rebuilt Ubuntu desktop, apparently successfully | 14:18 |
| cjwatson | I guess I can try the others in a bit ... | 14:18 |
| stgraber | cool, yeah, that'd be great. thanks | 14:18 |
| pitti | stgraber: looks like, http://cdimage.ubuntu.com/mythbuntu/daily-live/20120127/ built | 14:18 |
| pitti | (that was auto-launched) | 14:19 |
| pitti | stgraber: sorry, forgot to check/try again | 14:19 |
| stgraber | slangasek: that didn't take long: bug 922578 :) | 14:30 |
| ubottu | Launchpad bug 922578 in ubuntu-meta (Ubuntu) "please remove 'resolvconf' from ubuntu-minimal Depends" [High,New] https://launchpad.net/bugs/922578 | 14:30 |
| === bladernr_afk is now known as bladernr_ | ||
| siretart | stgraber: what do you think about importing/syncing nx-libs-lite from unstable to precise? | 14:59 |
| cjwatson | 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 |
| ubottu | Launchpad bug 922631 in apache-pom (Ubuntu) "[MIR] apache-pom" [Undecided,New] https://launchpad.net/bugs/922631 | 14:59 |
| siretart | stgraber: If things work out, I'll upload x2goclient to unstable later today | 14:59 |
| stgraber | 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 |
| siretart | stgraber: they replace the existing libxcomp3* and nxproxy packages | 15:00 |
| stgraber | siretart: ah, now you're starting to scare me ;) | 15:01 |
| stgraber | siretart: are they compatible with NX? (mostly interested in qtnx) | 15:01 |
| stgraber | (as in, they were tested with it) | 15:02 |
| siretart | 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 |
| siretart | stgraber: so AFAIUI, yes, they are supposed to be compatible with NX | 15:02 |
| stgraber | 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:03 |
| siretart | stgraber: I can try | 15:04 |
| cjwatson | mvo: I could use help or workaround suggestions with bug 922639, if you have a moment ... | 15:10 |
| ubottu | Launchpad bug 922639 in apt-clone (Ubuntu) "apt-clone: "Could not exec dpkg"" [Undecided,New] https://launchpad.net/bugs/922639 | 15:10 |
| mvo | cjwatson: looking | 15:12 |
| mvo | cjwatson: this is with the apt-clone from lucid-backports? or the current one in precise ? | 15:13 |
| cjwatson | mvo: precise | 15:15 |
| cjwatson | 0.2.2 | 15:15 |
| hallyn | 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 |
| mvo | cjwatson: thanks, let me try to reproduce | 15:16 |
| cjwatson | mvo: I'm guessing any 'apt-clone restore --destination=/blah' should do it ... | 15:17 |
| hallyn | oops - sorry, wrong chan | 15:17 |
| micahg | pitti: neither one should be uninstallable (except for maybe on ia64/sparc) | 15:18 |
| * micahg checks in a chroot | 15:18 | |
| mvo | cjwatson: yeah, this should be covered by the tests actually :/ | 15:20 |
| mvo | cjwatson: heh :) I actually suspect its a apt bug | 15:21 |
| micahg | pitti: not sure, a chroot seems to be fine | 15:21 |
| pitti | micahg: oh, I know; it's in universe, promoting | 15:22 |
| micahg | ah, right, new binary | 15:23 |
| pitti | same for xul-ext-ubufox | 15:23 |
| micahg | right, same for xul-ext-mozvoikko in lucid/maverick | 15:24 |
| cjwatson | 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 |
| micahg | pitti: can you also please promote firefox-locale-* in both lucid and maverick | 15:24 |
| pitti | running | 15:26 |
| siretart | stgraber: testpackages uploaded to ppa:siretart/x2go | 15:28 |
| mvo | cjwatson: I think I commited a fix (lp:apt-clone) - I'm testing it right now, will take a moment | 15:31 |
| pitti | micahg: done | 15:32 |
| stgraber | siretart: thanks | 15:32 |
| siretart | stgraber: O | 15:32 |
| siretart | 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 |
| micahg | pitti: thanks | 15:33 |
| siretart | stgraber: it's more or less "just" an update to the latest nomachine upstream release | 15:33 |
| stgraber | siretart: ok, bumped the score on these builds so I can test now :) | 15:35 |
| siretart | :-) | 15:36 |
| cjwatson | mvo: python-apt seems to set Dir::Bin::dpkg, not Dir::Bin - is that important? | 15:38 |
| ScottK | 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:38 |
| ScottK | Is the p.c.c output out of date or ??? | 15:39 |
| mvo | cjwatson: good catch, I think we need to do both | 15:40 |
| cjwatson | ScottK: Doesn't look out of date; check the timestamp | 15:40 |
| cjwatson | ScottK: that "to satisfy" message means that it's satisfying a Provides, usually | 15:40 |
| ScottK | Hmm. OK. | 15:40 |
| ScottK | 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 |
| cjwatson | or rather a virtual dep | 15:41 |
| ScottK | So I'm confused. | 15:41 |
| ScottK | Ah, wait. | 15:41 |
| tgardner | 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 |
| cjwatson | Recommends: python-gi | python-gobject-2 | python-qt4-dbus | 15:42 |
| ScottK | Yeah. | 15:42 |
| cjwatson | (so not virtual, sorry, the message indicates alternatives) | 15:42 |
| ScottK | So i just need to seed the Qt one. | 15:42 |
| cjwatson | Yep, that would do it. | 15:42 |
| ScottK | I forgot Debian solved the problem a bit differently than we did. | 15:43 |
| debfx | ScottK: apport depends on python-gi so we can't get rid of it | 15:43 |
| ScottK | 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 | |
| ScottK | debfx: I'm picking them apart one at a time. | 15:43 |
| cjwatson | It is required to be absolute | 15:43 |
| cjwatson | In general, symbolic links within a top-level directory should be | 15:43 |
| cjwatson | relative, and symbolic links pointing from one top-level directory | 15:43 |
| cjwatson | into another should be absolute. (A top-level directory is a | 15:43 |
| cjwatson | sub-directory of the root directory `/'.) | 15:43 |
| cjwatson | policy 10.5 | 15:43 |
| apw | that makes life very painful with chroots ... | 15:44 |
| apw | if you touch the chroot from outside | 15:44 |
| cjwatson | stgraber: ^- looks like schroot should be adjusted | 15:44 |
| cjwatson | 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:44 |
| cjwatson | apw: but schroot will need to cope | 15:45 |
| tgardner | it seems like its a namespace collision on the symlink | 15:45 |
| apw | cjwatson, though from outside you'd use the real /etc/resolv.conf link, and inside you'd get the inside one | 15:45 |
| cjwatson | and generally speaking inside you ought to have /run bind-mounted | 15:45 |
| cjwatson | it's just the setup that breaks | 15:46 |
| apw | ahh so we are just missing /run mount rather than anything else | 15:46 |
| cjwatson | are we, or is this setup code that runs before the bind-mounts? | 15:46 |
| apw | though of course, if you don't have precise outside you will pollute your real /run | 15:46 |
| apw | which doesn't seem desirable | 15:46 |
| cjwatson | how will you pollute it by having a symlink into it? | 15:47 |
| apw | because outside doesn't have resolvconf at all cause we don't use it before precise by default | 15:47 |
| cjwatson | oh, if resolvconf runs. but who cares, nothing will touch it ... | 15:47 |
| apw | which is why rtg even noticed | 15:47 |
| apw | 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 | |
| apw | even if we are happy to have real /run end up polited | 15:48 |
| apw | sounds fair to me :) | 15:48 |
| stgraber | 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:49 |
| apw | stgraber, i don't think we care what happens as long as its safe in the inside chroot | 15:50 |
| apw | stgraber, as in our case outside is older than precise and doesn't have /run/resolvconf at all | 15:50 |
| tgardner | and /run isn't bind mounted within the chroot | 15:51 |
| tgardner | only /proc | 15:51 |
| stgraber | 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 |
| stgraber | slangasek: thoughts ^ | 15:51 |
| apw | sounds safe assuming resolvconf inside will do something sensible should it get run/upgraded/etc after the link is replaced | 15:52 |
| tgardner | stgraber, won't /bin/resolvconf complain? It checks that /etc/resolv.conf is a symlink | 15:52 |
| === bladernr_ is now known as bladernr_afk | ||
| apw | 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 |
| stgraber | 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 |
| stgraber | if that fails for some reason, we need to fix it then :) | 15:53 |
| tkamppeter | pitti, hi | 15:53 |
| pitti | hello tkamppeter | 15:53 |
| apw | stgraber, the other way to copy the file might be: cat source | chroot chroot_dir tee destination >/dev/null | 15:54 |
| === dbarth_ is now known as dbarth | ||
| apw | stgraber, ahh see what you mean about disabling, if thats what its meant to do, then that should work indeed | 15:58 |
| tgardner | apw, the symlink check in /sbin/resolvconf looks unequivocal. not that resolvconf is even run in achroot. | 15:59 |
| psusi | I don't suppose anyone could run a sync real quick for me? I've worked with the debian dev to merge ubuntu's changes there and a new upstream. Paperwork is in bug #922654 | 16:04 |
| ubottu | Launchpad bug 922654 in gparted (Ubuntu) "please sync gparted 0.11.0-1 from debian unstable" [Undecided,Incomplete] https://launchpad.net/bugs/922654 | 16:04 |
| micahg | psusi: no, I just NACKd that | 16:04 |
| psusi | ack... why? | 16:04 |
| micahg | psusi: new upstream with no testing, alpha 2 next week | 16:04 |
| micahg | we're syncing from testing by default | 16:04 |
| psusi | I've tested it ;) | 16:05 |
| micahg | that's fine, but I think it can wait until alpha 2 (that'll give it time to bake in unstable as well) | 16:05 |
| psusi | it also fixes an outstanding bug | 16:05 |
| cjwatson | mvo: it also strikes me that apt-clone could do with bind-mounting at least /proc and /sys into the chroot, maybe emore | 16:06 |
| cjwatson | *more | 16:06 |
| psusi | hrm.... ok... so next week? just wanted to make sure it got in before freeze... been working on it since before the new year, building, testing, merging in debian and ubuntu | 16:06 |
| micahg | psusi: oh, yeah, I think we want it for precise, just not before alpha 2, the Monday after barring any RC bugs would be fine :) | 16:07 |
| psusi | ok | 16:07 |
| micahg | unless the bug it fixes is extremely bad | 16:08 |
| cjwatson | oh yes | 16:08 |
| cjwatson | @pilot out | 16:08 |
| === 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: | ||
| psusi | I guess it isn't extrememly bad... just fails to resize ntfs sometimes | 16:09 |
| micahg | cjwatson: I think the channels got set to +t somehow a few days go | 16:09 |
| cjwatson | yes, I noticed. will investigate at some point :) | 16:10 |
| * psusi goes back to working on patches for upstream gparted... | 16:11 | |
| kirkland | any idea if ubumirror (or any of the other archive mirror tools) can mirror PPAs? | 16:13 |
| kirkland | or, what's the best way to mirror a PPA? | 16:13 |
| mvo | cjwatson: thanks, a good point, I look into it next | 16:21 |
| * smb got a plymouth-upstart-bridge going mad after upgrading precise today (on a server install). Not sure exactly what is going wrong | 16:48 | |
| smb | epoll_wait(3, {}, 64, 0) = 0 (repeated constantly) | 16:49 |
| smb | init similarly bad | 16:51 |
| smb | read(24, 0x7f515e650c50, 8192) = -1 EAGAIN (Resource temporarily unavailable) | 16:52 |
| smb | lrwx------ 1 root root 64 Jan 27 17:51 24 -> /dev/ptmx | 16:52 |
| === JanC_ is now known as JanC | ||
| apw | if i am decoding that epoll_wait correctly then it is passing a timeout of 0, which is: | 17:08 |
| === deryck is now known as deryck[lunch] | ||
| apw | "... while specifying | 17:08 |
| apw | a timeout equal to zero makes epoll_wait() to return immediately even | 17:08 |
| apw | if no events are available (return code equal to zero). | 17:08 |
| apw | ", and we are returning 0 as expected. | 17:08 |
| * apw is suspicious of this upstart upload, 5 hours ago. | 17:09 | |
| apw | cjwatson, ^^ | 17:10 |
| smb | right. went back two kernel versions to make sure we did not do evil and its still the same | 17:11 |
| cjwatson | apw: -> jodh | 17:11 |
| cjwatson | assuming he's still around | 17:11 |
| apw | jodh, when did you change your nick!?! | 17:12 |
| * smb though hom to be jhunt... | 17:12 | |
| cjwatson | month or two back | 17:12 |
| jodh | apw: keep up :) | 17:12 |
| cjwatson | um, the epoll_wait in upstart is in upstart-socket-bridge, not plymouth-upstart-bridge as smb cited above | 17:13 |
| cjwatson | now, plymouth calls epoll_wait itself, but it hasn't been uploaded recently | 17:13 |
| smb | cjwatson, The process I straced was upstart-udev-bridge | 17:14 |
| cjwatson | why did you say plymouth-upstart-bridge? | 17:14 |
| smb | I mean plymouth-... | 17:14 |
| cjwatson | please can you be accurate | 17:14 |
| smb | Just mistyped now | 17:14 |
| cjwatson | pick one | 17:14 |
| mvo | cjwatson: trunk does the bind mounting now | 17:14 |
| cjwatson | mvo: thanks | 17:14 |
| smb | 1662 root 20 0 19236 892 704 R 99 0.0 0:12.95 plymouth-upstar | 17:14 |
| === bladernr_afk is now known as bladernr_ | ||
| mvo | yw | 17:14 |
| * mvo gets some dinner | 17:14 | |
| cjwatson | ok. but plymouth-upstart-bridge has not changed recently | 17:14 |
| cjwatson | that's just plymouth's stock event loop code | 17:15 |
| smb | cjwatson, Cannot say for sure what package exactly but those two processes seem to end up running wild now | 17:17 |
| smb | PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND | 17:17 |
| smb | 1662 root 20 0 19236 892 704 R 100 0.0 7:25.38 plymouth-upstar | 17:17 |
| smb | 1 root 20 0 24212 2228 1272 R 100 0.0 7:52.06 init | 17:17 |
| jodh | smb: eek! | 17:17 |
| jodh | smb: are you running upstart 1.4-0ubuntu3? | 17:18 |
| cjwatson | common factor: the kernel | 17:18 |
| cjwatson | ;-) | 17:18 |
| smb | cjwatson, no | 17:18 |
| apw | cjwatson, luckily smb testing very old kernels to confirm | 17:18 |
| smb | cjwatson, tried tree different ones | 17:18 |
| * apw wonders if we had a libc update | 17:18 | |
| cjwatson | upstart is a more likely candidate | 17:18 |
| cjwatson | /dev/ptmx - I wonder if there's a missing cloexec | 17:18 |
| smb | jodh, yes | 17:18 |
| jodh | smb: try rebooting with "--no-log" | 17:19 |
| cjwatson | try with ... what he said | 17:19 |
| smb | one min | 17:19 |
| smb | ipmi reset running | 17:19 |
| cjwatson | jodh: is it possible that pty_master is being inappropriately leaked to child processes? | 17:20 |
| cjwatson | that could have amusing effects | 17:20 |
| smb | jodh, improbability factor 1:1 (we're back to normal) | 17:21 |
| cjwatson | jodh: the log file seems to be O_CLOEXEC but not the pty master | 17:21 |
| apw | smb, so that fixes it huh | 17:22 |
| jodh | ? "545: nih_io_set_cloexec (pty_master);" | 17:22 |
| smb | apw, yo! | 17:22 |
| smb | So no process at 100%, and I do not see defunct processes anymore | 17:24 |
| cjwatson | jodh: ah, sorry, missed that | 17:24 |
| smb | which means boot completes and I get a console on ttyS0 as well | 17:24 |
| jodh | smb: did you get any log files written in /var/log/upstart? | 17:25 |
| cjwatson | jodh: but that's only done in the child - what happens if some other process is spawned between that log object being created and it being destroyed? | 17:25 |
| smb | jodh, before or after? | 17:25 |
| cjwatson | jodh: afaics any other process spawned will end up with a copy of that pty_master | 17:25 |
| smb | jodh, I mean do I need to boot back into without --no-log? | 17:25 |
| cjwatson | the nih_io_set_cloexec should be right after opening | 17:25 |
| smb | jodh, btw yes, there are several files in /var/log/upstart | 17:26 |
| === Chipzz_ is now known as Chipzz | ||
| jodh | smb: could you try reproducting the problem again? | 17:48 |
| hallyn | kees: bug 912493, any plans/ideas? | 17:49 |
| ubottu | Launchpad bug 912493 in libcap2 (Ubuntu) "libpam-cap: /etc/security/capability.conf reported as obsolete config" [Low,Confirmed] https://launchpad.net/bugs/912493 | 17:49 |
| smb | jodh, Simple, just have to reboot without --no-log :) | 17:49 |
| smb | jodh, Ok, computer is back to bad state | 17:51 |
| dobey | anyone else having problems with X after latest update? | 17:52 |
| dobey | really need my workstation back :( | 17:52 |
| slangasek | cjwatson: jodh tells me you guys have a prospective fix? | 17:52 |
| cjwatson | slangasek: I think a cloexec fix (jodh has a patch in hand) is at the very least worth testing | 17:53 |
| slangasek | ok | 17:53 |
| cjwatson | seems like a very plausible source of trouble | 17:53 |
| * slangasek nods | 17:53 | |
| cjwatson | the way that plymouth-upstart-bridge is suffering indicates that it's some kind of leakage between upstart and child jobs | 17:54 |
| bryce | arges, hiya; missed your message yesterday, but I can look into it right now | 17:55 |
| arges | bryce, thanks! yea i'm new to this, so please let me know if anything needs to be fixed. | 17:59 |
| bryce | arges, certainly. Do you want feedback here in irc or on the bug report? | 18:00 |
| jodh | cjwatson, slangasek, smb: lp:~jamesodhunt/ubuntu/precise/upstart/pty_master-cloexec-fix, https://launchpad.net/~jamesodhunt/+archive/upstart-testing | 18:00 |
| jodh | cjwatson, slangasek, smb: I've dput to the upstart-testing ppa, but the page hasn't updated yet... | 18:00 |
| smb | jodh, I will pull as soon as I find it there and let you know | 18:01 |
| arges | bryce, bug reports fine | 18:01 |
| bryce | right, will do | 18:01 |
| smb | jodh, or .... start to build in 7 hrs... hmmm | 18:02 |
| dobey | hrmm, the -10 kernel at least tells me low graphics mode | 18:03 |
| jodh | smb: thx. | 18:03 |
| jodh | smb: hey, that's better than the 11hrs for i386. | 18:03 |
| dobey | but now dpkg-reconfigure tells me nvidia-current is broken or not fully installed :( | 18:03 |
| jodh | cjwatson: could you rescore this one pretty please? | 18:03 |
| infinity | jodh: On it. | 18:03 |
| jodh | infinity: awesome, thanks. | 18:03 |
| dobey | weird | 18:03 |
| smb | jodh, Still would be zzz time for smb :) | 18:03 |
| infinity | smb: No zzz for you, the jobs are rescored. :P | 18:04 |
| smb | infinity, bah! At least its beer time. :) | 18:04 |
| infinity | smb: No beer either! | 18:04 |
| smb | infinity, too late | 18:04 |
| infinity | ;) | 18:05 |
| smb | infinity, you know us. right on time with that one. ;) | 18:05 |
| dobey | beer doesn't sound like a bad idea right now | 18:05 |
| === deryck[lunch] is now known as deryck | ||
| infinity | I need to move to Europe so that when smb starts beering, I don't realise I still have the entire day ahead of me. | 18:06 |
| smb | Best move even a bit more east. Then it is not only at least the same time but even cheap. :) | 18:08 |
| infinity | smb: Yeah, I'm not sure cheap beer is easter Europe's biggest selling feature, but it's definitely one of them... | 18:10 |
| infinity | s/easter/eastern/ | 18:10 |
| === dpm is now known as dpm-afk | ||
| jodh | smb: amd64 has now built. | 18:11 |
| infinity | (both have) | 18:11 |
| jodh | infinity: thanks again for the prompt action. | 18:12 |
| smb | package installed... power reset | 18:13 |
| * jodh starts to sweat | 18:14 | |
| smb | still seems to be in badlands | 18:16 |
| smb | I think to be sure I need to boot with --no-logs and re-install | 18:16 |
| smb | jodh, No, sorry situation without --no-log has not improved with the new package | 18:23 |
| jodh | smb: ok, I guess we'll have to disable logging until we can identify the actual cause. | 18:23 |
| jodh | smb: thanks for testing. | 18:24 |
| cjwatson | ok | 18:24 |
| smb | jodh, ok. welcome | 18:24 |
| dobey | and i thought nvidia wasn't going to get broken this time :( | 18:24 |
| diwic | scott-work, was it now you wanted to talk to me? | 18:27 |
| === Pici is now known as Guest34884 | ||
| jodh | smb: could you raise a bug on this issue? It would be interesting to know which log files get created and if there's anything interesting there too. | 18:29 |
| jodh | smb: also would be interesting to see the output of "ls /etc/init/" | 18:29 |
| smb | jodh, ok can do and add that output. | 18:30 |
| jodh | smb: thanks. | 18:31 |
| slangasek | patrickmw: there are some very strange outliers in the results on http://reports.qa.ubuntu.com/reports/boot-speed/acer-veriton-01/index.html; are these tests 100% automated and non-interactive? | 18:36 |
| slangasek | patrickmw: wondering about http://reports.qa.ubuntu.com/reports/boot-speed/acer-veriton-01/2012-01-24_16-58-22/bootchart.png in particular, which took twice as long to start the desktop as normal | 18:37 |
| slangasek | (but it's not the only one) | 18:37 |
| cjwatson | jodh: are you going to send me a branch to disable logging again, or do you want me to do it? | 18:42 |
| cjwatson | I have a few minutes before dinner ... | 18:42 |
| kees | hallyn: hrm, weird. let me take a look. | 18:43 |
| smb | jodh, bug 922754 | 18:44 |
| ubottu | Launchpad bug 922754 in upstart (Ubuntu) "booting without --no-log causes init and plymouth-upstard-bridge to spin at 100%" [Undecided,New] https://launchpad.net/bugs/922754 | 18:44 |
| smb | bah upstart ... cannot write anymore... :-P | 18:45 |
| slangasek | cjwatson: I'm taking it | 18:45 |
| === cking_ is now known as cking | ||
| cjwatson | slangasek: ah good, thanks | 18:46 |
| slangasek | jibel: bug #903137 - heh, you didn't reopen the bug? | 18:48 |
| ubottu | Launchpad bug 903137 in base-files (Ubuntu Precise) "lucid->precise upgrade - prompt to update unmodified conf files in /etc/update-motd.d: 00-header, 10-help-text, 99-footer" [Medium,Fix released] https://launchpad.net/bugs/903137 | 18:48 |
| slangasek | E: base-files: file-in-etc-not-marked-as-conffile etc/legal | 18:53 |
| slangasek | sigh | 18:53 |
| SpamapS | slangasek: hey, you did a trick once where you imported a missing upstream into a branch.. how did you do that? | 18:55 |
| slangasek | SpamapS: possibly bzr import-upstream? | 18:56 |
| SpamapS | reading.. | 18:56 |
| slangasek | or bzr merge-upstream | 18:56 |
| slangasek | depends on the context :) | 18:56 |
| cjwatson | psusi: pretty sure that parted patch broke LVM handling in d-i; bug 922646 | 18:57 |
| ubottu | Launchpad bug 922646 in parted (Ubuntu Precise) "precise alternate LVM failed to install: no root file system" [High,Triaged] https://launchpad.net/bugs/922646 | 18:57 |
| cjwatson | psusi: will try to figure it out if you don't beat me to it ... | 18:57 |
| SpamapS | slangasek: I think import-upstream was what I was missing | 18:57 |
| * slangasek nods | 18:57 | |
| SpamapS | upstream-2.6.1 ? | 18:57 |
| SpamapS | hm, ? tho.. | 18:57 |
| slangasek | that means bzr knows about the tag but can't find a revision id for it in the current branch | 18:57 |
| slangasek | are you in a subdir of a bzr repo? | 18:58 |
| cjwatson | ++ if (_is_dm_major(major(st.st_rdev)) && _is_dmraid_device (buf) | 18:58 |
| cjwatson | ++ && !_dm_is_part(buf)) | 18:58 |
| cjwatson | I think that has arranged not to probe non-dmraid DM devices, which is definitely wrong | 18:58 |
| SpamapS | slangasek: I'm in the root of a working tree underneath a shared repo. | 18:58 |
| SpamapS | Imported ../rabbitmq-server_2.6.1.orig.tar.gz as tag:upstream-2.6.1. | 18:58 |
| slangasek | SpamapS: ah, so that's what you're seeing after running import-upstream, sure | 18:59 |
| slangasek | SpamapS: you probably need to do a null merge of -rtag:upstream-2.6.1 now | 18:59 |
| slangasek | in order to graft it into the branch history where you want it | 19:00 |
| SpamapS | null merge? | 19:01 |
| SpamapS | thats a new concept for me. :p | 19:01 |
| slangasek | SpamapS: 'bzr merge -rtag:upstream-2.6.1'; 'bzr diff | patch -R' :) | 19:02 |
| slangasek | 'bzr commit' | 19:02 |
| SpamapS | slangasek: that merge tries to find the tag in the parent branch | 19:02 |
| slangasek | hmm | 19:02 |
| slangasek | not sure what's happened then | 19:02 |
| SpamapS | adding '.' worked | 19:02 |
| slangasek | ah | 19:02 |
| SpamapS | now, whether the package builds sanely.. thats another story | 19:03 |
| SpamapS | slangasek: if I don't pass '--split' to bzr bd, it thinks the package is native | 19:05 |
| slangasek | SpamapS: ummm? that makes no sense to me | 19:07 |
| SpamapS | ok.. after importing the next dsc.. it builds with normal mode | 19:07 |
| slangasek | SpamapS: what's the version number in debian/changelog? | 19:07 |
| slangasek | ah | 19:07 |
| SpamapS | slangasek: 2.6.1-1ubuntu2 | 19:07 |
| SpamapS | slangasek: would you mind inspecting this branch to see if I did it right: lp:~clint-fewbar/ubuntu/precise/rabbitmq-server/fixed-upstream-tag | 19:08 |
| SpamapS | bzr bd works | 19:08 |
| SpamapS | history looks fine | 19:09 |
| slangasek | SpamapS: yep, looks like what I've done in the past | 19:10 |
| === kalosaurusrex is now known as albrigha | ||
| * slangasek carefully avoids saying "looks correct" ;D | 19:10 | |
| SpamapS | well that at least makes sense | 19:10 |
| slangasek | cjwatson, jodh: upstart -0ubuntu4 uploaded | 19:10 |
| SpamapS | merging the next upstream seems to have hit a lot of conflicts though | 19:10 |
| slangasek | not necessarily illegitimate... is this source format v1, with upstream changes? | 19:11 |
| SpamapS | probably.. doh | 19:11 |
| slangasek | not that that's necessarily a wrong thing either | 19:12 |
| slangasek | you may just fundamentally have conflicts that need resolving | 19:12 |
| SpamapS | actually no | 19:12 |
| SpamapS | no upstream changes | 19:12 |
| slangasek | hmm, ok | 19:12 |
| SpamapS | Conflict adding files to plugins-src. Moved to root. | 19:13 |
| SpamapS | I've never seen such a conflict | 19:13 |
| slangasek | oh fun | 19:13 |
| slangasek | I don't have any good advice on those | 19:13 |
| slangasek | #bzr might | 19:13 |
| * SpamapS ponders rewinding the branch to before it was borked, and just import-dsc'ing ... | 19:14 | |
| slangasek | if it's a UDD branch you will ensure the importer will fail going forward, but I guess it's probably failing already | 19:14 |
| SpamapS | Ugh, why's that? | 19:15 |
| slangasek | because rewinding+overwriting changes the revision IDs associated with the tags the importer cares about | 19:15 |
| slangasek | and the importer isn't robust in the face of such changes | 19:15 |
| slangasek | https://bugs.launchpad.net/udd/+bug/714622 | 19:15 |
| ubottu | Ubuntu bug 714622 in Ubuntu Distributed Development "import fails when lp branch has been push --overwrite'n" [High,Confirmed] | 19:15 |
| SpamapS | slangasek: I would have thought it just cared about the upstream-* tags and the debian / ubuntu tags.. not the revids | 19:16 |
| slangasek | SpamapS: it's a very cautious importer | 19:16 |
| SpamapS | ah | 19:16 |
| === Guest34884 is now known as Pici | ||
| lamont | so when I boot the system and it says that it's waiting for network, then waiting up to 60 seconds more, and then finally says that it's booting without full networking.... | 19:19 |
| lamont | I'm guessing that's not supposed to be the last message I ever see | 19:19 |
| lamont | slangasek: your "fastest networking to date" claim? I refute it | 19:19 |
| slangasek | lamont: that means you've got garbage in /etc/network/interfaces - the system brings up all the network it can | 19:20 |
| slangasek | and then it waits for devices you've told it should be there but aren't :) | 19:20 |
| lamont | http://paste.ubuntu.com/819194/ <-- slangasek | 19:24 |
| lamont | to be fair, I did just uncomment the 'auto lo' | 19:24 |
| lamont | anything I should change before I try booting that partition again? | 19:24 |
| slangasek | lamont: "just uncomment" as in since the failure or immediately before it? | 19:25 |
| lamont | since booting oneiric so that I have a usable system | 19:26 |
| slangasek | lamont: ok. but you say you get the "booting without full networking" message, and then it still doesn't boot? | 19:26 |
| stgraber | lamont: it looks like you could drop the pre-up on that virbr0 and replace it by "bridge-ports none", not that it'd make much of a difference though | 19:26 |
| lamont | slangasek: it just sits there. I'll admit, the longest I waited was 5 minutes | 19:26 |
| slangasek | lamont: desktop, server? | 19:27 |
| lamont | upgrade from oneiric, desktop | 19:27 |
| lamont | specifically, my laptop | 19:27 |
| slangasek | well, the basic logic for failsafe boot hasn't changed since oneiric | 19:27 |
| slangasek | so I think something's wrong inside your /etc/init/rc-sysinit.conf | 19:28 |
| slangasek | rather | 19:28 |
| slangasek | something's wrong in your runlevel that should get kicked off by /etc/init/rc-sysinit.conf | 19:28 |
| lamont | a50c045d9390a6e6c43c18b19cd72fe5 /mnt/etc/init/rc-sysinit.conf | 19:29 |
| lamont | I suspect that's virgin | 19:29 |
| stgraber | tgardner: just uploaded yet another resolvconf which should fix your schroot bug (you'll need to build a clean chroot though) | 19:29 |
| slangasek | lamont: because with that config, your network should come up straightaway, and so /etc/init/failsafe.conf should stop almost immediately because of 'runlevel' being emitted; and runlevel comes from the 'telinit' at the bottom of rc-sysinit.conf | 19:30 |
| slangasek | lamont: you have time to debug this? | 19:30 |
| lamont | slangasek: I'm making time | 19:35 |
| slangasek | lamont: things to check: - is /var/run a symlink to /run? - on boot, does /run/network contain both 'ifup.lo' stamp file and 'static-network-up-emitted' stamp dir? - when you're left with the message on-screen, can you switch vts to get a getty? | 19:36 |
| lamont | slangasek: bonus question: how on earth do I actually make it so I can get into this beast at that point? | 19:37 |
| slangasek | lamont: you mean if you don't have a getty? | 19:38 |
| slangasek | lamont: you can edit /etc/init/tty2.conf (for example) to 'start on filesystem' instead of 'start on runlevel [23]' | 19:38 |
| lamont | yeah | 19:38 |
| lamont | no getty, no love | 19:38 |
| slangasek | ok... but the vt switching itself works correctly? | 19:39 |
| lamont | yes | 19:39 |
| slangasek | ok | 19:39 |
| slangasek | can you try booting with --no-log on the kernel commandline? | 19:39 |
| slangasek | (just to rule out a recent upstart change as the culprit) | 19:39 |
| tgardner | stgraber, thanks, I'll give it a try. | 19:43 |
| SpamapS | oh awesome.. I love when people leave stuff like this in their build scripts, but not the .git dirs.. | 19:43 |
| SpamapS | echo UPSTREAM_SHORT_HASH:=`git --git-dir=eldap-wrapper/eldap-git/.git log -n 1 HEAD | grep commit | cut -b 8-14` >eldap-wrapper/build/hash.mk | 19:43 |
| psusi | cjwatson: so where do you think it failed? | 19:43 |
| stgraber | tgardner: might take a while until ubuntu5 is published | 19:43 |
| tgardner | stgraber, can I pull the source and build it for myself ? | 19:44 |
| james_w | barry, hi, there's a nice fresh wadllib release with py3 support, Colin told me you were going to shepherd that in to the archive? | 19:44 |
| cjwatson | psusi: I'm currently testing http://paste.ubuntu.com/819225/ | 19:44 |
| lamont | slangasek: do I care about stop on runlevel [!23] ? | 19:45 |
| stgraber | tgardner: not too easily as you need to have debootstrap use the new one :) | 19:45 |
| slangasek | lamont: not at the moment | 19:45 |
| lamont | as in it's ok if it's there? | 19:45 |
| slangasek | lamont: not unless you think something in /etc/rc2.d is going to telinit you to a different runlevel | 19:45 |
| slangasek | lamont: yep | 19:45 |
| lamont | ah, ok | 19:46 |
| stgraber | tgardner: though the new one should be published in the next 30min to an hour | 19:46 |
| tgardner | stgraber, thats soon enough. I've got a few other things on my todo list. | 19:46 |
| slangasek | lamont: note that this is not an impossible failure condition, as some people have wound up with links to /etc/init.d/single in /etc/rc2.d before due to insserv unpleasantness | 19:46 |
| psusi | cjwatson: ohh shit... d-i depends on ped_probe_all() showing logical volumes? I removed those intentionally beacuse I've always thought it was a bug that parted -l shows logical volumes, which are really akin to partitions | 19:49 |
| jodh | smb, slangasek: thanks both. | 19:50 |
| lamont | slangasek: and boot twice, once with and once without --no-log ? | 19:50 |
| lamont | ls: cannot access /mnt/etc/rc2.d/*single*: No such file or directory | 19:50 |
| slangasek | lamont: sure | 19:50 |
| lamont | ok. back after I finish beating on this box a few times. | 19:51 |
| psusi | cjwatson: hrm... I think you want a ! on the _dm_is_part() as well | 19:51 |
| psusi | or maybe not... hrm... | 19:52 |
| psusi | wait, yea, that's screwwy | 19:53 |
| psusi | cjwatson: yea, you want the ! on _dm_is_part too ;) | 19:56 |
| psusi | cjwatson: so that if it is a dmraid, it shows it if it is the whole disk, not if it is a partition | 19:59 |
| psusi | cjwatson: shouldn't d-i be figuring out what logical volumes there are from lvs though, not parted? | 20:01 |
| lamont | slangasek: so... --no-log produces happier me | 20:09 |
| lamont | still unhappy me, but happier | 20:09 |
| lamont | without --no-log, init winds up at 99-100% busy reading from fd14 and getting EINVAL... fd14 is /dev/ptmx | 20:09 |
| lamont | with --no-log, we get all the way to the point where X tries to start, manages to display a cursor, and then falls over. eventually, we hit something hard enough to wedge the display completely, and then all that is left is the rebooting and the crying | 20:10 |
| lamont | chmod a-x /usr/bin/X was sufficient to get to a shell prompt where I could get back into irssi and scream | 20:10 |
| slangasek | lamont: right, that's the same bug smb reported earlier today | 20:11 |
| lamont | slangasek: the --no-log, or the fact that X hates me? | 20:12 |
| slangasek | lamont: --no-log | 20:12 |
| lamont | more to the point, how do I make X love me again | 20:12 |
| slangasek | lamont: so what do you and smb have in common | 20:12 |
| slangasek | X> no idea :/ | 20:12 |
| stgraber | siretart: it's a no-go for these packages. They break qtnx (session init works but the actual NX window never appears and eventually the server cuts the connection), reverting to current Precise packages fixes it. | 20:12 |
| lamont | slangasek: 3.2.0-11-generic kernel in a whole disk encrypted root on lvm disk | 20:13 |
| lamont | at least in my case | 20:13 |
| lamont | the only error in X is failing to setup the touchpad device | 20:15 |
| lamont | dell inspiron 15R if that means anything | 20:15 |
| slangasek | lamont: seems unlikely to be the touchpad failure that's preventing X from starting, but I don't know. Desktop team just landed a new X stack this week. | 20:21 |
| slangasek | bryce: ^^ lamont's X is broken after upgrading from oneiric to precise | 20:21 |
| lamont | was working on 21 jan, probably with 20th bits | 20:22 |
| slangasek | lamont: oh, so you were already running precise? | 20:22 |
| slangasek | sorry, thought this was a recent o->p upgrade | 20:23 |
| lamont | slangasek: yes | 20:25 |
| * bryce looking | 20:25 | |
| lamont | actually, running precise. was fine after updating and rebooting on 21st, failed when I finally rebooted again today after dist-upgrading | 20:26 |
| lamont | 21st had a minor annoyance going that I needed to rootcause before filing the bug, but was otherwise working | 20:26 |
| bryce | lamont, /var/log/dpkg.log please? | 20:27 |
| lamont | in fact, I'm thinking I'll afk just long enough to reboot into the state I had right before rebooting today, just to see if it makes a good difference | 20:27 |
| lamont | bryce: sure | 20:27 |
| infinity | ...with log object freed on process exit | 20:29 |
| infinity | BAD: block 0x405f0b90 (job) not freed as expected at tests/test_job_process.c:2982 (test_run). | 20:29 |
| infinity | /bin/bash: line 5: 28676 Aborted ${dir}$tst | 20:29 |
| infinity | FAIL: test_job_process | 20:29 |
| infinity | ^-- upstart testsuite failure on armhf... | 20:30 |
| slangasek | yes | 20:30 |
| infinity | I wonder if that relates to the same issue that's making us turn logging off in that upload. | 20:30 |
| slangasek | no | 20:30 |
| infinity | Mmkay. | 20:30 |
| slangasek | at least not AFAICT | 20:30 |
| lamont | bryce: chinstrap:~lamont/dplg.log | 20:30 |
| slangasek | currently I'm throwing the builds back at the builders until they stick | 20:30 |
| infinity | builds, plural? It's failed elsewhere too? | 20:31 |
| slangasek | will worry about debugging the intermittent test failure afterwards | 20:31 |
| lamont | bryce: everything since the last working reboot 20120121 1445 -0700 is significant | 20:31 |
| slangasek | yes, it failed amd64, armhf, armel; then it succeeded amd64 | 20:31 |
| infinity | Special. | 20:31 |
| infinity | Kay, then I can at least not worry about it being arm-specific. | 20:31 |
| slangasek | yep | 20:31 |
| slangasek | infinity: has anyone kubuntuish followed up with you about the buildd kernel question? | 20:32 |
| cjwatson | psusi: ah, yeah, I overnegated | 20:32 |
| infinity | slangasek: Regarding qtwebkit-source, for instance? | 20:32 |
| cjwatson | psusi: d-i uses parted to probe all volumes, lvm or not. deal with it. :) | 20:32 |
| slangasek | infinity: yeah. AIUI we've had solid confirmation that the kernel fix, if actually applied, does raise the memory split to 3G/1G as designed | 20:32 |
| infinity | slangasek: Yeah, and still doesn't fix the build failures that were attributed to said split issue. | 20:33 |
| slangasek | yep | 20:33 |
| slangasek | infinity: and the kubuntu team said in the release meeting today that they were "waiting for a kernel fix" | 20:33 |
| infinity | slangasek: Which makes some sense, as testing that mmap testcase on other platforms (like ppc) shows that they don't all have 3G available anyway. | 20:33 |
| slangasek | which seems, um, incorrect | 20:33 |
| slangasek | (or, maybe correct that they're waiting, but an ineffectual strategy) | 20:33 |
| ScottK | It's correct we're waiting. Time will tell if it's ineffectual or not. | 20:34 |
| infinity | slangasek: Yeah. I need to find someone with available round tuits (or push some things to the side on my plate) and figure out what's really going on here. | 20:34 |
| infinity | slangasek: I'm sort of beginning to suspect it might be a binutils bug or something. But I need to investigate. | 20:34 |
| lamont | also have I mentioned that the apparent hardcoding of the root device in the initramfs is quite frustrating? | 20:34 |
| cjwatson | psusi: btw ... intentionally removing things without mentioning that in the merge proposal? um, yeah. don't do that. :-) I could have seen that in the cover letter and then QA wouldn't have needed to track down a regression ... | 20:36 |
| infinity | slangasek: (It could still be a kernel issue too, but I'm getting to the point where I'm suspecting that binutils might just be using RAM very poorly and/or leaking on ARM. Need some sane testing to confirm, tough) | 20:36 |
| cjwatson | (yes, I should have spotted it in code review) | 20:36 |
| slangasek | infinity: right | 20:37 |
| tgardner | who can I get to punch linux-firmware through the unapproved queues for Lucid and Oneiric ? | 20:39 |
| lamont | bryce: need anything else before I try rebooting into last week's world? | 20:40 |
| lamont | brb (hopefully), rebooting | 20:42 |
| infinity | slangasek: The other angle I need to test (I'll kick off a testbuild this afternoon) is that it might still be a kernel issue, and fixed in precise. And if it is, I think I might need your help in escalating the "doogfooding precise on a couple of buildds" thing. | 20:43 |
| infinity | slangasek: Because I think it would be time pretty solidly wasted to keep trying to figure out what needs to be backported if we could just upgrade a Panda or two, and re-route the problem builds there. | 20:43 |
| psusi | cjwatson: I guess I didn't explicitly mention removing logical volumes... I just said in the patch header: don't probe dm devices unless they are dmraid whole disk devices... guess I should have made that more clear | 20:45 |
| cjwatson | psusi: yeah, I probably should've read it into that; oh well | 20:49 |
| === salem_ is now known as _salem | ||
| * lamont has successfully reverted to pre-reboot state. | 20:57 | |
| lamont | though I can see some serious script writing in my weekend to make that less painful for the next time | 20:57 |
| psusi | lamont: btrfs snapshots? | 20:57 |
| lamont | lvm | 20:58 |
| psusi | ahh... I mucked with that last year... yea... very painful.. | 20:58 |
| psusi | it's so much smoother with btrfs | 20:58 |
| lamont | mixed with hard coded ROOT= in places in the initramfs, and an fstab that wasn't changed to reflect the snapshot name, and well, pain | 20:58 |
| lamont | psusi: /dev/mapper/rover3-20120125 / ext3 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0 | 20:59 |
| lamont | I hear ext4 came out a while ago | 20:59 |
| lamont | bryce: I don't have running state any more, but can certainly scrape files off of the disk trivially now, and can reboot into the broken world if you want me to try anything | 21:02 |
| psusi | the problem with lvm snapshots is they have to copy all blocks that get touched to the snapshot store, even if they are later freed... then when you revert, all of the touched blocks, even the freed ones, have to be copied back.. also can't do more than one snapshot.. with btrfs, it's just an mv to rename the snapshot of your choice to the normal root name and reboot... no copying... | 21:02 |
| lamont | psusi: 2 lvrenames have the same effect | 21:03 |
| psusi | lvrename has nothing to do with snapshots.... you lvconvert --merge to roll back a snapshot | 21:03 |
| lamont | who cares about rolling it back? | 21:03 |
| lamont | the snapshot (in my case) is the as-was filesystem | 21:04 |
| psusi | ohh, you just want to boot from it temporarily? yea... you can do that too I guess... | 21:04 |
| lamont | /home is on its own partition, specifically to let me bounce around without paying _too_ much attention | 21:04 |
| psusi | until the snapshot exception store fills up anyhow, then your root fs dies ;) | 21:04 |
| lamont | that's why both are 20GB | 21:05 |
| patrickmw | slangasek, boot speed tests are still running for todays ISOs. There have been multiple spins today and its catching up as they take a while to run. As for the 26th's results- yes they are fully non-interactive. From the time the cd drops to publishing results. | 21:06 |
| lamont | my pain this go-round was making it possible to "just boot" from the snapshot, without needing to do all the renames | 21:06 |
| slangasek | patrickmw: the ones I was looking at with the weird numbers are from the 24th | 21:06 |
| slangasek | patrickmw: I'm not concerned with being caught up, I'm concerned with having 100% variation between successive runs with what should be the same image... | 21:07 |
| patrickmw | slangasek, yeah that variance was dramatic. | 21:07 |
| slangasek | patrickmw: are all three runs on a given day guaranteed to be done with the same image? | 21:08 |
| slangasek | (they need to be, for our purposes) | 21:08 |
| patrickmw | slangasek, yes | 21:08 |
| slangasek | ok | 21:08 |
| slangasek | so something's very strange there, but it doesn't sound like a methodology problem | 21:08 |
| slangasek | which means it must be a desktop startup bug, so thanks for revealing it :-) | 21:09 |
| patrickmw | I don't typically review these results, I just get them published for those that understand what they are looking for | 21:09 |
| broder | the tests are running a vm, right? is the vm's host subject to interesting load? | 21:10 |
| patrickmw | no, they are running on slow hardware. acer veritons | 21:10 |
| broder | oh, cool. nvm, then | 21:10 |
| patrickmw | I would also expect a little variance, but the 24th is odd. | 21:11 |
| patrickmw | these have been running "unmanned" for months now | 21:11 |
| bryce | lamont, sorry, got several people asking for help all at once :-) | 21:14 |
| bryce | lamont, so your issue is likely not an X issue. | 21:14 |
| bryce | lamont, looking at your dpkg.log for the 20th/21st there are no X packages changed | 21:14 |
| lamont | _since_ 21st 1445 local | 21:15 |
| lamont | _that_ boot worked just fine | 21:15 |
| lamont | and is, in fact, what I'm running now | 21:15 |
| lamont | if need be, I can go bisect the upgrade, but I'd rather not... that way lies work | 21:16 |
| bryce | lamont, possibly you're seeing bug #921998 | 21:17 |
| ubottu | Launchpad bug 921998 in unity-greeter (Ubuntu Precise) "unity-greeter crashed with SIGSEGV in indicator_object_get_entries()" [High,Confirmed] https://launchpad.net/bugs/921998 | 21:17 |
| lamont | hrm... I suppose that could be verified by simply reverting that package, yes? | 21:17 |
| lamont | should I see a tombstone in kernel logging for that segv? | 21:18 |
| dobey | lamont: would think, though i seem to still get that crash with the old version as well :-/ | 21:18 |
| * bryce gets off phone troubleshooting monitor problems with his mother | 21:18 | |
| bryce | ("Oh, honey, I noticed the cord was just loose. I plugged it in and it everything works." Ugh) | 21:19 |
| lamont | unity-greeter 0.2.0-0ubuntu4 vs 0.2.0-0ubuntu5 | 21:19 |
| lamont | heh | 21:19 |
| bryce | lamont, symptoms include no errors in your X logs, X just appears to shut down normally; switching to gdm works around it; should be a segfault in dmesg | 21:20 |
| dobey | lamont: yeah, rebuild of new libindicate i think | 21:20 |
| bryce | lamont, did you file a bug report? | 21:21 |
| dobey | unfortunately the new xserver-xorg-core and/or new kernel, seems to also break compat with the nvidia-current driver :( | 21:21 |
| lamont | bryce: hadn't yet - where should I file it against? | 21:26 |
| lamont | Jan 27 13:00:48 rover3 kernel: [ 81.530390] unity-greeter[5105]: segfault at 18 ip 00007fec4b0a4f6c sp 00007fffb061d390 error 4 in libindicator3.so.7.0.0[7fec4b0a0000+d000] | 21:26 |
| lamont | oh yeah, that's the badger | 21:27 |
| bryce | lamont, don't worry about it, if you had I'd say dupe it to the one I mentioned | 21:27 |
| cjwatson | bryce: heh, I rarely get familial tech support for my actual area of expertise since who installs an OS that often - I just get stuff I have no idea about and have to guess | 21:27 |
| bryce | lamont, apparently the branch associated with the bug does not fix it | 21:27 |
| lamont | bryce: nice | 21:28 |
| bryce | cjwatson, yeah it came down to, "Mom, the software all shows the monitor is not being detected right, so either your dog broke the monitor when he knocked it over, or the cable is not connected right, or a pin bent when you plugged it back in." | 21:28 |
| * lamont clicks the AOL link on 921998, just for giggles | 21:29 | |
| slangasek | stgraber: man, bug #922491 ftw | 21:29 |
| bryce | 20 minutes later... "No, it's plugged in solidly... oh wait, when I did earlier, that the other end came loose." | 21:29 |
| ubottu | Launchpad bug 922491 in resolvconf (Ubuntu Precise) "lucid to precise server upgrade: resolvconf failed to upgrade: cp cannot create regular file `/run/resolvconf/resolv.conf': No such file or directory" [High,New] https://launchpad.net/bugs/922491 | 21:29 |
| slangasek | stgraber: this fails because resolvconf creates the directory in the *preinst*, then initscripts is configured and clobbers it with a bind mount :P | 21:30 |
| bryce | next HW refresh mom's getting a plain old desktop with >one< monitor. | 21:30 |
| slangasek | I think this is another case of fixing a resolvconf bug by removing code | 21:30 |
| bryce | while doing this, my 2 1/2 year old son comes in. "Hi Dutch, do you want to talk to grandma?" "No, no thanks." | 21:31 |
| * lamont reboots to play with today's precise and 921998 | 21:31 | |
| slangasek | omgubuntu: Ubuntu X maintainer rejects multimonitor support | 21:31 |
| lamont | slangasek: his son is not a monitor. just sayin | 21:31 |
| cjwatson | do not degauss small child | 21:33 |
| stgraber | slangasek: oh fun ... | 21:34 |
| slangasek | stgraber: easy enough to fix the case of resolvconf being installed on upgrade, because that just requires us to create the directory in the postinst. But I need to think some more about how to handle the case of the lucid version of resolvconf already being installed. | 21:38 |
| kees | random... why is "discard" not a default mount option for ext4 filesystems? | 21:43 |
| slangasek | infinity: so armhf and powerpc are failing the new upstart consistently, whereas armel has managed to build it; since armhf and powerpc also failed to build the *previous* version, they're not affected by --log anyway, so I'm punting this for now | 21:44 |
| broder | kees: Documentation/whatever claims that they didn't trust it to be completely safe | 21:44 |
| cjwatson | yeesh, unpacking multipath-udeb into the d-i environment breaks LVM | 21:45 |
| kees | broder: oh...heh. | 21:45 |
| * cjwatson takes a hatchet to ... something | 21:45 | |
| broder | kees: i don't know that it's actually true in practice | 21:45 |
| kees | broder: "but it is off | 21:46 |
| kees | by default until sufficient testing has been done." | 21:46 |
| kees | (Documentation/filesystems/ext4.txt) | 21:46 |
| kees | only one way I know of to get lots of testing!! ;) | 21:46 |
| broder | heg | 21:47 |
| broder | *heh | 21:47 |
| slangasek | cjwatson: do you know any reason it wouldn't be safe to have resolvconf pre-depends: initscripts (>= /run) ? | 21:58 |
| cjwatson | unless it's circular, can't see why not; lots of other stuff does | 22:01 |
| cjwatson | well, initscripts Depends: upstart Depends: ifupdown | 22:02 |
| cjwatson | so maybe be a little careful | 22:02 |
| siretart | stgraber: any idea what's going wrong, and does the server use NX 3.5 as well, or some earlier version? | 22:02 |
| cjwatson | iirc Pre-Depends/Depends loops are just about ok though? | 22:02 |
| psusi | cjwatson: is that from my merge today too? ;( | 22:02 |
| cjwatson | psusi: in that I changed your patch to depend on multipath-udeb rather than kpartx-udeb because the latter didn't exist, yes; but it was only exposing a latent bug anyway | 22:03 |
| cjwatson | I'd rather have that kind of thing front-and-centre so it's easy to notice and fix | 22:03 |
| psusi | cjwatson: ok ;) | 22:03 |
| stgraber | siretart: really not sure, the only difference in behaviour is the lack of actual NX window with the new version. All the console output looks identical | 22:04 |
| psusi | so installing kpartx-udeb before also caused the breakage? | 22:04 |
| stgraber | siretart: the server is running a mix of old freenx (from freenx-team PPA) and x2go | 22:04 |
| psusi | err, multipath-udeb rather | 22:04 |
| stgraber | siretart: I can't really try to touch anything on the server as that's the production weblive servers and they need to work with natty, oneiric and precise | 22:04 |
| cjwatson | psusi: well, I haven't actually tried, but AFAICS yes - it's because it emits log junk to *stdout* when dm-multipath isn't loaded | 22:05 |
| cjwatson | stupid thing | 22:05 |
| psusi | ahh, fun | 22:06 |
| cjwatson | hmm, but if hw-detect loads multipath-udeb, it modprobes dm-multipath at the same time | 22:06 |
| cjwatson | maybe the easiest fix is just to create a kpartx-udeb then | 22:06 |
| siretart | stgraber: well, too bad then. | 22:06 |
| cjwatson | and say that multipath-udeb should only ever be loaded by hw-detect | 22:06 |
| cjwatson | not as robust but it's looking pretty twisty to fix otherwise | 22:07 |
| psusi | or move the modprobe from hw-detect to the multipath-udeb postinst? | 22:07 |
| cjwatson | postinsts in udebs are different from postinsts in debs | 22:08 |
| cjwatson | they imply having a menu item | 22:08 |
| stgraber | siretart: server is on nxlibs 3.3 and nxproxy 3.4. With x2goserver 3.0.99.6-0~343 and freenx 0.7.3.git100327.e224628-0~ppa6~natty1.5ubuntu1 | 22:08 |
| siretart | stgraber: so a mixture of NX 3.3 and NX 3.4? interesting that this works at all | 22:09 |
| slangasek | cjwatson: pre-dep+dep loop could be a bit dicey, but ifupdown doesn't depend on resolvconf in any event. I'll watch out for loops | 22:10 |
| siretart | stgraber: did you try to keep the old x2goserver and only update the libxcomp* and nxproxy stuff? | 22:11 |
| siretart | stgraber: or did you upgrade everything? | 22:12 |
| stgraber | siretart: I didn't touch anything server side, I only upgraded the client side (as that's the only part I actually care about. The server I have full control of the packages that are installed there) | 22:14 |
| siretart | I see | 22:14 |
| stgraber | siretart: so on my laptop I upgraded from Precise using your PPA and tried to connect => failed, reverted to clea Precise => worked. | 22:14 |
| siretart | stgraber: and I guess that you don't actually use x2go, but stick with a 'plain' NX server, right? | 22:15 |
| stgraber | siretart: people using weblive on Natty (by default in Edubuntu's software center) are using qtnx to connect, these using Oneiric or Precise are using python-x2go | 22:16 |
| stgraber | siretart: that's why I have that weird mix on the server side, needed to find something that works with all the client versions :) | 22:16 |
| siretart | good luck maintaining that mix | 22:16 |
| slangasek | stgraber, cjwatson: ok, resolvconf ubuntu6 uploaded with the initscripts dep changed to a pre-dep; hopefully that's the last upload before EOD | 22:17 |
| stgraber | well, so far, copying the exact same packages seems to work fine. Eventually natty will be end of support and I'll be able to drop NX and just support x2go. | 22:17 |
| siretart | oh, nice, x2goclient just got accepted into unstable | 22:18 |
| stgraber | slangasek: yeah, I think that was the last bug discovered today that had to be fixed :) I still think LTSP is broken but I haven't tested it yet and haven't got a bug report yet. Planning on testing and fixing that over the weekend. | 22:19 |
| em | Isn't it an obvious bug that the pyopencl package in Ubuntu depends on the Nvidia driver package? | 22:23 |
| em | Why would it be set up that way? | 22:23 |
| em | It means that there is no way for people who don't use Nvidia to install pyopencl from the repos. | 22:23 |
| micahg | IIRC, only the nvidia binary driver have an opencl implementation | 22:25 |
| micahg | s/have/has/ | 22:25 |
| RAOF | micahg: I'm pretty sure fglrx also has an opencl implementation; in fact, given AMD pushes OpenCL harder than nvidia, I'd guess they had it first. | 22:35 |
| jtaylor | it has | 22:39 |
| jtaylor | but you have to build pyopencl from source to use it with fglrx | 22:39 |
| infinity | That seems entirely counter to what OpenCL is meant to promise. :P | 22:40 |
| jtaylor | though maybe I only did that to avoid pulling in nvidia stuff which the package depends on | 22:41 |
| RAOF | Mesa's growing OpenCL support, so we'll probably see some sensible packaging once that happens :P | 22:42 |
| infinity | You may well be right. I haven't looked at it at all. I just find it somewhat ironic if our opencl implementation doesn't actually do what opencl is meant to do (provide a generic interface to GPUs and CPUs) without rebuilding it for each target. | 22:42 |
| jtaylor | you'll have rebuilding in any case, opencl is all about just in time compiling | 22:43 |
| infinity | Well, yes. | 22:43 |
| infinity | I suppose we could JIT the JIT. | 22:43 |
| infinity | Problem solved. | 22:43 |
| RAOF | Huh, yeah. | 22:44 |
| RAOF | pyopencl has a dependency on nvidia-current. That's a barefaced lie! | 22:44 |
| infinity | RAOF: If that's demonstrably untrue, then perhaps demote it to a Recommends on nvidia|fglrx? | 22:45 |
| infinity | RAOF: I mean, I'd assume it doesn't actually depend on a GPU at all, but I don't know pyopencl. | 22:45 |
| jtaylor | I'm not sure if fglrx includes libopencl | 22:45 |
| infinity | RAOF: I just know that opencl should, if implemented sanely, also run on the host CPU just fine. | 22:45 |
| RAOF | fglrx: /usr/lib/fglrx/libOpenCL.so.1 | 22:45 |
| infinity | (And maybe this pipe dream is waiting for Mesa to catch up, at least on Linux) | 22:45 |
| jtaylor | ah great | 22:45 |
| jtaylor | its been a while since I last set it up | 22:45 |
| RAOF | infinity: Yeah, but we don't (yet) have a CPU-bound OpenCL library. | 22:46 |
| === bladernr_ is now known as bladernr_afk | ||
| infinity | RAOF: So, Mesa will make everything better? | 22:46 |
| RAOF | infinity: Well, mesa will trigger us to actually do OpenCL packaging properly :) | 22:47 |
| lamont | I have now progressed to new and different levels of pain | 22:48 |
| lamont | bryce: the workaround for bug 921998 is: apt-get install indicator-{datetime,power} | 22:48 |
| ubottu | Launchpad bug 921998 in unity-greeter (Ubuntu Precise) "unity-greeter crashed with SIGSEGV in indicator_object_get_entries()" [High,Confirmed] https://launchpad.net/bugs/921998 | 22:48 |
| lamont | which I will so note shortly. | 22:48 |
| lamont | otoh, now it just won't let me log in, since it cannot launch session ubuntu-td | 22:48 |
| lamont | ubuntu-2d, even | 22:49 |
| RAOF | Ah, there we go. Debian has fixed python-pyopencl, and we just need to merge & stuff. | 22:51 |
| * lamont reinstalls unity-2d | 22:55 | |
| * cjwatson idly notes that there's something on the FTBFS list called "viennacl" which is dep-wait on libopencl1 | 22:56 | |
| cjwatson | which looks like it comes from some nvidia package in Debian IIRC | 22:57 |
| cjwatson | but it'd be awfully nice if somebody with a clue about this stuff could fix that up | 22:57 |
| lamont | slangasek: you are forgiven. all is better now in my world. bugs updated, time for a new snapshot partition | 23:01 |
| lamont | should I be concerned that when the window goes full screen (which I didn't tell it to - old bug), that the icons for kill, minimize, and unfullscreen are all indistinguishable from the background of the panel, and require guessing placement for added fun? | 23:08 |
| kees | smoser: say, any chance you can resync e2fsprogs from debian? I like having an actually-released version. :) | 23:23 |
| infinity | kees: You're so picky. | 23:26 |
| * kees bows | 23:26 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
