[00:38] <diddledan> gunix: yes
[06:37] <mborzecki> morning
[07:04] <gunix> hey diddledan
[07:04] <gunix> if somebody that can explain snapd to me is online, please ping me
[07:04] <gunix> i do not understand how this system works and it amazes me that stuff like LXD works on archlinux via snap
[07:19] <mborzecki> mvo: morning
[07:25] <mvo> good morning mborzecki
[07:26] <mup> PR snapd#4508 closed: New spread test for hardware-random-observe interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4508>
[07:37] <mvo> 4495 needs a second review
[07:41] <mup> PR snapd#4425 closed: config: add support for `snap set core proxy.no_proxy=...` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4425>
[07:44] <mvo> 4473 also needs a second review :)
[07:44] <mup> PR snapd#4476 closed: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4476>
[08:03] <kalikiana> good morning
[08:07] <pstolowski> hey o/
[08:08] <zyga-ubuntu> good morning :)
[08:09] <mvo> good morning kalikiana pstolowski and zyga-ubuntu !
[08:09] <mvo> happy monday!
[08:09] <koza> mvo, hey, what is the forecast on the strace support for snaps?
[08:09] <mvo> koza: if somone reviews my PR at least basic support will land for 2.31
[08:09] <mborzecki> zyga-ubuntu: pstolowski: kalikiana: morning guys
[08:10] <mvo> koza: we want support for custom options as well, there is a PR for that too
[08:10] <mborzecki> koza: hey
[08:10] <mvo> 4473 is the strace pr that needs a second review :)
[08:10] <mvo> koza: there is also your motd PR that we need to land for 2.31, right?
[08:10] <koza> mvo, but like days, weeks, months? :)
[08:11] <koza> mvo, would be nice, Thibaut commented vi email, Ill change the PR accordingly today
[08:11] <mvo> koza: 2.31 is scheduled for beta this week and stable in ~4 weeks
[08:11] <mvo> koza: ta
[08:11] <koza> mvo, nice!
[08:11] <mvo> koza: yeah, we are quite excited about strace too, its a popular feature
[08:14] <mborzecki> mvo: i'm looking at https://bugs.launchpad.net/snapd/+bug/1744433 so far got this: https://bugs.launchpad.net/snapd/+bug/1744433 this should make the message: 'error: cannot refresh "vlc": snap "vlc" has auto-refresh in progress'
[08:14] <mup> Bug #1744433: 'snap refresh' is silent about changes in progress <snapd:Triaged> <https://launchpad.net/bugs/1744433>
[08:14] <mvo> mborzecki: aha, you have a pr already?
[08:15] <mborzecki> mvo: no :) trying to figure out if there's a nicer way
[08:15] <mborzecki> mvo: i can open a pr with this change though
[08:16] <mvo> mborzecki: what is your current diff, could you pastebin this please?
[08:16] <mborzecki> mvo: https://paste.ubuntu.com/26435923/
[08:16] <mborzecki> sorry, paste the bug link twice in the previous message
[08:18] <mvo> mborzecki: no worries. will that help with the original issue? afaict mark did "snap refresh" and got "all snaps up-to-date" but in fact there were not, there were refreshing. so the message should be something like "vlc is refreshing" or similar. are we running a changeConflictError when a global refresh is running and a global refresh is requested again?
[08:19] <mborzecki> mvo: the error mesage on `snap refresh vlc` would be friendly, instad of changes you'd get 'auto-refresh' and so on
[08:20] <zyga-ubuntu> mvo: I think I should update 2.30 in opensuse today
[08:20] <mborzecki> the rest i have not figured out yet
[08:20] <zyga-ubuntu> mvo: and we have some bug reports on fedora front to inspect
[08:20] <mvo> mborzecki: aha, ok - yeah, making this friendlier is definitely nice
[08:20] <mvo> zyga-ubuntu: +1 for updates
[08:21] <mvo> zyga-ubuntu: where do the fedora bugs come from? their bugtracker?
[08:26] <zyga-ubuntu> mvo: yes, on bugzilla
[08:26] <mvo> zyga-ubuntu: ok, how bad do they look?
[08:26] <zyga-ubuntu> https://bugzilla.redhat.com/show_bug.cgi?id=1536895
[08:27] <mvo> uhh, ok
[08:27] <mvo> I wonder why we did not caught this in testing :(
[08:27] <zyga-ubuntu> yes, it's surprising to me as well
[08:35] <zyga-ubuntu> I'll be back soon, just getting some quick food
[08:35] <mborzecki> zyga-ubuntu: looks like something we fixed recently
[08:57] <mup> PR snapd#4513 closed: dirs: fix snap mount dir on Manjaro <Created by mati865> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4513>
[09:11] <mup> PR snapd#4514 opened: overlord/snapstate: record the 'kind' of conflicting change <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4514>
[09:14] <Chipaca> whoa, quickest reviewers in the west
[09:15] <mborzecki> Chipaca: morning
[09:16] <Chipaca> mborzecki: morning :-)
[09:20] <Chipaca> do we have a pedronis again this week, or is that next week?
[09:21] <mborzecki> Chipaca: i think he mentioned he'd be on vacation until 29th
[09:22] <Chipaca> mborzecki: I laud your detailed memory
[09:22] <mborzecki> haha, yeah, my wife would disagree :)
[09:22] <mvo> lol@ mborzecki
[09:23] <mvo> hey Chipaca good morning and happy monday!
[09:23] <Chipaca> mborzecki: she holds you to a higher standard :-D
[09:23] <Chipaca> mvo: good morning! monday's looking good indeed
[09:30] <zyga-ubuntu> Chipaca: hey
[09:30] <zyga-ubuntu> Chipaca: I added i386
[09:31] <zyga-ubuntu> Chipaca: I didn't do accounts yet but ping me if you want to play and I'll do that quickly
[09:31] <Chipaca> zyga-ubuntu: awesome. I don't think I need it right now, but very good to know.
[09:31] <zyga-ubuntu> and I will change the power adapter for the dragonboard so that it can be on 24/7
[09:31] <zyga-ubuntu> but that's in the evening as it's not a priority for anyone today
[09:38] <zyga-ubuntu> mborzecki: 4509 has another review
[09:38] <mborzecki> zyga-ubuntu: thanks
[09:38] <zyga-ubuntu> mvo: any news on bolt, ppc and other misery?
[09:41] <mvo> zyga-ubuntu: not yet, I was doing a 2.30 core image respin to exclude the microcode again this morning, I will focus on 2.31 next, part of this is bolt on ppc
[09:42] <mborzecki> wonder when the new 'working' microcode will be released
[09:43] <mvo> mborzecki: you are not alone here
[09:43] <mvo> mborzecki: btw, are you looking into the "snap refresh" output as well (if there is another refresh alreaady running)?
[09:44] <mborzecki> mvo: no, i've put is aside for now, i ended up going in circles
[09:45] <zyga-ubuntu> mborzecki: "working" or working?
[09:45] <mvo> mborzecki: ok, no worries, just wanted to check
[09:45] <mvo> mborzecki: I was considering looking but had no time for it yet :/
[09:46] <mborzecki> mvo: go ahead, i'm poking around https://bugs.launchpad.net/snappy/+bug/1741486 now
[09:46] <mup> Bug #1741486: failed snap try leaves snap symlink around <Snappy:New> <https://launchpad.net/bugs/1741486>
[09:47] <mvo> mborzecki: aha, nice! thats a good one too
[09:47] <mborzecki> btw. can we close https://bugs.launchpad.net/snappy/+bug/1743504 ? this was the unlucky fellow who basically had his filesystem bail out on him
[09:47] <mup> Bug #1743504: Ubuntu 16.04 snapd service not working <Snappy:New> <https://launchpad.net/bugs/1743504>
[09:51] <mvo> mborzecki: looking
[09:53] <mvo> mborzecki: I closed it now
[09:53] <mborzecki> mvo: great, thanks
[09:53] <mup> Bug #1743504 changed: Ubuntu 16.04 snapd service not working <Snappy:Invalid> <https://launchpad.net/bugs/1743504>
[09:53] <mvo> mborzecki: thank you! how are we actually doing with "New" bugs? how many are not confirmed/triaged currently?
[09:58] <Chipaca> (a) wooo, baby steps progress is now tangible
[09:58] <Chipaca> (b) /me -> physio
[09:59] <mvo> zyga-ubuntu: silly question, do we bundle on opensuse?
[10:00] <zyga-ubuntu> mvo: yes, we do
[10:00] <mvo> zyga-ubuntu: excellent
[10:00] <zyga-ubuntu> mvo: (it's legan now)
[10:00] <zyga-ubuntu> legal*
[10:01] <mvo> zyga-ubuntu: I fixed bolt on fedora by sed things back to boltdb/bolt
[10:01] <mvo> zyga-ubuntu: that means we just need to fix debian, I can make a patch, just need to find the upstream repo
[10:01] <mvo> zyga-ubuntu: eh, packaging repo
[10:03] <mvo> zyga-ubuntu: we really should import their packaging to make this simpler. anyway, found it and doing a patch
[10:10]  * Chipaca actually goes
[10:13]  * kalikiana moooore coffeeeee
[10:17] <jamesb192> zyga-ubuntu: working on a package for *ntoo and wondering what important stuff I am missing. manifest -> https://paste.pound-python.org/show/kHgFz1bglDwHLo89K5ZK/
[10:19] <zyga-ubuntu> jamesb192: looking
[10:19] <zyga-ubuntu> kalikiana: you are reading my mind!
[10:20] <zyga-ubuntu> jamesb192: snap-confine is usually in /usr/lib/snapd/snap-confine or /usr/libexec/snapd/snap-confine
[10:20] <zyga-ubuntu> jamesb192: same with a host of other binaries (only snap and snapctl are on path)
[10:20] <zyga-ubuntu> jamesb192: you can drop the following systemd units: autoimport, core-fixup
[10:20] <zyga-ubuntu> snap-repair
[10:20] <zyga-ubuntu> system-shutdown
[10:20] <zyga-ubuntu> and the corresponding timer
[10:21] <zyga-ubuntu> jamesb192: you can drop the snapd autoimport servic
[10:21] <zyga-ubuntu> er
[10:21] <zyga-ubuntu> this thing: -rw-r--r-- root/root       157 2018-01-20 08:53 ./lib/udev/rules.d/66-snapd-autoimport.rules
[10:21] <zyga-ubuntu> the udev rules
[10:21] <zyga-ubuntu> those things are all files relevant for core but irrelevant elsewhere
[10:21] <zyga-ubuntu> core == not classic systems
[10:21] <zyga-ubuntu> the /opt/snapd location is curious, what made you put all those files there/
[10:21] <kalikiana> zyga-ubuntu: you're welcome :-D
[10:22] <jamesb192> temporary holding area until I do something useful.
[10:23] <zyga-ubuntu> jamesb192:
[10:24] <zyga-ubuntu> ok, I think you will have some issues still but this looks like a good starting point, I may have missed something
[10:24] <zyga-ubuntu> I would suggest to look at debian/ubuntu/fedora packages and see if there are any files they ship that you do not
[10:24] <zyga-ubuntu> and always exclude the files I mentioned above
[10:24] <zyga-ubuntu> (they are at best no-ops on normal systems)
[10:24] <zyga-ubuntu> the end goal is to have a system that can be spread tested and that would pass our integration tests
[10:25] <zyga-ubuntu> but for now just iterate this way and run snaps on your system and see what breaks
[10:26] <jamesb192> Okay. I will do that. thank you.
[10:27] <zyga-ubuntu> jamesb192: please send update reports to the forum, I'm sure it will have wider exposure there
[10:27] <zyga-ubuntu> I can respond there as well
[10:33] <zyga-ubuntu> 4505 needs a 2nd review
[10:33] <zyga-ubuntu> ah
[10:33] <zyga-ubuntu> sorry
[10:33] <zyga-ubuntu> 4502*
[10:33] <zyga-ubuntu> not 5
[10:48] <zyga-ubuntu> mvo: 4505 updated per your comments
[10:52] <mup> PR snapd#4514 closed: overlord/snapstate: record the 'kind' of conflicting change <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4514>
[10:58] <mvo> zyga-ubuntu: ta, one quick comment added
[10:59] <zyga-ubuntu> sure
[11:00] <zyga-ubuntu> mvo: which code reads "it" (I assume group/user name)
[11:00] <zyga-ubuntu> mvo: the switch you linked to explicitly maps specific values
[11:01] <mvo> zyga-ubuntu: let me double check, maybe github is playing tricks on me
[11:01] <zyga-ubuntu> mvo: the code in snap-update-ns did do name lookups AFAIR but I'm not sure it has to still
[11:01] <zyga-ubuntu> mvo: and that code is more generic as it applies to other mechanisms
[11:01] <zyga-ubuntu> mvo: this one only does layout language
[11:02] <mvo> zyga-ubuntu: aha, you are right, I was misreading the code
[11:02] <mvo> zyga-ubuntu: sorry
[11:02] <zyga-ubuntu> mvo: no worries, I wanted to check if I missed something :) thank you for askin!
[11:46] <zyga-ubuntu> joc: gentle ping about #4326
[11:46] <mup> PR #4326: interfaces/builtin: blacklist zigbee dongle <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/4326>
[11:47] <zyga-ubuntu> I think you know more about that than we do
[11:50] <zyga-ubuntu> mborzecki: what's the status of 4285?
[11:51] <mborzecki> zyga-ubuntu: i've put it on hold now, most of the tests were passing though, iirc the were maybe 1-2 left, one of those was /media directory
[11:55] <zyga-ubuntu> mborzecki: does it make sense to unconflict and merge this
[11:56] <zyga-ubuntu> opensuse 42.2 will be EOLed this week
[11:56] <zyga-ubuntu> we should switch to 42.3
[11:59] <mborzecki> zyga-ubuntu: i'll merge master and push it for a travis run and we'll see how much has changed
[12:01]  * kalikiana taking a break
[12:18] <gunix> hey guys
[12:18] <gunix> do snaps run in containers?
[12:18] <zyga-ubuntu> gunix: hey
[12:18] <zyga-ubuntu> gunix: it depends
[12:18] <zyga-ubuntu> gunix: snaps are known to run (with some known issues) on recent versions of lxd when running on top of ubuntu
[12:19] <gunix> zyga-ubuntu: i just tried LXD on archlinux ... install via AUR is not working, but install via snapd is working. and this confuses me
[12:19] <gunix> zyga-ubuntu: and that made me ask my self how snapd is actually working
[12:21] <zyga-ubuntu> gunix: I think mborzecki will be the best to know this (he runs arch)
[12:21] <zyga-ubuntu> gunix: I can happily respond to detains about what we need from the system and how containers may break things
[12:22] <gunix> zyga-ubuntu: i am curious how snap is running system-agnostic apps
[12:22] <gunix> i don't understand how that is possible
[12:22] <gunix> for example, LXD needs to create a network bridge, so it needs to create specific files on the system
[12:22] <gunix> files which normally are not distro-agnostic
[12:22] <gunix> but still, it seems to work
[12:23] <gunix> i am can't understand how this is possible and i didn't find documentation about this online
[12:24] <zyga-ubuntu> mvo: 4399 needs a review, it's very nice and could be a 2.31 item
[12:24] <zyga-ubuntu> gunix: I cannot comment about LXD
[12:24] <zyga-ubuntu> gunix: perhaps stgraber can answer that
[12:26] <mborzecki> gunix: does the network work inside the containers?
[12:27] <gunix> mborzecki: yes, that's the confusing part. if you install LXC from the archlinux repos, you still have to configure networking
[12:27] <gunix> mborzecki: if you install LXD from aur, you can't create containers because it can't map the IDs
[12:28] <gunix> mborzecki: however, if you install LXD from snap (and snap gets installed from aur), you just do lxd init and everything works after that
[12:28] <gunix> this really looks like dark magic
[12:30] <gunix> oh and by default on archlinux you need to change a flag on the kernel if you want normal users to create NEWNS with clone (a.k.a. containers) ... and with the snap version of LXD, you just add the user to the lxd group and it works.
[12:31] <gunix> i guess you normally get people that ask why it doesn't work. not people who ask why it works. :D
[12:38] <zyga-ubuntu> mborzecki: can you please look at 4326
[12:38] <mborzecki> gunix: the USERNS thing is already fix in arch kernel
[12:39] <mborzecki> zyga-ubuntu: uhh vendor reused vid/pid
[12:39] <zyga-ubuntu> ...
[12:39] <zyga-ubuntu> yeah
[12:40] <mborzecki> and here i thought i'd never have to see such things again
[12:40] <zyga-ubuntu> serial ports, no vid/pid, mess, usb, reuse vid/pid becaue saves 0.01$
[12:40] <zyga-ubuntu> mess
[12:40] <mborzecki> ehehe, wonder how many devices are there with default ftdi vid/pid ;P
[12:41] <zyga-ubuntu> mvo: 4140 needs someone to decide
[12:44] <kalikiana> gunix: id mapping works differently because the snap sees the core's filesystem rather than the host's
[12:47] <gunix> mborzecki: are you sure? because i just installed an arch linux and you need to add the flag or install another kernel, in order to create containers when not root
[12:48] <mborzecki> gunix: which option? CONFIG_USER_NS?
[12:48] <gunix> mborzecki: https://wiki.archlinux.org/index.php/Linux_Containers
[12:49] <gunix> Enable support to run unprivileged containers (optional)
[12:49] <gunix> i don't know which of them because i didn't get it to work yet, i will go through all steps later today
[12:50] <mborzecki> gunix: yeah, just the kernel package + sysctl should work, iirc there was some discussion in the original bug report and the maintainer dopted patches from ubuntu or fedora
[12:51] <kalikiana> gunix: note that the lxd snap always runs as root
[12:51] <kalikiana> not as the lxd user
[12:54] <zyga-ubuntu> mvo: can you please look at https://github.com/snapcore/snapd/pull/3963 (aka oldest PR)
[12:54] <mup> PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
[12:54] <gunix> kalikiana: it still has to fix the user mapping problem
[12:54] <gunix> *the id mapping
[12:54] <kalikiana> gunix: did you read my previous message?
[12:55] <gunix> sorry, got only the one that it runs on root. reading now
[12:55] <kalikiana> no worries :-)
[12:56] <gunix> kalikiana: which are the core/host filesystems?
[12:56] <kalikiana> gunix: from the point of view of a snap, / comes from the core snap
[12:57] <kalikiana> not the actual / you'd expect
[12:57] <gunix> kalikiana: so all packages get installed in its chroot?
[12:58] <kalikiana> gunix: have a peek at /snap/core/current/ - nothing's installed there, but folders are mounted into place where things should be writable or you want to see the real contents
[12:59] <gunix> ok. thank you ... and in the users homefolder are only settings regarding the apps? because he also gets a .snap folder
[13:00] <niemeyer> OMW to the standup..
[13:01] <zyga-ubuntu> hey niemeyer
[13:01] <kalikiana> gunix: those are files created by the snap, yes. home isn't accessible (unless you're using the "home" interface, and only non-hidden files even then)
[13:02] <gunix> you mean everything outside of /home/gunix/snap is not accessible by the application running as a snap?
[13:02] <gunix> kalikiana: ^
[13:07] <kalikiana> gunix: yeah. a strict snap couldn't read, say, /home/gunix/mydocument.txt by default
[13:07] <gunix> kalikiana: than why was i able to change the settings of chromium to save in /home/gunix/Downloads instead of /home/gunix/snap/chromium/current/downloads ?
[13:08] <kalikiana> gunix: Have a look at `snap interfaces chromium`. You'll notice it has ":home" in the list
[13:09] <zyga-ubuntu> gunix: also try "snap interface home"
[13:09] <gunix> kalikiana: i have to install snap again for that, can you please paste that to bpaste? i will install snap later today, if you don't have time, so it's no rush
[13:11] <kalikiana> gunix: :home                    ag-mcphail,chromium,corebird,dekko,gedit,gimp,handbrake-jz,libreoffice,magic-device-tool,midori,nethack,rg,spotify,telegram-sergiusens,vlc
[13:12] <gunix> kalikiana: so chromium wants to use libreoffice and vlc?
[13:14] <kalikiana> gunix: Chromium uses the "home" slot, which the listed snaps plug into. Or to put it more simply, "Chromium uses the home interfaces, and all those other snaps do, too"
[13:14] <gunix> kalikiana: oh, so that's a list of the snaps that use the home slot, and you installed all the snaps in the above list, right?
[13:15] <kalikiana> gunix: Yes. This wouldn't show snaps that aren't installed.
[13:15] <gunix> kalikiana: do snaps run as containers? because i don't understand how gnome3 GUI apps would run in a container
[13:16] <zyga-ubuntu> gunix: no
[13:16] <zyga-ubuntu> gunix: and maybe
[13:16] <gunix> zyga-ubuntu: please explain :D
[13:16] <zyga-ubuntu> gunix: have a look at this https://new.zygoon.pl/post/poking-holes-in-cheese/
[13:17] <gunix> zyga-ubuntu: haha "a look"
[13:17] <gunix> i will read it today or tomorrow
[13:18] <gunix> i also need to start working on a tripleo deployment since that is for my job, but i am too curious how snap works and i keep testing it instead of doing what i should
[13:19] <gunix> i always get this when i try archlinux. "yea i will just install arch on my desktop really quick and create some redhat VMs and continue my work" ... 5 days later: "ok so what if i install arch on the logical volume instead of the partition, so that i snapshot it before upgrades? hmm gotta try that"
[13:23] <jdstrand> greyback: oh right, forgot about that. in that snap, just do: something like:
[13:23] <jdstrand> name: foo
[13:23] <jdstrand> slots:
[13:24] <zyga-ubuntu> jdstrand: good morning!
[13:24] <jdstrand>   x11-service:
[13:24] <jdstrand>     interface: x11
[13:24] <greyback> jdstrand: already figured out, with zyga's help
[13:24] <jdstrand> apps:
[13:24] <jdstrand>   ...
[13:24] <jdstrand> ok, cool
[13:24] <jdstrand> hey zyga-ubuntu :)
[13:24] <jdstrand> cachio: reading 'man capabilities', it makes sense to add that cap to the policy
[13:25] <greyback> jdstrand: and it is working ok. Am trying to tighten up the interfaces and figure out /dev/shm usage
[13:25] <jdstrand> cachio: feel free to send up a PR and ping me for review
[13:25]  * kalikiana going to go for lunch in a bit
[13:25] <jdstrand> greyback: awesome! sorry again for the slow response. I'm no longer sprinting
[13:25] <greyback> jdstrand: no worries at all
[13:25]  * greyback thinks he sees the finishing line at long last
[13:35]  * kalikiana read that as "fishing line" and wondered if that was sarcasm
[14:03]  * pstolowski lunch
[14:06] <cachio> jdstrand, ok, I'll try that, thanks
[14:21] <diddledan> zyga-ubuntu: I think you're misunderstanding gunix's question regarding "do snaps run inside containers?". I think gunix means something along the lines of not "if I create a container can I run a snap inside it?" and more "when I run a snap on my system, is it being executed inside a container to isolate it?"
[14:23] <seb128> mvo, is bug #1744584 might be worth commenting on if you have any recommendation of what snaps folder need backuping or not?
[14:23] <mup> Bug #1744584: Exclude Snap .cache from Dejadup backups <Déjà Dup:Triaged> <Snappy:New> <deja-dup (Ubuntu):Triaged> <https://launchpad.net/bugs/1744584>
[14:23] <zyga-ubuntu> diddledan: ah, perhaps
[14:23] <zyga-ubuntu> gunix: ^
[14:23] <zyga-ubuntu> gunix: which question was it?
[14:25] <gunix> when I run a snap on my system, is it being executed inside a container to isolate it?
[14:25] <gunix> diddledan: zyga-ubuntu ^
[14:25] <mvo> seb128: thanks, looking
[14:25] <seb128> mvo, thanks :)
[14:25] <zyga-ubuntu> gunix: aha, I see
[14:26] <zyga-ubuntu> gunix: so my answer stands, it depends on how you understand containers; I'm inclined to say "no" more than yes
[14:26] <zyga-ubuntu> gunix: because most of the security confinement comes from LSM (apparmor)
[14:26] <zyga-ubuntu> gunix: though we also use some of the technology used by what people agree are containers
[14:26] <gunix> zyga-ubuntu: can't be. i am running archlinux
[14:26] <zyga-ubuntu> gunix: hence the fuzzy answer
[14:27] <zyga-ubuntu> gunix: right, we use a combination of things
[14:27] <diddledan> there is a teeny bit of container-tech used, such as mount-namespaces
[14:27] <zyga-ubuntu> gunix: and container is a marketing term more than a technical term today
[14:27] <zyga-ubuntu> gunix: but also spiritually, we try to integrate the app with the host
[14:27] <zyga-ubuntu> gunix: more than any other "containers" do
[14:27]  * diddledan meditates
[14:27] <gunix> zyga-ubuntu: with container, i mean NEWNS flag within the clone() function.
[14:27] <diddledan> I'm spiritual
[14:28] <gunix> zyga-ubuntu: was that a marketing explanation too? :D
[14:28] <zyga-ubuntu> gunix: yes, we do that
[14:28] <zyga-ubuntu> (ish)
[14:28] <zyga-ubuntu> gunix: that's the only thing that we do that is clearly a container tech
[14:28]  * zyga-ubuntu gets more tea
[14:29] <gunix> zyga-ubuntu: is that default for all snaps?
[14:31] <Chipaca> getting more tea _should_ be the default for all apps
[14:31]  * Chipaca gets more tea too
[14:31] <diddledan> I'm more a cola addict :-p
[14:31] <diddledan> pepsi max ftw (no sugar)
[14:31] <zyga-ubuntu> gunix: yes, all snaps use that by default; the only exception are snaps that you install with --classic
[14:32] <zyga-ubuntu> gunix: those are, like classic packages, installed directly on your system
[14:36] <kalikiana> re
[14:38] <zyga-ubuntu> mvo: 4507 is green and has two +1s
[14:47] <cachio> jdstrand, you mean net_admin capability?
[14:49] <cachio> jdstrand, https://paste.ubuntu.com/26437642/
[14:50] <cachio> I am using this, I already modified the capability
[14:56] <Chipaca> am I missing a trick, or is it not possible to stream a file into a tar with archive/tar?
[14:57] <Chipaca> (the key being I don't know the size of the file beforehand)
[14:57] <diddledan> Chipaca: you should be able to do something equivalent to `cat file | tar cf mytarfile.tar`
[14:58] <diddledan> unless you're talking about golang in which case I've done that before on an unrelated project
[14:58] <Chipaca> diddledan: golang yes
[14:59]  * Chipaca asks the same question over in #go-nuts because he feels it's nuts that he can't :-)
[14:59] <elopio> Good morning!
[15:00] <diddledan> my code is a mess, but you can see I stream a file from sftp into a tar here: https://github.com/bowlhat/sftp-client/blob/master/backup.go
[15:00] <mborzecki> Chipaca: iirc you need to know the size upfront so that when parsing t you can skip that much + any padding
[15:05] <mup> PR snapd#4507 closed: advisor: use forked bolt to make it work on ppc <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4507>
[15:05] <cachio> jdstrand, this is the interface that I am using when I see that error, https://github.com/sergiocazzolato/snapd/blob/tests-interface-netlink-audit/interfaces/builtin/netlink_audit.go
[15:06] <cachio> jdstrand, do you think it needs any other change?
[15:10] <mup> PR snapd#4495 closed: data/dbus: add AssumedAppArmorLabel=unconfined <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4495>
[15:24] <gunix> I added snap as an installation method for LXD on the archlinux wiki: https://wiki.archlinux.org/index.php/LXD
[15:25] <zyga-ubuntu> mvo: can I close core#67 now?
[15:25] <mup> PR core#67: initramfs-tools: revert the symlinks generation to unbreak snapcrafts kernel plugin <Created by mvo5> <https://github.com/snapcore/core/pull/67>
[15:25] <gunix> since snap works flawlessly, it deserves this
[15:25] <zyga-ubuntu> gunix: thank you~!
[15:25] <mvo> zyga-ubuntu: so to fix the mount unit ordering issue, what kind of test do we need?
[15:25] <mvo> zyga-ubuntu: is a reboot inside the lxd container the rightonw?
[15:25] <mvo> right one?
[15:25] <zyga-ubuntu> mvo: I think I had a branch with a test
[15:25] <mup> PR core#67 closed: initramfs-tools: revert the symlinks generation to unbreak snapcrafts kernel plugin <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core/pull/67>
[15:26] <zyga-ubuntu> mvo: just remove a snap :)
[15:26] <mvo> zyga-ubuntu: inside lxd? ok
[15:26] <zyga-ubuntu> mvo: yes
[15:26] <zyga-ubuntu> mvo: is core#69 something that can be closed now?
[15:26] <mup> PR core#69: hooks: add 28-command-not-found.chroot to create c-n-f handler <Created by mvo5> <https://github.com/snapcore/core/pull/69>
[15:27] <mvo> zyga-ubuntu: yes, good point
[15:27] <jdstrand> cachio: your paste from before was for audit_read: https://paste.ubuntu.com/26412541/
[15:27] <mup> PR core#69 closed: hooks: add 28-command-not-found.chroot to create c-n-f handler <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core/pull/69>
[15:28] <zyga-ubuntu> thank you!
[15:29] <cachio> jdstrand, let me create a PR with the test so you can see what I am doing
[15:29] <kalikiana> gunix: niiiice :-D
[15:30] <cachio> jdstrand, #4515
[15:30] <mup> PR #4515: tests: new spread test for netlink-audit interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4515>
[15:30] <jdstrand> cachio: man 7 netlink only says that net_admin is needed for multicasting. that doesn't mean it is accurate, but your paste from last week says audit_read and 'man capabilities' says 'Allow reading the audit log via a multicast netlink socket'
[15:30] <mup> PR snapd#4515 opened: tests: new spread test for netlink-audit interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4515>
[15:31] <jdstrand> cachio: since net_admin is needed for setting up a multicast socket, you probably will need both
[15:31] <mborzecki> Chipaca: have you found a way to deal with the tar issue?
[15:31] <Chipaca> mborzecki: "use archive/zip instead"
[15:31] <mborzecki> radical
[15:31] <Chipaca> this is exactly the sort of silly issue i wanted to root out by this approach to it all, so \o/
[15:32] <mborzecki> Chipaca: glad that it works with zip :)
[15:32] <Chipaca> mborzecki: we'll see :-)
[15:32] <Chipaca> i like your optimism though
[15:33] <jdstrand> cachio: reading that PR it isn't clear that NETLINK_AUDIT is a multicast socket
[15:34] <mborzecki> Chipaca: hmm looking at https://golang.org/src/archive/zip/writer.go#L224 looks like zip writes the header upfront too
[15:34] <cachio> jdstrand, what do you suggest to fix it?
[15:36] <Chipaca> mborzecki: but AFAICT it doesn't require the size at that point
[15:37] <Chipaca> mborzecki: note how close() updates the header
[15:37] <mborzecki> Chipaca: yeah, it seems to update the count on the flly (next to crc32)
[15:38] <mvo> zyga-ubuntu: any idea about https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1744738 ? i.e. inside lxd it seems like apparmor is not confined anymore
[15:38] <mup> Bug #1744738: snapd <IP_ADDRESS> ADT test tests/main/lxd failure with linux-hwe 4.13.0-30.33~16.04.1 <snapd (Ubuntu):New> <https://launchpad.net/bugs/1744738>
[15:38] <mvo> zyga-ubuntu: also slightly sad, but I only get 20kb for the lxd test so my ordering fix can take forever to verify
[15:39] <zyga-ubuntu> mvo: looking
[15:39] <mborzecki> Chipaca: so there's a fileWriter https://golang.org/src/archive/zip/writer.go#L317 and a countWriter https://golang.org/src/archive/zip/writer.go#L384 oh my
[15:39] <zyga-ubuntu> hmm
[15:40] <jdstrand> cachio: I think that the capabilities man page implies it is multicast. I commented in the pr
[15:41] <jdstrand> mvo, zyga-ubuntu: I may have an idea on that
[15:41] <mborzecki> Chipaca: we had a running joke at my previous company that all problems are solved by adding another reader/writer, in that case we had a file upload through POST which was repacking the data, checksumming, encrypting and uploading to s3 from one of the intermediate steps :P
[15:41] <mvo> jdstrand: oh, tell us more please
[15:42] <cachio> jdstrand, great, thanks
[15:42] <jdstrand> mvo: I haven't read that bug very closely, but serguisens reported an issue to me
[15:42] <zyga-ubuntu> mvo: can you please cherry pick the unit test from #4258
[15:42] <mup> PR #4258: cmd/snap-confine,tests: fix unmounting on systems without rshared / <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4258>
[15:42] <zyga-ubuntu> mvo: as for the lxd issue you just linked to
[15:42] <jdstrand> mvo: on kernels that have partial apparmor support, the apparmor policy is set to the classic template
[15:42] <zyga-ubuntu> mvo: not sure yet
[15:43] <Chipaca> mborzecki: I may or may not have a io.TeeReader of a io.TeeReader of a member of an archive and a hasher, and a sizer
[15:43] <zyga-ubuntu> jdstrand: ah, nice catch!
[15:43] <jdstrand> mvo: this gives a glob rule like /** pix,
[15:43] <Chipaca> mborzecki: 	dec := json.NewDecoder(io.TeeReader(metaReader, io.MultiWriter(metaHashChecker, &sz)))
[15:43] <Chipaca> mborzecki: also that ^
[15:43] <jdstrand> mvo: whereas the lxd-support template has /usr/sbin/aa-exec ux, (or similar)
[15:44] <mborzecki> Chipaca: hahah
[15:44] <jdstrand> mvo: 'ix' ends up scrubbing the environment (it shouldn't, that is an apparmor bug related to limitations in the current implementation)
[15:44] <jdstrand> mvo: and 'ux' doesn't
[15:44] <niemeyer> Newly allocated one machine roundtrips a dummy run in almost exactly one minute
[15:44] <niemeyer> on spread+Linode, that is
[15:45] <niemeyer> Surprisingly good
[15:45] <mvo> jdstrand: hm, why do we start to see this now?
[15:45] <mvo> jdstrand: thanks for explaining that :)
[15:45] <mvo> jdstrand: I wonder a) why now b) what can we do about it :)
[15:45] <niemeyer> That includes allocation of the brand new instance, image creation, trivial task run, and machine removal
[15:45] <jdstrand> mvo: what I've seen is that on those kernels the 'lxd init' command can't find the required libraries because LD_LIBRARY_PATH is cleared
[15:47] <jdstrand> mvo: I have a todo to file both an apparmor bug and a snapd bug. I'm evaluating how to fix this in snapd. this came up at the sprint so I couldn't chase it down further. was going to look at it after the layouts reviews
[15:48] <mvo> jdstrand: great, thank you! can I paste this into the open bug?
[15:48] <jdstrand> mvo: now, like I said, I haven't looked at the aforementioned bug closely, but I wonder if something with the partial support is affecting this? it *shouldn't* if I understand that bug after looking at it a little-- seems this should all be happening on a xenial kernel with full apparmor support
[15:49] <jdstrand> mvo: well, no, I'm only wondering if that bug is involved
[15:49] <mvo> jdstrand: aha, ok, sorry I misunderstood
[15:49] <mvo> jdstrand: yes, this is all full confinement
[15:49] <jdstrand> + lxd init --auto
[15:49] <jdstrand> LXD has been successfully configured.
[15:49] <jdstrand> that suggests that it isn't it...
[15:50] <jdstrand> so, sorry for the noise, but fyi there is a problem with lxd snap and partial apparmor support :)
[15:51] <mvo> jdstrand: heh, no worries and thanks, good (or bad) to know about this problem
[15:55] <jdstrand> mvo, zyga-ubuntu: with that bug, it seems that the container doesn't have the snap-confine loaded or snap-confine is not detecting that it is loaded correctly
[15:57] <mvo> jdstrand: the only change we did for <IP_ADDRESS> was http://launchpadlibrarian.net/347640641/snapd_<IP_ADDRESS>_<IP_ADDRESS>.diff.gz
[15:59] <zyga-ubuntu> mvo: it feels like something else has changed under us
[15:59] <jdstrand> mvo: it is a <IP_ADDRESS> to <IP_ADDRESS> regression? the bug talks about 2.28.5
[15:59] <mvo> jdstrand: indeed, 2.28.5 -> <IP_ADDRESS>
[16:00] <mvo> zyga-ubuntu: same here
[16:00] <jdstrand> it could be that the kernel changed or lxd. someone should try to reproduce manually and run snap-confine in debug mode
[16:00] <jdstrand> mvo: (the diff you gave was <IP_ADDRESS> to <IP_ADDRESS>)
[16:01] <mvo> hm, <IP_ADDRESS> is fine with lxd for linux-meta/<IP_ADDRESS>.110 on 2017-12-22 so <IP_ADDRESS> is probably not it
[16:01] <jdstrand> istr a bug about lxd not detecting apparmor correctly
[16:01]  * jdstrand tries to find
[16:04] <jdstrand> mvo: I wonder if it is a variation on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1743079?
[16:04] <mup> Bug #1743079: apparmor exit code 123 <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1743079>
[16:04] <jdstrand> mvo: ie, snap-confine.d doesn't exist and the profile fails to load
[16:04]  * jdstrand looks at the log more closely
[16:04] <mvo> jdstrand: ohhh, that sounds likely
[16:04] <mup> PR snapd#4516 opened: spread: setup machine creation on Linode <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4516>
[16:05] <niemeyer> HEADS UP: I just "broke" spread on Travis.. it will fail to allocate machines if something gets pushed *right now* as I'm testing the machine allocation with the new feature (PR above)
[16:05] <jdstrand> I don't see anything in the logs about that, but that doesn't surprise me. I doubt the logs would have lxc debug output
[16:11] <jdstrand> mvo (cc zyga-ubuntu): there was talk last week about artful kernels breaking lxd in that profiles were not loaded with 4.13 kernels due to the container check in /lib/apparmor/profile-load
[16:11] <jdstrand> mvo: this autopkgtest is with a 4.13 kernel
[16:11] <zyga-ubuntu> jdstrand: ouch
[16:11] <jdstrand> mvo: let me get a url for you. I don't see that a bug was filed
[16:13] <jdstrand> mvo (cc zyga-ubuntu): https://irclogs.ubuntu.com/2018/01/09/%23ubuntu-devel.html#t03:34
[16:14] <zyga-ubuntu> thank you
[16:14] <niemeyer> And it works.. wow.. nice to see 26 machines coming up at once.
[16:14] <mvo> jdstrand: thank you!
[16:15] <jdstrand> mvo (c zyga-ubuntu): ok, now I paid my penance for distracting you with the partial apparmor lxd bug I mentioned
[16:15] <jdstrand> hopefully this will help you zero in on it
[16:15] <zyga-ubuntu> niemeyer: it's live now?
[16:16] <zyga-ubuntu> niemeyer: do you have a KPI for the # of machines up? :D
[16:16] <zyga-ubuntu> (average/day maybe)
[16:16] <niemeyer> zyga-ubuntu: Sort of.. Travis should be working again, but new allocations won't work until I drop the 80 preallocated systems
[16:16] <zyga-ubuntu> k
[16:16] <niemeyer> Except for that one PR that I tuned
[16:16] <zyga-ubuntu> niemeyer: cool, I cannot wait to see how that performs, maybe we'll finally never run out of systems!
[16:17] <niemeyer> If this one works well, and by now I see no reason why it wouldn't, I will drop the preallocations and then everybody can enjoy faster tests
[16:17] <niemeyer> zyga-ubuntu: Keep an eye here then: https://travis-ci.org/snapcore/snapd/builds/331879604?utm_source=github_status&utm_medium=notification
[16:17] <niemeyer> zyga-ubuntu: All 26 systems are dynamically allocated 8GB machines
[16:17] <jdstrand> mvo: if you verify profile-load is actually the issue, I guess file a bug against apparmor with steps to reproduce and we can look at how to fix it
[16:18] <zyga-ubuntu> looking :)
[16:19] <niemeyer> zyga-ubuntu: Note how it took *9 seconds* between request to allocate the new machine and us having it
[16:19] <niemeyer> For all 26 of them.. so sweet
[16:21] <zyga-ubuntu> niemeyer: has something changed on linode? AFAIK last time you said that it doesn't matter if the machines are on or off, they cost the same; I understand that those are machines added and removed to the pool/account but is that a new feature on linode or just us making use of it?
[16:22] <niemeyer> zyga-ubuntu: It doesn't matter if the machine is on or off, but it does matter if you have the machine or not have it at all
[16:22] <mvo> zyga-ubuntu: so using the bind mount /snap /snap and unshare it approach, the mount table has now two entries for each snap :/
[16:22] <Chipaca> roundtripping with zip ftw
[16:22]  * Chipaca earned a break
[16:22] <niemeyer> zyga-ubuntu: In other providers (Amazon, GCE) you pay only when the machine is on, even if you have the whole metadata of the machine associated with it still (configuration, disks, etc)
[16:23] <zyga-ubuntu> mvo: ugh :/
[16:23] <zyga-ubuntu> mvo: did you remove the code in snap-confine that was doing stuff in that area?
[16:23] <zyga-ubuntu> niemeyer: aha, I see
[16:24] <mvo> zyga-ubuntu: I did but let me double check
[16:24] <niemeyer> zyga-ubuntu: Yeah, this is now dynamically creating the whole machine.. nothing exists before or after
[16:24] <zyga-ubuntu> niemeyer: also, no more out of disk space errors!
[16:24] <niemeyer> zyga-ubuntu: Hah, indeed.. :)
[16:35] <mup> PR snapd#4517 opened: data: add systemd unit that unshares /snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/4517>
[16:35] <niemeyer> It's looking good.. we just need to tune a bit the number of workers on each system
[16:35] <niemeyer> It hasn't finished, but we're down to only 6 machines
[16:35] <niemeyer> Which means 20 already terminated their job and went away
[16:36] <niemeyer> We're probably not making great use of the 8GB, either memory wise or CPU wise
[16:36] <niemeyer> It's probably better to split tasks further and take smaller machines
[16:37] <mvo> zyga-ubuntu: I pushed a first PR with the mount rshared thing, but its ugly due to the duplication afaict
[16:38] <zyga-ubuntu> mvo: duplication?
[16:38] <zyga-ubuntu> of those entries?
[16:40] <mvo> zyga-ubuntu: yes, everything under /snap it seems, I wonder if there is a different way to archive the --make-rshared. but I guess this only works on mounts not dirs?
[16:40] <zyga-ubuntu> mvo: it only works on mount entries, yes
[16:43] <mvo> zyga-ubuntu: ok, maybe we need to life with the dups then, I will see if a full snap run is happy
[16:43] <niemeyer> cachio: Is there a known Fedora error right now where the test hangs on "snap install"?
[16:44] <zyga-ubuntu> mvo: can you show me the code please?
[16:44] <mvo> zyga-ubuntu: sure, the PR is up
[16:44] <zyga-ubuntu> ah, let me refresh, thanks!
[16:44] <cachio> niemeyer, no
[16:44] <cachio> niemeyer, do you have any log?
[16:45] <niemeyer> cachio: https://travis-ci.org/snapcore/snapd/builds/331879604?utm_source=github_status&utm_medium=notification
[16:45] <niemeyer> cachio: Both workers hanging exactly in the same place for 10+ minutes, so not a coincidence
[16:45] <zyga-ubuntu> those fedora boxes
[16:45] <zyga-ubuntu> yeah
[16:46] <zyga-ubuntu> niemeyer: offtopic, I was thinking about my piles of abandonware lately and I was thinking about tagging it as such
[16:46] <zyga-ubuntu> niemeyer: and I quickly made this today: https://github.com/zyga/project-status-shields
[16:46] <mvo> zyga-ubuntu: adding the new units to the spec files now
[16:47] <cachio> niemeyer, I dont see any error on fedora
[16:47] <zyga-ubuntu> mvo: so this is the service unit
[16:47] <cachio> niemeyer, but are delayed
[16:48] <zyga-ubuntu> mvo: what happened to the snap.mount unit?
[16:48] <niemeyer> cachio: Well..? :)
[16:48] <cachio> niemeyer, first time I see that butI saw similar issues that I tried to address on the spread PR
[16:49] <cachio> niemeyer, https://github.com/snapcore/spread/pull/49
[16:49] <mup> PR spread#49: send keepalive packets every 10 seconds to avoid losing the connection <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/49>
[16:50] <zyga-ubuntu> mvo: reviewed
[16:50] <cachio> niemeyer, I have seen kill timeout reached the last weeks
[16:50] <cachio> niemeyer, not just for fedora
[16:51] <niemeyer> cachio: Again, an entire run looking perfect except for the two Fedora workers hanging exactly on the same place is not a coincidence
[16:51] <niemeyer> cachio: These are independent machines, started independently, running independently
[16:51] <kyrofa> kalikiana, are you still around?
[16:52] <kalikiana> hey kyrofa
[16:52] <kalikiana> Yes I am :-D
[16:52] <niemeyer> cachio: Have you seen where it's stuck?
[16:52] <kyrofa> kalikiana, late for you! I don't suppose you have 5 minutes to meet?
[16:52]  * zyga-ubuntu small supper & fresh tea
[16:52] <cachio> niemeyer, yes
[16:53] <kalikiana> kyrofa: Indeed. I'll grab my headphones. It's fine.
[16:53] <cachio> niemeyer, but the test seem to be ok
[16:53] <cachio> niemeyer, in fact it is the first time I see this error
[16:53] <kyrofa> kalikiana, about on-to by the way
[16:53] <cachio> niemeyer, perhaps it is something related to the store
[16:54] <kyrofa> Weekly?
[16:54] <kalikiana> kyrofa: Ack
[16:56] <niemeyer> cachio: Maybe, but what would justify getting stuck?
[16:57] <cachio> niemeyer, perhaps it is not stuck, spread is who is not getting the changes
[16:57] <cachio> niemeyer, I used to see that in my machine often
[16:57] <cachio> mainly when we use the quiet command
[16:58] <niemeyer> cachio: Not sure I understand what you mean by that
[16:58] <niemeyer> cachio: There's a "snap install" command there and no output
[16:59] <cachio> niemeyer, what I say is that it could be different thinks, either the snap command got stuck or spread did not received any other output but after a time snap install continued working
[17:00] <cachio> niemeyer, that's what I saw running from localhost in different situations
[17:00] <niemeyer> cachio: snap install should not hang silently like that
[17:01] <cachio> niemeyer, let me try to reproduce it here
[17:01] <niemeyer> cachio: If it does it's a bug.. if you are seeing this frequently, let's please  not ignore it
[17:01] <niemeyer> Anyway, really need to run.. o/
[17:01] <cachio> I created a PR in spread for those situations
[17:01] <cachio> niemeyer, but I am not sure if this case is affected by that
[17:02] <cachio> niemeyer, I'll try to reproduce it locally
[17:03] <cachio> niemeyer,  I am already runnig this test in order to see if I can reproduce it
[17:03] <jdstrand> mvo: fyi, jjohansen has been working on artful kernel for the autopkgtest failure. it seems like this will go to artful then the hwe kernel will get it in due course. in other words, if you can demonstrate that the test failure is due to the profiles not loading, then the bug will be fixed in due course
[17:04] <jdstrand> mvo: that came out a little weird-- he has a kernel to fix lxd, which I think will fix the autopkgtest failure (he isn't looking at the snappy autopkgtest failure)
[17:07] <cachio> mvo, the tests for beta are going really well
[17:08] <cachio> mvo, we are going to candidate soon
[17:10] <cachio> niemeyer, 2018-01-22 16:12:58 Cannot allocate linode:debian-9-64: no powered off servers in Linode account and no plan to allocate new machines
[17:10] <cachio> niemeyer, is being happening a change in linode?
[17:10] <cachio> all the machines failed because of this
[17:11] <cachio> https://travis-ci.org/snapcore/snapd/builds/331880011?utm_source=github_status&utm_medium=notification
[17:14]  * cachio lunch
[17:19] <kyrofa> elopio, did you ever manage to get the bot cranking out autopkgtests again?
[17:20] <elopio> kyrofa: no, had to do it locally. But haven't checked again since thursday.
[17:20] <kyrofa> elopio, looks like we have arm again
[17:20] <elopio> I'll check in a few.
[17:23] <kalikiana> Going to call it a day now
[17:23]  * kalikiana waves
[17:23] <zyga-ubuntu> kalikiana: o/
[17:24]  * zyga-ubuntu EODs and marks most of his projects as abandoned
[17:25] <kalikiana> zyga-ubuntu: is that a part of "live every day like it's your last day"? ;-)
[17:25] <zyga-ubuntu> kalikiana: haha
[17:25] <zyga-ubuntu> no, about some thinking I was doing
[17:25] <zyga-ubuntu> on ancinent projects
[17:25] <zyga-ubuntu> and on ...
[17:25] <zyga-ubuntu> https://github.com/zyga/project-status-shields
[17:28] <kyrofa> elopio, does that mean you tested snapcraft#1877 locally?
[17:28] <mup> PR snapcraft#1877: tests: move test files out of the snapcraft dir <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1877>
[17:28] <mup> PR snapcraft#1878 closed: repo: use debian.arfile instead of dpkg-deb <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1878>
[17:30] <kalikiana> zyga-ubuntu: neat
[17:34] <elopio> kyrofa: yes.
[17:44] <kyrofa> elopio, with success? :P
[17:44] <kyrofa> I'll merge that PR if so
[17:49] <elopio> kyrofa: https://autopkgtest.ubuntu.com/request.cgi still gives 500, so no way to launch them.
[17:49] <kyrofa> cjwatson, do you know anything about that?
[17:49] <elopio> kyrofa: and yes, locally the tests ran. Not all of them passed, but that's not because of the refactor.
[17:49] <kyrofa> elopio, enough to give you confidence in the PR, though?
[17:50] <cjwatson> kyrofa: (a) it's intentional until Spectre mitigation is finished (b) in general please ask Laney about autopkgtest stuff, not me
[17:50] <elopio> kyrofa: yes, because travis is running all of them and passing.
[17:50] <kyrofa> cjwatson, excellent, thank you. Good to know who runs that stuff!
[18:14] <cachio> niemeyer, I could reproduce the error on fedora
[18:14] <cachio> this is the log with the error https://paste.ubuntu.com/26438961/
[18:20] <zyga-ubuntu>             return BadRequest("cannot %s %q: %v", inst.Action, inst.Snaps[0], err)
[18:20] <zyga-ubuntu> looks like inst.Snaps is empty
[18:21] <zyga-ubuntu> Chipaca: ^
[18:24] <cachio> zyga-ubuntu, did you see this error?
[18:25] <cachio> seem to be affecting fedora
[18:26] <zyga-ubuntu> cachio: I looked at your log, I didn't investigate more
[19:15] <mup> PR snapd#4518 opened: tests: fix for test interface-netlink-connector <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4518>
[19:23] <zyga-ubuntu> cachio: ^
[19:23] <zyga-ubuntu> I think you need to use ' ' rather than ""
[19:23] <zyga-ubuntu> it looks like invalid yaml
[19:23] <barry> hey folks, sorry to ping here but i have a quick question which i didn't seem to find answered on the forum.  what is the roadmap for official rhel7 support?  any thoughts on osx support?  i'm betting rhel6 is completely infeasible due to its age
[19:24] <zyga-ubuntu> barry: hey
[19:24] <barry> zyga-ubuntu: hi!
[19:24] <zyga-ubuntu> barry: I think rhel7 is "soon" but nobody has championed that, perhaps someone just needs to work together with Pharaoh_Atem who maintains the fedora packages
[19:25] <zyga-ubuntu> barry: osx support is something that is a different class of problem to solve (virtualization most likely)
[19:25] <cachio> zyga-ubuntu, yes
[19:25] <cachio> zyga-ubuntu, thanks
[19:25] <barry> zyga-ubuntu: that totally makes sense re: osx
[19:26] <zyga-ubuntu> barry: I think that if you want to see rhel happen soon you should get in touch with neal (Pharaoh_Atem) and see what's missing
[19:26] <zyga-ubuntu> I heard neal made some centos packages and I'm not on top of that anymore
[19:27] <zyga-ubuntu> barry: technically I think rhel is "just packagign"
[19:33] <cachio> zyga-ubuntu, should I add net-admin capability to the ssh-keys and ssh-public-keys interface?
[19:33] <cachio> zyga-ubuntu, I mean, to avoid connecting to network-control
[19:35] <zyga-ubuntu> cachio: I don't think so
[19:35] <zyga-ubuntu> those interfaces don't say "you are network admin"
[19:35] <zyga-ubuntu> cachio: perhaps just use a simpler test
[19:35] <zyga-ubuntu> cachio: don't run ssh
[19:35] <zyga-ubuntu> cachio: just read keys
[19:36] <cachio> zyga-ubuntu, ok, but the test is sharing ssh, that's why I using it
[19:36] <cachio> zyga-ubuntu, I mean, I am trying to cover the whole interface
[19:37] <zyga-ubuntu> cachio: yes but the interface doesn't promise you can run ssh
[19:37] <zyga-ubuntu> cachio: not sure if that's worth it
[19:39] <cachio> zyga-ubuntu, ok, so perhaps this line should not be included
[19:39] <cachio> in the interface /usr/bin/ssh ixr,
[19:40] <zyga-ubuntu> cachio: hmm, intersting,
[19:40] <zyga-ubuntu> jdstrand: ^ do you think this makes sense?
[19:40] <zyga-ubuntu> ssh-keys should not be about running ssh
[19:41] <zyga-ubuntu> jdstrand: or if it should it should really allow it
[19:42] <Pharaoh_Atem> zyga-ubuntu: there's a few other things, like making the software install integration work
[19:45] <zyga-ubuntu> Pharaoh_Atem: gnome-software?
[19:45] <zyga-ubuntu> Pharaoh_Atem: what's missing there?
[19:45] <zyga-ubuntu> Pharaoh_Atem: I think getting basic CLI package out there would help
[19:51] <jdstrand> cachio: please don't add network-control for testing ssh
[19:52] <barry> zyga-ubuntu: okay thanks
[19:52] <jdstrand> cachio: when I tested the interface, I did not need network-control
[19:52] <jdstrand> cachio: how are you using ssh?
[19:53] <cachio> jdstrand, https://github.com/snapcore/snapd/pull/4512/files
[19:53] <mup> PR #4512: tests: new spread test for ssh-public-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4512>
[19:53] <jdstrand> cachio: the interfacec doesn't claim to support everything the ssh command can do
[19:55] <cachio> jdstrand, so, which is the idea about the ssh command for that interface?
[19:55] <cachio> jdstrand, to do what?
[19:55] <cachio> jdstrand, so I can update the test
[20:00] <jdstrand> cachio: "ssh-public-keys: I was unable to determine a use for this interface" from https://github.com/snapcore/snapd/pull/4100
[20:00] <mup> PR #4100: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4100>
[20:01] <jdstrand> cachio: people wanted that interface to only allow the public keys, so that is what it does. probably the best test is ssh -V and testing if can access the .pub file
[20:02] <cachio> jdstrand, ok
[20:02] <cachio> jdstrand, what about the ssh-keys?
[20:02] <cachio> jdstrand, should I test the ssh command connection?
[20:03] <cachio> jdstrand, or just the access to the keys?
[20:03] <jdstrand> cachio: "ssh-keys: I was able to login to a remote server"
[20:03] <cachio> jdstrand, I tried that and I couldn't, let me try again
[20:03] <jdstrand> cachio: if you can do it without network-control, then I say go for it. I don't know why it is asking for that...
[20:04] <jdstrand> cachio: if you can't, the ssh -V and testing if can access .pub and private keys should be enough
[20:04] <cachio> jdstrand, ok
[20:11] <Pharaoh_Atem> zyga-ubuntu: g-s is one bit, but not really the important one
[20:11] <Pharaoh_Atem> the important one is making sure that the selinux policies apply correctly
[20:12] <zyga-ubuntu> Pharaoh_Atem: and what is missing there?
[20:14] <Pharaoh_Atem> zyga-ubuntu: well, I still need to backport a bunch of patches for ensuring the paths work correctly
[20:14] <Pharaoh_Atem> basically, I need to retry with 2.30 / 2.31
[20:14] <Pharaoh_Atem> which I'm preparing for Fedora right now
[20:16] <zyga-ubuntu> I see, thank you!
[20:22] <cachio> jdstrand, permission denied
[20:22] <cachio> [  497.497832] audit: type=1400 audit(1516652364.412:57): apparmor="DENIED" operation="create" profile="snap.test-snapd-ssh-keys.ssh" pid=19379 comm="ssh" family="inet" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
[20:23] <cachio> jdstrand, this is without network-control
[20:23] <cachio> for the ssh-keys interface
[20:34] <jdstrand> cachio: sure, you will definitely need 'network'
[20:34] <roadmr> elopio: hi! hey do you know who mans the snapcrafters e-mail address?
[20:35] <elopio> roadmr: I would guess Alan and Martin.
[20:35] <roadmr> thanks elopio ! (I wrote there to double-check a couple of snap transfers, just wanted to check if it's not a black hole heh)
[20:36] <cachio> jdstrand, so, what do you prefer for the test, add network or just check keys? for the ssh-keys interface
[20:57] <lundmar> Hi. I need to stage libqt5charts5 but this package is not available in the official Xenial repo. I've found an unoffical .deb package I want to use. Is there a plugin that can install remote .deb packages by URL?
[21:04] <jdstrand> cachio: I don't have a preference. I think it is sufficient to only check check the keys
[21:04] <cachio> jdstrand, ok, tx
[21:05] <jdstrand> roadmr: istr noise][ reporting at the sprint that snap v1 is gone. does that mean I can finally remove click and snap v1 from the review tools?
[21:06] <noise][> jdstrand - yes!
[21:07] <roadmr> jdstrand: \o/ zorch em
[21:25] <jdstrand> ok thanks
[21:37] <mup> PR snapd#4518 closed: tests: fix for test interface-netlink-connector <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4518>


[09:46] <zetheroo1> I am trying to remove a package but am getting 'Processing was halted because there were too many errors.'
[09:47] <zetheroo1> Full output https://pastebin.com/f0gsmgze
[09:51] <tomreyn> zetheroo1: it appears that the post-removal script which is part of the installed onlyoffice-documentserver package (and can be specific to its package version) ran into an error. you may be able to get more information about this by running the    dpkg --remove   command against this package manually / directly.
[09:53] <tomreyn> zetheroo1: what can help in such situations is to first upgrade the package to the latest version, then attempt removing it again. another approach you could take is to edit the post-removal script manually to work around the root cause of this error (once you know it), then attempt removing the package again.
[09:53] <tomreyn> note that this is a third party package, not supported by ubuntu
[09:54] <zetheroo1> Ok
[09:57] <zetheroo1> I did 'rm /var/lib/dpkg/info/onlyoffice-documentserver.postrm' and now the package uninstalled successfully
[09:59] <zetheroo1> Another question ... probably not Ubuntu-specific ... I have a RAID5 which randomly becomes read-only. I have to unmount it, do a fsck on it, and then remount for it to be read/write again.
[09:59] <zetheroo1> Any idea what could be causing it to become read-only? Could a failing/bad disk do this?
[10:01] <tomreyn> RAID-5 is not a file systems. you do not unmount it, run a fsck against it.
[10:02] <tomreyn> RAID-5 is not a file system. you do not unmount it, or run a fsck against it.
[10:03] <tomreyn> you may be able to run a parity check against the RAID, depending on how it was setup and which tools are available for its management.
[10:04] <tomreyn> a failing disk is a common cause of a RAID implementation pausing writes to a RAID array.
[10:05] <tomreyn> (may vary by RAID level and implementation, though)
[10:10] <zetheroo1> ok, yes, sorry. I unmount /dev/md0 and run fsck against that
[10:14] <tomreyn> md events go to dmesg, are logged to syslog / the systemd journal. journalctl -b    would get you access to anything logged since the latest boot. search for "kernel: md"
[10:15] <tomreyn> cat /proc/mdstat     provides information on the current state and health of all md managed RAID arrays.
[10:19] <tomreyn> for anything else, use mdadm
[10:20] <zetheroo1> ok, seems to be a lot of messages like this in the syslog:
[10:20] <zetheroo1> Jun 27 22:59:16 gary kernel: md/raid:md0: read error not correctable (sector<PHONE_NUMBER> on sdc).
[10:20] <zetheroo1> oh crap ... for sdd as well
[10:21] <tomreyn> RAID-5 is not recommended nowadays, certainly not with larger disks.
[10:22] <zetheroo1> These disks are from an old NAS (FreeNAS) which was running for ~6 years ... so I guess the disks would be pretty worn :P
[10:23] <zetheroo1> I was going between RAID5 and 10 ... but 10 seemed overkill for a Home NAS
[10:29] <zetheroo1> I noticed I have the lxd snap installed - is this a default snap on Ubuntu Server 20.04?
[10:30] <zetheroo1> do some snaps "pull in" other snaps? https://pastebin.com/KEYZqHsh
[10:42] <murmel> zetheroo1: yes, lxd is default on server
[10:43] <murmel> the only 3 snaps by default are lxd,core20 and snapd
[10:56] <zetheroo1> ok thanks
[11:07] <zetheroo1> I have now replaced the worst disk (sdd) in the RAID5 array, but I'm confused about the various commands/instructions online about re-adding the disk to the array. So far I did 'sudo mdadm --add /dev/md0 /dev/sdd' and 'sudo mdadm -D /dev/md0' shows /dev/sdd 'rebuilding'. Do I have to do anything else? There's instructions to use the 'mdadm --grow' command and to create the filesystem etc on the new disk ...
[11:08] <zetheroo1> This is the output of mdadm: https://pastebin.com/XB4fqHub
[11:41] <radioa> Hi, I have an issue with Gigabyte E252-P30 ARM platform with Ampere Altra Q80-30: i can't boot Ubuntu Server 20.04/22.04 net installers via iPXE in UEFI mode. Files(initrd, linux) loads successfully, but after that i see 3 messages with EFI stub: prefix, last one is EFI stub: Exiting boot services and installing virtual address map... At this point, loading hangs. Any tips or ideas are greatly appreciated!
[15:43] <yurtesen> ahasenack: jetty9 has the same problem as tomcat9. Syslog is not able to write to /var/log/jetty because the log folder has 750 permissions and owned by jetty:jetty.  As the syslog user does not have write access...
[15:51] <akincer> Back in 20.04 there was a bug during server install that caused the installer to crash on a VMware VM if IPv4 is configured. It appears this still exists in 22.04. Is this a known bug that is slated to be fixed?
[16:39] <tomreyn> akincer: do you have the bug report id? "crash" as in a segementation fault, or something else? what does vmware do differently that would trigger this?
[20:06] <samy1028b> akincer: Could you give more details.  I've been running a bunch of Ubuntu 14.04/16.04/18.04/20.04 on ESXi 6.0/7.0 and never seen anything like this.
[20:06] <samy1028b> Is it ESXi / vSphere,  VM Workstation, VM Player, or something else where you saw this?
[21:07] <patdk-lap> akincer, I'm not sure what your talking about
[21:07] <patdk-lap> I have installed hundreds of 20.04 and 22.04 on esxi 6.5 and 6.7 without an issue with ip4 configured


[14:58] <bdrung_work> !dmb-ping
[14:59] <bdrung_work> can someone let me in our channel?
[15:00] <Laney> hi
[15:00] <Laney> can't you auth to nickserv?
[15:01] <bdrung_work> not with this nick name.
[15:03] <stgraber> bdrung_work: try now
[15:03] <bdrung_work> stgraber: thanks
[15:04] <laney_> just checked: /msg nickserv identify nick password works
[15:04] <Laney> anyway. ScottK is supposed to chair according to wiki
[15:04] <bdrung_work> i didn't tried to pass my nick there too
[15:08]  * barry waves to ScottK
[15:08] <IdleOne> yup, you can identify to your account no matter the nick you are using (provided that nick is not already registered by someone else)
[15:14] <mitya57> o/
[15:14] <mitya57> Is the DMB meeting happening?
[15:15] <Laney> I think there should be enough people
[15:16] <Laney> the order of the chairs is ScottK tumbleweed stgraber barry bdrung_work
[15:16] <barry> Laney: so i guess that would make stgraber up next?
[15:17] <stgraber> #startmeeting DMB
[15:17] <meetingology> Meeting started Mon Dec 16 15:17:16 2013 UTC.  The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:17] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[15:17] <stgraber> #topic review of past action items
[15:17] <stgraber> micahg to restructure PPU teams.
[15:18] <stgraber> I'm assuming nothing changed there, carried to next meeting.
[15:18] <stgraber> Discussion of skipping of Dec 30 2013 meeting on ML
[15:18] <stgraber> this was discussed and the meeting of the 30th will be skipped.
[15:18] <stgraber> #topic Per Package Uploader Applications
[15:18] <bdrung_work> +1 for skipping the Dec 30 meeting
[15:19] <barry> next meeting after today is 13 jan
[15:19] <stgraber> #topic Dmitry Shachnev for PPU of: python-markdown, python-keyring, python-secretstorage, python-docutils, python-qt4, sip4, sphinx and the QT5 packageset
[15:19] <mitya57> o/ again
[15:20] <stgraber> hi mitya57, can you please introduce yourself and your application?
[15:20] <mitya57> Of course
[15:21] <mitya57> I am Dmitry Shachnev, user of Ubuntu since some ancient version, developing since ~Natty. I am interested in a big bunch of stuff, including Python, Qt, JS, GNOME and KDE.
[15:22] <mitya57> For the packages listed (^), I am not the primary maintainer.
[15:22] <mitya57> Most of them (except sphinx and sip4 I think) are now in sync with Debian.
[15:22] <mitya57> s/not/now/
[15:23] <mitya57> For some of them I am also upstream co-developer (i.e. for python-keyring)
[15:23] <mitya57> And I also contribute to upstream Qt (have made ~13 commits)
[15:24] <mitya57> Well, I think that will be enough, the details are in the application
[15:24] <mitya57> https://wiki.ubuntu.com/DmitryShachnev/PPUApplication
[15:25] <Riddell> mitya57: what have you done with sip4 and pyqt?
[15:25] <mitya57> Riddell: ScottK asked me to help with maintaining them, I think I've done one sip4 upload and two python-qt4 uploads
[15:26] <Laney> mitya57: thanks
[15:26] <Laney> are you in the Debian teams for all of these things?
[15:26] <mitya57> I am also maintaining pyqt5, but it is in universe, so I can already upload it in Ubuntu
[15:26] <mitya57> Laney: yes
[15:27] <barry> mitya57: why ppu and not core-dev yet?
[15:27] <Laney> lolz, tumbleweed is your AM
[15:27] <mitya57> barry: I don't know :)
[15:27] <barry> :)
[15:28] <barry> mitya57: for the record, i've been very happy with all your contributions to python.  thanks!
[15:28] <Riddell> mitya57: any plan for sip 4.15.3?
[15:29] <Laney> regarding your "Things I don't like" - not all of it is due to a lack of communication
[15:29] <mitya57> Riddell: oh, it just needs a trivial merge
[15:29] <mitya57> Will do when I get upload rights :)
[15:29] <Riddell> groovy, mitya57 gets my +1 :)
[15:29] <Laney> Riddell in joining the DMB shocker
[15:30] <Laney> anyway, sometimes there are general technical / design differences
[15:31] <Laney> and there are pockets of great collaboration even within communities like GNOME imo, but it's obviously quite a way from perfect
[15:31] <Laney> what do you think we could do there?
[15:31] <mitya57> Laney: actually, that what-i-dont-like-in-ubuntu section is quite difficult to fill in
[15:31] <Laney> I do like what you put though
[15:32] <Laney> as someone who calls out not-coordinated work and not-forwarded patches from time to time
[15:32] <mitya57> I think we should get more people testing unstable GNOME and pointing out issues, and discussing these issues with upstream
[15:32] <Laney> a lot of people are just resigned to the projects being different these days
[15:33] <Laney> the collaboration on the library level is better
[15:33] <Laney> but Ubuntu GNOME is good in this regard too
[15:33] <mitya57> Yes, but the Gtk's CSDs stuff looks like nobody tested it under Unity before 3.10 was released
[15:34] <mitya57> (Gtk is a library :P)
[15:34] <Laney> yeah I was thinking of that
[15:34] <Laney> quite a few changes came from the pre-upload testing
[15:34] <Laney> still, the basic problem is that we were testing something after it was already baked
[15:35] <Laney> ahem, I'll stop rambling
[15:35] <Laney> anyone else?
[15:36] <Laney> well, I'm ready to vote :-)
[15:36] <bdrung_work_> no, everything is answered already.
[15:36] <bdrung_work_> i am ready to vote.
[15:36]  * barry too
[15:36] <Laney> stgraber:
[15:37] <stgraber> Laney: 1sec
[15:38] <stgraber> #vote Dmitry Shachnev for PPU of: python-markdown, python-keyring, python-secretstorage, python-docutils, python-qt4, sip4, sphinx and the QT5 packageset
[15:38] <meetingology> Please vote on: Dmitry Shachnev for PPU of: python-markdown, python-keyring, python-secretstorage, python-docutils, python-qt4, sip4, sphinx and the QT5 packageset
[15:38] <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me)
[15:39] <Laney> +1
[15:39] <bdrung_work_> +1
[15:39] <meetingology> +1 received from Laney
[15:39] <meetingology> +1 received from bdrung_work_
[15:39] <barry> +1 [keep going!  i hope to see core-dev app soon]
[15:39] <meetingology> +1 [keep going!  i hope to see core-dev app soon] received from barry
[15:39] <stgraber> +1
[15:39] <meetingology> +1 received from stgraber
[15:40] <stgraber> #endvote
[15:40] <meetingology> Voting ended on: Dmitry Shachnev for PPU of: python-markdown, python-keyring, python-secretstorage, python-docutils, python-qt4, sip4, sphinx and the QT5 packageset
[15:40] <meetingology> Votes for:4 Votes against:0 Abstentions:0
[15:40] <meetingology> Motion carried
[15:40] <stgraber> #action stgraber to get webops to add the new PPU and add qt5 membership
[15:40] <meetingology> ACTION: stgraber to get webops to add the new PPU and add qt5 membership
[15:40] <Laney> you can add the membership yourself
[15:40] <Laney> unless I'm parsing that wrong
[15:41] <Laney> mitya57: congrats!
[15:41] <mitya57> barry: UCD application in my todo list after becoming a DD :)
[15:41] <mitya57> Laney & everybody: thanks!
[15:41] <barry> mitya57: \o/  hopefully it won't take you as long for DD as it did for me :)
[15:41] <Laney> UCD is something else
[15:42] <stgraber> Laney: right, I'll add the membership myself
[15:42] <Laney> (contributing developer)
[15:42] <Laney> beware of applying for that
[15:42] <Laney> :P
[15:42] <dholbach> mitya57, congratulations!
[15:42] <mitya57> dholbach: danke!
[15:42] <dholbach> :)
[15:42] <mitya57> Laney: names conflict, that is
[15:42] <Laney> everyone just says core-dev
[15:42] <stgraber> #topic Graham Inggs for MOTU
[15:43] <ginggs> hi
[15:43] <stgraber> ginggs: hey there, can you introduce yourself and your application please?
[15:43] <ginggs> I'm Graham Inggs, I've been an Ubuntu user since 2007/2008 and have been contributing since 2012
[15:44] <dholbach> ginggs, sorry for not getting to update your application - just for the completeness' sake I'd like to point out that I was VERY happy with Graham's work, if there were ever issues, Graham was very quick to resolve them, coordinate with Debian and Upstreams, huge +1 from me
[15:45] <mitya57> Let me also give a +1 to ginggs if you don't mind :)
[15:46] <barry> ginggs: hi.  in your endorsements section, there is a criticism about "over-eagerness to sru".  what's your criteria for deciding whether to sru a fix or not?
[15:47] <ginggs> If it affects a lot of users or the fix is trivial, I'll try for an SRU
[15:49] <barry> ginggs: do you think the effort to sru fixes is too high, too low, or just right?
[15:51] <ginggs> I would say it's just right; it's not so easy as to make one want to SRU everything, and it's not so difficult as to make one avoid it altogether
[15:54] <Laney> Do you keep up with the testing status of things you have SRUed?
[15:54] <Laney> Sometimes things can linger in -proposed
[15:56] <ginggs> yes, I usually give other people a chance to test and if no responses after 7 days I will test again myself and change the verification status
[15:56] <barry> ginggs: i notice the conflict regarding sru's between your endorsement feedback and your comment about "what i like least in ubuntu".  how do you resolve these two viewpoints?
[16:01] <ginggs> I don't think it will make me want to SRU any less, but if I had upload rights at least my uploads wouldn't be taking up the sponsors team's time
[16:01] <bdrung_work> ginggs: did your SRUs had any regressions?
[16:02] <ginggs>  i don't believe so
[16:07] <stgraber> ginggs: are you subscribed to ubuntu-devel-announce?
[16:07] <ginggs> not yet, no
[16:07] <stgraber> can you please make sure you are?
[16:07] <ginggs> will do
[16:08] <stgraber> also. Some packages in universe are seeded and require extra care at specific times of the cycle. Can you tell me how to check whether a package is seeded or not, when to be careful about those and how to check what images may be affected?
[16:11] <ginggs> can check with seeded-in-ubuntu and need to be careful with seeded packages after beta freeze
[16:12] <ginggs> not sure offhand how to check which image
[16:12] <stgraber> not only after beta freeze, there are milestones before that (such as this week)
[16:13] <stgraber> seeded-in-ubuntu is pretty reliable at telling you which image
[16:13] <stgraber> everyone ready to vote?
[16:13] <Laney> yup
[16:14] <stgraber> #vote ginggs for MOTU
[16:15] <stgraber> meetingology seems dead, so don't wait for it :)
[16:16] <Laney> +1
[16:18] <barry> +1
[16:19] <bdrung_work_> +1
[16:20] <tumbleweed> +1 [ sorry I missed the rest of the meeting ]
[16:21] <stgraber> +1
[16:21] <stgraber> #endvote
[16:21] <stgraber> #action stgraber to add ginggs to the relevant teams
[16:21] <dholbach> ginggs, congratulations! :)
[16:21] <tumbleweed> ginggs: \o/
[16:21] <stgraber> the chair for our next meeting (January 13th) will be tumbleweed
[16:22] <stgraber> #topic AOB
[16:22] <stgraber> anything?
[16:22] <Laney> it should be ScottK since he missed this one
[16:22] <stgraber> oh, good point
[16:23] <stgraber> I'll just move myself at the back of the rotation, that should do it
[16:23] <barry> stgraber: yep
[16:24] <stgraber> #endmeeting
[16:24] <meetingology> Meeting ended Mon Dec 16 16:24:33 2013 UTC.
[16:24] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-12-16-15.17.moin.txt
[16:24] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-12-16-15.17.html
[16:24] <barry> stgraber: thanks!
[16:24] <stgraber> oh and now meetingology works... :)
[16:25] <tumbleweed> well, he missed a bit
[16:26] <Laney> thanks!
[16:26] <Laney> & yay for new motus
[16:27] <tumbleweed> yeah, that's getting rare
[16:28] <Laney> ginggs: https://wiki.ubuntu.com/MOTU/New (please update it with new things as you learn them)
[16:45] <jdstrand> hi!
[16:45] <mdeslaur> \o
[16:45] <mdeslaur> hi
[16:45] <tyhicks> hello
[16:45] <jdstrand> #startmeeting
[16:45] <meetingology> Meeting started Mon Dec 16 16:46:00 2013 UTC.  The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:45] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[16:45] <jdstrand> The meeting agenda can be found at:
[16:45] <jdstrand> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[16:46] <jdstrand> [TOPIC] Announcements
[16:46] <jdstrand> Due to the EOY leave, the next security team meeting will be 2014/01/06
[16:47] <jdstrand> [TOPIC] Weekly stand-up report
[16:47] <jdstrand> I'll go first
[16:47] <jdstrand> I'm on triage this week
[16:47] <jdstrand> I'll be here all week this week!
[16:47] <jdstrand> (try the veal)
[16:47] <mdeslaur> \o/
[16:47] <jdstrand> but, I'm off the next two weeks
[16:47] <mdeslaur> slacker
[16:47] <mdeslaur> :)
[16:47] <jdstrand> hehe
[16:48] <jdstrand> I've got some pending updates
[16:48] <jdstrand> and a few work items around apparmor-easyprof-ubuntu that I am working on
[16:48] <jdstrand> I dug into oxide testing last week and started developing policy for apparmor policy version 1.1 for it
[16:49] <jdstrand> chris is off til the end of the year, so I'll mention that the packaging is all together for it, and it builds for all archs
[16:49] <mdeslaur> oh, that's awesome :)
[16:50] <jdstrand> it fails at runtime on armhf which we think is due to a compile-time option surrounding neon
[16:50] <jdstrand> the navigation api is reviewed and I think will be committed soon
[16:51] <jdstrand> so it is really coming along. I've got a todo this week to communicate this to other stakeholders (and an oxide meeting too)
[16:51] <jdstrand> I think that's it for me
[16:51] <jdstrand> mdeslaur: you're up
[16:51] <mdeslaur> I'm on community this week
[16:51] <mdeslaur> I have a couple of updates pending, I'm in the final stages of testing
[16:52] <mdeslaur> and I'll continue going down the list, as usual.
[16:52] <mdeslaur> that's about it from me
[16:52] <mdeslaur> hrm, sbeattie isn't here
[16:52] <mdeslaur> tyhicks: you're up
[16:52] <tyhicks> I've got some carry over from last week
[16:53] <tyhicks> I got hung up for a little too long on an issue where the emulator fails the executable stack test of test-kernel-security.py
[16:53] <tyhicks> I spent quite a bit of time on it and I've convinced myself that it is an emulator bug because everything works fine on maguro
[16:54] <jjohansen1> ickky
[16:54] <jdstrand> tyhicks: interesting-- can you file it if you haven't already? it would be good to get the emulator fixed so that other teams don't get tripped up
[16:54] <tyhicks> I've built final goldfish, manta, and mako kernels and need to do some quick testing and then send off the patches
[16:54] <tyhicks> jdstrand: sure, that's a good idea
[16:54] <jdstrand> tyhicks: oh, maguro, interesting-- do we have access to that device on the team?
[16:55] <jjohansen1> jdstrand: ? I've got one
[16:55] <tyhicks> oh no
[16:55] <tyhicks> I was wrong about the code name
[16:55] <tyhicks> I meant grouper
[16:55] <jdstrand> jjohansen1: ah right, you have nearly everything :)
[16:55] <jdstrand> ok
[16:55]  * tyhicks has another shot of coffee
[16:55] <jdstrand> heh
[16:56] <tyhicks> after that, I'll be on user data encryption
[16:56] <jjohansen1> jdstrand: no no, please forget I ever mentioned uh, never mind ;)
[16:56] <tyhicks> well, there is one problem
[16:56] <tyhicks> I can't test the manta and mako kernels
[16:56] <tyhicks> but I also don't want to bog down jj
[16:57] <tyhicks> I think testing in the emulator is sufficient, though
[16:57] <jdstrand> I have a mako. chris has a manta
[16:57] <jdstrand> (though chris is off this week)
[16:57] <jdstrand> tyhicks: if you need me, holler
[16:57] <tyhicks> all mako and manta get are some backported yama patches since their kernel configs were already hardened correctly
[16:57] <tyhicks> ok
[16:57] <tyhicks> I'll think about it some more
[16:57] <tyhicks> that's it for me
[16:57] <tyhicks> jjohansen1: you're up
[16:59] <jjohansen1> I'm working on apparmor again this week, I've got some testing work to coordinate with sbeattie around dfa and permission changes, and yes ipc work.
[16:59] <jjohansen1> And I'm fixing another invalidation bug that keeps taking down anything using a compound label
[17:00] <jjohansen1> so files, sockets, ..., stacking pretty much everything
[17:00]  * jjohansen1 sighs
[17:00] <sarnold> :(
[17:02] <jjohansen1> well I think thats it from me, sarnold your up
[17:04] <sarnold> I'm in the happy place this week
[17:05] <sarnold> I'm all caught up on the apparmor patches (I think) so I'm moving on to the MIR audits, it's amazing how quicklyu they pile up when I'm not looking..
[17:05] <jdstrand> yes...
[17:05] <tyhicks> sounds like it is about time to write some more apparmor patches
[17:05] <tyhicks> ;)
[17:06] <jdstrand> hah
[17:06] <sarnold> haha :)
[17:07] <sarnold> I started reading the developer.ubuntu.com docs last night and found a handful of problems that I'll file some bugreports for.. it's amazing how much is done already :) woo.
[17:07] <sarnold> I think that's me covered, jdstrand back to you
[17:08] <jdstrand> sarnold: are these security bugs or just regular bugs?
[17:08] <sarnold> jdstrand: regular bugs :) woot
[17:08] <jdstrand> ok, good :)
[17:08] <jdstrand> [TOPIC] Highlighted packages
[17:08] <jdstrand> The Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so.
[17:08] <jdstrand> See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved.
[17:08] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/rawstudio.html
[17:09] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/nagstamon.html
[17:09] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/slim.html
[17:09] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/ruby-passenger.html
[17:09] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/autotrace.html
[17:09] <jdstrand> [TOPIC] Miscellaneous and Questions
[17:09] <jdstrand> Does anyone have any other questions or items to discuss?
[17:09] <mdeslaur> jdstrand: we need to talk about who is doing watch during the holidays
[17:09] <jdstrand> mdeslaur: yeah, I added that to my todo this morning
[17:10] <mdeslaur> cool
[17:10] <jdstrand> mdeslaur: thanks for reminding me
[17:14] <jdstrand> mdeslaur, tyhicks, jjohansen1, sarnold: thanks!
[17:14] <jdstrand> #endmeeting
[17:14] <meetingology> Meeting ended Mon Dec 16 17:14:36 2013 UTC.
[17:14] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-12-16-16.46.moin.txt
[17:14] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-12-16-16.46.html
[17:14] <sarnold> thanks jdstrand!
[17:14] <jjohansen1> thanks jdstrand
[17:14] <mdeslaur> thanks jdstrand!
[17:14] <jdstrand> :)
[17:16] <tyhicks> thanks!


[12:55] <cheater_> hi
[12:56] <cheater_> i have a slight issue understanding something. i understand there can be two types of repositories that i have on my hard drive, one is a repository from which i can create new checkouts (and could act as a central repo) and another one needs the original repository to work. is that correct?
[12:58] <AuroraBorealis> you are probably thinking about branches vs lightweight checkouts?
[12:58] <cheater_> possibly
[12:58] <AuroraBorealis> a branch has the entire history
[12:58] <cheater_> how do i create either of them?
[12:58] <AuroraBorealis> a lightweight  checkout doesn't have history
[12:59] <cheater_> as in, the commands
[12:59] <AuroraBorealis> or it could be a checkout of a repository, which means that it needs to access the repo to pretty much do anything
[12:59] <cheater_> ah yes, i am probably thinking branch vs checkout
[12:59] <cheater_> is there a reliable way to tell those two apart?
[12:59] <AuroraBorealis> http://doc.bazaar.canonical.com/latest/en/user-reference/init-repository-help.html
[13:00] <cheater_> let me look at that very quickly
[13:01] <AuroraBorealis> http://doc.bazaar.canonical.com/latest/en/user-reference/checkouts-help.html
[13:01] <AuroraBorealis> the difference between branches and a heavy checkout is the 'location' to where it commits
[13:01] <AuroraBorealis> as in if its bound or not
[13:02] <AuroraBorealis> not sure how to tell a branch from a checkout
[13:03] <cheater_> would this not register in the branches registered somewhere in bzr metadata?
[13:03] <AuroraBorealis> im sure it is
[13:03] <AuroraBorealis> not sure if there is any nice command to tell
[13:04] <cheater_> see i have four source trees here
[13:04] <cheater_> i did a heavyweight branch just before the central server got hit by a meteorite
[13:04] <AuroraBorealis> o.o
[13:05] <cheater_> it's one of them and i need to figure out which
[13:05] <AuroraBorealis> well
[13:05] <cheater_> also, one of these trees which is what i have been working out of is a lightweight checkout
[13:05] <AuroraBorealis> if its a lightweight checkout
[13:05] <AuroraBorealis> then it WONT have history
[13:05] <AuroraBorealis> the other 3 options it should still have history.
[13:05] <cheater_> yeah
[13:05] <AuroraBorealis> and it should not matter which one it is
[13:06] <cheater_> if i go there and do cat .bzr/branch/branch.conf then it shows me bound = True and bound_location = sftp://whatever
[13:06] <cheater_> that is evident of it being a lightweight checkout right?
[13:06] <AuroraBorealis> not necessarilly
[13:06] <AuroraBorealis> A checkout is created with the bzr checkout command (see “help checkout”). You pass it a reference to another branch, and it will create a local copy for you that still contains a reference to the branch you created the checkout from (the master branch). Then if you make any commits they will be made on the other branch first. This creates an instant mirror of your work, or facilitates lockstep development, where eac
[13:06] <AuroraBorealis> h developer is working together, continuously integrating the changes of others.
[13:06] <AuroraBorealis> However the checkout is still a first class branch in Bazaar terms, so that you have the full history locally
[13:07] <AuroraBorealis> just means that when you commit, its gonna commit to the remote place first
[13:07] <AuroraBorealis> and then commit locally
[13:07] <AuroraBorealis> basically mimics svn in a way
[13:07] <cheater_> so how can i tell if a checkout is lightweight?
[13:07] <AuroraBorealis> try doing bzr log on it
[13:07] <AuroraBorealis> i guess
[13:07] <cheater_> where is the difference in meta data?
[13:08] <AuroraBorealis> i am not that exierenced in bzr's internals so im not sure
[13:08] <cheater_> what should it do? bzr log
[13:08] <AuroraBorealis> well
[13:08] <AuroraBorealis> bzr log wont work if its lightweight
[13:08] <AuroraBorealis> cause it has no history
[13:08] <AuroraBorealis> one sec let me try a lightweight checkout
[13:08] <cheater_> thanks
[13:08] <cheater_> i currently do not have any working bzr infrastructure so can't check myself
[13:10] <jelmer> hi AuroraBorealis, cheater_
[13:11] <cheater_> hi jelmer
[13:12] <AuroraBorealis> it seems a lightweight checkout
[13:12] <AuroraBorealis> just doesnt have a .bzr/repository folder
[13:14] <cheater_> heh
[13:15] <cheater_> all the source trees have that
[13:15] <cheater_> funny!
[13:16] <jelmer> AuroraBorealis: right, the point of a lightweight checkout is that is uses a branch/repository that is located elsehwere
[13:16] <AuroraBorealis> yeah
[13:16] <AuroraBorealis> he just lost his remote repository
[13:16] <AuroraBorealis> but since none of his source trees are lightweight, they should still have all the history
[13:16] <AuroraBorealis> up to the point from when they were last updated / merged / whatever
[13:17] <jelmer> cheater_: what's the problem you're trying to solve exactly?
[13:17] <cheater_> yeah there is actually no discrepancy in what commits they contain
[13:17] <cheater_> as in all the source trees are up to date
 i did a heavyweight branch just before the central server got hit by a meteorite
[13:17] <AuroraBorealis> thats his problem
[13:17] <AuroraBorealis> :>
[13:18] <cheater_> jelmer: i have been working on a single-person project with just one main branch, using a "centralized" workflow with a bzr repo being available via sftp off a server, and a local checkout on my home computer
[13:18] <cheater_> the server doesn't exist anymore
[13:18] <cheater_> i want to resume my work
[13:18] <jelmer> cheater_: you should be able to unbind your local branch, if it was a heavyweight checkout
[13:18] <cheater_> just before the server went away i came in here anticipating it, and you guys told me to do some specific kind of checkout or branch
[13:18] <cheater_> i guess you told me to do a branch
[13:18] <cheater_> so i did
[13:19] <cheater_> ok how do i do that jelmer?
[13:19] <AuroraBorealis> bzr unbind probably
[13:19] <cheater_> let me try that then
[13:19] <jelmer> cheater_: if it's a heavyweight checkout, then "bzr unbind" should work
[13:20] <cheater_> let me just make a copy of that dir
[13:21] <cheater_> nice
[13:21] <cheater_> i just added a file and committed
[13:21] <cheater_> Committed revision 42.
[13:22] <cheater_> funny thing given that i started reading the hitchhiker trilogy lately..
[13:22] <cheater_> ok, great!
[13:22] <AuroraBorealis> =P
[13:23] <cheater_> and branching works too
[13:23] <cheater_> amazing
[13:23] <cheater_> thanks a lot guys
[13:24] <AuroraBorealis> :D
[13:24] <cheater_> there might still be some life left in this project
[13:24] <AuroraBorealis> back it up again though :>
[13:25] <cheater_> yeah it's backed up
[13:25] <cheater_> raid is backup, right?
[13:26] <sjamaan> Hi. I'm trying to find the bzr library API.  The link in the manual points to http://starship.python.net/crew/mwh/bzrlibapi/ but that's empty
[13:26] <sjamaan> Anywhere else I can look?
[13:26] <AuroraBorealis> well i meant on another server =P
[13:26] <cheater_> AuroraBorealis: heheh, i was just kidding.
[21:50] <gutworth> is there some option I can pass to disable the progress bar?
[22:49] <beuno> gutworth, I think -q may do it
[22:57] <gutworth> mm, too bad it's not global
[23:00] <bob2> isn't there an env var?
[23:05] <gutworth> BZR_PROGRESS_BAR beautiful
[23:56] <Noldorin> hey wgz
[23:56] <Noldorin> err, mgz :-)
[23:59] <mgz> I'm... not really still awake


[08:28] <Ady2> I downloaded lubuntu-15.04-alternate-i386.iso. Inside it, I see 'install/netboot/ubuntu-installer/i386/pxelinux.cfg', but it is empty. I also see 'install/netboot/ubuntu-installer/i386/pxelinux.0' (not under the 'pxelinux.cfg' subdir) but there is no ldlinux.c32 in the same directory (so pxelinux.0 would fail to find it). Is there any place where I can find info about this (e.g. relevant package, or how to use
[08:28] <Ady2>  / what's the goal of this directory and its subdirs.)? I cannot make sense of these subdirs. Should they be included in this iso image at all? What for? Is this some kind of bug?
[11:26] <Kamilion> Not sure, Ady2
[11:26] <Kamilion> I've had a number of small issues with mismash files on some of the ISOs
[11:27] <Kamilion> for example, mboot.c32 is also AWOL
[11:27] <Kamilion> or was, at least
[11:28] <Ady2> Kamilion: I am investigating it. I have a hunch this is sth related to debianinstall or related package. I would like to know where are these files and directories coming from. I don't have a problem of mismatch versions, just that there should be one additional file in there (which is located in a different subdirectory).
[11:29] <Kamilion> by mishmash I mean that some files are present and others are missing. Seems mostly syslinux/isolinux/pxelinux modules.
[11:30] <Kamilion> I couldn't be tossed to figure it out, so I just threw mboot.c32 in there myself. (i needed it to load xen)
[11:31] <Ady2> I also don't know why the files are not under 'pxelinux.cfg/', but first I guess I should find where are these files and structure originated. Yes, they are from Syslinux, but the structure is not from Syslinux upstream. Someone else (debianinstaller?) puts them there.
[11:32] <Ady2> And finally, I would like to know why they are included in the iso. How they are supposed to be used, under which scenario, why we need additional syslinux files, and additional kernel and initrd.
[11:32] <Kamilion> last time I looked into the matter I was lead to https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/bin/cron.daily-live
[11:34] <Kamilion> in your case it would have been https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/bin/cron.daily
[11:35] <Kamilion> this is apparently the mechanism that actually makes the ISOs
[11:44] <Kamilion> I'm still trying to grasp how everything works for a .seed to end up as a built ISO set
[11:49] <Kamilion> I hit a brick wall at https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/lib/cdimage/livefs.py#L166
[11:52] <Kamilion> it looks like that's the point where it goes off and runs the package builds needed to end up on disc
[11:56] <Kamilion> but deeper in there is where it grabs the build artifacts, including all of the files. https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/lib/cdimage/livefs.py#L706
[11:57] <Kamilion> s/all of the files/all of the boot files/i
[12:44] <Ady2> Considering http://cdimage.debian.org/debian/dists/jessie/main/installer-i386/current/images/netboot/ this has to be originated somewhere in debian too, perhaps in the d-i-netboot-assistant package. But then it goes to ubuntu and then to lubuntu too. So the Q is, is there someone here that can give some clue?
[12:45] <Ady2> The equivalent to what it is seen inside the iso  is http://cdimage.debian.org/debian/dists/jessie/main/installer-i386/current/images/netboot/debian-installer/i386/
[12:52] <Kamilion> yeah, someone'll show up with more knowledge of history than I
[12:53] <Kamilion> So do your best to explain the situation now and someone'll read the scrollback.
[12:55] <Kamilion> at the very least, someone will tell you which package the bug report should get filed on.
[12:57] <Ady2> I don't have a situation. I am trying to understand why all these subdirectories and files are included in the iso, and I know Syslinux enough so to understand that, for whichever goal these have been included, they still need ldlinux.c32 together with pxelinux.0, or it will fail in whichever situation these files and directory structure could be needed.
[13:02] <Kamilion> my guess would be filing a bug against syslinux or d-i. I know the relevant files exist in the built package. Why they don't arrive on the media? *shrug* Someone here probably knows when they wake and read the scrollback.
[13:03] <Kamilion> only certain files are copied, according to some rule during ISO generation. Where that lives; I'm still trying to find out.
[13:03] <Kamilion> If you happen to find out -- let me know, so I can request mboot.c32 too
[13:04] <Kamilion> I've got to go get some sleep; but I didn't want you to leave thinking you were ignored.
[13:04] <Ady2> TY. FWIW, the ldlinux.c32 is there, but in the wrong subdir.
[13:05] <Kamilion> well, either way, it's not something that can be fixed; the release has came and gone and the ISOs are already mirrored worldwide
[13:05] <Kamilion> so it will have to be fixed for 15.10
[13:21] <Ady2> The problem is also described at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750586#90 , expect that the bug is not upstream Syslinux, but in Debian, in some package related to DebianInstaller (and my guess is that such package is netboot-assistant). It doesn't answer my doubt though, why are these files and directory structure included in the iso (I mean, what for)?
[13:27] <Kamilion> ... Huh.
[13:28] <Kamilion> yeah, THAT issue sounds like an upstream bug in syslinux (re: pxelinux.0 not respecting ldlinux.c32's path)
[13:29] <Kamilion> something has changed recently
[13:29] <Kamilion> ~march/april
[13:32] <Ady2> I repeat, the bug is not in Syslinux itself, but in Debian. The fact that users report something being upstream because they happen to find that a prior version works doesn't mean their conclusions are correct.
[13:36] <Kamilion> In general, regressions are A Bad Thing, in my opinion.
[13:36] <Ady2> The fact that the reporter in msg #90 just copies ldlinux.c32 to the "right" location (as per Syslinux expects it) and it works actually shows that the problem is the location in which the Debian package is putting the files. Whether it is one file that needs relocation (ldlinux.c32), or the whole structure is inadequate, I don't know). The package (netboot-assistant) is not maintained (correctly).
[13:38] <Ady2> This is not exactly a regression. It just needs further modifications in addition to whatever they did during the last months.
[13:38] <Kamilion> I understand your sentiment.
[13:40] <Kamilion> In general from the deployments I've seen, most PXE setups tend to be site-specific, and customized to a high degree.
[13:42] <Kamilion> A great many of the ones I've recently interacted with have moved over to using iPXE and loading files from a protocol newer than TFTP, such as HTTP or HTTPS.
[13:43] <Kamilion> and the last time I checked, that process currently doesn't need pxelinux.0
[13:44] <Kamilion> so my observation is that it may be not be maintained (correctly) due to people moving on to a more modern solution.
[13:44] <Kamilion> leading to things like pxelinux.0 not getting as much testing as it once did; where people would cry out when something changed for the worse.
[13:46] <Ady2> Sure, I understand. Well, v.5 added lpxelinux.0 already, but that's not my point here. For whichever reason, this directory structure is included in the iso, and I really would like to know what's its purpose.


[13:15] <combinatoric> I'm up and running ubuntustudio and would like to participate in some development
[13:15] <combinatoric> let me know something I can start with
[13:18] <zequence> combinatoric: Right now we're preparing for release, which is in about a month, and we're just testing the beta. http://cdimage.ubuntu.com/ubuntustudio/releases/13.04/beta-1/
[13:19] <zequence> combinatoric: Get yourself a launchpad account, if you haven't https://launchpad.net/
[13:19] <zequence> combinatoric: What we want to test specifically right now is doing upgrades from 12.10 to 13.04
[13:19] <combinatoric> ok gotcha
[13:20] <combinatoric> I just got 12.04 installed I'm downloading 12.10 now and going to reinstall
[13:20] <zequence> There are two ways. Either by using the installer DVD - it should appear as one of the install options (keep home, just update release), or you use the script do-release-upgrade from 12.10
[13:20] <combinatoric> ok what about upgrading from 12.04 to 12.10
[13:21] <zequence> You can do that too, if you want to
[13:21] <zequence> sudo do-release-upgrade
[13:21] <combinatoric> ok I will try
[13:21] <zequence> subscribe to our -devel mail list, if you haven't
[13:21] <zequence> https://lists.ubuntu.com/mailman/listinfo/Ubuntu-Studio-devel
[13:22] <combinatoric> already have
[13:22] <zequence> combinatoric: About testing upgrades https://lists.ubuntu.com/archives/ubuntu-studio-devel/2013-March/004982.html
[13:23] <zequence> In short, it would be nice if your install is as clean as possible (no other desktop systems side by side, etc)
[13:24] <zequence> And that you've made some user setting changes. Changes in the panels, menu, things like that
[13:24] <zequence> We want to see if an upgrade from Ubuntu Studio -> Ubuntu Studio works ok or not, and if that is something we should recommend for people to do


[02:14] <Guest54502> hey i am looking for a development environment for yunit, and something with qt 5.8. Does 17.10 have qt 5.8 as well as some of the unity 8 development packages?
[02:22] <tsimonq2> akiva-thinkpad: Hey there :)
[02:23] <tsimonq2> akiva-thinkpad: Ubuntu skipped Qt 5.8 because it was a bit of a buggy release. I'm actually working with mitya57 to get Qt 5.9 in the archive, so that should be there within the next month.
[02:23] <tsimonq2> akiva-thinkpad: As for Yunit, they don't have that in the archive, as they've removed Unity 8. So you'll have to ask the Yunit folks on that one.
[02:23] <tsimonq2> akiva-thinkpad: Hope this helps :)
[04:32] <akiva-thinkpad> tsimonq2, that helps perfectly. thank you.
[17:15] <tjpnz> Hi
[17:16] <tjpnz> Is it possible to test drive the upcoming Ubuntu version that _won't_ have Unity?