[06:35] <mborzecki> morning
[06:40] <mborzeck2> damn isp
[07:33] <mup> PR snapd#7747 closed: gadget: skip fakeroot if not needed <Simple 😃> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7747>
[07:38] <zyga> hey
[07:38] <mborzecki> zyga: hey
[07:38] <zyga> mborzecki: check out "Sourcetrail"
[07:38] <zyga> it's FOSS just now
[07:38] <zyga> pretty neat IMO
[07:39] <mborzecki> zyga: hmmm 'something went wrong'
[07:39] <zyga> mborzecki: did you finish all of the HR training?
[07:39] <mborzecki> zyga: yup
[07:39] <zyga> https://github.com/CoatiSoftware/Sourcetrail
[07:39] <zyga> did you have any issues?
[07:39] <mborzecki> zyga: with the hr training?
[07:39] <zyga> I had to re-do one from scratch because the in progress version was stuck on last page without ability to "sign" the result
[07:40] <zyga> yes
[07:40] <zyga> I finished everything but more like at 1-2AM
[07:42] <mborzecki> zyga: so sourcetrail is like a better gnu global web mode?
[07:44] <zyga> I have no idea what that is
[07:44] <zyga> hey mvo
[07:44] <zyga> how did you sleep?
[07:50] <mvo> hey zyga ! much better. did stay up longer and had a relatively good sleep
[07:50] <mvo> zyga: and you?
[07:50] <mborzecki> mvo: hey
[07:51] <zyga> mvo: I managed to sleep at 2:30 - 3:00 AM
[07:51] <zyga> better than yesterday for sure
[07:52] <zyga> mvo: I shared this with Maciek earlier: https://github.com/CoatiSoftware/Sourcetrail
[07:52] <zyga> it's neat, I played with it a little
[07:53] <zyga> their website is slashdotted now
[07:53] <zyga> but should recover eventually
[07:53] <mvo> zyga: 2:30am - 3:00 am ? that is still not great :/
[07:53] <mvo> hey mborzecki
[07:53] <mvo> zyga: oh, nice
[08:03] <pstolowski> morning
[08:05] <mvo> hey pstolowski ! good morning
[08:06] <zyga> good morning pawel
[08:07] <mborzecki> pstolowski:  hey
[08:32] <zyga> mvo: I think I should take a swap day today
[08:32] <zyga> mvo: yesterday was okay to "burn" the day on HR and some random reviews
[08:32] <zyga> but today I feel so tired and sleepy, in the morning, that I really think I need to just take it easy and sleep/rest all day
[08:32] <zyga> and not pretend to work effectively
[08:33] <mvo> zyga: sure, thats fine
[09:16] <Mirv> if there's someone who is not really badly sleep deprived and has access to openSUSE Tumbleweed, please update to 20191116 and check if you can reproduce what I have bug #1853110
[09:16] <mup> Bug #1853110: On up-to-date openSUSE Tumbleweed all snaps show "broken" <snapd:New> <https://launchpad.net/bugs/1853110>
[09:16] <zyga> j,,
[09:16] <zyga> hmm
[09:17] <pstolowski> Mirv: hey! yes i'm actually looking at it right now
[09:18] <zyga> pstolowski: thank you
[09:18] <pstolowski> (it's my bug triaging day today)
[09:18] <Mirv> zyga: you are not counted into that someone according to log above :D take care.
[09:18] <Mirv> pstolowski: ok, thanks!
[09:18] <zyga> thank you so much guys
[09:18]  * zyga returns to cleaning the office
[09:21] <Mirv> apparmor was updated but not sure what was changed https://lists.opensuse.org/opensuse-factory/2019-11/msg00264.html - that said, disabling apparmor does not seem to help me
[09:21] <pstolowski> Mirv: i'm installing tumbleweed atm as i don't have it handy
[09:22] <zyga> pstolowski: it eats gobs of space
[09:22] <zyga> pstolowski: using btrfs and snapshots
[09:22] <zyga> not very vm friendly
[09:22] <zyga> you may want to disable snapper (snapshot thing)
[09:23] <Mirv> ..or just select ext4 for everything in advanced setup instead of btrfs
[09:33] <pstolowski> zyga, Mirv good to know, thanks, yeah, too late to change fs, will look at disabling later
[09:49] <mvo> a second review for 7745 would be great
[09:50] <mvo> should be simple and will unblock 7746
[09:50] <zyga> mvo: let me do it
[09:52] <Mirv> pstolowski: so for example I've rocketchat-desktop installed, and with sudo mount /var/lib/snapd/snaps/rocketchat-desktop_97.snap /mnt I get: mount: /mnt: mount failed: Operation not permitted.
[09:52] <Mirv> I wish there was something meaningful in some log, but I can't find any
[09:54] <zyga> Mirv: look at audit log
[09:54] <zyga> Mirv: /var/log/audit/audit.log
[09:56] <Mirv> I tried, but I did not find other than "ype=AVC msg=audit(1574157270.914:590): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.signal-desktop.signal-desktop" pid=7789 comm="apparmor_parser"" type of messages
[09:58] <zyga> that's odd
[09:59] <pstolowski> Mirv, zyga: i cannot reproduce the exact mount issue, but something is definately broken. all snaps get mounted, also after reboots. but i can get a snap to run only after i install it, and until reboot. after reboot i get "cannot change profile for the next exec call: No such file or directory
[09:59] <pstolowski> snap-update-ns failed with code 1: File exists" for all snaps
[09:59] <zyga> pstolowski: did you enable snapd.apparmor.service?
[09:59] <pstolowski> profiles seem to be in place, snaps mounted
[09:59] <zyga> it's part of the install docs
[10:00] <pstolowski> ah, i missed that
[10:00] <zyga> mvo: https://github.com/snapcore/snapd/pull/7745#pullrequestreview-318910411 + 1
[10:00] <mup> PR #7745: snap-bootstrap: add go-flags cmdline parsing and tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/7745>
[10:01] <mup> PR snapd#7745 closed: snap-bootstrap: add go-flags cmdline parsing and tests <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7745>
[10:02] <mvo> zyga: thank you!
[10:04] <pstolowski> zyga: right that was it
[10:05] <mvo> also 7712 needs a second review (a bit more work but really important to move forward with uc20)
[10:06] <pstolowski> Mirv: ok, cannot reproduce on fresh install, wonder what when wrong on your box. do you have everything updated, no held dependencies etc?
[10:06] <Mirv> I do see "missing file /snap/.../meta/snap.yaml" type of messages but that's obvious since nothing is mounted, it's just annoying that regarding the "Operation not permitted" I'm not finding anything, and sudo systemctl stop apparmor + sudo systemctl stop snapd.apparmor do not help so it does not seem to be apparmor that's denying the permission (also as nothing is in audit.log)
[10:07] <pstolowski> Mirv: the fact you cannot even mount .snap manually is a key, that's pretty weird
[10:07] <Mirv> pstolowski: :( everything is updated, nothing seems to be held
[10:08] <Mirv> pstolowski: yes it is
[10:08] <Mirv> squashfs is installed, that's one thing that I thought about
[10:08] <pstolowski> Mirv: that's not even a snapd issue but something more fundamental
[10:08] <pstolowski> Mirv: is it a standard suse kernel?
[10:09] <Mirv> pstolowski: standard yes. but I have another TW laptop at 20191112, I'll update that one too and see if it gets broken or not
[10:10] <pstolowski> Mirv: also, can you try mount -v /var/lib/snapd/snaps/rocketchat-desktop_97.snap /mnt (-v for verbose)
[10:11] <Mirv> pstolowski: not anymore verbose with that
[10:12] <Mirv> pstolowski: ah, it's loop devices broken, somehow.. I can't mount an iso either
[10:13] <Mirv> but yes this is not snapd anymore
[10:13] <mup> Bug #1853122 opened: Facing requires classic confinement error <Snappy:New> <https://launchpad.net/bugs/1853122>
[10:13] <zyga> Mirv: losetup -a?
[10:13] <zyga> maybe you ran out of loopback devices
[10:14] <Mirv> zyga: empty
[10:14] <zyga> can you try:
[10:15] <zyga> Mirv: losetup -f /path/to/a/squashfs/file/
[10:15] <zyga> (as root)
[10:15] <zyga> perhaps also with -r for --read-only
[10:15] <Mirv> hmm, losetup: cannot find an unused loop device
[10:15] <zyga> so that's the problem
[10:16] <zyga> can you strace it?
[10:17] <Mirv> yep, and from there I can see that there's nothing ls /dev/loop*
[10:17] <zyga> do you have loop-control?
[10:17] <Mirv> not even that
[10:17] <zyga> I don't know what makes it
[10:17] <zyga> on my system that is 10:237
[10:23] <pstolowski> Mirv: thanks for updating the bug report!
[10:24] <Mirv> pstolowski: sorry for taking your time :( it very effectively seemed like "snapd broken" for a long time..
[10:25] <Mirv> so currently I've filed openSUSE bug report, but then again my other laptop did not break. mknod /dev/loop-control c 10 237 helps. I'll follow up on the more relevant channels, maybe of course snapd current report a bit more if loop devices are broken.
[10:25] <mup> Bug #1853122 changed: Facing requires classic confinement error <snapd:New> <https://launchpad.net/bugs/1853122>
[10:25] <zyga> pstolowski: consider adding a check that /dev/loop-control exits and has major/mior
[10:26] <zyga> sanity check, that is
[10:26] <pstolowski> zyga: exactly
[10:26] <pstolowski> Mirv: no worries. we do some sanity checks, and i think this problem highlights one other potential problem that we may want to check
[10:39] <xnox> Chipaca:  mvo: https://raw.githubusercontent.com/snapcore/pc-amd64-gadget/20/grub.cfg-recovery  note improvements 1) variables select the default entry by id 2) all recovery systems are enumerated 3) entries are created per-mode / per-system 4) no idea what duplicate hotkeys will do 5) added menuentry to go back to UEFI setup, as my VM is too quick
[10:39] <xnox> it's kind of evolution of previous globgging, with type entries.
[10:40] <xnox> and the cmdline is now correct.
[10:41] <xnox> i was thinking that load_env --file /systems/$snapd_recovery/grubenv could e.g. declare the modes that are supported, and then generate entries for modes that a given recovery system can do?
[10:41] <Chipaca> xnox: I too was thinking of an env per system
[10:41] <mvo> xnox: sounds good! should we handle this stuff via PRs or do you prefer to commit directly to master?
[10:42] <xnox> it was a rewrite, thus i just pushed it to master
[10:42] <Chipaca> xnox: i'm not sure the logic for default= is sane there though
[10:43] <Chipaca> xnox: shouldn't that be set after the loop?
[10:43] <xnox> Chipaca:  mvo: we were meant to have design for the boot menu right....? because it matters what order things are shown, what the text / hotkeys are, what they do, how they are grouped.
[10:44] <xnox> Chipaca:  it is set if there is a default provided in the global env (i.e. boot that next); otherwise it is set each time a new better system is found.
[10:45] <xnox> mvo:  Chipaca: and we need to like search for ubuntu-boot and add entry to chainload "normal mode" grub right?
[10:46]  * xnox also dislikes run/recover. I would prefer "normal/recover/install" such that hotkeys are unique: n r i
[10:47] <mvo> xnox: I pushed https://github.com/snapcore/core20/pull/13 with a very first draft of the separation of writable-path from initramfs. its the old code almost untouched. I will look to add tests and then we can start refactoring I think
[10:47] <mup> PR core20#13: handle-writable-paths: extract the writable-path handling <Created by mvo5> <https://github.com/snapcore/core20/pull/13>
[10:47] <mvo> xnox: but its what you had in mind, rightß
[10:47] <mvo> ?
[10:48] <mvo> niemeyer: it would be great if https://github.com/snapcore/core20/ pull requests could be added to mup
[10:48]  * mvo needs to step out for ~10min
[10:48] <niemeyer> mvo: Heya
[10:48] <niemeyer> mvo: Sure, will do
[10:50] <xnox> mvo:  yes, that is the right approach, and a good starting point. It shouldn't live in /etc though, and can always iterate that once we create it as an entry point.
[11:05] <pstolowski> Chipaca: hey, why was this assigned to some other team? https://bugs.launchpad.net/snapd/+bug/1851480
[11:05] <mup> Bug #1851480: Hooks are not included in slot/plug label expressions <snapd:Confirmed for glancr> <https://launchpad.net/bugs/1851480>
[11:08] <zyga> pstolowski: community
[11:11] <pstolowski> zyga: someone specific is going to fix it?
[11:11] <mvo> xnox: yeah, do you prefer /usr/lib/something/handle-writable-path?
[11:12] <Chipaca> pstolowski: that's dot-tobias
[11:12] <pstolowski> Chipaca: ah, ok
[11:12] <xnox> mvo:  /usr/lib/core/handle-writable-paths yeah
[11:13] <Chipaca> pstolowski: they said on 2019-11-07 they'd get to it "next week", and that they'd report progress
[11:13] <Chipaca> pstolowski: so maybe it's time to jiggle the plug
[11:14] <mvo> xnox: cool, will move it over
[11:16] <zyga> pstolowski: yes, though please reassign if you want to fix it sooner
[12:09] <mup> PR snapd#7749 opened: tests: restart the snapd service in the snapd-failover test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7749>
[12:13] <cachio>  mvo hey
[12:14] <cachio> #7749 is to fix the issue I raised about that test on pi3?
[12:14] <mup> PR #7749: tests: restart the snapd service in the snapd-failover test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7749>
[12:16] <mvo> cachio: it *could* be related but it was the outcome of a discussion with mborzecki about the snapd failover robustness and we wanted to make sure our tests are complete (i.e. testing that we didn't just restart into the right snapd but also ensuring that its stable accross the restart)
[12:16] <mvo> cachio: you need to remind me about this pi3 issue, I don't recall :/
[12:17] <cachio> mvo, sure
[12:17] <cachio> I see this error https://paste.ubuntu.com/p/xBhPYrjfVf/
[12:18] <mup> PR snapd#7750 opened: sanity: check /dev/loop-control device as part of sanity checks <Created by stolowski> <https://github.com/snapcore/snapd/pull/7750>
[12:18] <cachio> mvo, It happens after we install the broken snapd
[12:20] <mup> PR snapd#7712 closed: seed: support in Core 20 seeds local unasserted snaps for model snaps <Priority 🏇> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7712>
[12:21] <mvo> cachio: thanks, thats interessting. is this happening all the time or just sometimes?
[12:21] <cachio> mvo, all the time
[12:23] <mvo> cachio: do you know when this started to happen?
[12:24] <mvo> cachio: or is it happening since forever?
[12:24] <mvo> cachio: also I assume this happens on all the Pis, not just pi3, pi2 as well?
[12:25] <cachio> mvo, checking logs
[12:26] <mvo> cachio: thank you, no rush, I get lunch now but that is interessting, I wonder if there is a race with that path
[12:28] <cachio> mvo, 2.42 execution
[12:28] <cachio> first time I saw that
[12:28] <cachio> I raised the issue at that moment
[12:29] <cachio> and then I did a manual execution to get more info
[12:29] <cachio> last week
[12:30] <cachio> mvo, I mostly reproduced that on pi3
[12:31] <cachio> on pi2 not sure
[12:32] <cachio> just once on pi2, it was during 2.42.1
[12:37] <cachio> mvo, it is not happening all the time on pi3
[12:37] <cachio> mvo, this is an execution during last week https://trello-attachments.s3.amazonaws.com/5da8bc830df86851446e9d4e/5dcf78cb5984618fb21cd5d7/1a9b05bfb0491c8faad045fc9f6143d3/snapd_2.42.1%2Bgit1140.g9173632_(5459)_pi3-refresh-18_arm32.log
[12:38] <cachio> this is all stable + snapd from edge
[12:38] <cachio> and it works well
[12:50] <pstolowski> cachio: is this still the case https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1852635 ?
[12:50] <mup> Bug #1852635: mount-ns test failing with latest bionic updates <snapd (Ubuntu):New> <https://launchpad.net/bugs/1852635>
[12:52] <cachio> pstolowski, yes
[12:52] <cachio> pstolowski, this is the last log https://travis-ci.org/snapcore/spread-cron/builds/613333438
[12:53] <cachio> from yesterday
[12:53] <pstolowski> cachio: ok, thanks, will investigate
[12:53] <cachio> pstolowski, thanks
[13:48] <mvo> cachio: thank you! interessting find, I wonder what is going on there, our code did not change in a while, maybe systemd did change somehow
[14:09] <mborzecki> pstolowski: https://devfest.withgoogle.com/#devfest-map try poland
[14:09] <pstolowski> mborzecki: thanks
[14:22] <mup> PR snapd#7748 closed: overlord: fix the get command help message <Simple 😃> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/7748>
[14:24] <pstolowski> cachio: fwtw i run spread -debug google:ubuntu-18.04-64:tests/main/mount-ns and it didn't fail
[14:31] <mborzecki> cachio: pstolowski: do you have the log?
[14:33] <pstolowski> mborzecki: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1852635
[14:33] <mup> Bug #1852635: mount-ns test failing with latest bionic updates <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1852635>
[14:37] <mup> PR snapd#7751 opened: cmd: fix the get command help message <Simple 😃> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7751>
[14:37] <cmatsuoka> mborzecki: did it over in the right message: https://github.com/snapcore/snapd/pull/7751
[14:37] <mup> PR #7751: cmd: fix the get command help message <Simple 😃> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7751>
[14:38] <cachio> pstolowski, are yo uusing the image test-bionic-1 ?=
[14:40] <cachio> mborzecki, this is the last error https://travis-ci.org/snapcore/spread-cron/builds/613333438#L1850
[14:41] <mborzecki> cmatsuoka: thanks, will take a look
[14:42] <pstolowski> cachio: no, how do you mean?
[14:43] <cmatsuoka> mborzecki: thanks for noticing that, I grepped for the faulty message and I think I didn't expect more than one instance
[14:45] <pstolowski> cachio: ah, you mentioned it in the beginning of output in the bug report
[14:46] <pstolowski> cachio: how do i get it?
[14:48] <ijohnson> mborzecki: regarding epochs on #7431, I don't think we should do anything for that, AFAICT it should just work with epochs, my gut feeling is that if there is something special that should happen with disabled services and epochs the "transitioning" snap between epochs should take care of that in post-refresh, pre-refresh hooks IMHO
[14:48] <mup> PR #7431: overlord/snapstate: don't re-enable and start disabled services on refresh, etc <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7431>
[14:48] <ijohnson> anyways do you think I'm ok to land that PR now since it's green? (CC mvo)
[14:49] <ijohnson> mvo: also should we get a +1 from jdstrand on #7731 before merging?
[14:49] <mup> PR #7731: usersession/userd: add "apt" to the white list of URL schemes handled by xdg-open (LP: #1776873) <Created by oSoMoN> <https://github.com/snapcore/snapd/pull/7731>
[14:50] <mvo> ijohnson: yeah, a review for 7731 from jdstrand would be great, should be fine but best to double check with him
[14:50] <ijohnson> ack
[14:51] <mvo> ijohnson: let's merge 7431, it got two +1 and conceptually samuele had looked at it so AFAIK we should not block on him
[14:52] <cachio> pstolowski, I created it by updating and upgrading bionic and then rebooting it
[14:52] <ijohnson> \o/ I'm on it
[14:52] <mvo> ijohnson: great, thanks for this one!
[14:53] <mup> PR snapd#7431 closed: overlord/snapstate: don't re-enable and start disabled services on refresh, etc <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7431>
[14:53]  * ijohnson can't wait for pstolowski to rewrite all of that code for preseeding and review it all again
[14:53] <mup> PR snapcraft#2809 opened: project-loader: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2809>
[14:54] <pstolowski> ijohnson: yay
[15:14] <ijohnson> pstolowski: I'm not quite done going through my backlog of forum/email/github notifications, did you submit a PR adding 'k' to the serial-port apparmor rules? If not I can do that
[15:14] <ijohnson> looks like jdstrand gave a +1 to adding 'k' to the rule
[15:14] <ijohnson> https://forum.snapcraft.io/t/not-able-to-start-configure-custom-built-ubuntu-core/14142/23?u=ijohnson
[15:16] <pstolowski> ijohnson: he did, but he also said he was going to do it afaiu
[15:17] <ijohnson> ah I see his other comment now, nvm :)
[15:18]  * cachio lunch
[15:19] <mup> PR snapd#7752 opened: tests: enable degraded test on arch linux after latest image updates <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7752>
[15:19] <mborzecki> ijohnson: yeah, i was wondering about the snap service naming, it's totally up to whoever builds the snap, so you can have a service named A, then the user disables it, the publisher renames A to B, the user proceeds to disable B, then A returns as something completely new and gets disabled because we carry the history of the disabled service names, but it a corner case so meh ;)
[15:21] <ijohnson> well the question I would have is when you say "A returns as something completely new", how do you qualify something completely new? :-) it has the same name, so the publisher probably intended some kind of connection between the first service and it's reincarnation
[15:21] <ijohnson> but yes that is a corner case
[16:35] <mup> PR snapcraft#2810 opened: build-providers: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2810>
[16:40] <ijohnson> Chipaca: I think the snapd REST API wiki docs need an update, see https://forum.snapcraft.io/t/facing-requires-classic-confinement-error/14163
[16:40] <Chipaca> hmm
[16:40]  * Chipaca looks
[16:41] <Chipaca> ijohnson: oh, doc seems to be wrong, not outdated
[16:42] <ijohnson> wrong == outdated ?
[16:44] <Chipaca> ijohnson: /v2/snaps never took options
[16:44] <ijohnson> right got it
[16:44] <Chipaca> so all those options descriptions should be on /v2/snaps/<snap>
[17:14] <Chipaca> augh
[17:14]  * Chipaca takes a break
[17:21] <ijohnson> degville, when you get a chance can you take a look at making the docs changes for https://bugs.launchpad.net/snapd/+bug/1612440 ?
[17:21] <mup> Bug #1612440: Full systemd socket activation support <lxd> <Snapcraft:New> <snapd:Fix Released> <https://launchpad.net/bugs/1612440>
[17:23] <degville> ijohnson: will do, thanks for letting me know.
[17:29] <ijohnson> thanks!
[17:41] <jk0ne> Hello!  I am beginning an upgrade of the snapcraft forums.  The forum will be in read-only mode until this is completed.  ETA: less than one hour.
[17:53] <Chipaca> EOD for me it is
[17:53] <Chipaca> 👋
[18:32] <jk0ne> forum.snapcraft.io has been upgraded. Maintenance is complete.
[18:32] <mup> PR snapcraft#2811 opened: extractors: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2811>
[18:39] <degville> thanks jk0ne!
[18:46] <ogra> hmm
[18:46] <ogra> jk0ne, not sure if that was your intent ... https://imgur.com/a/es4hRK9
[18:47] <ogra> (has anyone else lost all CSS from the forum ?)
[18:48] <ogra> bah ... ok, now it is back but i'm hard logged out ...
[18:48] <ec0> looks OK here
[18:48] <ogra> (and cant remember my credentials since the silly forum doesnt use SSO)
[19:03] <jk0ne> ogra: I think you might have hit it during the actual reload.  Let me know if you are seeing issues still.
[19:15] <ogra> jk0ne, nope, seems ok now
[19:17] <jk0ne> glad to hear
[23:24] <mup> PR snapcraft#2812 opened: store: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2812>
[23:39] <mup> PR snapcraft#2813 opened: pluginhandler: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2813>


Got revoked as an Ubuntu member after 1 month and 8 days, as someone from the Kubuntu project said i was not nice, even if it was him that bullied me so losing my rabatte at Gandi and @ubuntu.com email tomorrow


[05:21] <fweht> i couldnt install the vscode snap on ubuntu 24.04 server...  could it be that i need some xorg/wayland compatibility layer?  firefox from snap installed just fine...


[09:48] <ev> (replied via email)
[10:55] <CIA-3> debian-installer: cjwatson * r1412 ubuntu/ (5 files in 2 dirs): merge lp:~apw/debian-installer/kernel-update
[11:39] <ev> heads up: accessibility support in ubiquity-dm is broken
[11:40] <ev> looking into it now
[13:56] <CIA-3> debian-installer: cjwatson * r1413 ubuntu/debian/changelog: releasing version 20101020ubuntu16


[10:17] <jamespage> how are the packages associated with each team defined for the reports @ http://reqorts.qa.ubuntu.com/reports/rls-mgr/
[10:17] <jamespage> ?
[10:18] <jamespage> the server team are currently using this with another report and I'd like to consolidate on the official release management report
[10:18] <jamespage> but I think the list of packages needs to be expanded.
[10:25] <xnox> jamespage: if i remember correctly, bdmurray maintains package mapping in those reports.
[10:25] <infinity> Is it not just based on bug subscriptions?
[10:25] <infinity> If it isn't it probably should be, and those should be cleaned up.
[10:25] <infinity> Maintaining parallel lists is silly.
[10:26] <Daviey> Hmm.. it was maintained via a *spreadsheet*.. That might not still be the case.
[10:27] <Daviey> Ursula and brad would be good contacts for that, i think.
[10:27] <infinity> Daviey: I'm not arguing that it might not be in a spreadsheet currently, just that it shouldn't be. :P
[10:28] <infinity> We demand bug subscriptions when we do MIRs and such, we really should just formalise that as the one canonical place for team blame.
[10:28] <Laney> I think there was a BP to stop using the spreadsheet and do something else
[10:28] <Laney> which is the part bdmurray was working on
[10:28] <Daviey> well, that doesn't have a single poc when there are multiple subscriptions.
[10:29] <infinity> (And before anyone mentions that more than one team can subscribe to a package and then bugs would show pu twice in the report, tell me how that's bad that two teams would care?)
[10:29] <Laney> https://blueprints.launchpad.net/launchpad/+spec/other-p-package-mapping
[10:32] <Daviey> infinity: It's bad, in the situation that both teams think the other will deal with it.  Which has happend :)
[10:33] <Daviey> So having a single contact for the tracking/triaging, even if not the team solving it.. Is a good way IMO
[10:33] <infinity> Daviey: One could short the reports to only display for one team once it's been assigned to a member of that team.
[10:33] <infinity> Daviey: But I think the default assumption when unassigned should be "no one's looked at it yet".
[10:34] <infinity> Daviey: Besides, it seems a bit weird for people to use the reports to find bugs they shouldn't be working on, rather than the inverse.  Look at your own section, silly. :P
[10:34] <Daviey> hah
[11:21] <cjwatson> I've disabled precise daily builds in preparation for 12.04.2
[11:21] <cjwatson> infinity,plars: ^-
[11:26] <infinity> cjwatson: Shiny.
[12:03] <jamespage> xnox: thanks (and to *all for the general conversation - felt more difficult that is should have been)
[12:04] <xnox> jamespage: if we were in bdmurray timezone it should have been more simple =)
[12:30] <Riddell> ok I give up, how does xserver lts-quantal bits get on the precise CDs?  I don't see a seed change and I don't see it in the germinate output
[12:30] <Riddell> but it's there in the ubuntu desktop manifest
[12:31] <jamespage> xnox: indeed
[12:32] <infinity> Riddell: livecd-rootfs magic.  Is this about the alternate CD bug?  I'm going to fix that today.
[12:32] <infinity> Riddell: Or, at least, attempt to.  We'll see how it goes.
[12:33] <Riddell> infinity: I'm wondering what to do to get it on the kubuntu 12.04.2 candidate images
[12:33] <ogra_> btw, someone asked about documentation if you want to opt-in to the -lts package stack ... do we have any wikipage or so ?
[12:33] <infinity> Riddell: Oh, you didn't sign up for it earlier?  Indeed you didn't.
[12:34] <Riddell> ogra_: talking to me?
[12:34] <infinity> Riddell: ScottK may have opted out in earlier discussions.  Perhaps you two should quickly agree on that point before we go emergency SRUing livecd-rootfs.
[12:34] <infinity> ogra_: A wiki page for what?  For flavours, or users?
[12:34] <ogra_> Riddell, to the room, or anyone involved with the -lts stack
[12:35] <infinity> ogra_: Users can only opt in or out by either picking old/new install media, or manually changing packages.
[12:35] <ogra_> infinity, well, my 12.04 wont automatically upgrade to the -lts packages
[12:35] <infinity> ogra_: flavours were meant to opt in weeks ago, so we could make the right changes. :P
[12:35] <infinity> ogra_: No, upgrades won't.  And there's no reason they should.
[12:35] <ogra_> if i want the new stack, is there a meta or so i can install ?
[12:35] <infinity> ogra_: The whole point was hardware enablement.  If your hardware works, why upgrade the stack?
[12:35] <ogra_> because my steam games might run faster for example
[12:36] <ogra_> with newer driver and kernel
[12:36] <infinity> ogra_: You can install "xserver-xorg-lts-quantal linux-generic-lts-quantal" and you're there.
[12:36] <cjwatson> Riddell: sorry, you'll have to revert, there isn't time now to get the new stacks in
[12:36] <ogra_> infinity, rifght, *i* know that .... but there was someone asking of there is any documentation
[12:36] <Riddell> ok, c'est la vie
[12:36] <cjwatson> unless your images are broken without the new stacks
[12:36] <cjwatson> in which case an emergency SRU is probably possible ...
[12:37] <infinity> Given it's a straight cargo-cult from the other flavours, an emergency SRU is pretty low risk.
[12:37]  * ogra_ is just playing cassandra here
[12:37] <cjwatson> well
[12:37] <cjwatson> I guess I don't mind terribly, but do try to get all the pieces
[12:38] <cjwatson> which I don't think Riddell's seed commit did
[12:38] <cjwatson> ship-live: * linux-headers-generic-pae [i386] # Make sure we get the right headers
[12:38] <infinity> Riddell: Talk it over with ScottK.  If you both feel pretty strongly about it, we'll talk.
[12:38] <cjwatson> (that should probably be removed rather than substituted)
[12:38] <infinity> cjwatson: Where's that commit?
[12:38] <cjwatson> kubuntu.precise seeds
[12:38] <infinity> Or, derp.
[12:39] <infinity> But yes, headers shouldn't be there at all.
[12:39] <cjwatson> it needs at least also (a) livecd-rootfs SRU (b) extend the thing in debian-cd/CONF.sh that sets BACKPORT_KERNEL=quantal
[12:40] <infinity> Plus the bits I'm about to change for seeds/debian-cd love.
[12:40] <cjwatson> (c) lib/cdimage/livefs.py search for quantal
[12:40] <cjwatson> [generic vs. generic-pae]
[12:42] <cjwatson> and it will involve switching Kubuntu over to metapackages in livecd-rootfs at the last minute, which means you need to do a test build, compare the resulting package lists, and add hacks for anything that gets added that shouldn't have been added (i.e. what I did for Ubuntu and Edubuntu)
[12:43] <cjwatson> (the "libqt4-sql-sqlite notify-osd" bit)
[12:43] <cjwatson> and you arguably ought to avoid adding SB support at the same time since all this is complicated enough
[12:44] <cjwatson> there are enough moving parts - and I'm not absolutely certain I've remembered everything - that I really recommend against doing this at the last minute; it might be better to do a proper job, including SB, for .3?
[12:44] <cjwatson> infinity: the metapackage hacks are why this isn't a straight cargo-cult
[12:46] <infinity> cjwatson: Yeah, I agree it looks hairy as a last-minute thing.  Deferring to .3 is certainly less pressure.  Though, we should probably do it immediately post-.2, so no one forgets until the next last-minute.
[12:47] <cjwatson> ... for all flavours, consistently
[12:48] <cjwatson> (which probably means getting consent from everyone nowish - which is why I didn't do it originally, I think I asked some set of people and fixed things up for the ones who responded)
[12:48] <cjwatson> (and being in a tearing hurry)
[12:48] <Riddell> ok let's stick with the old stack for kubuntu 12.04.2
[12:49] <cjwatson> sorry, I know this is basically my screwup
[12:49] <Riddell> could someone respin the image to get rid of the linux change I made (I just reverted seed)
[12:50] <infinity> Riddell: Will do.
[14:05] <Riddell> infinity: new kubuntu 12.04.2 candidates on their way?
[14:08] <infinity> Riddell: Yeah, I just need to hit enter in this terminal.  Wanted to make sure the world settled.
[14:08] <infinity> Riddell: Building now.
[14:08] <Riddell> thanks
[14:19]  * ScottK didn't opt out of anything.
[14:20] <infinity> ScottK: No, you may have just failed to opt in.  I could have sworn you were around and speaking up about it when we were discussing it in the channel with other flavours, but maybe not. :/
[14:20] <ScottK> Not that I recall.
[14:20] <infinity> ScottK: The backport stack stuff was all rather haphazardly organised, I'm afraid.
[14:20] <infinity> For .3, we should just make sure both the backport stack and SB is just universally enabled and be done with it.
[14:21] <infinity> (And soon after .2, so new dailies DTRT)
[14:22] <ScottK> Makes sense.
[15:14] <plars> cjwatson: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1122072 seems to be a regression for 12.04.1
[15:14] <ubot2> Ubuntu bug 1122072 in xorg (Ubuntu) "[Precise amd64 on VirtualBox] "Fatal server error: no screen found" in Xorg.0.log" [Undecided,Confirmed]
[15:23] <plars> cjwatson: alternate images seem to be oversized at the moment?
[15:29] <infinity> plars: Alternate images are being worked on for other reasons, we'll see where we end up.
[15:30] <plars> infinity: what else is being worked on with them?
[15:31] <infinity> plars: Making them use the enablement stack...
[15:54] <bdmurray> jamespage: We are still using the spreadsheet but are planning on moving away from it
[15:55] <infinity> bdmurray: Planning to move to what, out of curiosity?
[15:55] <ogra_> a more shiny spreadsheed with colors
[15:55] <ogra_> :P
[15:56] <bdmurray> infinity: launchpad team subscriptions to packages
[15:57] <infinity> bdmurray: Ahh, good, exactly what I suggested above.
[15:57] <infinity> bdmurray: I appreciate when people have the same idea as me, spares a whole lot of time trying to convince them they're wrong.  *nod*
[15:58] <bdmurray> infinity: Well, I'm certain you heard me talk about on the train in Copenhagen and that it was my idea first. ;-)
[15:58] <jamespage> bdmurray: can i review/get that spreadsheet updated please?
[15:58] <infinity> bdmurray: Crazy talk.  That implies I listen to other people.
[16:00] <bdmurray> jamespage: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AhTVBLlLWapNdHRpM2QyRGQ5NGFzZmF3ODNpZ2E3d1E&authkey=CJzt1xo#gid=0
[16:02] <infinity> bdmurray: Not public readable?  Classy. :)
[16:06] <rtg__> infinity, what do you suggest for libaudit-dev in Precise with regard to the Raring LTS kernel ? just don't build perf ?
[16:10] <infinity> rtg__: Yeah.
[16:10] <rtg__> my thoughts exactly
[16:10] <infinity> rtg__: Unless you want to go to the hassle of tearing out whatever bits of perf reference libaudit.
[16:11] <rtg__> ick
[16:11] <rtg__> guess I could take a look
[16:13] <infinity> rtg__: Probably not worth the effort unless it's a dead simple case of removing the header include and a few function calls.
[16:13] <rtg__> infinity, maybe NO_LIBAUDIT in the Makefile will help. I'll keep digging
[16:14] <infinity> linux-tools so needs to grow a proper configure.
[16:15] <infinity> Actually, wait, I thought it had one?
[16:15] <infinity> It spews bits about disabling things if GTK isn't there, etc.
[16:15] <infinity> So, maybe the configure just needs to be smarter about audit. :P
[16:15] <infinity> Or, we could just not care.
[16:15] <rtg__> I'm leaning that direction.
[16:16] <infinity> rtg__: perf is a pretty awesomely useful debugging tool, but I suppose it's more interesting in an active development release than an LTS.  Maybe.
[16:17] <rtg__> infinity, I know cking has used it on older releases for a variety of profiling researches
[16:21] <infinity> rtg__: There's you answer.  Punt to cking.  If he cares, he'll fix it to build without audit and submit the patch upstream. ;)
[16:21] <rtg__> infinity, yeah, he'll punt it back to me.
[17:49] <antarus> infinity: do you have the src for that kernel pruner thing we talked about on Friday?
[17:50] <infinity> antarus: I'll upload it today and point you at it.
[17:50] <infinity> antarus: (Or you could check raring, but if you're looking for it backported to precise, no point doing the work twice)
[18:02] <antarus> infinity: whats the pkg name in raring?
[18:03] <infinity> antarus: apt.  You've probably heard of it.
[18:04] <antarus> heh
[18:04] <antarus> I'll poke at it then ;0
[18:04] <infinity> Heh.  I'll backport the relevant commits this afternoon.
[18:18] <antarus> infinity: is there a launchpad bug for the backport?
[18:19] <infinity> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/923876
[18:19] <ubot2> Ubuntu bug 923876 in apt (Ubuntu Quantal) "FR: Limit and clean-up kernel images and headers automatically in LTS" [High,New]
[18:20]  * infinity sets that to In Progress, and gets progressing on it.
[18:22] <antarus> thx
[20:27] <balloons> It's been mentioned there's no upgrade test for 12.04.2 -- is this intentional? Did we simply not include it in the rollout?
[20:28] <stgraber> those need to be manually added as they're not pushed by nusakan
[20:30] <balloons> stgraber, ohh.. I do remember that now
[20:30] <balloons> ok,  I was holding off because I thought there was a reason
[20:31]  * balloons goes to add
[20:32] <stgraber> balloons: for dailies I have a script bumping the version every week, but I'm not doing that for milestones
[20:32] <balloons> hmm.. precise stll has the legacy stuff on it
[20:33] <balloons> that makes it tricky too
[20:34] <balloons> ohh ugh
[20:35] <balloons> how did I not notice these were all linking to the old legacy testcases
[20:38] <balloons> stgraber, well, since we're already chatting in here.. If I change and update the testcase links for everything, we re-write history and lose all of our old results, right?
[20:38] <stgraber> yep, precise doesn't have the shiny new testcases
[20:38] <balloons> but if we don't change the, we're stuck using the old stuff
[20:38] <balloons> which actually has broken testcases at this point?
[20:39] <stgraber> balloons: I haven't looked at the code in a while but I "think" accessing archived records should be fine even if you change the testsuites/testcases for precise
[20:39] <stgraber> might be worth testing with just a product to check though
[20:39] <stgraber> I don't keep an explicit history for those but results are linked to build and testcase
[20:39] <balloons> stgraber, well, if possible, we should get precise updated to the new stuff
[20:40] <balloons> I remember we avoided converting for simplicty
[20:40] <stgraber> so if I did it correctly, accessing an older build should still show you the old testcases and results
[20:40] <balloons> but since precise is going to keep coming up..
[20:40] <stgraber> balloons: can you convert let's say, Edubuntu amd64 and then let me know so I can check?
[20:40] <stgraber> balloons: I happen to know the testcaseid for Edubuntu by heart so if it ends up messing the history I can easily revert
[20:40] <balloons> stgraber, yes, I'll do that.. I'll remove the legacy links and put in the proper ones
[20:42] <stgraber> balloons: ok, let me know when you're done
[20:44] <balloons> stgraber, k, done
[20:44] <balloons> mm.. we lost today's results ofc
[20:44] <stgraber> balloons: alright, let me take a look at the history
[20:45] <stgraber> balloons: history's broken. Let me poke at it for a bit see if we can get that working with some configuration
[20:50] <stgraber> balloons: ok, that doesn't work :( I thought I had written some code to detect cases where we had results for testcases and testsuites not currently linked to a product, but apparently I either didn't do that or the code is broken
[20:51] <balloons> hmm.. well, so where does that leave us?.
[20:54] <stgraber> nowhere particularly good, we don't have enough time for me to fix the code and land it and if we simply go ahead with swapping the testsuites and then land the fix post-release, it means we won't be able to access the results from any of the dailies which may be relevant
[21:04] <balloons> stgraber, right.. so, I guess we continue as-is then.. I wonder if I can even change the upgrade tests
[21:04] <balloons> I guess not
[21:08] <stgraber> probably not and they'd end up being wrong if you did as they need extra testcases for LTS-to-LTS
[21:11] <balloons> well, as you ca see I simply turned on the existing upgrade builds, with the old testcases
[21:11] <balloons> thanks stgraber
[21:16] <balloons> stgraber, ohh.. since this will come up again, can we at least note it in the bug tracker.. whenever you have time to open and proper bug with description.. I'd prefer you to do it since you can describe the technical limitations better
[21:26] <stgraber> balloons: yep, I'll file a bug and get that fixed soon
[22:39] <knome> release team (ping micahg_): the xubuntu team wishes to move to a 1GB image; do you need something from us or will you process?
[22:41] <stgraber> it's actually a ping for the cdimage team :)
[22:41] <stgraber> but yeah, I can bump the limit for you
[22:42] <infinity> I was already there.
[22:42] <stgraber> infinity: if you remember where it's, go ahead ;)
[22:43] <stgraber> infinity: I vaguely remember cjwatson moving those bits to python so I was preparing to do some grepping around
[22:44] <infinity> stgraber: Already done.
[22:45] <infinity> knome: ^
[22:45] <knome> infinity, cheers!
[22:46] <knome> and thanks for stgraber too ;)
[22:48]  * ogra_ doesnt get why the nexus7 build failed
[22:48] <ogra_> the log doesnt show any errors
[22:48] <ogra_> yet i got a failure mail
[22:48] <infinity> ogra_: When?
[22:49] <ogra_> 1.5h ago
[22:49] <ogra_> which is weird, the build should have finished several hours ago
[22:49] <ogra_> (it starts at 13:30 UTC or so)
[22:49] <infinity> ogra_: I'm fiddling with some things, let me try again.
[22:49] <ogra_> oh, err
[22:50] <ogra_> thatt mail was from the 10th
[22:50] <ogra_> LiveFS ubuntu-nexus7/raring/armhf+nexus7 failed to build on 20130210
[22:50] <infinity> Oh, that was probably when the world was half exploded.
[22:50] <ogra_> seems todays worked
[22:50] <infinity> Anyhow, testing things now.
[22:50] <infinity> Today's would have been on cadejo, the one I'm doing now will be on celbalrai.
[22:51] <ogra_> still strange that nusakan held back the mail for 24h
[22:52] <ogra_> hmm, evolution, the chromebook and livefs build logs go better together than my high end x86 desktop
[22:52] <ogra_> (on my desktop evo crashes if i scroll to fast)
[22:55] <antarus> chromebook++
[22:55] <ogra_> yeah
[22:56] <ogra_> its soo ugly, but works so well :)
[22:57] <ogra_> (and properly working flash on ubuntu-arm is actually priceless)
[23:25] <plars> sorry for the vagueness in this bug, but https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1122525 is blocking from testing ltsp on alternate. Also, shouldn't precise alternate images have apport in them? ubuntu-bug and apport don't seem to work there but it looks like it did at one time.
[23:25] <ubot2> Ubuntu bug 1122525 in ltsp (Ubuntu) " ltsp-build-client build ltsp chroot failed : Unable to locate package linux-image-generic" [Undecided,New]
[23:26] <plars> it's virtually identical to an older bug that was fixed by stgraber, so hopefully the breakage should be clear
[23:27] <plars> infinity: or is this related to the problem you mentioned earlier?
[23:34] <infinity> plars: The ltsp bug is related to the lts backport stack, but not the thing I was fixing. :/
[23:34] <infinity> stgraber: ^
[23:35] <plars> infinity: I'll cc him on the bug
[23:35] <infinity> stgraber: Looks like ltsp in .2 wants to be installing the lts-quantal kernel instead of -generic, if it's relying on the CD for its packages...
[23:37] <stgraber> infinity: hmm, yeah, I should have thought of that... we have logic to figure out the right kernel in there which needs updating
[23:38] <infinity> stgraber: Please with the emergency SRU? :)
[23:39] <stgraber> infinity: yep. Busy with other things tonight but will try anyway, worst case will have something first thing tomorrow
[23:41] <infinity> stgraber: Kay.  I'm airplaney tomorrow, but I'm sure you can convince someone else of the urgency and get it in. :)
[23:41] <stgraber> infinity: yeah, hopefully the change will be very simple and very readable. I'll do any necessary nagging to get it in once it's all tested.
[23:52] <skaet> stgraber, ScottK,  I just noticed there's a new kernel for raring 3.8.0-6.11 in -proposed.   Was it discussed with Edubuntu or Kubuntu teams during this alpha 2?
[23:54] <skaet> slangasek,  does it make sense to turn off the autobuilds now for raring edubuntu and kubuntu - until the alpha 2 is out the door.
[23:54] <skaet> ?
[23:55] <skaet> smoser,  any thoughts on whether you want to pick up the new kernel or not for your Alpha2 images?
[23:56] <infinity> I can block the migration if anyone cares deeply, but it should be fine.
[23:56] <stgraber> skaet: well, d-i has been uploaded so it's too late to avoid it but I don't really care
[23:57] <infinity> No one's asked for a freeze or anything.
[23:57] <stgraber> I think I looked at the changelog and nothing looked scary
[23:57] <slangasek> skaet: I'm assuming that someone from edubuntu and kubuntu will tell me when they want autobuilds disabled for testing purposes


[13:30] <meena> aciba: when are ye back to work?
[14:19] <meena> falcojr: I'm taking one of my PRs getting merged means: about now
[14:21] <minimal> FYI this proposed dhcpcd change may be relevant to cloud-init: https://github.com/NetworkConfiguration/dhcpcd/discussions/271
[15:04] <falcojr> thanks for the link!
[15:55] <meena> holmanb: i would've just banned this account https://github.com/canonical/cloud-init/pull/4720#issuecomment-1874176078
[15:55] -ubottu:#cloud-init- Pull 4720 in canonical/cloud-init "proposed commit message because PRs are squash merged by default." [Closed]
[15:56] <meena> Also this one https://github.com/canonical/cloud-init/issues/4712
[15:56] -ubottu:#cloud-init- Issue 4712 in canonical/cloud-init "[docs]:" [Closed]
[16:00] <minimal> falcojr: re that growpart Issue, I never understood why cc_growpart added the key stuff as I've resized LUKS partitions without it (via bootcmds, not via cc_growpart) and now I've sort-of figured it out
[16:01] <minimal> for LUKS *v1* "cryptsetup resize" does NOT need any keys for a LUKS that is already unlocked (i.e. the one containing the rootfs or whatever filesystem you want to grow)
[16:02] <minimal> for LUKS *v2* however I do see that "cryptsetup resize" of an unlocked LUKS *does* prompt for passphrase, I haven't yet figured out why
[16:03] <minimal> I'm currently working on a cc_growpart PR to cater for this
[16:04] <falcojr> yeah, I'm no luks experience. I was more leaning on the expertise of others for that one
[16:04] <falcojr> *expert
[16:05] <minimal> for locally I've modified cc_growpart to not require a key for rootfs and tested - works as expected for rootfs on LUKSv1, however doesn't for rootfs on LUKSv2 (as expected, "cryptsetup resize" is blocking waiting for passphrase input
[16:07] <minimal> I'm hoping to shortly raise an PR to address issues with cc_growpart's handling of LUKS and LVM (as I finally came up with a code change to fix an Alpine-related issue that let's me test this now)
[17:21] <holmanb> meena and minimal: we're back today - nice to see you o/
[17:21] <holmanb> meena: no perms to ban in github I don't think
[17:24] <holmanb> meena: thanks for the link on the dhcpcd stuff - I've been tracking the dhcpcd conversation, didn't want to jump into it yet because I didn't have time to over the break
[17:24] <minimal> holmanb: that was me ;-)
[17:24] <holmanb> bleh
[17:24] <holmanb> sorry minimal
[17:24] <minimal> you still on the Egg Nog? lol
[17:24] <holmanb> heh
[17:24] <holmanb> don't like the nog unfortunately
[17:25] <holmanb> just trying to skim through a backlog
[17:26] <holmanb> minimal: Roy is aware that Ubuntu's initramfs-tools is using dhcpcd in the same way that cloud-init likely will, and offered to keep around at least one flag that he was going to remove[1], so I think we're in the clear as long as we make our use case clear
[17:26] <holmanb> [1] https://github.com/NetworkConfiguration/dhcpcd/issues/276#issuecomment-1872556229
[17:26] -ubottu:#cloud-init- Issue 276 in NetworkConfiguration/dhcpcd "Waiting for carrier blocks timeout" [Open]
[17:28] <holmanb> minimal: but the line in the discussion you linked "dhcpcd-11 will require starting as a service in the same way as..." makes me nervous, so I'll need to follow up on that
[17:29] <minimal> yeah that was one of the things that jumped out at me too
[17:31] <minimal> perhaps you need to mention to him the c-i ephemeral scenario
[17:35] <holmanb> minimal: planning on it - I wanted to grok what manager mode even is before continuing the conversation
[17:35] <meena> holmanb: got time for https://github.com/canonical/cloud-init/pull/4677 ? I wanna get that fixed, and the OpenBSD port submitted
[17:35] -ubottu:#cloud-init- Pull 4677 in canonical/cloud-init "fix(runpath): On *BSD, create /run is not ephemeral" [Open]
[17:36] <holmanb> meena: I'll try to get to it today
[17:38] <minimal> holmanb: normally there are multiple dhcpcd processes running, Manager mode appears to replace this with a single process
[17:41] <minimal> e.g. on the Alpine VM I have in front of me there are the following dhcpcd processes running: "dhcpcd: eth0 [ip4] [ip6}", "dhcpcd: [privileged proxy] eth0 [ip4] [ip6]", "dhcpcd: [network proxy] eth0 [ip4] [ip6]", "dhcpcd: [BPP ARP] eth0 a.b.c.d", "dhcpcd: [DHCP6 proxy] aabb:ccdd:eeff:gghh:iijj", "dhcpcd: [BOOT proxy] a.b.c.d"
[17:41] <minimal> that's 7 dhcpcd processes
[18:57] <holmanb> minimal: https://github.com/NetworkConfiguration/dhcpcd/discussions/271#discussioncomment-7996089
[19:07] <minimal> thanks
[19:08] <holmanb> I also pinged the canonical dev internally who worked on the initramfs stuff to loop them into the conversation
[19:15] <minimal> falconjr: BTW I think I see why there's a difference in LUKSv1 vs LUKSv2 behaviour: "Starting with cryptsetup 2.0 we load VK in kernel keyring by default for LUKSv2 devices (when dm-crypt with the feature is available)."
[19:15] <minimal> from: https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/docs/Keyring.txt


[00:00] <roaksoax> jay___: so you can configure /etc/maas/rackd.conf instead of localhost put the IP address of itself on the internal network
[00:00] <jay___> I see
[00:01] <jay___> change maas_url: http://localhost:5240/MAAS into http://myip:54220/maas
[00:01] <roaksoax> http://<your-local-ip-that-machines-can-access-to>:5240/MAAS
[00:01] <jay___> * http://myip:5240/MAAS
[00:01] <roaksoax> indeed
[00:01] <jay___> thx a lot
[00:02] <roaksoax> jay___: btw.. what's the version of maas you using ?
[00:02] <jay___> 2.3 maybe
[00:03] <jay___> yes, 2.3
[00:03] <jay___> MAAS version: 2.3.0 (6434-gd354690-0ubuntu1~16.04.1)
[00:07] <roaksoax> jay___: when rackd.conf is localhost, maas should try to autodetect that so you wouldnt' have to configure rackd.conf
[00:07] <roaksoax> but we fixed a bug related to that and will be in 2.3.1
[00:08] <jay___> thx again, that would be so helpful for beginners like me
[00:10] <jay___> instead of shutdown, I am getting cloud-init [1166]: + sleep in 10
[00:17] <jay___> @roaksoax still up?
[00:23] <jay___> roaksoax: still up?
[00:34] <jay___> roaksoax: one suggestion though: It shuts down too fast at failures. maybe there should be a error page and shutdown after 30s or anykey
[04:21] <mup> Bug # changed: 1712678, 1730955, 1731009, 1734077


[21:31] <hades08> hi
[21:31] <hades08> how to put apparmor in complain mode under ubuntu-core / snappy ? apparmor_parser -C ?
[21:35] <hades08> im trying to enable /dev/ppp in a lxd container but it doesnt work , anyone could help plz ?
[21:46] <hades08> ubuntu-core-launcher not working neither
[21:46] <hades08> could someone give me a hint about how to put apparmor in complain mode with ubuntu-core ? :P


[12:05] <tjaalton> infinity: I've started pushing lts-xenial stuff to the queue, libdrm first and llvm-3.8 will be next
[13:11] <tjaalton> infinity: so should we bump libxrandr to 1.5.0 in trusty?
[13:29] <tjaalton> other deps needed too, x11proto-core and x11proto-randr of course
[14:46] <infinity> tjaalton: -ENOTENOUGHINFO
[14:46] <infinity> tjaalton: Why would we need a newer xrandr?
[14:48] <yofel> regarding kde-l10n in xenial unapproved, scarlett got the version wrong, but as these are just translations the packaging version doesn't matter that much, so would those be ok to be accepted anyway?
[14:48] <yofel> If not it would be nice if someone could reject them so we can upload another set
[14:52] <tjaalton> infinity: xserver
[14:52] <tjaalton> 1.18
[14:52] <tjaalton> and llvm-3.8 doesn't build
[14:53] <tjaalton> some files missing, weird
[15:08] <apw> yofel, you can just upload over the top as the version in the queue does not count
[15:09] <yofel> apw: oh, so the last upload always overwrites what's in unapproved?
[15:10] <apw> yofel, strictly both will end up in the queue, and if you go that route we can reject the older wrong one
[15:10] <yofel> aaaah, right. Good idea, thanks
[15:12] <apw> yofel, my personal oppinion is if its easy to fix the version so it is right, there is less confusion to be had there, but i have no idea how much work that is
[17:30] <tjaalton> infinity: llvm-3.8 fails to build on arm64 because of an "internal compiler error".. others seem happy now
[19:03] <infinity> tjaalton: Fun.
[20:52] <bdmurray> infinity: Is there a point release schedule for 16.04 yet?
[21:28] <infinity> bdmurray: Yes.
[23:11]  * lamont belives that switching from python2 to python3 is SRU-worthy, yes?
[23:11] <lamont> (specifically bind9/xenial)
[23:11] <lamont> (from the "IT DEPENDS ON WHAT!@!!" department)
[23:14] <Kamilion> ?
[23:14] <Kamilion> my interest is piqued and I do not know of this issue. Tell me more.
[23:15] <lamont> bind9utils et al Depend: python, python-argparse
[23:15] <lamont> because of oh yeah, they do
[23:15] <Kamilion> and works fine with python3, python3-argparse?
[23:15] <lamont> no python3-argparse, it was part of python stdlib by 2.7
[23:16] <Kamilion> thought that was optparse
[23:16]  * Kamilion shrugs, I'm often wrong though. :D
[23:16] <lamont> seems to like python3 just fine, I'm doing a test build, and then looking at uypstream history, but they seem to believe in python3
[23:16] <lamont> --with-python=python3
[23:16] <Kamilion> ah, optparse was the old 2, argparse is the new stdlib hotness. gotcha.
[23:20] <Kamilion> seems to pass the quick eyeball-sanity test for me, being a pythony-person, but I took a look at https://source.isc.org/cgi-bin/gitweb.cgi/?p=bind9.git;a=shortlog and see a few python2/3 related patches as of 3-4 days ago.
[23:21] <lamont>     [v9_10] minor python3 portability fix
[23:22] <lamont> I'm gonna go with "yep, they believe in python3"
[23:24] <Kamilion> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=470af54b4ec7ab38ad10a5bd22a0a20664838c99;hp=304d16f08fd7373dd61a43561fe6400ddda3f46f
[23:24] <Kamilion> yeah, looks very minor
[23:29] <Kamilion> considering it's not really too hard to write python that works in 2.7 and 3.3-3.5 if you're careful about insisting on unicode everywhere and using the u'' and .format constructs
[23:30] <Kamilion> maybe it was 3.2 that brought u'' back, I don't recall. I do know that 3.0 and 3.1 lacked it.
[23:51] <cjwatson> Kamilion: don't even need .format
[23:52] <Kamilion> I don't like the % syntax personally
[23:52] <cjwatson> I mildly prefer it but whatever; python3 is happy with either
[23:52] <cjwatson> 3.3 was the one that reintroduced u'' - https://docs.python.org/3/whatsnew/3.3.html
[23:52] <Kamilion> yep. u'this is {}'.format(thing) works really well for me.
[23:53] <Kamilion> thing can even be ascii, and it does the right thing.
[23:53] <cjwatson> yep.  ditto %
[23:54] <lamont> I'll be tossing -10 at sid, and then -8ubuntu2 at xenial-proposed "sometime after yakkety has -10"


[02:46] <liam> whats the difference between the .pem key you get with your instance to the access keys, X.509 certs and key pairs that are in your account access credentials page in aws?
[02:49] <liam> does anyone know if you do the api tools steps outlined here https://help.ubuntu.com/community/EC2StartersGuide that you can ssh in to your ec2 instance with having to use the command "-i key.pem" ??
[02:49] <flaccid> liam: http://docs.amazonwebservices.com/AWSSecurityCredentials/1.0/AboutAWSCredentials.html
[02:50] <flaccid> liam: no, a private key is required by default with images
[02:50] <flaccid> you might like to add the private key to your client ssh
[02:50] <liam> the private key is the .pem right?
[02:50] <flaccid> i would assume so
[02:51] <liam> flaccid: I still cant find how to add it to the ssh client...
[02:51] <flaccid> rtfm
[02:51] <liam> is it just ssh add key.pem??
[03:00] <erichammond> liam: Instead of having Amazon generate an ssh key, you can simply upload your default to avoid needing "-i"
[03:00] <erichammond> liam: I wrote about it here: http://alestic.com/2010/10/ec2-ssh-keys
[03:01] <liam> erichammond: thank you.
[03:01] <erichammond> This is my recommended way of working with EC2 now.  There's no need to have Amazon generate ssh keys any more.
[03:01] <flaccid> sorry that i am short today. gotta do a release in 2 hours
[03:02] <erichammond> flaccid: I often say nothing to avoid saying nothing nice :)
[03:02] <flaccid> true
[03:06] <erichammond> #ubuntu-* channels have higher standards: https://wiki.ubuntu.com/IRC/Guidelines
[03:06] <erichammond> It's one of the things that drew me to Ubuntu
[03:07] <erichammond> besides the fact that it just worked better and didn't break when upgrading.
[03:07] <flaccid> lol
[03:07] <flaccid> i wasted 3 years with ubuntu, i aint going back
[03:08] <erichammond> and the software packages were more recent versions
[03:08] <erichammond> and...
[03:08] <flaccid> i have much higher standards than ubuntu
[09:54] <progre55> hi guys. Is there a way to re-register (deregister - register) walrus without losing any of the already uploaded images, kernels, etc?
[10:30] <TeTeT> progre55: never tried that, but I don't think that this is possible :(
[10:31] <progre55> TeTeT: I've managed to change it, from the admin web ui, but still, when I say "euca-describe-images" I get "no route to host" after some time..
[10:33] <progre55> TeTeT: Oh, I havent changed the environment variables after I changed the IP address =)
[10:33] <TeTeT> progre55: you probably need to d/l new credentials from the admin interface
[10:34] <progre55> TeTeT: it's working now, after I changed the EC2_URL env. variable to the correct one =)
[10:34] <progre55> thanks
[10:35] <TeTeT> progre55: was merely reading, didn't do anything
[10:36] <progre55> TeTeT: but still, it's nice to know that there are people trying to help you =)
[10:37] <TeTeT> :)
[10:46] <progre55> TeTeT: a question, if I may =)
[10:47] <progre55> I have downloaded one of my images using "euca-download-image" and it's a bunch of 10Mb files with a manifest. how can I convert it to a single image file now?
[10:49] <progre55> oops, i.e. euca-download-bundle
[10:52] <progre55> oh, euca-unbundle, I guess
[10:54] <TeTeT> progre55: yes, euca-unbundle
[10:54] <progre55> TeTeT: thanks =)
[10:58] <TritoLux> hi there, just out of curiosity.. is UEC the only distribution able to make use the POWERSAVE option?
[11:00] <TritoLux> make use OF the..
[11:58] <gijo> what is the parameter port in boto.connect_ec2()
[12:16] <TeTeT> gijo: probably 8773
[12:17] <TeTeT> gijo: for UEC that is, don't know for Amazon EC2
[12:18] <gijo> thx
[12:32] <TritoLux> that you know of, is UEC the only distribution able to make use of the POWERSAVE option? since I get powernap error 255 out of the box, is there anything I need to change in the default config to make it work in maverick? is apparmor aware of powernap policies?
[16:01] <samuel> hey all
[16:17] <kim0> samuel: hey
[21:15] <TritoLux> is UEC the only distribution able to make use of the POWERSAVE option? since I get powernap error 255 out of the box, is there anything I need to change in the default config to make it work in maverick? is apparmor aware of powernap policies?
[21:25] <mathiaz> smoser: hi!
[21:25] <mathiaz> smoser: do you know if someone looked at hosting an apt repository in S3?
[21:26] <mathiaz> smoser: given that S3 is accessible via http and that apt uses http to download files, I wonder if an apt repository could be hosted in S3?
[21:27] <smoser> i had read something about this at one point
[21:27] <smoser> iirc there was some issue with it, vut i don't really recall what. i only went as far as seing someone say they had issues...
[21:27] <smoser> but don't let that stop you from trying
[21:28] <smoser> https://github.com/kyleshank/apt-s3 might have more info
[21:28] <smoser> hm.. htat seems to do authetnticated s3... so maybe unautghed s3 "just works"
[23:08] <erichammond> mathiaz: I think S3 should be fine for an apt repository as long as you can get the files uploaded in a timely manner and detect which files need to be updated on each refresh (following the correct order).
[23:09] <erichammond> mathiaz: I tried a couple years ago using s3fs (and rsync?).  I gave it up because my initial upload was taking forever and RightScale (then Canonical) started mirroring Ubuntu repositories on EC2 instances.
[23:15] <mathiaz> erichammond: right
[23:15] <mathiaz> erichammond: I'm looking at hosting my own packages as part of the infrastructure
[23:15] <mathiaz> erichammond: and I would also need private access to S3
[23:15] <mathiaz> erichammond: as some of the packages may include private data
[23:16] <mathiaz> erichammond: for a public repository I think that a normal apt repo can just be mirrored to an S3 bucket
[23:16] <mathiaz> erichammond: if file names in the Packages.gz files are relative
[23:16] <mathiaz> erichammond: it should even be possible to mirror a pool/ dists/ layout in S3?
[23:16] <mathiaz> erichammond: if S3 supports sub-directories
[23:18] <erichammond> mathiaz: S3 supports "keys" where the key can include slashes.  This means that you can emulate subdirectories as far as HTTP goes, and many tools like s3fs and web UIs also present a subdirectory paradigm.
[23:18] <mathiaz> erichammond: that's great - so it should possible to host a public apt repository in S3 follow the same structure as a local repo
[23:19] <erichammond> mathiaz: I believe so, yes.
[23:19] <mathiaz> erichammond: however providing a private repo in S3 may be a bit more complicated
[23:19] <erichammond> It won't auto-generate subdirectory listings or replace /dir/ with /dir/index.html, but I don't think apt repositories require those.
[23:19] <mathiaz> erichammond: correct - apt doesn't require those
[23:20] <erichammond> mathiaz: Using the HTTP(S) protocol, the only way you could get private would be to pick a very long, random bucket name and always use SSL.
[23:20] <erichammond> The bucket name would effectively be your password.
[23:24] <erichammond> Not a highly recommended approach, but I toss it out for consideration as it may work for some situations.
[23:25] <mathiaz> erichammond: right - smoser pointed out an apt method that supports authentication
[23:25] <mathiaz> erichammond: using an access id and a secret key
[23:25] <erichammond> mathiaz: Yep, I saw that when it came out (2008) but haven't tried it.


[22:20] <OvenWerks> Eickmeyer: I don't have access to all the mail lists you guys sent that to. So my messages are only sent to our list and Steve. If you feel the content is worth sharing beyond that, feel free to copy/paste to other lists as well.
[22:20] <Eickmeyer> OvenWerks: Ok. Yeah, Steve is the one that's going to do the change on that, so he's the guy.
[22:22] <Eickmeyer> You can always subscribe to ubuntu-devel@ and ubuntu-release@ if you want to be able to post without moderation.
[22:22] <OvenWerks> Eickmeyer: is there no way to get FF as a deb?
[22:22] <Eickmeyer> Nope, the deb is merely a transitional package now.
[22:22] <Eickmeyer> This was Mozilla's call as part of renewing the distribution agreement.
[22:22] <OvenWerks> Eickmeyer: so if I send mail there it will be held not just bounced?
[22:23] <Eickmeyer> Right, should be held, not bounced.
[22:23] <OvenWerks> ok, I didn't bother sending to any list I wasn't a member of.
[22:23] <Eickmeyer> Yeah, don't worry about it. It went to the right people.
[22:23]  * OvenWerks wonders how long till snap is dropped in favour of flatpack
[22:24] <OvenWerks> well you got it anyway :)
[22:25] <Eickmeyer> RE: Flatpak: Not likely. One of Steve's biggest objections is that flatpak installs with authentication *per repo* as opposed to per package, causing some weird security implications.
[22:25] <Eickmeyer> So, once you authorize a repo, you can install from that repo without entering a password ad infinitum.
[22:25] <OvenWerks> has snap entered the redhat relm?
[22:26] <Eickmeyer> Snaps can be installed on fedora and rhel, yes.
[22:31] <OvenWerks> Eickmeyer: my understanding is that a USB stick is seen as another drive and can boot with whatever FS it happens to sport as if it was another "hard drive" since quite a long time, is that correct?
[22:31] <Eickmeyer> Yes, that's correct, depending on the BIOS.
[22:32] <Eickmeyer> Most modern machines can.
[22:32] <OvenWerks> I am thinking bios in 64bit systems... but then I guess there may be older amd64 bios that do not.
[22:34] <OvenWerks> I know my 15? year old 32 bit system is picky
[22:38] <OvenWerks> Speaking of my old 32bit laptop... I have an old RPi (2 something) which is 32bit as well that does a better job of redering YT videos that the laptop.
[23:01] <Eickmeyer[m]> Oh, that's cool.


 well
 I just hosed my screen resolution intalling a new nvidia
 drfiver
 I forgot how to get the second display running and proper screen config xD
 nvidia-settings
 It doesn't seem to run, I'm going to try running the .deb this time
 Are you using noveau?
 or prop?
 I don't know, I'm on 18.04
 Oh, fresh ubuntu?
 I'd guess it's probably noveau
 well sorta fresh
 would explain it
 How do I get around that?
 you'd have to go grab the nvidia release
 installing nvidia drivers should do it
 iiiiiiiiii'd guess there's a PPA for it
 maaaayyybe it's in the repos? (does ubuntu care about non-foss?)
 I downloaded and chmodded and ran, I even had it init 3
 running straight from the nvidia website caused issues for me some years ago
 lsmod see if novuea is up?
 is it named noveau?
 nvidia_modeset       1036288  1 nvidia_drm … nvidia              17276928  2 nvidia_uvm,nvidia_modeset … drm_kms_helper        172032  1 nvidia_drm
 I seemed to have installed nvidia
 but my screens are stuck at single monitor with 1024x768
 whatttt
 yea, think it's actually named noveau in lsmod
 so you have some kinda nvidia in there lol
 no errs on nvidia-settings?
 You could just go grab arandr or something
 not sure what ubuntu installs be default
 it's a front end for.. xrandr
 Until you resolve the nvidia software issues
 if ubuntu doesn't have arandr, there's lxrandr also
 Mainly have to install the nvidia issue, I'm trying to get tensorflow running
 but if you have ubuntu, these sorts of w/e randr options should be in your display settings
 hm..
 xrandr --listmonitors
 gets you something like:  0: +DP-2 1920/698x1080/393+0+0  DP-2
 identifier DP-2 is one of my displays
 can manage like: xrandr --output DP-2 --mode 1920x1080
 If you have more than one display, you can specify on the same line
 the layout for my 2 (1 vert, 1 horiz)
 xrandr --output DVI-D-1 --off --output HDMI-1 --off --output DP-2 --primary --mode 1920x1080 --rate 144 --pos 1080x736 --rotate normal --output DP-1 --off --output HDMI-2 --mode 1920x1080 --pos 0x0 --rotate right
 @Abrerr, ^^ But this should do it
 Obv swap out DP-2 with w/e your display is
 I have it working again thank you, I had to use some of the ubuntu based controls x_x
 ubuntu-devices and apt-get install nvidia-driver-415
 I think installing tensorflow is going to be the pain point tonight
 er, cuda and cudnn
 @KMyers !!!
 10 Operating Systems You Can Run on Raspberry Pi in 2019 … https://www.fossmint.com/operating-systems-for-raspberry-pi/
 What is the plan for Tomorrow @Ivoriesablaze / @RazPi
 You been Sunday?
 You know what..  I need coffee before I try to think
 @KMyers  Do you remember the name of  that all you can sushi buffet in Pembroke Pines?
 @SivaMachina, They changed their name a few weeks ago.
 Do you know what to?
 On the phone with @Panzer_III and he thinks it is Noni
 Nori Tori
 @KMyers, Gesundtite
 @Panzer_III  @KMyers  thank you for the help
 @KMyers, I'm up for anything
 Could make it a coffee shop project day
 I like coffee
 https://wsvn.com/news/local/pilot-dead-after-plane-crashes-into-building-near-fort-lauderdale-beach/
 All I can think of is Edna saying "no capes"
 Doesn't have the FI or Tail listed
 if it's ADSB I'd like to know where and how fast it was
 @KMyers Good call on that printer. It arrived today and I struggeled for 30 minutes to get it installed on my Work laptop to no avail. Rolled over to my Ubuntu desktop and pulled up the printer app .... IT WAS ALREADT LISTED AND INSTALLED. HA!
 too funny
 @EZRA1964, Glad to hear it is working


[04:40] -queuebot:#ubuntu-release- New binary: avahi [s390x] (bionic-proposed/main) [0.7-3ubuntu1] (core)
[04:41] -queuebot:#ubuntu-release- New binary: avahi [ppc64el] (bionic-proposed/main) [0.7-3ubuntu1] (core)
[04:42] -queuebot:#ubuntu-release- New binary: avahi [amd64] (bionic-proposed/main) [0.7-3ubuntu1] (core)
[04:42] -queuebot:#ubuntu-release- New binary: avahi [i386] (bionic-proposed/main) [0.7-3ubuntu1] (core)
[04:44] -queuebot:#ubuntu-release- New binary: avahi [arm64] (bionic-proposed/main) [0.7-3ubuntu1] (core)
[04:44] -queuebot:#ubuntu-release- New binary: avahi [armhf] (bionic-proposed/main) [0.7-3ubuntu1] (core)
[05:09] -queuebot:#ubuntu-release- New binary: mstch [s390x] (bionic-proposed/universe) [1.0.2-2] (no packageset)
[05:11] -queuebot:#ubuntu-release- New binary: libtree-r-perl [amd64] (bionic-proposed/universe) [0.072-1] (no packageset)
[05:11] -queuebot:#ubuntu-release- New binary: mstch [ppc64el] (bionic-proposed/universe) [1.0.2-2] (no packageset)
[05:11] -queuebot:#ubuntu-release- New binary: mstch [amd64] (bionic-proposed/universe) [1.0.2-2] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: mstch [arm64] (bionic-proposed/universe) [1.0.2-2] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: mstch [i386] (bionic-proposed/universe) [1.0.2-2] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: mstch [armhf] (bionic-proposed/universe) [1.0.2-2] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: flask-security [amd64] (bionic-proposed/universe) [1.7.5-1] (no packageset)
[05:16] -queuebot:#ubuntu-release- New binary: qscintilla2 [s390x] (bionic-proposed/universe) [2.10.2+dfsg-4] (no packageset)
[05:20] -queuebot:#ubuntu-release- New binary: qscintilla2 [ppc64el] (bionic-proposed/universe) [2.10.2+dfsg-4] (no packageset)
[05:25] -queuebot:#ubuntu-release- New binary: qscintilla2 [i386] (bionic-proposed/universe) [2.10.2+dfsg-4] (no packageset)
[05:36] -queuebot:#ubuntu-release- New binary: qscintilla2 [amd64] (bionic-proposed/universe) [2.10.2+dfsg-4] (no packageset)
[05:40] -queuebot:#ubuntu-release- New binary: qscintilla2 [arm64] (bionic-proposed/universe) [2.10.2+dfsg-4] (no packageset)
[05:47] -queuebot:#ubuntu-release- New binary: qscintilla2 [armhf] (bionic-proposed/universe) [2.10.2+dfsg-4] (no packageset)
[09:22] -queuebot:#ubuntu-release- Unapproved: vulkan (xenial-proposed/universe) [<IP_ADDRESS>+dfsg1-1ubuntu1~16.04.1 => <IP_ADDRESS>+dfsg1-1ubuntu1~16.04.1] (no packageset)
[09:37] -queuebot:#ubuntu-release- New: accepted qscintilla2 [amd64] (bionic-proposed) [2.10.2+dfsg-4]
[09:37] -queuebot:#ubuntu-release- New: accepted qscintilla2 [armhf] (bionic-proposed) [2.10.2+dfsg-4]
[09:37] -queuebot:#ubuntu-release- New: accepted qscintilla2 [ppc64el] (bionic-proposed) [2.10.2+dfsg-4]
[09:37] -queuebot:#ubuntu-release- New: accepted qscintilla2 [arm64] (bionic-proposed) [2.10.2+dfsg-4]
[09:37] -queuebot:#ubuntu-release- New: accepted qscintilla2 [s390x] (bionic-proposed) [2.10.2+dfsg-4]
[09:37] -queuebot:#ubuntu-release- New: accepted qscintilla2 [i386] (bionic-proposed) [2.10.2+dfsg-4]
[09:42] -queuebot:#ubuntu-release- New: accepted avahi [amd64] (bionic-proposed) [0.7-3ubuntu1]
[09:42] -queuebot:#ubuntu-release- New: accepted avahi [armhf] (bionic-proposed) [0.7-3ubuntu1]
[09:42] -queuebot:#ubuntu-release- New: accepted avahi [ppc64el] (bionic-proposed) [0.7-3ubuntu1]
[09:42] -queuebot:#ubuntu-release- New: accepted mstch [amd64] (bionic-proposed) [1.0.2-2]
[09:42] -queuebot:#ubuntu-release- New: accepted mstch [armhf] (bionic-proposed) [1.0.2-2]
[09:42] -queuebot:#ubuntu-release- New: accepted mstch [ppc64el] (bionic-proposed) [1.0.2-2]
[09:42] -queuebot:#ubuntu-release- New: accepted avahi [arm64] (bionic-proposed) [0.7-3ubuntu1]
[09:42] -queuebot:#ubuntu-release- New: accepted avahi [s390x] (bionic-proposed) [0.7-3ubuntu1]
[09:42] -queuebot:#ubuntu-release- New: accepted mstch [i386] (bionic-proposed) [1.0.2-2]
[09:42] -queuebot:#ubuntu-release- New: accepted avahi [i386] (bionic-proposed) [0.7-3ubuntu1]
[09:42] -queuebot:#ubuntu-release- New: accepted mstch [arm64] (bionic-proposed) [1.0.2-2]
[09:44] -queuebot:#ubuntu-release- New: accepted dpdk [amd64] (bionic-proposed) [17.11-3]
[09:44] -queuebot:#ubuntu-release- New: accepted dpdk [i386] (bionic-proposed) [17.11-3]
[09:44] -queuebot:#ubuntu-release- New: accepted dpdk [arm64] (bionic-proposed) [17.11-3]
[09:44] -queuebot:#ubuntu-release- New: accepted dpdk [ppc64el] (bionic-proposed) [17.11-3]
[09:45] -queuebot:#ubuntu-release- New: accepted flask-security [amd64] (bionic-proposed) [1.7.5-1]
[09:45] -queuebot:#ubuntu-release- New: accepted mstch [s390x] (bionic-proposed) [1.0.2-2]
[09:45] -queuebot:#ubuntu-release- New: accepted libtree-r-perl [amd64] (bionic-proposed) [0.072-1]
[09:45] -queuebot:#ubuntu-release- New: accepted libt3key [amd64] (bionic-proposed) [0.2.7-1]
[09:45] -queuebot:#ubuntu-release- New: accepted libt3key [armhf] (bionic-proposed) [0.2.7-1]
[09:45] -queuebot:#ubuntu-release- New: accepted libt3key [ppc64el] (bionic-proposed) [0.2.7-1]
[09:45] -queuebot:#ubuntu-release- New: accepted libt3key [arm64] (bionic-proposed) [0.2.7-1]
[09:45] -queuebot:#ubuntu-release- New: accepted libt3key [s390x] (bionic-proposed) [0.2.7-1]
[09:45] -queuebot:#ubuntu-release- New: accepted libt3key [i386] (bionic-proposed) [0.2.7-1]
[09:47] -queuebot:#ubuntu-release- New: accepted libmail-message-perl [amd64] (bionic-proposed) [3.005-1]
[09:47] -queuebot:#ubuntu-release- New: accepted libt3highlight [arm64] (bionic-proposed) [0.4.5-1]
[09:47] -queuebot:#ubuntu-release- New: accepted libt3highlight [i386] (bionic-proposed) [0.4.5-1]
[09:47] -queuebot:#ubuntu-release- New: accepted libt3highlight [s390x] (bionic-proposed) [0.4.5-1]
[09:47] -queuebot:#ubuntu-release- New: accepted libt3highlight [amd64] (bionic-proposed) [0.4.5-1]
[09:47] -queuebot:#ubuntu-release- New: accepted libt3highlight [ppc64el] (bionic-proposed) [0.4.5-1]
[09:47] -queuebot:#ubuntu-release- New: accepted libt3highlight [armhf] (bionic-proposed) [0.4.5-1]
[10:36] -queuebot:#ubuntu-release- New binary: libt3widget [s390x] (bionic-proposed/universe) [0.5.4-1] (no packageset)
[10:37] -queuebot:#ubuntu-release- New binary: libt3widget [ppc64el] (bionic-proposed/universe) [0.5.4-1] (no packageset)
[10:38] -queuebot:#ubuntu-release- New binary: libt3widget [amd64] (bionic-proposed/universe) [0.5.4-1] (no packageset)
[10:38] -queuebot:#ubuntu-release- New binary: libt3widget [i386] (bionic-proposed/universe) [0.5.4-1] (no packageset)
[10:39] -queuebot:#ubuntu-release- New binary: libt3widget [arm64] (bionic-proposed/universe) [0.5.4-1] (no packageset)
[10:44] -queuebot:#ubuntu-release- New binary: libt3widget [armhf] (bionic-proposed/universe) [0.5.4-1] (no packageset)
[11:31] <tseliot> sil2100: hi, is it ok if I reupload ubuntu-drivers-common for LP: #1728547 dropping the code for the other SRU for now? (we need the nvidia fix to get in quickly)
[12:41] -queuebot:#ubuntu-release- New: accepted libt3widget [amd64] (bionic-proposed) [0.5.4-1]
[12:41] -queuebot:#ubuntu-release- New: accepted libt3widget [armhf] (bionic-proposed) [0.5.4-1]
[12:41] -queuebot:#ubuntu-release- New: accepted libt3widget [ppc64el] (bionic-proposed) [0.5.4-1]
[12:41] -queuebot:#ubuntu-release- New: accepted libt3widget [arm64] (bionic-proposed) [0.5.4-1]
[12:41] -queuebot:#ubuntu-release- New: accepted libt3widget [s390x] (bionic-proposed) [0.5.4-1]
[12:41] -queuebot:#ubuntu-release- New: accepted libt3widget [i386] (bionic-proposed) [0.5.4-1]
[13:17] <sil2100> tseliot: hm hm, that might be a bit problematic as I'm not sure it would be wise to skip the 7-day aging period for it
[13:17] <sil2100> tseliot: so after the new version is uploaded and accepted into -proposed, it'd still have to wait there for at least 7 days I guess
[13:19] <sil2100> tseliot: but if you think that the bugfix might not work (as I see in the other bug comment, Alex seemed to have some issues verifying the fix) I guess re-uploading might be a solution
[13:32] <tseliot> sil2100: yes, the thing is I'm not sure when we would be able to verify the amdgpu code. That can wait. The fix for nvidia is more urgent, and we need the new fix that Alex proposed too
[13:57] -queuebot:#ubuntu-release- Unapproved: rejected dpkg [source] (trusty-proposed) [1.17.5ubuntu5.8]
[14:03] -queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (xenial-proposed/main) [1:<IP_ADDRESS> => 1:<IP_ADDRESS>] (desktop-core, ubuntu-server)
[14:36] -queuebot:#ubuntu-release- New binary: tilde [s390x] (bionic-proposed/universe) [0.3.9-1] (no packageset)
[14:37] -queuebot:#ubuntu-release- New binary: tilde [amd64] (bionic-proposed/universe) [0.3.9-1] (no packageset)
[14:38] -queuebot:#ubuntu-release- New binary: tilde [arm64] (bionic-proposed/universe) [0.3.9-1] (no packageset)
[14:38] -queuebot:#ubuntu-release- New binary: tilde [i386] (bionic-proposed/universe) [0.3.9-1] (no packageset)
[14:38] -queuebot:#ubuntu-release- New binary: tilde [armhf] (bionic-proposed/universe) [0.3.9-1] (no packageset)
[14:38] -queuebot:#ubuntu-release- New binary: tilde [ppc64el] (bionic-proposed/universe) [0.3.9-1] (no packageset)
[14:38] <sil2100> tseliot: ok, re-upload in that case (with a newer version number of course)
[14:38] <sil2100> tseliot: I'll pick it up from the queue
[14:42] <tseliot> sil2100: you should be able to see my upload a few lines above ^^
[14:43] <sil2100> Ahah ;)
[14:43] <sil2100> Ok!
[14:46] <LocutusOfBorg> jbicha, please double check my sane-backends merge
[14:48] <jbicha> LocutusOfBorg: where?
[14:50] -queuebot:#ubuntu-release- Unapproved: accepted vulkan [source] (xenial-proposed) [<IP_ADDRESS>+dfsg1-1ubuntu1~16.04.1]
[14:51] <LocutusOfBorg> jbicha, bionic
[14:52] <tseliot> sil2100: thanks for your help ;)
[15:01] <sil2100> tseliot: yw! hm, I guess we don't need a re-upload for zesty, considering that it'll be EOL this month
[15:02] <tseliot> sil2100: yes, right, let's just leave zesty alone
[15:02] <jbicha> LocutusOfBorg: seems fine enough, a bit mysterious why that diff wasn't included in the Debian upload since it was properly forwarded as comment 50 at Debian bug 870078
[15:03] <jbicha> but I have trouble communicating with jff :(
[15:28] <sil2100> tseliot: I see the new xenial upload includes a minor change on top, right? Like, the skip bbswitch?
[15:28] <sil2100> tseliot: remember to re-test it before re-marking as verified
[15:30] <sil2100> tseliot: oh, and hm, I guess you'll have to re-upload (if possible) and remove the link to bug LP: #1731873
[15:31] <sil2100> tseliot: or, maybe not remove it but just do the source package build without -v, so that the .changes file only includes 1:<IP_ADDRESS> - whichever you prefer
[15:31] <sil2100> tseliot: since otherwise the SRU machinery will need the other bug verified as well, even though the fix has been reverted
[15:54] <tseliot> sil2100: alextu tested that change. I can certainly re-upload the package without -v, if you reject it
[15:54] <sil2100> tseliot: sure, upload and I'll reject
[15:56] <tseliot> sil2100: done
[15:56] <sil2100> tseliot: done, will re-review your new upload once the diff is generated
[15:56] <sil2100> Thanks!
[15:56] <tseliot> sil2100: thanks to you!
[15:56] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (xenial-proposed) [1:<IP_ADDRESS>]
[15:56] -queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (xenial-proposed/main) [1:<IP_ADDRESS> => 1:<IP_ADDRESS>] (desktop-core, ubuntu-server)
[16:09] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (xenial-proposed) [1:<IP_ADDRESS>]
[16:28] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.25 => 2.408.27] (desktop-core)
[17:23] <jbicha> slangasek: could you drop the mango-lassi pkg from bionic to allow avahi to migrate? (already removed in Debian Testing)
[17:25] -queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (artful-proposed/partner) [176.0.0-0ubuntu1 => 183.0.0-0ubuntu1~17.10.0] (no packageset)
[17:26] -queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (xenial-proposed/partner) [176.0.0-0ubuntu1~16.04.0 => 183.0.0-0ubuntu1~16.04.0] (no packageset)
[17:27] -queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (trusty-proposed/partner) [176.0.0-0ubuntu1~14.04.0 => 183.0.0-0ubuntu1~14.04.0] (no packageset)
[17:29] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.27]
[18:06] <slangasek> jbicha: done
[19:14] <jbicha> slangasek: avahi-sharp (and gshare) need to be removed too. Do you need a LP bug filed?
[19:21] <slangasek> jbicha: are there serious bugs filed in Debian that I can point to for those?
[19:22] <jbicha> avahi-sharp is Debian bug 877038 , gsharp was removed from testing because it needs avahi-sharp
[19:23] <slangasek> ok
[19:24] <slangasek> one
[19:24] <slangasek> done
[19:25] <jbicha> "one and done" :)
[19:25] <slangasek> cpaelzer: wrong merge target for https://code.launchpad.net/~paelzer/britney/hints-ubuntu-bump-openvswitch/+merge/335670, I think
[20:22] -queuebot:#ubuntu-release- New binary: libmoosex-traitfor-meta-class-betteranonclassnames-perl [amd64] (bionic-proposed/universe) [0.002003-1] (no packageset)
[20:34] -queuebot:#ubuntu-release- Unapproved: horizon (xenial-proposed/main) [2:9.1.2-0ubuntu3 => 2:9.1.2-0ubuntu4] (openstack, ubuntu-server)
[20:52] <slangasek> tsimonq2: "because it fixes Lubuntu daily builds" - har; why did your seeds disappear from bzr before this had been done?
[20:55] <tsimonq2> slangasek: Because I thought it would be alright... probably should have asked where it would break first, to be honest...
[20:55] <tsimonq2> Probably shouldn't have used it as an argument :P
[20:56] <tsimonq2> ¯\_(ツ)_/¯
[20:56] <slangasek> tsimonq2: as we're adding support for git here, I would prefer that the pattern for legacy bzr usage to also be explicitly tagged 'bzr'.  Would you care to do an s/pattern/bzrpattern/ throughout, or should I fix it up as part of the merge?
[20:57] <tsimonq2> slangasek: I'll be home in ~ 45 mins and can do it then, unless you feel inclined to merge this now
[20:57] <slangasek> tsimonq2: I can wait for you, thanks
[20:58] <tsimonq2> slangasek: Cool, I'll ping when it's done
[20:58] <tsimonq2> slangasek: But I'm also curious to see what you think about the other branch I linked in the MP
[20:59] <slangasek> haven't looked yet - will try to do so soon
[20:59] <tsimonq2> Alright.
[21:02] <tsimonq2> slangasek: afaict the last place that needs to be fixed is ubuntu-archive-tools, does that sound right?
[21:03] <slangasek> ¯\_(ツ)_/¯
[21:07] <tsimonq2> Heh alright, I guess we'll have to see then. :P
[21:07] <tsimonq2> Thanks slangasek
[21:36] <tsimonq2> slangasek: What's the version of germinate deployed on Nusakan?
[21:37] <slangasek> tsimonq2: I don't actually know where https://code.launchpad.net/~tsimonq2/+junk/ubuntu-archive-scripts is supposed to be merged to
[21:37] <slangasek> tsimonq2: checking
[21:37] <slangasek> germinate @VERSION@
[21:37] <slangasek> ;)
[21:37] <slangasek> d6b2f1ad5687ad07b85f3589d5e6a2236566bb31
[21:38] <slangasek> which is approximately 2.25
[21:38] <tsimonq2> slangasek: This: https://code.launchpad.net/~ubuntu-archive/+junk/scripts
[21:39] <cjwatson> somebody should feel free to make that a proper project if it's going to get MPs
[21:39] <cjwatson> sorry I haven't had time to review
[21:39] <slangasek> tsimonq2: right, thanks
[21:39] <slangasek> (I have a checkout of that branch, but its name eluded me)
[21:39] <cjwatson> you might also want to think about what to do about branch-seeds in lp:ubuntu-archive-tools
[21:40] <tsimonq2> cjwatson: Right, that was my next step.
[21:42] <slangasek> tsimonq2: https://code.launchpad.net/~tsimonq2/+junk/ubuntu-archive-scripts merged, and cjwatson's suggestion to make it a proper project added to my round-tuit pile
[21:43] <slangasek> tsimonq2: wrt germinate versions, 2.26 help output matches - so if you've tested or looked at code or something to tell you that --vcs == --vcs=auto, that's fine, it's just not obvious to me from the --help
[21:43] <tsimonq2> slangasek: Cool cool, looking at addressing your comments on my MP now
[21:44] <tsimonq2> slangasek: Sure, if you look at lubuntu-meta from bionic, that's what I did in the update script, and it seemed to work (with the platform seeds being in Bionic and the Lubuntu seed being in Git, it had no problems)
[21:44] <tsimonq2> (just specifying --vcs)
[21:45] <slangasek> ok
[22:07] <tsimonq2> slangasek: bzrpattern change pushed, but I'm unsure about this bit (there's confusingly similar language in the germinate source), is {prefer,use}_bzr specific to cdimage, or is it taken from the germinate Python module?
[22:10] <tsimonq2> (s/language/variables/ I guess...)
[22:11] <slangasek> tsimonq2: in this context it's specific to cdimage
[22:12] <tsimonq2> slangasek: Alright, thanks.
[22:15] <tsimonq2> slangasek: Should be good now, could you take a look?
[22:23] <slangasek> tsimonq2: merged
[22:24] <tsimonq2> slangasek: thanks, looking at lp:ubuntu-archive-tools now then
[22:25] <slangasek> tsimonq2: ah, you didn't run run-tests and neither did I
[22:26] <tsimonq2> slangasek: TIL ...
[22:28] -queuebot:#ubuntu-release- Unapproved: sosreport (artful-proposed/main) [3.4-1 => 3.5-1~ubuntu17.10.1] (ubuntu-desktop, ubuntu-server)
[22:28] -queuebot:#ubuntu-release- Unapproved: sosreport (xenial-proposed/main) [3.4-1~ubuntu16.04.1 => 3.5-1~ubuntu16.04.1] (ubuntu-desktop, ubuntu-server)
[22:28] -queuebot:#ubuntu-release- Unapproved: sosreport (trusty-proposed/main) [3.4-1~ubuntu14.04.1 => 3.5-1~ubuntu14.04.1] (ubuntu-desktop)
[22:28] -queuebot:#ubuntu-release- Unapproved: sosreport (zesty-proposed/main) [3.4-1~ubuntu17.04.1 => 3.5-1~ubuntu17.04.1] (ubuntu-desktop, ubuntu-server)
[22:29] <tsimonq2> slangasek: Do you want to fix things or should I?
[22:30] <slangasek> tsimonq2: inprogress here
[22:30] <tsimonq2> ack
[22:31] -queuebot:#ubuntu-release- Unapproved: sosreport (trusty-proposed/main) [3.4-1~ubuntu14.04.1 => 3.5-1~ubuntu14.04.1] (ubuntu-desktop)
[22:33] -queuebot:#ubuntu-release- Unapproved: sosreport (xenial-proposed/main) [3.4-1~ubuntu16.04.1 => 3.5-1~ubuntu16.04.1] (ubuntu-desktop, ubuntu-server)
[22:34] -queuebot:#ubuntu-release- Unapproved: sosreport (zesty-proposed/main) [3.4-1~ubuntu17.04.1 => 3.5-1~ubuntu17.04.1] (ubuntu-desktop, ubuntu-server)
[22:35] <tsimonq2> ubuntu-archive-tools> As they say, there's more than one way to skin a cat... I'm leaning towards trying to programatically detect if it's a git or bzr repo and then adding a --vcs argument if the user wants to override, would that be alright?
[22:35] -queuebot:#ubuntu-release- Unapproved: sosreport (artful-proposed/main) [3.4-1 => 3.5-1~ubuntu17.10.1] (ubuntu-desktop, ubuntu-server)
[22:37] <slashd> Happy new year sil2100 ! As we previously discussed could you please have a look at the uploads of sosreport for AZXT to start building in -proposed tomrrow during you SRU day ? I'm sorry I had to re-upload it after realizing I haven't put the LP: #XXX in d/changelog, you can reject the less recent upload and proceed with the most recent ones.
[23:02] -queuebot:#ubuntu-release- New: accepted libmoosex-traitfor-meta-class-betteranonclassnames-perl [amd64] (bionic-proposed) [0.002003-1]
[23:03] -queuebot:#ubuntu-release- New: accepted tilde [arm64] (bionic-proposed) [0.3.9-1]
[23:03] -queuebot:#ubuntu-release- New: accepted tilde [i386] (bionic-proposed) [0.3.9-1]
[23:03] -queuebot:#ubuntu-release- New: accepted tilde [s390x] (bionic-proposed) [0.3.9-1]
[23:03] -queuebot:#ubuntu-release- New: accepted tilde [amd64] (bionic-proposed) [0.3.9-1]
[23:03] -queuebot:#ubuntu-release- New: accepted tilde [ppc64el] (bionic-proposed) [0.3.9-1]
[23:03] -queuebot:#ubuntu-release- New: accepted tilde [armhf] (bionic-proposed) [0.3.9-1]
[23:08] <cjwatson> germinate: error: --vcs option requires an argument
[23:08] <cjwatson> I think your --vcs == --vcs=auto theory may not hold water
[23:08] <tsimonq2> Yeah.
[23:08] <tsimonq2> MP is a min away :)
[23:09] <tsimonq2> cjwatson: I made a false assumption that germinate argument syntax was the same as germinate-update-metapackage in that if only --vcs was specified, it would fall back to auto.
[23:10] <tsimonq2> (I wonder why there's that inconsistency, but regardless, fixing.)
[23:11] <cjwatson> mm, I don't quite recall
[23:12] <cjwatson> germinate-update-metapackage --vcs doesn't take an arg
[23:12] <tsimonq2> Ohh.
[23:13] <tsimonq2> cjwatson: Commit pushed to lp:~tsimonq2/ubuntu-cdimage/add-git-support-to-germinate and there might still be that MP attached.
[23:14] <tsimonq2> (Still, the inconsistency is a bit peculiar...)
[23:15] <cjwatson> I think there was some reason to do with g-u-m having extra information from the thing it's updating, or somehting
[23:15] <cjwatson> it was a while ago
[23:18] <tsimonq2> cjwatson: (Apologies if you're already doing it but) could I please get http://bazaar.launchpad.net/~tsimonq2/ubuntu-cdimage/add-git-support-to-germinate/revision/1697 pulled to lp:ubuntu-cdimage? It seems https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/add-git-support-to-germinate/+merge/335604 doesn't update...
[23:18] <cjwatson> I'm not and won't have time
[23:18] <tsimonq2> Sure.
[23:18] <cjwatson> sorry
[23:18] <tsimonq2> slangasek? :)
[23:25] <acheronuk> "Build farm disabled for maintenance; no ETA yet "
[23:25] <acheronuk> from #launchpad ^^^
[23:26] <tsimonq2> Might be worth updating the topic in here and #ubuntu-devel.