[04:18] <pitti> Good morning
[04:19] <pitti> SpamapS: I answered to 876959 yesterday
[05:19] <micahg> http://packages.qa.debian.org/d/dpatch/news/20111024T000209Z.html \o/ dpatch  deprecated for new packages in Debian...
[05:20] <StevenK> This is terrible news.
[05:21] <micahg> StevenK: that's is deprecated or only for new pacakges?
[05:21] <StevenK> No, that it is deprecated at all.
[05:22] <StevenK> quilt can go DIALCF
[05:23]  * micahg ♥ quilt
[05:27]  * RAOF can get right behind StevenK's quilt hate.
[05:29]  * micahg wonders why people hate quilt
[05:30] <StevenK> quilt push -a ; quilt new ; edit file ; OHDAMNITIFORGOTQUILTADD
[05:31] <pitti> for more extensive edits there is also quilt shell
[05:31] <StevenK> I just want a patch system, not a VCS wannabe
[05:32] <StevenK> And a buggy VCS wannabe, at that.
[05:32] <micahg> StevenK: src format 3 FTW, just make your changes debuild -S, you have a patch :)
[05:32] <StevenK> Ugh, format 3
[05:32] <micahg> I love it, no more forgetting quilt add...
[05:41] <RAOF> Although now you get to play the game of disentangle the multiple patches!
[05:53]  * nigelb <3 quilt as well.
[05:54] <nigelb> StevenK: Its even more awesome when you use quilt with UDD.
[05:54] <nigelb> ;)
[05:54] <nigelb> (that's the only quilt use case I absolutely hate)
[07:07] <dholbach> good morning
[07:13] <speakman> gmorning!
[07:17] <speakman> Where can I find unity-2d-panel source? It's having problem adjusting it's width on multi monitor setups.
[07:17] <speakman> (on launchpad that is)
[07:18] <htorque_> hello everyone! i keep seeing problems reported with read-only file systems by users that followed some guides involving the recovery mode (as this seems to have changed in oneiric).
[07:18] <htorque_> wouldn't it be more convenient to offer a 'read-only' menu item rather than making users first use 'remount' and then 'root'?
[07:31] <geser> speakman: https://code.launchpad.net/~unity-2d-team/unity-2d/oneiric (project page is https://launchpad.net/unity-2d)
[07:34] <speakman> geser: thx m8 :)
[07:40] <speakman> (I'm about to post a bug report for this, but are there any tools to print the current resolution of each monitor attached?)
[07:46] <speakman> Using Xinerama
[07:54] <StevenK> Is there any magic I need for apt-cache to show long descriptions again?
[07:56] <pitti> StevenK: it always did?
[07:56] <cjwatson> no magic should be needed.  perhaps your mirror has failed to mirror the Translations-* files?
[07:56] <StevenK> Oh
[07:56]  * StevenK kicks apt-mirror
[07:57] <cjwatson> debmirror works fine
[07:58] <StevenK> I suspect I'm back to a postmirror script to wget the en translations
[08:21] <cjwatson> StevenK: do please file a bug against apt-mirror about this, though
[08:23] <StevenK> cjwatson: I got distracted by writing a suitable postmirror script, but will do
[08:25] <StevenK> cjwatson: Already filed: https://bugs.launchpad.net/ubuntu/+source/apt-mirror/+bug/368419
[08:27] <cjwatson> hmph
[08:28] <StevenK> cjwatson: Exactly what I thought
[08:28]  * cjwatson comments
[08:39] <RAOF> speakman: xrandr --verbose
[08:56] <speakman> RAOF: I'm on Xinerama so xrandr doesn't work. I used nvidia-settings GUI instead.
[08:58] <OdyX> tkamppeter_ : any idea when openprinting.org will see life again ? (linuxfoundation.org/…/openprinting works though, so maybe just a matter of redirects)
[09:03] <zyga> hi
[09:03] <zyga> I'd like to report a bug but I'm not sure which component is responsible for this
[09:03] <zyga> I cannot shut down my clean-install oneiric
[09:03] <zyga> selecting shut down simply logs me out, selecting shut down from lightdm does nothing
[09:03] <zyga> is it a lightdm bug?
[09:04] <pitti> could be a lightdm or consolekit problem
[09:09] <zyga> pitti, any clue on where to look, syslog has nothing while I try to shut down
[09:09] <pitti> no idea, perhaps start with filing a bug against lightdm, to include /var/log/lightdm/lightdm.log
[09:09] <pitti> that might have a clue
[09:10] <pitti> also ~/.xsession-errors when you try to shutdown from your session
[09:10] <zyga> pitti, thanks for the hint, I'll try to shut down now
[09:26] <SpamapS> pitti: thanks
[09:27]  * SpamapS should not be awake but stupid smoke alarms went off because their batteries had died
[09:31] <SpamapS> http://people.canonical.com/~clint/bootchart.png .. anybody know what would cause check-new-relea to be run at boot time?
[09:32] <SpamapS> I think its update-motd
[09:32] <cjwatson> /etc/update-motd.d/91-release-upgrade -> /usr/lib/update-manager/release-upgrade-motd -> /usr/lib/update-manager/check-new-release
[09:32] <OdyX> cyphermox: fyi, usb-modeswitch linked against libjim uploaded to Ubuntu. Tests and comments appreciated…
[09:33] <OdyX> meh. s/Ubuntu/Debian/
[09:33] <SpamapS> cjwatson: ahh thats why greps didn't work
[09:34] <SpamapS> seems like we could delay a bit... its a rather busy command
[09:36] <SpamapS> or am I reading the rather non-decipherable colors wrong and its a zombie most of the time? :-P
[09:36] <pitti> SpamapS: certainly not; checking apt stuff during boot is ridiculously expensive
[09:36] <pitti> (or anytime during login, really -- it causes VT logins to hang for a long time)
[09:37] <pitti> at least they used to in the past, it took about 5 seconds for me
[09:57] <SpamapS> pitti: all of update-motd feels like something that can wait until the first login.. or 5 minutes after first boot even.
[09:58] <pitti> SpamapS: btw, red means "iowait", i. e. processes blocking on disk activity (usually waiting for data to read)
[09:58] <SpamapS> pitti: "red" ?
[09:58] <pitti> on rotary disks, the heavy apt stuff can block quite a bit
[09:58] <SpamapS> I see only white
[09:58] <pitti> SpamapS: on the bootcharts
[09:58] <SpamapS> or blue
[09:58] <pitti> I see a fair amount of red on your charts
[09:59] <pitti> you don't seem to have an ureadahead cache
[09:59] <SpamapS> dpkg-reconfigure ureadahead maybe?
[09:59] <pitti> presumably this is from a boot right after you changed something in the boot sequence (perhaps you installed bootchart and this is the first boot after it?)
[09:59] <pitti> or that :)
[09:59] <SpamapS> no after 10 slow boots I got frustrated
[09:59] <pitti> usually, after you do this, you boot to a desktop, wait for a minute, remove all old charts, and reboot again
[10:00] <SpamapS> this is the third boot-chart measured boot
[10:00] <SpamapS> but, seriously, no red
[10:00] <SpamapS> its like we have a different pallete or something
[10:00] <pitti> your CPU gets bored to death, the entire boot is one huge big red IOwait condition, and your HDD doesn't get to shovel more than some 5 MB/s into the RAM
[10:01] <pitti> SpamapS: I'm looking at http://people.canonical.com/~clint/bootchart.png
[10:01] <pitti> SpamapS: well, it's a relatively light red, more like pink
[10:01] <SpamapS> yeah, I see pink, blue, white, no red
[10:01] <SpamapS> the colors are fairly hard to distinguish from one another
[10:01] <SpamapS> they mostly just look like shades of gray
[10:01] <pitti> really? there are only four: white, black, blue (CPU), pink (IO wait)
[10:02] <SpamapS> except the green ;)
[10:02] <pitti> ah, right
[10:02] <pitti> so your boot is entirely stuck on utterly slow data reading
[10:02] <pitti> in theory ureadahead ought to help there quite a bit
[10:02] <pitti> you have one or two peaks with 40 MB/s, but most of the time only a tiny fraction of that
[10:03] <SpamapS> yeah I wonder why ureadahead hasn't been updated
[10:03] <pitti> SpamapS: try a comparison with disabling that apt script?
[10:03] <SpamapS> since 9/20!
[10:03] <pitti> SpamapS: if it is, you should have /var/lib/ureadahead/*pack
[10:03] <SpamapS> oh I hav eno packs, just debugfs
[10:03] <SpamapS> hm
[10:04] <pitti> SpamapS: do you have /etc/init/ureadahead.conf ?
[10:05] <SpamapS> yes indeed
[10:05] <pitti> hm, so perhaps it fails for some reason to write the pack files
[10:05] <SpamapS> it was in fact running during bootchart
[10:06] <pitti> SpamapS: http://people.canonical.com/~pitti/bootcharts/tick-lucid-20100622-standard.png
[10:06] <SpamapS> are we graphing bootchart somewhere btw?
[10:06] <pitti> that's from my utterly slow latitude d430, its disk really sucked (20 MB/s)
[10:06] <pitti> but even there ureadahead saved some 30 or 40 seconds
[10:06] <SpamapS> I swear we do *way* too much manual testing
[10:06] <pitti> SpamapS: yes
[10:06] <pitti> http://reports.qa.ubuntu.com/reports/boot-speed/
[10:06] <pitti> the beginnings of it, anyway
[10:07] <SpamapS> cool
[10:08] <SpamapS> I'm going to reboot with console output in /etc/init/ureadahead.conf
[10:09] <SpamapS> I think you may be right that its not writing the pack files
[10:09] <pitti> SpamapS: oh, how do you get the console output of a job?
[10:10] <pitti> so far I kludged that with something like "exec 2>/tmp/log; set -x" in the pre/post-start scripts
[10:10] <SpamapS> pitti: ctrl-alt-f7 ;)
[10:10] <pitti> (to debug these particular parts)
[10:10] <pitti> ah, ok; no magic cookie
[10:10] <SpamapS> might end up in /var/log/boot.log too
[10:10] <SpamapS> but thats hit or miss
[10:11] <SpamapS> pitti: I think jhunt is working on a dmesg-like thing for job output buffers
[10:11]  * SpamapS reboots...
[10:12] <ogra_> hmm, is mom not working (or did we stop isung it) 8 merges for main doesnt look much
[10:13] <Laney> ogra_: Think you clicked on the manual link :-)
[10:13] <Laney> look above
[10:13] <pitti> https://merges.ubuntu.com/main.html looks fine
[10:14] <ogra_> Laney, lol, yeah, you are right
[10:14] <ogra_> thanks !
[10:14] <Laney> i did the same the other day
[10:14] <cjwatson> and no we have not stopped using MoM
[10:15] <ogra_> obviously ... as long as the user can read it even works as expected ;)
[10:22] <SpamapS> pitti: ok, so I just realized I uninstalled/reinstalled bootchart between runs... i wonder if something it does during its install removes the pack files. They're there now
[10:22]  * SpamapS needs to go back to sleep. Stupid smoke alarms
[10:23] <pitti> SpamapS: yes, bootchart changes the boot sequence; the pack files are removed, triggered by changes to /etc/init
[10:28] <SpamapS> pitti: thats what I thought.. so my first 2 were probably more accurate ;)
[10:31] <pitti> cjwatson: do you have an opinion about bug 873401? should live-build not write a header to the md5sum.txt file, or can we fix gfxboot's checksum thingy (I don't know which package that is) to ignore the header?
[10:34] <cjwatson> the latter.  I'll deal with it
[10:34] <cjwatson> and it has nothing to do with gfxboot :)
[10:34] <pitti> I thought so, but for the lack of a better name :)
[10:34] <pitti> what part does that, OOI?
[10:35] <cjwatson> see the bug
[10:35] <cjwatson> (reassigned and such)
[10:35] <pitti> ah, casper, nice
[10:35] <pitti> thanks
[10:54] <leex> slangasek: I guess it was removed by upgrading to 11.10
[10:54] <leex> slangasek: there should be some docu that states that fact, would have helped me a lot
[10:58] <leex> slangasek: thanks for the info ;)
[10:59] <cjwatson> it would have taken specialised gymnastics to have libc6:i386 installed before upgrading to 11.10
[11:00] <cjwatson> the only people for whom that should have been true would have been people working on multiarch implementation, really
[11:04] <oimon> tkamppeter: i wonder if you can help - i've been after a particular ppd file (pxl1010.ppd) since linuxprinting.org went offline - can you advise where i can get it?
[11:21] <tkamppeter> oimon, this is in the source of foomatic-db. Do "apt-get source foomatic-db" and you find the XML files for it in /deb/source/.
[11:21] <oimon> tkamppeter: excellent, many thanks :)
[11:22] <tkamppeter> oimon, to build the Ubuntu package with it, edit db/source/driver/pxl1010.xml removing the "<obsolete ...>" line.
[11:22] <oimon> cheers - any news on when the website is coming back btw?
[11:24] <tkamppeter> oimon, every week they say "next week", on UDS I will look into getting another hoster ...
[11:25]  * StevenK stares at apt.
[11:25] <StevenK> W: Failed to fetch copy:/var/lib/apt/lists/partial/silver_ubuntu_dists_oneiric_main_i18n_Index  Encountered a section with no Package: header
[11:25] <StevenK> I thought the index wasn't supposed to have any Package: headers ...
[11:26] <cjwatson> kees: I'm stealing your jasper merge, per your comments of a few days ago that you weren't going to have time for a while
[11:26] <cjwatson> StevenK: I bet you have an out-of-date apt from oneiric beta-1.  upgrade it
[11:26] <StevenK> By hand, I guess
[11:26] <cjwatson> no need for that
[11:26] <cjwatson> apt-get update has updated enough stuff that you can 'apt-get install apt' now
[11:26] <StevenK> And yeah, that chroot is a bit stale
[11:27] <StevenK> cjwatson: Sorted, thanks.
[11:27] <cjwatson> this is bug 871731 which we decided to accept
[11:27] <cjwatson> you may remember it from LP conversation just pre-release :)
[12:05] <kirkland> SpamapS: update-motd doesn't get run until login
[12:05] <kirkland> SpamapS: should not affect boot time
[12:06] <kirkland> Spads: something else must be running that apt-check
[12:28] <soren> kirkland: I'm not sure that's true.
[12:28] <soren> kirkland: Hang on.
[12:28] <kirkland> soren: oh, hmm, actually
[12:28] <soren> kirkland: The mounted-run job runs update-motd.
[12:28] <kirkland> soren: ah, you're right ...
[12:49] <speakman> My pulseaudio session daemon seems to stop sometimes (I think it's Flash doing something). How do I best turn on debugging of the daemon?
[12:49] <speakman> (I've been running it in the foreground most of the day but of course nothing happens)
[12:56] <tkamppeter> pitti, hi
[13:14] <speakman> hm it just died. saying "Killed". wtf?
[13:14] <cjwatson> that sounds like the out-of-memory killer got it; I bet you'll find something in /var/log/syslog and/or /var/log/kern.log
[13:15] <cjwatson> (it's possible some other process was at fault)
[13:17]  * cjwatson upgrades to precise
[13:17] <cjwatson> WCPGW
[13:17] <ogra_>  good luck :)
[13:18] <nigelb> I'm surprised by brain interpreted WCPGW /very/ fast.
[13:18] <nigelb> s/by/my/g
[13:18] <cjwatson> apt-get did tell me that there were some ocaml-related uninstallables (which I'm working on clearing), but otherwise it seems OK at least at that level
[13:19] <speakman> cjwatson: no debugging was enabled. Just changed that in /etc/pulse/daemon.conf. I'll watch syslog for error messages.
[13:19] <cjwatson> OOM killer events will get logged by the kernel regardless of pulseaudio logging levels
[13:20] <ogra_> you should find it in dmesg
[13:47] <SpamapS> kirkland: something was running check-new-release early in the boot.. update-motd was thought to possible be it.
[13:51] <SpamapS> possibly even :p
[13:52] <cjwatson> SpamapS: do you think you could merge gdal?  it needs a rebuild for the libjpeg transition, and if it needs to be merged anyway ...
[13:52] <SpamapS> cjwatson: sure, will merge it today.
[13:52] <cjwatson> thanks!
[13:53] <luist> hey… if im installing a symbolic link when building a package, will it get the real file to build?
[13:54] <cjwatson> not quite sure what you mean, maybe an example would help
[13:54] <speakman> are there any #ubuntu-pulseaudio sort of channel?
[13:54] <luist> well in my debian/install i have:  myApp       usr/bin
[13:55] <luist> but myApp is a sym link to where the executable really is
[13:55] <cjwatson> where is that symlink created?
[13:56] <cjwatson> and where is the real executable?
[14:01] <stgraber> geser: ping
[14:01] <doko> hmm, who did score up the powerpc builds?
[14:01] <luist> cjwatson: its in the development folder… :P
[14:01] <luist> cjwatson: on the same level, but diff folder
[14:03] <cjwatson> luist: sorry, I don't think that answers my question.  Perhaps you could put the whole source package somewhere?
[14:03] <cjwatson> doko: me - trying to get some multi-level transitions done and it's easier if all architectures keep up
[14:03] <cjwatson> doko: what's the problem?
[14:04] <luist> cjwatson: i dont see whats so hard to understand… im putting a symbolic link in the install list and i want to know if its gona pack a broken link or the real file
[14:04] <cjwatson> luist: there are a couple of different things you might mean and I need specifics.  Please can I see the whole source package?
[14:04] <cjwatson> I don't have time to guess
[14:05] <doko> cjwatson, hmm, I did rescore openjdk-6 for the security update
[14:05] <cjwatson> (answered doko in /msg)
[14:11] <cjwatson> luist: you see, the answer depends on things like whether the symlink is absolute or relative, and whether it's statically present in the tarball, created in a Makefile or similar, or created with dh_link
[14:12] <cjwatson> luist: and on whether the real path to the executable is installed in the package
[14:12] <cjwatson> luist: this kind of thing is much easier to tell without lots of going back and forth by just looking at a source package, if that's at all possible
[14:57] <Daviey> doko: Did you have any comments about the php5 debian package you merged?
[15:08] <smoser> slangasek, i'd be interested in your feedback on https://code.launchpad.net/~smoser/ubuntu/oneiric/isc-dhcp/lp857524/+merge/76791 . cjwatson would also be nice as i know you've touched that package (i think for installer primarily).
[15:12] <cjwatson> smoser: I agree with Marc; there's no reason not to update this file atomically
[15:13] <cjwatson> please refactor the patch to do so (it sounds like that's what the code did originally)
[15:13] <smoser> cjwatson, actually i dont think you can accomplish that
[15:13] <smoser> with read-only /etc/
[15:13] <cjwatson> I don't care how narrow a race condition is; it's either there or it isn't.  Actually a narrow one is worse than a wide one.
[15:13] <cjwatson> if /etc is read-only then you can't write to /etc/resolv.conf either
[15:14] <smoser> ah, yeah, i just have to find the  target of the link if its a link
[15:14] <smoser> and put the temp file on *that* filesystem
[15:14] <cjwatson> if /etc/resolv.conf is a symlink to somewhere writable, then update it atomically there
[15:14] <cjwatson> right
[15:14] <mdeslaur> smoser: you could follow the symlink and create the tempfile wherever the real resolv.conf turns out to be located
[15:14] <mdeslaur> heh
[15:14] <smoser> anyone else want to repeat ?
[15:14] <smoser> :)
[15:14] <cjwatson> narrow worse than wide> because it's harder to debug
[15:15] <mdeslaur> smoser: I'm not afraid of a write race, I'm more afraid of a read race while the address is being renewed
[15:15] <smoser> mdeslaur, well that'd take a lockfile via some mechanism to address, right?
[15:16] <cjwatson> yup, and that would be absolute hell to debug, so let's not doom our successors to that
[15:16] <cjwatson> no, mv into place is enough
[15:16] <cjwatson> prevents reading an incomplete resolv.conf
[15:17] <smoser> cjwatson, i didn't understand "narrow worse than wide>"
[15:17] <cjwatson> 16:13 <cjwatson> I don't care how narrow a race condition is; it's either there or it isn't.  Actually a narrow one is worse than a wide one.
[15:17] <smoser> oh. regarding the race.
[15:41] <smoser> cjwatson, quick question.
[15:41] <smoser> in the case where there is no /etc/resolv.conf, the old chown / chmod would fail.
[15:41] <smoser> should i explicitly set root:root 644 on it then ?
[15:41] <smoser> or let the normal umask/uid/gid of this script be used.
[15:42] <cjwatson> I'm not sure.  Does the normal umask/uid/gid produce the right answer?
[15:43] <smoser> well this would be running as root, called through ifup
[15:43] <smoser> so i assume uid:gid is right
[15:44] <cjwatson> smoser: if it produces the right answer then I think I would be happy to just use the defaults
[15:51] <smoser> cjwatson, test here shows root:root 644.
[15:51] <smoser> so we'll go with that.
[15:52] <cjwatson> ok
[16:14] <leex> hi, since you guys have been helpful yesterday, I would like to be helped again ;) when I boot I am dropped a non functional root shell instead of starting slim,xdm,gdm or ... I can switch to a different tty and just startx as a workaround, but I would like to get slim working again ;) the only thing that went wrong, judging from the syslog is [   18.189682] EXT4-fs (dm-1): re-mounted. Opts: errors=remount-ro. Does anyone have an idea where to sta
[16:16] <Daviey> infinity: *poke* bug 759545 .. if you have an idea of how to resolve this, i'd be most appreciative of a fix for alpha 1 :)
[16:17] <leex> ubottu: thanks, I will study it, brb
[16:18] <infinity> Daviey: That gives me a month and a bit to ponder it?  I'm okay with that schedule. :P
[16:19] <leex> ah, that wasn't related to me ;)
[16:31] <smoser> infinity, regarding the grub2 bug above, i'd really appreciate it if you could also address the general need for local modification to /etc/default/grub
[16:32] <smoser> right now, the cloud-images modify that file for good reason, and set:
[16:32] <smoser>   GRUB_CMDLINE_LINUX_DEFAULT=console=ttyS0
[16:33] <smoser> also we modify GRUB_HIDDEN_TIMEOUT_QUIET, GRUB_TERMINAL, GRUB_TIMEOUT
[16:37] <leex> some additional information: running 11.10, fsck done didnt help
[16:40] <slangasek> smoser: I defer to cjwatson, he seems to have the bases covered
[16:40] <smoser> agreed.
[16:44] <leex> http://paste.ubuntu.com/718018/ that's my dmesg output
[16:52]  * ogra_ glares at http://qa.ubuntuwire.org/ftbfs/ and wonders why it thinks evas and ecore are parts of ubuntu-desktop
[16:54] <cjwatson> They're in the ubuntu-desktop package set in precise.  I'm not sure why or who put them there (wasn't me).
[16:55] <ogra_> ah, i only checked for the task in the package description in oneiric
[16:56]  * ogra_ isnt really up to speed with precise yet
[16:56] <ogra_> i just found it weird to have them in a supported set
[16:56] <cjwatson> Quite.  I'll see what happens when I run the script to sync up with seeds.
[17:04] <micahg> cjwatson: would you mind if I did an audit of the various package sets at some point this cycle? some stuff does look out of place?
[17:05] <cjwatson> micahg: not at all although I don't promise to change anything ;-)
[17:05] <micahg> heh, ok
[17:05] <cjwatson> autogeneration is what makes them manageable at all
[17:08] <micahg> cjwatson: so, core, and the CD related sets are only autogenerated?
[17:08] <cjwatson> yes
[17:09] <micahg> ok, that will make this interesting then :), maybe there's a bug somewhere
[17:09] <cjwatson> there's a small exception list for moving things out of "more privileged" sets when e.g. the desktop team actually functionally maintains things in core
[17:09] <cjwatson> but I don't want to take it further than that
[17:09] <cjwatson> ogra_: should be fixed next time it updates
[17:09] <ogra_> it seems to also generate unr and netbook atm
[17:09] <ogra_> cjwatson, great
[17:10] <ogra_> i assume the two above will vanish as well then
[17:10] <micahg> cjwatson: makes sense, but when I see universe stuff in core, I start to wonder, I will do some digging at some point
[17:10] <cjwatson> micahg: that was a bug and should be gone now.
[17:11] <micahg> cjwatson: excellent, thank you
[17:11] <cjwatson> I'm not quite sure what happened, possibly a Launchpad bug on initialising the distroseries, but I can't quite tell at this point since there's little auditing.  I've made a mental note to check this out when Q opens to see if the same thing happens
[17:11] <cjwatson> It's not too big a deal since I always blat over it with an autogenerated list at some point anyway.
[17:12] <cjwatson> ogra_: unr and netbook - no idea
[17:12] <cjwatson> I'll go and have a look
[17:12] <ogra_> both  should be officially gone
[17:12] <ogra_> though i'm not sure anyone ever deleted the seed branches from the respective seeds
[17:14] <micahg> cjwatson: the other puzzling thing was something like awstats in core which seems like it should be in the server packageset, any ideas about that? (no rdepends)?
[17:15] <cjwatson> it seems to have copied some from much older series, which is odd
[17:15] <cjwatson> micahg: check germinate output
[17:15] <micahg> cjwatson: ok, thanks
[17:15] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.precise/rdepends/ALL/awstats - seeded
[17:18] <cjwatson> my guess as to what's happened here is that LP has made precise packagesets be the union of those in all previous series, rather than the immediately previous one
[17:18] <micahg> ah, that seems bad
[17:18] <cjwatson> but I've run out of time to investigate this right now and it's not super-urgent
[17:20] <Riddell> ogra_: could you renew my membership of canonical-arm-dev?
[17:20] <ogra_> sure, one sec
[17:20] <micahg> cjwatson: ok, if I get time, I"ll dig more and file bugs as appropriate (probably not until after UDS)
[17:21] <ogra_> Riddell, you got one more year :)
[17:28] <Riddell> thanks ogra, I shall savour every day of it
[17:28] <leex> Can anyone confirm that there is no /etc/inittab on ubuntu 11.10?
[17:28] <Riddell> leex: yes
[17:29] <leex> Riddell: thanks
[17:30] <leex> Riddell: still searching for my strange "dropped to root shell after boot"-bug
[17:30] <slangasek> dropped to a root shell, or dropped to a login prompt?
[17:31] <leex> slangasek: dropped to a login prompt would be ok ;)
[17:31] <slangasek> I'm asking which happens
[17:31] <leex> slim just stopped working, and I get a root shell instead
[17:32] <leex> [   14.546502] init: failsafe main process (796) killed by TERM signal ... [   14.588677] init: lightdm main process (1053) killed by TERM signal
[17:33] <leex> http://paste.ubuntu.com/718075 that's the whole dmesg
[17:34] <slangasek> the only cases in the 11.10 boot sequence that will give you a root shell are 1) booting in recovery mode (booting with 'recovery' on the kernel commandline), 2) booting with 'S' as the runlevel target, 3) a critical failure in mountall causing it to drop to a root shell for you to fix your filesystem
[17:35] <slangasek> do you know if any of these apply to your case?
[17:35] <leex> slangasek: I did a shutdown -rF now, before comming here
[17:35] <leex> slangasek: I did not select recovery mode
[17:35] <leex> slangasek: how can I check for the runlevel target?
[17:36] <slangasek> the runlevel target would also be on the kernel commandline (normally) - since your dmesg doesn't show that, it's probably not runlevel S either
[17:37] <slangasek> however, this dmesg shows processes being killed by SIGTEMR
[17:37] <slangasek> SIGTERM
[17:37] <slangasek> that's not at all normal
[17:37] <slangasek> did you use SysRq to kill the jobs?
[17:37] <leex> slangasek: y
[17:37] <leex> slangasek: no
[17:37] <slangasek> ok
[17:37] <leex> slangasek: I just enter my luks password, nothing else
[17:38] <leex> I justed upgraded from 11.04 recently, but that's a week ago. and I havent had the issue til today
[17:38] <leex> should I file a bug report?
[17:39] <slangasek> you might want to check if you have any modified files under /etc/init or /etc/init.d, or anything in either of those directories not belonging to a package; or if you have put anything unusual in /etc/rc.local.  This doesn't look like an Ubuntu bug, it looks like something has run amok in your startup sequence and is killing off processes
[17:40] <leex> hmm, I will check, have to leave office now though. I will have a look at and tell you lator
[17:40]  * ogra_ sees gdm in the dmesg output
[17:40] <leex> but I didn't touch any of these files by hand
[17:40] <ogra_> how did you do your upgrade from 11.04 exactly ?
[17:41] <slangasek> ogra_: the upgrade from 11.04 is expected to leave gdm installed, and that's not the bug
[17:41] <leex> ogra_: upgrade manager
[17:42] <infinity> I have a hard time seeing this as an upgrade bug anyway.  Worked fine for a bit, exploded today.  And, seriously, what runs amok and kills everything, including rc?
[17:42] <leex> infinity: ack
[17:42] <infinity> My kingdom for sane init logs.
[17:43] <slangasek> infinity: define? :)
[17:43] <slangasek> infinity: better yet, define in Orlando :)
[17:44] <infinity> slangasek: Can I just hand-wavingly say "something a lot more verbose than his dmesg output that would tell me WTF happened there"? :)
[17:44] <slangasek> infinity: you can, but that's not actionable :)
[17:44] <slangasek> we do have working /var/log/boot.log
[17:44] <infinity> With nothing else to blame, I'd guess sendsigs is being run in runlevel 2.
[17:44] <infinity> Which would be... Special.
[17:44] <slangasek> and you can boot with --verbose
[17:44] <ogra_> slangasek, ah, i wasnt aware it leaves gdm in place
[17:45] <slangasek> infinity: right, also notice the gap in timing of the SIGTERMs... one batch at 17s after boot, another at 39s after boot
[17:45] <slangasek> thigns are getting killed *twice*
[17:45] <slangasek> maybe sendsigs is in both /etc/rcS.d and /etc/rc2.d :P
[17:45] <slangasek> leex: ^^ make sure there are no symlinks to /etc/init.d/sendsigs in either of these directories, please
[17:45] <leex> have to go home now, but if you have an idea on how to track this bug, please let me know. btw here is my boot.log http://paste.ubuntu.com/718082
[17:45] <infinity> slangasek: Though, that still wouldn't do anything bad.  sensigs start is a no-op.
[17:46] <leex> slangasek: I will do, back in about an hour
[17:46] <slangasek> in any event, sendsigs is *not* supposed to kill anything that's attached to an upstart job
[17:46] <slangasek> infinity: it could be a K link?
[17:46] <infinity> That would be even more special. ;)
[17:46] <slangasek> this whole scenario is unambiguously special
[17:47] <infinity> If this proves to be an upgrade bug, I think we're getting ever closer to discovering the long-sought-after secret to punching people in the face over the internet.
[17:48] <slangasek> leex: fwiw, your boot.log shows that your system *is* entering single-user mode, *after* having started runlevel 2: "* Starting System V single-user mode compatibility"
[17:48] <slangasek> infinity: see? we have logs
[17:48] <slangasek> we just need to line wrap them properly
[17:49] <infinity> slangasek: Oh, I may have missed the bit where a log was provided. :)
[17:49] <slangasek> infinity: it was provided after you asked :)
[17:49] <infinity> Also, I can't read.
[17:52] <slangasek> leex: this message comes from /etc/init.d/single, which is somehow being invoked.  Up to line 60 of your paste, everything appears to be correctly starting runlevel 2, then all of a sudden, with no indication of runlevel change, /etc/init.d/single has been called.  I suspect there's a wrong link to this script in /etc/rc2.d.
[17:52] <infinity> Indeed.
[17:54]  * infinity wonders if one of the many "user-friendly" rc editors is to blame.
[17:54] <infinity> Or something.
[17:55] <infinity> leex: For the record, on a stock install you should see this:
[17:55] <infinity> adconrad@cthulhu:~$ ls /etc/rc?.d/???single
[17:55] <infinity> /etc/rc1.d/S90single
[17:55] <infinity> (And no other links)
[18:12] <superm1> Daviey, if it's got my fixes, yeah that sounds good
[18:18]  * Daviey tries to remember context
[18:24] <superm1> Daviey, python mysqldb
[18:25] <Daviey> ah!
[18:25] <Daviey> superm1: Are you handling the sync?
[18:25] <superm1> Daviey, you can go ahead if you'd like
[18:26]  * Daviey tries the whizzy webui
[18:26] <superm1> I don't have a precise schroot set up yet, and don't plan on getting to that until after UDS probably
[18:26] <leex> re ;) reading backlog
[18:27] <Daviey> seems the option has been disabled.
[18:27] <Daviey> gah
[18:28] <leex> infinity: sysv-rc-config
[18:29] <leex> infinity and slangasek how to figure out what's wrong?
[18:29] <slangasek> leex: covered in scrollback - having any links to 'single' outside of /etc/rc1.d is wrong
[18:30] <leex> lrwxrwxrwx 1 root root 16 2011-10-20 14:16 S90single -> ../init.d/single*
[18:30] <leex> :D
[18:30] <leex> in rc2.d
[18:30] <leex> slangasek: can I just remove that?
[18:31] <slangasek> sysv-rc-config isn't a package in the archive.  Where did you get it... and why did you think to run it on your systeM?
[18:31] <slangasek> leex: yes, you can and *must* remove it
[18:31] <slangasek> oh, it's called sysv-rc-conf, maybe
[18:31] <leex> sry, sysv-rc-conf
[18:32] <leex> slangasek: will restart and check whether it is ok
[18:32] <slangasek> leex: in the future, when asking why your system doesn't boot, "I ran a runlevel editor recently" would be pertinent information to mention ;)
[18:33] <smoser> cjwatson, please re-review https://code.launchpad.net/~smoser/ubuntu/oneiric/isc-dhcp/lp857524/+merge/76791 . it uses tmpfile and move now.
[18:34] <smoser> generally, what is the right way to do ask such a thing? am i supposed to hit 'requeest another review' ?
[18:34] <leex> slangasek: I am sorry :/ I forgot about it, I know that it would have been good to tell you.
[18:35] <leex> oh yeah it fixed it
[18:35] <slangasek> :)
[18:35] <slangasek> hallyn: fwiw, bug #880996 is a duplicate... yes, qemu-system-ppc doesn't work, we know
[18:35] <leex> I will note not to use sysv-rc-conf again :)
[18:36] <hallyn> slangasek, sorry, i should've looked for a dup
[18:36] <leex> slangasek: any recommendations for a rc editor?
[18:36] <slangasek> hallyn: no worries
[18:36] <hallyn> slangasek, i still was wondering if he was actually trying to boot a ppc .img with qemu-kvm
[18:36] <slangasek> leex: I'm afraid not.  The last I looked, none of them presented a very good interface
[18:37] <leex> slangasek: ok, then I will read some tut on how to edit them by hand ;)
[18:41] <leex> slangasek: fixed the slim rc config and anything is back to normal
[18:41] <leex> yeah, thanks everyone for helping me!
[18:43] <slangasek> YokoZar: so, ia32-libs is out of the picture now.  any thoughts on how to split the 32/64-bit parts of wine to be installable for 12.04 without use of biarch?
[18:50] <infinity> slangasek: wine1.x = metapackage that depends on wine1.x-32 on i386 and wine1.x-32 & wine1.x-64 on amd64, ship wine1.x-32 only on i386, done?
[18:51] <infinity> (And make wine1.x-64 depend on wine1.x-32, for people who blatantly avoid the metapackage, since I suspect 64 would actually need 32 to be fully useful, though I'm not sure)
[19:06] <slangasek> infinity: does that mean you're volunteering to do the conversion? ;)
[19:10] <infinity> slangasek: It really doesn't.
[19:11] <infinity> slangasek: I know somewhere between nothing and very little about wine, see the part where I'm not even sure if wine64 needs wine32 to function (though, I'd guess it does, based on what I know about win64 and win32).
[19:11] <infinity> Well, s/function/function usefully/
[19:14] <jcastro> pitti: ok you should be seeing a schedule update now
[19:20] <killown> What does the unity developers thinks that the "show desktop icon"  isn't  usefull?
[19:20] <killown> Very annoying shortcut key ctrl+alt+d ...
[19:30] <Quintasan> tumbleweed: GZ
[19:40] <tumbleweed> Quintasan: eh?
[19:47] <Quintasan> Aren't you on DMB tumbleweed?
[19:47] <dobey> hrmm, no patch pilot?
[19:49]  * dobey wonders who to bug for sponsoring, with some people already in/headedfor orlando
[19:50] <tumbleweed> Quintasan: as of very recently, yes :)
[19:50] <tumbleweed> Quintasan: thanks :)
[19:51] <LaserJock> cjwatson: awesome blog post! I love the +1 maintenance team idea
[19:51] <Quintasan> You're welcome. :-)
[19:59] <YokoZar> slangasek: Yes, there's a whole procedure to go through on Wine's wiki.  I'll take care of it.
[19:59] <YokoZar> Also what infinity said
[20:08] <barry> tumbleweed: how did i miss the fix for syncpackage? ;)  has it landed already and i missed it?  was there an open bug and i missed it?  in any event, glad you fixes those issues
[20:09] <tumbleweed> barry: it's in unapproved since this morning
[20:09] <tumbleweed> we were waiting for the previous SRU to be approved first
[20:10] <barry> tumbleweed: just curious, was it my bug report that triggered your fix, or was this another case of ships crossing in the night?
[20:10] <tumbleweed> I'd already fixed it in trunk a week or two ago
[20:11] <tumbleweed> then slangasek ran into it again on the weekend and I prepared an SRU, but it was blocked until this morning
[20:11] <barry> tumbleweed: cool.  i must have looked at the wrong branch.  yay tho!
[20:11] <barry> (i did search the bug tracker but didn't find anything)
[20:12] <tumbleweed> the bugs live in the ubuntu source package, and the code in the lp project
[20:13] <tumbleweed> IIRC the discussion about it happened on -release. But u-d-t discussion also often happens in -motu
[20:14] <barry> tumbleweed: cool.  i wasn't around much this weekend.  i did look in the source package bugs, but i looked in the source package branch too, which is how i missed it
[20:14] <barry> tumbleweed: no worries.  glad it'll be fixed.
[20:15] <tumbleweed> :)
[20:28] <kees> cjwatson: cool, have at it
[20:33] <barry> tumbleweed: i see the debdiff attached to the dup'd bug.  note that my patch also fixed the printing of the url that 404'd, but i don't see that in the debdiff.  you might want to consider that too, as what's currently printed isn't much help in figuring out what went wrong (e.g. you're misled to think that packages.debian.org is offline)
[20:35] <tumbleweed> barry: true, although this is a known issue if you are familiar with requestsync
[20:35] <tumbleweed> I'll apply that to trunk
[20:35] <barry> thx
[21:01] <slangasek> YokoZar: hmm, where's wine's wiki and where is this page, OOI?
[22:07] <cjwatson> smoser: done
[22:07] <cjwatson> LaserJock: thanks :)
[23:23] <YokoZar> slangasek: http://wiki.winehq.org/Wine64ForPackagers
[23:26] <RAOF> YokoZar: Does that mean that we'll likely be having a WoW64 wine build on amd64 in Precise?  Cool!
[23:26] <YokoZar> RAOF: yeah, it's something I've been putting off until after multiarch
[23:26] <RAOF> Sweet.
[23:26] <slangasek> ah, do we currently not have any win64 support at all?
[23:27] <slangasek> perhaps I misunderstood the state of the art
[23:28] <broder> WoW64 is 32-on-64, right?
[23:29] <YokoZar> slangasek: Right, we don't build Wine in 64 bit mode at the moment.  It's straight forward to make a 64 bit only Wine, but it's fairly useless.
[23:29]  * slangasek nods
[23:30] <YokoZar> broder: Yes, a bit confusingly named
[23:30] <YokoZar> broder: even more confusingly is that the windows "system64" folder actually contains the 32 bit dlls I think
[23:30] <broder> YokoZar: yeah, that's how i remembered it working, too
[23:54] <SpamapS> woot, MBA has graphics .. but.. touchpad broken now. DOH