[04:17] <pitti> Good morning
[04:18] <ScottK> Good morning.
[05:40] <dupondje> xnox: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/903422
[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: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
[07:30] <dholbach> good morning
[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
[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: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
[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.
[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 :(
[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.
[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: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: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
[14:07] <mpt> Keep gvfs away from my backend, thanks very much
[14:20] <xnox> mpt: =))))))))
[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] <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.
[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] <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: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
[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] <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! =)
[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.
[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
[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:23] <jamespage> slangasek, yes
[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] <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...)
[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
[19:36] <slangasek> jdstrand, jjohansen: so I'm questioning the analysis on bug #1058356 now
[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] <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: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] <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
[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
[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
[23:54]  * xnox hopefully now migrated to znc proxy.


[13:09] <jcsackett> morning, all.
[13:09] <rick_h_> party
[13:11] <rick_h_> jujugui please update the kanban board with what got done (even if not on the board) and where things are at today
[13:26] <jcsackett> how many of us are actually working today?
[13:31] <rick_h_> jcsackett: well the only request for swap day I got was from frankban
[13:31] <rick_h_> jcsackett: so I have no idea
[13:36] <jcsackett> rick_h_: dig.
[14:21] <kadams54> rick_h_: for this new search header view that I'm working on, should I keep it in the subapp/browser space?
[14:21] <rick_h_> kadams54: yes
[14:21] <kadams54> Or do we want that to go away?
[14:22] <kadams54> kk
[14:24] <rick_h_> jujugui (repeat for the folks joined recently) please update the kanban board with what got done (even if not on the board) and where things are at today
[14:30] <rick_h_> ccccccbtujivddegtrcuebbulfrhrjkfngkbjireglbe
[14:30] <redir> cat
[14:30] <hatch> dog
[14:31]  * hatch is sick
[14:31] <rick_h_> doh
[14:31] <hatch> stupid sick people traveling
[14:31] <rick_h_> double doh
[14:31] <rick_h_> redir: did you get the leankit email?
[14:32] <rick_h_> redir: looks like you did. You should have full access to the board now https://canonical.leankit.com/Boards/View/102529849
[14:32] <redir> rick_h_: yup. but no permissions on the boards yet
[14:32] <rick_h_> redir: let me know if you want to hangout pre call to get a run down of the board
[14:33] <redir> OK. Just tried creating a card but didn't have permissions.
[14:33] <rick_h_> yea, just updated it
[14:33] <rick_h_> you should be full user now
[14:34] <redir> k
[14:39] <redir> card created
[14:39] <redir> rick_h_: can I get a rundown of the board tomorrow morning?
[14:39] <rick_h_> redir: sure thing
[14:39] <rick_h_> redir: it uses gravatar for the head pics on the cards
[14:41] <redir> OK. I'll find a good headshot
[14:42] <hatch> rick_h_ kadams54 after the standup can you guys explain to me the email re the sidebar changes? I don't really see where the proposed changes are any different than what we have been doing
[14:42] <rick_h_> hatch: k, will do
[14:56] <jcsackett> juju-gui: call in 4 minutes, i suppose.
[14:56] <jcsackett> (hope i'm not stepping on toes there, but hadn't seen a warning)
[14:56] <rick_h_> oh yea, jujugui call in 4 :)
[14:56] <rick_h_> no -
[14:57]  * rick_h_ is heads down atm and missed it and makyo normally catches it
[14:57] <rick_h_> speaking of which
[14:58] <Makyo> Sorry, late morning.
[14:59] <rick_h_> hah it's all good. I think all of us are moving a bit slow today
[14:59] <rick_h_> I'm still recovering form that 2.5mi hike to the sharks on friday
[14:59] <rick_h_>  /form/from
[14:59] <hatch> haha
[15:00] <jcsackett> jujugui: going to be a moment late, i've misplaced my earphones when unpacking.
[15:01] <rick_h_> redir: joining or are you on the train?
[15:01] <rick_h_> https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
[15:25] <rick_h_> jcsackett: I don't see you at all
[15:25] <jcsackett> rick_h_: you don't see me at all, like in canonicaladmin? b/c i can verify curtis is getting my expenses.
[15:26] <rick_h_> jcsackett: right, you're not listed on my team in canonical admin
[15:26] <jcsackett> rick_h_: right...so do i need to complain to P&C, or do you?
[15:27] <rick_h_> jcsackett: writing the email now. don't worry about it
[15:27] <jcsackett> rick_h_: cool, thanks.
[15:27] <hatch> P&C sounds like a big corporate conglomerate
[15:29] <rick_h_> Makyo: on your branch, jcsackett I think did some initial ideas towards that. The idea being that we whitelist good states and if it's not a good state we fallback to a default
[15:31] <Makyo> rick_h_, oh, okay.  I was going to see if a state was possible, then fall back, but that may be overthinking it.
[15:31] <jcsackett> rick_h_: we don't actuallly have any work towards that idea--we had a verification step i took out of my current branch b/c it only checked for files in flash for local insepctor.
[15:31] <rick_h_> Makyo: yea, I guess the general idea is I think it'd be better to try to whitelist and control things (e.g. in sandbox a inspector/mysql view isn't valid)
[15:32] <rick_h_> jcsackett: ok, well just saying we've had conversations so there's some background
[15:32] <jcsackett> rick_h_: dig. just didn't want there to be any false hope of work already done. :)
[15:32] <rick_h_> lol
[15:33] <Makyo> Sounds good, I'll head in that direction.
[15:40] <hatch> is this the part where we need to check if the inspector urls are valid, if they aren't then show the charmbrowser/
[15:40] <rick_h_> hatch: yes, that's the idea.
[15:41] <hatch> oh, and having a section validator pre dispatching is not going to work?
[15:41] <rick_h_> I think that's kind of the idea. To whitelist first before trying to do a bunch of stuff and then failing
[15:43] <hatch> ahh - I was thinking that because each section had such different requirements that it would validate each section individually
[15:43] <rick_h_> yea, but then it's hard to maintain and find out why something failed imo
[15:43] <rick_h_> I'd be curious if people are willing to trade off maintaining a white list up front that's clear/easy to read vs debugging it at the failure point
[15:45] <hatch> so you're thinking: URL parse to state > validate parsed state > dispatch ?
[15:45] <rick_h_> hatch: yep
[15:45] <rick_h_> hatch: at least it's the discussion I'd like to have :)
[15:46] <hatch> I think that will be considerably more work because you'd have to have these complex methods for parsing the state out instead of splitting it up into the sections.
[15:46] <hatch> and then dealing with them 1:1
[15:48] <rick_h_> hatch: right but there's a point where state is parsed before dispatch right?
[15:48] <rick_h_> so a single call through some validation bits to say "oh, a charmbrowser state with metadata XX is invalid in this case"
[15:48] <hatch> no it goes from the url into state, then the state is only parsed in the dispatchers
[15:48] <hatch> it's "dumb" until the dispatchers
[15:48] <rick_h_> ah well then sucky. Maybe we can at least force a common api?
[15:49] <rick_h_> all dispatchers have a single parse/validate the state bit?
[15:49] <rick_h_> I just worry that it's like we have now with browser.js. When something fails to draw correctly, you have to debug through 6 methods to figure out why
[15:49] <hatch> it'll need to be validated pre-dispatch because we'll need to change the url to the 'default' for that section then re-dispatch
[15:49] <rick_h_> it's too spread out how you get from url to called views
[15:50] <rick_h_> hatch: right
[15:50] <jcsackett> rick_h_: that does start to sound like the work hatch and i considered, we have a validate method that calls validateSectionXXX, and that chain starts before dispatching starts.
[15:50] <rick_h_> jcsackett: k, yea I had hoped to make it state's job
[15:50] <rick_h_> but sounds like it's not possible
[15:50] <rick_h_> because at the state time, it could be changed quickly and easily
[15:50] <hatch> well this wuld be in state
[15:50] <jcsackett> rick_h_: not sure what you mean--validate/dispatch is in state.
[15:51] <rick_h_> then the state is only parsed in the dispatcher
[15:51] <rick_h_> is the quote hatch said
[15:51] <hatch> the url is parsed into sections, which make up the state, then the dispatcher runs through those sections and calls the handlers
[15:52] <hatch> the validation needs to happen pre dispaching
[15:52] <rick_h_> ok, sounds perfect then
[15:52] <jcsackett> "the dispatcher" here being a dispatch method.
[15:52] <hatch> yes
[15:52] <hatch> jcsackett so sounds like the original plan is still the right direction.....agree?
[15:52] <jcsackett> hatch: sounds very similar, yeah.
[15:52] <hatch> col
[15:52] <rick_h_> I just want to make sure that the error "inspector/mysql is not valid for sandbox mode" is done somewhere high up and obvious vs in the View which then triggers a new change event
[15:52] <hatch> cool
[15:53] <hatch> rick_h_ yes in the state module for sure
[15:53] <rick_h_> hatch: cool, then /me gets out of the way and carries on :)
[15:53] <jcsackett> Makyo: if you're working on this (and have been following along) https://github.com/jaycee/juju-gui/tree/add-flash-memory-to-state has some work you can crib, re the _validateSection logic.
[15:54] <Makyo> ccccccdiltnnfvenndnvnrcddkedfhlebjlnvernfcge
[15:54] <hatch> rick_h_ it would help in planning for the demo if we had a basic script outline of the UI actions mark will be running
[15:55] <Makyo> By which I mean thanks, jcsackett
[15:55] <rick_h_> hatch: yes
[15:55] <hatch> Makyo lol
[15:55] <jcsackett> Makyo: i figured that's what you meant. :)
[15:55] <rick_h_> hatch: I'll try to write out something and maybe even see if we can get UX to use their wireframes to mock out the journey for us
[15:55] <hatch> that would be awesome
[15:56] <rick_h_> hatch: will do, added a card for me to do that today.
[15:56]  * rick_h_ is going to go afk to go yell at the car dealer
[15:56] <jcsackett> Makyo: you can ignore the "flash" parts--you're just interested in the _validate stuff from view/state.js in that branch. i can land a follow up after yours to make sure the flash bits are validated using whatever you land.
[15:56] <jcsackett> it's not much, but it's code towards the long spiel rick_h_, hatch and i just had. :p
[15:56] <hatch> rick_h_ gl :)
[15:57] <jcsackett> hatch: i think i've addressed all your comments etc in my PR.
[15:57] <hatch> cool I'll take a look and QA
[15:57] <hatch> most were pretty trivial
[15:59] <hatch> jcsackett tests are failing fyi
[16:01] <jcsackett> hatch: well, test-server is blowing up--i can't reproduce anything locally. :/
[16:01] <hatch> jcsackett doh
[16:02] <hatch> jcsackett when rick_h_  returns we will need to get him to killall the process
[16:02] <hatch> it'll be broken until then
[16:02] <jcsackett> hatch: fun times. well, are you happy with the PR, tests aside?
[16:03] <hatch> very likely, just going through still
[16:04] <hatch> jcsackett somewhat related - do we ever want to explicitly clear out the `flash` ATTR as well as the state one?
[16:04] <hatch> or do you think it's ok for the ATTR to hang around populated
[16:08] <jcsackett> hatch: i don't follow..."as well as the state one"
[16:08] <jcsackett> there's only a state ATTR.
[16:09] <jcsackett> or do you mean on metadata as well?
[16:09] <jcsackett> or am i just completely misreading you? :p
[16:11] <hatch> haha
[16:11] <hatch> ok so you reset the `flash` property on the state object
[16:12] <hatch> but there is also a `flash` ATTR on the state instance
[16:12] <hatch> which is only ever overwritten
[16:12] <hatch> never reset
[16:13] <hatch> jcsackett oh wait NM
[16:13] <hatch> ignore everything I Just said
[16:14] <hatch> I thought this https://github.com/juju/juju-gui/pull/271/files#diff-49f77193fff0d5a96b555595ed918791R126 was resetting the state object's property
[16:21] <hatch> jcsackett I created a few more comments for the tests. I'm QA'ing now
[16:28] <hatch> jcsackett you might want to hold off pushing the final version to the PR until CI is reset
[16:28] <hatch> else you'll have to trigger it all manually
[16:35] <hatch> http://store.steampowered.com/app/244830/ python IDE on steam?
[16:37] <Makyo> Oh, that's kinda neat!
[16:40] <redir> what is the bzr equiv of git pull upstream?
[16:43] <Makyo> jujugui ^^^
[16:43] <Makyo> (I don't remember, unfortunately)
[16:44] <hatch> hmm - I always just pulled to update that branch then merged in
[16:44] <hatch> sorry I'm no help either
[16:44] <hatch> redir btw - in your irc client add `jujugui` and `guihelp` as notification targets
[16:44] <Makyo> I mean, you can bzr merge lp:<project>/trunk, I think, but don't know if that's best practice
[16:44] <hatch> sorry for dinging everyone :)
[16:45] <hatch> Makyo yeah that's what I always did heh
[16:48] <redir> thanks
[16:53] <redir> Cory Booker is sitting across the aisle from me on the train...foranyone who follwos that kind of stuff
[16:54] <Makyo> Sometimes, I forget that I have the xkcd substitution extension running in Chrome...
[16:55] <redir> Makyo: there's probably an appropriate strip for that
[16:55] <Makyo> "Cory Anthony Booker (born April 27, 1969) is an American politician and the junior United States Elf-Lord from New Jersey. At the time of his eating contest to the Senate, he was the Mayor of Newark."
[16:55] <hatch> I also had to google him
[16:55] <redir> awesome
[16:55] <hatch> and rofl Makyo
[16:55] <hatch> haha
[16:56] <hatch> I didn't think anyone cared about politics until someone does something that's ok unless a politician does it
[16:56] <Makyo> https://chrome.google.com/webstore/detail/xkcd-substitutions/jkgogmboalmaijfgfhfepckdgjeopfhk
[17:03] <rick_h_> hatch: jcsackett looking at ci
[17:04] <hatch> thx
[17:04] <hatch> what was the result of the burningoilness ?
[17:04] <rick_h_> hatch: jcsackett process killed
[17:04] <rick_h_> hatch: just took it in, sitting here waiting now
[17:04] <rick_h_> hatch: I expressed my displeasure
[17:05] <hatch> ahhh - what kind of car?
[17:05] <rick_h_> hatch: outback
[17:05] <hatch> bugatti veyron ?
[17:05] <hatch> :P
[17:06] <hatch> ahh, does it only puff the smoke on startup?
[17:06] <rick_h_> no, it leaks in the drive (carboard with pattern brought in this time) and when I pulled in their garage it was smoking lovely
[17:06] <rick_h_> this time I think they believe me
[17:07] <hatch> ahh
[17:07] <hatch> good thing is that subies are easy to fix
[17:08] <hatch> I used to have an 01 WRX
[17:08] <hatch> with like 250,000km on it haha
[17:09] <rick_h_> yea, I'm bummed we're having this at 65k mi
[17:09] <rick_h_> my last one didn't have issues until closer to 100k mi
[17:10] <hatch> If it's leaking oil it might simply be that the smoke is because it's burning the oil on the outside, not from the valves or rings
[17:10] <hatch> hopefully
[17:11] <rick_h_> yep
[17:14] <hatch> http://varianto25.com/ <--- yes yes yes
[17:15] <redir> highlights set, thanks hatch
[17:15] <hatch> np
[17:45] <hatch> rick_h_ do we have any code atm which takes an unplaced-unit and makes it a placed-unit ?
[17:45] <hatch> ^ jujugui
[17:46] <rick_h_> hatch: the api calls are there to create machines and containers.
[17:46] <hatch> right, but it looks like everything just creates a new unit via add_unit
[17:46] <rick_h_> hatch: we need the UI events to turn one into the other (e.g. on button press/etc turn unit token to machine token)
[17:46] <rick_h_> hatch: so no, this is the glue stuff we need to start now that we can show tokens at all three levels
[17:47] <rick_h_> unplaced, machine, and container
[17:47] <hatch> hmm ok
[17:47] <rick_h_> we should have UI and such for all three now
[17:47] <hatch> right, we can create an unplaced unit....but I don't think we have any code in the back end to convert that to a placed unit
[17:47] <rick_h_> well placed means a machine or container
[17:48] <rick_h_> so the code is two fold, one to create a changeset to add machine or container
[17:48] <rick_h_> and two, to remove the unplaced unit token and create a new machine/container token
[17:48] <rick_h_> or am I missing your point on this slow minded monday of mine?
[17:48] <hatch> well a unit != machine/container token
[17:48] <rick_h_> it does once placed?
[17:49] <rick_h_> well, it'll either update a machine or container token
[17:49] <rick_h_> or become one
[17:49] <hatch> I think you're mixing UI state with env state
[17:49] <hatch> for example
[17:49] <hatch> say I create 10 unplaced units
[17:49] <rick_h_> hatch: right, but env state should be a ghost machine/container, ghost service, ghost unit
[17:50] <hatch> those units are now in the db without a 'machine' value
[17:50] <hatch> now once the user drags that unit to a machine/container
[17:50] <hatch> we need to update that model....or delete it and create a new one
[17:50] <hatch> I'm wondering if that code exists
[17:51] <rick_h_> no, that code does not exist
[17:52] <hatch> ok for this branch I'll just call the env's add_unit method on mass scale up, and we can deal with the rest later
[17:52] <rick_h_> hatch: ok
[17:52] <hatch> I'll fire an email to frankban as he will certainly have some input on the 'placement' implementation
[17:53] <rick_h_> yea, I want to sit down a group to go through the db talk we started in vegas
[17:53] <rick_h_> the whole tracking units through both machines/containers and services
[17:53] <hatch> yeah...can we do that....say wednesday hopefully I'll be better by then :)
[17:54] <rick_h_> yea, all good
[17:54] <rick_h_> I think that fits into your question a bit though
[17:54] <rick_h_> because placing a unit it sticking it in the right part of the db referenced by the other super objects
[17:55] <hatch> yeah atm we need to create a unit on the service, then pre-sending the 'real' add-unit call, we need to have the 'machine' property updated
[17:55] <rick_h_> right
[17:59] <rick_h_> rogpeppe: you around today or swap day-ing it?
[17:59] <jcsackett> rick_h_: i see a card about browser.js needing to instantiate inspector views--i think we're already doing that now?
[18:00] <jcsackett> rick_h_: see various create*InspectorView functions.
[18:00] <rick_h_> jcsackett: yes
[18:00] <rick_h_> jcsackett: I didn't move it as the work is in progress like the local ones
[18:00] <jcsackett> ah, so i can move it along with my local card?
[18:00] <rick_h_> jcsackett: sure thing, sounds ok to me
[18:00] <jcsackett> since i think that's the only WIP regarding that.
[18:00] <jcsackett> ok.
[18:01] <jcsackett> hatch: that sound right? all inspectors now being done in browser? ^
[18:01] <hatch> reading back...
[18:01] <hatch> correct
[18:01] <jcsackett> awesome.
[18:01] <hatch> after your card they are all moved
[18:06] <rogpeppe> rick_h_: today is a public holiday
[18:06] <rick_h_> rogpeppe: ah, cool then
[18:06] <rogpeppe> rick_h_: tomorrow i'm swap daying it
[18:06] <rogpeppe> rick_h_: then i'm on holiday :-)
[18:07] <rick_h_> oh right cool
[18:07] <rogpeppe> rick_h_: will be back on 22nd May
[18:08] <rick_h_> rogpeppe: cool thanks. I'll look forward to getting started then. I'm working on getting out notes and such from the sprint loaded up into docs and things
[18:08] <rogpeppe> rick_h_: great, that will be useful
[18:09] <rogpeppe> rick_h_: really looking forward to getting going on all of this stuff.
[18:10] <rick_h_> rogpeppe: same here :) I'll add you to the internal list for our stuff and send some notes there
[18:11]  * rogpeppe goes back to his mojito
[18:12] <rick_h_> enjoy!
[18:14] <hatch> rick_h_ I've finished my shutdown holidays and expenses
[18:15] <rick_h_> hatch: k, got the holidays in. Will go through expenses.
[18:17] <hatch> cool
[18:18] <rick_h_> jcsackett: if you get yours into landing can you peek at huw's pull request and QA please?
[18:18] <hatch> is May 19th a holiday in the US? National Patriots Day?
[18:18] <hatch> rick_h_ jcsackett  I already did, he needs some slight refactoring first
[18:18] <rick_h_> hatch: ah ok thanks
[18:18] <hatch> when he gets in tonight I'll guide him through the implementation
[18:18] <rick_h_> hatch: no, there's memorial day the 26th
[18:18] <rick_h_> for the US
[18:19] <hatch> ahh one week later
[18:19] <rick_h_> hatch: rgr
[18:19] <hatch> jcsackett lint error failure in your branch
[18:19] <hatch> :)
[18:19] <rick_h_> hatch: he might not be around tonight
[18:19] <rick_h_> travel and all that
[18:19] <hatch> ohh ok, np, well when he does
[18:25] <hatch> I'm going to take lunch
[18:26] <rick_h_> hatch: have fun
[18:27] <rick_h_> bah, car seal goes boom!
[18:33]  * rick_h_ gets ready to get driven home from car dealer. back online later on
[19:17]  * rick_h_ is back
[19:19] <hatch> rick_h_ which seal
[19:19] <hatch> ?
[19:19] <rick_h_> some front engine seal
[19:19] <rick_h_> looks like it was coming down into the oil pan
[19:20] <hatch> ahh yeah - that one might be pricy to fix
[19:20] <rick_h_> showed me the leak but don't know enough about cards to name the bits
[19:20] <rick_h_> yea, $1k
[19:20] <rick_h_> new timing belt along for the ride wheee
[19:20] <hatch> yeah sounds about right
[19:20] <hatch> :/ cars
[19:21] <rick_h_> hey, I wanted to pay it off before major work, mission accomplished
[19:21] <rick_h_> $1k is like 2 car payments so if it goes a year after this we're all good :)
[19:22] <hatch> haha yeah - that's where I'm at too, cars paid off....hard to justify the payments for the amount of k's I drive
[19:22] <Makyo> Excellent use of canvas: http://www.georgeandjonathan.com/
[19:22] <rick_h_> yea, that was cool
[19:24] <hatch> heh vwry cool
[19:26] <jcsackett> rick_h_: can you kick CI again? it's still doing the server death thing.
[19:27] <hatch> jcsackett was there a hanging run?
[19:27] <rick_h_> jcsackett: well, it's a different error
[19:28] <hatch> that you killed manually
[19:28] <rick_h_> jcsackett: I'm looking now
[19:28] <rick_h_> ReferenceError: Can't find variable: YUI
[19:28] <rick_h_> and connect.multipart() will be removed in connect 3.0 connect.limit() will be removed in connect 3.0
[19:28] <hatch> Error: listen EADDRINUSE
[19:28] <hatch> it's the same....looks like it just got further before crashing
[19:28] <rick_h_> hatch: in the latest? #859?
[19:28] <hatch> http://ci.jujugui.org:8080/job/juju-gui/859/console
[19:28] <rick_h_> oh it is, wtf
[19:28] <hatch> yup
[19:29] <hatch> I don't see any manually killed runs, so I'm not sure how that got broken
[19:29] <hatch> maybe we should add a killall in the start of our script?
[19:29] <rick_h_> hatch: yea, there's supposed to be a catch
[19:29] <rick_h_> hatch: jcsackett ok, try again killed
[19:29] <rick_h_> I think I missed a process last itme I ssh'd my bad
[19:29] <rick_h_> there were two I needed to kill I think
[19:30] <rick_h_> only got the one
[19:30] <rick_h_> jcsackett: if it runs ok on your end just :shipit:
[19:31]  * rick_h_ makes a card in on deck to update to sauce connect 3.0
[19:55] <rick_h_> dimitern: hey, do you know what you were ordered for nuc/switch?
[19:55] <rick_h_> dimitern: I want to get a setup here as well and haven't heard back yet on what the standard is
[19:56] <dimitern> rick_h_, hey
[19:56] <dimitern> rick_h_, i'm yet to see dustin and take the nucs + switch
[19:57] <dimitern> rick_h_, i'll let you know when i have them
[19:57] <rick_h_> dimitern: ok cool. If you think about it, would love to see what models and such
[19:57] <rick_h_> dimitern: ty much
[19:57] <hatch> rick_h_ thinking for a home test box?
[19:57] <dimitern> rick_h_, not quite sure about the models as dustin had them ordered - for the nucs
[19:57] <rick_h_> hatch: yea, I want to setup a MAAS test env here at the house
[19:58] <rick_h_> hatch: and maybe see about how to share it out to the team for maas setup/testing as we need to make sure our bundles, quickstart, etc work well
[19:58] <hatch> coolio
[19:58] <dimitern> rick_h_, ... they are the ones supporting amt (more expensive), and the switch is some 8-port d-link with vlans support, but don't have the model
[19:58] <hatch> oh that would be sollllid
[19:58] <rick_h_> dimitern: yea, the switch I'm less worried about. I've got a dell that does vlans currently that's cool and not bad. It's more trying to find the right nuc model
[20:08] <rick_h_> robbiew: howdy, I notice your bug. Can you verify that 1.3.2 fixes it? We hit a Juju regression I believe and we've patched and are looking to get an update into trusty this week
[20:09] <robbiew> huh?
[20:09] <robbiew> rick_h_:
[20:09] <robbiew> what bug?
[20:09] <rick_h_> robbiew: http://jujugui.wordpress.com/2014/04/30/juju-quickstart-1-3-2-released/
[20:09] <rick_h_> robbiew: looking for the number
[20:10] <rick_h_> https://bugs.launchpad.net/juju-quickstart/+bug/1309455 robbiew
[20:10] <_mup_> Bug #1309455: The auto-generated local env does not work in trusty <juju-quickstart:Fix Released> <https://launchpad.net/bugs/1309455>
[20:10] <robbiew> ooohhhhh
[20:10] <rick_h_> robbiew: we just fixed quickstart during the sprint and just got back
[20:10] <rick_h_> we were going to ping soon to work on seeing about 1.3.2 into trusty as a bugfix update
[20:11] <rick_h_> frankban is out today as swap but should be back tomorrow. We fixed a couple of bugs
[20:11] <rick_h_> robbiew: unless 1.3.2 does not in fact fix your issue. In which case we need to look at the issue asap
[20:11] <robbiew> rick_h_: sorry...this isn't my bug
[20:12] <robbiew> oh...nevermind
[20:12] <robbiew> now I remember
[20:13] <rick_h_> robbiew: it's a mix of juju and quickstart bugs. We're working with QA team to get quickstart into the Juju CI runs
[20:13] <robbiew> sounds good
[20:14] <rick_h_> robbiew: https://bugs.launchpad.net/juju-quickstart/+bug/1306537 is the other one I think
[20:14] <_mup_> Bug #1306537: LXC local provider fails to provision precise instances from a trusty host <deploy> <local-provider> <lxc> <juju-core:Fix Released by wallyworld> <juju-core 1.18:In Progress by jameinel> <juju-quickstart:Fix Released by frankban> <https://launchpad.net/bugs/1306537>
[20:14] <robbiew> ack
[20:15] <rick_h_> robbiew: to be able to get an update to quickstart in trusty should I file a bug on the package? Is there a format to make sure I meet?
[20:17] <robbiew> I have no idea
[20:17] <robbiew> rick_h_: lol
[20:17] <rick_h_> robbiew: oh :) nvm then.
[20:17] <robbiew> rick_h_: just ask marco
[20:17] <rick_h_> lol wrong robbie my bad
[20:18] <robbiew> yeah...that's what I quickly figured
[20:18]  * rick_h_ remembers robie has one b
[20:18] <rick_h_> sorry about the confusion
[20:18] <rick_h_> so yea, use 1.3.2 for the moment and we'll work with rbasak to get trusty updated asap
[20:18] <robbiew> it's cool...I knew of the bug just because I had used juju from some demoes awhile back...but when you asked me how to file the bug...figured it out
[20:19] <rick_h_> I'll mark the bug as a dupe for now. If 1.3.2 doesn't fix it let me know as it's something else we're not aware of
[20:19] <robbiew> ack
[20:20] <hatch> jujugui who wrote the machine-token.js file?
[20:20] <hatch> originally that is
[20:20] <rick_h_> hatch: huw maybe
[20:20] <rick_h_> hatch: either huw or kadams, I can't recall atm
[20:21] <rick_h_> hatch: any reason you're hunting?
[20:21] <hatch> it's expecting a hardware object in the render cycle and it fails if that's not provided
[20:21] <hatch> I was wondering if that was intentional or if it's a bug
[20:22] <rick_h_> hatch: probably a bug in that it was written aroud current data
[20:22] <hatch> well, either way it's a bug, I'm just trying to figure out if it's the machine-token or the database
[20:22] <rick_h_> so it was probably just a way to get it working and viewable vs thorough
[20:22] <hatch> ok I'll put in a || for now
[20:22] <rick_h_> hatch: yea, I mean the tokens are just UI starts to build on, all of them
[20:22] <hatch> ok sounds good
[20:39] <rick_h_> woot, nuc, drives, and ram ordered with gigabit vlan switch
[20:40] <hatch> haha nice
[20:41]  * rick_h_ wonders if he can get a second IP from ATT Uverse
[20:43] <hatch> it'll probably be $100/mo
[20:43] <hatch> lol
[20:48] <rick_h_> doh, bit by CC thinking it's fraud
[20:49] <hatch> you're such a criminal
[20:49] <hatch> kehehe
[20:54] <hatch> yay jcsackett 's branch finally landed heh
[20:54] <hatch> poor CI
[21:01] <hatch> I'm going to go lie down for a bit, I'll finish up the day later
[21:22] <Makyo> I should get a few NUCs too.  Kind of weird to think about, since James just got a nuc (as in nucleus colony of bees) this weekend.
[21:30] <Makyo> rick_h_, what NUC did you get?
[21:44] <rick_h_> Makyo: http://www.newegg.com/Product/Product.aspx?Item=N82E16856102052
[21:44] <rick_h_> Makyo: right now working with ATT to get multiple IP addresses on my account
[21:45] <rick_h_> goal is to setup the 3 nuc and switch on their own network for folks to use
[21:45] <Makyo> Oh, rock on
[21:46] <rick_h_> so yea, will take a bit to get the bits in order but should help with bundle/quickstart/network testing in the future
[21:46] <rick_h_> as maas is the first network target especially
[21:48] <Makyo> Yeah, for sure
[22:05] <Makyo> Ducking out to get the dog to the vet.  She cut her paw on something.
[22:08] <rick_h_> ruh roh, good luck!
[23:08] <huwshimi> Morning
[23:14] <hatch> morning huw
[23:14] <hatch> I see you're still alive :)
[23:15] <hatch> I made a comment on your branch, let me know if you have any questions about it
[23:17] <huwshimi> hatch: Thanks! Makes sense :)
[23:17] <hatch> excellent


[08:35] <Atamira> reboot brb
[19:45] <technomensch> anyone in here?
[19:45] <technomensch> :::paying attention, that is::::
[19:46] <technomensch> in MediaWiki, there is a SpecialPages that lets you see "what links here" to a specific page.  Does this wiki have the same feature somewhere?
[19:50] <charlie-tca> I don't know if this is what you are looking for, but clicking the page title does a search for related pages
[19:51] <technomensch> that helps a little, thanks
[19:52] <charlie-tca> glad to help
[20:19] <technomensch> are you on the wikiteam, or a documentor?
[20:39] <technomensch> are there any members of the Wiki Team currently in the Chat room??
[20:39]  * cody-somerville raises his hand.
[21:07] <technomensch> hi cody


[07:54] <mborzecki> morning
[07:55] <mvo> good morning mborzecki
[07:55] <mborzecki> mvo: hey
[07:59] <mborzecki> mvo: can you land https://github.com/snapcore/snapd/pull/10067 ?
[07:59] <mup> PR #10067: overlord/snapstate: make sure that snapd current symlink is not removed during refresh <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10067>
[08:00] <mvo> mborzecki: sure
[08:01] <mvo> mborzecki: looking, I'm going over the list of open PRs right now, there are some more that were ready and just failed because of things like snap-advice failing
[08:02] <mup> PR # closed: snapd#10035, snapd#10070, snapd#10071, snapd#10072
[08:03] <mvo> mborzecki: thank you so much for this PR! merged
[08:03] <mvo> mborzecki: and cherry-picked
[08:06] <mborzecki> thanks!
[08:06] <pstolowski> morning
[08:06] <mvo> pstolowski: good morning!
[08:06] <mborzecki> pstolowski: hey
[08:07] <mup> PR snapd#10067 closed: overlord/snapstate: make sure that snapd current symlink is not removed during refresh <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10067>
[08:11] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/10054 ?
[08:11] <mup> PR #10054: overlord/snapstate, wrappers: add dependency on usr-lib-snapd.mount for services on core with snapd snap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10054>
[08:12] <mup> PR snapd#10064 closed: tests: simplify the reset.sh logic by removing not needed command <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10064>
[08:14] <mborzecki> mvo: pstolowski: i think we can land https://github.com/snapcore/snapd/pull/10062 too, the failures are unrelated afaict
[08:14] <mup> PR #10062: tests: validation sets spread test <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10062>
[08:15] <mvo> mborzecki: sure thing, thank you!
[08:17] <mup> PR snapd#10062 closed: tests: validation sets spread test <validation-sets :white_check_mark:> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10062>
[08:19] <pstolowski> mborzecki: will do
[08:19] <mborzecki> pstolowski: thanks!
[08:20] <zyga> good morning guys!
[08:20] <mvo> hey zyga
[08:20] <zyga> hey mvo, how are you doing?
[08:21] <mvo> zyga: good, thank you! how are you? it's getting sunny here again which is super nice
[08:21] <zyga> oh, I envy you the sun then :) Here's it's finally getting warmer, it looks like Saturday will be perfect for some time (alone) outside
[08:22] <zyga> but it's also bound to be raining so I guess it will be just me and the bike again
[08:22] <zyga> so much work lately that I rarely think about stuff like that
[08:22] <zyga> but it's the last stretch it seems
[08:25] <mvo> zyga: yeah, the alone part is the same here, it's a bit annoying
[08:26] <zyga> mvo: some of our parents got vaccinated already but there's a huge queue and we're not likely to get anything more this year
[08:26] <mvo> zyga: I'm somewhat hopeful for end-of-summer here but I'm also notouriously optimistic
[08:27] <zyga> we had to move our release for three weeks to pick up the documentation work and the website
[08:27] <zyga> but after that it looks like some normal time will happen
[08:28] <zyga> a week off
[08:28] <zyga> and regular feature work
[08:28] <zyga> I'm looking forward to having early EODs and warm weather for just doing stuff
[08:35] <pstolowski> hey zyga
[08:35] <zyga> hey :)
[08:36] <mvo> zyga: sounds great, total +1 on this
[08:37] <mup> PR snapd#10058 closed: cla-check: Use has-signed-canonical-cla GitHub Action <Skip spread> <Created by MarcusTomlinson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10058>
[08:51] <pedronis> mvo: that fix that you are non finding in Ian's PR, seems to have be done already in the prereq: https://github.com/snapcore/snapd/pull/10035/commits/73e4cb21bf7c7d0f54ba1205beb9ad866c017845
[08:51] <mup> PR #10035: o/devicestate: split off ensuring next boot goes to run mode into new task <Simple 😃> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10035>
[08:51] <pedronis> *been
[08:53] <pedronis> mborzecki: hi, related to the snapd fixes, are you also working on the snap-confine profile change?
[08:54] <mvo> pedronis: nice, thanks
[08:54] <mvo> pstolowski: looks like 10068 just needs one more small check if we can reuse the same test and then it can go in. nice job there!
[08:55] <pedronis> mvo: mborzecki: does the caching of spread test results still works as before? I have the impression all tests are re-run now, but maybe I'm just confused
[08:55] <pstolowski> mvo: looking
[08:55] <mborzecki> pedronis: noticed that too, but did not look into it yet
[08:57] <mup> PR snapd#10075 closed: interfaces/udisks2: allow locking /run/mount/utab for udisks 2.8.4 <Needs Samuele review> <Created by knitzsche> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10075>
[09:02] <zyga> ^ on that last merged PR: one of the files that udisks/libmount wanted to read, not sure if it's that one in /run, was tricky to share
[09:02] <zyga> because that interface (in the libmount sense) is not aware of mount namespaces, udisks would get very confused
[09:06] <mvo> pedronis, mborzecki if you have an example where you see this I can have a look after my meeting, it should be visible in the logs of the runs what stamp files were used
[09:06] <pstolowski> mvo: i preplied, not sure we want to change that without input from Sergio
[09:07] <pstolowski> *replied
[09:07] <mup> PR snapd#10048 closed: o/configstate: deal with no longer valid refresh.timer=managed <Bug> <Needs Samuele review> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10048>
[09:07] <mvo> pstolowski: thanks, let's make sure we can do a followup, it's not a blocker
[09:07] <pstolowski> mvo: ok
[09:10] <pstolowski> hmm but it looks the test failed on reboot, that's weird, i'm sure it passed when i run it manually
[09:11] <pstolowski> ah we need || ture, weird..
[09:16] <mvo> pstolowski: I see an error that it can't resolve "ubuntu" which is kind of expected given that we turned off resolving :) but of course annoying
[09:16] <mvo> pstolowski: I wonder if adding ubuntu to /etc/hosts is enough
[09:16] <pstolowski> mvo: yes i saw that (it's from sudo i think)
[09:16] <mvo> (but it could/should be there already)
[09:17] <mvo> pstolowski: yeah, sudo tries to be smart because it can have per-host configuration in sudoers.cfg
[09:25] <pstolowski> mvo: this is something we would do on core image I assume?
[09:26] <pstolowski> (rather than trying to modify config on writable etc)
[09:28] <mvo> pstolowski: it's a good question, I can check after my meeting
[10:02] <mup> PR snapd#10076 opened: tests: fix snap-advise-command check for 429 <Simple 😃> <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/10076>
[10:11] <mvo> pedronis: ^- this should make your (and other) PRs much more happy
[10:14] <mvo> pstolowski: ok if I merge 10068 as squash-merge?
[10:15] <pstolowski> mvo: yes; let's wait for nested though, i pushed a fix
[10:15] <mvo> pstolowski: thanks
[10:16] <mvo> pstolowski: does that work? I mean, sudo complains but it still reboots?
[10:16] <pstolowski> mvo: it's an error from ssh dropping connection; we do that in other places
[10:16] <mvo> pstolowski: aha, makes sense
[10:17] <mvo> pstolowski: thanks!
[10:18] <pstolowski> mvo: i'm not sure why it didn't fail before when i run this test, maybe it's not always reporting an error (?)
[10:18] <mvo> pstolowski: probably a race
[10:20] <pstolowski> could be
[10:37] <mup> PR snapd#9981 closed: gadget: policy for gadget/kernel refreshes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9981>
[10:55] <mup> PR snapcraft#3489 opened: errors: introduce details_from_called_process_error() helper <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3489>
[11:37] <mup> PR snapd#10076 closed: tests: fix snap-advise-command check for 429 <Simple 😃> <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10076>
[11:42] <mup> PR snapd#10077 opened: o/configstate: fix panic with a sequence of config unset ops over same path <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10077>
[11:44] <mvo> mborzecki: iirc we need to also have some code that keeps snap-confine apparmor profiles around during snapd refreshes, did I remember this correctly?
[11:44] <mborzecki> yes
[11:45] <mvo> mborzecki: what's the current thinking on this, do we have ideas already :) ?
[11:47] <mborzecki> mvo: yes, setup-profiles glob needs ot be altered such that the old profiles stay around and only get cleaned up when given revision of the snapd snap is being removed
[11:47] <mup> PR snapd#10078 opened: tests: handle "snap refresh" returning an empty reply gracefully <Created by mvo5> <https://github.com/snapcore/snapd/pull/10078>
[11:52] <mvo> mborzecki: great, is that something you can work on? and something we could even cramp into 2.49.2?
[11:53] <mborzecki> it's in my list
[11:53] <mvo> mborzecki: \o/ thanks!
[12:08] <jdstrand> mvo: hey, I don't know it you saw, but I was able to commit to the snappy-debug tree we setup, but the uploads all failed: https://launchpad.net/~jdstrand/+snap/snappy-debug/+build/1347999 https://launchpad.net/~jdstrand/+snap/snappy-debug/+build/1348000 ("Cannot upload new revisions for name=snappy-debug"). Is this something you could look at, give to someone, tell me who to talk to? (I feel like maybe
[12:08] <jdstrand> I'm not a coillaborator?)
[12:08] <jdstrand> I have no visibility on it (https://dashboard.snapcraft.io/snaps/snappy-debug/ is 404)
[12:17] <mborzecki> mvo: pedronis: the caching does not work afaict
[12:17] <mborzecki> and there's this warning in the task that restores the cache: `Warning: tunneling socket could not be established, statusCode=403`
[12:22] <mborzecki> tasks that run on github's infra ahve caching working correctly
[12:39] <pedronis> mborzecki: it's a firewall issue?
[12:40] <mborzecki> ha https://github.com/actions/cache/issues/478
[12:41] <mborzecki> although the issue describes a close event
[12:43] <mvo> jdstrand: let me chase this
[12:46] <jdstrand> mvo: thanks! it's fixed now :)
[12:58] <mup> PR snapd#10079 opened: api: provide meaningful error message on connect/disconnect for non-installed snap <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10079>
[13:33] <ijohnson> thanks mvo for merging all those pr's of mine that had 2 +1s but were red for a long time
[13:56] <mvo> ijohnson: sure thing!
[14:18] <pstolowski> cachio: there is a question re nested suites that maybe you can clarify in https://github.com/snapcore/snapd/pull/10068
[14:18] <mup> PR #10068: o/configstate: don't pass --root=/ when masking/unmasking/enabling/disabling services <Run nested> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10068>
[14:46] <cachio> pstolowski, let me take a look
[14:53] <cachio> pstolowski, done
[15:06] <pstolowski> cachio: thanks; does it make sense then to enable 20.04 for nested/core tests or are they bound to fail?
[15:07] <cachio> pstolowski, if you run the test for system 20.04 on suite nested/core
[15:07] <mvo> pstolowski: https://github.com/snapcore/snapd/pull/10068/checks?check_run_id=2192201052 looks real
[15:07] <mup> PR #10068: o/configstate: don't pass --root=/ when masking/unmasking/enabling/disabling services <Run nested> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10068>
[15:07] <cachio> the vm wont be a real uc20
[15:07] <mvo> pstolowski: "2021-03-25T10:39:52.8546726Z - Run configure hook of "core" snap (run hook "configure": [disable rsyslog.service] failed with exit status 1: Failed to disable unit: Unit file rsyslog.service does not exist." - that's odd, your test does not touch this, does it?
[15:07] <ijohnson> cachio: what do you mean?
[15:07] <cachio> because the vm won't have secure boot
[15:08] <ijohnson> well it's just not a secure boot + tpm uc20 vm
[15:08] <mvo> mborzecki: is it okay to squash-merge https://github.com/snapcore/snapd/pull/10054 ?
[15:08] <mup> PR #10054: overlord/snapstate, wrappers: add dependency on usr-lib-snapd.mount for services on core with snapd snap <Squash-merge> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10054>
[15:09] <cachio> on nested/core
[15:09] <cachio> NESTED_ENABLE_TPM: '$(HOST: echo "${NESTED_ENABLE_TPM:-false}")'
[15:09] <cachio> NESTED_ENABLE_SECURE_BOOT: '$(HOST: echo "${NESTED_ENABLE_SECURE_BOOT:-false}")'
[15:09] <cachio> and in nested/core20
[15:09] <cachio> NESTED_ENABLE_TPM: '$(HOST: echo "${NESTED_ENABLE_TPM:-true}")'
[15:09] <cachio> NESTED_ENABLE_SECURE_BOOT: '$(HOST: echo "${NESTED_ENABLE_SECURE_BOOT:-true}")'
[15:09] <cachio> this is the main dif
[15:10] <pstolowski> mvo: oh
[15:10] <cachio> ijohnson, depends on the test, if it is ok to run the test with that configuration so we can run it in nested/core
[15:11] <cachio> if we need to make sure the test run with secboot and tpm so we need to run in nested/core20
[15:11] <ijohnson> cachio: I guess we should think about unifying tests/nested/core and tests/nested/core20, and possibly making the default for tests/nested/core for uc20 to be w/o tpm and secboot, but allow specific tests to opt-in to secboot and tpm in that suite
[15:12] <ijohnson> it would mean that if for example I go add a new uc specific test to tests/nested/core, it will run on an unencrypted uc20 VM, and if I wanted to also run it for uc20 with secboot and tpm, then I would create a variant of the test with env vars in the spread task.yaml
[15:13] <ijohnson> we would then have to filter out duplicated non-uc20 systems, since non-uc20 systems operate the same with and without secboot/tpm, but I think the gain of unifying those suites is that we can more easily get uc20 coverage by just adding a file to the tests/nested/core suite without needing to remember about tests/nested/core20 suite, or potentially worse just duplicating an entire task.yaml except for one line
[15:13] <cachio> ijohnson, that makes sense
[15:14] <pstolowski> mvo: does rsyslog exist on core18?
[15:15] <cachio> ijohnson, i'll try to implement that
[15:19] <mvo> pstolowski: I think so, I can double check
[15:20] <mvo> pstolowski: oh, looks I'm wrong
[15:20] <mvo> pstolowski: seems like we don't
[15:20] <pstolowski> mvo: i think we're abusing rsyslog in gadget.defaults in the tests
[15:21] <pstolowski> mvo: and this triggers the problem. fwtw i think uc20 doesn't have rsyslog either
[15:21] <mvo> pstolowski: yeah, that definitely does not has it
[15:21] <mvo> pstolowski: meh, ok
[15:21] <mvo> pstolowski: abuse sounds not great
[15:22] <pstolowski> mvo: unfortunately rsyslog was the only flag we could test, that's why (because ssh is problematic to test :/)
[15:22] <mvo> pstolowski: I see
[15:22] <mvo> pstolowski: could we use resolved now?
[15:22] <pstolowski> mvo: yes i think so
[15:22] <pstolowski> mvo: i'm on it
[15:23] <mvo> \o/
[15:27]  * cachio lunch
[15:48] <mup> PR snapd#10080 opened: interfaces/u2f-devices: add HyperFIDO Pro (https://launchpad.net/bugs/1919268) <Created by oSoMoN> <https://github.com/snapcore/snapd/pull/10080>
[15:50] <pstolowski> mvo: ok the test passed with systemd-resolved; updated and pushed
[15:55] <pstolowski> mvo: so if anyone uses similar gadget defaults without reflection, this means problems after this PR
[15:57] <mvo> pstolowski: I guess we could do a git grep for this pattern maybe?
[15:57] <mvo> mborzecki: can I help in any way with the snap-confine profile thing? one more meeting then I have a bit of time I hope :)
[15:57] <pstolowski> mvo: i mostly worried about our users
[15:57] <zyga> snap confine profile magic? :-)
[15:58] <zyga> what are you changing?
[15:58] <mvo> pstolowski: oh, I see
[15:58] <pstolowski> *i'm
[15:58] <ijohnson> pstolowski: what do you mean reflection for gadget defaults ?
[15:58] <mborzecki> mvo: let me know how bad it looks https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/snapd-security-profiles-stay-around?expand=1
[15:58] <mborzecki> some tests are missing still
[15:59] <pstolowski> ijohnson: using service.rsyslog.disable=true in gadget defaults for early config on systems where it doesn't make sense because the unit doesn't exist
[15:59] <ijohnson> oh so before using that would not break anything and now using that would break something ?
[15:59] <mvo> mborzecki: does not look bad at all actually
[15:59] <pstolowski> ijohnson: which doesn't cause problems in early config, but strikes later
[15:59] <ijohnson> ah interesting
[16:00] <mvo> pstolowski: right so if someone cargo culted a rsyslog setting that would now cause problems
[16:00] <pstolowski> ijohnson: yeah beacause we always go over all services on snap set
[16:00] <ijohnson> I think it's unlikely it would happen for our users, but gadgets have a history of being cargo culted and doing very weird things
[16:01] <pstolowski> mvo: maybe it's 2.50 material then? i don't know
[16:18] <pedronis> pstolowski: I think we discussed the idea of checking if a service exist at all at some point or use system exit codes (but doesn't changed between releases)
[16:18] <pedronis> s/doesn't/those/
[16:20] <pstolowski> pedronis: yes
[16:20] <pedronis> mvo: #9999 needs a master merge and is also unblocked?
[16:20] <mup> PR #9999: snapstate: add "kernel-assets" to featureSet <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9999>
[16:20] <pedronis> pstolowski: I still think is the right path forward given that services are not the same across versions
[16:30] <pstolowski> pedronis: i could look at this as a prerequsite for existing PR
[16:35] <cachio> pedronis, is this the error you saw? https://paste.ubuntu.com/p/4vW7vqH6k4/
[16:36] <cachio> google:ubuntu-20.04-64 ...# ls /var/lib/snapd
[16:36] <cachio> state.json
[16:36] <cachio> this is what I see
[16:36] <pedronis> cachio: yes, something like that
[16:37] <pedronis> pstolowski: yes, we need to decide what to do exactly though, because the last time I'm not sure we reached a conclusion except that the error codes weren't useful
[16:38] <pstolowski> pedronis: yes, error codes were useless
[16:38] <pstolowski> pedronis: we would probably need a separate call to systemctl status
[16:45] <pedronis> yes
[16:45] <pedronis> I fear that's what we would need
[16:45] <pedronis> pstolowski: I think #10077 is reasonable but I have a probably annoying question
[16:45] <mup> Bug #10077: libforms1: new changes from Debian require merging <Ubuntu:Fix Released by cjwatson> <https://launchpad.net/bugs/10077>
[16:45] <mup> PR #10077: o/configstate: fix panic with a sequence of config unset ops over same path <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10077>
[16:48] <pstolowski> pedronis: thanks, i need to stare a bit a this
[16:49] <pstolowski> *at
[16:49] <pstolowski> what are some really big snaps in the store? i need to test something
[16:51] <ijohnson> pstolowski: try the 0ad snap it's pretty big our
[16:51] <pedronis> pstolowski: some of the jetbrains snap are big
[16:51] <ijohnson> *iirc
[16:51] <pstolowski> ack, thanks
[16:53] <pstolowski> ok, so snap abort correctly cancels the context while inside download task
[16:57] <mborzecki> mvo: wrapipng it up for today, pushed some tweaks https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/snapd-security-profiles-stay-around happy to discuss tomorrow if the branch makes sense
[17:00] <mvo> mborzecki: yeah, I will chat with pedronis if/how we could land this givne that he is off tomorrow
[17:06] <zyga> I had a look at the change and conceptually it looks good, I'm a bit puzzled though, was that profile removed from memory or is it only a problem if the file is gone from disk?
[17:06] <zyga> I'm asking because of a bug we keep propagating:
[17:06] <zyga> https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/snapd-security-profiles-stay-around#diff-48ad8c3c5d0a39f5ce40d31863a4ae42289a624cfcded61f571ce66fd984a729R583
[17:06] <zyga> here
[17:06] <mvo> mborzecki: got a verbal okay from samuele to land without him (the current diff looks fine)
[17:06] <zyga> this is never doing anything, right?
[17:07] <zyga> because apparmor unload program relies on the ability to parse the profile and find the profile names again
[17:07] <zyga> so we remove things from disk and apparmor just NOPs
[17:07] <zyga> cc mborzecki pedronis ^
[17:07] <pedronis> mborzecki: there's a typo: SecuityBackendDiscardingLate Security
[17:08] <mvo> zyga: only gone from disk, we have a race when snapd is refreshing and there is a reboot in the middle
[17:08] <zyga> ah
[17:08] <zyga> then that is good IMO
[17:09] <zyga> I'd drop a comment so that what I said about unload profiles doesn't get lost
[17:09] <zyga> yeah, raciness on poweroff is very tricky
[18:38] <mup> PR snapd#10081 opened: [RFC] interfaces, interfaces/apparmor, overlord/snapstate: late removal of snap-confine apparmor profiles <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10081>
[19:08]  * cachio afk
[21:41] <mup> PR snapcraft#3490 opened: build(deps): bump pyyaml from 5.3 to 5.4 <dependencies> <python> <Created by dependabot[bot]> <https://github.com/snapcore/snapcraft/pull/3490>


[01:11] <ScottK> ~ninjas | 4.6.2 tarballs for packaging.
[01:12]  * ScottK tries again.
[01:12] <ScottK> !ninjas | 4.6.2 tarballs for packaging.
[01:12] <neversfelde> hehe
[01:17] <neversfelde> ScottK: would you add my ssh key to the known hosts on ktown?
[01:17] <neversfelde> https://launchpad.net/~neversfelde/+sshkeys
[01:17] <ScottK> Sure.
[01:17] <neversfelde> I lost my old one once again
[01:18] <ScottK> So I can remove the old one?
[01:19] <ScottK> neversfelde: Swapped.
[01:19] <ScottK> Please check you can get in.
[01:24] <neversfelde> ScottK: works, thank you. I'll have a look how I can help with 4.6.2
[01:25] <ScottK> Great.
[01:25] <ScottK> AFAIK you're the first, so I'd start with kde4libs.
[01:30] <neversfelde> it's 3 am over here, I nee a bit of sleep, but I will start wit libs, if no one else does tomorrow
[02:56] <dantti_> ScottK: hey, you reported a bug against kpk, do you have some kind of test case like install gnome (for a bunch of packages)? I never saw that happening...
[03:18] <ScottK> dantti_: What bug.  I don't recall.
[03:24] <dantti_> ScottK: it says that you reported a hour ago :P https://bugs.launchpad.net/ubuntu/+source/kpackagekit/+bug/747902
[03:24] <ScottK> Looking
[03:25] <ScottK> dantti_: That's not me.
[03:25] <ScottK> ScottK != ScottT
[03:26] <dantti_> ah :P
[03:26] <dantti_> sorry then
[03:26] <ScottK> No problem.
[07:37] <c2tarun> I was trying to configure kmail in order to work on some kmail bugs and I got this error http://pastebin.com/tnMMBe3d  can anyone please help.
[10:32] <c2tarun> anyone here?
[10:37] <ari-tczew> c2tarun: yep
[10:38] <c2tarun> ari-tczew: can you please help me with this error http://pastebin.com/tnMMBe3d
[10:39] <ari-tczew> c2tarun: sorry dunno
[10:40] <c2tarun> ok :)
[12:23] <CIA-43> [sysadmin] stikonas * 1226849 * trunk/extragear/sysadmin/ (libqapt/ muon/) Cleanup after git migration.
[16:03] <debfx> ScottK: the ~ppa1/~release1~ppa1 version scheme breaks once we are in the q-series
[16:04] <ScottK> debfx: Not so far away, so that's a good point.  Please reply to the thread with that thought.
[16:09] <debfx> ScottK: done, the obvious fix would be to always use ~release1~ppa1
[16:38] <nixternal> DarkwingDuck: ping
[16:40] <nixternal> DarkwingDuck: I am at the Ubuntu Global Jam here in Chicago along with a Python Hack-A-Thon and the Flourish conference, what needs to be done
[16:52] <DarkwingDuck> nixternal: gimme 15 minutes... recovering
[17:18] <ScottK> debfx: Agreed.  Thanks.
[17:19] <ScottK> nixternal: Make kubuntu-docs build would be a good start.
[17:57] <nixternal> ScottK: they don't build?
[17:57] <ScottK> nixternal: Apparently not.  I recall some reference they FTBFS in a rebuild test.
[17:57]  * nixternal checks
[17:58] <nixternal> ScottK: was it a checkout build that was failing, or was it just the maverick docs being built in natty that crashed?
[17:58] <ScottK> It was whatever in the archive failing.
[17:58] <ScottK> in/is in
[18:03] <nixternal> ok, updating my pbuild then I will check it out. I need to see if DarkwingDuck has any updates that need to be built for nutty
[18:13] <nixternal> ScottK: yup, it sure does crash. this should be fun one.
[18:40] <shadeslayer> ScottK: Riddell KDE 4.6.2 on kde-packagers ... did we start on those yet?
[18:41] <ScottK> shadeslayer: neversfelde said something about starting today.  Not sure if he got anything done or not.
[18:41] <ScottK> shadeslayer: Other than that, I think it's all there to work on.
[18:42] <shadeslayer> ah .. okay .. i can start tomorrow after i fix a few bugs in telepathy kde tonight
[18:43] <debfx> shadeslayer: I've just uploaded kde4libs so you can start packaging the rest :)
[18:43] <shadeslayer> ok :)
[19:07] <afiestas__> Riddell: ping
[19:27] <ScottK> afiestas__: Would you have a look at Bug 747572?
[19:28] <ScottK> afiestas__: I still haven't seen him since you last pinged.
[19:31] <afiestas__> ScottK: I'm kinda busy right now, but yes I can take a look at it
[19:31] <ScottK> Thanks.
[19:31] <afiestas__> but I know a kde developer (apol) with the same problem
[19:31] <afiestas__> and iirc it was an udisk problem
[19:31] <ScottK> This is power though.
[19:31] <ScottK> And upower was reporting correctly.
[19:32] <afiestas__> *upower
[19:32] <ScottK> (unless upower -d reports something different than what it tells solid, I don't see how)
[19:34] <afiestas__> ScottK: could you check the value from dbus?
[19:35] <afiestas__> qdbus --system org.freedesktop.UPower... ?
[19:35] <ScottK> I'll try.
[19:38] <ScottK> afiestas__: http://paste.kde.org/8788/
[19:38] <ScottK> Also reinstalling HAL and then switching power sources I immediately get the problem again.
[21:27] <c2tarun> India win the World Cup :)
[21:49] <nixternal> ScottK: yeah, i found the borkage, but i will have to spend a little time on it. had to fix stuff in kubuntu-docs bzr but something has changed with the ksgmtools2 stuff in KDE that has borked a ton of other things. I need to figure those out next, so something tells me this is going to suck :/
[21:49] <nixternal> DarkwingDuck: ^^
[21:50] <nixternal> kubuntu-docs == borked, will not build. need major fixes, where? I have no idea, gotta figure that out, so you need to continue bothering me to get it done, otherwise I will just leave you all hanging
[21:53] <ScottK> nixternal: I have a vague recollection that ksgmtools2 used to be from kdelibs, now it's from kde4libs.
[21:53] <ScottK> So it's moved to a several years newer version of $stuff.
[22:38] <apparle> guys, kubuntu 11.04 beta is out right? why don't I see anything on kubuntu.org?
[22:39] <ScottK> Probably because someone forgot to write something.
[22:39] <ScottK> ryanakca: ^^^
[22:40] <apparle> ScottK: what is the release date for 11.04?
[22:40] <shadeslayer> !schedule
[22:41] <ryanakca> ScottK: Sure. Can I just base it off of http://www.kubuntu.org/news/natty-alpha-3 ?
[22:43] <ScottK> ryanakca: Yes.
[22:43] <ScottK> apparle: IIRC 4/28.
[22:43] <ScottK> ryanakca: Thanks.
[22:44] <apparle> thanks
[22:45] <stikonas> Is there any reason why there are no translations in .desktop files in plasma-desktop package?
[22:46] <stikonas> (this question was for anybody who knows)
[22:46] <debfx> stikonas: they are stripped from the desktop files and put into language packs
[22:47]  * ryanakca wonders why the admin section of the Kubuntu website still only works with Drupal
[22:48] <stikonas> hmm, strange because the word Desktop is untranslated in "Desktop Settings"
[22:48] <ryanakca> sorry, Konqueror
[22:50] <shadeslayer> ryanakca: or rekonq
[22:52] <debfx> stikonas: you can check https://translations.launchpad.net/ubuntu/natty/+source/kdebase-workspace/+pots/plasmagenericshell to see if the string is translated
[22:53] <ryanakca> ScottK: http://www.kubuntu.org/news/kubuntu-natty-beta-1-released
[22:54] <stikonas> ok, I will look at it. Actually, it is translated in KDE and everything worked in Fedora and in Gentoo, so this is definetely launchpad thing...
[22:56] <stikonas> debfx: are you sure that this is the correct pot file?
[22:57] <stikonas> because in upstream translations the string was in desktop_kdebase_kde-workspace.pot
[23:03] <stikonas> debfx: https://translations.launchpad.net/ubuntu/natty/+source/kdebase-workspace/+pots/desktop-kdebase-workspace/ has "Desktop" entry and it is translated
[23:03] <stikonas> something very strange is happening
[23:04] <stikonas> actually I tested now with another language, and Desktop is still untranslated
[23:21] <ScottK> ryanakca: Looks good.  Thanks.


[04:06] -SwissBot:#ubuntu-news- ::Fridge:: Ubuntu Weekly Newsletter Issue 715 @ https://fridge.ubuntu.com/2021/12/27/ubuntu-weekly-newsletter-issue-715/ (by guiverc)
[08:14] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Kubernetes infographic: usage of cloud native technology in 2021 @ https://ubuntu.com//blog/kubernetes-infographic
[16:09] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Design and Web team summary – 3 December 2021 @ https://ubuntu.com//blog/design-and-web-team-summary-3-december-2021


[11:34] <BluesKaj> 'Morning folks
 https://twitter.com/kubuntu/status/1277978377815646208
 ooooo, new wallpaper too :)  Update was smooth here on real hw.