[03:58] <encryptedchicken> anyone around that could shed some light on an issue i'm gaving?
[03:58] <encryptedchicken> having*


[07:14] <dholbach> good morning
[08:34] <dfletch> morning
[08:34] <dfletch> can one have apt parallel to snappy?
[08:50] <JamesTait> Good morning all; happy Wednesday, and happy Frappe Day! 😃
[08:56] <clobrano> good morning
[09:02] <clobrano> Chipaca: hello, I came back on Bug #1496319 :)
[09:04] <clobrano> Chipaca: problem was adding custom Udev string as hw-assign parameter. Is there a way to check whether Udev is tested enough for this?
[09:05] <soffokl> Hi all, we are still trying to execute Snappy on parallella board. Based on porting guilde, we have take beagebone rootof and our own kernel. After some configuring u-boot, we have managed to load system.
[09:05] <soffokl> But after that we failed to login by “ubuntu/ubuntu”, because of system after first boot sets /var/lib/extrausers/shadow like ubuntu:!$6$tOIJ…
[09:06] <soffokl> After removing “!” we can successfully login into system. But mount command shows that root mounted in “rw” mode. And seems like not all mount points mounted properly.
[09:10] <soffokl> ogra2, ogra_ : you are our last chance :)
[09:15] <Chipaca> lool: you around?
[09:16] <Chipaca> mwhudson: did you see pitti's reply on bug 1487010?
[09:16] <lool> Chipaca: yup
[09:16] <Chipaca> clobrano: i'd ask security people
[09:16] <Chipaca> lool: you've ported snappy to some odd places :)
[09:16] <Chipaca> lool: any hints for soffokl here?
[09:16] <clobrano> Chipaca: thanks
[09:17] <lool> soffokl: are you using our initrd snippets?
[09:18] <lool> soffokl: http://kernel.ubuntu.com/git/rtg/snappy-tools.git/ has a tool to create the device tarball from kernel .debs
[09:18] <Chipaca> clobrano: most of 'em are at something like utc-5 though
[09:19]  * clobrano checking UTC-5
[09:19] <clobrano> Chipaca: it's not a problem, I can wait :)
[09:25] <ogra_> soffokl, and you used ubuntu-device-flash to create this image ?
[09:25] <Chipaca> an ogra!
[09:25]  * Chipaca faints
[09:25] <ogra_> well, inofficial still :)
[09:25] <Chipaca> :)
[09:26] <ogra_> (but bored as hell)
[09:26] <soffokl> lool, we have tried to use beagleboneblack initrd, but then our kernel failed to load.
[09:26] <ogra_> then youur kernel is likely missing bits that snappy needs
[09:27] <lool> soffokl: you need to have the right modules and options, either builtin modules or in the initrd
[09:27] <ogra_> nah
[09:27] <ogra_> you shouldnt need modules
[09:28] <lool> ogra_: either builtin or as modules  :-)
[09:28] <ogra_> if you use the same config we use on the beagle or on the rpi images you will have everything you need to mount the readonly root and the overlays
[09:28] <soffokl> ogra_, yes, we have created image with "sudo ubuntu-device-flash core 15.04 -o my-snappy.img --size 4 --channel edge --oem beagleblack --enable-ssh --device-part=./device.tar.xz"
[09:28] <ogra_> i have booted both with module-less initrds
[09:29] <biezpal> ogra_, which config you mean?
[09:29] <ogra_> soffokl, well, you need to create your onwn oem snap ... with the right bootloader, vmlinuz and initrd
[09:29] <ogra_> biezpal, the kernel config :)
[09:30] <biezpal> ogra_, where can we get the "correct" kernel config?
[09:32] <biezpal> we are using our own kernel for parallella and seems like it doesn't have required for snappy bits..
[09:32] <ogra_> ppisati, ^^ doo you have a link for biezpal
[09:33] <ppisati> biezpal: kernel version?
[09:33] <ppisati> 3.10, 3.14 or 3.18?
[09:34] <ogra_> or perhaps 4.2 ?
[09:34] <ogra_> :)
[09:34] <ppisati> *drums*
[09:34] <ppisati> 4.2 would be awesome
[09:34] <biezpal> ppisati, 4.2.0  :D
[09:35] <ogra_> soffokl, note that a readonly root is normal ... only a few selected bits are writable via bind mounted dirs and files, that is what the initrd is needed for
[09:35] <ogra_> (it sets up the bind-mount-farm)
[09:36] <ppisati> biezpal: http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_packaging
[09:36] <ppisati> biezpal: look at the UBUNT: [Config] commits
[09:36] <ppisati> biezpal: they all touch files in
[09:36] <soffokl> ogra_, thanks, we are keep reading about oem snap
[09:37] <ppisati> biezpal: http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/tree/arch/arm/configs/snappy?h=snappy_packaging
[09:37] <ppisati> biezpal: cherry-picks these commits
[09:37] <ppisati> biezpal: then
[09:37] <ppisati> biezpal: $ ARCH=arm ./scripts/kconfig/merge_config.sh arch/arm/configs/YOURCONFIG_defconfig arch/arm/configs/snappy/*.config
[09:38] <ppisati> biezpal: and you should get a config able to boot snappy
[09:38] <ogra_> soffokl, note that we switched to use a uboot.env file for the environment, but the old uEnv.txt and snappy-system.txt stuff should still work to get something to do a first boot (just rollback and update wont, but thhats a second step for porting)
[09:40] <biezpal> ppisati, ok, thanks for helping..
[10:17] <longsleep> yesterday i tried updating one of my test boxes to stable 6, it failed with the message that ubuntu-core was sideloaded. Is that expected?
[10:23] <longsleep> ogra_: Hey, are you using predictable network interface names with rpi2 image? If so, how did you enable it, kernel parameter only?
[10:23] <ogra_> longsleep, i'm actually suppressing them via kernel cmdline option corrently
[10:24] <ogra_> net.ifnames=0
[10:25] <ogra_> that keeps the old naming scheme
[10:25] <longsleep> ogra_: Ah - but that is the default in ubuntu isnt it?
[10:25] <ogra_> not sure if we use it elsewhere
[10:26] <longsleep> ogra_: net.ifnames=1 is working to some level for me, but i was wondering if the interfaces should still be eth0 and wlan0
[10:26] <ogra_> well.... snappy config ubuntu-core defaults to eth0 currently
[10:27] <longsleep> right, but aside from that, i was kind of expecting crazy interface names with that change
[10:27] <ogra_> yeah
[10:27] <ogra_> depends on your HW
[10:28] <longsleep> mhm ok, USB wifi is getting wlan0 names, works fine as long as you do not replace the USB device with another one
[10:29] <ogra_> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
[10:29] <ogra_> seems you are lucky and fall inot category 5 on that 1-5 list
[10:30] <longsleep> mhm
[10:31] <longsleep> this means the hardware does not provie 1, 2 or 3 or i am doing something wrong
[10:31] <ogra_> right ... or you have a udev rule in place already
[10:31] <longsleep> i did at least expect it to use 3
[10:32] <longsleep> ogra_: why do you not use it on the rpi2? just because ubuntu-core defaulting to eth0?
[10:32] <ogra_> yeah, and i get a really weird name based on the mac address (4)
[10:32] <longsleep> oh
[10:32] <longsleep> yeah 4 would be bad
[10:33] <ogra_> (which i shouldnt according to that doc)
[10:33] <longsleep> well, maybe it is enabled in the systemd build somwhere
[10:33] <ogra_> iirc Chipaca said all that works fine in rolling ... never tried that
[10:34] <ogra_> i added this hack to rpi specifically for 15.04 images
[10:34] <Chipaca> mmh?
[10:34] <Chipaca> i was probably lying, whatever it was
[10:34] <Chipaca> 's a good bet
[10:34] <ogra_> lol
[10:34] <longsleep> anyways, i am basically fine with getting 5 - but i have some issues when an active USB wifi is removed and replaced, something is not released then and then
[10:35] <longsleep> mhm, from my testing setting the kernel parameter to 0 is the same as the default behavior without the parameter
[10:35] <longsleep> (stable channel though)
[10:35] <ogra_> funny
[10:36] <ogra_> is that on a first boot ?
[10:36] <longsleep> yes
[10:36] <ogra_> (wont work on subsequent ones since the udev rule exists)
[10:37] <longsleep> when i remove the udev rule and reboot without the parameter it creates it again
[10:37] <longsleep> same is when booting with 0 as value
[10:37] <longsleep> when booting with 1, the udev rule is not created
[10:38] <ogra_> yeah
[10:38] <ogra_> but your kernel simply provides the old naming
[10:40] <Chipaca> is this about the creation of the file for the first ethernet card?
[10:40] <longsleep> ogra_: oh, so this thing depends on the kernel as well, i thought it would be systemd only
[10:40] <ogra_> well, that is what the wikipage says
[10:41] <longsleep> Chipaca: it is about the interface names and the udev rule stores all ethernet devices ever connected to the host
[10:41]  * longsleep checks the wiki again
[10:41] <ogra_> 5. Classic, unpredictable kernel-native ethX naming (example: eth0)
[10:41] <ogra_> kernel-native
[10:41] <Chipaca> ah
[10:42] <Chipaca> but i had nothing to do with that :)
[10:42] <Chipaca> all i did touching that was creation of the first-boot file for the first ethernet device
[10:42] <soffokl> ogra_, we are successfully loaded with initrd, thanks again :)
[10:42] <longsleep> ogra_: right, but any kernel should be the same right?
[10:42] <Chipaca> which just looks for eth* and en*
[10:42] <ogra_> i'm pretty sure you worked on a snappy specific bug for it :)
[10:42] <ogra_> right
[10:42] <longsleep> Chipaca: what file is that?
[10:42] <ogra_> soffokl, \o/
[10:42] <Chipaca> longsleep: /etc/networ/interfaces.d/{ethname}
[10:43] <longsleep> Chipaca: ah, well you should probably extend this to also support wl*
[10:43] <ogra_> in the course where we discussed that bug it turned out that rolling and 15.04 behaved differently
[10:43] <ogra_> which led me to use the kernel cmdline option on rpi stable
[10:44] <longsleep> i see
[10:44] <longsleep> mhm funny that i do not seem to be required to use the cmdline option though
[10:44] <ogra_> i agree abouth the wl* thing though
[10:44] <Chipaca> longsleep: wl is wifi, sin't it?
[10:44] <longsleep> Chipaca: yeah
[10:44] <ogra_> yep
[10:45] <Chipaca> isn't that more complicated?
[10:45] <ogra_> buut if you are unluckly it could also be wifi0
[10:45] <ogra_> :P
[10:45]  * ogra_ has seen such devices before
[10:45] <longsleep> really
[10:45] <longsleep> oh my
[10:45]  * Chipaca <- il ne sais rien
[10:45] <Chipaca> sait*
[10:45] <ogra_> rm -fr ....
[10:45] <longsleep> lol
[10:45]  * ogra_ removes the french
[10:46] <Chipaca> :D
[10:46] <Chipaca> or, D:
[10:46] <Chipaca> let me get our friends out of france first!
[10:46] <ogra_> heh
[10:46] <longsleep> wifi is more complicated true, i am currently providing wpa config in /etc/writable/wpa_supplicant.conf
[10:46] <longsleep> did not find any better writable mount to put it
[10:47] <ogra_> there might be a network-manager framework at some point in the future
[10:47] <ogra_> that should make it easier to just supply a snappy confg yaml for your setup
[10:47] <Chipaca> longsleep: you can't configure it via the interfaces.d thing in config?
[10:48] <ogra_> only to a certain extend
[10:48] <longsleep> Chipaca: not if you want to be able to configure multiple networks
[10:48] <ogra_> wifi config works fine via /e/n/i ... but not for the higher level encryptions
[10:48] <Chipaca> longsleep: i don't think multiple networks blocks this
[10:48] <ogra_> i.e. enterprise WPA and such
[10:48] <Chipaca> ogra_: yeah, those always tripped me up :)
[10:49] <longsleep> Chipaca: what is not blocked by multiple networks?
[10:49] <ogra_> normal personal WPA2 works fine via the file
[10:49] <longsleep> only for a single ssid
[10:49] <ogra_> i never tried multiple :)
[10:49] <longsleep> if you want roaming or have it auto pick the stronges signal it will not
[10:50] <Chipaca> ah
[10:50] <longsleep> =t
[10:50] <Chipaca> so, let's call it "basic support"
[10:50] <Chipaca> :)
[10:50] <ogra_> and my WIFI APs here can properly use ESSID for roaming
[10:50] <longsleep> hehe all right
[10:51] <ogra_> (using the same SSID for all and have them send roaming info to the client about strenght etc)
[10:51] <longsleep> ogra_: mhm so you say i should avoid using a wpa config file mhm - not sure - then i need a way to store multiple ssid/password combinations some place else and apply them from some place else
[10:51] <ogra_> but thats sadly an AP feature you dont find in the home user HW
[10:52] <longsleep> right, and only works for a single logical network
[10:52] <ogra_> yeah
[10:52]  * longsleep thinks wpa-confi option is the way to go for everyone
[10:52] <ogra_> nah
[10:52] <longsleep> snappy even shipts wpa_passphrase to create it
[10:52] <longsleep> :)
[10:52] <longsleep> -t
[10:52] <ogra_> nmcli via snappy config from your oem snap is the way to go
[10:53] <longsleep> nmcli oh my
[10:53]  * longsleep was hoping to avoid that
[10:53] <ogra_> once there is a NM framework we ship by default
[10:54] <ogra_> NM offers evereything we need for GSM, LAN and WLAN
[10:54] <ogra_> and whatever else
[10:54] <longsleep> does NM also offer link detection? I added a new comment to https://bugs.launchpad.net/snappy/+bug/1498631/comments/10 yesterday, as dhcp is running forever even if there is no link on eth0
[10:54] <ogra_> yes, it should
[10:55] <longsleep> Now the waiting is fixed with the release from yesterday but the dhcp keeps running and running
[10:55] <ogra_> (plug a cable into your laptop ... it will DTRT)
[10:55] <longsleep> oh, i did some brief research about ifplugd and and did not like it very much
[10:55] <ogra_> is that dhclient ?
[10:55] <longsleep> yes dhcclient is started for eth0
[10:56] <longsleep> no matter if plugged or not
[10:56] <ogra_> that should have a timeout option we can add i think
[10:56] <longsleep> mhm but what when you plug it after that timeout was reached?
[10:56] <ogra_> i think -1 ...
[10:56] <longsleep> that is there
[10:56] <ogra_> but that will only make it try once
[10:57] <ogra_> oh
[10:58] <ogra_> it should try only once for the duration of the timeout that was defined in dhclient.conf
[10:58] <longsleep> mhm it does have some kind of interval
[10:59] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ grep ^time /etc/dhcp/dhclient.conf
[10:59] <ogra_> timeout 300;
[10:59] <ogra_> so it should stop after 5min
[10:59] <longsleep> No working leases in persistent database - sleeping.
[10:59] <longsleep> and after some time it will try again
[10:59] <longsleep> ok maybe i was not patient enough
[11:00] <longsleep> nope its not me
[11:00] <longsleep> it just started again
[11:01] <longsleep> ogra_: 10:54:53 sleeping
[11:01] <longsleep> ogra_: 11:00:33 DHCPDISCOVER
[11:01] <ogra_> uhm
[11:01] <longsleep> i did nothing with that device in the meantime
[11:01] <longsleep> just journalctl
[11:02] <ogra_> pitti, any idea why that happens ? "dhclient -1 <iface>" should not make it restart, no ?
[11:02] <ogra_> or i'm reading the manpage wrong ... sounds like a bug
[11:03] <longsleep> ogra_: well then i am reading the manpage wrong as well
[11:03] <longsleep> ogra_: exit with code 2 :)
[11:03] <ogra_> right
[11:03] <daker> hi, anyone with some snappy/Ubuntu Core presentations ?
[11:04] <longsleep> i am out for lunch now, i will dig more on this later
[11:04] <ogra_> daker, i know sergiuens held a talk, but i dont know where his slides are ... (and he is off until tomorrow)
[11:05] <daker> ogra_: ok, i will ask him tomorrow
[11:05] <Chipaca> http://summit.ubuntu.com/ubuconla-2015/meeting/22539/hola-snappy/
[11:06] <Chipaca> ogra_: ^ that one?
[11:06] <ogra_> oh, right
[11:07] <ogra_> you might need to pipe it through skype though to get it in a sane language
[11:07] <ogra_> *g*
[11:07] <daker> Chipaca: thanks
[11:08] <svij> daker: depending on your language, here's another one in not-english: https://speakerdeck.com/svij/snappy-ubuntu-core
[11:08] <daker> svij: thanks!
[12:09] <ogra_> ppisati, err ... why do we default to "powersave" in the kernel config, thats really bad ... (first: that makes booting slow, second: we have a userspace job that forces it to ondemand after boot)
[12:10] <ogra_> can we please set this back to performance by default so the boot doesnt get slowed down =
[12:10] <ogra_> ?
[12:11] <ogra_> (we can discuss making the usespace job configurable to then default to powersave after boot or some such)
[12:19]  * Chipaca goes to lunch, while pondering the genius of http://bennyhillthis.com/
[12:30] <longsleep> ogra_: so the dhclient is still trying to get an address for the not connected eth0, so i think we can say that it does not stop
[12:32] <ogra_> longsleep, right, i think thats a bug .... seems pitti didnt see my ping above :)
[12:32] <pitti> ogra_: I didn't get to it yet; sorry, being flood-pinged
[12:32] <ogra_> i would expect it to stop doing that if -1 is used and a timeout is set in dhclient.conf
[12:32] <longsleep> ok let me add it to the tracker then
[12:33] <ogra_> perhaps something external restarts dhclient and doesnt respect "exit 2" though
[12:33] <longsleep> ogra_: no, the pid of that dhclient did not change since 2 hours
[12:34] <ogra_> wow
[12:34] <ogra_> yeah, then it sounds like dhclient doesnt even exit
[12:34] <pitti> I didn't follow scrollback, but -1 doesn't (seem to) be "try once and immediately exit", just "try once" (as documented)
[12:34] <pitti> so it might stay around until it actually succeeds?
[12:35] <longsleep> yet it stays around and flodding logs all 5 minutes with DHCPDISCOVER on eth0 lines
[12:35] <longsleep> s/yet/yes
[12:36] <ogra_> pitti, well, the manpage says it does try once for the duration of the timeout thats defined in dhclient.conf
[12:36] <pitti> so that sounds like a bug then
[12:36] <ogra_> and then it does an "exit 2"
[12:37] <longsleep> let me add a new bug separate from 1498631
[12:37]  * pitti runs "sudo dhclient -1 -v -i lxcbr0" (which can't succeed) and lets that sit for 5 mins
[12:38]  * pitti gets grumpy, changes timeout to 30s and re-runs
[12:38] <longsleep> hehe
[12:38] <pitti> what kind of ridiculous default is "5 mins" anyway
[12:39] <pitti> we live in an impatient world :)
[12:39] <pitti> 5 mins == broken
[12:39] <pitti> No DHCPOFFERS received.
[12:39] <pitti> and exits with 0 (!) after 30 s
[12:39] <longsleep> Maybe its only with a lease file?
[12:39] <longsleep> After No DHCPOFFERS received it logs No working leases in persistent database - sleeping.
[12:39] <pitti> I do have a /var/lib/dhcp/dhclient.leases
[12:40] <pitti> right, I get the same
[12:40] <longsleep> mhm
[12:40] <pitti>       Old leases are kept around in case the DHCP server is unavailable when  dhclient
[12:40] <pitti>        is  first  invoked  (generally during the initial system boot process).  In that
[12:40] <pitti>        event, old leases from the dhclient.leases file which have not yet  expired  are
[12:40] <pitti>        tested,  and if they are determined to be valid, they are used until either they
[12:40] <pitti>        expire or the DHCP server becomes available.
[12:40] <ppisati> ogra_: powersave is our default on every kernel/arch
[12:40] <pitti> so that sounds plausible
[12:40] <ppisati> ogra_: how much do we gain in boot time going to performance?
[12:41] <longsleep> mine does not exit - the pidfile got created at 10:25 utc and it still has that pid
[12:41] <pitti> longsleep: so does it log that it's re-using old leases then?
[12:41] <longsleep> pitti: no there are no leases
[12:41] <longsleep> (lease file is empty)
[12:41] <longsleep> its the first boot actually, and it never had a link on eth0
[12:42] <ogra_> ppisati, a few seconds !
[12:43] <ogra_> ppisati, who decided to drop performance in our main kernels ?!?
[12:43] <ogra_> thats an essential boot speed bit
[12:43] <ogra_> (worked out around lucid by keybuk)
[12:43] <ppisati> ogra_: let me check
[12:44] <pitti> CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
[12:44] <ogra_> phew !
[12:44] <pitti> we still have that in wily's amd64 kernel at least
[12:44] <pitti> is that different on other kernels?
[12:44] <ogra_> seems like
[12:44] <ogra_> well, in snappy kernels
[12:44] <pitti> and /etc/init.d/ondemand should change it to something else after 1 min
[12:44] <ogra_> yeah
[12:45] <ogra_> we want full CPU and IO throughput until we are booted
[12:45] <ogra_> and after that switch to ondemand
[12:45] <ogra_> if we want to switch to something else in snappy thats fine, but only after booting please
[12:45] <pitti> FWIW, needing something like /etc/init.d/ondemand seems silly; I'd have thought the kernel's default scheduler would be clever enough by now
[12:46] <pitti> I mean, even with ondemand/powersave it should go to full CPU if there's load; doesn't it?
[12:46] <ppisati> pitti: yep
[12:46] <ppisati> pitti: it just tries to go down quicker
[12:47] <pitti> ppisati: right, I'm not advocating to keep "performance" all the time; I'm just asking why "ondemand" all the time is worse
[12:47] <pitti> if there is demand (and there obviously is during boot) it should certainly be as fast?
[12:48] <ppisati> ogra_: i was wrong, the default is still PERFORMANCE
[12:48] <ogra_> i think keybuk found that it takes a bit to scale up
[12:48] <ogra_> ppisati, good
[12:49] <ppisati> ogra_: tough in that rpi2 kernel was powersave
[12:49] <ppisati> ogra_: let me check another thing
[12:49] <ogra_> pitti, so you run without full performance for a second or two during boot
[12:49] <Chipaca> jdstrand: ping
[12:49] <ppisati> here it is
[12:49] <ppisati> arch/arm/configs/bcm2709_defconfig:CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE=y
[12:50] <ogra_> which costs precious CPU throughput at a point where you dont want to lose it
[12:50] <ppisati> ogra_: that was the default governor from the rpi config
[12:50] <ogra_> ppisati, oh, please change that asap
[12:50] <ogra_> we want ondemand after boot and performance during boot
[12:50] <ppisati> ogra_: let me check 4.2
[12:50] <ogra_> now i understand why it boots so sluggish
[12:50] <ppisati> ogra_: and i'll push a a new kernel for 3.19
[12:50] <Chipaca> jdstrand: https://code.launchpad.net/~chipaca/snappy/auth/+merge/273683
[12:51] <ogra_> ppisati, why ? we dont use 3.19 anywhere anymore :)
[12:51] <ogra_> snappy is 4.2 everywhere since last image
[12:51] <ppisati> ogra_: i'm still using it :)
[12:51] <Chipaca> jdstrand: marked "work in progress" because i still need to add code that uses it, but that's the crypto bits done for your guys to take a look
[12:51] <longsleep> ppisati, ogra_ : Added the dhcp issue as bug #1503680
[12:52] <Chipaca> oh, drat, prerequisites
[12:52] <ogra_> and in snappy we run cloud-init during boot *before* the ondemand governor is used ... and cloud-init is python ... which is ultra slow on ARM in itself
[12:52] <ogra_> longsleep, thanks !
[12:52] <Chipaca> jdstrand: https://code.launchpad.net/~chipaca/snappy/auth/+merge/273684 <- fixed prereq's
[12:56] <ppisati> CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y is the default on 4.2 rpi2 too
[12:56] <ppisati> so it was just a 3.19 thing
[12:57] <ppisati> ogra_: when you were referring to slowness, did it apply to 4.2 too?
[12:57] <ppisati> ogra_: because it's correct there
[12:58] <ogra_> ppisati, i didnt measure it recently ... in my initial images it was really slow (1-2min to boot) .... with the last image i mostly booted remote
[12:58] <ogra_> i have to prepare a new rpi image this week (nobody told me we'd release a new stable one this week, i thought that was planned for teh 17th)
[12:59] <ogra_> i'll do some stopwatching :)
[12:59] <ppisati> ogra_: cool
[13:00] <longsleep> any reason why opencryptoki is in ubuntu-core stable? I just added bug #1503681
[13:01] <ogra_> longsleep, weird, thats fixed
[13:01]  * ogra_ wonders if mvo did test on all ARM arches before doing that rushed release yesterday :/
[13:02] <longsleep> mhm the image i created yesterday has it installed
[13:02] <ogra_> longsleep, its a duplicate in any case, let me find the bug
[13:02] <ogra_> https://bugs.launchpad.net/snappy/+bug/1500020
[13:03] <longsleep> let me compare it
[13:03] <ogra_> ah, and i didnt milestone it so that mvo could have found it because asac didnt create a milestone
[13:03] <jdstrand> Chipaca: ok, I added it to the card
[13:03] <ogra_> i fixed it in wily
[13:03] <mvo> ogra_: I ran on bbb and did not touch raspi
[13:03] <jdstrand> s/to the/to a/
[13:03] <Chipaca> jdstrand: g'morning :)
[13:03] <jdstrand> Chipaca: hi!
[13:03] <mvo> ogra_: oh, in a meeting right now, but I can check right after that
[13:03] <ogra_> mvo, right, but there are plenty bugfixes missing seemingly ... i asked asac for a milestone and he missed creating one during the sprint
[13:04] <ogra_> so the open bugs are all not milestoned
[13:04] <jdstrand> Chipaca: it will likely be a couple of days-- sarnold is swamped with other reviews
[13:04] <jdstrand> Chipaca: hey, do you know who implemented socket* and listen-stream?
[13:04] <ogra_> mvo, but therer are some regressions due to stuff that was added for amd64
[13:04] <Chipaca> jdstrand: the chipacacentric worldview is disappointed
[13:05] <Chipaca> jdstrand: mvo iirc
[13:05] <jdstrand> ok thanks
[13:05] <jdstrand> mvo: I know you're in a meeting. after the meeting when its convenient, can you ping me re socket* and list-stream?
[13:05] <jdstrand> listen*
[13:06] <longsleep> ogra_: i see, well the comment says that the writable path should be added, it has not been added for ubuntu-core 6 - at least the one i got
[13:06] <ogra_> longsleep, yeah, thats broken
[13:07] <longsleep> ogra_: ubuntu-core 6 has 0.6.15 of ubuntu-core-config - thats why - fixed in 0.6.29
[13:07] <ogra_> longsleep, thats correct, as i said there is a bunch of regressions that werent fixed
[13:08] <ogra_> (and vivid has 0.6.15, which is correct too)
[13:08] <longsleep> ok good, so how can i close 1503681 as duplicate
[13:09] <longsleep> ah found it
[13:09] <ogra_> longsleep, done
[13:09] <longsleep> ok thanks :)
[13:17] <mvo> ogra_: do you have bugs already for the regressions?
[13:17] <mvo> jdstrand: ok, I will ping you
[13:17] <ogra_> mvo, i have to dig them up, bug 1500020 is definitely one
[13:18] <ogra_> i had three, i think i closed two of them already
[13:18] <ogra_> all regessions from the last additions of packages for the amd64 images
[13:19] <ogra_> we definitely need to improve our milestone process for bugs ... perhaps just create ten in advance in LP or so so that doesnt get forgotten
[13:36] <mvo> jdstrand: back
[13:36] <jdstrand> mvo: hi!
[13:37] <mvo> ogra_: yeah, this time the sprint made the timing really awkward
[13:37] <jdstrand> mvo: I am writing up some documentation and noticed the new socket* and listen-stream directives for services. can you give me a two sentence summary of the feature?
[13:38] <jdstrand> (just so we are on the same page-- I think I know what's going on from the docs, but I have followup questions)
[13:38] <mvo> jdstrand: hm, it allows socket activated daemons with snappy
[13:39] <mvo> jdstrand: the patch comes from kickinz1 for docker
[13:39] <jdstrand> I see
[13:39] <mvo> jdstrand: I think its somewhat documented in meta.md
[13:39] <jdstrand> mvo: listen-stream says "The full path of the stream socket". is this a named socket?
[13:39]  * jdstrand was looking at https://developer.ubuntu.com/en/snappy/guides/package-metadata/
[13:40] <mvo> uh, its poorly documented in docs/meta.md - but at least its mentioned
[13:41] <mvo> jdstrand: it can be both a path or a abstract socket with @foo
[13:41] <mvo> jdstrand: or a port (haven't tested that though)
[13:42] <jdstrand> mvo: are there any checks to make sure that a named path falls within the app-specific directories? does the abstract socket use namespacing? (eg, if pkgname is foo, check that abstract matches @foo_...)
[13:42] <mvo> jdstrand: its essentially what SYSTEMD.SOCKET(5) is doing
[13:42] <mvo> jdstrand: no checks currently, no
[13:42] <jdstrand> ok, so I can make some review tools checks for those
[13:43] <jdstrand> basically, I'll say its ok if it matches the app-specific TMPDIR or SNAP_APP_DATA_PATH
[13:43] <jdstrand> and I'll do what I suggested for the abstract socket
[13:43] <jdstrand> mvo: does that sound reasonable?
[13:43] <mvo> jdstrand: yes!
[13:43] <mvo> jdstrand: thanks a lot!
[13:43] <jdstrand> ok
[13:44] <jdstrand> now, for the bit that really concerns me: socket-user and socket-group
[13:44] <jdstrand> we don't assign UIDs or GIDs
[13:44] <jdstrand> how are these supposed to work?
[13:45] <mvo> jdstrand: welllllll they work for docker because there is  a docker user on the image, but they don't work for anything else right now
[13:45] <jdstrand> right
[13:45] <jdstrand> ok
[13:45] <mvo> so maybe we should not expose that option while there is no way to add users ?
[13:46] <jdstrand> mvo: so I will just flag those if they are specified at all. when we support UID and GID per-snap (I was thinking this would be opt-in), we can check that it matches that
[13:46] <mvo> makes sense
[13:46] <jdstrand> mvo: clearly docker needs it. it is probably a doc change
[13:47] <jdstrand> either don't expose it in the doc at all, or mention that it will flag a manual review
[13:48] <jdstrand> mvo: how about I add a bug for the review tools and add a snappy task to update the docs so there is a little more information?
[13:48] <jdstrand> mvo: and I'll submit an MP for that
[13:48] <mvo> jdstrand: +1
[13:49] <jdstrand> ok. it won't be until the end of the week/next week
[13:49] <jdstrand> mvo: thanks for walking me through this
[13:49] <mvo> thats fine! thank you!
[13:52] <jdstrand> mvo: can listen-stream to a relative path or just absolute path?
[13:54] <mvo> jdstrand: I think it has to be absolute (which makes it interessting)
[13:54] <jdstrand> I can use current/
[13:56]  * mvo nods
[14:03] <jdstrand> mvo: btw, it seems that snappy build still doesn't run the tools by default
[14:03] <jdstrand> mvo: I thought we agreed they should? note, I think the tools ppa needs to have a review tools upload for the recent 'architectures' changes
[14:04] <mvo> jdstrand: let me check that, I was sure my branch got merged
[14:05] <jdstrand> mvo: maybe it is my local snappy that is out of date...
[14:05] <mvo> jdstrand: no, you are right
[14:05] <mvo> jdstrand: let me chase that
[14:06] <jdstrand> ok, I'll work to get the updated review tools into the ppa. again, it'll be a couple days (doc writing)
[14:07] <mvo> ok
[15:16] <Chipaca> elopio: mvo: https://en.m.wiktionary.org/wiki/husk
[15:21] <Chipaca> anyway, i suck at names, so i'm all ears
[15:44] <elopio> Chipaca: call them "meta", that fixes everything :)
[15:44] <Chipaca> meta.
[15:45] <elopio> I'm ok with husks actually (after the explanation of course). I would call that peel, but what do I know?
[15:47] <Chipaca> elopio: thinking about it, hollejo is not the right word. Hollejo is the white thing under the orange skin and before the "gajos", for example
[15:48] <Chipaca> elopio: you know what chala (as in "humita en chala") is? that's a husk
[15:48] <Chipaca> the outer, leafy covering of corn is the husk
[15:49] <Chipaca> and you remove a husk by husking, which would've made it more confusing in code so i called it 'load' :-p
[15:49] <elopio> umm, yes. I think my mother calls hollejos the calluses in the fingers. I'm sure I've heard that somewhere, but not entirely sure where.
[15:49] <elopio> no, chala makes it worst. I've only heard chala rasta. I think they are from argentina. Not sure either.
[15:50] <Chipaca> https://upload.wikimedia.org/wikipedia/commons/1/13/Humitas_en_chala_tipicas_de_Argentina8.JPG
[15:50] <Chipaca> mmmmmmmmm
[15:50] <Chipaca> now i want some
[15:50] <elopio> Chipaca: you should write a husker interface, and propose it for golang upstream. I'm sure you'll be famous.
[15:51]  * Chipaca mumbles incoherently and gets back to work
[15:53] <elopio> I think we call the "chalas of the corn" just "hojas".
[15:53] <elopio> and humita is something like tamal de elote.
[15:53]  * elopio goes for breakfast.
[15:54] <mvo> Chipaca, elopio I still like something about lighweightThing, that makes it realtively easy to parse (although its a bit long :/
[15:54]  * mvo gets dinner
[15:54] <Chipaca> yep, long, is why i said maybe just use lightweight
[15:55] <Chipaca> elopio: re-review https://code.launchpad.net/~chipaca/snappy/systemimage-exported-consts/+merge/273479 if you get a moment please
[15:56] <elopio> exuvia
[15:56] <elopio> I doubt we can fix it, but I'm sure we can make it worst :) https://en.wikipedia.org/wiki/Exuvia#/media/File:Euscorpion_exuvia_2.jpg
[15:57] <Chipaca> exuvia works for me, but i thought it was a bit offbeat :)
[15:57] <Chipaca> love magicicada exuviae stuck to trees
[15:57] <elopio> Chipaca: approve, needs commit message.
[15:58] <Chipaca> on it
[16:08] <Chipaca> mvo: wrt https://code.launchpad.net/~chipaca/snappy/removed-pkg/+merge/273481, renamed it to RemoteManifestPath, want to take another look?
[16:08] <Chipaca> mvo: otherwise i'll top-approve :)
[16:19] <Chipaca> elopio: i didn't know exuviae is also another word for booty. +1 to exuvia.
[16:20] <elopio> I didn't know that either. I've learned so much today!
[16:25] <matiasb> hi there! quick question, if I'd want to get some review outcome for a snap package (uploaded to store, triggered manual review during auto-review), who should I ping?
[16:27] <elopio> matiasb: I don't understand. You want to cause your snap to trigger a manual review?
[16:28] <matiasb> elopio, nop, I submitted a package (a real one!), but it requires manual review, so I'm waiting for it (for a few days now)
[16:29] <elopio> matiasb: ah, generally it's Sergio who reviews them.
[16:29] <elopio> he's back tomorrow.
[16:29] <matiasb> elopio, ah, ok, thanks :)
[16:30] <elopio> beuno: can you give me permissions to look at the review queue?
[16:40] <beuno> elopio, they are rarely handed out. What for?
[16:42] <elopio> beuno: is there a staging I can look at? I just want to understand the process, and do some exploratory tests with snaps that require manual review.
[16:48] <beuno> elopio, they are the same ACL list. The process is: run the security scripts (lp:click-reviewer-tools), if they fail they get rejected. You can re-request a manual review, and someone clicks a button
[16:49] <elopio> beuno: ok, that works. matiasb is your source public? I would like to see the click-reviewer-tools failure in your branch.
[16:50] <beuno> elopio, click-reviewer-tools is public, the rest isn't
[16:51] <matiasb> elopio, I packaged transmission, so sources are public; re the errors, I can share a paste with them, but they are related to the fact that I had to tweak the default security profile
[16:51] <elopio> matiasb: w00t for transmission.
[16:53] <elopio> matiasb: yes, please paste the error. I'm just curious. I've just reviewed a branch with a test for the reviewer-tools and want to learn more about it to add more tests.
[16:53] <matiasb> elopio, http://paste.ubuntu.com/12706117/
[16:53] <elopio> thank you.
[16:54] <matiasb> elopio, np, it doesn't say much, it complains I'm changing the sec profile :)
[16:55] <matiasb> I couldn't find another way to work around that
[16:58] <Chipaca> matiasb: wrt tweaking security profile, that's usually a "talk with jdstrand"
[16:59] <Chipaca> matiasb: and he, too, can do manual reviews, specifically for this scenario :)
[17:02] <matiasb> Chipaca, got it, thx; so, when jdstrand is around to take a look... :)
[17:02] <Chipaca> mvo: so, for when you return: 1. leave husk/Husk; 2. exuvia/Exuvia; 3. package lightweight, type PartList
[17:04] <Chipaca> mvo: husk.Byname -> lightweight.PartListByName, husks.All -> lightweight.AllPartLists
[17:04] <Chipaca> mvo: all others end up waaay too long imho :)
[17:19] <jdstrand> Chipaca, matiasb: fyi, unless the app comes from a trusted vendor, we don't allow security-override or security-policy in the public store (a private store could allow it). having the source open is great, but the snap may not have been built from that source
[17:19] <jdstrand> matiasb: how extensive are the policy edits? perhaps they are bugs in the templated policy?
[17:20] <Chipaca> jdstrand: dude, we don't do "bugs".
[17:20] <Chipaca> they're miscomprehended teenager features
[17:20] <matiasb> jdstrand, understood; I had to add a few extras to the default templates, as specified in the comment there, happy to workaround if possible
[17:22] <jdstrand> matiasb: looking at what you put in the review, we could allow /proc/sys/kernel/random/uuid
[17:22] <jdstrand> matiasb: we can't allow mounts (info leak)
[17:23] <jdstrand> matiasb: and quotactl is potentially dangerous too. you should probably patch transmission to not need mounts and quatactl
[17:24] <matiasb> jdstrand, ack, got it; I'll take a look and check if that's possible
[17:24] <nessita> jdstrand, silly question, how would transmission workaround usage of quotactl since it needs to know if there is free space in disk to keep (or not) downloading torrents?
[17:25] <matiasb> jdstrand, so I guess I will let you know if I can fix that, thanks
[17:26] <nessita> ah, perhaps free disk space can be checked with other libraries
[17:27] <Chipaca> nessita: because snappy doesn't (yet? evar?) support quotas, just checking df is probably enough
[17:27] <ogra_> would df work ?
[17:28] <ogra_> (i guess it also needs access to /proc/mounts)
[17:28] <jdstrand> matiasb: the simplest would be to not perform that check at all. perhaps there is an actual alternative solution.
[17:29] <nessita> Chipaca, got it, thanks
[17:29] <ogra_> (i mean, perhaps something like "df ." doesnt need it, never tired)
[17:29] <matiasb> jdstrand, probably, didn't review the sources in detail, but I guess it should be possible to work something out
[17:30] <Chipaca> ogra_: df . does need it :(
[17:30] <ogra_> ah, sad
[17:30] <Chipaca> [101896.479363] audit: type=1400 audit(1444238994.246:13): apparmor="DENIED" operation="open" profile="hello-world.canonical_env_1.0.18" name="/bin/df" pid=1531 comm="env" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[17:31] <ogra_> that is actually quite a drawback, i can imagine a lot usecases where apps would want to know the free space in SNAP_APP_DATA_DIR
[17:31] <Chipaca> maybe there's a way to allow just that?
[17:32] <ogra_> i doubt any available tool can do that without /proc/mounts or at least without accessing info about the underlying disk SNAP_APP_DATA_DIR lives in
[17:32] <ogra_> i could be wrong though
[17:33] <jdstrand> Log: apparmor="DENIED" operation="open" profile="hello-world.canonical_sh_1.0.18" name="/proc/3814/mounts" pid=3814 comm="df" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[17:33] <ogra_> yeah
[17:33] <jdstrand> we need an out of process service
[17:33] <jdstrand> then we could allow talking to it
[17:33] <ogra_> snappy freespace
[17:33] <jdstrand> df isn't in the policy now cause it needs /proc/*/mounts
[17:34] <jdstrand> well, not snappy
[17:34] <ogra_> "SNAP_APP_DATA_DIR has 1254MB free"
[17:34] <jdstrand> apps can't use snappy :)
[17:34] <ogra_> oh, indeed
[17:34] <jdstrand> snapd maybe
[17:34] <jdstrand> anyhoo, something our of process
[17:35] <jdstrand> out*
[17:35] <jdstrand> ogra_: hey, I have a couple of questions while I have you
[17:35]  * jdstrand pulls them up
[17:35] <ogra_> note that i'm not officially here :P ... but shoot
[17:36] <jdstrand> these are actually community type questions
[17:36] <jdstrand> ogra_: but please don't let me distract you from life :)
[17:36] <ogra_> well, i'm on sick leave til tomorrow ... but pretty bored so just ask
[17:38] <Chipaca> jdstrand: that's ogra's way of saying, you've just got to make your questions more interesting that his alternatives
[17:38] <jdstrand> ogra_: do you know if there is a way or if we plan to enable via snappy config ubuntu-core to setup remove logging? ie, tell rsyslogd to send its logs to another syslog server? /etc/rsyslog.d is not a writable-path and systemd's journal doesn't do rfc syslog
[17:38] <jdstrand> for me personally, making /etc/rsyslog.d a writable-path would be sufficient
[17:38] <ogra_> lets do that theen
[17:38] <jdstrand> but it sounds mildly interesting as an ubuntu-core config option
[17:38] <jdstrand> ok, I'll file a bug
[17:38] <ogra_> sounds like something thats helpful in IoT cases and such
[17:39] <ogra_> (and the fix is easy enough)
[17:39] <jdstrand> ogra_: next question. I tried to setup a static ip via snappy config ubuntu-core, and was successful. however, I didn't know how to setup the resolver. is that possible?
[17:40] <ogra_> there are /e/n/i options (dns-servers ?) you should be able to use
[17:40]  * ogra_ checks his static snappy server
[17:40] <jdstrand> oh, dns-servers are in there? I read the man page, I must've missed it
[17:41] <ogra_> (amd64)ogra@aleph2:~$ grep dns /etc/network/interfaces.d/eth0
[17:41] <ogra_> dns-nameservers <IP_ADDRESS>
[17:41] <jdstrand> yeah, man interfaces doesn't have it
[17:41] <ogra_> yeah, seems to work here
[17:41] <jdstrand> ok, awesome :) that probably needs a doc update for snappy config...
[17:41] <jdstrand> I'll file a bug on that too
[17:41] <ogra_> well, thats not snappy specific ... i think it is resolvconf that uses it
[17:42] <jdstrand> right
[17:42] <jdstrand> but my point it, it wasn't in 'man interfaces' either
[17:42] <jdstrand> so I had no way to discover it
[17:42] <ogra_> right, if we added it we should have patched the manpage
[17:43] <ogra_> ah, wait
[17:43] <jdstrand> cause it wasn't there or a snappy example. there is a snappy example for static ip (which I used), but it doesn't include dns-nameservers
[17:43] <ogra_> man resolvconf has it
[17:43] <jdstrand> which meant I got an ip address great, but couldn't do much
[17:43] <ogra_> yeah
[17:43] <ogra_> we should add it to the example
[17:43] <jdstrand> I'll file a bug
[17:43] <ogra_> thx
[17:44] <jdstrand> next question: is there a way to setup the ntp servers?
[17:44] <ogra_> hmm
[17:44] <jdstrand> they seem to try to reach out to the pool ones
[17:44] <jdstrand> with no way to point to an internal one
[17:44] <jdstrand> s/internal/another/
[17:44]  * ogra_ reads /etc/network/if-up.d/ntpdate
[17:45]  * jdstrand doesn't have that file on latest snappy stable
[17:46] <ogra_> /etc/default/ntpdate
[17:46] <ogra_> oh ?
[17:46] <ogra_> do we already have timedated ?
[17:46] <jdstrand> I don't have /etc/default/ntpdate either
[17:46] <jdstrand> systemd+   488  0.0  0.0 100276  2532 ?        Ssl  Oct06   0:01 /lib/systemd/systemd-timesyncd
[17:47] <jdstrand> is that the same thing?
[17:47] <ogra_> no, thats the new thing
[17:47] <ogra_> which i dont know much about yet
[17:47] <ogra_> ah
[17:47] <ogra_> it has a -H <host> option
[17:48] <ogra_> now i'm not sure where to configure it ...
[17:48] <jdstrand> I guess that is /etc/systemd/timesyncd.conf
[17:48] <jdstrand> http://www.freedesktop.org/software/systemd/man/timesyncd.conf.html
[17:48] <jdstrand> but it is not a writable-path
[17:48] <ogra_> so we need to add that one too
[17:48] <jdstrand> ok, I'll file a bug for that too
[17:49] <ogra_> yeah, seems you can just set NTP=
[17:49] <ogra_> pointing to a server
[17:49] <jdstrand> the last is sshd_config. it *is* a writable path. I'm just curious if there are plans to do more with it via snappy config
[17:50] <ogra_> that i dont know :)
[17:50] <ogra_> wouldnt be hard to add i guess
[17:50] <jdstrand> well, I'm not trying to create more work
[17:50] <ogra_> it is riteable because cloud-init generates the keys in that dir
[17:50] <jdstrand> even though I did. though just barely :)
[17:51] <ogra_> well, useful work ... everything you asked about is valid :)
[17:51] <jdstrand> cool and thanks-- this was quite helpful
[17:51] <ogra_> :)
[17:51]  * Chipaca adds df to the rest api
[17:51] <jdstrand> ogra_: hope you feel better and try not to be too bored :)
[17:52] <ogra_> i'm fine, i had drilled some screw anchors into my jaw last thu ... recovery is in the last stages
[17:52]  * Chipaca watches the rest api get in a race with systemd for what's left of posix
[17:53] <ogra_> we should fork systemd to systemd-posix
[17:53] <ogra_> ;)
[17:53] <ogra_> seems forking is in fashion currently
[17:53]  * ogra_ just saw the news about mjg59
[18:00]  * ogra_ goes back to icepack->cheek
[21:15] <Chipaca> jdstrand: ogra_
[21:15] <Chipaca> (amd64)ubuntu@localhost:~$ hello-world.env
[21:15] <Chipaca> /writable has 368392 blocks of 4096 bytes available (~93.390998%)
[21:16] <Chipaca> jdstrand: ogra_: http://pastebin.ubuntu.com/12709065/
[21:16] <Chipaca> oh, also matiasb ^
[21:17] <matiasb> nice!
[21:17] <matiasb> Chipaca, how can I use that?
[21:17]  * matiasb looks the pastebin
[21:17] <Chipaca> matiasb: gcc -D_GNU_SOURCE -Wextra -Werror -o /tmp/fakedf /tmp/fakedf.c
[21:18] <matiasb> Chipaca, awesome, will try it when I get a few
[21:18] <Chipaca> matiasb: then, fakedf $SNAPP_APP_DATA_PATH
[21:19] <Chipaca> or fakedf $SNAP_APP_USER_DATA_PATH
[21:19] <Chipaca> s/SNAPP/SNAP/ soz
[21:19] <Chipaca> and apparently that's enough :)
[21:19] <Chipaca> matiasb: also python has statvfs which is the same call, if you're doing python
[21:20] <matiasb> Chipaca, this is for transmission, so C should be
[21:20] <Chipaca> matiasb: and man 3 statvfs for the fields in the struct if you need some other info
[21:21] <matiasb> Chipaca, perfect, thx!
[21:21] <Chipaca> np
[21:21] <Chipaca> maybe we should ship this :)
[21:37] <Chipaca> hah! we already do
[21:37] <Chipaca> /usr/bin/stat
[21:41] <Chipaca> jdstrand: ogra_: (dunno if you're still interested in this, but) e.g. “/usr/bin/stat -f -c "%a * %s" /writable/”
[21:43] <jdstrand> Chipaca: oh, nice! :)
[21:43] <Chipaca> megabytes: echo $(($(/usr/bin/stat -f -c '%a * %s/1024/1024' /writable/)))
[21:43]  * jdstrand add a note to update snappy-security to recommend that
[21:43]  * Chipaca stops


[10:02] <mup> PR snapcraft#3659 closed: meta: add support for hooks <Created by mr-cal> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3659>
[19:58] <Guest11> Hello 🌎


[09:22] <xnox> Wimpress:  may I upload refreshed ubuntu-mate-meta? note that it needs update.cfg adjustment to look at -proposed packages too when germinating https://paste.ubuntu.com/p/JBQ3rYDMrX/
[09:27] <Wimpress> xnox: Yeah, I spotted that the ubiquity panel hadn't migrated from proposed.
[09:27] <xnox> and it will not, until we fix metas =) chicken-egg =)
[09:27] <Wimpress> Ah, OK.
[09:27] <xnox> plus it's nice to have all the pockets in update.cfg anyway, for SRUing new deps / updates.
[09:28] <Wimpress> So -proposed should be remove from update.cfg once everything has migrated?
[09:28] <Wimpress> Or safe to leave?
[09:29] <Wimpress> Thanks for sorting that, I'll let the Ubuntu Budgie guys know what to do.
[09:29] <xnox> safe to leave
[09:30] <xnox> ie. ubuntu-meta has it always
[09:30] <Wimpress> Thanks.
[09:30] <xnox> uploaded
[09:31] <Wimpress> Wonderful. I'll get the QA guys to test the next daily.
[09:32] <xnox> Wimpress:  well not gonna migrate yet.
[09:32] <Wimpress> OK
[09:33] <xnox> Wimpress:  for budgie the question is, if they want to show a panel at all during 'maybe-ubiquity' and 'only-ubiquity' modes. cause it looks like they seed indicators just for that.
[09:33] <xnox> the principal need for panel there, historically was to mimick unity7 UI and to provide add-hoc ability to change keyboard layout at any page of the installer.
[09:41] <Wimpress> Yes, Budgie is different in that regard. The indicators are for Ubiquity only.
[09:41] <Wimpress> bashfulrobot: See the discussion above. Can you ask David to join this channel so he can answer xnox questions.
[10:20] <xnox> in essence we are splitting the panel out of ubiquity-frontend-gtk into a separate universe package, and if panel is desired it should be seeded. Or if panel is not part of the desired installer look & feel, one can drop it.
[10:52] <tmhoang> Hello, for Arch, Debian, Fedora, I can find their build "scripts" and patches at : https://src.fedoraproject.org/rpms/gcc, https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gcc, https://salsa.debian.org/toolchain-team/gcc/tree/master/debian/rules.d. Where could I find the same for Ubuntu ? Is it at : https://code.launchpad.net/gcc ? (I pick gcc as an example).
[10:52] <tmhoang> many thanks
[11:02] <Laney> dear hive mind: would it be acceptable for autopkgtest to write ${RELEASE}-security entries here using the configured mirror? https://salsa.debian.org/ci-team/autopkgtest/blob/master/setup-commands/setup-testbed#L141
[11:02] <Laney> I feel a bit uncomfortable about forcefully inserting security.u.c there
[11:03] <Laney> but I can't remember what the situation is with mirrors carrying -security
[11:26] <sladen> cking: have sent a ubuntu-devel@ reply re: the compression
[11:28] <cking> sladen, ok, i'll try and get that done sometime in the next week or so
[11:28] <sladen> cking: it's more than my hunch is that there's likely to be a better solution that adding-more-code
[11:29] <xnox> tmhoang:  that url for gcc is for the "upstream" rather than ubuntu packaging. You probably want something like this: https://code.launchpad.net/ubuntu/+source/gcc-8
[11:31] <tmhoang> xnox: thanks ! Are 'Ubuntu packaging' packages start at prefix https://code.launchpad.net/ubuntu/ ?
[11:31] <xnox> tmhoang:  most but not all.
[11:31] <xnox> tmhoang:  some projects where ubuntu is upstream are at top-level, or even at github. or both!
[11:31] <tmhoang> ah interesting
[11:31] <xnox> tmhoang:  e.g. launchpad.net/ubiquity
[11:32] <tmhoang> good point. many thanks
[11:32] <xnox> github.com/CanonicalLtd/subiquity
[11:32] <xnox> etc.
[11:38] <xnox> sladen:  hmmm.... are you implying that the order of cpio members matters? =)))) as in, initrd will boot faster if busybox is first, init second, and the rest of things are in the exec order?
[11:41] <sladen> xnox: think one needs data ... but if the CPIO can be ordered, and files made available as soon as they are ready (rather than waiting for $everything to be decompressed), there would be the potential for a win there too---but *only* if the code is setup for returns files/object when they are ready
[11:42] <sladen> xnox: the stream decoders do not parallise well;  bzip2 is a block decoder: so when can decode multiple blocks in parallel on separate CPUs
[11:43] <sladen> xnow: so there is probably a local maxima for Bzip2 using eg 100kB blocks and 30 CPUs in parallel
[11:44] <xnox> i wonder if i can experiment with like shuffling init to be the last cpio archive member and like for it to be the very first one.
[11:44] <xnox> to see if there is a significant difference.
[11:44] <xnox> cause it would be behind all the kernel modules, and firmware blobs
[11:49] <sladen> xnox: there are two potential wins: (1) re-ordering similiar file content to be <32kB distant gives compression benefits;  (2) if the code was adjusted to 'stream'/return partial results; then it would unblock lots of downstream processes
[13:37] <xnox> vorlon:  Laney: is new systemd killing virtual machines, or is lcy cloud not nice? i see kernel traceback unable to mount rootfs on reboot.... but then it does show login prompt<EMAIL_ADDRESS>[13:39] <xnox> ditto i386<EMAIL_ADDRESS>[13:41] <Laney> xnox: i dunno, looks like the restart doesn't go very well though
[13:42] <Laney> there's still recent passes on other releases, e.g.: http://autopkgtest.ubuntu.com/packages/systemd/bionic/amd64 http://autopkgtest.ubuntu.com/packages/systemd/bionic/i386 http://autopkgtest.ubuntu.com/packages/systemd/cosmic/i386
[13:44] <Laney> does it happen on your system with qemu? if not, you should still have access to the cloud to run things there
[15:12] <tmhoang> I'm building a package using CMake. Does debian/rules has an option to build with debug info or I have to add something like -DCMAKE_BUILD_TYPE=RelWithDebInfo in debian/rules ?
[15:16] <xnox> tmhoang:  normally, debug symbols are built and stripped into .ddeb
[15:16] <tmhoang> I'm running : dpkg-buildpackage -j4 -uc -us and see that CXXFLAGS=-g -O2 by default. I wonder where that debugging option is set
[15:16] <xnox> tmhoang:  you can keep the debug symbols intact, it's normally done with DEB_BUILD_OPTIONS=nostrip debuild
[15:16] <xnox> to keep all debug stuff attached
[15:17] <tmhoang> xnox: I think I would stick with 2nd option instead of .ddeb. I have not used them before :(
[15:18] <xnox> tmhoang:  we strip debug symbols into .ddebs such that anyone can install all debug symbols for all the packages
[15:18] <tmhoang> understood
[15:18] <xnox> https://wiki.ubuntu.com/Debug%20Symbol%20Packages
[15:18] <xnox> for more details
[15:19] <tmhoang> so, I guess something like : DEB_BUILD_OPTIONS += nostrip should work
[15:20] <xnox> tmhoang:  in debian/rules ?! no, not allowed to do that
[15:20] <xnox> DEB_BUILD_OPTIONS is explicitely build-environment controlled.
[15:20] <xnox> it's for end-users to rebuild things
[15:20] <xnox> tmhoang:  instead one would override dh_strip to not strip them
[15:21] <xnox> but that's non-standards compliant / non-suitable for ubuntu/debian
[15:21] <xnox> i.e.
[15:21] <xnox> override_dh_strip:
[15:21]  * xnox just that ^ will be enough to short circuit dh_strip
[15:22] <tmhoang> ah I saw it now. Many thanks. Also this is for dev so I'd ignore standards :D
[16:51] <ddstreet> xnox your boot-smoke addition of --wait should remove the while loop, and also will make the test hang forever (until adt timeout) if is-system-running never becomes true
[16:54] <ddstreet> xnox Laney re: unable to mount root, it's also booted with panic=-1 so something seems to be booting the kernel without the initrd with the intention for it to panic and reboot, at least that's my best guess, i don't know why else it would be booting with panic=-1
[16:55] <xnox> vorlon:  ^
[16:56] <vorlon> "something seems to be booting" - yes, all the cloud images disco and later have this
[16:57] <vorlon> and as we expect the cloud images to be using linux-generic which is not guaranteed to boot initramfsless in KVM, the normal boot path includes 2 reboots
[17:01] <ddstreet> makes sense, assuming the first initramfsless boot works some of the time, i suppose.  note that upstream systemd (or at least whoever opened the bug from upstream) doesn't appear aware of that, you might want to mention in lp #1829829 that the first panic=-1 boot is expected and ok
[20:51] <xnox> ddstreet:  no, not expected and not ok
[20:51] <xnox> ddstreet:  expectation for cloud images is to successfully boot initrdless
[20:52] <xnox> vorlon:  well
[20:52] <xnox> vorlon:  we build a custom image for autopkgtest..... and we do expect it to boot.....
[20:52] <xnox> vorlon:  so clearly our autopkgtest image building is wrong?!
[20:52] <vorlon> xnox: we expect it to /boot/.  but we also expect it to boot the kernel twice before it gets to userspace, based on the fact that it will fail to boot initramfsless
[20:53] <vorlon> unless I'm forgetting something
[20:54] <xnox> vorlon:  well, but over nova api that trips the state up of autopkgtest, no? cause "yeap booted", "oh no, no network", "meanwhile it booted the second time fine"
[20:57] <vorlon> xnox: AFAIK autopkgtest doesn't depend on nova api to determine whether a system is booted
[20:58] <vorlon> we might issue a reboot command via nova, but then it's polling for the system to come up
[20:58] <vorlon> and a double-reboot should have no impact on networking
[21:01] <xnox> hmmm
[21:04] <xnox> vorlon:  i don't understand the point of a cloud image that always boots twice.
[21:04] <xnox> and always will......
[21:05] <vorlon> xnox: we will have KVM-specific cloud images that use linux-kvm and don't boot twice.  I'm unsure if we would want that in the autopkgtest instances though
[21:06] <vorlon> xnox: and "always boots twice" is certainly not a feature
[21:06] <vorlon> but having initramfs+fallback by default is
[21:09] <xnox> right
[21:09] <xnox> how do i opt out of that?
[21:10] <vorlon> xnox: something something grub.d
[21:10] <xnox> cause we  customize cloud image for autopkgtests, i thought
[21:10] <xnox> let me check the somethings
[21:10] <vorlon> :)
[21:14] <xnox> GRUB_FORCE_PARTUUID=
[21:14] <xnox> i think
[21:15] <xnox> vorlon:  tyring initrdless boot should a properly of a kernel.
[21:15] <xnox> vorlon:  it makes sense for flavours, it doesn't make sence for generic
[21:16] <xnox> and i do understand that we have more flavour type of kernel.
[22:26] <Eickmeyer>  We (the Ubuntu Studio team) now have two packages that need sponsoring.  (bug 1829562 and bug 1831154)
[22:26] <Eickmeyer> Somebody PLEASE take a look at these.