[02:13] <ubptgbot> AimanFO was added by: AimanFO
[02:27] <ubptgbot> distrojunkie was added by: distrojunkie
 (Photo, 1080x1920) https://irc.ubports.com/B6kLygkc.png
 Hey guys, is it ok the battery of my nexus 5 drain so much during the night?
 I left it about 90% with mobile data and wifi off, no apps opened and this morning it's 38%!!! The only thing I thought is that I'm in roaming and could be bad for the battery, but the nights before it doesn't drain so much
 that's kinda usual on Nexus 5, there's an open issue about it and a possible cause
 try running sudo pkill -9 hciattach
 the drain is ~20% for me but after using this command, it's 3-10% only
 What does this command do?
 not sure though what's the impact of killing that process, bluetooh might stop working?
 kills the hciattach process
 Yes sure, but I mean: What does this process do? :-)
 iirc hciattach is basically the link between bluetooth hardware to the os' bluetooth stack
 ^ like I said, I don't know LOL, search the issues in github...I'm kinda lazy right now coz I'm on my phone 😅
 @dohniks, Here you go :) … https://github.com/ubports/ubuntu-touch/issues/701 … https://github.com/ubports/ubuntu-touch/issues/700
 nice
 is the proot error the only entry in the log?
 if so, please clarify in the issue, if not, please attach
 @mymike00, Is that the new app to design rollercoasters? 😆
 On a serious note, that's pretty similar to what I see on my N5 altought is less pronounced since I installed a new battery
 [Edit] On a serious note, that's pretty similar to what I see on my N5 althought is less pronounced since I installed a new battery
 @advocatux, yep, but still in development 😁
 😂
 @advocatux, yeah, I was thinking about taking a new battery... but the thing is that it's the first night I had so much drain, all the days before I had -20% max per night 😢
 What changed that night? Maybe on roaming mode is calling the antennas more frequently?
 I'm in roaming for about 2 weeks...
 (Document) https://irc.ubports.com/Zi2xi3cI.mp4
 @mymike00, Xenial or vivid
 @mymike00, [Edit] Xenial or vivid?
 https://forum.xda-developers.com/showthread.php?t=2546645 (get the link from the forum https://forums.ubports.com/topic/358/nexus-5-hammerhead-battery-boost-disable-auto-rotate-reboot-for-slower-drain ) says that could be apps that don't shut down sensors after finished using it. … now I think the app is https://github.com/mymike00
[06:18] <ubptgbot> /ActivityTracker (forked by me, and I'm the actual dev) because if I try to use it for the seond time (it create gps tracks) the position switch doesn't work very well anymore and I have to reboot the phone...
 @malditobastardo, vivid
 [Edit] https://forum.xda-developers.com/showthread.php?t=2546645 (get the link from the forum https://forums.ubports.com/topic/358/nexus-5-hammerhead-battery-boost-disable-auto-rotate-reboot-for-slower-drain ) says that could be apps that don't shut down sensors after finished using it. … now I think the app is https://github.com/m
[06:18] <ubptgbot> ymike00/ActivityTracker (forked by me, and I'm the actual dev) because if I try to use it for the seond time (it create gps tracks) the position switch doesn't work very well anymore and I have to reboot the phone... … is it possible?
 try with killing hciattach as suggested before
 for me it worked
 now in xenial it seems like that was fixed
 @malditobastardo, but after that can I still use bluetooth?
 hmm no, you have to reboot the phone in order to use bt again
 but you can do that before going to sleep to avoid the huge battery drain when sleeping
 ok, I'll try tonight, thank you all!
 @mymike00 have you tried to put the phone on airplane mode at night?
 not yet, I could also have a try with that 👍🏻
 :)
 I can confirm, that libertine works (somewhat) on Bq M10 with 16.04
 Firefox reports: "Your Firefox profile cannot be loaded. It may be missing or inaccessible." and crashes, but GIMP loaded and works
 I had no luck with Libertine in vivid.  I had to sneak in the puritine click package someone slipped me back when I was just using my Nexus 5!
 And or Nexus 7.
 where did you get stuck?
 It aborts somewhere around setting up some xorg packages, about 3 apt-gets in.
 disk space maybe?
 Not possible.  Fresh flash, 5.3 GB free.
 not sure where the disk space is claimed. if it's on the system partition, it will be limited
 Almost certainly in the user partition, unless there's some kind of symlink.
 which guide did you follow. the ubports docs one, or the ubuntu wiki?
 The UBports one.
 A combination of knowing xenial is coming up quickly and wanting to reflash the tablet with the original image from Bq (also not workign out for me) resulted in me not spending a lot of time working on it.  (I'm using a frieza device.)
 [Edit] A combination of knowing xenial is coming up quickly and wanting to reflash the tablet with the original image from Bq (also not working out for me) resulted in me not spending a lot of time working on it.  (I'm using a frieza device.)
 you could try the ubuntu wiki's instruction. it includes installing libertine with apt, which just might add something you could be missing. it at least installs the gui app so you can manage apps and containers in that.
 Hm, I just have the OpenStore's scope, which seems to work.
 If it's still not working somehow once xenial's released, I'll spend some real tiem with it.  (I know the best time is now with the rc, but I don't have the time to keep flashing over and over, and xenial is missing a lot of apps.)
 Man, the terminal app on Xenial is awesome!
 Is it?
 such an improvement over an already great app
 it's a fullblown terminal with everything necessary
 I would use it on desktop
 Easy to use tabs, splitting windows horizontally and vertically, good aesthetics
 (Photo, 1920x1200) https://irc.ubports.com/yFAq2vjE.png
 @nhaines, it is
 that's in windowed mode right? … transparency doesn't work in staged mode … and hell yeah, the new terminal is awesome :)
 Yeah, in staged mode I often have this problem, where the touch doesn't work on right side of the screen
 apart from the top panel
 so I always run in windowed
 I noticed a strange behaviour in libertine though. Applications open a new window whenever there's a menu option unrolled
 IE, if I click on File menu in Gimp, instead of just showing the File menu options it opens a new fullscreen window
 with the options
 Hmm... damn, not enough space in root to install byobu :(
 I wonder what can I remove without crippling my system.
 @tylnesh, interesting. seems there has been some tweaking with window classes? what does it do with dialogies? do open/save/print dialogues get their own window too?
 yep
 everything
 and when I click on Window->Single window mode in Gimp, it spawns another (incomplete) window
 and when launching GIMP with SWM enabled, it opens a full window in the foreground and two windows (layers and controls) in the background
 hmm I think I know what are you refering to.. it happens the same with Unity8 on desktop
 in xenial every new window spawned by a libertine app opens in the same window (start gnome-terminal, type `gedit` > gedit overlaps terminal instead of getting it's own windows
 [Edit] in xenial every new window spawned by a libertine app opens in the same window (start gnome-terminal, type `gedit` > gedit overlaps terminal instead of getting it's own windows)
 yes
 it has something to do with mir
 and if the app is qt bla bla, technica stuff that I dont understand
 so we go from everything in the same window to EVERYTHING in a new window 😆
 but the same thing you can experience on desktop
 @YougoChats, Yep :D
 every xmir app gets it's own xsession inside a mir window. some sanity must be achieved about what items spawned by the xmir app must stay in the same xsession (menus, toolbars, tooltips etc) and which ones must get their own xsession (floating toolbars like gimp's, dialogues, new apps spawned by the original app, like starting f
[07:50] <ubptgbot> rom terminal, or a browser tab detached to or opened in a new window)
 that happens with qt apps that are natively run in mir … menus open in a new window
 but qt apps in libertine too?
 i have vlc in libertine on vivid and it opens menus in its main window
 i haven't really used libertine that much … I'm a rebel...I install apps directly LOL
 but yeah, on vivid xmir, menus work fine
 (Sticker, 512x512) https://irc.ubports.com/FBAhwtTC.webp
[09:07] <ubptgbot> hassan_mohamad was added by: hassan_mohamad
[09:09] <ubptgbot> italian00 was added by: italian00
 Hi all!
[09:19] <ubptgbot> iamr00t was added by: iamr00t
 @Javacookies, Can you write down the instructions for installing apps directly??
 @Javacookies, [Edit] Can you write down the instructions for installing apps directly?
 I can't, it's not advisable! 😁
 Hi @italian00 & @iamr00t , welcome!!! Take a look to https://ubports.com/telegram-welcome to get you started !! There are  language focus groups too.
 The advice can be obtained quite straigtforwardly via search engines, if you take responsibility for the risks.
 LOL … actually it's quite easy to install, just make you filesystem writable then you can install app via apt
 creating app launchers would need a couple of steps though
 and you only have 2GB of space by default and mostly taken up already
[09:49] <ubptgbot> javic was added by: javic
 @javic, Hello Javic … You can read more about UBports here … https://ubports.com/page/telegram-welcome … What is your first language?
 Hello, Spanish
 Hola :)
 @Stereofont, English
 Ok Wiz
 Ok Lionelb
 Hola advocatux
 Hi :) You can join us in the Spanish group too 👍
[11:00] <ubptgbot> aryanpathania was added by: aryanpathania
 @advocatux, Ok
 javic also if you set an alias in your Telegram account it's easier to ping you
 @aryanpathania, Hi Aryan, welcome! Take a look to https://ubports.com/page/telegram-welcome :)
 @advocatux, Hi
 👋
 @Javacookies, Ah, yeah, right.. I do this as well for byobu and other utilities. Didn't know you can do it with X apps, though. And in Xenial, there ain't enough space for even byobu on the root partition
 @Javacookies, Don't worry.. back on vivid, I changed part of my sources to point to artful...
[11:06] <ubptgbot> saarja was added by: saarja
 Somehow, the device did not burst into flames
 Bye. I go to spanish group. 👋🏻
 Thanks!!!
 Welcome @saarja !!! Check out this to get you started! If you have any questions, feel free to ask here or in our Welcome and Install room! https://ubports.com/page/telegram-welcome
[11:51] <ubptgbot> Anto Josu was added by: Anto Josu
[11:53] <ubptgbot> <Anto Josu> Hi
[11:53] <ubptgbot> <Anto Josu> I would like to know that whether ubuntu touch runs on 512 mb ram
 i don't think that will be a good experience. what device are you talking about?
[11:59] <ubptgbot> <Anto Josu> Gionee P2S
 that device is not supported. you can see which devices are supported on https://devices.ubuntu-touch.io/
 oo
 (Voice, 5s) https://irc.ubports.com/37MgjuCA.oga
 (Photo, 1280x720) https://irc.ubports.com/rDd0X4d0.png
 @piday72 please, don't spam this group. Next time you'll be banned
 Please add support for Xiaomi Redmi Note 4X, its a very popular phone now.
 Some devs are trying to port these Redmi devices https://github.com/Halium/projectmanagement/issues?utf8=%E2%9C%93&q=is%3Aissue+Redmi but porting it isn't an easy task
 Owh,I see. Hope they succeed soon
 You can read this https://docs.ubports.com/en/latest/porting/introduction.html if you want to get the idea of how complex porting is
 and all the people doing it are volunteers 😉
 @Anto Josu, Some legacy devices run with 1Gb but the threshold for smooth operation seems to be around 1.5Gb
 @Anto Josu, I suggest you to try postmarketOS
 https://www.postmarketos.org/
 it runs ok on devices with 512Mb
[13:04] <ubptgbot> John was added by: John
 Hmm, but there are quite a lot of devices here: https://github.com/Halium/halium-devices/tree/halium-7.1/manifests - I've never checked. How is Ubuntu Touch working on Halium? Were all things resolved and should it just work now or are there still some issues?
 @zubozrout, CAF is broken
 and UBports requires building a different boot image (halium-boot)
 but well it got better
 you should look at projectmanagement issues to find out if UT works on that device
 manifests are just trees for the build. for example i built a dream2lte image, but it doesn't even boot yet
 Welcome John !!! Check this put for more about UBports https://ubports.com/page/telegram-welcome
 @vanyasem, https://github.com/Halium/projectmanagement/issues?q=is%3Aopen+is%3Aissue+label%3APorts
 Any one tried the voice assistant for UT  i saw it in git-hub
 @vanyasem Thanks :)
 take a look at this one for example
 https://github.com/Halium/projectmanagement/issues/28
 it has nice photos in comments
 Cool, even with screenshots to make this more interesting :)
 @vanyasem, except that he won't be able to use it as phone :)
 Fwd from ℑnςo๓ع ᴮᵒᵗ ᶜᵃˢʰ: [[](http://telegr](http://t.me/Bitcoin_Cloud_Mining_bot?start=544874992)[](http://telegra.ph/file/ab02c7c582cfed2cfc3c1.jpg)🎖Trusted Paying Bot … Earn without any fee or points … 📂 ɴᴀᴍᴇ: Bitcoin Cloud Mining … 🌐 ʟɪɴᴋ: BitconCloudMining … 📥 ᴍɪɴ ɪɴᴠᴇsᴛ: no investment … 📤 ᴍɪɴ ᴡɪᴛʜᴅʀᴀᴡ: 0
[13:14] <ubptgbot> .001 … 🤖 ʙᴏᴛ ᴛʏᴘᴇ: mining / game … ⁉ sᴛᴀᴛᴜs: PAYING … ⚠ New server comes with fast mining. … ✅ another payout
 @mariogrip @UniversalSuperBox spam
 gtfo spam :D
 ah man, i was so going to cllick that!
 @mariogrip, R u the one in the ubports youtube video
 @John, one of them yeah
 @mariogrip, xD
 @mariogrip, U r doing great job congrats
 @John, Thanks :D :D what video did you watch if i may ask? was it one of the q/a?
 Yea bits of all 30 videos
 @mariogrip, must have been one where your internet was working :D
 @dohbee, ouch :P
 @John, Aweome :D didnt know it was that many videos yet even :D
 feels like we started the q/a just some month ago, not a full year
 *close to a full yeah*
 @mariogrip, In case you're interested, I've seen you for the first time in a Lunduke interview
 Together with Bhushan
 I instantly fell in love
 haha :P me and bhushan is extra qute togheter
 Hey is it possible to install chrome addons on new browser
[14:01] <ZeroPointEnergy> I destroyed (physically) my Aquaris E5 and now I had to reflash my Samsung S7 I used for development with Lineage because I needed a working phone :'(
 destroyed? not just break but destroyed? what did you do?
 @John, not visual ones, no
 but things that hook into the rendering engine you can make work
 does the openstore automatically detect vivid versions of apps and suggest user to update to xenial version if there's available?
 I'm talking about when upgrading to xenial without wiping
 I see many posts that has this topic especially with the openstore app
 No I dont think so ;)
[15:07] <ZeroPointEnergy> YougoChats: It got bent, so the glass broke and the touchscreen is no longer working
[15:10] <ZeroPointEnergy> Not sure if I just should get one of the supported devices or just wait for the librem 5. Also the librem dev kit should soon show up, so at least  I can experiment again. But android is just horrible
 Hi. I tried to update my 16.04 and after reboot freezed like this...
 (Photo, 1280x720) https://irc.ubports.com/D7RlUW5q.png
 (Photo, 1280x720) https://irc.ubports.com/WSHXPTWN.png
 What may i do?
[15:14] <ubptgbot> ClayFM was added by: ClayFM
 a random thought, but maybe we could get community-supported MediaTek device that is cheap, currently available to buy, yet has kernel sources? at least it doesn't suffer from CAF issues
[15:23] <ubptgbot> MelodyTheFolf was added by: MelodyTheFolf
 @NotKit, https://forum.xda-developers.com/redmi-note-4/development/rom-lineageos-14-1-xiaomi-redmi-note-4-t3760332
 Redmi 4 note mtk edition maybe?
 no kernel source
 Sony phones have kernel sources avaliable, but... 1. no support 2. sony devices can be a PITA
 How about 1st gen android one?
 https://forum.xda-developers.com/crossdevice-dev/android-one-crossdevice-development-original-android-development/rom-lineageos-14-1-android-one-1st-gen-t3744646
 Welcome @ClayFM & @MelodyTheFolf !!! Check out https://ubports.com/page/telegram-welcome to get you up to speed
 @VeryOriginalUsername, it's rather old, approximately same hw as BQ Aquaris
 Thank you!
 @Jyoti, Hi Jyoti. Please join https://ubports.com/page/telegram-welcome
 Bastaaaardo
 I'm waiting, but nothing is happening, the phone was stopped in this image ... I can move between the options but I do not know which option to choose ...
 @Jyoti, If the first one is "Reboot to system" or something like that what about that?
 I tried this option, rebooted and after that, when i try to update, start to reboot and again shows this image
 So you can boot the system normally but just can't update?
 @zubozrout, Yes, the first option is to reboot
 @zubozrout, Yes, i guess is the only problem. Can boot, cant update
 Maybe i will just boot and not update for npw
 Jyoti: … Maybe i will just boot and not update for now
 Well that sounds odd. But unfortunately can't test this as I don'ŧ have a BQ device. Are you on devel channel?
 [Edit] Well that sounds odd. But unfortunately can't test this as I don't have a BQ device. Are you on devel channel?
 It could be that today's build is somehow broken for frieza - it does work on arale though. But devel can break any time so maybe next build will install normally.
 @zubozrout, Ok. Thanks you anyway
 @zubozrout, I mean, thank you  :-)
 Hi
 Any news about Decko for xenial ?
 Work In Progress :)
 ok
 well, trying again to create a xenial container on my n4, after patching libertine
 ubports tr not open :(
 @ankaos, it's open. but there's only 14 members in it, and you just joined and asked something. give it time
[17:43] <ubptgbot> bapakmuu was added by: bapakmuu
 Welcome bapakmuu !!! Check out this to get you started! If you have any questions, feel free to ask here or in our Welcome and Install room! https://ubports.com/page/telegram-welcome
 @mariogrip hmm, can we maybe rebuild all the device kernels without the seccomp backports?
 @dohbee, patching?
 @dohniks, patched to not add the overlay ppa, and to add the ubports repo instead
 ok
 Hi all. A question: Can I change 16.04  repository from devel to RC without lost anything? Is it advisable? Thanks
 @RoccoOPO yes, you can do it without any problem. About if it is advisable or not to do it, it just depends on what you want to do :)
 Of course remaining in develop mode I have the system always updated...
 devel updates daily (more or less) and RC does it weekly
 OK, thanks
 👍
 Hi all, how can I build and test the https://github.com/ubports/keyboard-component ? Thanks
[20:50] <ubptgbot> Domi was added by: Domi
 Welcome Domi !!! Check out https://ubports.com/page/telegram-welcome to get you started, we have language groups available.
 My Pro 5 took a full body dip in water this morning :(
 I dried it out in a pot of rice for 9 hours. Turning it on, I noticed:
 a) The SIM wasn't responding but after switching slots back and forth and trying my dad's card, it seems to be back now.
 Rice is generally too moist to do anything but make things really messy
 b) The selfie cam is foggy, hopefully that dries out.
 this is why I keep silica gel packets around
 c) The headphone port isn't responding to the plug going in or out. By default it thinks headphones are always plugged in. I can adjust outputs manually in Pavucontrol on Libertine, but this could be rather inconvenient e.g. for incoming calls.
 I took the SIM slot out to fully expose everything and now I'm drying it out again overnight.
 What would you guys recommend for drying if not rice?  Can it be corrected if the water fully dries out, or should I assume the circuitry is damaged for good?
 I don't have rubbing alcohol to hand, I'm not sure about a hair dryer.
 "depends"
 Make backup now that you still can. Most likely that phone is going to die. So do it until is too late
 [Edit] Make backup now that you still can. Most likely that phone is going to die. So do it now until is too late
 Sure, I'll do that in the morning after this rice bath.
 The SD card is mostly backed up and it's out of the phone so I can get the rest of it tonight.
 😺👍
 I will say my old HTC M7 took a dunk and it was significantly damaged before that but after IDK if it had any more signifcant effect. Really all I noticed was a cluster of dead pixels in one corner. Let's try to be optimistic.
 *significant
 SIlica gel packets are made up of small beads, right? Would one need a large number of packets to submerge the phone?
 really the water itself isn't the problem. it's the minerals in the water, which will be left behind after it evaporates
 disassembly + alcohol/sonic bath + hair dryer is the best if you can. but disassembling phones is pretty hard
 depends on the phone, heh
 The most important action is to cut off the supply (battery out). Then is time to dry.
 If the water had salt it's better bath it in clean water. If it hadn't better dry it.
 Don't have a sonic drier to hand either.
 In teardown videos, they seem to use some sort of magnetic device to raise the LCD screen from the device. Would that be another requirement?
 Put it into a no frost fridge.
 How does one determine if you own a no frost fridge?
 When you buy it. They sell it.
 It removes the water with air.
 My father bought a new fridge/freezer combo recently. I'd have to check the model.
 Perhaps. He should know it because it dries the things. You have to cover them.
 My guess is it's just a conventional model. Maybe I should take it to a professional teardown and repair service.
 It will be in the manual.
 Forget it.
 I mean, take the phone in for repair.
 May be.
 But I think of two options: If when it is dry it go, ok. Else buy another one.
 [Edit] But I think of two options: If when it is dry it goes, ok. Else buy another one.
 Yep, in the worst case scenario I will back up everything, sell it as a (mildly) damaged phone on eBay and order a new Pro 5 in time for Xenial.
 Ok. We expect it'll be ok tomorrow.
 Asking on Facebook for recommendations for phone repair. There's a Hacklab which might have all the required tools and would probably do it for free and/or let me take the reins.
 In the city of Edinburgh, I mean.


[18:39] <x58> Morning all... trying to get the latest cloud-init (0.7.7) on CentOS 7 to write out ifcfg-eth0/eth1 based upon ConfigDrive, however it seems to be using the fallback source.
[18:39] <x58> Is this not currently implemented?
[19:29] <x58> Nevermind, it is implemented. Just need a release that fixes https://bugs.launchpad.net/cloud-init/+bug/1610784


[00:00] <gsilvapt> Anyway, here's my understanding:
[00:01] <gsilvapt> The @click.version_option() command should be like @click.version_option(message.format(snapcraft.__version__))
[00:01] <gsilvapt> This get the version number and plugs it in the variable string
[00:01] <gsilvapt> The same goes in the version module. click.echo(message.format(snapcraft.__version__))
[00:02] <gsilvapt> kyrofa, is this correct so far?
[00:03] <kyrofa> Essentially. The question is: where does `message` come from?
[00:04] <gsilvapt> Yes
[00:07] <kennyloggins> how do you ensure that the Mp3 or whatever you are sending is seen in servicesID ?
[00:08] <kyrofa> Hmm. Anyone run into this before? https://forum.snapcraft.io/t/raspberry-pi-2-edge-core-snap-seems-broken/3061/2
[00:09] <gsilvapt> Yes, that is essentially the question, kyrofa
[00:09] <kyrofa> gsilvapt, you've been right so far, can you continue?
[00:09] <gsilvapt> I tried adding in version module, before click statement and didn't work. Tried adding to group section, not worked either
[00:10] <gsilvapt> kyrofa, not really. The question is where should I define that variable
[00:10] <kyrofa> gsilvapt, take a look at snapcraft/cli/store.py
[00:11] <kyrofa> gsilvapt, notice the `_MESSAGE_REGISTER_PRIVATE` definition
[00:11] <gsilvapt> kyrofa, yes, I'm trying to follow the example
[00:12] <kyrofa> gsilvapt, the module-level definitions (like the variable) are accessible from __init__ because we have an "import versioncli" there, right?
[00:12] <kyrofa> Which means you can access stuff via `versioncli.<variable>`
[00:12] <kyrofa> Uh, no sorry
[00:12] <kyrofa> Haha
[00:13] <kyrofa> Rather, the module-level definitions are available in the `.version` import
[00:13] <kyrofa> Note how in __init__.py we're using `from .version import versioncli`
[00:13] <kyrofa> All we need to do is also import the variable you define in there
[00:13] <kyrofa> It works the same way
[00:15] <gsilvapt> kyrofa, so I added from .version import _MESSAGE_SNAPCRAFT_VERSION and I am able to use the command again without any errors
[00:16] <gsilvapt> now I have to properly define the string to get prog name and version number
[00:16] <gsilvapt> Right now the version command is always retrieving ($prog) and ($version)
[00:16] <kyrofa> There you go. Although since you've created it for use for other modules I wouldn't use an underscore at the beginning (that indicates that it's mean to be private)
[00:17] <gsilvapt> Oh right, this is different in Python. A global variable does not take any underscore, right?
[00:17] <kyrofa> Well, it can, it depends on its usage
[00:18] <gsilvapt> kyrofa, how about this case?
[00:18] <kyrofa> Python has very little rules, but lots of conventions
[00:18] <kyrofa> I would call it `SNAPCRAFT_VERSION_TEMPLATE`
[00:18] <gsilvapt> I'm more used to work in Java and this stuff is specific anyway :P
[00:20] <gsilvapt> Well, it's late again and I need to sleep. I hope we can work on this together some time soon. I think it is working now but the string is poorly defined. I need to tell Python where to get the variable values ($prog) and ($version)
[00:20] <gsilvapt> %(prog) and %(version) instead of what I wrote before, lol
[00:23] <kyrofa> Yeah that's not too hard, happy to work on it later with ya
[00:23] <gsilvapt> Thank you! Have a good night folks o/
[00:23] <kennyloggins> o/
[00:24] <kyrofa> Night gsilvapt
[00:35] <mup> PR snapcraft#1728 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1728>
[02:42] <sergiusens> elopio kyrofa snapcraft#1781 is updated
[02:42] <mup> PR snapcraft#1781: many: set rpath for elf files for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1781>
[07:26] <mborzecki> morning
[07:27] <mborzecki> sorry i'm later than usual, had to drive the kids to school & kindergarten
[07:27] <mvo> hey mborzecki, good morning!
[07:27] <mvo> mborzecki: no worries
[07:28] <mborzecki> mvo: thanks for the review & suggestions btw
[07:29] <mvo> mborzecki: your welcome, but I may have been to simplistic, I think there are more cyclic case
[07:30] <mvo> mborzecki: something like "a: after-b, b: after-c, c: before-a
[07:30] <mvo> mborzecki: which I guess (I need to look again) your code addressed but mine did not
[07:30] <mborzecki> zyga suggested trying to do topo sorting on a graph, so i tried to play with this yesterday, but the naiive approach that i did over the weekend beat the 'smart' in all the cases i tried
[07:31] <mvo> mborzecki: heh :) yeah, our inputs are pretty small
[07:31] <mvo> mborzecki: I will look at this again with a fresh mind today
[07:33] <mborzecki> the benchmarks would suggest that we're loosing on doing extra allocations when creating the 'extra' data structures either dfs or khan may need
[07:34] <mborzecki> mvo: one thing that bugs me, is that if you add 'after' does that imply 'Requires=' in the service file?
[07:37] <mvo> mborzecki: I think it does not imply this, one is about ordering, the other about dependencies, they are often used together but orthogonal. i.e. you can express "if this thing.service is installed I want to start before. without the requires it also says: but I don't care if it is there or not"
[07:38] <mborzecki> this post mentions 'with' https://forum.snapcraft.io/t/snap-service-start-ordering/1470/13 this might map to Requires
[07:38] <mvo> mborzecki: yeah, I think there is language in there (as a next step) to express these dependeices as well
[07:40] <mborzecki> let's land this one first and we'll know if there's need for more ways to express dependencies
[07:58] <kalikiana> good morning folks
[07:59] <mborzecki> kalikiana: morning
[08:06] <mup> PR snapd#4361 opened: devicestate: fix misbehaving test when using systemd-resolved <Created by mvo5> <https://github.com/snapcore/snapd/pull/4361>
[08:36] <jamesh> mvo: I uploaded a new version of the test-snapd-gnome-online-accounts snap (the original wouldn't run due to library incompatibility), which seems to have been held up by the automatic review process.  Are you able to do anything about that?
[08:41] <mvo> jamesh: probably, let me check
[08:43] <mvo> jamesh: did you request a manual review?
[08:43] <mvo> jamesh: if not, please do
[08:44] <jamesh> mvo: I've done that now
[08:45] <mvo> jamesh: approved
[08:45] <jamesh> thanks
[08:45] <mvo> jamesh: yw, shall I pushlish it as well?
[08:46] <jamesh> mvo: I think I've got it published right now
[08:47] <jamesh> thanks for the help
[08:47] <mvo> great, your welcome
[09:04] <pedronis> mvo: is edge building still broken?  afaict  current edge doesn't contain yet the configure-snapd fix
[09:06] <mvo> pedronis: let me check, I though I triggered a manual build the other day. auto-building is broken
[09:06] <mvo> pedronis: let me trigger it now
[09:19] <zyga-ubuntu> o/
[09:20] <zyga-ubuntu> man, I overslept
[09:25] <Chipaca> I ended up poking at spread in qemu until way too late :-)
[09:26] <Chipaca> but, now i'm off to physio gym thing, so it evens out
[09:26] <zyga-ubuntu> Chipaca: what did you find?
[09:26] <Chipaca> o/
[09:26] <zyga-ubuntu> ah, ttyl
[09:26] <Chipaca> zyga-ubuntu: i found that it's weird :-)
[09:26] <zyga-ubuntu> pfff, we all knew that
[09:26] <zyga-ubuntu> ;-)
[09:26] <zyga-ubuntu> enjoy; let's talk soon
[09:26] <Chipaca> zyga-ubuntu: i've got two straces, one that dies and one that doesn't
[09:27] <Chipaca> zyga-ubuntu: I don't see the difference
[09:27] <zyga-ubuntu> pastebin thenm
[09:27] <zyga-ubuntu> them*
[09:27] <mvo> +1
[09:27] <zyga-ubuntu> o/ mvo
[09:27] <zyga-ubuntu> I have a pastebin I'm chewing through since yesterday, today I need to do some practical experiments on non-test machines
[09:27] <mvo> cachio_: fwiw, trying to reproduce the install-cache test failure you mentioned on ubuntu-core-16-64 seems to be ok for
[09:27] <zyga-ubuntu> well, on non-spread test machines running core
[09:28] <mvo> cachio_: I try harder
[09:28] <mvo> hey zyga-ubuntu
[09:28] <zyga-ubuntu> we are doing some very weird things on core
[09:28] <zyga-ubuntu> (lots of red lights in my mind)
[09:28] <zyga-ubuntu> the failure of those tests I mentioned yesterday, with the stale core detection, is deeper
[09:28] <zyga-ubuntu> even if we reboot the system is really broken IMO
[09:28] <mvo> zyga-ubuntu: oh
[09:29] <Chipaca> http://paste.ubuntu.com/26123959/ and http://paste.ubuntu.com/26123957/
[09:29] <mvo> zyga-ubuntu: tell me more?
[09:29] <mvo> zyga-ubuntu: please
[09:29] <zyga-ubuntu> mvo: the pastebin I sent you pics of yesterday was from the console of a core system
[09:29] <zyga-ubuntu> mvo: it seems that we mount / twice
[09:29] <zyga-ubuntu> mvo: with a load of things in between
[09:30] <zyga-ubuntu> mvo: my understanding of how this works means that _all_ of the things we mounted before 2nd / are just wasted memory and hidden entries
[09:30] <zyga-ubuntu> mvo: I don't yet know why we do that
[09:30] <mvo> zyga-ubuntu: could it be a pivot root thing going on?
[09:30] <zyga-ubuntu> mvo: it might be but pivot root would leave / mounted elsewhere
[09:30] <zyga-ubuntu> you cannot pivot root / /
[09:30] <zyga-ubuntu> (no op)
[09:30] <mvo> zyga-ubuntu: well, we need to work on this for base-18 anyway, so a good time to cleanup
[09:30] <zyga-ubuntu> http://pastebin.ubuntu.com/26118789/
[09:30] <zyga-ubuntu> mvo: good to hear
[09:31] <zyga-ubuntu> mvo: I'll poke at a real pi3 device and see if this is consistent
[09:31] <mvo> zyga-ubuntu: have you looked at the initramfs code? the writable path things makes it messy, I'm all for a cleanup
[09:31] <mvo> (and historic baggage)
[09:32] <Chipaca> ok, i'm off for real now. I'll leave you guys to ponder which one of those two traces is the one that kills the whole session.
[09:33] <Chipaca> to me they look identical
[09:33] <zyga-ubuntu> Chipaca: ha, good plan :)
[09:33] <Chipaca> (but yes, i know which is which)
[09:34] <Chipaca> it's as if one of them closed stdout, or stderr, or stdin, or whatever it is
[09:34] <Chipaca> hmm
[09:34]  * zyga-ubuntu hates pastebein with moronic need to auth
[09:34] <zyga-ubuntu> no wget
[09:34] <mvo> zyga-ubuntu: I'm looking at the pictures you pasted, I see core_ mounted twice on / is that what you are concerend about?
[09:34] <zyga-ubuntu> mvo: yes
[09:34] <zyga-ubuntu> mvo: IMO that is wrong
[09:34] <Chipaca> zyga-ubuntu: blame spammers
[09:34] <mup> PR snapd#4362 opened: interfaces: update fixme comments <Created by stolowski> <https://github.com/snapcore/snapd/pull/4362>
[09:35]  * Chipaca runs off before he gets sucked in again
[09:35] <pstolowski> zyga-ubuntu, ^ hey, one of the changes you requested - just an update of comments, no code change
[09:35] <mvo> zyga-ubuntu: yeah, let me wander into initramfs land again /me puts on asbestos cloth
[09:35] <zyga-ubuntu> mvo: yeah
[09:35] <mwhudson> zyga-ubuntu: did i ever tell you about debugging docker on arm64 where cloneflags was ignored so pivot_root was called in the default namespace
[09:35] <zyga-ubuntu> mvo: I'll gladly work on fixing this
[09:35] <mwhudson> zyga-ubuntu: that was quite confusing :)
[09:36] <zyga-ubuntu> mwhudson: haha, that must have been quite the alice in wonderland moment
[09:36] <mwhudson> especially as the host system didn't have an awful lot on it to distinguish it from the docker image i was testing with
[09:36] <mvo> zyga-ubuntu: we need to be careful this sh code is undertested
[09:36] <mvo> mwhudson: woah :)
[09:36] <mwhudson> i run docker run foo ... and docker itself disappears?
[09:38] <zyga-ubuntu> mvo: I'm acutely aware of that :/
[09:39] <mvo> zyga-ubuntu: I know :)
[09:40] <mvo> zyga-ubuntu: I may have found the bug already and its amazingly stupid
[09:40] <mvo> zyga-ubuntu: my conservative self is not wanting me to say this, but: I really want to write the initramfs stuff in something sane that is not sh
[09:40] <zyga-ubuntu> !!!
[09:41] <zyga-ubuntu> that was quick
[09:41] <zyga-ubuntu> mvo: skunkworks project to rewrite that +1
[09:41] <zyga-ubuntu> mvo: just not in go (we cannot)
[09:41] <mvo> zyga-ubuntu: no go because of the setns issues?
[09:41] <zyga-ubuntu> mvo: so, this is interesting: on bare metal I don't see that problem: http://pastebin.ubuntu.com/26123995/
[09:42] <mvo> with threading and all that
[09:42] <zyga-ubuntu> mvo: not only setns but yes
[09:42] <zyga-ubuntu> mvo: 1thread requirement
[09:43] <zyga-ubuntu> mvo: the fact that / is mounted from initramfs and then core is mounted again from userspace is also a bit annoying but I don't know if it's worth fixing
[09:43] <zyga-ubuntu> http://pastebin.ubuntu.com/26123999/ <- core snap mounted twice
[09:43] <mvo> zyga-ubuntu: yes
[09:44] <mvo> pedronis: new core snap in edge should have the configure-snapd fix now, I did a bit of manual handholding
[09:45] <zyga-ubuntu> mvo: also interesting: http://pastebin.ubuntu.com/26124012/ the two snaps we mount from initramfs are mounted as _writable_ and not as auto-clear
[09:45] <zyga-ubuntu> mvo: the auto clear is probably irrelevant but the writable bit should have never been set
[09:45] <zyga-ubuntu> mvo: this allows an attacker to write to loop0 and change the squashfs bits
[09:47] <mvo> zyga-ubuntu: aha, that should be an easy fix, one minute
[09:48] <mvo> zyga-ubuntu: http://paste.ubuntu.com/26124029/
[09:49] <zyga-ubuntu> mvo: +1
[09:50] <zyga-ubuntu> mvo: every time I look at that pile if shell I feel bad
[09:51] <mvo> zyga-ubuntu: yeah, makes me want to scrub myself
[09:51] <zyga-ubuntu> mvo: can you fix inconsistent tabs/spaces
[09:51] <mvo> zyga-ubuntu: anyway, lets see what we can do to fix things
[09:51] <zyga-ubuntu> mvo: if you are going to make changes there
[09:51] <pedronis> mvo: thank you, refresh to it now worked
[09:51] <zyga-ubuntu> mvo: I'll check other systems, I don't understand if the brokenness I saw is specific to spread
[09:52] <mvo> pedronis: yay
[09:52] <mup> Issue snapcraft#1702 closed: Apply guidelines from design to error messages with reasons for errors <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1702>
[09:52] <mup> PR snapcraft#1640 closed: cli: add what, why, and how to fix to the common errors <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1640>
[09:52] <pstolowski> pedronis, hey, can you take a look and weight on #4301? I've addressed the last bit from Gustavo (AttrGetter -> Attrer renaming), but aparently he didn't manage to re-review yesterday, would be good to land it as it's a prerequisite for others
[09:52] <mup> PR #4301: interfaces: PlugInfo/SlotInfo/ConnectedPlug/ConnectedSlot attribute helpers <Created by stolowski> <https://github.com/snapcore/snapd/pull/4301>
[09:52] <zyga-ubuntu> mvo: and btw, I don't see any use of pivot_root
[09:52] <zyga-ubuntu> mvo: is it hidden somewhere or are we just missing it?
[09:53] <mvo> zyga-ubuntu: I think I may misrember actually
[09:53] <mvo> zyga-ubuntu: now that I look at the code its less clear to me what is going on
[09:53] <pedronis> pstolowski: will look in  a bit
[09:53] <zyga-ubuntu> mvo: I'll check dragon and I'll get an amd64 image for qemu
[09:54] <mup> PR core-build#24 opened: ubuntu-core-rootfs: mount os/kernel snaps RO <Created by mvo5> <https://github.com/snapcore/core-build/pull/24>
[09:55] <mup> Issue snapcraft#1663 closed: patchelf with common rpath (not runpath) <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1663>
[09:55] <mup> PR snapcraft#1781 closed: many: set rpath for elf files for classic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1781>
[09:55] <zyga-ubuntu> mvo: can you test your PR in practice and see that losetup --json shows it's correct then?
[09:55] <zyga-ubuntu> mvo: a manual test if you can do that
[09:56] <zyga-ubuntu> mvo: I approved the PR already
[09:57] <zyga-ubuntu> mvo: we really have to rewrite mount units
[09:57] <zyga-ubuntu> mvo: on dragon I see three generation of mount files we write
[09:58] <zyga-ubuntu> mvo: a simple rewrite that fixes things for next boot would be good
[10:05] <zyga-ubuntu> mvo: uh, my mistake, I was blinded by odd double-sided print
[10:05] <zyga-ubuntu> mvo: stop looking for double / :)
[10:05] <zyga-ubuntu> mvo: so now I'm back to square one, what is wrong there :/
[10:06] <mvo> zyga-ubuntu: rewrite fix is still needed? or should I also scratch that?
[10:06] <mup> PR snapd#4363 opened: cmd/snap-mgmt: add more directories for cleanup and refactor purge() code <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4363>
[10:07] <mvo> zyga-ubuntu: rewriting with the before=snapd.servie?
[10:07] <zyga-ubuntu> mvo: no, that is still needed
[10:07] <zyga-ubuntu> mvo: that should have been there forever
[10:08] <mvo> zyga-ubuntu: ok, but "just" that - or do we need more rewrite?
[10:08] <zyga-ubuntu> mvo: not sure I understand the difference; we need to be able to rewrite mount units and and we ought to rewrite mount units in the field to correct for past mistakes
[10:10] <mvo> zyga-ubuntu: we are in agreement, I was wondering if there is a new bug that requires us to rewrite them
[10:10] <zyga-ubuntu> aha, sorry for being confusing then
[10:10] <mvo> zyga-ubuntu: I will have a look. no worries, communication is hard :)
[10:10] <mvo> (it always is!)
[10:10] <zyga-ubuntu> mvo: the pastebin I sent you, I was holding it wrong, litteraly :)
[10:10] <zyga-ubuntu> I looked at head of both inside and outside parts
[10:11] <mvo> zyga-ubuntu: heh
[10:11] <mvo> zyga-ubuntu: we have 256 files in etc and var in my base-18 WIP snap :/ there is quite some work to get rid of those if we want to get rid of the writable-path magic
[10:12]  * mvo gets to work
[10:12] <zyga-ubuntu> mvo: where do you do this work?
[10:12] <zyga-ubuntu> mvo: I'd love a new repo for base-18
[10:13] <mvo> zyga-ubuntu: lp:snap-base-18
[10:13] <mvo> zyga-ubuntu: so far very minimal/experimental/WIP but its a start
[10:14] <zyga-ubuntu> bzr or git?
[10:14] <mvo> zyga-ubuntu: git
[10:14] <mvo> zyga-ubuntu: what is bzr?
[10:14] <zyga-ubuntu> hhaha
[10:14]  * zyga-ubuntu checks how to clone from launchpad
[10:14] <mvo> zyga-ubuntu: https://github.com/snapcore/base-18 :P
[10:15]  * mvo is afk for some minutes
[10:15] <zyga-ubuntu> mvo: so is it on launchpad or github?
[10:21] <zyga-ubuntu> mvo: I've started sending PRs
[10:36] <brunosfer> Hi guys, does anyone know how can I enable the driver from bluetooth on the Raspberry Pi with Ubuntu snappy core?
[10:40] <zyga-ubuntu> brunosfer: it should already be enabled,
[10:40] <mvo> zyga-ubuntu: github
[10:40] <zyga-ubuntu> ok
[10:40] <zyga-ubuntu> mvo: I send one trivial PR
[10:40] <zyga-ubuntu> mvo: how do you test/use this?
[10:41] <zyga-ubuntu> mvo: one more
[10:42] <mvo> zyga-ubuntu: well, I build a snap :) thats all there is for tests so far
[10:43] <mvo> zyga-ubuntu: good stuff, thank you!
[10:43] <zyga-ubuntu> mvo: ha, well, I didn't think of that :)
[10:43] <mvo> zyga-ubuntu: but yeah, its a good question, we need more automation and travis and all that here
[10:43] <zyga-ubuntu> mvo: snapcraft fails, did you run it via fakeroot?
[10:44] <mvo> zyga-ubuntu: yes, it needs to run as root currently, I think fakeroot will work
[10:44] <mvo> zyga-ubuntu: the LP builder runs it as real root
[10:44]  * zyga-ubuntu tries fakeroot snapcraft
[10:45] <mvo> zyga-ubuntu: what is annoying is that in order to get to an empty /etc we need to undo the alternatives system i.e. awk which is provided via an alternative
[10:45] <mvo> (and more, w, pager)
[10:46] <zyga-ubuntu> hmm, we need real real root
[10:46] <mvo> zyga-ubuntu: ok, I need to look into why, iirc because of chroot, right?
[10:46] <mvo> zyga-ubuntu: *maybe* fakechroot works
[10:47] <zyga-ubuntu> mvo: no, because of chroot
[10:47] <zyga-ubuntu> mvo: anyway, that's fine,
[10:47] <mvo> zyga-ubuntu: fakechroot may work
[10:47] <zyga-ubuntu> mvo: just trying to see where this is going and what's in the snap
[10:48] <mvo> zyga-ubuntu: I hope it goes into a minimal base that can boot and that works with an empty /etc/ /var so that we can do factory reset easily and don't need the writable-path hacks
[10:48] <ogra_> why dont you just grab an ubuntu-base tarball from cdimage and modify it as needed ...
[10:48] <mvo> ogra_: that would also be an option, right now it is using debootstrap to get that
[10:48] <ogra_> (with a bit of fiddling oyu can even do that completely without chroot calls)
[10:49] <ogra_> mvo, yeah i was guessing that ...
[10:49] <ogra_> ubuntu-base is pretty much a minbase debootstrap though
[10:51] <zyga-ubuntu> mvo: there's some things that should be easy to kill
[10:51] <mvo> ogra_: indeed, interessting
[10:51] <zyga-ubuntu> mvo: etc/selinux
[10:51] <mvo> zyga-ubuntu: yeah /etc/{apt,dpkg}
[10:51] <zyga-ubuntu> mvo: /etc/apt
[10:51] <zyga-ubuntu> yeah
[10:52] <zyga-ubuntu> mvo: /etc/kernel/install.d
[10:52] <mvo> zyga-ubuntu: and some stuff we need to look at and upstream, i.e. if adduser.conf has different defaults than adduser itself we should ensure that gets fixed
[10:52] <ogra_> just dont kill /usr/share/doc/<pkg>/copyrights.gz ...
[10:52] <zyga-ubuntu> ogra_: make that a fuse https FS
[10:52] <zyga-ubuntu> ;-)
[10:52] <mvo> ogra_: yeah, no worries :)
[10:52] <ogra_> :)
[10:53] <mvo> ogra_: its mostly based on the current livecd-rootfs scripts
[10:53] <mvo> ogra_: the new skeleton
[10:53] <mvo> ogra_: but using a different "base"
[10:53] <ogra_> yeah .. many of these scripts can also be dropped
[10:53] <ogra_> we (I) didnt do a good job of throwing away old stuff thats not needed anymore
[10:54] <ogra_> and some bits that live in ubuntu-core-config should rather move to the build scripts ... and vice versa ... someone should do an audit of all this
[10:55] <mvo> ogra_: yeah, the work on this is (slowly) starting with base-18. unfortuantely quite a bit of work but at the same time exciting because of the cleanup potential
[10:55] <ogra_> yep
[10:56] <mvo>  /etc/bindresvport.blacklist <- why do i have this file in /etc :(
[10:56] <ogra_> i'm still curious how it will work out ... but looking massively forward to have bases for commercial projects ... they will massively solve issues i'm running into since i started in the new team
[10:56] <mvo> anyway,
[10:57] <mvo> ogra_: fingers crossed, but I'm excited aboutt the opportunities, all sorts of crazy bases
[10:57] <ogra_> yeah
[11:02] <zyga-ubuntu> mvo: some more stuff in 3
[11:13] <zyga-ubuntu> https://github.com/snapcore/base-18/pull/3
[11:13] <mup> PR base-18#3: Document how to build the project locally, trim /etc, ignore build artefacts <Created by zyga> <https://github.com/snapcore/base-18/pull/3>
[11:14] <zyga-ubuntu> mvo: do we need /etc/init.d?
[11:15] <zyga-ubuntu> mvo: /etc/ld.so.conf.d/libc.conf also looks like something to remove
[11:16] <zyga-ubuntu> mvo: /etc/logrotate.d/{alternatives,dpkg}
[11:16] <zyga-ubuntu> mvo: /etc/profile.d
[11:16] <zyga-ubuntu> mvo: /etc/rc[0-6S].d
[11:17] <zyga-ubuntu> mvo: anyway, I think it would be fantastic if we had a way to kvm-boot this for testing
[11:17] <zyga-ubuntu> mvo: take a kernel snap, base-18 and gadget and boot it some way for very fast iteration
[11:25]  * kalikiana coffee break
[11:36] <kalikiana> okay, that was a lie, I ended up making tea
[11:38]  * zyga-ubuntu wonders when we will see snaps on windows 3.11 http://assets.metacade.com/emulators/win311vr.html
[11:38] <cachio_> mvo, hey
[11:40] <cachio_> mvo, The changelog for 2.30 rc2 doesn't contain the <IP_ADDRESS> changes
[11:40] <cachio_> mvo, is it ok? are those changes included?
[11:48] <mvo> cachio_: thanks for catching that, I will double check
[11:49] <cachio_> mvo, apart of that I have seen some issues during the execution
[11:49] <mvo> zyga-ubuntu: thanks! yeah, I think that must be the goal, right now the initramfs stuff cannot boot bases - just core
[11:49] <mvo> cachio_: tell me more, you mentioned yesterday that the install-cache test fails ?
[11:50] <cachio_> mvo, yes
[11:50] <cachio_> and the error seems to be genuine
[11:51] <cachio_> mvo, similar issue for catalog-update
[11:52] <cachio_> mvo, https://paste.ubuntu.com/26120827/
[11:52] <cachio_> this is a reexec in pi3 for all the errors that I saw
[11:53] <cachio_> some of them are test errors, I am working on fixing them
[11:55] <mvo> cachio_: for the cache-install failure, does that happen just on arm or on any core device?
[11:55] <cachio_> mvo, it was in any core device
[11:55] <cachio_> both tests failed in any core device
[11:55] <cachio_> the install-cache and the catalog-update
[11:56] <cachio_> mvo, I have to go to the doc now
[11:56] <cachio_> I'll be back for the standup
[11:56] <mvo> cachio_: thanks, I need to dig into this then, I was not able to reproduce it from a release/2.30 git checkout and running spread from there, sounds like I need to create an image first
[11:56] <mvo> cachio_: sure, see you. and thanks for the update
[11:56] <cachio_> mvo, np
[11:57] <sergiusens> hello everyone
[11:59] <zyga-ubuntu> hey sergiusens
[11:59] <zyga-ubuntu> sergiusens: what's the weather like where you live?
[11:59] <mborzecki> i bet it's better than here
[11:59] <mvo> zyga-ubuntu: why do you ask?
[12:00] <zyga-ubuntu> mvo: ?
[12:00] <zyga-ubuntu> just curious
[12:00] <mvo> zyga-ubuntu: I was wondering if you want to fly there ;)
[12:00] <sergiusens> zyga-ubuntu non deterministic
[12:02] <ogra_> zyga-ubuntu, definitely better than yours :)
[12:03] <sergiusens> zyga-ubuntu https://www.facebook.com/photo.php?fbid=10159702028205367&set=a.10154038137770367.1073741826.844960366&type=3&theater
[12:04] <sergiusens> it might rain, it might not; it might get cooler (like 18), it is 25 now, and it might also go up to 39
[12:04] <ogra_> what did you do to your knee ?
[12:04] <sergiusens> depends on if i decides to rain
[12:04] <sergiusens> ogra_  https://en.wikipedia.org/wiki/Chondromalacia_patellae
[12:05] <ogra_> ouch
[12:09] <Chipaca> sergiusens: nene, eso no se hace! :-(
[12:15] <mborzecki> hmm tarvis jobs mostly timing out today?
[12:18] <zyga-ubuntu> mborzecki: sad travis day
[12:18] <zyga-ubuntu> I'm working entirely locally
[12:21] <kalikiana> btw sergiusens I tried out the slot feature in the calendar. Can you see any difference on your end? I'm not sure if it handles regular appointments correctly. You should see at least one 'unavailable' slot tomorrow.
[12:25] <mup> PR snapd#4362 closed: interfaces: update fixme comments <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4362>
[12:28] <mup> PR snapd#4301 closed: interfaces: PlugInfo/SlotInfo/ConnectedPlug/ConnectedSlot attribute helpers <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4301>
[12:30] <mborzecki> #4354 needs a 2nd review
[12:30] <mup> PR #4354: tests/lib: introduce helpers for setting up /dev/random using /dev/urandom in project prepare <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4354>
[12:58] <mcphail> hi. does the automated github build service only build from the master branch, or do all branches get built?
[12:59] <zyga-ubuntu> mcphail: hey, do you mean on build.snapcraft.io?
[13:02] <mcphail> yes, zyga-ubuntu
[13:02] <kalikiana> lunch time
[13:04] <zyga-ubuntu> mcphail: ah, I don't know what's the state of that, sorry
[13:04] <mcphail> zyga-ubuntu: ok, thanks
[13:10] <sergiusens> ogra_ is there an amd64 Ubuntu Core image for download?
[13:10] <ogra_> sure
[13:10] <zyga-ubuntu> sergiusens: yes
[13:10] <ogra_> sergiusens, http://cdimage.ubuntu.com/ubuntu-core/16/
[13:10] <ogra_> pick your channel
[13:11] <zyga-ubuntu> sergiusens: http://paste.ubuntu.com/26125012/
[13:11] <sergiusens> kalikiana slots are interesting new concept in the calendar, but I think it is more of a thing for another person to click to get a slice of your time
[13:11] <ogra_> note that this is zero padded for better use with kvm though (unlike the other arches)
[13:11] <zyga-ubuntu> sergiusens: make boot; make login
[13:11] <sergiusens> kind of like a doctor's appointment thing
[13:12] <sergiusens> ogra_ zyga-ubuntu thanks, I won't be needing any of the automation, it is for a potential demo at the IoT meetup I am presenting at today
[13:13] <zyga-ubuntu> sergiusens: this is not much automation, just remembers the URL and the long command
[13:16] <zyga-ubuntu> mvo: btw, why are you using >100 hook numbers?
[13:18] <zyga-ubuntu> mvo: sad
[13:18] <zyga-ubuntu> zyga@kaedwen:~/snap-base-18$ grep -R bindresvport.blacklist .
[13:18] <zyga-ubuntu> Binary file ./prime/lib/x86_64-linux-gnu/libc-2.26.so matches
[13:18] <zyga-ubuntu> Binary file ./prime/lib/x86_64-linux-gnu/libc.so.6 matches
[13:26] <mvo> zyga-ubuntu: well, we can patch that
[13:26] <zyga-ubuntu> mvo: yes but I find it just sad
[13:26] <mvo> zyga-ubuntu: +100
[13:26] <zyga-ubuntu> mvo: /etc/letmecallthisfilethatIreallylikeanduseitfromlibc
[13:26] <sergiusens> zyga-ubuntu I just noticed it is a makefile, it does look useful!
[13:26] <zyga-ubuntu> :)
[13:27] <sergiusens> ogra_ zyga-ubuntu does stable have subiquitty and all that or should I go and get something like candidate or edge?
[13:28] <zyga-ubuntu> sergiusens: it has all that stsuff
[13:28] <zyga-ubuntu> *stuff
[13:28] <ogra_> all of them have subiquity
[13:31] <Chipaca> mvo: http://paste.ubuntu.com/26123959/ and http://paste.ubuntu.com/26123957/
[13:32] <zyga-ubuntu> mvo: https://github.com/snapcore/base-18/pull/5
[13:32] <mup> PR base-18#5: More etc cleanups and reporting <Created by zyga> <https://github.com/snapcore/base-18/pull/5>
[13:32] <zyga-ubuntu> ls
[13:33] <zyga-ubuntu> mvo: do we need to keep empty things for later bind mounts or can this be added at a later stage
[13:33] <zyga-ubuntu> mvo: I'd like to make it so that we know we're done with /etc cleanups
[13:33] <zyga-ubuntu> mvo: and that the rest is actually desired
[13:37] <mvo> zyga-ubuntu: lets kill the empty ones too
[13:37] <mvo> zyga-ubuntu: if we are successful there will be no bind mounts
[13:42] <zyga-ubuntu> mvo: I'll tweak things so that we can boot-test this
[13:42] <mup> PR snapd#4359 closed: interfaces/many: misc updates for default, browser-support, opengl, desktop, unity7, x11 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4359>
[13:43] <mup> PR snapd#4350 closed: debian: make "gnupg" a recommends <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4350>
[13:44] <mvo> zyga-ubuntu: sounds good, maybe its enough to make it "type: os" to be able to test install it
[13:44] <mvo> zyga-ubuntu: it will not properly run because it lacks snapd but its might be enough to get to the console
[13:44] <mvo> zyga-ubuntu: but probably some initrd hacking is required, hopefully not much
[13:44] <zyga-ubuntu> mvo: yes
[13:44] <zyga-ubuntu> mvo: fingers crossed
[13:44] <zyga-ubuntu> mvo: actually may be even easier
[13:49] <sergiusens> elopio already around?
[13:55] <zyga-ubuntu> mvo: some progress, getting over last initrd hurdle
[13:55] <kalikiana> sergiusens: Yeah, I might just go back to using regular events. It looked like slots would help with scheduling meetings, but it doesn't seem to be meant for that
[13:55]  * kalikiana back from lunch
[14:17] <cachio_> jdstrand, hey, the test security-device-cgroups-serial-port is failing in the pi2 and 3
[14:17] <cachio_> jdstrand, I am researching a bit to understand why
[14:19] <cachio_> jdstrand, hey, the test security-device-cgroups-serial-port is failing in the pi2 and 3
[14:19] <cachio_> jdstrand, https://paste.ubuntu.com/26125367/
[14:20] <cachio_> jdstrand, any idea what I can't get info from  /dev/ttyS4?
[14:27] <mup> PR core#66 opened: 500-create-xdg.binary: use "set -o pipefail"  <Created by mvo5> <https://github.com/snapcore/core/pull/66>
[14:30] <mup> PR snapd#4364 opened: interfaces: added Ref() helpers, restored more detailed error message on spi iface <Created by stolowski> <https://github.com/snapcore/snapd/pull/4364>
[14:31] <mborzecki> cachio_: maybe there is no device behind /dev/ttyS4, even though the node is there
[14:31] <pstolowski> zyga-ubuntu, ^ this is the other follow-up that addresses your comment from previous PR
[14:31] <zyga-ubuntu> pstolowski: thanks; looking
[14:32] <zyga-ubuntu> pstolowski: why not pass the slot directly?
[14:32] <zyga-ubuntu> pstolowski: not a big deal, just curiou
[14:32] <pstolowski> zyga-ubuntu, because the function is used for both SlotInfo and ConnectedSlot
[14:32] <zyga-ubuntu> ahh
[14:32] <zyga-ubuntu> ok
[14:32] <zyga-ubuntu> +1
[14:32] <pstolowski> thx
[14:37] <Chipaca> grmbl!
[14:38] <mborzecki> cachio_: there seem to be only 2 serial ports listed in rpi3 dts files, these should map to /dev/ttyS0 and S1 and udev should list those, 2 and above have no real devices so even if the node is there it won't work and udev will now know about it
[14:38] <mborzecki> s/now/not/
[14:38] <zyga-ubuntu> Chipaca: hmm?
[14:38]  * zyga-ubuntu moves an inch foward
[14:39] <Chipaca> zyga-ubuntu: I just lost the output of half an hour of debugging this because for some reason the fiddling around that spread does results in the thing not letting you ssh in
[14:39] <Chipaca> nor log in at all actually
[14:41] <zyga-ubuntu> Chipaca: is that locally or over linode?
[14:41] <Chipaca> locally
[14:41] <Chipaca> qemu
[14:41] <zyga-ubuntu> hmm
[14:41] <zyga-ubuntu> on core?
[14:42] <Chipaca> zyga-ubuntu: classic
[14:42] <zyga-ubuntu> and you don't have qemu console, do you?
[14:42] <Chipaca> zyga-ubuntu: yes i do
[14:42] <Chipaca> you can telnet to it
[14:42] <Chipaca> e.g. 2017-12-06 14:38:43 Serial and monitor for qemu:ubuntu-14.04-64 available at ports 59479 and 59579.
[14:43]  * mvo added those
[14:43] <Chipaca> (the serial has a getty, but that didn't let me log in once spread had started)
[14:43] <Chipaca> i need to ssh in before the 'preparing' phase is done
[14:43] <zyga-ubuntu> Chipaca: hmm
[14:44] <zyga-ubuntu> sorry :/
[14:44] <zyga-ubuntu> I was thinking about saving a snapshot
[14:45] <zyga-ubuntu> and extracting stuff from that image
[14:46] <Chipaca> zyga-ubuntu: tried that, but apparently snapshot_blkdev doesn't work well together with -snapshot
[14:46] <Chipaca> Could not open '/var/tmp/vl.MGVYHB': No such file or directory
[14:47] <zyga-ubuntu> Chipaca: you can save that snapshot
[14:47] <zyga-ubuntu> Chipaca: it is documented in the qemu manual somewhere
[14:47] <zyga-ubuntu> Chipaca: it talks about running qemu with -snapshot and then giving it a real name in the monitor
[14:48] <Chipaca> ah, buh
[14:48] <Chipaca> i'll try that if i get stuck like this again
[14:48] <cachio_> mborzecki, well the test is creating this device in case there is not one
[14:49] <cachio_> mborzecki, perhaps for the pi3 we shuould create it in a different way
[14:49] <mborzecki> cachio_: it's creating a node, that does not mean yet there's a device, and udev knows about devices only
[14:49] <mborzecki> can you try ttyS1 on rpi?
[14:49] <mvo> Chipaca: did you try to login via test:ubuntu?
[14:50] <Chipaca> mvo: ubuntu:ubuntu
[14:50] <cachio_> mborzecki, in my pi3 there is not a /dev/ttyS1
[14:51] <mvo> Chipaca: you said the getty wouldn't let you login after spread has started, iirc we change the setup and add test:ubuntu as a user. I was wondering if that might work to login in the getty
[14:51] <cachio_> I created a node for /dev/ttyS1
[14:51] <Chipaca> mvo: i'll try
[14:51] <cachio_> mborzecki,  and I have the same problem when I do "udevadm info --path=/dev/ttyS1"
[14:51] <cachio_> I get syspath not found
[14:52] <Chipaca> mvo: ubuntu:ubuntu logs in and is immediately logged out again
[14:52] <Chipaca> mvo: test:ubuntu gets login incorrect
[14:55] <mvo> Chipaca: :( ok
[14:56] <Chipaca> but thanks to zyga mentioning auditd, i now have logs that are different \o/
[14:56] <Chipaca> http://pastebin.ubuntu.com/26125591/
[14:56] <zyga-ubuntu> woot!
[14:56] <Chipaca> jdstrand: hiya. I have some rather messed up shenanigans going on in 14.04 that i'd like to understand if possible
[14:56] <cachio_> mborzecki, which pi do you have?
[14:56] <mborzecki> cachio_: you can try dumping udev db and checking if there's anything suitable
[14:57] <cachio_> mborzecki, sure
[14:57] <mborzecki> cachio_: i fried the last one i had :)
[14:58] <Chipaca> jdstrand: i now have an audit log :-) in both the "everything dies" case, and the less interesting "everything abstains from dying"; the difference is the existence of a file, and the thing that triggers the dying is doing ls on the directory that contains the file, as a user that shouldn't be able to list that directory
[14:58] <cachio_> mborzecki, https://paste.ubuntu.com/26125620/
[15:00] <mborzecki> cachio_: where can i find the dtb that you use?
[15:01] <cachio_> mborzecki, dtb?
[15:01] <mborzecki> cachio_: what image do you have installed there and can i get it somewhere?
[15:01] <cachio_> device tree?
[15:02] <cachio_> mborzecki, you need to build it
[15:02] <cachio_> mborzecki, download https://github.com/sergiocazzolato/validator
[15:03] <cachio_> and then you do "./create.sh beta pi3"
[15:03] <cachio_> it is gonna create the beta image
[15:04] <cachio_> if you have pi2, "./create.sh beta pi2"
[15:04] <cachio_> mborzecki, then you can use that image that is the same we use for beta validation
[15:06] <mborzecki> cachio_: it is pi2 or pi3 you're using now?
[15:11] <cachio_> pi3
[15:11] <cachio_> mborzecki, I am gonna lunch now, I'll be back
[15:12] <cachio_> mborzecki, export SPREAD_EXTERNAL_ADDRESS=<device ip>
[15:13] <cachio_> spread -v -debug external:ubuntu-core-16-arm-32:tests/main/security-device-cgroups-serial-port
[15:13] <cachio_> this is to reproduce the issue
[15:14] <mup> Issue snapcraft#1733 closed: Apply guidelines from design to error messages with commands that fix <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1733>
[15:14] <mup> PR snapcraft#1790 closed: cli: include consistent commands to fix error conditions <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1790>
[15:15] <mvo> zyga-ubuntu: review for https://github.com/snapcore/core/pull/66 would be great
[15:15] <mup> PR core#66: 500-create-xdg.binary: use "set -o pipefail"  <Created by mvo5> <https://github.com/snapcore/core/pull/66>
[15:16] <zyga-ubuntu> mvo: sure
[15:18] <zyga-ubuntu> done
[15:18] <zyga-ubuntu> also restarted tests
[15:20] <mvo> zyga-ubuntu: ta
[15:20] <jdstrand> cachio_: so, you are do a mknod, but that isn't sufficient to make the device show up to udev and be exposed in sysfs
[15:21] <ikey> jdstrand, sorry for not replying to your apparmor comments there the other day - just letting you know i saw em, cheers :]
[15:21] <jdstrand> cachio_: there is no hardware behind that device file, so the kernel didn't do a uevent for udev to do its thing
[15:21] <jdstrand> ikey: cool! I also mentioned it to jj, so if he didn't followup, feel free to ping him directly
[15:22] <ikey> aye :]
[15:22] <ikey> had a mild rebase to do today with 4.14.4 due to some audit.h changes
[15:22] <ikey> nothing too difficult tho
[15:22] <jdstrand> cachio_: and therefore nothing works
[15:23] <jdstrand> ikey: cool
[15:23] <mup> PR snapcraft#1796 opened: Changelog for release 2.37 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1796>
[15:25] <jdstrand> Chipaca: hey. I understood what you communicated, but don't feel like I have enough context to effectually respond
[15:26] <jdstrand> Chipaca: do you have a snap and instructions that demonstrates the issue?
[15:36] <zyga-ubuntu> mvo: what is going on here: https://travis-ci.org/snapcore/core/builds/312446771?utm_source=github_status
[15:37] <mborzecki> cachio_: iirc both 2 and 3 have 2 uarts, i tried to download the kernel you might use (4.4.0-1009-raspi2?), then dtb for rpi2 lists the 2nd uart as disabled, the one for rpi3 lists both uarts as ok, IMO it's best if you check dmesg and look in /sys/devices/platform to see if the devices are there
[15:37] <Chipaca> jdstrand: I haven't been able to reproduce it outside of a in-progress branch (it's up as a PR, but fails)
[15:37] <mvo> zyga-ubuntu: I don't know :/
[15:38] <zyga-ubuntu> what is /var/lib/snapd/environment?
[15:42] <Chipaca> zyga-ubuntu: a directory (?)
[15:43] <zyga-ubuntu> sure but what is it for?
[15:43] <Chipaca> zyga-ubuntu: I hope it's something we no longer use, as opposed to a random directory
[15:43] <Chipaca> i'm seeing it in the packaging but have no idea
[15:43] <zyga-ubuntu> yeah
[15:43] <zyga-ubuntu> I'm seeing it in booted images
[15:50] <mup> PR snapcraft#1797 opened: tests: update the snap name already registered for store tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1797>
[15:56] <mup> PR snapd#4365 opened: interfaces/mir: allow Wayland socket and non-root sockets <Created by gerboland> <https://github.com/snapcore/snapd/pull/4365>
[15:59] <cachio_> jdstrand, ok, so we should skeep the test execution in that case
[16:00] <cachio_> I mean, in case "udevadm info /dev/ttyS4" failes
[16:00] <cachio_> jdstrand, then we exit
[16:00] <cachio_> jdstrand, is it ok if I make that change?
[16:01] <geekgonecrazy> Hey guys, Is anyone aware of any issues with the node part? Have our rocketchat-server snap setup to build on launchpad, but keeps failing after downloading node part.  Only thing that has changed between last version and this the location we download our rocket.chat bundle - https://launchpadlibrarian.net/347779291/buildlog_snap_ubuntu_xenial_amd64_stable_BUILDING.txt.gz  Any ideas?
[16:04] <geekgonecrazy> Looks like its failing right as it finishes downloading the part
[16:04] <geekgonecrazy> ```
[16:05] <geekgonecrazy> Downloading ''   0%                                                             Traceback (most recent call last):   File "/usr/bin/snapcraft", line 9, in <module>
[16:06] <Chipaca> geekgonecrazy: the error is “IsADirectoryError: [Errno 21] Is a directory: '/build/stable/parts/rocketchat-server/src/'”
[16:07] <Chipaca> geekgonecrazy: looks like it expects a file but it's a directory
[16:07] <geekgonecrazy> Chipaca: yeah I see that, but seems to happen after the initial exception.
[16:07] <geekgonecrazy> Has something changed in snapcraft?  Here is my changeset between versions.  Why would this start now? https://git.launchpad.net/rocket.chat/commit/?h=stable&id=6682e7d79762d4cd1f0957845f35932fea563a92
[16:07] <Chipaca> geekgonecrazy: that's the last line of the initial exception, ie the bit that triggered it (the rest is the stack)
[16:08] <Chipaca> it goes up, not down
[16:08] <geekgonecrazy> i'm used to js stacks hehe.  My python experience is probably enough to be dangerous :D
[16:09] <Chipaca> if that's the diff between your thing not working and your thing working, i think you're right to suspect snapcraft itself
[16:10] <Chipaca> sergiusens, ^
[16:11] <geekgonecrazy> Chipaca: Yeah that's why I wondered if the part was messed up mainly because it stops right there. But if the workers are using newer versions of snapcraft that change could be the fault as well
[16:14] <mup> PR snapd#4366 opened: interfaces/removable-media: also allow 'k' (lock) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4366>
[16:19] <mup> PR snapd#4367 opened: interfaces/removable-media: also allow 'k' (lock) for 2.30 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4367>
[16:20] <geekgonecrazy> spinning up a clean VM, i'll see if I can hack past it locally.  We cut release a few days back and hadn't had time to debug it.  Hoped it was a launchpad issue that would resolve its self :P
[16:25] <kalikiana> kyrofa: would you be up for a hangout? to talk about the unmet dependencies
[16:25] <kyrofa> kalikiana, yep, perfect timing
[16:26] <jdstrand> cachio_: sounds reasonable to me
[16:26] <kyrofa> geekgonecrazy, to be clear, you only see that in LP? Not locally?
[16:26] <cachio_> jdstrand, ok, I'll create a PR for that
[16:26] <kyrofa> kalikiana, want to just use the weekly?
[16:26] <kalikiana> kyrofa: sure
[16:29] <geekgonecrazy> kyrofa: i'm double checking to see if that's the case now.  Gotten spoiled by launchpad and our ci just working.  :)
[16:36] <geekgonecrazy> kyrofa: ok I suppose good news is it happens locally. :)
[16:37] <mup> PR snapd#4368 opened: tests: fix security-device-cgroups-serial-port test for rpi and db <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4368>
[16:37] <geekgonecrazy> kyrofa: might it have something to do with there being a redirect involved in the file download?
[16:38] <zyga-ubuntu> woot
[16:43] <zyga-ubuntu> fafasafafsaj
[16:43] <zyga-ubuntu> my keyboard has gone crazy
[16:43] <zyga-ubuntu> mvo: we ccccccccccccc
[16:43] <zyga-ubuntu> anc now test ocre rsnaps
[16:43] <zyga-ubuntu> faak
[16:44]  * zyga-ubuntu reboots
[16:52] <mup> PR snapd#4369 opened: add write permission to optical-drive interface <Created by diddledan> <https://github.com/snapcore/snapd/pull/4369>
[16:52] <diddledan> aww, and here I was thinking someone wanted me :-p
[16:53] <zyga-ubuntu> diddledan: +1
[16:53] <diddledan> thankyou :-)
[16:53]  * diddledan feels clever now that I've looked at snapd code
[16:54] <kyrofa> geekgonecrazy, sorry, was in a meeting there for a few minutes
[16:55] <kyrofa> Yes, the fact that you get it locally is good indeed! Troubleshooting on LP is no fun :D
[16:55] <diddledan> and then I feel less clever now I spot I wrote BluRay differently each time I said it
[16:55] <zyga-ubuntu> mvo: I can now boot our base-18 snaps
[16:55] <zyga-ubuntu> mvo: it says "welcome to ubuntu core 18" :-)
[16:56] <kyrofa> geekgonecrazy, being due to a redirect seems odd
[16:56] <zyga-ubuntu> mvo: I think we need to drop a rule that gives us a getty on tty2
[16:56] <kyrofa> That would surprise me
[16:56] <zyga-ubuntu> mvo: anyway, let me clean this up and send a PR
[16:58] <kyrofa> geekgonecrazy, I suspect now that you're able to reproduce locally you'll be able to figure out the cause, but do let me know if you want some help
[17:00] <kalikiana> diddledan: clearly you need to open lots more snapd PRs and feel the love of snapd's attention :-D
[17:01] <diddledan> :-)
[17:01] <geekgonecrazy> kyrofa yup seems due to redirect.  :( wonder if it only follows certain redirects? I now have a very ugly looking prepare statement
[17:01] <kyrofa> geekgonecrazy, any chance you could share the URL?
[17:01] <geekgonecrazy> `prepare: curl -SLf "https://releases.rocket.chat/0.59.6/download/" -o rocket.chat.tgz; tar xvf rocket.chat.tgz --strip 1; cd programs/server; npm install; cd npm/node_modules/meteor/rocketchat_google-vision; npm install grpc` is what my prepare now looks like o.O
[17:02] <kyrofa> geekgonecrazy, also, I assume this is something that's changed recently?
[17:02] <kyrofa> Yikes
[17:02]  * kalikiana preparing to wrap up for the day
[17:02] <kyrofa> geekgonecrazy, so to be clear: you're saying using source: https://releases.rocket.chat/0.59.6/download is what breaks?
[17:03] <geekgonecrazy> kyrofa: we've had a redirect of some sort in place for a good while I think... i'll have to look back and verify
[17:03] <geekgonecrazy> kyrofa: yes fails fast and hard with that as source and source-type: tar
[17:04] <kyrofa> geekgonecrazy, huh. This works for me: http://paste.ubuntu.com/26126334/
[17:05] <kyrofa> Although I'm on snapcraft master. What are you using locally?
[17:08] <geekgonecrazy> kyrofa: snapcraft, version 2.35
[17:08] <cachio_> mvo, the snapd.refresh.timer does not exist on pi3, https://paste.ubuntu.com/26126388/
[17:08] <kyrofa> geekgonecrazy, and does that YAML I pasted break for you?
[17:08] <cachio_> it is making the test ubuntu-core-services fail
[17:11] <geekgonecrazy> kyrofa: it downloads, throws exception at the end i'm guessing because it doesn't know source type is a tar
[17:11] <geekgonecrazy> here is what our snapcraft yaml looked like before my hack around: https://git.launchpad.net/rocket.chat/tree/snapcraft.yaml?h=stable&id=945e4f912f0d5d9dc7416e2998f710da46f1755c
[17:11] <geekgonecrazy> might be related to the prepare there?
[17:12] <kyrofa> geekgonecrazy, huh, interesting. No exception for me. I'll try 2.35
[17:13] <kyrofa> geekgonecrazy, prepare effects the build step, not pull
[17:15] <kyrofa> I still get no issues with 2.35
[17:16] <geekgonecrazy> kyrofa: thats what I thought.  :D
[17:16] <zyga-ubuntu> mvo: https://github.com/snapcore/base-18/pull/8
[17:16] <mup> PR base-18#8: Add rudimentary testing infrastructure <Created by zyga> <https://github.com/snapcore/base-18/pull/8>
[17:17] <diddledan> zyga-ubuntu: base-18 sounds like weird counting to me.. base-16 works well with computers :-p
[17:17] <zyga-ubuntu> diddledan: wait till base-20
[17:17] <diddledan> :-o
[17:17] <geekgonecrazy> kyrofa: interesting.. Some how I get same error as launchpad and launchpad I assume is building in lxd for clean builds
[17:17] <diddledan> so with base-16 we count 0 thru F. what are we gonna do with base-20?!
[17:19] <Chipaca> diddledan: base-85 is a thing
[17:19] <Chipaca> jus' sayin'
[17:19] <diddledan> drak me
[17:19] <diddledan> frak*
[17:20] <diddledan> that's crazy numbers
[17:20] <Chipaca> diddledan: also called Ascii85, it's in python and go's stdlibs
[17:20] <diddledan> ee gads
[17:21] <diddledan> avoid it like the plague!
[17:21] <diddledan> I'm guessing it's used for crypto symbolism
[17:21] <diddledan> similarly to base64
[17:21] <Chipaca> diddledan: PDFs use it
[17:21] <Chipaca> diddledan: as does Postscript
[17:22] <diddledan> oh, well when Adobe are involved all bets are off :-p
[17:22] <Chipaca> diddledan: also ZeroMQ and ZMODEM
[17:23] <Chipaca> there's also an ascii85 representation of ipv6 addresses
[17:23] <Chipaca> (just, what, no)
[17:23] <diddledan> if 0mq uses it then I guess htey've ported it to many programming languages
[17:24] <zyga-ubuntu> so
[17:24] <Chipaca> when you see “4)+k&C#VzJ4br>0wv%Y” on your terminal your first thought is "oh crap something bought it", not "ah, good old 1080:0:0:0:8:800:200C:417A"
[17:24] <zyga-ubuntu> I need a hand
[17:24] <zyga-ubuntu> how do add a simple root shell systemd unit?
[17:24] <zyga-ubuntu> no login, just #
[17:24] <zyga-ubuntu> on tty2 ideally
[17:24] <Chipaca> zyga-ubuntu: don't you want the emergency shell?
[17:24] <zyga-ubuntu> Chipaca: I want _a_ shell
[17:24] <diddledan> zyga-ubuntu: get it to run getty?
[17:24] <zyga-ubuntu> whatever you do :)
[17:25] <Chipaca> zyga-ubuntu: that gives you a root shell on tty9 (iirc), from early boot
[17:25] <zyga-ubuntu> I need an answer in terms on systemd units
[17:25] <Chipaca> zyga-ubuntu: systemd.debug-shell=1 on the kernel commandline
[17:25] <zyga-ubuntu> ahh
[17:26] <zyga-ubuntu> perfect
[17:26] <Chipaca> zyga-ubuntu: or systemctl enable debug-shell.service if you'd rather that
[17:27] <zyga-ubuntu> now
[17:27] <zyga-ubuntu> how do I move ttys in qemu?
[17:27] <Chipaca> zyga-ubuntu: ctrl-alt-left or -right
[17:27] <Chipaca> is the easiest way imo
[17:27] <zyga-ubuntu> nope
[17:27] <zyga-ubuntu> doesn't work
[17:27] <zyga-ubuntu> do I need some fancy option for GUI?
[17:28] <zyga-ubuntu> Chipaca: I clicked on the qemu window
[17:28] <Chipaca> zyga-ubuntu: you're in the gui, yes?
[17:28] <zyga-ubuntu> (so that it woud catch my input)
[17:28] <zyga-ubuntu> then tried the combo
[17:28] <zyga-ubuntu> maybe it uses it to release
[17:28] <Chipaca> zyga-ubuntu: does it say your keyboard is captured?
[17:28] <zyga-ubuntu> the title changes
[17:28] <Chipaca> ah
[17:28] <zyga-ubuntu> says use alt-ctrl to escape
[17:28] <Chipaca> 1 sec
[17:28] <zyga-ubuntu> (ctrl-alt)
[17:29] <Chipaca> zyga-ubuntu: i had to bring a qemu up to remember
[17:29] <Chipaca> it's in muscle memory
[17:29] <Chipaca> zyga-ubuntu: just alt-left or -right
[17:29] <Chipaca> no ctrl
[17:29] <diddledan> if you do need to build one yourself, the exec= line would be `getty -n tty2`
[17:29] <zyga-ubuntu> Chipaca: no change
[17:29] <zyga-ubuntu> Chipaca: I don't get anything
[17:29] <Chipaca> zyga-ubuntu: lies
[17:29] <Chipaca> :-)
[17:29] <zyga-ubuntu> Chipaca: wanna see?
[17:30] <Chipaca> zyga-ubuntu: yes
[17:30] <zyga-ubuntu> I'll gladly hangout it
[17:30] <zyga-ubuntu> one sec
[17:31] <zyga-ubuntu> Chipaca: in standup
[17:31] <Chipaca> omw
[17:36] <Chipaca> reasons wayland is not "there" yet #(++n)
[17:37] <Chipaca> zyga-ubuntu: that's from https://freedesktop.org/wiki/Software/systemd/Debugging/#earlydebugshell FWIW
[17:38] <zyga-ubuntu> Chipaca: thanks
[17:38] <zyga-ubuntu> if anyone wonders what was wrong, wayland and qemu still don't work well
[17:38] <Chipaca> zyga-ubuntu: <Chipaca> reasons wayland is not "there" yet #(++n)
[17:39] <Chipaca> (from just before you logged back on)
[17:39] <Chipaca> n--
[17:39] <Chipaca> :-)
[17:40] <zyga-ubuntu> hehe
[17:45] <zyga-ubuntu> mvo: teaser https://twitter.com/zygoon/status/938464408610754562
[17:56] <sergiusens> geekgonecrazy are you behind a proxy? kyrofa I assume you are not
[17:56] <kyrofa> Indeed I am not
[17:56] <kyrofa> But LP is, of course
[17:58] <sergiusens> kyrofa yeah, that might be the commonality
[17:58] <kyrofa> Yeah interesting idea
[18:13] <zyga-ubuntu> kyrofa: when does a make plugin detect that it is out of date
[18:13] <zyga-ubuntu> kyrofa: I have a make-based project
[18:13] <zyga-ubuntu> kyrofa: I keep changing things and snapcraft thinks it's all up-to-date
[18:14] <kyrofa> zyga-ubuntu, only when something in the yaml changes
[18:14] <zyga-ubuntu> kyrofa: and then re-squahses stuff
[18:14] <zyga-ubuntu> kyrofa: why? you can ask make
[18:14] <zyga-ubuntu> kyrofa: you have all the part lifecycle stuff
[18:14] <zyga-ubuntu> kyrofa: make -n
[18:14] <zyga-ubuntu> or perhaps -q
[18:14] <zyga-ubuntu> (yes -q)
[18:14] <zyga-ubuntu> given that this is a network-heavy part I just keep wasting time because it's too silly to make again
[18:15] <kyrofa> zyga-ubuntu, a few different reasons. First of all, snapcraft doesn't build the source you hand it directly. During the pull step it copies it into the area it controls. So make doesn't see any changes
[18:15] <cachio_> pedronis, we have a test failing in rpi
[18:15] <cachio_> pedronis, it fails doing > snap ack "$TESTSLIB/assertions/testrootorg-store.account-key"
[18:16] <cachio_> error: cannot assert: assert failed: cannot find account (testrootorg)
[18:16] <pedronis> it's probably missing a skip
[18:16] <pedronis> we cannot run some tests if it's a real snapd
[18:16] <cachio_> any idea why it could fail just on rpi and dragonboards?
[18:16] <pedronis> (no test keys)
[18:16] <pedronis> it's telling you this a real snapd, not a test build one
[18:16] <sergiusens> kyrofa elopio I haven't seen any comment on https://github.com/snapcore/snapcraft/pull/1796
[18:16] <mup> PR snapcraft#1796: Changelog for release 2.37 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1796>
[18:16] <pedronis> s/real/prod/
[18:16] <kyrofa> zyga-ubuntu, also, while make supports discovering changes, not all build systems are as nice, as we haven't developed a generic method that works for all plugins
[18:17] <cachio_> pedronis, ah, ok
[18:17] <cachio_> what should I check to skip it?
[18:17] <kyrofa> zyga-ubuntu, that's not to say we don't want to get there, but it's a good chunk of work
[18:17] <pedronis> cachio_: well we have TRUST_TEST_KEYS or something like that?
[18:17] <pedronis> maybe you are not setting it properly?
[18:17] <kyrofa> Also, snapcraft is a packaging tool. It isn't best-suited to being so tightly in the development loop
[18:17] <pedronis> or the test doesn't have the check yet
[18:17] <cachio_> TRUST_TEST_KEYS are true
[18:18] <pedronis> cachio_: you cannot set it to true if you are using a prod snapd
[18:18] <pedronis> it doesn't have the keys
[18:18] <zyga-ubuntu> kyrofa: this makes sense, thank you for explaining
[18:18] <cachio_> pedronis, mmm, well something else is setting that var to true
[18:18] <cachio_> pedronis, I am not setting it
[18:19] <kyrofa> Of course
[18:19] <kyrofa> sergiusens, oh man, I missed it go up!
[18:19] <pedronis> cachio_: true is the default
[18:19] <pedronis> you need to set to false yourself
[18:19] <pedronis> if I understand
[18:19] <zyga-ubuntu> kyrofa: is there some way to ask snapcraft to use fast compression?
[18:19] <pedronis> SPREAD_TRUST_TEST_KEYS=false
[18:19] <zyga-ubuntu> kyrofa: especially for test snaps
[18:20] <zyga-ubuntu> kyrofa: that are not sent anywhere
[18:20] <cachio_> pedronis, ok, I'll take a look to that
[18:20] <kyrofa> zyga-ubuntu, honestly I'm not sure what that means :P
[18:20] <kyrofa> zyga-ubuntu, you mean for the squashfs image?
[18:20] <zyga-ubuntu> kyrofa: call mksquashfs without compression
[18:20] <cachio_> pedronis, in the spread.yaml it is using TRUST_TEST_KEYS: "false"
[18:20] <kyrofa> zyga-ubuntu, no, it's hard-coded to xz etc. to make the store happy
[18:21] <cachio_> but just for ubuntu-core-16-64 and ubuntu-core-16-32
[18:21] <kyrofa> zyga-ubuntu, but you could hack it pretty easily if you wan
[18:21] <cachio_> pedronis, in this case, for pi3 we use system: ubuntu-core-16-arm-32
[18:21] <pedronis> cachio_: ah
[18:21] <cachio_> pedronis, so, should I change it?
[18:21] <pedronis> they all need to be the same
[18:21] <kyrofa> zyga-ubuntu, snapcraft/internal/lifecycle/_packer.py for your reference
[18:21] <geekgonecrazy> sergiusens: nope not behind proxy (though I know launchpad is)
[18:22] <pedronis> cachio_: this is the external backends ?
[18:22] <zyga-ubuntu> kyrofa: thank you!
[18:22] <cachio_> pedronis, yes
[18:22] <cachio_> pedronis, external
[18:22] <pedronis> cachio_: yes, they all need the same config
[18:22] <pedronis> not sure why some have the false and some not
[18:22] <cachio_> pedronis, ok, makes sense
[18:22] <cachio_> thanks, I'll check that
[18:22] <pedronis> I wasn't really paying attention to that part of spread.yaml
[18:22] <geekgonecrazy> kyrofa: https://launchpadlibrarian.net/348314093/buildlog_snap_ubuntu_xenial_amd64_stable_BUILDING.txt.gz got one successful doing the curl in the prepare step.  o.O Not pretty but gets the release where I can push it out to the impatient users :D
[18:23] <cachio_> pedronis, I do :)
[18:23] <cachio_> pedronis, I use it a lot
[18:29] <kyrofa> Hey jdstrand, I'm playing with another joystick lib, and finding our joystick interface lacking a bit. I'd like to be able to access /dev/input/event* for the joystick... but it's entirely unclear to me how we can determine which events are tied to the joystick
[18:29] <kyrofa> jdstrand, https://pastebin.ubuntu.com/26126996/
[18:30] <kyrofa> jdstrand, note how js0 and event17 are pretty clearly provided by the same device
[18:30] <kyrofa> jdstrand, think that's possible?
[18:33] <jdstrand> kyrofa: can you paste 'udevadm info /dev/input/event17'?
[18:34] <kyrofa> jdstrand, here's both event17 as well as js0: https://pastebin.ubuntu.com/26127016/
[18:35] <kyrofa> I don't know much about this-- they both seem to be an interface to the same data. Is one just a newer/different API?
[18:36] <jdstrand> I think so, yes
[18:37] <jdstrand> kyrofa: so, I do think this is possible. what you would need to do is interrogate udev to map the thing you know (/dev/input/js0) to the thing you don't (/dev/input/event17) then add the device access for event17
[18:37] <kyrofa> Quick research leads me to believe js is old, event is newer
[18:37] <kyrofa> jdstrand, can we do things like that in an interface?
[18:37] <jdstrand> kyrofa: that is accurate
[18:38] <kyrofa> So far I've just been adding static ones
[18:38] <jdstrand> kyrofa: well, it is something I always hoped we could do for all sysfs entries. Ie, we assign js0 and then allow the precise sysfs entries for that device
[18:38] <jdstrand> kyrofa: this isn't that different
[18:39] <jdstrand> kyrofa: the problem is this is related to hotplug
[18:39] <kyrofa> Say no more...
[18:40] <kyrofa> jdstrand, would I be correct to assume that whitelisting /dev/input/event* in joystick is a bad idea?
[18:41] <jdstrand> kyrofa: so we could come up with a way to look at udev (or possibly more simply, various symlinks), but interfacec connections happen at specific points in time, but reboots, plug/unplug, etc would change the paths
[18:41] <jdstrand> kyrofa: oh gosh yes. that would grant anything that plugged the interface the ability to spy and spoof input events
[18:42] <jdstrand> *all* input events
[18:42] <kyrofa> Heh
[18:42] <kyrofa> Yeah and profile generation only happens at install/upgrade time, right?
[18:43] <jdstrand> connect/disconnect (obviously)
[18:43] <kyrofa> Right, that's more specific. And THAT is what causes them to happen at install/upgrade time I suppose
[18:43] <jdstrand> interestingly, also on reboot if the policy is different on disk from what snapd generates
[18:44] <kyrofa> Oh, hmm
[18:44] <jdstrand> I mention that last point cause you could get there crudely on reboot if snapd did its interrogating to come up with different policy
[18:44] <kyrofa> Exactly my thought
[18:44] <jdstrand> so js0 -> event17 might be js0 -> event16
[18:45] <jdstrand> snapd would detect that
[18:45] <jdstrand> but snapd would have to tie into the uevent kernel framework to get notifications on hotplug/unplug
[18:46] <kyrofa> Right, and then in order to get new devices into the profile, one would need to reboot, or disconnect/connect the interface
[18:46] <kyrofa> Meh
[18:47] <jdstrand> there is another way to deal with this: static file labels with apparmor. the idea is that you create a udev rule that statically labels the device based on the snap's label
[18:47] <jdstrand> but apparmor doesn't support that yet
[18:47] <jdstrand> (that incidentally would get rid of the need for device cgroups, which would be great)
[18:48] <jdstrand> kyrofa: exactly (hence the 'crudely' and why this is tied to hotplug)
[18:49] <jdstrand> all of this is doable, but as you know, hotplug is on the roadmap but not prioritized for the short term
[18:49] <kyrofa> Indeed. Okay, I'll hold off further investigation into this, and look for a python lib that uses the older interface. Very educational, thank you!
[18:49] <kyrofa> Indeed
[18:49] <jdstrand> np
[18:57] <mup> PR snapcraft#1796 closed: Changelog for release 2.37 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1796>
[18:57] <sergiusens> kyrofa elopio don't merge anything until further notice please
[18:57] <kyrofa> ack
[18:58] <elopio> ok
[19:14] <mup> PR snapd#4370 opened: tests: set TRUST_TEST_KEYS=false for all the external backends <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4370>
[19:51] <kyrofa> Hey cjwatson, I'm curious: why, if LP supports all these architectures in the builders, does build.snapcraft.io only support a few of them?
[19:59] <cjwatson> kyrofa: mainly because we want to have the facility to select specific architectures in snapcraft.yaml or similar (as we talked about at the rally, if you remember) before we enable more architectures by default that many developers won't care about without offering them a way to shut up the build failures
[20:00] <cjwatson> kyrofa: also, s390x needs to have the new scalingstack region finished off before we can offer it in BSI
[20:02] <mup> PR snapd#4364 closed: interfaces: added Ref() helpers, restored more detailed error message on spi iface <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4364>
[20:15] <kyrofa> Ah, makes sense thank you :)
[20:55] <sergiusens> cjwatson seems something hit kyrofa on the head, we were just discussing this on Monday ;-)
[20:55] <kyrofa> sergiusens, we didn't discuss that it was preventing more arch support in build.snapcraft.io
[20:56] <sergiusens> kyrofa oh, I am talking about the flashback to the rally conversation :-)


[07:13] <dholbach> good morning
[07:58] <Kilos> hi dholbach svij and everyone else
[07:58] <dholbach> hi Kilos
[09:01] <dholbach> dpm_, mhall119, popey: I mixed the schedule up somewhat, but I'm up for the Q&A today - who else is?
[09:02] <dpm_> dholbach, I was on last week with davidcalle, I'll let you guys arrange today's one
[09:04] <popey> dholbach: sure, I can do it with you
[09:04] <dholbach> excellent!
[09:04] <popey> want me to schedule it all?
[09:07] <dholbach> I can do it
[09:09] <popey> okay :)
[09:20] <dholbach> done :)
[14:21] <dholbach> popey, I'll do another round of telling everyone
[14:22] <popey> dholbach: ok, mhall119 usually does it just 15 mins before
[14:22] <dholbach> oh ok...
[14:22] <popey> dunno which is more successful
[14:23] <dholbach> happy to follow his lead...
[14:23] <popey> but people probably more likely to remember :)
[14:25] <dholbach> I'll do in 5 mins ;-)
[14:27] <popey> kk
[15:06] <dholbach> mhall119, is summit set up for UOS already?
[15:06] <dholbach> can people add sessions?
[15:11] <mhall119> dholbach: they can propose them, yes
[15:11] <mhall119> we need track leads before we add them to the schedule
[15:12] <dholbach> ok cool
[16:14] <dholbach> all right my friends - I call it a day - have a good one!
[17:58] <tsimonq2> popey: nice answer on my question ;)
[17:58] <tsimonq2> popey: (Community Team Q&A)
[17:59] <tsimonq2> and I totally called the speakers too :P
[17:59] <tsimonq2> I *knew* it would be popey and dholbach :P
[18:31] <popey> :)


[00:55] <mup> PR snapcraft#4448 closed: chore(deps): update dependencies <Created by lengau> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/4448>
[00:55] <mup> PR snapcraft#4457 closed: build(deps): bump cryptography from 41.0.4 to 41.0.6 <Dependencies> <Python> <Created by dependabot[bot]> <Closed by dependabot[bot]> <https://github.com/snapcore/snapcraft/pull/4457>
[10:41] <mup> PR snapcraft#4355 closed: Try to repro Flutter issue <Created by mraleph> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/4355>
[10:41] <mup> PR snapcraft#4460 closed: fix: push tags for remote-build <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/4460>
[11:57] <mup> PR snapd#13398 opened: boot/grub.go: return all possible boot chains <Run Nested -auto-> <Created by valentindavid> <https://github.com/snapcore/snapd/pull/13398>
[12:21] <mup> PR snapcraft#4461 opened: fix: improve lifecycle messages <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/4461>
[12:37] <mup> PR snapd#13351 closed: overlord/snapstate: support snaps on same lane in refreshedSnaps <Created by Meulengracht> <Merged by Meulengracht> <https://github.com/snapcore/snapd/pull/13351>
[12:42] <mup> PR snapd#13399 opened: t/m/snap-quota-memory: improve robustness of test on some distros <Simple 😃> <Test Robustness> <Created by Meulengracht> <https://github.com/snapcore/snapd/pull/13399>
[12:47] <pcrafford-adm> @sarah321
[13:41] <mup> PR snapcraft#4461 closed: fix: improve lifecycle messages <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/4461>
[16:36] <mup> PR snapcraft#4462 opened: build(deps): bump craft-providers to 1.20.1 <Created by mr-cal> <https://github.com/snapcore/snapcraft/pull/4462>
[17:03] <mup> PR snapd#13400 opened: snap,overlord: backend support to copy and mount components <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/13400>
[18:34] <mup> PR snapd#13395 closed: tests: add details to spread tests - part-3 <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/13395>
[21:02] <mup> Issue snapcraft#4463 opened: Enable craft-parts partitions feature <Enhancement> <Created by mr-cal> <https://github.com/snapcore/snapcraft/issues/4463>
[21:07] <mup> Issue snapcraft#4464 opened: Parse and validate component keywords in `snapcraft.yaml` <Enhancement> <Created by mr-cal> <https://github.com/snapcore/snapcraft/issues/4464>
[21:32] <mup> Issue snapcraft#4465 opened: Create partitions for components <Enhancement> <Created by mr-cal> <https://github.com/snapcore/snapcraft/issues/4465>
[21:37] <mup> Issue snapcraft#4466 opened: Generate metadata for components <Enhancement> <Created by mr-cal> <https://github.com/snapcore/snapcraft/issues/4466>
[21:42] <mup> Issue snapcraft#4467 opened: Package snap components <Enhancement> <Created by mr-cal> <https://github.com/snapcore/snapcraft/issues/4467>
[22:22] <mup> Issue snapcraft#4468 opened: feature/craft-application: migrate version command <Enhancement> <Created by mr-cal> <https://github.com/snapcore/snapcraft/issues/4468>
[22:22] <mup> Issue snapcraft#4469 opened: feature/craft-application: implement `get_build_plan()` <Enhancement> <Created by mr-cal> <https://github.com/snapcore/snapcraft/issues/4469>
[22:32] <mup> Issue snapcraft#4470 opened: feature/craft-application: implement Package service <Enhancement> <Created by mr-cal> <https://github.com/snapcore/snapcraft/issues/4470>


[20:28]  * genii-around sips and looks around
[20:29] <Unit193> You and your drinking... ;)
[20:29] <genii-around> True, true
[20:48] <genii-around> Which business cards you guys like to use?
[21:04]  * Tm_T huggles Unit193
[21:06]  * Unit193 doesn't know what to do at this point... hides
[21:10] <jussi> genii-around: which design?
[21:11] <genii-around> jussi: Yes, from https://wiki.ubuntu.com/BusinessCards
[21:12] <Tm_T> the one with most K in it
[21:12]  * Tm_T hides
[21:13] <jussi> none of them...
[21:14] <genii-around> Tm_T: Well, i did also look at https://wiki.ubuntu.com/BusinessCards?action=AttachFile&do=view&target=KubuntuBusCard.svg since I'm primarily a Kubuntu user
[21:15] <genii-around> But I think for general promoting, a regular one is probably better and more recognizable
[21:15] <Tm_T> I think I have done several attempts on trying to find anything I like from those or other readymade designs, every time ending up trying to do my own
[21:15] <Tm_T> genii-around: that one has old logo and all, not suitable anymore I'd say
[21:50] <genii-around> I guess power came back on