=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
[04:17] <pitti> Good morning
[04:18] <ScottK> Good morning.
=== dendrobates is now known as dendro-afk
[05:40] <dupondje> xnox: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/903422
[05:40] <ubottu> Launchpad bug 903422 in gvfs "Ubuntu does not work with Samsung Galaxy phones (needs update to libmtp)" [Wishlist,In progress]
[05:41] <dupondje> ubuntu does not use libmtp, but gphoto2 to access the devices via gvfs
[06:17] <ScottK> pitti: I would appreciate it if you could have a look at Bug #1065827 and let me know if we're missing something from our seeds or if it's an actual jockey problem.
[06:17] <ubottu> Launchpad bug 1065827 in jockey (Ubuntu) "Kubuntu 12.10 bcmwl install failure" [High,New] https://launchpad.net/bugs/1065827
[06:25] <pitti> ScottK: so detection and attempt to install seemed to work alright; let me look at your desktop image's pool
[06:27] <pitti> ScottK: hm, all seems to be there; if you try "sudo apt-get install bcmwl-kernel-source" on the live system, does apt also try to download it from the network?
[06:27] <pitti> ScottK: do you see the CD source in /etc/apt/sources.list?
[06:27] <ScottK> Looking
[06:28] <ScottK> It's not in the sources.list.
[06:28] <ScottK> Which would explain it.
[06:29] <ScottK> So which package owns that problem?
[06:30] <ScottK> (and the apt-get install obviously doesn't work)
[06:36] <pitti> ScottK: is that in the live system or installed system?
[06:36] <ScottK> pitti: Live
[06:36] <pitti> ScottK: yesterday we had the topic for the installed system, where it's not entirely clear whether or not it should be there
[06:36] <pitti> ScottK: hm, somewhere in our live-build configuration then
[06:37] <ScottK> I have an install in progress on the system right now.
[06:37] <ScottK> I asked for non-free stuff to be installed during the install, so I'll know shortly if that works or not too.
[06:38] <ScottK> Then I'm going to have to crash because it's almost 2AM here.
[06:52] <ScottK> pitti: Thanks for helping out.
[06:53] <ScottK> It didn't install there either.
[07:22] <wzssyqa> I generate an iso with simple-cdd, while installing, it always ask me to insert a CD when the installation is nearly finished
=== tkamppeter_ is now known as tkamppeter
[07:30] <dholbach> good morning
=== smb` is now known as smb
=== micahg_ is now known as micahg
[08:26] <shuerhaaken> Hello. Anybody has this issue on quantal where some elements like some GtkLabels or GtkDrawingareas or the background of tabs are painted black with adwaita? See here: http://imgur.com/l8q0N
=== lifeless_ is now known as lifeless
[08:50] <xnox> dupondje: ok, then add appropriate gphoto2 task as well. sorry about that. That bug is a mess ;)
[08:55] <dupondje> xnox: gphoto2 claims to support the Samsungs
[08:55] <dupondje> it actually works (partly) when using gphoto2 commandline
[08:57] <dupondje> xnox: but it seems the MTP on the device needs calls within a few seconds after connecting
[08:57] <dupondje> else it goes into /ignore mode :p
[08:58] <xnox> dupondje: I don't have a device to test, it's just that cz<tab> was complaining that it doesn't work.
[08:58] <dupondje> its not working no (with gvfs/nautilus) indeed
[08:58] <dupondje> which is quite annoying
[08:59] <dupondje> surely because ALOT of people have a Samsung Android
[08:59] <xnox> dupondje: i think laura wanted mtp more to sync music and stuff.
[08:59] <xnox> dupondje: well i didn't migrate to android phones yet. and i gathered it was about samsung galaxy nexus
[09:00] <dupondje> nope
[09:00] <xnox> all?
[09:00] <dupondje> Samsung devices with Android 4.x
[09:00] <dupondje> so alot
[09:00] <dupondje> prolly 3.x also, but nobody uses MTP on those (as it has Mass Media option)
[09:00] <xnox> what changed?
[09:00] <dupondje> where Android 4.x only has MTP/PTP
[09:02] <xnox> well in the udev rules by libmtp I can clearly see galasy S and nexus 4.0 updates
[09:03] <xnox> dupondje: i'll look into mtp output from laura and check what's wrong later.
[09:54] <dupondje> xnox: btw, it 'worked' on precise
[09:54] <dupondje> was able to open my device in Nautilus
[09:54] <dupondje> but everything was empty :p
[09:54] <xnox> dupondje: for some value of 'worked'... I'd call that 'crashed with less flames'
[09:57] <dupondje> :)
[09:57] <dupondje> its quite annoying an device that is used so much is broken on Ubuntu
[09:59] <seb128> patches are welcome ;-)
[09:59] <seb128> or you can offer me a device and I will look at the bug :p
[09:59]  * seb128 only has a dumb bada old phone
[10:02] <dupondje> heh seb128  :)
[10:03] <dupondje> seb128: alot of things have been fixed in new gphoto2 version
[10:03] <dupondje> upstream requested to test that first, but its quite some work (new api)
[10:03] <dupondje> so gphoto2 / libgphoto2 needs to be recompiled
[10:03] <seb128> yeah, that's not going to happen for quantal
[10:03] <dupondje> and also gvfs should be adjusted/recompiled
[10:04] <dupondje> if we know the new version is ok, then we can check to maby cherry pick a patch
[10:04] <dupondje> but first should need to test the newest version
[10:06] <seb128> yeah...
[10:06] <seb128> dupondje, do you know if fedora uses the new version?
[10:06] <seb128> it might be easier to boot a live image from f18 to test
[10:07] <seb128> tseliot, hey, how are you?
[10:07] <seb128> tseliot, could you look at bug #1061659?
[10:07] <ubottu> Launchpad bug 1061659 in nvidia-settings-updates (Ubuntu Quantal) "package nvidia-settings-updates 304.43-0ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/nvidia-settings.1.gz', which is also in package nvidia-settings 304.51-0ubuntu1" [High,Confirmed] https://launchpad.net/bugs/1061659
[10:08] <dupondje> LATEST BUILD
[10:08] <dupondje> 2.5.0-3.fc18
[10:08] <dupondje> newest version :)
[10:09] <dupondje> i'll try it this evening :)
[10:16] <tseliot> seb128: hi, yes, it's on my todo list. I'll fix it soon
[10:16] <seb128> tseliot, thanks, I assigned the bug to you, I hope it's ok
[10:16] <seb128> dupondje, thanks, let me know how it goes
[10:16] <tseliot> seb128: sure, thanks
=== maxb_ is now known as Guest72551
=== dendro-afk is now known as dendrobates
[10:58] <dupondje> hmz, any idea why in usb-creator-gtk, the 'Write image' button is grayed out
[11:02] <xnox> dupondje: not enough space on the target?
[11:02] <xnox> dupondje: no source/target selected?
[11:03] <dupondje> xnox: .iso is 700MB
[11:03] <dupondje> usb stick is 3,8GB
[11:03] <dupondje> and I can only select the source from commandline :s
[11:04] <xnox> dupondje: I have no idea =) use dd or file a bug.
=== MacSlow is now known as MacSlow|lunch
=== mcclurmc_away is now known as mcclurmc
[11:11] <dupondje> lol
[11:12] <dupondje> xnox: without chaning anything, I started it again now, and it works
[11:12] <dupondje> wt... :p
[11:13] <dupondje> ahhh, it only works for Ubuntu images it seems :(
=== diwic_ is now known as diwic
=== doko_ is now known as doko
=== cpg is now known as cpg|away
[11:54] <jibel> jodh, I added a detailed test case to https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1060249/+text to reproduce from Precise without a full upgrade.
[11:54] <ubottu> Launchpad bug 1060249 in debconf (Ubuntu Quantal) "frontend crashed with signal 5 in free_pending_nulls()" [High,Confirmed]
=== MacSlow|lunch is now known as MacSlow
[12:42] <jodh> jibel: thanks very much!
[12:56] <om26er> cjwatson, Hey! you will be patch pilot today ?
[12:57] <cjwatson> Oh, I suppose I ought to be
[12:57] <cjwatson> Not clear how much I can get done given that we're hard-frozen for release
[12:57] <cjwatson> But maybe some SRU processing or something
[12:57] <cjwatson> What's up?
[12:58] <om26er> cjohnston, i have a SRU for bamf https://code.launchpad.net/~om26er/ubuntu/precise/bamf/SRU_for_lp_1026426/+merge/129405
[12:58] <om26er> fixes 1026426 a critical one
[12:58] <om26er> bug 1026426
[12:58] <ubottu> Launchpad bug 1026426 in bamf (Ubuntu Precise) "LibreOffice Unity integration (launcher and switcher) is broken" [Critical,Triaged] https://launchpad.net/bugs/1026426
[12:59] <om26er> oops
[12:59] <cjwatson> OK, I'll finish up what I'm currently working on and then start piloting
[12:59] <om26er> cool
[13:16] <diwic> I'd like bug 973014 to be SRUed as well
[13:16] <ubottu> Launchpad bug 973014 in gst-plugins-bad0.10 (Ubuntu Quantal) "gstreamer0.10-plugins-bad, (libgstvideoparsersbad.so), causes a failure to decode many common video files encoded as AVC 1 Baseline - L2.1, Baseline - L1.1 & others" [Undecided,Confirmed] https://launchpad.net/bugs/973014
[13:18] <dupondje> seb128: its broken in FC18 also :(
[13:18] <seb128> dupondje, ok, so not likely fixed by the new stack...
[13:19] <seb128> dupondje, thanks for testing
[13:19] <dupondje> indeed, but I don't know if the bug is really in gphoto2
[13:19] <dupondje> guess it gvfs <-> libgphoto2 interaction that is bit broken
[13:19] <seb128> dupondje, I guess the real fix is for gvfs to get a mpt backend (seems to be worked upstream by some contributor)
[13:19] <dupondje> yep I saw that :)
[13:42] <cjwatson> jamespage: I don't suppose the eigenbase-resgen build failure means anything to you?
[13:42] <jamespage> cjwatson, funny you should say that - I was just looking
[13:42] <jamespage> I can't reproduce it
[13:43] <cjwatson> Reproduces exactly for me in sbuild
[13:43] <jamespage> cjwatson, hmm
[13:44] <jamespage> cjwatson, i386 or amd64?
[13:45] <cjwatson> jamespage: i386
[13:45] <cjwatson> it's an arch-all build, so that's what you want
[13:46] <jamespage> cjwatson, I don't disagree but I can only fit so many schroots in my tiny SSD
[13:46] <jamespage> fortunately I have one of those
[13:46]  * jamespage tries again
[13:46] <cjwatson> That's what I have a big external disk for
[13:51] <jamespage> cjwatson, well at least I can repo now
[13:52] <cjwatson> jamespage: cool
[13:53] <jamespage> cjwatson, that is a puzzler
=== carif_ is now known as carif
[14:07] <mpt> Keep gvfs away from my backend, thanks very much
[14:20] <xnox> mpt: =))))))))
=== micahg_ is now known as micahg
[15:12] <xnox> slangasek: cjwatson: do you remember a bug or something about ubiquity unmounting /target not in a clean way resulting in journal replay on first boot/mount ?
[15:14] <cjwatson> xnox: I don't think so, although I can imagine that as a side-effect of all sorts of other things
[15:16] <xnox> cjwatson: ok. that seems to be that bug 1065034 is kind of a result of unclean fs (install, do not boot, try to reinstall). if the fs is actually clean, we proceed fine.
[15:16] <ubottu> Launchpad bug 1065034 in ubiquity (Ubuntu) "'ubuntu ubiquity: umount: /tmp/tmp.h3NCLhoxSh: not mounted' during a Reinstall attempt on a previously manually partioned vm installation" [High,Confirmed] https://launchpad.net/bugs/1065034
[15:16] <cjwatson> Could all be a side-effect of this GRUB bug, several layers down the line ...
[15:16] <xnox> cjwatson: so the bug is not nearly as bad.
[15:16] <cjwatson> I think you need a good deal more analysis, at any rate
[15:16] <cjwatson> e.g. shell tracing of where that's happening
[15:17] <xnox> yeah. that's what I am doing now.
[15:17]  * xnox well as well as ubiquity tracing as it does call out to os-prober by itself.....
[15:17] <xnox> ok.
=== ricotz_ is now known as ricotz
[15:23] <slangasek> cjwatson: which grub bug is "this" grub bug?
[15:24] <cjwatson> Sorry
[15:24] <cjwatson> slangasek: bug 1051306 - Windows detection (or indeed grub-mount handling of anything) fails in the presence of a symlink to a directory
[15:24] <ubottu> Launchpad bug 1051306 in grub2 (Ubuntu Quantal) "Windows not found unless partition is mounted" [Critical,Triaged] https://launchpad.net/bugs/1051306
[15:24] <cjwatson> *just* tracked it down that far
[15:25] <cjwatson> As it happens I have a /cdrom symlink in my / which triggers this - it's at least somewhat filesystem-independent
[15:25] <cjwatson> (Though obviously it has to support symlinks at all)
[15:26] <cjwatson> Given that grub-mount is used by ubiquity and os-prober in various places, I can easily imagine this causing confusion about what's mounted
[15:26] <cjwatson> Particularly in the presence of mounts on subdirectories
[15:26] <cjwatson> I may be wrong, it's just a theory at this point
[15:28] <slangasek> cjwatson: aha, ok
[15:28] <cjwatson> slangasek: Do you agree with my continued assessment that this is RC?
[15:29] <slangasek> cjwatson: yes
[15:29] <cjwatson> It doesn't affect all cases of detecting Windows, but I strongly suspect quite a few, and is likely to have all kinds of weird side-effects
[15:29] <cjwatson> om26er: ... sorry, I'm going to have to postpone my piloting shift
[15:29] <cjwatson> Not that I was on time anyway
[15:31] <om26er> cjwatson, no problem, i'll catch Clint ;-)
[15:31] <seb128> om26er, you should start by subscribing ubuntu-sponsors so it shows up on http://reports.qa.ubuntu.com/reports/sponsoring/
[15:34] <om26er> seb128, now subscribed ubuntu-sponsors to both bugs
[15:52] <stokachu> slangasek: hey im getting a lot of pressure for having bug 1013211 and bug 1036834 uploaded and pushed into precise, is there anything we can do to get this going?
[15:52] <ubottu> Launchpad bug 1013211 in libgnomecanvas (Ubuntu Precise) "[FFe] Please transition libgnomecanvas to multi-arch" [High,In progress] https://launchpad.net/bugs/1013211
[15:52] <ubottu> Launchpad bug 1036834 in gdb (Ubuntu Precise) "[FFe] gdb should be marked "Multi-arch: allowed"" [High,In progress] https://launchpad.net/bugs/1036834
[15:53] <stokachu> both are in quantal but theres been no movement on precise
[15:53] <slangasek> doko: ^^ were you looking at sponsoring 1013211?
[15:54] <ScottK> IIRC there was some push back on gdb.
[15:54] <stokachu> the gdb one has conflicting comments
[15:54] <doko> slangasek, is this for q? I'm not sru release. I think I did upload it
[15:54] <slangasek> stokachu: the gdb one is probably all me, though; I'm unlikely to get a chance to look at it before release
[15:54] <doko> gdb was rejected by bad pitti
[15:54] <stokachu> slangasek: ok, libgnomecanvas is the high prio one atm anyway
[15:54] <slangasek> stokachu: ah, oh
[15:55] <slangasek> stokachu, doko: right, I see libgnomecanvas in the queue and today's my SRU day (once I'm through with 12.10-related fires), so I'll get that moving
[15:55] <doko> stokachu, libgnome for p is alreay done?
[15:55] <stokachu> doko: libgnome is done libgnomecanvas is not though
=== micahg_ is now known as micahg
[15:59] <doko> infinity, slangasek: sbsigntool promoted to main. Please fix the i386 configury properly, using the $host macros, not fiddling around with uname and then fixing it ...
[15:59] <doko> slangasek, where should sbsigntool be seeded?
[16:00] <slangasek> doko: i386 configury> bah, hadn't noticed that; could you please file a bug on the package to track it? I'm not likely to get to this before release
[16:00] <slangasek> doko: also, would you please stop promoting packages before they're seeded ;)
[16:01] <stokachu> doko: if possible could we get bug 1013211 pushed into precise-proposed today?
[16:01] <ubottu> Launchpad bug 1013211 in libgnomecanvas (Ubuntu Precise) "[FFe] Please transition libgnomecanvas to multi-arch" [High,In progress] https://launchpad.net/bugs/1013211
[16:01] <infinity> doko: Sorry, the i386 thing was just a hack to fix jk's worse hack, I meant to bring it up with him using a ruler.
[16:01] <stokachu> ive got clients ready to test and verify
[16:01] <doko> slangasek, why? as long as pitti has left, they're not demoted again ;p
[16:01] <slangasek> doko: they generate email spam to me!
[16:02] <slangasek> doko: and sometimes yes, I do demote things I see there
[16:02] <stokachu> err sorry
[16:02] <stokachu> missed that comment from slangasek
[16:02] <stokachu> slangasek: thanks for taking a look at that
[16:02] <slangasek> doko, cjwatson: how about supported-installer-common for sbsigntool seeding (for the time being)?
[16:03] <infinity> Seems as good as any.
[16:03] <infinity> Or supported-hardware-common
[16:06] <slangasek> doko, infinity: seeded, thanks
[16:06] <doko> hmm, the uefi packages are already in supported-installer-common
[16:06] <slangasek> yep
[16:06] <slangasek> not sure why arm bootloaders are in hardware, but x86 bootloaders are in installer. :-P
[16:06] <infinity> Just cause.
[16:06] <cjwatson> slangasek: Yep
[16:07] <infinity> Maybe someone was making the distinction between ARM bootloaders being, essentially, the BIOS (so, "hardwareish")?  I dunno.
[16:08] <infinity> Should I be suspicious that the one arch where remctl is FTBFS in Ubuntu happens to be the one arch that was hand-built and uploaded by the maintainer in Debian?
[16:20] <xnox> infinity: you can copy-package from debian archive into ubuntu archive using lp api right?! =)
[16:20]  * xnox hides
[16:20] <cjwatson> No, because LP doesn't import the binaries :-P
[16:20] <cjwatson> Just as well.
[16:20] <xnox> cjwatson: good! =)
=== Ursinha-afk is now known as Ursinha
[16:21] <doko> infinity, builds fine on i386 in wheezy
[16:22] <cjwatson> infinity: Can you make anything out of the rakudo build failure?  It keeps failing in different places, from what I can tell, and it built fine on scheat.
=== stan_ is now known as stan
[16:27] <infinity> cjwatson: Means nothing to me, at a glance.  But if it's failing in different spots, obviously the solution is to give it back once an hour until release.
[16:28] <infinity> cjwatson: Oh, and smb4k fixed and testbuilding here.
[16:28] <infinity> (Well, potentially fixed, testbuil will tell me for sure)
[16:28] <cjwatson> infinity: excellent, I have your blessing then ;-)
[16:29] <cjwatson> smb4k> great.  We're getting close
[16:34] <ev> mpt: the deployment is blocked on me sorting out setting the browser history when the user changes the table
[16:34] <ev> right now it's getting stuck in a loop once you get back to the first query
[16:38] <cjwatson> infinity: I've got an armel build failure trying to link to __aeabi_i2d; is that a "wrong floating-point mode" error?
[16:40] <infinity> cjwatson: Missing -lgcc?
[16:41] <cjwatson> Oh, hmm, this is trying to link with ld
[16:41] <infinity> cjwatson: Except, that should be implicit on ARM, I thought...
[16:41] <cjwatson> I wonder if it's safer to switch to gcc generically or to add -lgcc
[16:41] <infinity> cjwatson: Oh, not so implicit if not linking with gcc.
[16:42] <TheLordOfTime> what's the package that contains most of the dev tools for ubuntu, such as gcc compiler libraries and the likes?
[16:42] <sarnold> TheLordOfTime: build-essential
[16:42] <infinity> cjwatson: Adding -lgcc means arch-guarding it, or having an unnecessary dep on other arches.  Using gcc should just DTRT, unless it's a package that's doing something very clever for very good reasons.
[16:43] <cjwatson> It's Java-related; it's more likely to be doing something stupid for bad reasons.
[16:43] <infinity> Hah.
[16:43] <cjwatson> (And actually this is a Debian-specific patch to boot.
[16:43] <cjwatson> )
[17:13] <cjwatson> doko: Does http://paste.ubuntu.com/1275250/ ring a bell, on armel?  That's java3d after I fixed it to link with gcc rather than ld.  I'm wondering if there's a java-config script it needs to be using or something ... full build log in my homedir on scheat
[17:21] <infinity> cjwatson: Looks more like a link order as-needed issue.
[17:22] <cjwatson> Possibly -ljvm before -ljawt I guess
[17:24] <infinity> cjwatson: Well, and -o foo in the wrong part of the link line.
[17:25] <cjwatson> Since when did the position of -o foo matter at all?
[17:25] <cjwatson> Position of input objects, sure, but they're all at the start here.
[17:29] <infinity> cjwatson: Oh, indeed.  I could also just be half asleep.
[17:29] <ogra_> youre such a pessimist
[17:30] <ogra_> could have said half awake :)
[17:32] <cjwatson> Switching -ljvm and -ljawt makes no difference.
[17:32] <cjwatson> And I doubt moving them any earlier would help.
[17:33] <silverarrow> hi
[17:34] <silverarrow> I am looking for more extensive info on how to troubleshoot audio driver issues
[17:34] <silverarrow> there something with the new kernel and snd-aoa drivers for powerpc I cannot figure out
[17:35] <silverarrow> they usual fixes described on FAQ  pages does not work
[17:37] <infinity> cjwatson: Hrm, well, maybe there was a reason they were using ld raw...
[17:37] <silverarrow> I don`t get any response on the forum either
=== TheLordOfTime is now known as TLoT
=== deryck is now known as deryck[lunch]
=== glebihan_ is now known as glebihan
=== mcclurmc is now known as mcclurmc_away
[18:05] <doko> cjwatson, will have a look tomorrow. afk
[18:22] <slangasek> jamespage: hey, do I understand correctly that bug #1053770 is being addressed by changing the "minimum requirements" documentation rather than shrinking the install?
[18:22] <ubottu> Launchpad bug 1053770 in ubuntu-docs (Ubuntu Quantal) "ubuntu-server install takes up too much space" [High,In progress] https://launchpad.net/bugs/1053770
[18:23] <jamespage> slangasek, yes
=== blackz_ is now known as blackz
[18:23] <slangasek> jamespage: ok, cheers - should we mark it 'wontfix' for ubuntu-meta/
[18:24] <jamespage> slangasek, done
[18:45] <jdstrand> mdeslaur, jjohansen, sarnold: I was just looking at bug #1058356
[18:45] <ubottu> Launchpad bug 1058356 in cups (Ubuntu) "fails to install when kernel does not provide block_suspend capability" [Undecided,Confirmed] https://launchpad.net/bugs/1058356
[18:45] <jdstrand> so, as the summary says, precise kernels don't have block_suspend, but quantal does
[18:46] <jdstrand> the quantal cups profile has a rule that uses block_suspend
[18:46] <mdeslaur> we're trying to run quantal userspace on a precise kernel?
[18:47] <jjohansen> oh fun
[18:47] <jjohansen> mdeslaur: more like quantal policy
[18:47] <mdeslaur> -ENOTSUPPORTED
[18:47] <jdstrand> and while dh-apparmor is smart enough to use 'apparmor_parser ... | true', /lib/init/apparmor-profile-load does not use '|| true', so when people upgrade from precise to quantal, cups is restarted, but that fails, so the job fails, and then the bug bites
[18:47] <mdeslaur> oh, hrm
[18:47] <slangasek> at minimum, this would be an issue on upgrade
[18:48] <slangasek> right
[18:48] <jdstrand> so the 12th our fix is to add || true to /lib/init/apparmor-profile-load
[18:48] <mdeslaur> jdstrand: I'm ok with that
[18:48] <jdstrand> slangasek: these days, upstart will log the error output, correct?
[18:49] <slangasek> jdstrand: stdout and stderr from any upstart job will by default wind up in /var/log/upstart, yes
[18:49] <jdstrand> ok, then I think || true is ok myself
[18:49] <jjohansen> jdstrand: well we should really fix it so that the parser can handle this
[18:49] <jjohansen> not saying that || true isn't the solution for today
[18:49] <jdstrand> yeah
[18:50] <jdstrand> agreed on both counts
[18:50] <sarnold> jjohansen: how does the parser/kernel interface report "unsupported capability"?
[18:50] <jdstrand> ok, let me bring this up in #ubuntu-release. I'll probably open a new bug for apparmor_parser
[18:50] <jjohansen> jdstrand: it is
[18:52] <jjohansen> sarnold: when the parser is built it auto extracts the list of capabilities known from the includes, the apparmor kernel module exports the mask of capabilities it supports :/
[18:52] <sarnold> jjohansen: by name or by number?
[18:52] <sarnold> (the exports-the-mask...)
=== deryck[lunch] is now known as deryck
[18:52] <jjohansen> sarnold: number, I had thought kees had made that a names list
[18:52] <sarnold> one hopes they're one-and-the-same, but ...
[18:53] <jjohansen> sarnold: well hrmm you would hope but I am not sure that is guaranteed for all architectures.  I know its not for rlimits
[18:54] <sarnold> the downside is, even if it does printk()/audit() 'unsupported capability in profile', the profile itself may still deny e.g. cap_sys_admin, if that was the capability required on earlier systems.
[18:54] <sarnold> jjohansen: oooh, ouch.
[18:54] <jjohansen> sarnold: so ideally we would patch the kernel to have a names mask as well but can always fall back to the current numeric mask
[18:55] <jjohansen> sarnold: I don't follow
[18:56] <sarnold> jjohansen: is block_suspend a brand-new interface that didn't exist in older kernels? or was it split out of cap_sys_admin?
[18:57] <jjohansen> sarnold: ah, got it. We need a mapping for things like that :/
[18:58] <sarnold> jjohansen: that's almost related to cbolt'z profile versioning -- except kernel versioning.
[18:59] <jjohansen> sarnold: yeah a similar but different problem
=== mcclurmc_away is now known as mcclurmc
[19:36] <slangasek> jdstrand, jjohansen: so I'm questioning the analysis on bug #1058356 now
[19:36] <ubottu> Launchpad bug 1058356 in upstart (Ubuntu Quantal) "fails to install when kernel does not provide block_suspend capability" [High,Fix committed] https://launchpad.net/bugs/1058356
[19:37] <slangasek> I don't think this is a precise->quantal upgrade issue at all
[19:37] <slangasek> it's not reproducible at all in the Ubuntu QA jenkins runs
[19:37] <jdstrand> slangasek: it was reported via a QA jenkins run
[19:38] <slangasek> jdstrand: for indicator-session CI, *not* the daily upgrade testing runs that we do
[19:38] <jdstrand> tedg_ reported it
[19:38] <slangasek> tedg_ is not Ubuntu QA :)
[19:38] <slangasek> the desktop upgrade tests do *not* show this failure
[19:38] <jdstrand> sure, but I am testing it now regardless
[19:38] <jdstrand> (ie, the test case for the sru)
[19:38] <jdstrand> so give me a few minutes
[19:41] <smoser> slangasek, are you planning on bringing 643286 back to precise?
[19:42] <slangasek> smoser: ENOSUCHBUG?
[19:43] <smoser> gar
[19:43] <smoser> bug 643289
[19:43] <ubottu> Launchpad bug 643289 in nfs-utils (Ubuntu Precise) "idmapd does not starts to work after system reboot" [High,Triaged] https://launchpad.net/bugs/643289
[19:43] <smoser> better.
[19:44] <slangasek> smoser: that's the idea, yes; but I was waiting for you to tell me if the latest mountall in quantal holds together :)
[19:45] <smoser> well.
[19:45] <smoser> $ df -h /
[19:45] <smoser> Filesystem      Size  Used Avail Use% Mounted on
[19:45] <smoser> /dev/vda1       9.9G  1.1G  8.5G  11% /
[19:45] <smoser> which is nicer than '-'
[19:46] <slangasek> smoser: well I know I fixed that particular bug... more looking for stress-test feedback
[19:46] <slangasek> since you seem to exercise mountall in ways we have not previously conceived ;)
[19:47] <claw_> hey guys i am missing pxechain.com in syslinux in 12.04 LTS
[19:47] <smoser> well our quantal "ephemeral" images sem functional at the moment
[19:48] <xnox> claw_: i saw your bug. but everyone is busy making quantal release right now. I have a mental note to look at it. but can't promise anything.
[19:48] <smoser> and the only issue that i'd seen in 2.41 was the  mtab issue.
[19:50] <slangasek> smoser: ok
[19:50] <claw_> xnox, that would be great thank you very much
[19:50] <slangasek> smoser: flagged in my brain to follow through on that SRU then, thanks
[19:50] <jdstrand> slangasek: ok, I can confirm that the simple test case of copying the quantal cups profile into place on precise causes the restart to fail. now I will attempt a precise to quantal upgrade
[19:50] <slangasek> jdstrand: ok, curious
[19:50] <smoser> slangasek, thanks. the only real raeson i'm asking is tha tmy fix for bug 1031065 depends on that.
[19:50] <ubottu> Launchpad bug 1031065 in cloud-init (Ubuntu Precise) "cloud-init-nonet runs 'start networking' explicitly" [Medium,Triaged] https://launchpad.net/bugs/1031065
[19:51] <slangasek> smoser: yeah, I know
[19:51] <claw_> xnox, but i did not open a bug request... it was an mail to the devs mailing list which was not accepted yet i guess
[19:51] <cjwatson> the pxechain problem in 12.04 is Debian #663302
[19:51] <ubottu> Debian bug 663302 in syslinux "include extra modules" [Normal,Fixed] http://bugs.debian.org/663302
[19:51] <cjwatson> So that should be reasonably easy to SRU since it's fixed in quantal
[19:51] <cjwatson> (not that I have time right now)
[19:51] <xnox> claw_: hmm... maybe I saw the email. if there is no bug report. open one please. using `ubuntu-bug syslinux`
[19:51] <xnox> claw_: otherwise it will be lost.
[19:52] <xnox> claw_: sorry, ignore me. see cjwatson's comment.
[19:52] <cjwatson> no, you were right the first time, it's a good idea to file a bug anyway
[19:52]  * xnox will use improt-debian-bug ;-)
[19:52] <cjwatson> in particular if you file it that means you'll be notified when there's a package in precise-proposed available for testing
[19:52] <ScottK> So claw_ should still see cjwatson's comment.
[19:53] <cjwatson> xnox: Better for somebody who cares directly to file it, and then they'll get told about testing
[19:54] <xnox> claw_: after all the chit-chat, please file a bug referencing the debian bug linked above.
[19:54] <xnox> =)
[19:57] <kees> jjohansen: I thought it was a bitmask, but rlimit was a name list?
[19:57] <kees> $ cat /sys/kernel/security/apparmor/features/capability
[19:57] <kees> 0xffffff
[19:57] <kees> $ cat /sys/kernel/security/apparmor/features/rlimit/mask
[19:57] <kees> cpu fsize data stack core rss nproc nofile memlock as locks sigpending msgqueue nice rtprio rttime
[19:57] <jjohansen> kees: yep
[19:57] <jjohansen> kees: for some reason I was thinking we did the name list with caps too
[19:58] <jjohansen> kees: I will probably add a new file with the names
[19:58] <kees> jjohansen: yeah, I thought I did too. There was some reason it wasn't that way, but it eludes me now.
[19:58] <kees> cool
[20:00] <claw_> the problem was fixed by debian on 8th May or earlier
[20:00] <cjwatson> Right, which is why it's fixed in 12.10
[20:01] <claw_> its a server system i want to have some LTS
[20:01] <cjwatson> Certainly - please file a bug about it and we'll get it backported
[20:01] <claw_> i will thanks
=== cpg|away is now known as cpg
[20:22] <xnox> Ooohhh we have SHA-3 the Keccak hash =)
[20:23]  * xnox best name ever
[20:25] <micahg> better than Pebcak hash :)
[20:41] <jdstrand> slangasek: so, like I said, I can readily reproduce with the new apparmor profile and the old upstart. it is curious as a do-release-upgrade worked fine, so I am back to being confused as to how people are actually hitting this in the real world. that said, I think it is still worthy of an SRU since this is like the 3rd time I've seen this bug
[20:41] <jdstrand> slangasek: but I have downgraded the priority
[20:42] <jdstrand> it's a trivial SRU, we recognize the deficiency in apparmor_parser and this should help whatever corner cases that people are hitting
[20:43] <slangasek> jdstrand: ack.  Strange for it to not reproduce in the upgrade
[20:44] <jdstrand> yeah. it has been a head-scratcher since people say they see it on upgrade, but yet I don't see it
=== hggdh is now known as hggdh_napping
[20:44] <jdstrand> I thought it might have something to do with the fact that the postinst has 'start cups'
[20:44] <jdstrand> (as opposed to restart)
[20:44] <jdstrand> and maybe upstart was being smat
[20:45] <jdstrand> smart
[20:45] <jdstrand> and if it was running, not running the apparmor bit
[20:45] <slangasek> postinst has 'start cups' because prerm has 'stop cups'
[20:45] <jdstrand> which would mean people would have to have cups stopped. but even then, the postinst as || true after start
[20:45] <slangasek> so cups should never be running at that point
[20:45] <jdstrand> ok, well, still. there is an || true
[20:47] <jdstrand> so, yeah, I don't know what corner case this is, but we can recognize the class of bug due to apparmor_parser and avoid the problem going forward
[20:47] <slangasek> right, as long as you're happy that the apparmor_parser change is per se correct
[20:47] <slangasek> and not simply a workaround for a bug
[20:47] <jdstrand> I believe it is correct for the current state of apparmor_parser
[20:48] <slangasek> if it's a workaround with negative side effects, it might be worth figuring out exactly what bug it's really working around
[20:48] <jdstrand> we would like to fix that, and when we do, we will remove this from upstart
[20:48] <jdstrand> oh, I might add that cups does not go unconfined
[20:48] <slangasek> right - the previous apparmor profile still applies, as expected?
[20:48] <jdstrand> it isn't removed
[20:49]  * slangasek nods
=== yofel_ is now known as yofel
=== hggdh_napping is now known as hggdh
=== Ursinha_ is now known as Ursinha
=== rsalveti_ is now known as rsalveti
[23:54]  * xnox hopefully now migrated to znc proxy.