[04:16] <mup> Bug #1652262 changed: subiquitycore exception in controller.run <snappy> <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1652262>
[04:51] <mup> PR snapcraft#1552 opened: tests: replace the mosquitto demo test with a snapd integration test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1552>
[07:25] <mvo> ppisati: could you please trigger a new kernel build for edge? I pushed a bugfix for ubuntu-core-initramfs-tools recently
[07:35] <mvo> ogra_: you showed me a bunch of empty revision dirs under /snap/core some days ago (iirc). could you pastebin that again? I was looking into this this morning but I haven't managed to reproduce it yet (and the code seems to be doing the right thing). so I'm curious to learn more how this is happening
[07:38] <mvo> zyga-ubuntu: I wonder if we need to look at the issue that we need to make /snap shared again for lxd. iirc there was this issue that the mounts happen before we run snap-confine for the first time to do the shared mount magic
[07:38] <mvo> zyga-ubuntu: you wanted to look if we can do something with namespace, we may need a brute force approach with an early mount unit
[07:44] <zyga-ubuntu> mvo: right, I was thinking about it last night; I wanted to mention that it also happens on 14.04 so it's relateively easy and painless to interate on
[07:44] <zyga-ubuntu> mvo: I haven't had the time to try though, I'm iterating on the feedback from jamie now
[07:48] <mvo> zyga-ubuntu: ok - my approach would be a mount unit similar to the one we have in 14.04 - but that is very heavy handed and may get tricky as we need to run it after /snap is mounted but before anything under /snap/* is squashfs mounted, so the right before= is tricky
[07:49] <mvo> zyga-ubuntu: also please check https://github.com/snapcore/core-build/pull/21 and https://github.com/snapcore/core-build/pull/22 if you have a moment, should be painless
[07:49] <mup> PR core-build#21: Release 0.7.43+ppa23 <Created by mvo5> <https://github.com/snapcore/core-build/pull/21>
[07:49] <mup> PR core-build#22: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
[07:49] <zyga-ubuntu> mvo: maybe we need After on actual units?
[07:49] <zyga-ubuntu> (mount units we create)
[07:49] <zyga-ubuntu> mvo: ok
[07:50] <mvo> zyga-ubuntu: yeah, that would work I think, we just need to make sure we rewrite existing ones (I don't think we do this currently)
[07:50] <zyga-ubuntu> mvo: no, we don't
[07:51] <zyga-ubuntu> mvo: I'd strongly enourage us to try SyncDir thing for that
[07:51] <davidcalle> sergiusens: hey, so you know, we are still following up on the deployment of the latest dn, I'll ping you when it's resolved
[07:51] <mup> PR core-build#21 closed: Release 0.7.43+ppa23 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/21>
[07:51] <zyga-ubuntu> mvo: as it has the "ensure" property of patching up broken state
[07:52]  * mvo nods
[07:53] <zyga-ubuntu> mvo: the tests look ok, I'm wondering if you tried using the VM-based tests that would run this in the real initrd
[07:54] <mvo> zyga-ubuntu: I did, but got stuck seting up the right environment for this
[07:54] <zyga-ubuntu> mvo: I see, what was the main difficulty?
[07:54] <mvo> zyga-ubuntu: also travis is broken since the VM based tests got merged, I'm looking at this right now
[07:54] <zyga-ubuntu> mvo: oh? It passed earlier
[07:54] <zyga-ubuntu> mvo: (I mean, it did go green before this was merged)
[07:55] <mvo> zyga-ubuntu: maybe I did not try hard enough, but I need to simulate the /writable and core snap changes so that sync dir can be tested, setting up changes in the core snap in /etc was were I got stuck
[07:56] <zyga-ubuntu> test init process did not signal boot-ok
[07:56] <mvo> zyga-ubuntu: please check https://travis-ci.org/snapcore/core-build/builds
[07:56] <mvo> zyga-ubuntu: maybe coincidence, I just started looking at this
[07:57] <mvo> zyga-ubuntu: aha, did you retrigger it?
[07:57] <mvo> zyga-ubuntu: the first actual failure is much later in #41
[07:57] <mup> PR #41: add X-Ubuntu-Wire-Protocol to the headers <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/41>
[07:57] <pedronis> core#41
[07:57] <mup> PR core#41: limit the version string to 32chars (this is what the store allows) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/41>
[07:57] <zyga-ubuntu> mvo: I re-started older test jobs that got cancelled
[07:57] <mvo> zyga-ubuntu: and please don't get me wrong, the iqemu tests are nice, just seems to be not nice for my particular test
[07:57] <zyga-ubuntu> mvo: we'll see when it stated failing (hopefully)
[07:58] <mvo> zyga-ubuntu: aha, nice
[07:58] <mvo> core-build#41
[07:58] <zyga-ubuntu> mvo: no worries, I just wanted to understand what was hard. I agree that it would be easier to do some of those tests with more of the system around (writable disk or SD card)
[07:58] <mvo> thanks pedronis, looks like mup does not know about core-build
[07:59] <mvo> zyga-ubuntu: I also looked briefly at the gpt regression bug and how to test that but that looks really tricky to unit test :(
[07:59] <mvo> zyga-ubuntu: *but* I think we should have a spread test for this, I will ponder a bit how to test it
[07:59] <zyga-ubuntu> mvo: yes
[07:59] <zyga-ubuntu> mvo: I think both would not hurt :)
[07:59] <mvo> +1
[08:00] <mvo> zyga-ubuntu: silly question, but do you know why the tests did not run on core-build?
[08:01] <mvo> (or why they were canceled)
[08:01] <zyga-ubuntu> mvo: no, no idea
[08:02] <zyga-ubuntu> mvo: I just did a test on my machine, clean tree, VM tests passed
[08:02] <zyga-ubuntu> mvo: everything does fail with: test init process did not signal boot-ok
[08:02] <zyga-ubuntu> mvo: let me push a pr that runs tests in verbose mode
[08:05] <zyga-ubuntu> mvo: hmmmm, why there's no travis here: https://github.com/snapcore/core-build/pull/23 ?
[08:05] <mup> PR core-build#23: tests: treat --verbose as -v <Created by zyga> <https://github.com/snapcore/core-build/pull/23>
[08:05] <mup> PR core-build#23 opened: tests: treat --verbose as -v <Created by zyga> <https://github.com/snapcore/core-build/pull/23>
[08:06] <zyga-ubuntu> ah, it just showed up
[08:07] <mvo> zyga-ubuntu: interessting
[08:08] <ppisati> mvo: i guess, every kernel
[08:09] <zyga-ubuntu> mvo: https://travis-ci.org/snapcore/core-build/builds/275784391?utm_source=github_status&utm_medium=notification ??!
[08:10] <mvo> zyga-ubuntu: "test init process did not signal boot-ok" - at least it is concistent, ie #27 also failed with the same error
[08:11] <mvo> zyga-ubuntu: is it supposed to show more output? maybe its just slow? how much time does it have for this signal?
[08:11] <zyga-ubuntu> mvo: I found the issue
[08:12] <mvo> ppisati: thank you, please let me know when new edge kernel is available and I will test right away
[08:12] <zyga-ubuntu> https://travis-ci.org/snapcore/core-build/builds/275784391#L2178
[08:12] <zyga-ubuntu> mvo: fixing that now
[08:13] <zyga-ubuntu> mvo: cpio was in the middle of a pipe so the erorr was silent
[08:13] <ppisati> mvo: ack
[08:13] <zyga-ubuntu> mvo: I pushed it back to my PR
[08:18] <zyga-ubuntu> mvo: it passed now
[08:19] <zyga-ubuntu> mvo: so whatever caused cpio to get yanked from the image we chroot into won't affect us anymore
[08:19] <zyga-ubuntu> mvo: please merge https://github.com/snapcore/core-build/pull/23 for happiness
[08:19] <mup> PR core-build#23: tests: treat --verbose as -v <Created by zyga> <https://github.com/snapcore/core-build/pull/23>
[08:23] <phil_m> @zyga-suse, @zyga-ubuntu, @zyga: great accomplishment with Manjaro and Snappy
[08:23] <nothal> phil_m: No such command!
[08:24] <zyga-suse> phil_m: I'm still working on opengl support but snapd proper works ok
[08:24] <phil_m> ok, so what was the problem?
[08:25] <phil_m> if some is needed to be changed within the kernel, we can do that also
[08:25] <zyga-suse> phil_m: so far none, the patch I cherry picked had different sum than the one from the URL, maybe it was corrupt there?
[08:25] <zyga-suse> phil_m: would you be interested in cherry-picking apparmor support into the manjaro kernel like solus did?
[08:25] <phil_m> ah ok.
[08:25] <zyga-suse> phil_m: this would give you apparmor confinement
[08:26] <phil_m> I've to see about appamor
[08:27] <zyga-suse> phil_m: the patch against 4.14 should be small now, 4.15 will have everything but I think we missed the window with some patches
[08:28] <zyga-suse> phil_m: do you have the apparmor userspace tools packaged?
[08:29] <phil_m> well, we had apparmor in our distro but removed it: https://github.com/manjaro/packages-core/issues/49
[08:29] <mvo> zyga-suse: ta
[08:29] <zyga-suse> phil_m: I see I have to add one more patch to cmd.go,
[08:29] <mup> PR core-build#23 closed: tests: treat --verbose as -v <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/23>
[08:30] <phil_m> since you have full write access to our community packages git repo you can also add the needed patches directly if you like.
[08:31] <zyga-suse> phil_m: thank you, should I discuss this with other manjaro developers before proposing PRs?
[08:32] <phil_m> na, not needed
[08:32] <zyga-suse> phil_m: thank you, I'll plan what is the best course of action
[08:32] <phil_m> we are open and since you know better about snapd you can push it directly
[08:32] <phil_m> however one of our maintainers has to package it.
[08:32] <zyga-suse> phil_m: please stick around and let's chat periodically about what else might be needed
[08:32] <phil_m> sure, no problem in that.
[08:33] <zyga-suse> phil_m: that's great, I'd love to co-maintain the package if that's okay
[08:33] <phil_m> sure, why not. we have to see how we can do that properly.
[08:33] <zyga-suse> phil_m: and if the main packager could be here or on the forum (or both) for release coordination, that would be perfect
[08:34] <phil_m> you can always ping me via email if needed or write in github that a new release needs to be packaged
[08:34] <zyga-suse> phil_m: thank you! I'll definitely stay in touch
[08:34] <phil_m> it should be packaged then on the same day with a small delay
[08:35] <phil_m> since we are not Arch we are more open for new packages if they make sense.
[08:35] <zyga-suse> yes, we have a release cycle that has a moment when the package is in testing and once we are happy across the spectrum of systems we mark it as stable
[08:35] <zyga-suse> thank you :-)
[08:35] <phil_m> we also have some kind of release cylce with each package. we use branches and move them when ready to the next one.
[08:36] <zyga-suse> where can I read about that?
[08:37] <pedronis> I noticed we never marked this  https://forum.snapcraft.io/t/interface-connection-from-gadget-in-firstboot/1431 as backlog, fixed now
[08:37] <phil_m> more or less in our forum or wiki
[08:37] <phil_m> https://wiki.manjaro.org/index.php?title=Repositories_and_Servers
[08:37] <phil_m> testing gets updated mostly every second day.
[08:37] <phil_m> unstable daily and stable in weekly basis
[08:41] <zyga-suse> phil_m: I think this matches snapd release cycle well, we are trying to (still trying though) make a reliable mothly cycle
[08:42] <phil_m> https://manjaro.github.io/homepage/public/features/background/
[08:42] <phil_m> this is a simply page explaining how we manage our packages
[08:43] <pedronis> mvo: let me when you want to chat about what's left for repairs
[08:48] <mvo> pedronis: I'm finishing a small branch, then I should be ready so ~30min or so (depending a bit on how tests look)
[08:49] <phil_m> zyga-suse: looking good so far according to your screens ;)
[08:49] <pedronis> mvo: ok
[08:49] <zyga-suse> yes :)
[08:49] <zyga-suse> phil_m: though I need to investigate two things before I call it good
[08:50] <phil_m> na, no pressure
[08:50] <phil_m> take all the time you need
[09:03] <ogra_> mvo, http://paste.ubuntu.com/25539231/
[09:05] <mvo> ogra_: and all empty except the last ~3 ones, right?
[09:05] <mup> PR snapd#3920 opened: snap-confine: improve error message if core/u-core cannot be found <Created by mvo5> <https://github.com/snapcore/snapd/pull/3920>
[09:07] <zyga-ubuntu> mvo: nice, thank you
[09:07] <mvo> zyga-ubuntu: thanks for the quick review!
[09:08] <zyga-ubuntu> darn
[09:08] <ackk> mvo, hi, I'm not really  sure what failed on https://github.com/snapcore/snapd/pull/3916, is it just flakiness in tests setup?
[09:08] <mup> PR #3916: add support for socket activation in apps <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
[09:09] <zyga-ubuntu> a bird just landed next to my window and I even have a camera standing by for that occasion but it ... flew away before I got the shot
[09:18] <mvo> ackk: yeah, the test failure looks not related to your code
[09:18] <ackk> mvo, can you restart just that build? or it doesn't matter for the review?
[09:18] <mup> PR snapcraft#1553 opened: lxd: instructions for /etc/sub{u,g}id after failed start <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1553>
[09:22] <ashwind> Hey, I see that GPIO pins cannot be accessed via a snap. Is this correct? I have a sensehat (https://www.raspberrypi.org/products/sense-hat/) connected a Pi3 via GPIO pins. I would like to obtain readings from those sensors via a python application. If this possible with a python app captured in a snap?
[09:24] <zyga-ubuntu> ashwind: hey, is your snap using the right interfaces? is it a service running as root or a command running as your user?
[09:25] <ashwind> I haven't fully implemented to snap yet.
[09:25] <ashwind> I just saw that gpio pin access is restrcted
[09:25] <ashwind> https://snapcraft.io/docs/reference/interfaces
[09:26] <zyga-ubuntu> ashwind: using the right interface you can definitely use GPIOs
[09:26] <ashwind> oh awesome, please advise
[09:26] <zyga-ubuntu> ashwind: the way this works is that a given snap can be given rights to use a restricted interface
[09:26] <zyga-ubuntu> ashwind: implement your snap as you would normally
[09:27] <ashwind> ok done
[09:27] <zyga-ubuntu> ashwind: installation instructions for a given device should show how to connect the right GPIO pins correctly
[09:27] <zyga-ubuntu> ashwind: for specific devices this will be available as a gadget feature (the gadget can pre-connect things correctly)
[09:27] <zyga-ubuntu> ashwind: auto-connect is not that useful for GPIOs because there are typically plenty of them
[09:28] <zyga-ubuntu> (and you get access to specific pins, not to all of them in general)
[09:28] <zyga-ubuntu> and because this differs from device to device and auto-connect logic is not smart enough to know which one is the right one
[09:32] <ogra_> mvo, yeah
[09:33] <ogra_> mvo, well, actually *all* empty ...
[09:34] <mvo> ogra_: hm? even current?
[09:34] <ogra_> yes
[09:35] <ogra_> ogra@anubis:~/datengrab/pi3$ sudo ls -l /root/snap/core/current
[09:35] <ogra_> lrwxrwxrwx 1 root root 4 Sep 13 22:59 /root/snap/core/current -> 2925
[09:35] <ogra_> ogra@anubis:~/datengrab/pi3$ sudo ls -l /root/snap/core/current/
[09:35] <ogra_> insgesamt 0
[09:35] <mvo> ogra_: ok, so there is something else going on, that explains why I can't reproduce it probably
[09:36] <ogra_> thhis system has been usinng snaps since day one, but there is no ubuntu-core dir theer
[09:36] <mvo> ogra_: and this is on the running system?
[09:36] <ogra_> thats my desktop macine
[09:36] <ogra_> *machine
[09:37] <mvo> ogra_: ohhhh, these are your data dirs
[09:37] <ogra_> (so yes)
[09:37] <mvo> ogra_: sorry, I misunderstood
[09:37] <ogra_> right
[09:37] <ogra_> well ... roots data dirs
[09:37] <pedronis> didn't we have a complicated discussion about removing those
[09:37] <ogra_> not hamful, just wasting inodes ... but still ugly
[09:38] <pedronis> they are not easy to find across distros
[09:38] <pedronis> and root indeed in a special case
[09:38] <pedronis> I think we look only for /home/* atm
[09:38] <ogra_> you mean /root isnt root in soome distros ?
[09:38] <pedronis> no that homedirs are not quite in the same place
[09:38] <ogra_> (why do we even create them ?)
[09:39] <ogra_> are they relevant for anything ?
[09:39] <pedronis> probably they get created when we run the configure hook?
[09:39] <ashwind> zyga-ubuntu: so i implemented my snap to be of type "app", do i need to change it to "gadget"? I see a pi3-gadget git repo https://github.com/snapcore/pi3-gadget/blob/master/snapcraft.yaml, how does this relate?
[09:39] <ogra_> i dont think core would ever wite to them
[09:39] <pedronis> or maybe we are not lazy at all
[09:39] <pedronis> don't remember
[09:41] <pedronis> mvo: I'm around if you want to chat btw, let me know
[09:41] <ogra_> looking at /root/snap core os the only snap with that behaviur
[09:41] <ogra_> *core is
[09:41] <mvo> pedronis: yeah, one minute and I'm ready
[09:42] <pedronis> ogra_: I suspect it's a consquence of running the configure hook
[09:42] <ogra_> all other packages remove the dirs on uninstall/refresh
[09:42] <pedronis> atm
[09:42] <ogra_> might be that this is what creates them ... but the bug seems to be in te emove code
[09:42] <ogra_> *remove
[09:42] <pedronis> as I said  the remove code does only /home/*/snap/...
[09:43] <pedronis> afaik
[09:43] <pedronis> we discussed improving it
[09:43] <pedronis> but I think it was postponed
[09:43] <pedronis> and root ends up like this
[09:43] <ogra_> yeah, it isnt critical or anything
[09:43] <mvo> pedronis: I have a look, looks trivial to include /root as a speical case
[09:43] <mvo> even if not perfect
[09:49] <ashwind> zyga-ubuntu: hmm let me read up, thanks!
[09:50] <phil_m> zyga-suse: I'd to go. Keep me updated via email on the snappy progress on Manjaro. If needed I can package it, when done.
[09:57] <zyga-ubuntu> re
[09:58] <zyga-ubuntu> ashwind: no, you should keep your snap as "app"
[09:58] <zyga-ubuntu> sorry i was on the phone
[10:07] <ogra_> hmm, do we have any dir in /run that a dameon can write to and that i can see as normal user ?
[10:08] <zyga-ubuntu> ogra_: $XDG_RUNTIME_DIR perhaps but not sure
[10:10] <ogra_> zyga-ubuntu, well, that seems tio be hidden from the otside world (or being deleted when i exist "snap run --shell"
[10:10] <ogra_> )
[10:11] <ogra_> but i found a solution ...
[10:39] <ogra_> zyga-ubuntu, your initrd tests make everything in core-build explode ...
[10:39] <ogra_> $ $CHROOT_RUN sh -c 'cd build/initramfs/testing; LC_ALL=C.UTF-8 ./aaa-tests.py --verbose'
[10:39] <ogra_> warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
[10:39] <ogra_> test init process did not signal boot-ok
[10:44] <ackk> mvo, so one thing I'm not totally sure about that PR for socket activation is whether it's better to keep the socket-mode as a string or an integer
[10:44] <mvo> ogra_, pedronis: fwiw, I am poking a bit at the user data thing for root/ and I think I'm on a good course
[10:44] <ogra_> yay
[10:45] <ackk> mvo, declaring it as an int in the snapcraft schema makes it render in the snap as decimal, not octal
[10:45] <mvo> ackk: yeah, I would prefer a string for this reason, unless there is yaml magic to make it render in the natural 0xxx notation
[10:46] <ackk> mvo, ok, then I can just revert the last commit (I had initially it as a string)
[10:46] <mvo> ogra_: I think its even buggy in the forward-data copy case for root :/ anyway, I am looking
[10:46]  * zyga-ubuntu -> lunch
[10:46] <mvo> ackk: sounds good, we will also need input from niemeyer on your socket activation PR as it touches the yaml and we need sign off for that :)
[10:46] <zyga-ubuntu> ogra_: pull master
[10:47] <zyga-ubuntu> ogra_: it was fixed now
[10:47] <ackk> mvo, ok
[10:48] <ogra_> zyga-ubuntu, well, i'm looking at master tests ... but if it is fixed now it is fine
[10:49] <ogra_> zyga-ubuntu, mvo how did you guys get travis to do anything again ? it hasnt even started tests for a while
[10:50] <zyga-suse> ogra_: it started instantly for me
[10:50] <zyga-suse> ogra_: no idea
[10:50] <zyga-suse> ogra_: maybe it hasn't been merged, there should be a PR open
[10:50] <zyga-suse> ogra_: please look, I'm trying not to starve today
[10:50] <ogra_> well it timed uot waiting fr starting the tests fr like 2 months now
[10:51] <ogra_> unrealated to the tests ... travis never started at all
[10:51] <ogra_> so someone has done something too make travis actually start again
[10:51] <zyga-suse> ogra_: I started about a dozen jobs on core-build today
[10:52] <ogra_> zyga-suse, right i did that nce a week for the last few weeks but travis only timed uot before even starting
[10:52] <ogra_> something has changed that suddenly allows it to run tests again ... did we pay extra $$$ ?
[10:52] <zyga-suse> nope, perhaps just smaller load
[10:53] <ogra_> well, then better watch snapd now ... if it is load related we migth steal cycles from other snapcore trees
[10:53] <ogra_> :)
[10:54] <ogra_> (this is not what i understand as reliable CI :P )
[10:55] <zyga-suse> free, reliable, nice,
[10:55] <zyga-suse> pick two
[10:55] <ogra_> haha
[11:08] <mup> PR snapd#3866 closed: many: implement fetching sections and package names periodically <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3866>
[11:08]  * Chipaca dances
[11:08] <Chipaca> also, glad to have been into london yesterday and not today
[11:08]  * Chipaca dances a bit more
[11:14]  * zyga-ubuntu hugs Chipaca
[11:14] <zyga-ubuntu> barbaric times we live in
[11:25]  * zyga-ubuntu resumes coding
[11:47] <ackk> mvo, updated that PR, fwiw
[11:54] <pedronis> mvo:  added a couple comments, some we already discused to the snap-repair list/show PR
[12:03] <ogra_> zyga-ubuntu, mvo, can we agree that "release" PRs in core-build simply get merged (i saw you guys did an actual review, i think this is pointless given it is only a changelog entry, the actual changes have been reviewed before anyway)
[12:03] <ogra_> (and if the changelog is broken the loacla dpkg-buildpackage would error anyway and you couldnt upload)
[12:03] <ogra_> *local
[12:04] <ogra_> i.e. https://github.com/snapcore/core-build/pull/21
[12:04] <mup> PR core-build#21: Release 0.7.43+ppa23 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/21>
[12:04] <ogra_> (reviews just waste time here IMHO)
[12:05] <ogra_> indeed only if it is just the changelog bump :)
[12:06] <zyga-ubuntu> ogra_: well, I think it's good for spotting typos but I agree in general; given that those should be reviewed very quickly I wouldn't change much thoug
[12:07] <ogra_> well, lets say they are "optional" then :)
[12:11] <cachio> mvo, hi
[12:11] <cachio> in rc3 it is failing to uninstall the network-manager
[12:11] <cachio> for db and pi3
[12:12] <cachio> I can reproduce it running test tests/regression/lp-1606277 and then any other test
[12:13] <mvo> cachio: thanks, what is the error output?
[12:14] <cachio> mvo, https://paste.ubuntu.com/25540183/
[12:14] <cachio> it works fine for example on pi2
[12:14] <cachio> but for pi3 and db we get the same error
[12:15] <ogra_> well, both have wlan
[12:15] <ogra_> while pi2 doesnt
[12:16] <ogra_> the log isnt really helpful since it only shows the final timeout after snap remove n-m
[12:16] <ogra_> did you check what happens when you manually install/configure/remove n-m on such a device ?
[12:16] <mvo> cachio: hm, I would bet syscall filtering related, could you paste the dmesg output?
[12:16] <cachio> mvo, give me 5 please
[12:16] <mvo> cachio: oh, hold on, its dying on rmeove, right?
[12:17] <cachio> mvo, yes
[12:17] <mvo> cachio: in this case ogra_ may have a better theory, still the dmesg/syslog output will be helpful
[12:17] <ogra_> i guess it cant deconfigure the wlan device properly
[12:18] <mvo> cachio: also, does reverting core fix it? wonder if it might be n-m related but the last stable is ~5 weeks old it seems so that is unlikely
[12:20] <cachio> mvo, give me 5 please, I am running the tests with -debug
[12:21] <mvo> cachio: thank you, no rush :)
[12:24] <mup> PR snapd#3921 opened: interfaces: updates for default, browser-support, desktop, opengl, upower and stub-resolv.conf <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3921>
[12:26] <jdstrand> mvo: fyi, ^
[12:26] <jdstrand> mvo: and hi! :)
[12:28] <mvo> jdstrand: nice, thank you. and good morning!
[12:35] <cachio> mvo, dmesg https://paste.ubuntu.com/25540261/
[12:37] <cachio> ogra_, for you too :)
[12:40] <cachio> this is the syslog when the error happened https://paste.ubuntu.com/25540285/
[12:47] <ogra_> cachio_, can we get the full syslog without the tail -50 ?
[12:48] <cachio_> yes
[12:48] <ogra_> "Failed to initialize control interface '/run/wpa_supplicant'.#012You may have another wpa_supplicant process already running or the file was#012left by an unclean termination of wpa_supplicant"
[12:48] <mup> PR #12: Bugfix/lp1480248 test reenable <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/12>
[12:48] <ogra_> that looks suspicious
[12:49] <ogra_> boo ... mup
[12:50] <mup> PR snapd#3922 opened: snapstate: deal with snap user data in the /root/ directory <Created by mvo5> <https://github.com/snapcore/snapd/pull/3922>
[12:51]  * Chipaca reads http://schd.ws/hosted_files/ossna2017/91/Linuxcon%202017%20NERF.pdf and doesn't know if he should show it to ogra_, or hide him from it
[12:52] <cachio_> ogra_, https://paste.ubuntu.com/25540337/
[12:53] <mvo> zyga-ubuntu: the error in 3920 is very confusing
[12:53] <mvo> zyga-ubuntu: no /snap/core/current on core
[12:53] <Chipaca> sergiusens: http://www.nbu.gov.sk/skcsirt-sa-20170909-pypi/
[12:53] <ogra_> cachio_, there you go ... the wlan got configured by systemd-networkd already (via some netplan setup i guess) ... i assume that is why n-m gets confused
[12:53] <Chipaca> sergiusens: could/should snapcraft warn about that?
[12:53] <mup> PR snapd#3923 opened: asserts,cmd/snap-repair: represent RepairID internally as an int <Created by pedronis> <https://github.com/snapcore/snapd/pull/3923>
[12:53] <pedronis> mvo: ^
[12:53] <zyga-ubuntu> mvo: are we hit by a bad build of core?
[12:55] <mvo> pedronis: nice
[12:55] <mvo> zyga-ubuntu: not sure, I try to reproduce now
[12:56] <sergiusens> Chipaca about what?
[12:57]  * sergiusens doesn't know who anyone is with lacking avatars ;-)
[12:57] <ackk> it is at all possible to install a lxd local snap? I get permission denied messages when it starts about reading /proc/self/attr/current and running aa-exec
[12:57] <ackk> (I did connect the lxd-support plug)
[12:58] <cachio_> ogra_, that could be the reason, do you need any other log'
[12:58] <cachio_> ''
[12:58] <cachio_> ?
[12:59] <ogra_> cachio_, well, not sure what to do here ... did your testing change that it leaves the wlan netplan config in place before installing nm where it didnt do that before or some such ?
[12:59] <ogra_> nothing should have changed on core or in n-m in that area in ages
[13:00] <Chipaca> sergiusens: about a list of evil fake/typo packages in pypi
[13:00] <cachio_> ogra_, no
[13:00] <Son_Goku> zyga-ubuntu: base-ish snaps for Fedora, openSUSE, and Mageia on demand: https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap/pipelines/11803392 :D
[13:06]  * zyga-ubuntu hugs Son_Goku
[13:06] <zyga-ubuntu> one small step for snap
[13:06] <Son_Goku> I need to rewrite the tool to use the DNF API instead of the CLI (better control over the solver)
[13:07] <Son_Goku> but it's a doing it
[13:08] <sergiusens> Chipaca oh, I think pip and PyPI itself should warn about that!
[13:11] <Son_Goku> zyga-ubuntu: note that it won't produce bootable core snaps either :(
[13:12] <ogra_> cachio_, as a hack/workaround you could simply try to remove the file in /run or kill wpa_supplicant before installing n-m or some such
[13:12] <ogra_> this is clearly not a use case we support (having two config mechanisms manage the same device)
[13:12] <ogra_> mvo, ^^^ ?
[13:14] <ogra_> it is either netplan or network-manager ... (netplan has a specific config option for this to hand off management of the device to n-m)
[13:18] <ogra_> https://wiki.ubuntu.com/Netplan has info about this
[13:19] <ogra_> you will need to switch the renderer option before installing n-m
[13:29] <mvo> ogra_: thanks, I was in a meeting. btw, PR with the fix for your /root/snap/ stuff is up. unfortunately it will not cleanup the past but at least it should stop doing so from now on (well, $now==when-it-gets-merged)
[13:30] <ogra_> mvo, well, it is just cosmetic anyway
[13:30] <mvo> ogra_: sort of, there is a real bug there too, the userdata of /root does not get copied forward on refresh - so its good that you brought it up
[13:31] <ogra_> heh, great
[13:31] <pedronis> mvo: I'm super confused,  in my branch go vet seems to think the RepairID() is still a string in some places but test pass
[13:32] <cachio_> ogra_, ok, i'll see how to rewrite that test in this case
[13:32] <cachio_> thanks
[13:32] <ogra_> cachio_, well, it shouold have failed before, interesting that it did not
[13:33] <ogra_> also ... the n-m snap should probably be fixed to not steal an already otherwise managed interface
[13:33] <cachio_> ogra_, perhaps it is a new test
[13:33] <cachio_> i'll research a bit on that
[13:33] <ogra_> ah
[13:34] <zyga-ubuntu> Son_Goku: bootable snaps are further down the line
[13:34] <zyga-ubuntu> Son_Goku: I would be happy with a working base
[13:56] <pedronis> mvo: niemeyer: I'm getting this (stalled run/no ouput):  https://travis-ci.org/snapcore/snapd/builds/275875794?utm_source=github_status&utm_medium=notification
[13:56] <pedronis> there is nothing super interesting in the PR
[13:58] <pedronis> afaict
[13:58] <mup> PR snapd#3924 opened: asserts,cmd/snap-repair: introduce a mandatory summary for repairs <Created by pedronis> <https://github.com/snapcore/snapd/pull/3924>
[13:58] <mvo> pedronis: strange, I saw this in some other PR recently too but it seems to be very rare
[13:58] <pedronis> mvo: I got it twice in a row
[13:59] <niemeyer> pedronis: Can't think of any reasonable reason
[14:00] <niemeyer> pedronis: Ah, now I can
[14:00] <niemeyer> pedronis: We have 100% utilization right now
[14:00] <niemeyer> pedronis: On Linode
[14:01] <niemeyer> Interestingly, a lot of machines are running for ~1h
[14:01] <niemeyer> Every machine I click, actually
[14:02] <niemeyer> This is below the halt timeout
[14:02] <niemeyer> And above what Travis would accept
[14:03] <niemeyer> Something strange happening with Travis...
[14:04] <niemeyer> "Ran for 5 hrs 29 min 42 sec"
[14:04] <niemeyer> I don't think that's true, somehow :)
[14:04] <ogra_> niemeyer, i have that since weeks for the less frequently changing trees like core-build and core ... it will eventually time out with no results
[14:05] <ogra_> (the tests dont even start)
[14:06] <niemeyer> https://usercontent.irccloud-cdn.com/file/wHpSvg9Y/image.png
[14:06] <ogra_> pedronis, see my discussion with zyga-ubuntu above (around 12:50)
[14:07] <ogra_> the verdict was:
[14:07] <ogra_> zyga-suse> free, reliable, nice,
 pick two
 haha
[14:07] <ogra_> :P
[14:07] <niemeyer> Definitely something bogus happening there.. look at this screenshot
[14:07] <niemeyer> It merged two independent runs together
[14:07] <ogra_> oh
[14:07] <ogra_> thats definitely more than i get
[14:07] <ogra_> it doesnt even produce a log
[14:08] <niemeyer> ogra_: These cases are generally Travis being busy
[14:08] <ogra_> looks more like a hang with the test itself somehow
[14:08] <niemeyer> ogra_: Either in general, or with our own project (too much activity, long queues)
[14:08] <ogra_> yeah
[14:09] <ogra_> one can usually work around by pulling the tree and PR into a user fork and have the tests run there then
[14:09] <ogra_> i guess it is because it is tied to the snapcore organization
[14:14]  * zyga-ubuntu -> coffee
[14:19] <niemeyer> pedronis: Something else is wrong.. found machines allocated by those stale Travis jobs.. they are there, allocated and sitting idle
[14:20] <niemeyer> I'm finding evidence that the machine was updating too
[14:21] <niemeyer> Installing things that spread requested, likely
[14:21] <niemeyer> Yeah..
[14:24] <niemeyer> The best theory at the moment is that there was overutilization, machines were taking a while to actually allocate, and that cause them to go over the 10 mins without output of Travis, which meant they were killed while the machines were allocated, which caused more overutilization, and the problem cycles
[14:25] <niemeyer> In a few minutes we'll over our 2h halt timeout threshold.. let's see what happens
[14:29] <ogra_> is anyone living close to the github datacenter so he could watch out for an atomic cloud ?
[14:36] <mup> PR snapd#3925 opened: snap-repair: implement `snap-repair {done,skip,retry}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3925>
[14:42] <niemeyer> If the theory above is confirmed, I think we should lower the halt timeout
[14:51] <niemeyer> No, something else must be causing those issues:
[14:52] <niemeyer> https://usercontent.irccloud-cdn.com/file/n6Bkt5zj/image.png
[14:52] <niemeyer> It froze mid-way through.. the only thing that might justify that is a bug in spread, or a bug in Travis
[14:53] <niemeyer> Spread would definitely display a warning if it was taking too long, and it's hard to believe that would happen in all 20 machines anyway, after they're already allocated
[14:53] <niemeyer> The fact we're getting this issue across multiple runs just now would hint at a problem on the infra side instead of Spread
[15:03] <mup> PR snapd#3926 opened: snap: implement `snap {repair,repairs}` and pass-through to snap-repair <Created by mvo5> <https://github.com/snapcore/snapd/pull/3926>
[15:05] <mup> PR snapd#3921 closed: interfaces: updates for default, browser-support, desktop, opengl, upower and stub-resolv.conf for 2.28 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3921>
[15:11] <mvo> cachio_: any news about the network-manager issue ? mostly curious
[15:11] <cachio_> mvo, no, ogra has a theory
[15:12] <cachio_> mvo, seems to be a conflict between network-manager and netplan
[15:13] <cachio_> mvo, if it is true, we should see what to do with those tests on pi3 and db
[15:13] <cachio_> because when it fails, it breaks the wifi connection so i loose the conectivity
[15:15] <mvo> cachio_: aha, do we have a newer netplan in the newer core, could this be the reason? and does the problem go away with an older go?
[15:15] <cachio_lunch> mvo, not sure
[15:16] <cachio_lunch> we could try to create an image with the old one
[15:16] <mvo> hm, looks like the last netplan upload happend a while ago so not super likely
[15:16] <mvo> or just snap refresh --stable core
[15:16] <mvo> and run the particular test again
[15:16] <ogra_> mvo, that test should have never been un like it does atm
[15:16] <cachio_lunch> mvo, is this network-manager test old? perhaps there was a  change in the snap that is affecting the tests
[15:17] <ogra_> mvo, if nplan manages the interface n-m can not ... if you want nplan and n-m to work together yu need a special nplan config that sets the renderer to n-m
[15:17] <ogra_> mvo, see the renderer stuff at https://wiki.ubuntu.com/Netplan
[15:18] <ogra_> mvo, the point here is though that n-m should ignore ine interface if nplan manages it, but it doesnt ... or that nplan needs a changed config that actually switches too the rigtht renderer ... now dont ask me why it only fails now
[15:19] <mvo> ogra_: well, that may well be, but why are things failing now and not before?
[15:19] <ogra_> i have no idea really ... was that est always there ?
[15:19] <ogra_> *test
[15:19] <ogra_> or was it just recently added
[15:19] <mvo> ogra_: the test is old, but the test does not deal with n-m, something in prepare is dealing with it and the question is also why
[15:19] <ogra_> all i can say is that it is completely wroong as it is now
[15:20] <mvo> cachio_lunch: the full test output might be nice, i.e. what tests ran before this one
[15:20] <ogra_> mvo, well, the interface is aleady configured by systemd-networkd at the point the n-m install runs
[15:21] <ogra_> so what prepare does seems to be to generate a nplan systemd-networkd config
[15:21] <ogra_> and then blindly install n-m on top
[15:21] <ogra_> which results in having two tools wrangle over the ownership
[15:22] <ogra_> and n-m uninstall n-m tries to stop wpa_supplicant but does not own the file in /run so it cant really stooop it and hanfs
[15:22] <ogra_> *hangs
[15:23] <mvo> ogra_: hm, that is interessting - is there a way to make this work, i.e. telling nm to not ouch the already-managed interfaces?
[15:23] <ogra_> not anymore, but nplan can swirtch to the n-m renderer and reconfigure the device
[15:23] <ogra_> n-m used too have an ignore thing in the past for ifupdown ... but i think thats gone
[15:24] <mvo> ogra_: hm, that sounds not ideal, I think I will switch the test to not run on the db then
[15:24] <ogra_> yeah
[15:24] <ogra_> same for the pi3
[15:24] <ogra_> the prob is that you need an interface at all to actually install n-m ... so there needs to be an initial configuration
[15:25] <ogra_> and you can only switch the config once n-m is there ... by then they are already fighting over ownership though
[15:28] <mvo> ok
[15:28] <mup> PR snapd#3927 opened: tests: only run tests/regression/nmcli on amd64 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3927>
[15:29] <ogra_> mvo, is the same test unning on x86 ?
[15:29] <ogra_> (i wonder why it doesnt fails therer if it gets run there)
[15:31]  * ogra_ goes and loks up where he can get single chery MX switches to fix his o and r on the kbd
[15:36] <pedronis> mvo:  did you see my small comments in the snap-repair list/show PR ?
[15:41] <niemeyer> I don't know what to take from this Travis issue..
[15:41] <bschaefer> ogra_, so fun work around, manually unpack the overlayfs into system-boot (AlbertA found this)
[15:41] <niemeyer> I'll take the kid to school and be back to investigate more
[15:41] <ogra_> bschaefer, overlayfs ? you mean overlays.tgz ?
[15:42] <bschaefer> yeah
[15:42] <ogra_> bschaefer, that kind of points to a discrepancy between gadget and kernel snap on your device then
[15:42] <ogra_> which is weird
[15:42] <bschaefer> yeah AlbertA hit the same issue as well after a core upgrade
[15:43] <ogra_> can you paste me the "snap list" output from your pi ?
[15:44] <bschaefer> ogra_, http://paste.ubuntu.com/25541086/
[15:44] <AlbertA> ogra_: it seems somehow after core upgrade
[15:44] <bschaefer> ive not seen kernel or gadget update for this last week
[15:44] <bschaefer> but core upgrades everyday
[15:44] <AlbertA> that partition gets corrupted and you get a bunch of fsck record files
[15:44] <AlbertA> and "overlays" folder disappears
[15:44] <ogra_> AlbertA, well, the gadget carries the original overlays and the kernel carries the verlays.tgz
[15:45] <ogra_> URGH!
[15:45] <ogra_> now thats completely different
[15:45] <ogra_> so your system-boot partition gets trashed
[15:45] <bschaefer> yeah i had a bunch of *.rec files
[15:46] <ogra_> well, i can reproduce it here now but i dont have a trashed partition
[15:46] <ogra_> ogra@localhost:~$ ls -l /dev/dri
[15:46] <ogra_> ls: cannot access '/dev/dri': No such file or directory
[15:46] <bschaefer> ogra_, this started umm
[15:47]  * bschaefer gets version
[15:47] <ogra_> ogra@localhost:~$ ls -l /boot/uboot/overlays/|grep -v dtb
[15:47] <ogra_> total 172
[15:47] <ogra_> ogra@localhost:~$
[15:47] <ogra_> i only have dtb files in there ... and als no other trace of fsck issue
[15:48] <bschaefer> the upgrade to 22913
[15:48] <bschaefer> 2913*
[15:48] <bschaefer> a few days ago
[15:48] <ogra_> well, it is unrelated t cre itself
[15:48] <ogra_> *core
[15:48] <bschaefer> o hmm seemed like the only thing changing
[15:48] <ogra_> a core update updates your bootlader config
[15:48] <mup> PR snapd#3919 closed: interfaces: updates for default, browser-support, desktop, opengl, upower and stub-resolv.conf <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3919>
[15:49] <ogra_> the fsck might be related t that update ... but not to any content of core
[15:49] <AlbertA> ogra_: yeah it doesn't look like the whole partition is trashed...
[15:49] <ogra_> but the other thing is that i can properly repro it here but without any corruption or fsck issues
[15:49] <AlbertA> only "overlays" dir for some reason
[15:49] <ogra_> theer must be some difference between kernel and gadget dtbs if extracting the overlays helps
[15:49] <bschaefer> i could still boot/ssh into it and move around
[15:50] <bschaefer> and install snaps etc
[15:50] <bschaefer> didnt see anything else wrong with the fs
[15:50] <AlbertA> bschaefer: ogra_: right I can still boot up the device just no VC4 is available (as expected since "overlays" dissapears)
[15:51] <AlbertA> and this was without installing any snaps...simply flashed a fresh image (the one from yesterday), booted, core upgraded, rebooted. Then after a second reboot
[15:52] <AlbertA> I see the issue
[15:52] <ogra_> right ... me too
[15:52] <ogra_> but without any corruption in my case
[15:52] <AlbertA> oh interesting
[15:53] <ogra_> ogra@localhost:~$ tar xf /snap/pi2-kernel/current/dtbs/overlays.tgz
[15:53] <ogra_> ogra@localhost:~$ diff -ruN /boot/uboot/overlays/vc4-kms-v3d-overlay.dtb overlays/vc4-kms-v3d-overlay.dtb
[15:53] <ogra_> ogra@localhost:~$ md5sum /boot/uboot/overlays/vc4-kms-v3d-overlay.dtb
[15:53] <ogra_> 43ee3abf64b77fc3ba837817a7eb51f8  /boot/uboot/overlays/vc4-kms-v3d-overlay.dtb
[15:53] <ogra_> ogra@localhost:~$ md5sum overlays/vc4-kms-v3d-overlay.dtb
[15:53] <ogra_> 43ee3abf64b77fc3ba837817a7eb51f8  overlays/vc4-kms-v3d-overlay.dtb
[15:53] <ogra_> ogra@localhost:~$
[15:53] <ogra_> and the files are identical ...
[15:53] <ogra_> yet ...
[15:53] <phil_m> zyga-suse, zyga-ubuntu: and some progress made within Manjaro?
[15:53] <ogra_> ogra@localhost:~$ ls -l /dev/dri
[15:53] <ogra_> ls: cannot access '/dev/dri': No such file or directory
[15:53] <ogra_> ogra@localhost:~$
[15:53] <ogra_> oh
[15:53] <ogra_> one sec
[15:54] <ogra_> i'm using a special gadget here
[15:54] <ogra_> ogra@localhost:~$ grep vc4-kms-v3d-overlay.dtb /boot/uboot/config.txt
[15:54] <ogra_> ogra@localhost:~$
[15:54] <ogra_> ok
[15:55] <ogra_> ah, grepping for the wrong thing wont help
[15:55] <mvo> pedronis: I have not checked in detail, I will either address them later today or monday morning. but thanks for them in any case !
[15:55] <ogra_> ogra@localhost:~$ grep vc4-kms-v3d /boot/uboot/config.txt
[15:55] <ogra_> #dtoverlay=vc4-kms-v3d
[15:55] <ogra_> ogra@localhost:~$
[15:55] <mvo> ogra_: yes, tests run on amd64 VM, however that does not have wifi
[15:56] <ogra_> mvo, ah ! yeah, then they wont wrangle over wpa_supplicant files indeed
[15:57] <ogra_> AlbertA, bschaefer, well, ok, i cant repro it *'yet* but will turn my bard back to use the vc4 driver now and check tomorrown after the next core update
[15:58] <ogra_> *board
[15:58] <AlbertA> ogra_: thanks!
[15:58] <ogra_> i definitely dont get any corruption here though ... and havent in a long time
[15:58] <ogra_> are your SD cards old ?
[15:59] <bschaefer> ogra_, nope i just got my this last week
[15:59] <bschaefer> since my old one was ... bad
[15:59] <bschaefer> though i have reflashed it ... ~20 times this week
[15:59] <AlbertA> ogra_: I have a sandisk 32GB maybe about a year old now
[15:59] <ogra_> (when runnign edge, every core update will write to the same spot on the card, so running edge can wear them out faster)
[16:00] <ogra_> (that is ... for the bootloader config update ...)
[16:00] <AlbertA> ogra_: oh interesting idea.. yeah maybe those particular blocks are going bad, seems plausible
[16:01] <ogra_> AlbertA, but that doesnt explain why bschaefer woould see it ...
[16:01] <mup> PR snapd#3928 opened: interfaces/system-observe: allow clients to enumerate DBus connection names <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3928>
[16:01] <noChance> We need to stop China from killing Bitcoin. The more people use BTCs the harder it will be for China to snuff it... https://freebitco.in/?r=7247637 -> get your own free Bitcoins.
[16:02] <ogra_> also ... my 4GB card that i have currently in use is rather in the 3-5y ealm and running edge daily sincer abut a yea now
[16:02] <bschaefer> well that would suck, ive 32GB
[16:02] <ogra_> i have only one out of like 30 cards here that i ave yet managed to wear out
[16:02] <bschaefer> same as AlbertA but yeah i got these over last weekend
[16:03] <ogra_> so wear levelling is always my last guess after all ...
[16:03] <bschaefer> ogra_, i do like that /writable seems to resize now to the fullsize of the SD card now
[16:03]  * bschaefer use to run out of room a bunch due to the image size
[16:03] <ogra_> yeah, there was a bug for a short time ... but thats fixed now
[16:03] <ogra_> the build did pull in the wrong initamfs-tools
[16:05] <bschaefer> ogra_, so future testing of this sort of thing, checking the dtbs in /boot?
[16:06] <ogra_> bschaefer, welll, finding the reason why yu both get that breakage ...
[16:06] <ogra_> the whole overlays stuff will change soon with the ability to upgrrade gadgets
[16:07] <bschaefer> o nice
[16:07] <bschaefer> yeah we do happen to have the same SD card IIRC
[16:08] <ogra_> it isnt ... by chance listed with a red marker in teh table at http://elinux.org/RPi_SD_cards ?
[16:09] <ogra_> (seems theer are a bunch of snadisk cards that dont play well with the Pi contoller)
[16:09] <bschaefer> ogra_, all the sandisk 32GB class 10 are green
[16:09] <ogra_> ok
[16:09] <bschaefer> yeah i bet my older SD 8 GB was red on this...
[16:10] <bschaefer> class 2 or 4
[16:11] <ogra_> well, let me see whyt my system des here with the next update
[16:11] <ogra_> also ... please bring the cards to NY ... i'lll have a Pi with me to play with
[16:11] <bschaefer> o yeah good idea
[16:11] <ogra_> (in case i dont find the cause til then indeed)
[16:11] <bschaefer> ill bring my rapi3 + sd cards as well
[16:12] <bschaefer> dont have a monitor though :)
[16:12] <ogra_> cool
[16:12] <bschaefer> there should be something about
[16:12] <ogra_> the hotel room will ;)
[16:12] <bschaefer> o yeah haha
[16:12] <ogra_> worst case
[16:16] <niemeyer> More unrelated Travis issues...
[16:16] <niemeyer> https://travis-ci.org/snapcore/spread-cron/builds/274621786
[16:21] <zyga-suse> phil_m: yes and no. I fixed all the other issues but at least inside vmware I cannot get opengl to work. I plan to investigate on real hardware tomorrow.
[16:22] <zyga-suse> phil_m: and in any case send a PR to github so that the package can be added in the initial version,
[16:26] <cachio> mvo, https://paste.ubuntu.com/25535960/
[16:27] <cachio> https://paste.ubuntu.com/25536062/
[16:27] <cachio> https://paste.ubuntu.com/25540165
[16:27] <cachio> mvo, it failed in those 3 runs
[16:27] <cachio> for db and pi3
[16:29] <mvo> cachio: yeah, i pushed a "fix"
[16:30] <cachio> pr'
[16:30] <cachio> ?
[16:30] <mvo> cachio: yeah
[16:30] <mvo> cachio: I say "fix" because the test is just skipped
[16:30] <phil_m> zyga-suse: ok. we will see. thx for the effort so far.
[16:30] <mvo> cachio: but thats ok, we cannot install n-m and netplan for wifi at the same time currently
[16:30] <cachio> mvo, good :) it is a way to fix it
[16:31] <ogra_> well, we can surely work on a real fix and have netplan use the n-m renderer
[16:31] <ogra_> but thats some wrk
[16:31] <ogra_> *work
[16:50] <zyga-suse> mvo: all good?
[16:51] <mvo> zyga-suse: yes, no?
[16:51]  * zyga-suse is worried we all work on Fridays so late
[16:55] <mup> PR snapd#3904 closed: tests: test the real "xdg-open" from the core snap <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3904>
[17:04] <ogra_> zyga-suse, thats all just the bad weather and stuff :P
[17:09] <lutostag_> the xdg-open was working for me on gnome until an update today (on artful/gnome-wayland), now it isnt... :/
[17:10] <zyga-ubuntu> lutostag_: I think this is a known issue that mvo is addressing with another release
[17:22] <mvo> lutostag_: as a workaround "snap refresh --candidate core" should bring it back
[17:32] <lutostag_> mvo: no joy on the refresh, https://paste.ubuntu.com/25541837/ but I am just glad someone is looking into it, thanks guys ;)
[17:35]  * zyga-suse takes a break to do something non-coding
[17:40] <mvo> lutostag_: hm, that lxd error rings a bell, maybe zyga-ubuntu remembers the details once he is back
[17:51] <zyga-suse> hmmm, holly molly
[17:51] <zyga-suse> no idea
[17:51] <zyga-suse> is that inside lxd?
[18:00] <niemeyer> Travis is out of the equation, btw.. I can reproduce the problem locally too. It's either a bug in Spread or something in the Linode API..
[18:01] <niemeyer> I'm guessing Linode needs to be involved somehow, since this has shown up without Spread changing
[18:27] <mvo> lutostag_: iirc we had this issue with older version of lxd, iirc when snap was run inside lxd. if that is the case, what version of lxd do you use (inside and outside?)
[18:29] <lutostag_> mvo: outside, then inside https://paste.ubuntu.com/25542158/
[18:30] <lutostag_> although I was running the snap refresh core --candidate on the outside
[19:52] <mvo> lutostag_: thanks, I wonder if lxd 2.17 would help


[01:36] <tlm> any idea how to fix this warning when building juju "failed to update distro info: open /usr/share/distro-info/ubuntu.csv: no such file or directory"
[01:42] <wallyworld_> tlm: update deps, there was a bug in juju/os
[01:42] <wallyworld_> that or install distro-info dep
[01:42] <tlm> ah sweet
[01:47] <hpidcock> tlm: stickupkid: I think landed a fix to develop
[01:47] <hpidcock> on k8s we don't have the apt package installed
[01:47] <hpidcock> so the error was happening
[01:48] <hpidcock> also on centos
[03:36] <wallyworld_> thumper: were you looking for a new 2.7 sha for QA testing?
[03:37] <thumper> wallyworld_: why did we need another? rick_h_ said he had passed on the previous one
[03:37] <wallyworld_> thumper: you asked for the race fix to be targetted to 2.7
[03:38] <thumper> wallyworld_: ah, no
[03:38] <thumper> we don't need that for 2.7.5
[03:38] <thumper> just that if we are going to fix it, should do it on that branch first
[03:38] <thumper> since we know the problem is there too
[03:38] <wallyworld_> yup, no worries, just wanted to clarify
[03:38] <wallyworld_> i was hoping we would not do a new sha
[04:26] <thumper> Review for anyone that feels the need: https://github.com/juju/juju/pull/11350
[04:26] <thumper> or desire
[04:26] <thumper> or whatever
[04:26] <wallyworld_> ok
[04:27] <thumper> wallyworld_: thanks
[04:28] <thumper> wallyworld_: it may be easier to review the commits one by one
[04:28] <thumper> I made sure they made sense individually
[04:28] <wallyworld_> because you care
[04:28] <thumper> yes, I care
[04:28] <thumper> they even have decent commit messages
[04:28] <thumper> IMO
[04:29] <wallyworld_> not too shabby
[04:39] <hpidcock> wallyworld_: found the bug
[04:39] <hpidcock> you approved it :)
[04:40] <wallyworld_> oh :-(
[04:40] <tlm[m]> :(
[04:40] <hpidcock> I'm assuming daemonset support was only in develop?
[04:40] <hpidcock> or did it get backported to 2.7?
[04:40] <wallyworld_> yeah
[04:40] <wallyworld_> only develop
[04:41] <hpidcock> sweet, unreleased bug then
[04:41] <wallyworld_> what was it?
[04:41] <hpidcock> ensureStatefulSet was missing else { return nil } on the create
[04:41] <hpidcock> so it would create
[04:41] <hpidcock> then immediately update it
[04:42] <wallyworld_> bollocks
[04:42] <hpidcock> I was this "" close to thinking it was a k8s bug
[04:43] <wallyworld_> so that explains all the symptoms?
[05:06] <hpidcock> wallyworld_: at least the deployment failure
[05:13] <wallyworld_> thumper: lgtm with a few comments
[05:21] <thumper> thanks
[05:21] <thumper> I'm EODing, and away tomorrow, will look Thursday
[05:21] <wallyworld_> enjoy the drive
[06:42] <wallyworld_> jam: did you want to land your jujuc PR and we can pick it up? easier than forking and re-proposing
[06:43] <wallyworld_> we can do the common socket code refactor etc
[06:43] <jam> wallyworld[m]: sure
[06:43] <wallyworld_> ty
[07:11] <flxfoo> Hi all
[07:12] <flxfoo> how do I see all permissions for  a user? I have two superuser but only one can perform system calls, the other one receives permission denied...
[07:39] <wallyworld_> flxfoo: juju show-model will show the users with acess to that model and what permissions they have
[07:39] <wallyworld_> juju show-user <fred> will also show a specific user
[07:43] <flxfoo> wallyworld_: thanks
[07:46] <flxfoo> wallyworld_: I tried to automate the backup (percona-cluster run-action backup) of the percona cluster, with  a cronjob.. at the end user needs to be superuser+admin ... any other idea to do that?
[07:49] <wallyworld_> flxfoo: i can't recall what level of permission is needed to run an action. i can try it
[07:54] <wallyworld_> flxfoo: i just tested a user with write access to a model containing a deployed application, and that user could run an action on that app
[09:08] <achilleasa> jam: I pushed the PR for relation-created. Can you take a look? https://github.com/juju/juju/pull/11341
[09:09] <achilleasa> manadart: if curious how I worked around that interface limitation that we were chatting about you might also want to take a look at ^
[09:16] <manadart> achilleasa: Ack, will take a look.
[09:29] <flxfoo> wallyworld_: mmm interesting... and just calling `run()` ?
[09:31] <wallyworld_> flxfoo: "juju run-action" on a client
[10:00] <wallyworld_> hpidcock: lgtm with a question about cm generations
[10:00] <wallyworld_> i don't quite get how we handle a mismatch
[10:22] <stickupkid> manadart, is anyone calling UpdateSpace, from my initial grepping, it seems like update-space and UpdateSpace method do nothing, is that correct?
[10:23] <stickupkid> manadart, seems like I could propose a PR to remove old stuff at the very least
[10:24] <manadart> stickupkid: Yes, I believe there are some commands not implemented that date from the spaces MVP.
[10:24] <stickupkid> manadart, let me do that first, it's very confusing to have UpdateSpace that will panic
[10:31] <stickupkid> manadart, https://github.com/juju/juju/pull/11353
[10:42] <stickupkid> manadart, I've got some other dead code to remove, if you've got a sec
[10:43] <manadart> stickupkid: Yep.
[11:02] <stickupkid> manadart, https://github.com/juju/juju/pull/11353 <- removed - I have a question about this though (https://github.com/juju/juju/pull/11353/files#diff-bfb621f2a13c2cf9efe1d5eaee1a31c7), everything else came out clean
[11:06] <manadart> stickupkid: I'd remove that method from API too.
[11:06] <stickupkid> manadart, agreed, just wanted another set of eyes
[11:08] <stickupkid> manadart, done
[11:22] <flxfoo> wallyworld_: no sorry I meant, if I `run('ls -l')  on remote machine, I have permission denied
[11:59] <manadart> stickupkid: https://github.com/juju/juju/pull/11354.
[12:00] <stickupkid> manadart, you can delete the checklist from the PR, it's just away to make you remember :D
[12:01] <manadart> stickupkid:
[12:01] <manadart> Done.
[12:05] <stickupkid> manadart, done
[12:11] <jam> stickupkid: any chance you could help me understand an issue with compiling Juju for windows?
[12:11] <stickupkid> jam, of course
[12:11] <stickupkid> daily?
[12:11] <jam> sure
[12:54] <stickupkid> manadart, do we want `juju move-to-space db-space <IP_ADDRESS>/28 <IP_ADDRESS>/20` or `juju move-to-space db-space id1 id2`?
[13:08] <stickupkid> jam, "success"
[13:32] <jam> stickupkid: indeed :0
[14:53] <achilleasa> rick_h_: this is how the who-departed will work: https://paste.ubuntu.com/p/KVFDYrhnXQ/ did I miss anything?
[15:06] <stickupkid> manadart, if I use SubnetsByCIDR to gather the tags for calling MoveSubnets, what's a tag in the params.SubnetsResults?
[15:06] <stickupkid> manadart, the ID?
[15:06] <manadart> stickupkid: Yes.
[15:06] <stickupkid> yolo
[15:06] <stickupkid> that's not confusing, tags are IDs
[15:06] <stickupkid> :|
[15:07] <rick_h_> achilleasa:  looking
[15:08] <rick_h_> achilleasa:  is that first number the relation id?
[15:08] <achilleasa> yes this is a debug log entry
[15:08] <rick_h_> achilleasa:  that looks right to me
[15:08] <achilleasa> the plan is to expose the departing unit to charms via the JUJU_DEPARTING_UNIT envvar
[15:09] <achilleasa> (only present when running relation-departed hooks)
[15:10] <rick_h_> achilleasa:  +1
[15:19] <achilleasa> rick_h_: is this the bug we are targeting or is there a newer one out there? https://bugs.launchpad.net/juju-core/+bug/1417874
[15:19] <mup> Bug #1417874: [RFE] Impossible to cleanly remove a unit from a relation <canonical-is> <charms> <feature> <hooks> <sts> <sts-rfe> <juju:Triaged> <juju-core:Won't Fix> <https://launchpad.net/bugs/1417874>
[15:21] <rick_h_> achilleasa:  let me check. I think I added the one to the checklist on the main card
[15:21] <rick_h_> achilleasa:  yea, that's the right looking one
[15:22] <achilleasa> rick_h_: cool; I will mark that as in-progress
[15:23] <rick_h_> achilleasa:  woot woot
[15:33] <stickupkid> manadart, why do these exist here? https://github.com/juju/juju/blob/develop/core/network/space.go#L26-L49
[15:37] <manadart> stickupkid: Not sure where those are used in conversion, but they might be better closer to usage...
[15:37] <stickupkid> manadart, yeah, these aren't core, esp. if we want to rip out the CLI, thise makes it super hard
[15:38] <stickupkid> oh god, they're like fucking view models and core models - yikes
[15:39] <stickupkid> manadart, got a sec
[15:39] <stickupkid> ?
[15:40] <manadart> stickupkid: Yep.
[16:08] <flxfoo> hi all,
[16:08] <flxfoo> we have an issue with rackspace, when trying to deploy a new unit we have "cannot run instance: failed to run a server with nova.RunServerOpts{Name:"juju-00f9f6-v5-prod-50", FlavorId:"general1-2", ImageId:"6e731e8e-ff3d-4e27-be6c-147fde688b7c", UserData:[]uint8{0x1"
[16:09] <flxfoo> where the imageID is no longer available
[16:09] <flxfoo> support told me to use another image ID
[16:09] <flxfoo> but I don't know how to tell juju to use that new image ID...
[16:09] <flxfoo> any idea?
[17:16] <achilleasa> I think I just found the function with the longest signature in juju! https://github.com/juju/juju/blob/develop/worker/uniter/runner/context/export_test.go#L156
[17:16]  * rick_h_ dies just a little more inside
[17:16] <rick_h_> wow, that...is impressive
[17:17] <achilleasa> Its call-site is even more impressive: https://github.com/juju/juju/blob/develop/worker/uniter/runner/context/env_test.go#L113
[17:18] <achilleasa> I will ... structurify it :D
[17:19] <rick_h_> hah, good luck!
[17:19] <achilleasa> I need to add an extra field there so...
[20:10] <flxfoo> hi all
[20:10] <rick_h_> howdy flxfoo
[20:10] <flxfoo> I find the reference if the "bad" image Id in /var/lib/juju/bootstrap-params file in the controller instance
[20:11] <flxfoo> refered as a custom-image-metada
[20:11] <flxfoo> can I remove or change that value?
[20:13] <rick_h_> flxfoo:  normally that's set via controller-config I believe. Is this a running controller?
[20:16] <flxfoo> rick_h_: yeah running controller
[20:17] <rick_h_> flxfoo:  ok, let me dbl check if it's model-config or controller-config you'd set to change that value
[20:18] <flxfoo> rick_h_: I have neither that key in controller-config nor model-config :(
[20:19] <flxfoo> or I don't look at the  right place?
[20:20] <rick_h_> flxfoo:  yea, refreshing. I think you're into https://discourse.jujucharms.com/t/cloud-image-metadata/1137
[20:20] <rick_h_> flxfoo:  which is using the metadata-source arg on bootstrap.
[20:21] <rick_h_> flxfoo:  and you can see some metadata related config in the model-config `juju model-config | grep meta`
[20:21] <rick_h_> flxfoo:  I'd be curious what those are currently set to?
[20:22] <flxfoo> rick_h_: agent-metadata-url defalt ""
[20:22] <flxfoo> rick_h_: agent-metadata-url default ""
[20:22] <flxfoo> rick_h_: container-image-metadata-url default ""
[20:23] <flxfoo> rick_h_: image-metadata-url default ""
[20:23] <flxfoo> that's what I got
[20:23] <flxfoo> I think the issue is related to that thread https://discourse.jujucharms.com/t/rackspace-cloud-london-region-missing-images/1339/5
[20:24] <flxfoo> where had been applied a "temporary" fix... using simplestream... and I think it should revert... but I don't know how... :(
[20:24] <rick_h_> flxfoo:  oh ok, good question.
[20:24] <flxfoo> this `custom-image-metadata should probably be empty or so..
[20:25] <flxfoo> rick_h_: I suppose if I change that `bootstrap-params` file that won't change anything... right?
[20:29] <rick_h_> flxfoo:  yea looking. I'd not expect that to do anything now that bootstrap is over. Since it's a bootstrap arg, and not config, it's not really a thing that's got a knob for "changing it"
[20:29] <rick_h_> flxfoo:  so trying to validate if there's a clear path to changing it or not. I'd hate to bork things even more.
[20:30] <flxfoo> rick_h_:ok thanks... do you a location where i could check that as well? or is it source code only?
[20:31] <rick_h_> flxfoo:  yea in this case I'm just poking at source trying to see
[20:31] <flxfoo> rick_h_: k
[20:31] <rick_h_> flxfoo:  honestly might have to wait and ask wallyworld for his expertise in this area
[20:31] <flxfoo> and he is the one who was appearing in the thread... so...
[20:32] <flxfoo> rick_h_: is he around sometime... better tomorrow?
[20:32] <rick_h_> flxfoo:  he'll be online in the next couple of hours
[20:33] <flxfoo> ok will try to wait a little then... thanks for your time... I though i was going crazy... (not to mention the quarantine)
[20:33] <flxfoo> maybe you could answer that following question though...
[20:34] <flxfoo> so i have this `custom-image-metadata` with at least a image id which is causng trouble because not theire anymore...
[20:34] <flxfoo> then the following lines defines the regions etc...
[20:35] <flxfoo> controller-cloud: name:rackspace. etc... regions etc...
[20:35] <rick_h_> right, that's the general cloud definition baked in. It tells the contrller things like api endpoints to use/etc
[20:36] <flxfoo> I suppose that custom-image-metadata is taking precedence on the that following list... am I making a correct assumption?
[20:37] <rick_h_> flxfoo:  well it's filling in the images specific data and not everything there. It can't refer to a region that the cloud list doesn't know about, for instance
[20:37] <rick_h_> flxfoo:  but it's tied together for sure
[20:38] <flxfoo> custom-image-metadata: '[{"id":"6e731e8e-ff3d-4e27-be6c-147fde688b7c","virt":"pvhvm","arch":"amd64","version":"18.04","crsn":"LON","region":"LON","endpoint":"https://lon.identity.api.rackspacecloud.com/v2.0/"}]'
[20:39] <flxfoo> here it would tell to use that particular image in case of region LON endpoint reached...
[20:39] <rick_h_> flxfoo:  right so that's saying that image is avilable in that region
[20:39] <flxfoo> ok
[20:39] <rick_h_> flxfoo:  there could be more images with different architectures/etc as well.
[20:39] <rick_h_> flxfoo:  in particular different ubuntu series like 14.04, 16.04, 18.04 but we know not all regions have the same things, etc
[20:40] <flxfoo> rick_h_: that's my point, the URL (thread) I posted was saying that for some time images were not available for LON region... so a custom bootstrap was made... then the images are then available... but the controller does not know about it
[20:41] <flxfoo> I am curious what would look like a setting when images are provided by region...
[20:42] <rick_h_> flxfoo:  right, so this gets interesting as the use case for htis is more bootstrapping on openstack and defifining things for that. I'm not sure how it's mutated/managed over time
[20:42] <rick_h_> flxfoo:  in theory all this data should be pulled from an online stream url. If the stream is valid, and Juju is looking at that url, it might just be a cause of removing this.
[20:43] <rick_h_> flxfoo:  but in looking at the code a metadata directory is setup on the machine and such so I think there's more to it than that
[20:43] <rick_h_> so that's where I don't want to mess you up and wait for wallyworld
[20:43] <flxfoo> rick_h_: exactly... obviouslly it is not manageable, because now that rackspace upgraded their images (That I suppose is my issue) then my model is just no its own,  I can not deploy or up.dwon scale anything
[20:44] <rick_h_> flxfoo:  yea :( maybe you can use that model config to set the image-metadata-url to the official one?
[20:44] <flxfoo> rick_h_: ok thanks...
[20:44] <rick_h_> flxfoo:  but it's not clear who wins priority atm
[20:45] <flxfoo> rick_h_: right, well I have to check... would it be the images endpoint url?
[20:46] <flxfoo> rick_h_: (if I cURL rackspace api I can get a list of available images)
[20:46] <rick_h_> flxfoo:  so I was thinking the model-config parameter image-metadata-url
[20:46] <rick_h_> flxfoo:  we can test this by adding a new model if you can?
[20:46] <rick_h_> and then set that value, and see if you can `juju add-machine`
[20:47] <flxfoo> rick_h_: I suppose I won't interfere with the current model?
[20:47] <flxfoo> rick_h_: sorry I am a bit new to juju...
[20:47] <flxfoo> rick_h_: what are the risks? :p
[20:48] <rick_h_> flxfoo:  right, but doing it in a new model we're reducing any risk
[20:48] <rick_h_> flxfoo:  once we're done with the test we can just remove the model
[20:49] <flxfoo> rick_h_: sure I got that, not playing with the current model but a new one...
[20:51] <flxfoo> rick_h_: I don't have any config to pass to a new model though
[20:55] <rick_h_> flxfoo:  do you know the url that rackspace hosts for the image data normally?
[20:57] <flxfoo> http://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:rax.json could it be this?
[20:57] <flxfoo> naaaa
[20:57] <flxfoo> sorry
[20:59] <flxfoo>  https://lon.images.api.rackspacecloud.com/v2/<tenantid>/images
[21:00] <flxfoo> through their api...
[21:00] <flxfoo> so you got a json list of image definitions with other details...
[21:00] <rick_h_> hmm, so the question is can you set that in the new model using `juju model-config image-metadata-url="https://lon.images.api.rackspacecloud.com/v2/<tenantid>/images"`
[21:04] <flxfoo> rick_h_:  as the controller has the `tenant-name` + the identity endpoint defined by region , i suppose it should be just https;//lon.images.api.rackspace.com/v2
[21:05] <rick_h_> flxfoo:  yea, might be. That I'm not 100% sure on. one thing we can do is make sure to crank up logging and watch for what it's doing in the actual requests.
[21:06] <rick_h_> flxfoo:  juju model-config logging-config="<root>=DEBUG;unit=TRACE"
[21:06] <rick_h_> well probably not unit-trace
[21:06] <rick_h_> flxfoo:  juju model-config logging-config="<root>=DEBUG;"
[21:10] <flxfoo> rick_h_: can that debug configuration load machines?
[21:11] <timClicks> progress report for last week is live https://discourse.jujucharms.com/2807
[21:12] <rick_h_> flxfoo:  what do you mean by "load machines"?
[21:12] <rick_h_> flxfoo:  it'll make all logging at debug level until it's set back to info
[21:14] <flxfoo> ok
[21:15] <flxfoo> I will try now to see if that gives something
[21:17] <flxfoo> rick_h_: should I add a charm like memcached or something small?
[21:19] <rick_h_> flxfoo:  just `juju add-machine`
[21:19] <rick_h_> flxfoo:  and see if you can get a new machine to come up
[21:22] <flxfoo> ok I have something different
[21:22] <rick_h_> hah, not sure if that's a good sign or a bad one
[21:23] <flxfoo> failed to start machine 0 (multiple networks with label "": [5836eb06-731c-4653-87ac-bebcd97f1a18 dd3389c6-cc70-43bf-a8ec-489be09855cb
[21:23] <flxfoo> :)
[21:24] <flxfoo> To resolve this error, set a value for "network" in model-config or model-defaults;
[21:24] <flxfoo> or supply it via --config when creating a new model), retrying in 10s (10 more attempts)
[21:25] <rick_h_> flxfoo:  ok, so have to set the model value for that
[21:25] <rick_h_> flxfoo:  exactly
[21:25] <rick_h_> flxfoo:  so have to add that to the model-config for our test model
[21:25] <rick_h_> flxfoo:  juju model-config network=XXXXXX (not sure which one you want)
[21:27] <flxfoo> rick_h_: wait not sure what I am suppose to put here
[21:29] <rick_h_> flxfoo:  one of those uuids from above
[21:30] <rick_h_> flxfoo:  we might have to check and see if there's a value in your other working model?
[21:30] <rick_h_> flxfoo:  I would assume that was needed there as well
[21:30] <rick_h_> flxfoo:  you can get the current config values by just doing `juju model-config network`
[21:45] <flxfoo> rick_h_: ok passes, but still have the original error line from custom-metadata-url content
[21:45] <flxfoo> :(
[21:50] <flxfoo> rick_h_: so I suppose the custom-metadata-url gets precedence
[22:12] <flxfoo> rick_h_: which code did you look at for `custom-metadata-url`?
[22:18] <babbageclunk> hey timClicks, how should I fix a bug in the docs?
[22:20] <wallyworld> flxfoo: if you bootstrapped with --metadata-source arg, then that custom image metadata is stored in mongo and takes precidence. you'll need to delete those image metadata records. to do that you'll need to turn on the image-metadata feature flag on the controller and on the client. to set on the controller, "juju controller-config features=[image-metadata]". you might need to bounce the controller agent systemd, not sure. then
[22:20] <wallyworld>  on the client, export JUJU_DEV_FEATURE_FLAGS=image-metadata. after that, you can juju metadata delete-image <id>. you can also juju metadata list-images
[22:21] <flxfoo> wallyworld: ok, thanks... I will need to read that several times... :)
[22:22] <wallyworld> sure, it's a bit messy because image metadata manipulation is not something normally exposed out of the box - you need a feature flag enabled and if not done at bootstrap, you need to turn it on afterwards. if anything is unclear, just ask. i would expect there will be questions
[22:23] <flxfoo> wallyworld: thanks a lot... give me a bit time :)
[22:23] <wallyworld> i assume you had custom jsom image metadata at bootstrap time? and you bootstrapped with --metadata-source
[22:24] <wallyworld> in any case, once the feature flag is enabled, you'll have access to add/list/delete custom image metadata commands
[22:24] <wallyworld> to see what your controller is using
[22:29] <flxfoo> wallyworld: correct bootstrapped with --metadata-source (I did not do that personally but the person in charge at the time)
[22:32] <flxfoo> wallyworld: so I understood properly, we will tell the juju client to use the `image-metadata` with the JUJU_DEV_FEATURE_FLAGS env var. Then by setting the related controller config entry `features`... restart the controller agent (which I need to check which process it is)... did I get things right?
[22:33] <flxfoo> wallyworld: I mean , If you undrestand what I am writing... I look tired :)
[22:33] <flxfoo> wallyworld: I think I got the picture...
[22:33] <flxfoo> wallyworld: are you around about that time usually?
[22:36] <flxfoo> wallyworld: the fact that I modified the `image-metadata-url` would have an incidence?
[22:37] <babbageclunk> flxfoo: that sounds right to me - I think wallyworld might have afk'd for a moment
[22:40] <babbageclunk> flxfoo: you can bounce the juju agent on the controller with `sudo systemctl restart jujud-machine-0.service`
[22:40] <babbageclunk> (assuming this is just a one-machine controller?)
[22:40] <flxfoo> babbageclunk: yes
[22:41] <flxfoo> babbageclunk: thanks
[22:41] <wallyworld> flxfoo: sorry, was caught up with something else. yeah, summary is correct. first step is to get the feature flag enabled and use the list-images command to see what the controller is using
[22:41] <flxfoo> wallyworld: nm
[22:41] <wallyworld> tz here is GMT+10
[22:41] <flxfoo> wallyworld: k
[22:43] <wallyworld> to restart the controller agent, ssh into the controller machine (ususally juju ssh -m controller 0) and then restart the juju-machine-0 systemd service
[22:43] <flxfoo> wallyworld: I will try that tomorrow morning.. and will let you know... I think things/issues come from there https://discourse.jujucharms.com/t/rackspace-cloud-london-region-missing-images/1339/5
[22:44] <flxfoo> wallyworld: many thanks, I would not have found that by myself for sure... :)
[22:45] <wallyworld> np, here to help you get this sorted. good that rackspace has complete image metadata but a mess to clean up for sure
[22:45] <flxfoo> wallyworld: and they are not helping... you are... thanks guys
[22:46] <flxfoo> I am out... good night/day :)
[22:46] <wallyworld> ttyl :-)


[12:20] <dolson> if there is a bug in a package, and the latest version in Debian unstable fixes it without any changes needing to be made, then what is the process to request to get that into Dapper? The bug in question is #28560, package is freewheeling. it currently segfaults with the Dapper version
[12:23] <ajmitch_> as it doesn't break UVF, it should be no problem for someone to request a sync or merge the ubuntu changes in
[12:24] <dolson> the ubuntu changes are not needed, from what I can tell
[12:24] <dolson> Loic changed the build deps and that's all, and this is changed in Debian now from what I can see
[12:25] <dolson> so can I request a sync? or does someone else higher up have to do it?
[12:27] <ajmitch_> a MOTU needs to
[12:27] <LaserJock> if you want a sync you can use our new wiki page https://wiki.ubuntu.com/MOTU/SyncRequests
[12:29] <dolson> done.
[12:33] <dolson> dholbach: hey, I just read your MOTU report. :)
[12:38] <dholbach> good night guys
[12:38] <LaserJock> cya dholbach
[12:38] <dholbach> bye LaserJock
[12:41] <dolson> cya later
[12:43] <dsas> dolson = dana olsen?
[12:43] <dolson> olson, yeah
[12:44] <dsas> Are you the person who wrote mandrake tutorials years ago?
[12:44] <dolson> I deny everything!
[12:44] <dolson> I am innocent!
[12:44] <dolson> http://pgshopping.com/mdkxp is not my old site!
[12:44] <dsas> :D, You were a great help back when I was starting with Linux, thanks a lot.
[12:44] <dolson> Thanks! that means a lot to me.. and I'm glad to see you're on Ubuntu now :)
[12:45] <ajmitch_> how long ago was this?
[12:45] <dsas> Uhm five years ago, roughly.
[12:45] <dolson> I started it in 2001 I think.. ended in 2003
[12:45] <ajmitch_> ah
[12:45] <dsas> I think it was when I was using mdk 7.2 or 8.0
[12:45] <ajmitch_> hard to believe I've been on debian & now ubuntu for that long
[12:46] <dolson> I used to spend all my spare time helping people on MSN and AIM, and some people sent me free stuff like Mandrake manuals, Linux video games, one guy took me out for lunch, and one guy even sent me a free MP3 player
[12:46] <dolson> I had to sell the MP3 player because I wanted to get one that actually worked in Linux instead, heh
[12:47] <dsas> ha :D, oh well.
[12:47] <dsas> I posted on some forums occasionaly that you frequented too, mandrake-users.org or something.
[12:47] <dolson> dsas: so who are you? maybe I would recognize the name
[12:47] <dolson> yeah, I remember the good ol' MUB
[12:48] <fbond> dolson: pong
[12:48] <dolson> fbond: hey man.. do you have packages for linuxsampler?
[12:48] <fbond> ah... no ...
[12:48] <dsas> yeah the mub that was it. I was probably dean, sas or dsas back then too. (I've never been very creative with names)
[12:48] <fbond> i was thinking that would be a good idea, though
[12:48] <fbond> although i'll admit, i fell in love with NI Kontakt (non-free) a few years ago
[12:48] <fbond> and that runs using dssi-vst
[12:49] <dolson> fbond: do you wanna tackle it? I am slow
[12:49] <fbond> i'll see if i can get to it
[12:49] <dolson> it uses libs and stuff, and I'm not at that level yet
[12:49] <fbond> ok
[12:49] <fbond> what's the deadline for dapper again?
[12:49] <dolson> soon
[12:50] <dolson> :)
[12:50] <ajmitch_> for new packages? in about a week
[12:50] <fbond> yup ...
[12:50] <fbond> ok, thanks
[12:50] <fbond> anybody want to help me with a copyright file?
[12:51] <fbond> i have a package with three different licenses
[12:51] <dolson> ouch
[12:51] <fbond> (for different components)
[12:51] <fbond> yeah ... that's actually dssi
[12:52] <fbond> is it okay to basically say "program xyz license\nlicense\n\nprogram abc license\nlicense text\n
[12:53] <fbond> takers?
[12:57] <dolson> sorry man, I don't know.. is there anything about license stuff in the debian maintainer guide?
[12:58] <fbond> a bit, nothing complex, though
[12:59] <fbond> i'll check the debian policy manual
[01:01] <fbond> yeah, policy manual is not much help ... throwing all the copyrights in there makes sense to me
[01:02] <dolson> I guess I'd just do it and get it up to REVU and someone will correct you if it's wrong
[01:03] <fbond> yup
[01:16] <Mez> ogra: ping
[01:29] <dolson> ahahahahah http://www.flurl.com/featured/Scare_Your_Kid_1082.html
[01:38] <dsas> does anyone know the difference between eric and eric3 in the repos?
[01:39] <ajmitch_> one of them should have been removed
[01:39] <ajmitch_> I can't remember which :)
[01:40] <dsas> presumably eric3 it has an older revision number.
[01:41] <dsas> I'll change the docs to reccomend eric then :)
[03:12] <psusi> man that Joerg Schilling is a jackass
[03:12] <psusi> I wish that thread would die finally
[03:15] <ajmitch_> and I don't know if I want to know :)
[03:24] <odla> man xfce is messed up right now on dapper ;)
[03:30] <psusi> the completely massive thread on lkml over the last week or two where Joerg has basically been shooting his mouth off about how linux is broken because it does not conform to his world view of all scsi type devices being addressed with bus:device:lun numbers
[03:31] <ajmitch_> ah right
[03:31] <ajmitch_> I think everyone knows to ignore him anyway, or at least I could hope so :)
[03:31] <psusi> he has been soundly smacked down on everything he has had to say but he keeps dodging and repeating himself because he refuses to accept that /dev/cdrom is just as good if not better than scsi:1:2:0 and the kernel isn't going to change
[03:31] <psusi> well there's something like 1000 posts in the thread ;)
[03:32] <whiprush> psusi: it's been like that for like ... at least 5 years.
[03:32] <psusi> makes me wish they'd just ban the asshat
[03:32] <whiprush> hi aj
[03:32] <whiprush> and hi jsgotangco
[03:33] <jsgotangco> jorge!!!!
[03:33] <jsgotangco> wow my fonts in dapper are crap
[03:33] <psusi> 0xDEADBEEF
[03:34] <whiprush> jsgotangco: try removing ttf-arphic-uming (worked for me)
[03:41] <jsgotangco> hmm my connection drops
[03:41] <jsgotangco> race?
[04:05] <psusi> that's nice... a trusted CA, 'geotrust' issued an SSL certificate to a phisher for a credit union's web site.... it seems they don't perform any kind of verification when issuing certs beyond an automated script that checks if the domain name is similar to known banks, and a WHOIS
[04:06] <ajmitch_> psusi: and that's a fairly ftal problem with those 'trusted' CAs
[04:06] <psusi> ftal?
[04:06] <ajmitch_> s/ftal/fatal/
[04:06] <ajmitch_> sorry, lagged ssh :)
[04:06] <psusi> yea... when you trust someone to perform due dilligence, and they don't.. that's a problem
[04:06] <psusi> time to remove them from the list of trusted CAs
[04:07] <jsgotangco> yeah
[06:06] <crimsun> heh, nice "Rent" quote in udev 079-0ubuntu11.
[06:56] <LaserJock> ok, so what happens after Feature Freeze? only new ubuntuX versions?
[06:59] <crimsun> only new package revisions; no new versions
[06:59] <crimsun> only exceptions are kernel and gnome desktop
[07:00] <crimsun> (and of course anything meeting an uvf/ff exception)
[07:00] <LaserJock> so no new Debian versions? I'm not sure what the difference betwen revisions an version would be
[07:04] <crimsun> revisions == packaging, or A.B.C-Y or A.B.C-YubuntuZ
[07:04] <crimsun> versions == A.B.C
[07:05] <LaserJock> but isn't that UVF
[07:05] <crimsun> yes. What isn't clear?
[07:06] <ajmitch_> feature freeze for us means no new packages
[07:06] <LaserJock> I'm talking about Feature Freeze
[07:06] <crimsun> we can NEW anything up until FF
[07:06] <ajmitch_> for main, it means no new features
[07:07] <LaserJock> so only new ubuntuX version not 0ubuntuX or upstream versons, correct?
[07:08] <ajmitch_> for us, it's generally the same as before
[07:08] <ajmitch_> with the exception that for dapper we're stopping accepting new packages off revu
[07:09] <LaserJock> ok
[08:06] <dolson> geez, why doesn't debuild -S -sa see the .orig file?
[08:07] <minghua> dolson: it should
[08:07] <dolson> hmm, that time it did... that is weird
[08:07] <dolson> the first time it didn't and I haven't changed anything
[08:08] <dolson> very strange.. oh well, dput time
[08:17] <minghua> Mez: ping
[08:53] <dholbach> good morning
[09:23] <dolson> morning dholbach
[09:24] <dholbach> hey dolson
[09:25] <dolson> I whipped up a script to check the breezy, dapper, and sid package lists against the list of apps that we think we need, and there are only 15 packages left that I or forest have not done yet
[09:28] <dolson> only one of the missing apps is in sid
[09:30] <Gloubiboulga> morning
[09:31] <dolson> morning Gloubiboulga
[09:31] <Gloubiboulga> hey dolson
[09:35] <Gloubiboulga> dholbach, hello!
[09:35] <dholbach> hey Gloubiboulga
[09:35] <Gloubiboulga> dholbach, do you have some news about the Texmaker UVF exception ?
[09:35] <dholbach> it's all on the mailing list
[09:35] <Gloubiboulga> oh ok
[09:35] <dholbach> i requested it yesterday
[09:35] <dholbach> afaik
[09:48] <dolson> dholbach: I've uploaded a couple more, and fixed the one you said to fix. working on another one now. this is fun. :)
[09:48] <dholbach> Cool.
[09:48] <dholbach> I'm currently quite busy with GNOME updates
[09:49] <dholbach> as soon as i get a break, i'll take a look
[09:49] <dolson> yeah, I noticed a whole whack of updates today
[09:49] <dolson> aww, thanks! will you be my valentine?!
[09:49] <dholbach> Sure. :-)
[09:49] <dolson> hah, hope my wife doesn't mind
[09:50] <dolson> meh, she's visiting her mom right now anyhow, who cares
[10:48] <dolson> another one bites the dust
[10:59] <viviersf> gyts
[10:59] <viviersf> * guys
[10:59] <viviersf> any1 have an idea why i cant setup a localle in a chroot ?
[11:02] <viviersf> ok nm
[12:00] <dolson> aw crap, it's 6am :( bed time.
[12:17] <sebest_> anyone using vmware-server on ubuntu breezy, i'm looking for libssl.so.4
[12:21] <Yagisan> sebest_: have openssl installed ?
[12:23] <sebest_> Yagisan, yes
[12:23] <sebest_> i had to do a link :s
[12:24] <sebest_> to libssl.so.0.9.7
[12:24] <sebest_> the httpd from vmware-server webui needs libssl.so.4
[12:27] <Yagisan> sebest_ I've never actually tried vmware sever, so I just took a guess.  I've had gtkpod-aac there for a while now
[12:58] <siretart> tepsipakki: what is your email?
[12:58] <tepsipakki><EMAIL_ADDRESS>[12:59] <tepsipakki> I can see the gpg-message, but there's nothing in it
[01:00] <siretart> not even a 'None'?
[01:02] <tepsipakki> well yes, but that apparently doesn't work
[01:03] <tepsipakki> are there any MOTUs who use VDR, or are in the debian vdr-team?
[01:03] <siretart> ok
[01:05] <tepsipakki> the current version of VDR doesn't start when an UTF8-locale is in use.. the init-script needs to be hacked ;)
[01:07] <siretart> tepsipakki: you're right, there went something really strange with your account
[01:07] <siretart> tepsipakki: what package did you upload?
[01:08] <tepsipakki> gtkpod-aac
[01:09] <tepsipakki> it's just that the freeze is upon us =)
[01:09] <tepsipakki> that package is for multiverse, I believe..
[01:10] <siretart> gnarf, you didn't use<EMAIL_ADDRESS>in your changelog, thats the problem
[01:10] <tepsipakki> oh? isn't that e-mail taken from the gpg-key?
[01:11] <siretart> well, you have several uids on your key, and I made some bad assumption which I wanted to fix in revu2
[01:11] <siretart> wenn I find time to code it, that is :/
[01:11] <siretart> I just mailed your pass to you, btw
[01:11] <siretart> check your email
[01:12] <tepsipakki> yes, thanks!
[01:42] <siretart> crimsun: around?
[02:42] <zakame> evening MOTUs
[02:44] <jpatrick> hello zakame
[02:44] <zakame> hello jpatrick :) how's everything?
[02:44] <jpatrick> fine :)
[02:45] <jpatrick> just trying to get kubuntu-es.org back up
[02:45] <jpatrick> you?
[02:46] <zakame> prepping up for a couple of talks this thursday, about FOSS and Linux, general stuff
[06:10] <fbond> hello all
[06:10] <fbond> does anyone have time to build/review package dssi:
[06:10] <fbond> http://revu.tauware.de/details.py?upid=1783
[06:17] <jpatrick> fbond: wow, looks good to me
[06:36] <fbond> jpatrick: thanks!
[06:38] <fbond> does anyone have REVU admin access, and wants to build dssi?  sorry to pester, just got some other packages that i need to finish up and build-depend on dssi-dev
[07:43] <LaserJock> man, it's quiet this morning
[08:03] <seth|away> fbond, set up a local apt repository
[09:19] <sistpoty> hi folks
[09:19] <jpatrick> hello
[09:26] <ompaul> there was a little note on the wiki about turning up in #motu if you thought you had an idea for improving ubuntu - so here goes - imagine a situation where the machine could be turned back to the way it was when it started, killing off all gnome configuration, all additional packages, and then it provides a list of packages that were removed to get to this state of post install- this would include removing all patches all packag
[09:26] <ompaul> es other than the base and reverting the .gnome2 for users to its original state
[09:27] <ompaul> go back a kernel version or two interesting?
[09:29] <dholbach> http://wiki.ubuntu.com/IdeaPool might be more appropriate or even better https://launchpad.net/distros/ubuntu/+addspec
[09:29] <dholbach> #ubuntu-motu is about maintaining the Universe component of Ubuntu
[09:55] <Riddell> raphink: motu-reviewers mailing list?
[09:55] <raphink> yes Riddell
[09:55] <Riddell> where's that?
[09:55] <Riddell> hmm, the super secret tauware.de domain
[09:56] <raphink> haha
[09:56] <raphink> no its no secret
[09:56] <Riddell> is that advertised anywhere?
[09:56] <raphink> it's even advertised on the main page of REVU
[09:56] <LaserJock> yes, super secret, only sabdfl knows where it truely is ;-)
[09:57] <dholbach> tauware.de/cgi-bin/mailman/listinfo/motu-reviewers
[09:57] <raphink> Riddell: on revu it says :
[09:57] <raphink><EMAIL_ADDRESS>    Pass: okioyouk     Login
[09:57] <raphink>  BREAKING NEWS:
[09:58] <Kyral> Is the issue about the boot sequence broken known?
[09:58] <Riddell> ahem
[09:58] <raphink>  The system now works and sends the notifications to<EMAIL_ADDRESS>[09:58] <raphink> ooops
[09:58] <raphink> bad konqui
[09:58] <jpatrick> :/
[09:58] <raphink> huhu
[09:58] <Riddell> how the heck did konqi put a password in the clipboard?
[09:58] <raphink> ajmitch_: could you please change my REVU password :s ?
[09:58] <raphink> Riddell: good question ...
[09:59] <Riddell> that's quite a significant security issue
[09:59] <raphink> Riddell: indeed
[09:59] <raphink> Riddell: they were starts on the page though
[10:00] <Riddell> wow, it does it for me too
[10:00] <Riddell> that's insane
[10:01] <raphink> very insane Riddell
[10:01] <raphink> and I guess it works on all websites
[10:01] <raphink> this must be reported
[10:01] <raphink> all the more as konqui remembers passwords
[10:01] <Riddell> yes, checked on random other website, happens there too
[10:03] <Riddell> can't non MOTUs get commenting rights if they ask now?
[10:04] <LaserJock> well, I think they can but it would take a really good non-MOTU that has shown that they know what they are doing
[10:05] <Riddell> allee would be a good example
[10:06] <Riddell> being a debian packager who likes to comment on revu packages
[10:09] <sistpoty> Riddell: revu1 is just too messy to hack in comments from non-motu's... but if comments go to motu-reviewers, i usually post them on revu
[10:09] <dolson> dholbach: thanks for the reviews,  I will look up debian/install now and fix the packages asap
[10:09] <Riddell> right
[10:12] <dholbach> dolson: rock! :)
[10:12] <sistpoty> raphink: password updated
[10:12] <raphink> sistpoty: thanks
[10:12] <sistpoty> np
[10:12] <raphink> sistpoty: maybe I could learn to change passwords, since I'm a REVU admin :s
[10:12] <raphink> could be useful
[10:13] <LaserJock> lol, I guess I won't be putting any passwords in konqi for a while
[10:13] <sistpoty> raphink: in /srv/revu1/scripts see alter_user.py ;)
[10:13] <raphink> LaserJock: hehe
[10:13] <raphink> thanks sistpoty :=)
[10:13] <Riddell> I've never noticed this konq password clipboard issue, I wonder if it's a new problem
[10:13] <raphink> I'll havea look
[10:14] <sistpoty> (so I still do it directly in the database *g*)
[10:14] <sistpoty> s/so/though/
[10:22] <Kyral> LJ is going for MOTU?
[10:23] <LaserJock> Kyral: we will see
[10:23] <Kyral> I feel so outta touch now
[10:24] <LaserJock> Kyral: don't worry I just decided to make a try
[10:34] <LaserJock> hmm, that didn't go too bad, I guess
[10:35] <jpatrick> LaserJock: it's going quicker than mine
[10:36] <LaserJock> jpatrick: yeah, but you got +1s in the end ;-)
[10:36] <sistpoty> LaserJock: actually I thought you were a motu already :/... if I knew it earlier, I could have taken a look at some of your packages
[10:36] <sistpoty> :(
[10:36] <Spec> apt-cache showpkg <package> should show the package maintainer, right?
[10:36] <LaserJock> no problem, it was somewhat of a spur of the moment thing
[10:37] <thesaltydog> who is in charge of synch-ing from debian?
[10:37] <jpatrick> LaserJock: I got the spanish inquisition
[10:37] <sistpoty> thesaltydog: elmo does the syncs... what package are you referring to?
[10:37] <ogra> and note we are in UVF ...
[10:38] <thesaltydog> few weeks ago I have fixed a bug on BUM, but maybe it came out on debian when dapper was already frozen
[10:38] <thesaltydog> malone bug 29831
[10:38] <Ubugtu> malone bug 29831 in bum "BUM leaves lock file around after failing to start" [Normal,Fix released]  http://launchpad.net/bugs/29831
[10:42] <thesaltydog> if synching could be  a big problem, don't care.
[10:44] <sistpoty> thesaltydog: it's a new upstream release... I'll take a closer look (and will call for UVF-exception)
[10:50] <thesaltydog> sorry but my line went down and I haven't got any answer.
[10:51] <sistpoty> thesaltydog: it's a new upstream version, so I'll need to request and UVF-exception... but I'm just taking a look at bum ;)
[10:52] <thesaltydog> sistpoty: thanks. As I said, if it is too much work, don't care. Users could download deb from my site...
[10:52] <thesaltydog> or from debian.
[10:53] <sistpoty> thesaltydog: if it's bugfixing, than it's just work that needs to be done anyway ;)
[10:53] <thesaltydog> ok. thanks!
[10:53] <sistpoty> thx for informing us ;)
[10:55] <thesaltydog> sistpoty: np.
[10:57] <sistpoty> thesaltydog: lintian complains: "W: bum: menu-command-not-in-package /usr/share/menu/bum:4 /usr/bin/gksudo"... is this an issue? (I don't know anything about sudo menu entries actually...)
[10:58] <thesaltydog> sistpoty: no. bum starts with gksudo. This warning just came out now, and I don't know why. For sure I cannot include gksu in the package!
[10:58] <phanatic> hi people
[10:59] <Kyral> hmm
[10:59] <Kyral> CDBS worked...
[10:59] <sistpoty> thesaltydog: yes, that for sure... but the menu entry changed from the last version: "command="/usr/sbin/su-to-root -X -c /usr/bin/bum"... (and I just don't know what should be there, that's what i mean)
[11:01] <thesaltydog> sistpoty: I have also tested with su-to-root, and the warning is still there. Putting gksudo in the menu is more standard then su-to-root, so I have changed.
[11:01] <Kyral> Why did I half expect CDBS to fail...
[11:01] <sistpoty> thesaltydog: ah, thanks
[11:03] <Kyral> ..gak...
[11:03] <Kyral> Its alright for me to modify the Orig tarball so that the dir inside is all lowercase right...
[11:03] <thesaltydog> goddnight sistpoty, and thanks again!
[11:04] <sistpoty> goodnight thesaltydog
[11:04] <sistpoty> Kyral: no
[11:04] <sistpoty> Kyral: why would you need to change the .orig for that reason?
[11:04] <Kyral> dh_make complains if its not in lowercase, yet I cannot modify it
[11:05] <Kyral> because the build is expecting it in lowercase
[11:05] <Kyral> but it comes out of the orig in "normal"
[11:05] <sistpoty> Kyral: do you mean the root-dir of the orig-tarball?
[11:05] <Kyral> so the build fails
[11:05] <Kyral> yah
[11:06] <sistpoty> Kyral: that usually shouldn't be a problem... you can rename it, call dh_make and still have the orig.tar.gz unchanged... dpkg-source will usually take care to rename the root-dir correctly if the sourcepackage is extracted
[11:06] <Kyral> hmm
[11:06] <Kyral> I wonder why its failing then...
[11:07] <sistpoty> Kyral: do you have the package publicly available? then I might take a look
[11:08] <Kyral> yah I'll put it on my server
[11:08] <Kyral> Keep in mind its no where near clean
[11:08] <Kyral> I make sure it builds first, then I clean it :D
[11:09] <sistpoty> Kyral: sure, I'll just take a look at it to get it building in the first place ;)
[11:09] <ajmitch_> hi
[11:10] <sistpoty> hi ajmitch_
[11:10] <LaserJock> hi ajmitch_
[11:11] <Kyral> http://azuredream.homelinux.org/aptwork/
[11:11] <Kyral> its in a subdir
[11:13] <LaserJock> sistpoty: wow, elmo spam ;-)
[11:14] <LaserJock> would replacing a b-d on xlibs-dev with the explicit packages be worth a merge?
[11:14] <sistpoty> LaserJock: sure
[11:15] <sistpoty> LaserJock: and for your question: sure... if we can have a package back autosynced, it's less work during next merges
[11:16] <Kyral> sistpoty: the sourcepack was made fine, and there was minimal lintian warnings
[11:17] <sistpoty> Kyral: just taking a look at it...
[11:17] <Kyral> ty
[11:17] <Kyral> Its my first time using CDBS so I wasn't expecting it to go smoothly
[11:17] <sistpoty> Kyral: but dpkg-source does it's job well... the mixed case dir from .orig.tar.gz is gpixpod-0.2.3/ after I do dpkg-source -x *dsc
[11:17] <Kyral> okay...then why didn't it find setup.py?
[11:17] <LaserJock> Kyral: why wouldn't you expect CDBS to work?
[11:18] <Kyral> LaserJock: I don't expect my first time doing anything to go smoothly ;P
[11:19] <LaserJock> oh, well that makes sense
[11:20] <dolson> can someone think of a simple example off the top of their heads that uses a .install file and dh_desktop?
[11:20] <Kyral> EasyChem?
[11:20] <Kyral> GTKEdit?
[11:20] <dolson> thanks
[11:20] <Kyral> I had to write those files from scratch for both ;P
[11:21] <Kyral> Actually I have to file a UVF Exception for GTKEdit...
[11:21] <dolson> I just don't see anything about them in the DNMG and the man pages don't tell me what I need to know
[11:21] <LaserJock> dolson: as far as what?
[11:21] <dolson> using a .install file or dh_desktop
[11:21] <Kyral> .install is easy
[11:21] <Kyral> as is dh_desktop
[11:22] <dolson> for instance, the man page for dh_desktop says it doesn't install the .desktop files
[11:22] <dolson> so I don't understand why to use it
[11:22] <Kyral> Yah you use dh_install
[11:22] <Kyral> because it registers them
[11:22] <dolson> but I don't know what that means... because my .desktop files show up in my menu when I install the package, even without using dh_desktop
[11:23] <LaserJock> dolson: it runs update-desktop-databse
[11:24] <sistpoty> Kyral: if you just use debhelper.mk and python-distutils.mk in your makefile, it builds fine... might be either the variables you define or tarball.mk
[11:24] <Kyral> sistpoty: okay
[11:24] <sistpoty> s/makefile/debian\/rules/
[11:24] <Kyral> I'll try that after dinner
[11:24] <Kyral> and also simplepatchsys has to go
[11:24] <Kyral> since I don't use it
[11:25] <Kyral> But I found it odd that although I left all the .ex files in the package...lintian didn't pick up on them
[11:26] <sistpoty> Kyral: lintian must leave some work for manual inspection :)
[11:26] <Kyral> sistpoty: I'm used to it complaing about that :P
[11:27] <sistpoty> *g*
[11:27] <Kyral> I mean I knew they were there ;P
[11:27] <sistpoty> Kyral: don't forget to run lintian on the generated debs as well... (and fix the issues there) ;)
[11:29] <Kyral> sistpoty: I know my stuff. EasyChem wouldn't have wound up in Sid otherwise
[11:29] <sistpoty> :)
[11:29] <Kyral> That did it
[11:29] <Kyral> Built fine in my PBuilder
[11:29] <Kyral> ty sistpoty
[11:29] <sistpoty> np
[11:30] <Kyral> ...gah I need to clean out my PBuilder Result dirs...
[11:30] <Kyral> Lintian is completely ignoring those .ex files, even with the built deb
[11:31] <Kyral> Did cdbs remove them or something?
[11:31] <sistpoty> they aren't in the built deb ;)
[11:31] <Kyral> anyway I'll polish it later...I'm hungry
[11:31] <sistpoty> cdbs didn't install them... (and neither debhelper), because they are called .ex and not anything else
[11:31] <sistpoty> good appetite
[11:39] <dholbach> good night guys - we'll have a ROCKING REVU DAY tomorrow!
[11:42] <ajmitch_> oh right, revu
[11:44] <LaserJock> hmm, I was kinda hoping to help. I'll have to work on syncs/merges instead. :-)
[11:48] <sistpoty> LaserJock: you can just post reviews to motu-reviewers list ;)
[11:48] <ajmitch_> eek, doko on the warpatj, dropping many python 2.3 packages
[11:48] <ajmitch_> s/patj/path/
[11:49] <ajmitch_> I wonder how many zope products might break now
[11:51] <LaserJock> ajmitch_: zope uses a lot of 2.3?
[11:51] <sistpoty> ajmitch_: btw.: what should packages, that used to depend on zope3 depend now? (and might there be issues?)
[11:52] <ajmitch_> LaserJock: zope <= 2.8 only uses 2.3
[11:52] <ajmitch_> sistpoty: huh?
[11:52] <sistpoty> ajmitch_: oh, it's zope3 that has an unmet dependency... I just noticed zope3 being unmet in (at least one package)
[11:53] <ajmitch_> sistpoty: yes, it depends on python2.4-mechanize, which needs dragged in from sid
[11:53] <sistpoty> ajmitch_: do you care about that? ;)
[11:53] <sistpoty> s/care/take care/
[11:54] <ajmitch_> it's in main, so I could, I suppose
[11:54] <ajmitch_> though doko has been handling that side of things
[11:54] <sistpoty> ah, k
[11:55] <ajmitch_> I think it's a sync for elmo to handle, after clearing it with mdz/kamion


[10:11] <guest1234> hi guys, yesterday I run ubuntu studio 17 in Vbox and had a problem. I could not get interne working. My fix was to add DNSSEC=off to resolved.conf  and reboot my machine. (like told here: https://github.com/cpriego/valet-linux/issues/7)
[10:11] <guest1234> *internet
[10:12] <guest1234> in case s.o. has the same prob