[00:19] <GunnarHj> slangasek: still there?
[00:22] <slangasek> GunnarHj: yep
[00:28] <GunnarHj> slangasek: In sudo they have user_readenv=0, so I  take it that the sudo tasks are invalid on bug 952185.
[00:29] <slangasek> GunnarHj: yep, sounds like they are
[00:29] <slangasek> GunnarHj: good catch, sorry I overlooked that
[00:29] <GunnarHj> slangasek: Ok, then my thinking was right for once. ;-)
[00:48] <smoser> slangasek, ok... new theory.
[00:48] <smoser> cloud-fconfig actually just writes the shell script.
[00:48] <smoser> cloud-final would run it
[00:49] <smoser> cloud-final runs on
[00:49] <smoser> start on (stopped rc RUNLEVEL=[2345] and stopped cloud-config)
[00:49] <slangasek> smoser: well, that doesn't look problematic to me
[00:50] <smoser> no?
[00:50] <smoser> i think this was reported as https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1103881
[00:50] <slangasek> ah
[00:50] <smoser> which i think is a wrong diagnosis, i'm seeing this without upgrade of upstart.
[00:50] <slangasek> mm
[00:51] <slangasek> well, jibel seemed convinced it was happening only when upstart was getting upgraded
[00:51] <smoser> in our pastebin here http://paste.ubuntu.com/1646707/
[00:51] <smoser> we never see 'rc' stop
[00:51] <slangasek> ah
[00:52] <slangasek> so what all is in /etc/rc2.d/ ?
[00:52] <slangasek> the only thing I know of that would prevent 'rc' from stopping is an init script that's hanging
[00:53] <slangasek> and jibel's bug does show rc being stopped (https://launchpadlibrarian.net/129295546/LP1103881.dmesg)
[00:53] <slangasek> so I think you have two different bugs with the same symptom
[00:53] <smoser> hm... so maybe they're coincidence.
[00:54] <smoser> just 'set -x' on rc
[00:54] <smoser> into /run/log
[00:54] <smoser> so i'll see that here  in a minute.
[00:54] <slangasek> ok
[01:04] <smoser> slangasek, i've got to run again. i'm really confused now.
[01:04] <smoser> http://paste.ubuntu.com/1647304/
[01:05] <slangasek> smoser: well, this shows no rc (or rc-sysinit) job running at all... ?
[01:05] <smoser> right.
[01:07] <smoser> tomorrow
[01:25]  * xnox waves from february 14th =) the international day of loving to debug mysterious presents in boot stacks
[01:25] <slangasek> it's a niche holiday
[01:37] <mwhudson> not really the right place to ask the question but
[01:37] <mwhudson> are there any docs on building custom initramfses?
[01:38] <mwhudson> i want mkfs + friends in one
[01:38] <TheMuso> You need only write a hook for update-initramfs to run to put the files you want in the initramfs.
[01:39] <mwhudson> sounds suspiciously easy
[01:39] <hallyn> hm, my boot time in raring just got really bad in the last few days.  from about 8 secs to about 30 secs.  bootchart doesn't show disk use or anything...
[01:39] <TheMuso> mwhudson: Look in /usr/share/initramfs-tools/hooks/ for some good examples.
[01:39] <TheMuso> mwhudson: Then its just a matter of writing extra hooks to be run in the initramfs.
[01:39] <mwhudson> ok
[01:40] <mwhudson> do you have to build the initramfs on the same arch as you're going to run it on?
[01:40] <mwhudson> i guess practically speaking yes
[01:40] <cjwatson> Yeah
[01:40] <cjwatson> Since it copies stuff from the host fs
[01:41] <hallyn> really dbus-daemon is the only thing that stops right when gnome stuff finally starts
[01:41] <mwhudson> i suppose you can chroot + qemu-arm-static
[01:41] <mwhudson> but
[01:41] <cjwatson> In principle yes
[01:42] <cjwatson> amd64 <-> i386 probably works fine with chroots; not sure if there mightn't be some weird quirk with ARM, but worth trying if it would make life easier
[01:42] <mwhudson> not sure if it would tbh
[01:42] <mwhudson> just the tediousness of copying files around
[01:45] <penguin42> mwhudson: You can, it does work for simple stuff (or did 18 months or so ago last time I tried it)
[01:47]  * xnox does qemu-arm-static a lot. For most things it's quicker than panda, but nexus7 beats it, as compared to my i5
[05:36] <pitti> Good morning
[06:03] <YokoZar> *files bug against 6 packages, uploads debdiffs for all, makes sponsorship queue sad*
[06:06] <YokoZar> Is it correct for apt-get-install foo to bail out if recommends are uninstallable without the --no-install-recommends flag, or should apt be trying to get as many as it can?
[06:09] <slangasek> YokoZar: unsatisfiable recommends should not cause apt-get to bail out, though they will cause warnings to be output
[06:10] <YokoZar> slangasek: Then this is also an apt bug :D https://bugs.launchpad.net/ubuntu/+source/winetricks/+bug/1123710
[06:12] <slangasek> YokoZar: I'm reasonably certain that the problem there is not that the recommends are uninstallable, but that the recommends are available, apt follows them, and as a result renders one of the *depends* uninstallable
[06:13] <slangasek> so... yes, apt could be smarter about skipping the recommends in that case, but this is a complicated problem
[06:15] <YokoZar> slangasek: so apt is considering switching a recommended (arch all but not M-A: foreign) package to it's "i386" version, then trying to get i386 versions of the arch:all's package depends, and then hitting a conflict and giving up rather than just ignoring the recommend
[06:16] <slangasek> hitting a conflict because it's managed to break one of the dependencies in the process and is too far down the rabbit hole to unwind
[06:16] <YokoZar> slangasek: I think that's right...and I think correct for apt in this case would be to ignore the recommended package rather than count the installed arch:all version as conflicting with itself.
[06:17] <slangasek> well, it wouldn't try to use i386 packages to satisfy the dependencies of an Arch: all package, no
[06:17] <YokoZar> I meant transitive i386 deps
[06:17] <YokoZar> eg when an arch: all package had arch specific deps
[06:17] <slangasek> still no
[06:17] <slangasek> an Arch: all package will have its deps satisfied by packages of the native arch
[06:18] <YokoZar> only if it's marked M-A foreign, yes?
[06:18] <YokoZar> (in the case of installing a non-native package that depends on the arch:all package)
[06:18] <slangasek> no
[06:19] <slangasek> an Arch: all package is treated as equivalent to a package of the native arch, in every way
[06:19] <YokoZar> Err then I'm confused because all the conflicts in question in the linked bug are recommends of arch:all packages
[06:19] <YokoZar> indeed, already installed arch:all packages
[06:19] <slangasek> well, I can't reproduce that error output on a raring system, so
[06:19] <slangasek> I get a completely different set of conflicts
[06:19] <YokoZar> apt-get install wine1.4 first
[06:20] <slangasek> ah right, I have wine1.5 installed
[06:20] <YokoZar> then remove it (but not the stuff it pulls in) and apt-get install wine1.4:i386
[06:31] <slangasek> YokoZar: still can't reproduce this in a clean chroot (and I'm not clobbering the wine1.5 install on my desktop for testing right now)
[06:37] <YokoZar> slangasek: The fact that you want to protect your wine1.5 install makes me kinda happy :D
[06:38] <slangasek> I'd be happier if the software in question didn't need it ;)
[06:39] <YokoZar> slangasek: I'll see if I can nail down an exact repro step on a new VM
[07:53] <dholbach> good morning
[08:21] <Dedunu> good morning
[08:47] <Adri2000> I've got a bug waiting for archive admin action since last december (#1086468). did I do something wrong? :)
[08:47] <seb128> bug #1086468
[08:48] <seb128> Adri2000, seems not, it's just that removal are not always done regularly I think
[08:50] <Adri2000> as long as it's processed before raring is released, it's ok for me :)
[08:50] <seb128> it will, no worry
[08:51] <didrocks> doing right now :)
[08:53] <didrocks> Adri2000: done
[08:55] <Adri2000> didrocks: thanks
[08:55] <didrocks> yw
[09:02] <pitti> seb128: I'm not a big fan of a comment field for whoopsie reports because we are never going to actually review them all
[09:03] <pitti> seb128: and it would create the impression that this is a kind of bug report
[09:03] <pitti> seb128: I'd much rather see the "collect extra information" or "request filing a bug report the next time" flag
[09:03] <seb128> pitti, we could have both ;-)
[09:03] <seb128> not denying we need the "request info"
[09:04] <seb128> but as said going through an hundred description can be enough to see a pattern
[09:04] <seb128> like "I was changing user when it happened"
[09:04] <seb128> 5 of those in a long stack can be enough to give an useful clue
[09:05] <pitti> seb128: for those I'd personally prefer a bug report
[09:06] <pitti> seb128: but anyway, I'm not strongly vetoing this, I'm just not a fan of it
[09:07] <seb128> pitti, @bug report, I though the idea was to stop reports to launchpad, so we need to get the infos we need linked to the whoopsie reports
[09:07] <pitti> seb128: right, but add a flag "the next person to encounter that please file a bug report", and it waits until someone actually does
[09:08] <pitti> there will always be cases where we need a proper dialog with reporters
[09:10] <seb128> pitti, right, I just feel like if we start automatically abusing that feature to ask "what were you doing" on most bugs then it's a sign that something is not right in the system
[09:10] <seb128> and that maybe the info should be asked upfront
[09:10] <seb128> oh well, let's see how it works in practice
[09:33] <seb128> bdrung, so, after sponsoring libreoffice for Sweetshark, do you feel more comfortable for the ppu? should he run again, or is there anything you recommend him to work on/change to be accepted?
[09:34] <seb128> bdrung, the details you found/fixed in your review seems mostly small and old packaging glitches, mostly cosmetic or coming from Debian, not mistakes from Bjoern
[11:41] <davmor2> hey guys I have done a fresh install of Raring on my Lenovo Y580, good news bluetooth now works out of the box huzzah, bad news the screen is black because it is dimmed right down, I have to wait for the drums and then I can up the brightness, is there any info I can get on it for you
[13:42] <xnox> micahg: announcement? =)
[14:20] <mdeslaur> cyphermox: FYI, I'm going to nag you to get dnsmasq 2.66 into raring as soon as it comes out
[14:20] <mdeslaur> cyphermox: 2.65 breaks local resolution with libvirt
[14:36] <cyphermox> mdeslaur: ok
[14:58] <smoser> jodh, ping wrt https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1124384
[15:18] <jodh> smoser: were you running upstart in debug mode at the time?
[15:18] <smoser> have have dmesg output with --verbose
[15:18] <smoser> i can easily get you --debug
[15:18] <jodh> smoser: yes please
[15:54] <smoser> slangasek, i'd appreciate your thoughts/input on bug https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/1123220
[16:15] <SpamapS> are there known bugs in raring causing X to repeat keypresses a lot? like just normal typing but suddenlllllllllllly l repeates a bunch?
[16:16] <smoser> i've not seen that.
[16:16] <SpamapS> I hesitate to report bugs from my old macbook pro.. because it has been dist-upgraded early in each cycle since it was installed with 10.10 alphasomething
[16:16] <SpamapS> but its getting rather frustrating :-P
[16:17] <dobey> i've never seen that either
[16:17] <infinity> @pilot in
[16:17] <dobey> only on my phone, which isn't ubuntu
[16:18] <jdstrand> hallyn: hey, fyi, I just pushed libivt ubuntu5 for an apparmor denial
[16:19] <jdstrand> hallyn: libvirt*
[16:20] <smoser> @pilot out
[16:20] <hallyn> jdstrand: ok.  possibly related to the nova bug zul was mentioning?
[16:20] <jdstrand> I doubt it: access to @{PROC}/sys/vm/overcommit_memory r
[16:20] <jdstrand> seemed like a harmless denial
[16:21] <jdstrand> (but noisy)
[16:21] <hallyn> oh, ok
[16:23] <apw> slangasek, can you remind me when and who switches us to vt during boot
[16:24] <apw> slangasek, in the non vt-handoff case
[16:38] <user12423> is ubuntu 12.04.2 released yet?
[16:39] <cjwatson> user12423: Nearly but not quite
[16:39] <cjwatson> Sorting out the tail end of testing
[16:40] <user12423> cjwatson: how much time will be take? Will it be released today?
[16:40] <cjwatson> Let's just say that I'm doing the release, I'm in the UK, and I want to be able to go to the pub with a clear conscience this evening
[16:40] <mdeslaur> hehe
[16:42] <user12423> cjwatson: I have read that ubuntu 12.04.2 comes with kernel 3.5. Will it work with proprietary ati drivers for radeon 4000 series as they are not compatible with quantal?
[16:42] <cjwatson> I'm afraid I don't know; you'll have to ask X folks, perhaps #ubuntu-x
[16:42] <user12423> cjwatson: ok thanks
[16:48] <infinity> user12423: Installing with 12.04.1 media and upgrading will have you on a 3.2 kernel by default, if you have a proprietary blob that hates 3.5
[16:49] <user12423> infinity: amd recently updated their legacy drivers to version 13.1, don't they work too in 3.5?
[16:49] <infinity> user12423: I have no idea, they may well work.  I was just saying "if they don't.."
[16:51] <user12423> infinity: ok
[17:08] <seb128> @pilot in
[17:34] <hallyn> slangasek: is the ovmf package intended to have a readme?
[17:35]  * hallyn wiating for src to d/l over slow link
[17:43] <hallyn> ok, i guess it's just my iso that's the problem - waiting for an even longer release iso d/l :)
[18:02] <quadrispro> hi everybody
[18:06] <quadrispro> I see dogtail is currently blacklisted, could anyone remove it from the sync-blacklist? Upstream has started again to develop and support dogtail, I took it in Debian
[18:07] <quadrispro> the latest release is available in experimental
[18:08] <mitya57_> quadrispro: https://bugs.launchpad.net/ubuntu/+source/dogtail/+bug/460210/comments/8
[18:08] <quadrispro> mitya57_, cool! thanks, I'll look into it
[18:13] <quadrispro> mitya57_, uploading the patch to experimental in few minutes
[18:14] <mitya57_> quadrispro: great, please also leave a comment on that bug
[18:21] <didrocks> barry: it seems you didn't merge oneconf 0.3.3 to lp:oneconf?
[18:21] <barry> didrocks: in a meeting...
[18:32] <mitya57_> quadrispro: did you really want to remove "def _getEncoding(self):" line?
[18:33] <mitya57_> nevermind, I've got confused by diff output :)
[18:34] <quadrispro> eh yes :) np
[18:34] <quadrispro> see you around
[18:47]  * mitya57_ wishes good night to everybody
[19:00] <seb128> stgraber, hey, can you set https://code.launchpad.net/~baltix/ubuntu/precise/ubuntu-defaults-builder/remove-quotes-from-firefox-bookmarks-titles/+merge/137107 as "work in progress"?
[19:00] <stgraber> seb128: done
[19:00] <seb128> stgraber, thanks
[19:10] <slangasek> smoser: bug #1123220> hmm, that seems to me that your a) option is the best (kernel not attaching /dev/console to something that doesn't work)
[19:10] <slangasek> apw: what do you mean by "to vt"?
[19:10] <timrc> wookey, Hi, I've been trying to figure out multistrap.. I noticed in raring version, 2.1.6ubuntu3, still contains /usr/share/multistrap/ubuntu/crosschroot-maverick.conf -- would you like me to file a bug on this?
[19:11] <slangasek> hallyn: I didn't put any readme in the ovmf package, no
[19:16] <smoser> slangasek, but kernel is really dumb
[19:17] <smoser> and that assignment happens really early
[19:17] <smoser> back some time ago i had smb investigate a bit and he seemed to think that was non-trivial
[19:18] <smoser> even in the event that the kernel was smarter, having safety code in upstart and initramfs seems like it wouldn't hurt.
[19:18] <slangasek> smoser: well, in this case you say it's crashing in the initramfs, right?  we might reasonably be able to make upstart itself more robust against a broken /dev/console... but not every command that might write to stdout in the initramfs.
[19:18] <smoser> sh -e 'echo hi; echo by' should not exit failure.  thats just not friendly to anyone.
[19:19] <smoser> slangasek, my suggestion was that in the initramfs (early) we do the code i posted.
[19:19] <slangasek> smoser: yes, but afaics that would merely be advisory?
[19:19] <smoser> basically redirecting to somewhere in /run or /dev/null if we can't find something useful.
[19:19] <smoser> huh?
[19:20] <slangasek> oh, you're proposing actually redirecting, ok
[19:20] <smoser> oh. yes, clearly if some other script in the initramfs opened /dev/console explicitly, then i can't stop that.
[19:20] <smoser> but stdout shouldn't be broken.
[19:20] <slangasek> well, init will reopen the console
[19:20] <slangasek> I don't know if it fails in this case
[19:20] <smoser> right.
[19:20] <smoser> so upstart would need the same thing.
[19:20] <smoser> open succeeds
[19:20] <smoser> writes fail
[19:21] <slangasek> I really think this needs to be fixed in the kernel
[19:21] <slangasek> trivial or not
[19:21] <slangasek> /dev/console should not be broken when you write to it
[19:25] <smoser> slangasek, it seems like maybe my suggested work aroudn wouldn't work.  see https://bugs.launchpad.net/maas/+bug/1061977/comments/4 . i'm not certain  that is correct, but i seem to remember that some writes to /dev/console worked fine.
[19:26] <smoser> as if there was a buffer that got filled up and it didn't fail until kernel tried to flush that
[19:26] <slangasek> smoser: yeah, I was just going to say, if this is related to the other bugs I've seen before in this area, there's probably kernel buffering making a mess of it besides
[19:28] <smoser> fwiw, we have 'console=ttyS0' (and want to keep that) because cloud providers (ec2 and openstack at least) give you access to data written to the serial device
[19:28] <smoser> so you can view that log.  if we have *no* console= parms, then it goes to a vga device, which is completely useless.
[19:30]  * slangasek nods
[19:30] <hallyn> slangasek: ok - i just wasn't sure if there was something i could/should do to work around the 'secure boot not enabled' msg.
[19:30] <slangasek> hallyn: you can nag me to fix that output from shim :)
[19:31] <hallyn> nag, i can do that :)
[21:56] <seb128> @pilot out
[21:56] <ogra_> geez
[21:56] <ogra_> nighflight
[22:54] <zykes-> 7win 38
[23:34] <m4n1sh> Laney, cjwatson : is the feature freeze applicable to a main package which has a revamped UI but hardly any new features. I hope so, but just cross checking
[23:34] <m4n1sh> AFAIK you both are in release team
[23:37] <RAOF> The UI would most certainly be considered a feature. :)
[23:38] <m4n1sh> RAOF: please tell me you are joking
[23:39] <m4n1sh> or maybe my sarcasm detector is broken
[23:39] <xnox> m4n1sh: https://wiki.ubuntu.com/FeatureFreeze
[23:39] <RAOF> I'm not sure how you'd significantly rework the UI *without* requiring a FFe.
[23:39] <xnox> m4n1sh: also note https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions
[23:39] <RAOF> Or, to put it another way, a revamped UI is *definitely* a feature.
[23:40]  * xnox once revampted a non-essential ubiquity screen - only to crash by default the installer due to i18n error
[23:41] <xnox> m4n1sh: the point is that it's potentially disruptive and can introduce bugs.
[23:41] <xnox> when one least expects them.
[23:41] <m4n1sh> yeah, introducing bug is surely the biggest problem
[23:41] <m4n1sh> xnox: Thanks. So that means I am really short of time
[23:41] <xnox> m4n1sh: what package is it?
[23:42] <m4n1sh> xnox: activity-log-manager
[23:42] <m4n1sh> The new design by matthew paul thomas
[23:42] <m4n1sh> it has been present since long and implemented too, but I am fighting with the code (some startup issues) and build system
[23:43] <xnox> m4n1sh: right so User Interface Freeze is on the 21st. Just work through it and polish it, then request FFe and everything will be good.
[23:43] <xnox> m4n1sh: you have 5 weeks \o/
[23:44] <RAOF> You might also want to ask for a *preemptive* FFe; the release team like to know what's coming up.
[23:44] <m4n1sh> xnox: yeah. Just hopeful it doesnt break anything new.
[23:44] <m4n1sh> RAOF: Yes. that would be better
[23:47] <m4n1sh> xnox: this is the mockup https://lh4.googleusercontent.com/aYbxFHevnMXUmWkVF73FXF1IGj8AaxMRWCZKJb71V3vsKpWWEVmlZ7S9U-QKV3UuquFSbeU5PxnFoVXxMSlwxzfQCDmh38wKJF9ztV7MW_v_kcvO31U
[23:47] <m4n1sh> Just FYI
[23:48] <xnox> m4n1sh: the joined up dropdown + and - buttons with toolbar inline style in gtk has a bug where it will not look joined up, just so you know
[23:48] <lifeless> cjwatson: can grub2 read kernel + initramfs from within a raid6 mdadm array ?
[23:48]  * xnox has some glade work with a similar pattern from mpt for ubiquity
[23:49] <m4n1sh> xnox: in raring?
[23:49] <xnox> m4n1sh: it did in quantal, didn't check raring recently.
[23:50] <xnox> m4n1sh: yeap still broken - open "Videos" (totem) and look at the buttons just below the playlist
[23:51] <m4n1sh> xnox: I can see this http://i.imgur.com/vUJkhpT.png
[23:52] <xnox> m4n1sh: the most right "v" button should be rounded on the right
[23:52] <xnox> e.g. (+ | - | v | ^ | v ) not (+ | - | v | ^ | v ]
[23:52] <m4n1sh> xnox: oh yeah. It slipped my eyes, I thought you were talking about the buttons being spaced apart
[23:52] <m4n1sh> yeah, that is a bug
[23:53] <xnox> but it's a theming issue.
[23:53]  * xnox filed it against light-themes but still not fixed. maybe i'll have to write the patch =(
[23:53] <xnox> m4n1sh: i could also trigger it to appear as ( | )[ | | ] which is even more ugly =/
[23:54] <m4n1sh> yeah, or every button be squared
[23:54] <m4n1sh> atleast that would have consistency