[08:26] <ovidiu-florin> ahoneybun: you around?
[08:44] <Riddell> ovidiu-florin: what happened to the people willing to sponsor digital ocean servers for us?
[08:45] <ovidiu-florin> do we have a server where I can deploy a docker container? it requires at leaset kernel 3.4. I want to setup a pootle server in it, for translating the Kubuntu manual. And also use it for reasearch on implementing it in KDE.
[08:46] <ovidiu-florin> Riddell: let me check on that mail thread
[08:46]  * ovidiu-florin cursed akonadi again
[08:46] <ovidiu-florin> surses*
[08:46] <ovidiu-florin> curses**
[09:35] <lordievader> Good morning.
[10:13] <ovidiu-florin> Morning lordievader
[10:14] <lordievader> Hey ovidiu-florin
[10:14] <ovidiu-florin> ahoneybun: RO translation is finished for DVD cover.
[10:15] <ovidiu-florin> ahoneybun: please don't forget to redo the text round on the label for both EN and RO.
[10:15]  * ovidiu-florin flies away
[10:56] <mparillo> Both the youtube review and the KDE Connect article are shared on G+ https://plus.google.com/u/0/b/107577785796696065138/107577785796696065138/posts
[11:05] <mparillo> Also tweeted: https://twitter.com/kubuntu
[11:06] <mparillo> Thanks for the links. Will try to add to wire.kubuntu.org, but it seems down for me.
[11:57] <ovidiu-florin> mparillo: thank you
[13:03] <BluesKaj> Hi folks
[13:11] <ranveeraggarwal> ximion: ping
[13:28] <ximion> ranveeraggarwal: pong
[13:29] <ranveeraggarwal> ximion: I was experimenting with qpk. Everything is working fine, except when I'm testing it out, I'm stuck on one thing
[13:29] <ranveeraggarwal> ximion: What exactly would the format of packageID be?
[13:30] <ximion> ranveeraggarwal: http://www.freedesktop.org/software/PackageKit/gtk-doc/concepts.html#introduction-ideas-packageid
[13:31] <ximion> so, when you have a package-name, you will need a Resolve() call to resolve it to a package ID
[13:32] <ranveeraggarwal> ximion: and package names would be same as what you have with apt/yum?
[13:33] <ximion> yes and no - of course APT/RPM also have something similar to a PK pid
[13:33] <ximion> a package-id is basically a package-name;version;repo triplet, so contains more information that just a simple name
[13:34] <ximion> this is important if a package is available from multiple sources, or on updates, where you have one version available and one version installed
[13:34] <ximion> a pid is a unique identifier for a package, while a package-name is, well, the name of a package
[13:34] <ximion> hope that makes sense to you
[13:35] <ranveeraggarwal> ximion: yup! Thanks
[19:31] <ahoneybun> yay ZNC is back up
[19:32] <ahoneybun> hey all https://plus.google.com/+OvidiuFlorinBogdan/posts/Z2hpvqYB7jv
[19:32] <ahoneybun> some DVD prototype thanks to ovidiu-florin
[20:32] <clivejo> ahoneybun: how does it stay together?
[20:32] <ahoneybun> clivejo: I'm not to sure how he did it
[20:32] <clivejo> looks good :)
[20:32] <ahoneybun> thanks :)
[20:32] <ahoneybun> will be better in color
[20:33] <valorie> pretty good in B/W
[20:33] <ahoneybun> thanks valorie
[20:33] <valorie> looks like he printed paper and glued it on cardstock
[20:33] <valorie> if we print them, we can just do it on the cardstock
[20:34] <clivejo> wish I could get my Epson Color Laser working in Wily
[20:34] <valorie> 2 folds, 2 strips of glue
[20:34] <clivejo> Id print a few CD/DVD labels
[20:35] <ahoneybun> valorie: I'm getting Canonical to make some for akademy
[20:35] <valorie> wow, how?
[20:35] <ahoneybun> mhall
[20:36] <ahoneybun> well their looking at pricing I should say
[20:36] <valorie> so like, they print, we make the DVDs?
[20:37] <ahoneybun> maybe, not sure
[20:37] <ahoneybun> might be how the DVDs I have of Ubuntu are made
[20:37] <ahoneybun> they handle it all
[20:37] <ahoneybun> not sure
[20:41] <valorie> thanks for asking, ahoneybun
[20:41] <ahoneybun> valorie: If I remember right it was a bit of mhall's idea as well
[20:41] <ahoneybun> not mine alone
[21:04] <clivejo> ahoneybun: how much are they working out to replicate?
[21:05] <ahoneybun> clivejo: how many to make?
[21:05] <clivejo> like cheapest price per unit?
[21:08] <valorie> we certainly don't need many for Akademy
[21:08] <valorie> they will only be a collectible
[21:08] <ahoneybun> he said anything under 100 would be a lot
[21:10] <ahoneybun> plus I can just hand the rest out at Fossetcon and other Ubuntu related events I'm at
[21:10] <ahoneybun> or host
[22:06] <valorie> sure, but it isn't an LTS
[22:06] <valorie> so it has a shelf life
[22:27] <ahoneybun> of course yea
[22:27] <clivejo> hummmm kdenlive is crashing on my wily install
[22:28] <ahoneybun> should we not make them at all valorie?
[22:57] <valorie> ahoneybun: if you want to have a table and give them out, that would be lovely
[22:58] <ahoneybun> at akademy?
[22:58] <valorie> yes
[22:58] <valorie> and if so, ask on the akad ml
[22:58] <ahoneybun> sure but I need someone else so we can take shifts
[22:58] <ahoneybun> lol
[22:59] <valorie> it will give us a place to gather
[22:59] <valorie> and of course
[23:00] <valorie> mostly you need a person first thing, lunch-time, and any longer breaks
[23:00] <valorie> play it by ear
[23:02] <ahoneybun> I don't have a problem maning it I just might want to see a session or something
[23:02] <ahoneybun> and walk around
[23:02] <valorie> certainly
[23:03] <valorie> it doesn't have to be staffed all the time
[23:03] <Riddell> I don't know if we get a table, you need to be a sponsor and I don't know what level blue systems is sponsoring at this year
[23:04] <Riddell> you'd need to check with sebas and seaLne I guess
[23:05] <ahoneybun> valorie: only found this one: https://mail.kde.org/mailman/listinfo/akademy-br
[23:06] <valorie> https://mail.kde.org/mailman/listinfo/akademy-attendees
[23:07] <valorie> or we can put them on the Blue Systems table I suppose
[23:09] <ahoneybun> makes sense
[23:10] <shadeslayer> I should really really book my tickets
[23:10] <shadeslayer> and BS table?
[23:10] <shadeslayer> I didn't realize we had a table


[04:15] <JohnFlux> Hey all
[04:16] <JohnFlux> It would be nice if the upstart library was installed with upstart on distros
[04:17] <JohnFlux> so that people can use the upstart program
[04:17] <JohnFlux> i mean use the upstart library from their programs
[11:42] <JohnFlux_> Hey all
[11:43] <JohnFlux_> anyone around?


[08:06] <LocutusOfBorg> seb128, I might have some patch soon for xpdf, I would appreciate if you can just review it
[08:08] <seb128> LocutusOfBorg, k
[08:17] <LocutusOfBorg> patch mostly finished
[12:57] <juliank> I extended bug #1825972 to cover some more old gnome 2 packages without reverse deps (gnome-vfs, libbonobo, libbonoboui, libgnome, orbit2)
[12:58] <juliank> Initially filed only to get libgnome-keyring out, I today realized that the whole gang can go
[17:29] <GunnarHj> Hi bdmurray, would you have time to look at bug #1825733 again? I submitted a couple of debdiffs.
[17:35] <bdmurray> GunnarHj: Do you want to fix bug 1727472 at the same time?
[17:41] <GunnarHj> bdmurray: I'm afraid that I don't know enough about gtk and qt to do that, sorry. I suppose the strings would need to me moved from respective .ui file to python. So I think it would be good if the qt oversight could be fixed separately.
[17:44] <bdmurray> GunnarHj: okay, I'll get the eoan change uploaded the disco one might be a bit as there is a current SRU
[17:46] <GunnarHj> bdmurray: That would be a good first step. As I stated in the bug report, I'm not 100% sure that the change is sufficient. But having it in eoan will make it possible to test Kubuntu 19.04->19.10 upgrades at least.
[21:10] <GunnarHj> bdmurray: autopkgtest complaint for update-manager:
[21:10] <GunnarHj> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-release-upgrader
[21:38] <ddstreet> vorlon you might not remember, but it looks like you added a patch to sudo to keep HOME in the keep_env list, way back in 2011 (so that running 'sudo' doesn't change $HOME by default, without -i or -H)...do you remember what the reason for setting that as default was?  I'm just curious as to why
[21:38] <vorlon> ddstreet: I only know that the changelog points to LP: #760140
[21:39] <ddstreet> ah! thnx, i was git blaming the patch to see how far back it was added, should have checked the changelog for that release
[21:40] <ddstreet> vorlon do you still agree with that decision?  it has some unfortunate side effects, like sudo-run applications creating root-owned files/dirs in $HOME
[21:41] <vorlon> ddstreet: I will not attempt to defend that decision 8 years later :)
[21:41] <ddstreet> lol
[21:41] <vorlon> things have moved on and there's certainly a new normal in terms of sudo expected behavior elsewhere
[21:41] <ddstreet> vorlon i suppose an email to ubuntu-devel would be best if i wanted to revive the discussion
[21:42] <vorlon> sounds good to me
[21:58] <connor_k> How can I increment a package version in just an older release (backporting something to Bionic) such that if they were to upgrade to Cosmic they wouldn't be forced to remain on the Bionic version (because it's now technically greater than the one in Cosmic)?
[21:59] <connor_k> Otherwise before the change, both packages are the same version number in Bionic and in Cosmic
[22:00] <tyhicks> I was talking with connor_k about this previously and don't have any good ideas myself
[22:01] <tyhicks> to give a specific example, he needs to SRU some patches that back to Bionic's ndiswrapper, but not Cosmic's, in order to let the module build with hwe kernels
[22:02] <tyhicks> the problem is that Bionic and Cosmic ndiswrapper are both at 1.60-6
[22:06] <tyhicks> bah... s/SRU some patches that back to/SRU some patches back to/
[22:07] <tyhicks> infinity, bdmurray: I feel like one of you two might have some solid advice here for connor_k ^
[22:07] <infinity> Without backporting to both releases, you can't achieve what you want.
[22:07] <infinity> (Well, uploading to both, at least)
[22:07] <infinity> Is there harm in cosmic having the same fixes?
[22:07] <tyhicks> I didn't think so but is it acceptable to only upload to Bionic in this case?
[22:08] <tyhicks> infinity: no harm other than needless risk of regression
[22:08] <infinity> It wouldn't particularly hurt anything to upload just to bionic either.
[22:08] <tyhicks> that was my feeling, too
[22:08] <infinity> Or, upload to bionic, verify, then binary copy forward to cosmic too, if one really cares about the version oops.
[22:09] <infinity> Once cosmic goes EOL, these sorts of version disparities happen all the time anyway.
[22:09] <tyhicks> exactly and cosmic EOL isn't far away
[22:09] <infinity> Cause someone will backport $pkg from $devel to bionic and disco, but cosmic is closed.
[22:10] <infinity> It's 2.5 months out.  That's far enough. :P
[22:10] <infinity> But if the patches are useless in cosmic anyway, it's all a bit of a meh.
[22:10] <tyhicks> after talking it over, I feel comfy enough sponsoring connor_k's upload only to bionic as this is a pretty harmless version oops (I wouldn't want to do it to an LTS release)
[22:11] <tyhicks> thanks
[22:11] <connor_k> infinity, tyhicks thanks!


[23:45] <nacc> ioc_: i really don't know, though
[23:53] <TJ-> airos: is the AHCI driver loaded? "lsmod | grep ahci"
[23:53] <airos> TJ-: lsmod is not available
[23:54] <TJ-> airos: hehehe OK "grep ahci /proc/modules"
[23:54] <airos> TJ-: no ahci
[23:54] <TJ-> airos: fingers crossed yours is AHCI then: "modprobe ahci"
[23:55] <TJ-> airos: then "dmesg | tail" and see if sda was found
[23:56] <airos> TJ-: there is no new message. I juste see message about sda when I connected my usb key (and message about sdb when I connected the second one)
[23:57] <TJ-> airos: OK, if found it'd get another drive letter. I'm trying to find an "lspci" output for that model on the web but not found it so far, to see what the disk controller is supposed to be


[16:45] <Brainstorm> Updates for Bangladesh: +7264 cases, +41 deaths, +42867 tests (16.9% positive) since a day ago


[04:09] <daftykins> uuuuuuuuuugh why did i click =|
[04:37] <lotuspsychje> EriC^^: morning
[04:38] <daftykins> o/
[04:38] <lotuspsychje> daftykins: hellow :p
[04:38] <daftykins> morning sir
[04:38] <daftykins> ugh you missed one of the lower points of the channel =|
[04:38] <daftykins> a bloody spammer linked to child porn again =|
[04:38] <lotuspsychje> what happened
[04:38] <lotuspsychje> ouch
[04:38] <lotuspsychje> who banned him?
[04:39] <daftykins> i did an !ops and thankfully Flannel showed up
[04:39] <lotuspsychje> why they always choose ubuntu to spam lol
[04:39] <daftykins> it's weird isn't it? ##windows i can imagine
[04:39] <daftykins> something genuinely hated
[04:39] <lotuspsychje> lol
[04:40] <daftykins> but volunteers helping for free for a Linux distro, just don't get it
[04:40] <lotuspsychje> maybe MS hired freaks to spam haha
[04:40] <daftykins> there are those who don't like the way the channel is run, of course
[04:40] <daftykins> XD
[04:41] <lotuspsychje> we are getting power worldwide with ubuntu now
[04:41] <lotuspsychje> some might not be happy about that
[04:41] <daftykins> the pretentious might have a problem with the masses using Linux yeah
[04:42] <daftykins> i've attracted a few fans in my time that come in just trying to troll me, that's for sure
[04:42] <lotuspsychje> lolz
[04:43] <daftykins> it's funny, sometimes you can spend 3 hours straight helping someone get ubuntu installed on their machine
[04:44] <daftykins> but a next user comes in and you call them out for being too lazy to even google their problem - and you get a fan for life :P
[04:44] <lotuspsychje> yeah i never get that
[04:44] <lotuspsychje> loool
[04:44] <daftykins> not sure if you have this phrase us Brit-ish types do, "no good deed goes unpunished"
[04:45] <lotuspsychje> well at the end we have a good felling upon ourselfs thats the only thing that matters to me
[04:46] <daftykins> mmm, puzzle solving can be ace
[04:46] <lotuspsychje> and we learn much ourselfs
[04:47] <daftykins> definitely - i mean i don't even USE ubuntu 8D
[04:47] <lotuspsychje> oh really
[04:47] <daftykins> desktop anyway ;D
[04:47] <lotuspsychje> wich distro?
[04:49] <daftykins> *cough* Windows
[04:49] <lotuspsychje> :p
[04:50] <daftykins> my ubuntu exposure is primarily servers
[04:50] <lotuspsychje> you game?
[04:51] <daftykins> mostly on consoles as i have friends too poor to buy PCs :)
[04:51] <daftykins> nah the majority of my work remains on Windows desktops so that's where my skills must stay
[04:52] <lotuspsychje> ic
[04:52] <daftykins> although it's a little worrying that i can still suggest reasonable solutions to Linux desktop queries people in other channels have, even when surrounded by people who use Linux desktops 24/7
[04:53] <daftykins> e.g. someone installed Linux for their mother back home, wanted to setup remote access... but that mother still took her laptop out and about occasionally
[04:53] <daftykins> so i said configure a static IP for the home wifi network via network manager
[04:53] <daftykins> nobody else had a clue :(
[04:53] <daftykins> i feel bad for kind of "ringing my own bell" there as we say, but it just shocked me that 24/7 Linux desktop types had no idea how to tackle that problem
[04:54] <lotuspsychje> :p
[04:55] <lotuspsychje> i try a mix of windows and ubuntu, but prefer to install ubuntu as its a long term solution
[04:55] <daftykins> there is that, all the people i help are locked into some proprietary software or another though
[04:55] <daftykins> and i would never put ubuntu in for anyone because i simply couldn't support it without using it myself
[04:55] <lotuspsychje> some ppl also dont understand ubuntu
[04:56] <lotuspsychje> but most multimedia use, have no troubles
[04:57] <lotuspsychje> my dad is 78 and never managed to crash ubuntu desktop yet :p
[04:57] <lotuspsychje> before i had to come fix windows every month
[04:58] <daftykins> i just remember back in the gnome 2 era, pre unity, when ubuntu couldn't even keep panel elements in the same places between boots
[04:58] <lotuspsychje> lol
[04:58] <daftykins> bit shocking :/
[04:58] <lotuspsychje> we come a long way indeed
[04:59] <lotuspsychje> i remember strugling on old redhat cdroms to get my internet working
[04:59] <lotuspsychje> but it fascinated me alot
[05:03] <daftykins> :D
[05:04] <daftykins> shared internet connections behind routers with wired or wifi definitely made it way easier for the modern generations
[05:04] <lotuspsychje> yeah true
[05:04] <daftykins> i think the first Linux i played with i was just missing my music collection
[05:04] <lotuspsychje> amarok :p
[05:07] <daftykins> i think it was stick on separate disks at the time
[05:07] <daftykins> and being too newb i would've had no idea how to mount some NTFS volume, if you even could back then
[05:07] <lotuspsychje> lolz
[05:13] <lotuspsychje> lol
[05:14] <lotuspsychje> http://news.softpedia.com/news/The-World-s-First-Ubuntu-Powered-Drone-is-Here-Video-480010.shtml
[08:51] <lordievader> Good morning.
[11:44] <BluesKaj> Hiyas all


[01:44] <handsome_feng> Hi, could someone have a look at LP: #1873543?
[06:48] <handsome_feng> Good morning, seb128, Could you have a look at LP: #1873543? I saw your name in the changelog, :)
[06:53] <seb128> handsome_feng, hey, what locale is that about?
[06:53] <seb128> zh_CN?
[06:57] <handsome_feng> seb128: Yes
[07:01] <seb128> handsome_feng, those strings are not listed in launchpad for translations, unsure how you got those translated before? I commented on the bug
[07:04] <handsome_feng> seb128: I translated those strings locally and then submitted the PR request... Now I think I should submit the translations to the launchpad...
[07:05] <seb128> handsome_feng, yes you should
[07:06] <handsome_feng> Is there a temporary solution？Or should I submit those translations to launchpad right now?
[07:06] <seb128> local changes get overriden when a proper export happens
[07:07] <seb128> handsome_feng, I've uploaded an updated template to launchpad, those strings should be translatable soon in the web interface
[07:08] <handsome_feng> seb128: Fine, I will do that ASAP, thanks!
[07:32] <LocutusOfBorg> wgrant, I'm pretty sure llvm-10 gets stuck
[07:32] <LocutusOfBorg> look:
[07:32] <LocutusOfBorg> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4023/+build/19167215
[07:32] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/llvm-toolchain-10/1:10.0.0-3/+build/19151969
[07:32] <LocutusOfBorg> they differ of one day in start building and they are stuck on the same page?
[07:32] <wgrant> LocutusOfBorg: Pretty sure they'
[07:32] <wgrant> re not stuck
[07:32] <wgrant> The test suite is just very quiet
[07:33] <wgrant> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4029/+build/19180814 is building with the test suite disabled, in case they don't eventually finish
[07:33] <wgrant> But I've had it run the test suite fine before
[07:38] <LocutusOfBorg> ack
[07:40] <LocutusOfBorg> nice to know, in any case the 4build1 on ci is one day ahead of the one in archive...
[07:45] <handsome_feng> seb128: Done, :)
[07:56] <seb128> handsome_feng, looks like you only did suggestions there, you are not part of the translators? you need to find an official member of the chinese translation team to approve those
[07:59] <handsome_feng> seb128:  Ok, I will try to find one now
[08:27] <handsome_feng> seb128: Done again! :)
[09:50] <wgrant> fo0bar: The riscv64 sshd hang is a bug in qemu 4.2. 4.1 or master are fine; https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1872945 has details.
[09:52] <cjwatson> Oh good, I'm glad that wasn't somehow openssh's fault
[10:00] <wgrant> The sshd test case was by far the quickest and made the bisect much more viable.
[12:53] <ahasenack> cjwatson: hi, looks like you TIL libfido2 in debian, could you check, or ask nicoo to take a look at https://salsa.debian.org/auth-team/libfido2/-/merge_requests/4 please?
[13:22] <cjwatson> ahasenack: I've left you some comments
[13:23] <ahasenack> ok
[13:24] <cjwatson> (and have fixed my notification settings for that repository, so I should receive further stuff by email)
[14:26] <cpaelzer> zyga: you asked on 1873004 to  "check with "snap changes" if there was a corresponding refresh"
[14:27] <cpaelzer> zyga: but that only tells me if ther currently is one
[14:27] <cpaelzer> how can I make it look back in time?
[14:27] <cpaelzer> --help output wasn't very helpful ont his particular question :-/
[14:40] <zyga> cpaelzer: hey
[14:40] <zyga> cpaelzer: it can, with snap changes you see the history as well
[14:41] <zyga> cpaelzer: but not that much sadly, as we recycle and remove entries rather quickly
[14:42] <cpaelzer> zyga: I have added on the bug what I could find otherwise now
[14:42] <cpaelzer> thanks for the answer
[14:42] <zyga> cpaelzer: thanks
[15:32] <TJ-> I think there's a critical regression in the X-related libraries affecting (at least) amdgpu. With multiple monitors positioned left or right (not above or below) the displays have a blocked staircase effect. I suspected libxcomposite but downgraded that without effect. Currently suspecting libxcb. (both have had recent new upstream releases). Related bug report:
[15:32] <TJ-> https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/10
[15:37] <fo0bar> wgrant: cjwatson: cool thanks.  fwiw, this weekend I noticed strace became available and briefly tested...  and sshd worked fine (albeit slowly) under strace.  I yelled about a watched pot and planned to follow up today
[15:38] <wgrant> fo0bar: Having strace (albeit only in -updates) is indeed handy. Interesting that it fixed sshd. I wonder if it caused mstatus to be dirtied more often.
[15:38] <TJ-> tjaalton: is this ^^^ something you would have a clue about? The common thread seems to be the recently upgraded (since early April) libx* packages
[15:48] <TJ-> tjaalton: Bug #1873895
[16:47] <tjaalton> hardly likely
[17:35] <Beret> I'm seeing DNS issues with a machine after updating focal last night - other machines work fine so it's something specific with this focal machine. Is anyone seeing anything similar?
[17:35] <Beret> resolver issues?
[19:00] <teward> !dmb-ping
[19:23] <Trevinho> doko: hey, have you tested if mutter in focal finally fixed your issue? as I wrote and uploaded the fix in https://launchpad.net/ubuntu/+source/mutter/3.36.1-3ubuntu2 :)
[19:42] <doko> Trevinho: cool, I'll test tomorrow
[20:24] <LocutusOfBorg> wgrant, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4023/+build/19167215
[20:24] <LocutusOfBorg> build killed after 1500 minutes of inactivity.
[20:25] <LocutusOfBorg> seriously? 1 day and one hour and then boom?
[20:25] <LocutusOfBorg> so it seems to be not a slow build, but a stuck one to me
[20:25] <LocutusOfBorg> (unless we need more ram/swap and so on)


[09:45] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #1928: SUCCESS in 57 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/1928/
[09:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #1928: SUCCESS in 1 min 1 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/1928/
[09:48] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #1928: SUCCESS in 3 min 51 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/1928/
[09:59] <BluesKaj> Hiyas all
[15:45] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #1929: SUCCESS in 54 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/1929/
[15:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #1929: SUCCESS in 1 min 0 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/1929/
[15:48] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #1929: SUCCESS in 3 min 42 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/1929/
 @CliffordTheBigRedDoggie have you done copyright on gcompris-qt lately?
 Nope
 Alright.
 @ca
 oops
 Also @CliffordTheBigRedDoggie, would you mind if I upstreamed our sddm changes to Debian and synced once it's uploaded?
 (if it's possible)
 I would mind
 Maybe it isn't possible, but I'd like to upstream as much as possible and just merge from Debian
 @acheronuk, How so?
 They have patches to suit their themeing
 I do mind, but past caring to be honest
 Maybe you can try, but if you break Kubuntu's greeter, be warned I will bring back a delta :P
 Ok :P


[15:32] <braedy> Is there still no easy way to run a script on start up as a user?
[17:20] <duvnell> despite all the people in this channel.. I asked a question yeterday and you're the first person to speak in this channel


[17:53] <Geochr> Hi all, i create a bug for puplishing pdf files on ubuntu software center, check below
[17:53] <Geochr> https://bugs.launchpad.net/ubuntudeveloperportal/+bug/1077176
[17:53] <ubot2> Launchpad bug 1077176 in Ubuntu App Developer site "Faster procedure for publishing magazines (.pdf)" [Undecided,New]


[07:01] <zyga-ubuntu> mvo: hello
[07:01] <zyga-ubuntu> mvo: how are you doing?
[07:02] <zyga-ubuntu> mvo: I updated the mini-lab, the dragon board now has a HDD and swap so should be suitable for more tasks
[07:02] <mvo> hey zyga-ubuntu - good monring. I'm doing well, how are you?
[07:02] <zyga-ubuntu> mvo: I also made ssh keys sync hourly, though not to each device yet (just to the ssh hop)
[07:02] <zyga-ubuntu> mvo: I'm iterating on layouts and feeling good :-)
[07:02] <zyga-ubuntu> mvo: the damp weather is a good motivator to keep warm and code :)
[07:03] <zyga-ubuntu> mvo: I will also add power control to dragon-1, it's already wired but not scripted yet
[07:03] <zyga-ubuntu> mvo: how are your purchases going?
[07:05] <zyga-ubuntu> mvo: while not perfect I found a working way to have home on an external HDD on ubuntu core
[07:05] <mvo> zyga-ubuntu: nice progress! no news on purchases, still pondering
[07:05] <zyga-ubuntu> mvo: same with swap support
[07:05] <mvo> zyga-ubuntu: oh, nice, how do you do it?
[07:05] <zyga-ubuntu> mvo: I created two systemd mount units
[07:06] <zyga-ubuntu> mvo: ssh and have a look, it's remarkably working fine :)
[07:06] <zyga-ubuntu> mvo: I ran some tests on it overnight and I have an idea
[07:06] <zyga-ubuntu> mvo: when idle it could just pull master and run tests in a loop
[07:06] <zyga-ubuntu> mvo: and report failures
[07:06] <zyga-ubuntu> mvo: I saw a few things like "settle" something fail because of timing
[07:07] <zyga-ubuntu> mvo: also noticed that the board only reports 0.7GB RAM, I suspect the rest is used up by GPU, modems and what not
[07:07] <zyga-ubuntu> mvo: and I wanted to ask ogra if that could be tweaked for a headless builder
[07:08] <mvo> zyga-ubuntu: interessting. I have a look in a bit once I finished look at PRs, mail etc :)
[07:08] <zyga-ubuntu> mvo: sure :)
[07:21]  * zyga-ubuntu -> breakfast
[07:22] <sborovkov> ogra_: btw. commenting out that stuff in the psplash.c. It actually does not disable psplash-write. So may be you should disable it as well. When psplash-write is called text is drawn just as expected.
[07:32] <zyga-ubuntu> re
[07:32] <zyga-ubuntu> pstolowski: hello
[07:32] <zyga-ubuntu> pstolowski: question, there's a debian bug report about missing manual page for snapctl
[07:32] <pstolowski> zyga-ubuntu, good morning!
[07:33] <zyga-ubuntu> pstolowski: would you like to write one in restructured text like some of our other manual pages?
[07:36] <pstolowski> zyga-ubuntu, sure. do we generate man pages from built-in help?
[07:41] <zyga-ubuntu> pstolowski: I think that's largely insufficient, look at the manual page for snap-confine for instance
[07:41] <zyga-ubuntu> pstolowski: the help part is really one element
[07:41] <pstolowski> zyga-ubuntu, ok, will do, just looked at .spec for fedora and saw man page generated from snap --man tere
[07:41] <pstolowski> *there
[07:42] <zyga-ubuntu> pstolowski: that's not the same, again
[07:42] <zyga-ubuntu> pstolowski: unless you have 10s of options I really strongly encourage you to write it manually
[07:44] <pstolowski> zyga-ubuntu, okay. snap-confine.rst it is
[07:45] <zyga-ubuntu> pstolowski: thanks, I'll gladly help if you need anything
[07:46] <pstolowski> thanks zyga-ubuntu
[08:20]  * zyga-ubuntu fights the 14.04 battle
[08:21] <zyga-ubuntu> mvo: would it be possible to build snapd with golang 1.6 like on 16.04?
[08:21] <zyga-ubuntu> mvo: I just got a failure about C99 constructs that are probably because of older golang defauls
[08:21] <mvo> zyga-ubuntu: on 14.04? we use a backported go-1.6
[08:21] <mvo> zyga-ubuntu: bug of course there is an older gcc there
[08:21] <zyga-ubuntu> mvo: aah
[08:22] <zyga-ubuntu> mvo: that makes sense!
[08:22] <zyga-ubuntu> thank you
[08:23] <zyga-ubuntu> well, one more rn
[08:23] <zyga-ubuntu> *run
[08:27] <ogra_> zyga-ubuntu, you can turn off the GPU ram but wont be able to run accellerated graphics stuff... just drop the last line in /booot/uboot/config.txt
[08:27] <zyga-ubuntu> ogra_: oh, thank you
[08:27] <zyga-ubuntu> ogra_: do you think that would make sense as a core config option?
[08:27] <ogra_> sborovkov, perfect, yeah, i''ll do that
[08:28] <ogra_> zyga-ubuntu, probably ... we need to have it on by defautl so trhat mir works thugh
[08:30] <zyga-ubuntu> ogra_: yes, certainly
[08:31] <zyga-ubuntu> ogra_: I don't have /boot/uboot/config.txt - just uboot.env which is binary
[08:32] <ogra_> zyga-ubuntu, bah, sory, i mis-read
[08:32] <ogra_> i thougth you were n a Pi
[08:32] <zyga-ubuntu> aha, right
[08:32] <ogra_> i dont think there is a way to tune that on a dragonboard
[08:32] <zyga-ubuntu> ogra_: ok, thanks
[08:32] <ogra_> despite using your own patched kernel or so
[08:33] <zyga-ubuntu> one of those days we will get sodimms on the devkits :)
[08:33] <ogra_> zyga-ubuntu, also ... the dragonboard is am64 ... the ram is not really eaten by GPU but by the fact that your binaries are about 1/3 bigge in ram
[08:33] <ogra_> arm64 on small boards is a massive insanity
[08:34] <zyga-ubuntu> ogra_: oh? why does linux report 0.7GB memory total then?
[08:34] <ogra_> (especially if the same board can run 32bit and eat half the ram in the end)
[08:35] <ogra_> well, part of it is surely GPU ... but you will also use massively more ram for the binaries
[08:36] <zyga-ubuntu> sure but it looks like 0.3 is just reserved up front
[08:37] <ogra_> yeah
[08:37] <ogra_> as i said, i dont think thats tunable
[08:37] <ogra_> despite recompilling parts
[08:39] <mup> Issue snapcraft#1543 closed: Unable to specify make arguments <Created by akashrajkn> <Closed by akashrajkn> <https://github.com/snapcore/snapcraft/issue/1543>
[08:39] <ogra_> just a FYI ... htop in a beaglebone repts 48MB in use on a idle system ... with the same set of snaps installed, htop on rteh dragonboard reports 122MB
[08:40] <ogra_> (there is some minimal overhead because the dragonboard uns wpa_supplicant and stuff, but you get the difference between arm64 and armhf)
[08:48] <sborovkov> ogra_: hi :) so from that script you provided me for using on the first boot. File system is always available? I am a bit confused about what's going on there.. I tried this if [ ! -d "/root/system-data/var/snap/screenly-client/" ] ; then psplash-write.... And checking for snap.json file. Somehow it executes that line on every boot :-(
[08:48] <ogra_> sborovkov, oh, sorry, i improved that a lot already ... one sec. let me dicg it up
[08:50] <ogra_> sborovkov, checking for state.json is the best thing to do here http://paste.ubuntu.com/25563809/
[08:50] <ogra_> sborovkov, it works fine here
[08:51] <ogra_> (only shows on first boot)
[08:51] <sborovkov> great.
[08:51] <sborovkov> thanks
[08:51] <ogra_> :)
[08:51] <sborovkov> I was checking it with -f
[08:51] <sborovkov> not sure why it shows up every time
[08:53] <sborovkov> ah
[08:53] <sborovkov> cause I did not check for /root/writable
[08:53] <sborovkov> but /root/system-data instead
[08:53] <ogra_> ah, yeah
[08:54] <Chipaca> in the forum, when something is fix-committed, do i do anything or do i leave it on upcoming?
[08:54] <Chipaca> do i leave myself tagged in it?
[08:56] <ogra_> isnt there ar "solution" tag that seta a gee checkmark and such ?
[08:56] <ogra_> *sets
[08:56] <ogra_> *green
[08:59] <pedronis> Chipaca: I think we remove upcoming and name only when is fix-release
[09:00] <pedronis> d
[09:00] <Chipaca> k
[09:00] <pedronis> Chipaca: unless is some kind of code reorg/internal feature, then probably landing to master is enough
[09:08] <mwhudson> zyga-ubuntu: did you see that maciattobin board thing?
[09:08] <mwhudson> zyga-ubuntu: that looks like an arm64 device you could use without endless swearing
[09:12] <zyga-ubuntu> mwhudson: yeah but it's not a ref device, I would probably consider getting one of the server boards if that was one
[09:12] <mwhudson> true
[09:13] <zyga-ubuntu> mwhudson: (one of the older armv8 server boards with DDR slots and sata and everything)
[09:13] <mwhudson> which of those?
[09:13] <zyga-ubuntu> mwhudson: any that's available :)
[09:13] <mwhudson> ah heh
[09:13] <zyga-ubuntu> mwhudson: it would be interesting to have an UEFI device
[09:13] <Chipaca> zyga-ubuntu: mwhudson: and the OpenQ 820?
[09:13]  * Chipaca doesn't know what makes something a 'reference device'
[09:14] <zyga-ubuntu> Chipaca: our decision
[09:14] <Chipaca> ah :-) ok
[09:14] <zyga-ubuntu> Chipaca: btw, can you perhaps ssh into office.zygoon.pl?
[09:14] <Chipaca> I dunno
[09:14] <Chipaca> properly get cooties
[09:14] <zyga-ubuntu> I wanted to check if this works for you
[09:14] <mwhudson> zyga-ubuntu: that's still a mobile phone cpu isn't it?
[09:14] <zyga-ubuntu> mwhudson: ye
[09:14] <Chipaca> zyga-ubuntu: what's your fingerprint?
[09:15] <mwhudson> zyga-ubuntu: at least it has usb 3 and pcie so the fastest io probably isn't the wifi :)
[09:16] <Chipaca> (i read about the macchiatobin and the 820 reading about arm64 laptopts)
[09:16] <zyga-ubuntu> 256 SHA256:C3V0UBPGQHPToLeX/qcEAAGX02XbbwHDx0zQkVQtM74 mini (ECDSA)
[09:16] <zyga-ubuntu> 2048 SHA256:x4RFVP/TtE/nLtJ2WUO3dlLsavKWny7qeXNR1gHL3HA mini (RSA)
[09:16] <zyga-ubuntu> 256 SHA256:adjGbm4pxRSXYErI0y/bnQeaeJqCDfJKYPHPDLQxKoM mini (ED25519)
[09:16] <Chipaca> https://lwn.net/Articles/733837/
[09:17] <mwhudson> oh wait, last two comments should have been at Chipaca :)
[09:17] <Chipaca> mwhudson: :-)
[09:18] <Chipaca> zyga-ubuntu: i'm in
[09:18] <Chipaca> zyga-ubuntu: minicom says i can't use the serial port
[09:18] <zyga-ubuntu> Chipaca: can you ssh into dragon-1 now
[09:19] <zyga-ubuntu> Chipaca: oh, I'll adjust that
[09:19] <zyga-ubuntu> Chipaca: you should be good now, also you should be able to hop onto dragon-1
[09:24] <Chipaca> zyga-ubuntu: the pi3 asks me for my password
[09:24] <Chipaca> zyga-ubuntu:  the dragon works
[09:25] <zyga-ubuntu> Chipaca: yes, pi is not configured yet, when I have more time I'll improve the script that sets this up to push accounts there as well
[09:25] <zyga-ubuntu> Chipaca: I mainly wanted to make the dragon available as most people have a working PI already
[09:25] <Chipaca> ah ok
[09:26] <zyga-ubuntu> Chipaca: and the dragon is a hit and miss it seems
[09:26] <zyga-ubuntu> Chipaca: feel free to use that any time
[09:26] <Chipaca> zyga-ubuntu: i can confirm minicom now lets me talk to the dragon
[09:26] <zyga-ubuntu> Chipaca: nice
[09:26] <Chipaca> zyga-ubuntu: why minicom and not screen, btw?
[09:26] <zyga-ubuntu> Chipaca: I will add a way to power the device on and off from mini
[09:26] <zyga-ubuntu> Chipaca: screen was corrupting input heavily
[09:26] <zyga-ubuntu> Chipaca: and minicom was solid
[09:26] <zyga-ubuntu> Chipaca: no idea, try screen
[09:27] <zyga-ubuntu> Chipaca: I also like minicom :)
[09:27] <Chipaca> :-)
[09:36] <mup> PR snapd#3930 opened: cmd/snap-repair: integrate root public keys for repairs <Created by pedronis> <https://github.com/snapcore/snapd/pull/3930>
[09:43] <mup> Bug #1717857 opened: UDisks2 interface restricts sending DBus.Properties.Get message from the client to udisksd service <Snappy:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1717857>
[09:44] <mup> PR snapd#3931 opened: interfaces/builtin: allow receiving dbus messages <Created by zyga> <https://github.com/snapcore/snapd/pull/3931>
[09:45] <mvo> zyga-ubuntu: hm, is 3931 a regression?
[09:46] <zyga-ubuntu> mvo: no, it's an old bug
[09:48] <mvo> zyga-ubuntu: interessting that we have not gotten bugreports earlier
[09:48] <zyga-ubuntu> mvo: yep, looks like nobody really tried tihs
[09:48] <ogra_> ppisati, i have been getting reports about SD corruption lately and i think we are hitting https://github.com/raspberrypi/firmware/issues/397#issuecomment-219287224 with some newer SD cards ... i suspect we'll need to collect some data and will need to ship some quirks like https://github.com/respeaker/openwrt/blob/master/target/linux/brcm2708/patches-4.4/0354-mmc-Apply-QUIRK_BROKEN_ERASE-to-other-capacities.patch
[09:49] <ogra_> ppisati, that is raspi2 only though
[09:51] <ogra_> (i'm still collecting info, just a FYI)
[10:03] <ppisati> ogra_: kernel version?
[10:07] <ppisati> ogra_: and we already have those quirks applied
[10:08] <ppisati> ogra_: i'm interested to know, if they experienced this on a 4.4.0-1071.79+ version
[10:10] <pedronis> mvo: I just noticed reading the topic that the plan was that the script would just call 'repair' (not 'snap-repair') using some kind of symlink, it's a bit annoying but makes sense
[10:11] <mvo> pedronis: I was looking at the summary in the snap-repair show and was wondering if it makes sense to include the summary into the log output, it would make it easier for humans to inject the snap-repair directories using find/less/grep
[10:11] <mvo> pedronis: re 'repair'> sure, I can create a symlink
[10:12] <pedronis> mvo:   we could, a bit of a question of how to format it there
[10:13] <pedronis> and how to present this in show itself
[10:14] <mvo> pedronis: yeah, I was thinking a tiny header like: "repair: canonical-1\nsummary: repair one\noutput:..." and we can/could either show in snap-repair show (even though slightly redundant) or just filter out in the command
[10:15] <mvo> pedronis: feels nice to have the relevant info in the file itself, was thinking e.g. filesystem corruption where fsck might not reconstruct the filename but the content. anyway, maybe overthinking this
[10:16] <zyga-ubuntu> hmm
[10:16] <zyga-ubuntu> Unpacking manpages-dev (4.13-2) ...
[10:16] <zyga-ubuntu> dpkg: error processing archive /tmp/apt-dpkg-install-FOEqdJ/39-manpages-dev_4.13-2_all.deb (--unpack):
[10:16] <zyga-ubuntu>  trying to overwrite '/usr/share/man/man4/console_ioctl.4.gz', which is also in package manpages 4.10-2
[10:16] <zyga-ubuntu> must be my lucky day
[10:16] <zyga-ubuntu> the systemd-virt-detect bug fixed itself
[10:17] <zyga-ubuntu> and now this strikes back from hell
[10:17] <mvo> pedronis: I will modify 3925 to create a dir with "repair" that symlinks to snap-repair and have that in PATH. we only need one,right? i.e. not snap-repair and repair (both names) for the repair script?
[10:18] <pedronis> mvo: yes, sounds rights
[10:18] <pedronis> *right
[10:18] <mvo> ta
[10:18] <ogra_> ppisati, it is the curent pi2-kenel snap, namely AlbertA and bschefer are using the same SD type and brand and both have a corrupted booot pattiion after every core upgrade (which means daily if you use the edge channel... )
[10:19] <ogra_> ppisati, some 32GB sandisk ... i'm waiting for them to get online to get the manfid and stuff
[10:20] <ppisati> ogra_: <IP_ADDRESS>1.71 - edge
[10:20] <ogra_> (sadly i shuffled the card into another board and cant currently use it in the pi)
[10:20] <ppisati> ogra_: then no, it is not what i think
[10:20] <ogra_> it seems to be oonly a small set of SDs but i hear about it regulary from users
[10:21] <pedronis> mvo: about summary in output, I think it makes sense,  just a bit wondering that it would be best to strip it out in show and have it separate, but we need to think what to do about newlines
[10:21] <ogra_> ppisati, and i know we already have a quirks patch ... i just think it needs to cover some more cards
[10:22] <ppisati> ogra_: ack, is there a way to reproduce it?
[10:23] <ogra_> ppisati, for bschefer and AlbertA the overlays subdir on the boot partition gets messed up so the kms dtb doesnt get loaded and they end up without /dev/dri ... for them this is reproducable with every update
[10:24] <ogra_> foo me on my card it used to be uboot.env that got corrupt, also reliably with every update
[10:25] <mvo> pedronis: yeah, I will ponder a bit
[10:25] <ogra_> ppisati, my idea was to cllect their SD data, and let them try a patched kenel t see if it help ... but the behaviour sounds suspiciously like the erase issue from above
[10:26] <ogra_> (specifically because they both have the same card exposing the same issue 100% of the time)
[10:26] <mup> PR #100: Ongoing work on the capability APIs <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/100>
[10:27] <ogra_> *** baa-dum tish ***
[10:27] <ogra_> zyga-ubuntu wins the price fr the 100st PR !!!
[10:27]  * ogra_ throws confetti
[10:27] <ppisati> ogra_: makes sense - do you have an old edge image around? so i can try with some sd cards here, and to some update cycles
[10:28] <ogra_> ppisati, http://people.canonical.com/~ogra/snappy/all-snaps/daily/ just pick an old one there
[10:28] <zyga-ubuntu> heh :-)
[10:28] <ppisati> ogra_: cool, will do - pi2 or pi3?
[10:29] <ogra_> ppisati, pi3 here but i bet it doesnt matter
[10:29]  * zyga-ubuntu tries a fix for the debian bug and goes to make more tea
[10:40]  * zyga-ubuntu itereates on manpages bug
[10:41] <zyga-ubuntu> and while spread runs let's test Fedora 25 update
[10:45] <zyga-ubuntu> mvo: that's something for you
[10:45] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/3932
[10:45] <mup> PR #3932: spread: work around temporary packaging issue in debian sid <Created by zyga> <https://github.com/snapcore/snapd/pull/3932>
[10:45] <zyga-ubuntu> mvo: locally still going
[10:45] <mup> PR snapd#3932 opened: spread: work around temporary packaging issue in debian sid <Created by zyga> <https://github.com/snapcore/snapd/pull/3932>
[10:46] <mup> PR snapd#3933 opened: snap-repair: make `repair` binary available for repair scripts <Created by mvo5> <https://github.com/snapcore/snapd/pull/3933>
[10:48] <mvo> zyga-ubuntu: ta
[10:52] <zyga-ubuntu> mvo: tests are rolling so I think this is a good fix
[10:58] <ppisati> $ snap list
[10:58] <ppisati> No snaps are installed yet. Try "snap install hello-world".
[10:58] <ogra_> ppisati, hrm
[10:58] <ppisati> ogra_: pi3 image of 3 days ago, i feel confused
[10:58] <ogra_> ppisati, sounds like fixrct didnt run
[10:58] <ppisati> 14 of sept image
[10:59] <zyga-ubuntu> darn, I ran out of disk space
[11:00] <ogra_> ppisati, very weird, i tested them after fixrtc got fixed again
[11:00] <ogra_> oh ... one sec
[11:00] <ppisati> ogra_: let me try with the 15th and 16th of sept image
[11:00]  * ogra_ checks if edge actually has the latest kernel
[11:02] <ogra_> hmm, no, latest kernel there
[11:02] <ogra_> i thought perhaps edge would be behind
[11:03] <mvo> pedronis: do we allow newlines in the summary currently?
[11:15] <zyga-ubuntu> Son_Goku: thank you for pushing the 2.27.6 release out
[11:15] <Son_Goku> my 2.27.6 is special, though :)
[11:15] <zyga-ubuntu> Son_Goku: yes, I know :)
[11:15] <Son_Goku> it's better than all the other snapd 2.27.6 :)
[11:15] <zyga-ubuntu> Son_Goku: I'm testing it on F25 now
[11:15] <zyga-ubuntu> Son_Goku: though it's out already I wanted to finish it
[11:15] <zyga-ubuntu> Son_Goku: sorry for being slow, the weather is getting the better of me :/
[11:16] <Son_Goku> it's fine
[11:17] <zyga-ubuntu> how are you doing?
[11:19] <pedronis> mvo: in principle yes, we don't check for them not to be there? we could prohibit them in asserts/repair.go if we want
[11:25] <Son_Goku> zyga-ubuntu: alright I suppose
[11:37] <ogra_> zyga-ubuntu, you should use stgraber's in-browser terminal that he uses for https://linuxcontainers.org/lxd/try-it/ and hook that up to native containers on the pi and dragonboard ;)
[11:37] <ogra_> (for your device lab that is)
[11:37] <zyga-ubuntu> ogra_: is there a snap for the client part?
[11:38] <ogra_> no idea :)
[11:38] <zyga-ubuntu> ogra_: I've redirected ports for mosh but I don't think we have a working mosh snap
[11:38] <ogra_> but that sounds like an awesome spare-time project :)
[11:38] <zyga-ubuntu> ogra_: but you can mosh into the mac mini allright
[11:38] <ogra_> having a central website to try ubuntu core in a browser on specific supported boards
[11:39] <zyga-ubuntu> ogra_: I need to get a 2nd hand desk rack
[11:39] <zyga-ubuntu> ogra_: I will add my other boards there but I have no space to make this reliable now
[11:42] <zyga-ubuntu> ogra_: btw, how do you power the dragon board?
[11:42] <zyga-ubuntu> ogra_: I've set 12V and 2A
[11:42] <ogra_> yeah, that should be fine
[11:42] <zyga-ubuntu> ogra_: I wonder what the on-board regulators do
[11:42] <ogra_> the 96boards boards all support 12-19V iirc
[11:43] <zyga-ubuntu> ogra_: is thre an optimal value that produces least waste heat
[11:43] <ogra_> i think 12V/2A is fine
[11:43] <ogra_> not sure how much lower you can go, there is a lot HW on the dragonboard
[11:44] <zyga-ubuntu> ogra_: fun fact
[11:44] <zyga-ubuntu> ogra_: I powered it last week using the PSP power adapter
[11:44] <zyga-ubuntu> ogra_: that's 5V
[11:45] <ogra_> https://www.96boards.org/product/power/
[11:45] <ogra_> "The 96Boards CE boards require an 8-18V 2A power supply."
[11:45] <ogra_> so you were lucky i guess :)
[11:45] <zyga-ubuntu> well now it should be solid :)
[11:45] <zyga-ubuntu> I was thinking about setting the limit to 3A
[11:46] <zyga-ubuntu> but even under load I see at most 0.5A
[11:46] <tbr> fun fact: the spec was *specifically* written to exclude powering it from USB/5V "because that's just too weak"
[11:46] <ogra_> because you are not using all HW ... iirc there is GPS and such
[11:47] <tbr> also hook up some USB devices that go to full spec load of 0.5A
[11:47] <ogra_> yep
[11:47] <zyga-ubuntu> tbr: it powers an external HDD using two USB ports
[11:48] <zyga-ubuntu> tbr: but now it's on 12V/2A supply
[11:48] <ogra_> the 12/2 thing will guarantee that it stays fully functional if all onboard HW is powered and used
[11:49] <tbr> and all USB ports used
[11:49] <tbr> power budget is always spec'd to full load *everything* and a bit of safety margin (at least one would hope)
[11:49] <ogra_> right
[11:50]  * Chipaca grabs the painkillers and heads back to bed
[11:50]  * zyga-ubuntu hugs Chipaca
[11:50] <zyga-ubuntu> Chipaca: stay strong, it's not even winter yet
[11:50] <Chipaca> heh
[11:50] <Chipaca> zyga-ubuntu: it's my back having a bad day, is all
[11:50]  * zyga-ubuntu reads https://www.securecoding.cert.org/confluence/display/c/MSC06-C.+Beware+of+compiler+optimizations
[11:50] <Chipaca> i must've done something unexpected over the weekend
[11:50] <zyga-ubuntu> Chipaca: ouch, even more sympathy then :/
[11:51] <Chipaca> like, the dishes /o\
[11:51] <zyga-ubuntu> I know how bad that is
[12:05] <mup> Bug #1710637 opened: Input falls through to gdm3 and terminates the session on Ctrl+C <amd64> <apport-bug> <artful> <gnome-17.10> <rls-aa-incoming> <wayland-session> <Snappy:New> <console-setup (Ubuntu):Fix Released> <gdm3 (Ubuntu):Incomplete> <gnome-shell (Ubuntu):Incomplete> <mutter
[12:05] <mup> (Ubuntu):Incomplete> <https://launchpad.net/bugs/1710637>
[12:07] <zyga-ubuntu> whaat?
[12:07] <ogra_> check the desktop channel :)
[12:27] <zyga-ubuntu> mvo: hey, just FYI in case it blows up on us: https://forum.snapcraft.io/t/snap-remove-somesnap-triggers-keyboard-input-fallthrough-to-vt-ctrl-c-in-terminal-logs-out-of-current-gdm-session/2162/6 and https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1710637 -- we may need another release for that
[12:27] <mup> Bug #1710637: Input falls through to gdm3 and terminates the session on Ctrl+C <amd64> <apport-bug> <artful> <gnome-17.10> <rls-aa-incoming> <wayland-session> <Snappy:New>
[12:27] <mup> <console-setup (Ubuntu):Fix Released> <gdm3 (Ubuntu):Incomplete> <gnome-shell (Ubuntu):Incomplete> <mutter (Ubuntu):Incomplete> <https://launchpad.net/bugs/1710637>
[12:28]  * zyga-ubuntu breaks for lunch before standup
[13:11] <ackk> niemeyer, when you have time, could you have a look at https://github.com/snapcore/snapd/pull/3916 for the addition to the snap.yaml content for apps?
[13:11] <mup> PR #3916: add support for socket activation in apps <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
[13:17] <zyga-ubuntu> jdstrand: hello
[13:17] <zyga-ubuntu> jdstrand: thank you for the review, I pushed more things and I think it's ready for re-review
[13:18] <zyga-ubuntu> jdstrand: I'd like to start proposing new PRs instead of iterating on this one as it's veryt hard to keep track of everything
[13:19] <jdstrand> zyga-ubuntu: I'm done with my big reviews, so anything extra is just making sure what I commented on is done
[13:20] <jdstrand> zyga-ubuntu: I assume you are talking about PR 3621?
[13:20] <mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
[13:22] <jdstrand> zyga-ubuntu: that PR is tricky because we are doing retroactive reviews. ie, it is arguably fine when not called from snap-confine but when called from snap-confine, needs changes
[13:22] <zyga-ubuntu> jdstrand: yes
[13:22] <zyga-ubuntu> jdstrand: let's mark it as good then
[13:22] <zyga-ubuntu> jdstrand: and land it :)
[13:22] <zyga-ubuntu> jdstrand: I just cannot land it before you agree
[13:22] <jdstrand> but anyway, like I said, I finished the big reviews, all that is left is making sure that comments are addressed, so I think it will be mergeable soon
[13:22] <zyga-ubuntu> thank you
[13:22]  * jdstrand nods
[13:37] <ogra_> ppisati, did you get anywhere with the newer images ?
[13:39] <ogra_> koza, hmm, https://docs.ubuntu.com/core/en/stacks/bluetooth/bluez/docs/reference/sending-files#receiving-files ... it doesnt seem like the mentioned "bluez-test" snap from there is in the store
[13:39] <ogra_> *bluez-tests
[13:40] <ppisati> ogra_: yes, so all the available daily (14/15/16 of sept) behave the same - snap list is empty
[13:40] <ppisati> ogra_: but when installing the hello world snap, tra triggered the update of core
[13:40] <ppisati> ogra_: so it did the update and rebooted fine
[13:40] <ogra_> ppisati, seems the builder was stuck, there are new images nnow
[13:40] <ppisati> $ snap list
[13:40] <ppisati> Name         Version    Rev   Developer  Notes
[13:40] <ppisati> core         16-2.27.6  2849  canonical  core
[13:40] <ppisati> hello-world  6.3        27    canonical  -
[13:41] <ogra_> ppisati, no, thats completely broken
[13:41] <ppisati> ogra_: yeah, it should show more snaps, but i was looking after the corruption
[13:41] <ogra_> ppisati, the device didnt get initialized ... else you would see the gadget and kernel snap in list ... what you have there is simply snapd that pulled in *another* core to be able to run hello-world
[13:42] <ogra_> ppisati, well, lets wait for bschaefer or AlbertA ... they can definitely reproduce 100%
[13:43]  * ppisati tries the new daily
[13:43] <ogra_> ppisati, in the case where you have an uninitialized image an upgrade wont actually upgrade the bootloader bits (because the image simply doesnt know about the bootloader) ... so thats pretty different
[13:44] <ogra_> on proper images a core update re-writes the bootloader config
[13:44] <ogra_> and thats where the corruption usually happens ... the vfat seems to be more prone to corruption than the ext4 partition in that case
[14:02] <ppisati> ogra_: the latest daily (18 of sept) is good, snap list report a list of snaps
[14:03] <ogra_> phew
[14:03] <ogra_> so the stale builds used soome old kernel before the no-change rebuild
[14:04] <ppisati> $ snap refresh core
[14:04] <ppisati> snap "core" has no updates available
[14:04] <ogra_> yeah ...
[14:04] <ogra_> do "snap refresh core --stable"
[14:05] <ogra_> that force-switches the channel so it will definitely up/downgrade
[14:18] <ppisati> ogra_: did it, it rebooted fine and i'm back in - mmcblk0p1 is mounted and i can see its content
[14:18] <ogra_> ppisati, great
[14:18] <ogra_> ppisati, so your SD isnt affected
[14:21]  * ppisati tries with another sd card, just in case...
[14:25]  * zyga-ubuntu forgot about his daughter because of the 2nd call
[14:35] <zyga-ubuntu> pstolowski: hey
[14:35] <zyga-ubuntu> pstolowski: I'll gladly help you on that effort
[14:36] <zyga-ubuntu> mvo: can we land https://github.com/snapcore/snapd/pull/3932?
[14:36] <mup> PR #3932: spread: work around temporary packaging issue in debian sid <Created by zyga> <https://github.com/snapcore/snapd/pull/3932>
[14:39] <zyga-ubuntu> jdstrand: thank you for a re-review
[14:40] <pedronis> zyga-ubuntu: pstolowski: a bit worried that this will mean even more Plug/SlotInfo around and that will be confusing
[14:44] <zyga-ubuntu> pedronis: if we add a interfaces.Connection type that stores PlugInfo, SlotInfo pointers nothing will (yet) change
[14:44] <zyga-ubuntu> pedronis: then some reshuffling to represent things this way
[14:45] <zyga-ubuntu> pedronis: as long as we don't land the plugdata branches it should not get more confusing than it is now
[14:46] <zyga-ubuntu> jdstrand: I didn't miss those btw, I was still under the impression that those can be merged separately
[14:46] <zyga-ubuntu> jdstrand: (so that this PR can land)
[14:46] <zyga-ubuntu> jdstrand: but I can make them here as well if you think this is necessary
[14:46] <mvo> zyga-ubuntu: is there a bts bug already about this issue in debian? if so, I think we should include a link to that so that we can remove this workaround once its fixed
[14:47] <pedronis> zyga-ubuntu: well we have things like Plugs()  []*Plug,  Plug have identity sort of, PlugInfo don't
[14:48] <zyga-ubuntu> mvo: I didn't look
[14:48] <zyga-ubuntu> pedronis: yes but that won't yet change, I think
[14:48] <zyga-ubuntu> pedronis: unless I'm mistaken and we need to cross that bridge soon
[14:49] <jdstrand> zyga-ubuntu: there so small I think here is good. if we land them and something happens and the next one gets released, that isn't good. I could try to separate out the must haves and the should haves, but then it just makes the other PR review difficult cause we need to reference back to this one
[14:49] <jdstrand> thy're*
[14:49] <jdstrand> meh
[14:49] <jdstrand> they're*
[14:49] <zyga-ubuntu> jdstrand: yes, that's a good point (about the release)
[14:52] <jdstrand> zyga-ubuntu: I mean, I guess technically you create a PR for just the security audit changes, land that before 3621, then merge that into 3621, but I don't see any gain in that
[14:52]  * jdstrand is trying to get this to land fast too :)
[14:52] <zyga-ubuntu> jdstrand: I didn't want to do the simplification changes as I think they are not critical and don't have a security impact
[14:53] <jdstrand> zyga-ubuntu: those are the should have column
[14:53] <jdstrand> like I said, we can split it up, but I don't see any reason
[14:53] <zyga-ubuntu> jdstrand: ok
[14:54] <jdstrand> I mean, we can make things harder on ourselves if we want :P
[14:55] <jdstrand> I'll leave the to split vs not up to you, but will say if split, please get the audit feedback in before 3621, so it is in place whenever 3621 is
[14:55] <zyga-ubuntu> jdstrand: I'll do them in the PR
[14:55] <jdstrand> ok cool. it is really close to landing
[14:55] <zyga-ubuntu> jdstrand: can you please edit https://github.com/snapcore/snapd/pull/3621#pullrequestreview-63369978 to indicate if something is optional
[14:55] <mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
[14:55] <zyga-ubuntu> jdstrand: I'm not sure if all of that is mandatory or not
[14:56] <zyga-ubuntu> sorry for being confused, I just dropped from a call and I'm swapping context
[14:56] <jdstrand> zyga-ubuntu: I did. I consider it all mandatory except the one that says (not a blocker)
[14:56] <zyga-ubuntu> jdstrand: why are the simplifications mandatory?
[14:56] <jdstrand> zyga-ubuntu: I gave my feedback on why the simplification is important last week in response to your question
[14:56] <zyga-ubuntu> ah
[14:56] <zyga-ubuntu> let me recheck
[14:57] <jdstrand> zyga-ubuntu: to be clear, there aren't security bugs there, but see my comment
[14:58] <zyga-ubuntu> ah, I see that
[14:58] <zyga-ubuntu> I must have missed that, sorry, the thread is so long now
[14:58] <jdstrand> indeed
[14:59] <jdstrand> zyga-ubuntu: the basic idea is since it is security sensitive, make it easy to verify
[15:11] <pstolowski> zyga-ubuntu, pedronis hey, sorry, was distracted and missed your earlier messages
[15:13] <mup> PR snapd#3810 closed: interfaces/hooks: PlugData and SlotData wrappers <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/3810>
[15:32] <pstolowski> pedronis, what was your worry? about having PlugInfo & SlotInfo in the "Connection" struct?
[15:32] <pedronis> pstolowski: not that, but when we remove Plug and Slot
[15:33] <ogra_> AlbertA, bschaefer so my pi did behave just fine over the weekend, no corruption ... but i found https://github.com/raspberrypi/firmware/issues/397#issuecomment-219287224 ... we might need something similar to https://github.com/respeaker/openwrt/blob/master/target/linux/brcm2708/patches-4.4/0354-mmc-Apply-QUIRK_BROKEN_ERASE-to-other-capacities.patch for your specific SD card
[15:34] <bschaefer> ogra_, o interesting
[15:35] <ogra_> AlbertA, bschaefer, the output of "grep . /sys/class/mmc_host/mmc0/mmc0:*/* 2>/dev/null" (as mentioned in the issue above) might be interesting ... ppisati was also looking into it but has no SD he can reproduce it with
[15:35] <bschaefer> ogra_, i bought two of the SD cards
[15:35] <ogra_> i assume both of yur boards ended up with a corrupt overlays dir again ?
[15:35] <bschaefer> i can give you or him one in new york (the one that was acting an issue)
[15:35] <bschaefer> or test some things out
[15:35] <bschaefer> ogra_, monday for me today + i had that hack of manually untaring
[15:36] <bschaefer> let me test agian
[15:36] <bschaefer> (monday 8:30am :)
[15:36] <ogra_> yeah, the patch is trivial, once we have the data from the grep above we ca surely cook something up
[15:36] <ogra_> *can
[15:36] <mup> PR snapd#3934 opened: snap-repair: implement `snap-reapir {listt,show}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3934>
[15:37] <zyga-ubuntu> mvo: llist
[15:37] <zyga-ubuntu> er, sorry, I meant listt
[15:37] <bschaefer> ogra_, cool let me re-flash and boot up
[15:38] <mvo> pedronis: I reworked 3777 quite a bit (I think its nicer now) in 3934 - I can either push this over 3777 or close 3777 either way is fine with me
[15:38] <mvo> zyga-ubuntu: thanks, fixed
[15:39] <Son_Goku> zyga-ubuntu: are you going to be at the sprint/rally/thing next week?
[15:39] <Son_Goku> mvo: ^?
[15:39] <ogra_> mvo, is reapir an aggressive brother of tapir ?
[15:39] <ogra_> :P
[15:39] <zyga-ubuntu> Son_Goku: no, I don't think I will
[15:39] <pedronis> mvo: I'll look in a bit
[15:40] <mvo> pedronis: no rush, I need to leave soonish anyway to play hockey
[15:40] <mvo> Son_Goku: I will be there
[15:40] <Son_Goku> \o/
[15:40] <mvo> ogra_: its what I turn into when I did not have enough tea sadly
[15:40] <ogra_> heh
[15:41] <mvo> Son_Goku: and more of the folks you know, we will have a blast!
[15:41]  * ogra_ gives mvo more tea
[15:43] <AlbertA> ogra_: ok I'll try to get those logs a bit later
[15:44] <bschaefer> ogra_, http://paste.ubuntu.com/25566047/
[15:44] <ogra_> thx
[15:45] <bschaefer> np! Let me know if theres any fixes you want me to test out as well
[15:45] <ogra_> will do
[15:58] <AlbertA> ogra_: http://pastebin.ubuntu.com/25566134/
[15:58]  * Chipaca ~> lunch
[15:58] <ogra_> AlbertA, bschaefer oooh, they differ !
[15:59] <ogra_> (different oemid)
[16:01] <mup> PR snapd#3935 opened: cmd/snap-repair: implement the repair run loop <Created by pedronis> <https://github.com/snapcore/snapd/pull/3935>
[16:01] <bschaefer> ogra_, though i think we both had corrupting issues :)
[16:02] <ogra_> yes, and obviously the same
[16:02] <bschaefer> AlbertA, your SD is old!
[16:02] <bschaefer> 2015
[16:02] <AlbertA> :)
[16:11] <AlbertA> ogra_: bschaefer: interesting, another core upgrade but this time after a second reboot, system won't boot at all (stuck at the "Starting Kernel..." screen)
[16:11] <bschaefer> AlbertA, that use to happen to me
[16:11] <bschaefer> but i blamed by 8GB SD card
[16:11] <AlbertA> ogra_: which SD cards do you use?
[16:11] <bschaefer> and got these 32GB ones and havent had an issue with that since
[16:12] <ogra_> AlbertA, totally random ones i buy at the electronics discounter next door
[16:12]  * bschaefer never knew the intricacies of SD cards
[16:12] <ogra_> i have some toshibas, sandisk, terratec ... apacer
[16:14] <ogra_> whatever they have in the offers when i need new ones, i explicitly dont pick a particular one (to be able to run into issues by my weird choice ... obviously that never works :P )
[16:14] <ogra_> AlbertA, well, you can check the card in your PC reader if it is really corrupt
[16:14] <ogra_> ppisati, see above ...
[16:15] <ogra_> ppisati, i'll cook up a patch that supppresses erase on both cards tomorrow
[16:16] <bschaefer> ogra_, ill be sure to pack the current one im using plus the other new one i have unopened
[16:16] <bschaefer> if you need more testing on those
[16:16] <bschaefer> though hopefully this is enough :)
[16:16] <ogra_> well, i should have a kernel snap or complete image for you guys to test tomorrow ... we'll then see if that helps
[16:16] <ogra_> up to now it is just a theory anyway
[16:17] <AlbertA> ogra_: yeah
[16:17] <AlbertA> thxs!
[16:17] <ogra_> :)
[16:17] <bschaefer> ogra_, awesome, and thanks!
[16:28] <ppisati> ogra_: ack, FWIW i tested on two more sd cards, everything was fine
[16:29] <ogra_> ppisati, yeah, i have like 30 cards here and only one that ever has shown such an issue
[16:35] <mup> Issue snapcraft#1489 closed: Custom path of desktop file - should not be expanded in prime directory <Created by koppor> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1489>
[16:35] <mup> Issue snapcraft#1506 closed: Inconsistent formatting when opening vs. closing channels <Created by Roadmaster> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1506>
[16:42] <zyga-ubuntu> Chipaca: how are you feeling?
[16:42] <Chipaca> zyga-ubuntu: better, thank you
[16:42] <Chipaca> had lunch even
[16:42] <Chipaca> did i miss much?
[16:45] <bschaefer> hmm is there a bug for this? "snap install <snap_name_not_complete><hit_tab_to_autocomplete> --devmode" turns into "snap install --devmode --devmode"
[16:46] <zyga-ubuntu> Chipaca: no, I think all is good
[16:46] <zyga-ubuntu> Chipaca: some discussion around iface repository and connections
[16:47] <ogra_> bschaefer, tab completion is Chipaca's baby
[16:48] <Chipaca> bschaefer: hm, that's a new one
[16:48] <bschaefer> Chipaca, i mainly hit it when i have mir-kiosk_*snap and mir-kiosk-apps*snap
[16:48] <bschaefer> and im install both with --devmode
[16:49] <bschaefer> so i just try to auto tab from mir-kisok-<tab> but since --devmode is there seems... to want to reaplce the string with that :)
[16:49] <Chipaca> bschaefer: I'll take a look, but just for the record a lot of things don't auto-complete properly from the middle of the command
[16:49] <niemeyer> ackk: Will check it out.. sorry for not replying earlier.. we were in the standup and then I forgot to reply
[16:49] <bschaefer> Chipaca, yeah figured it was an strange edge case :)
[16:49] <bschaefer> not really a huge issue
[16:49] <Chipaca> bschaefer: it _should_ work, though, and i know to fix it if it doesn't
[16:49] <Chipaca> so, i'll take a look
[16:50] <bschaefer> Chipaca, cool :), tahnks!
[17:08] <mup> Bug #1666386 changed: Snap apps do not work on Lubtuntu <Snappy:Invalid by zyga> <lubuntu-meta (Ubuntu):New> <https://launchpad.net/bugs/1666386>
[17:20] <nacc> for those using LP to build their snap, how are people organizing their repository to deal with stable/edge branches, etc. It seems I can only have one repository <-> package connection, which means I have to publish to edge, and manually promote to stable at the appropriate time? Can I have a stable branch pushing to stable and an edge branch pushing to edge?
[17:46] <kyrofa> nacc, to be clear, there are multiple ways to use LP to build snaps. You cannot achieve what you're asking with build.snapcraft.io, but you can if you simply use LP differently
[17:46] <pedronis> mvo: I think it's ok to close the previous one
[17:47] <kyrofa> nacc, so from the limitations you've mentioned, I assume you're using build.snapcraft.io, correct?
[17:48] <nacc> kyrofa: i'm using LP directly
[17:48] <nacc> (no b.s.io)
[17:48] <kyrofa> Oh! Well then yes, you can definitely do as you're asking
[17:48] <nacc> kyrofa: ok! link to docs?
[17:48] <kyrofa> nacc, don't make me laugh
[17:49] <nacc> kyrofa: if i click on the second branch and try to associate it to the same snap, LP says no
[17:49] <kyrofa> nacc, "snaps" in LP are really snap _recipes_
[17:49] <kyrofa> nacc, you can only create one per branch, and they must be named differently, but when they're uploaded to the store they're uploaded using the name in the YAML
[17:49] <kyrofa> nacc, which means they're the same snap
[17:50] <nacc> kyrofa: yep, that makes sense
[17:50] <kyrofa> nacc, so you're on the right path
[17:50] <kyrofa> nacc, create a new snap, called <mysnap>-stable
[17:50] <mup> PR snapd#3936 opened: data/completion: small tweak to snap completion snippet <Created by chipaca> <https://github.com/snapcore/snapd/pull/3936>
[17:50] <kyrofa> Associate it with the stable branch, auto-upload to stable, and voila
[17:50] <Chipaca> bschaefer: ^ :-)
[17:50] <nacc> kyrofa: oh! so basically lie to LP's recipe creator? :)
[17:50] <nacc> kyrofa: fun :)
[17:51] <bschaefer> Chipaca, awesome thanks!
[17:51] <kyrofa> nacc, whatever it takes :P
[17:51] <nacc> kyrofa: yeah :)
[17:51] <Chipaca> bschaefer: if you drop data/completion/snap from that pr into your /usr/share/bash-completion/completions, your issue should go away (and nothing bad could possibly happen™)
[17:51] <nacc> kyrofa: thannks! i'll try it now
[17:51] <kyrofa> nacc, you should see the gymnastics we do in the nextcloud snap
[17:52] <bschaefer> Chipaca, o sweet yeah ill give that a try now
[17:52] <nacc> kyrofa: are there bugs open for this to be easier?
[17:52] <nacc> kyrofa: as it seems like a pretty obvious workflow to me
[17:52] <nacc> kyrofa: do you make -stable -edge or whatever other snaps you create private so they don't show up int he store?
[17:52] <nacc> kyrofa: they are just placeholders, it feels like
[17:52] <kyrofa> nacc, I'm afraid I don't know about bugs
[17:53] <kyrofa> nacc, the snap recipes you create in LP do not show up in the store
[17:53] <kyrofa> nacc, the names are specific to LP
[17:53] <nacc> kyrofa: oh right and since there will be no uploads to git-ubuntu-stable, e.g., it will never show up
[17:53] <nacc> kyrofa: funny
[17:53] <kyrofa> nacc, there are fields on the recipe that cover "what is this named in the store"
[17:59] <bschaefer> Chipaca, sweet, confirmed working /me comment
[17:59] <Chipaca> bschaefer: ta
[18:17] <mup> PR snapd#3937 opened: interfaces/udev: only 'trigger --action=change', not 'control --reload-rules' <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3937>
[19:35] <mup> PR snapcraft#1551 closed: dirs: set plugin, schema, and library dir for snap <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1551>
[21:00] <cachio> niemeyer, I am looking at the test ubuntu-core-services which check the status for the different snapd services
[21:00] <cachio> i am looking the results on dragonboard and it is failing
[21:00] <cachio> basically snapd.autoimport.service and snapd.snapd.refresh.timer are not active on dragonboard
[21:01] <cachio> i am not sure if it is expected or it is an issue
[21:01] <cachio> niemeyer, any idea?
[21:11] <niemeyer> Hmm
[21:11] <niemeyer> cachio: Refresh timer is not supposed to be active anymore I believe. This is now internal.
[21:12] <niemeyer> cachio: As for autoimport, I *think* this is actually a once only thing on startup.. it's not supposed to be active the whole time.. but that's been a while ago and my memory fails
[21:13] <cachio> niemeyer, ok, i'll ask tomorrow to mvo because the test he just added is failing on ubuntu-core
[21:14] <pedronis> also test themselves manipulate those (maybe in different ways between core and classic)
[21:15] <cachio> pedronis, yes, that could be a reason, because i am running with external backend
[21:17] <pedronis> anyway mvo is indeed the best person to talk about this
[21:33] <cachio> niemeyer, the test-snapd-upower-observe-consumer snap is not available for arm-64 and a test is failing because of that, I don't have permissions to upload that to prod, do you?
[21:51] <niemeyer> cachio: I don't as well
[21:52] <mup> PR snapd#3938 opened: interfaces/opengl: don't udev tag nvidia devices and use snap-confine instead <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3938>