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