[00:00] <hackeron> Whoops, sorry that should be Chipaca
[07:28] <zyga> good morning!
[07:29] <zyga> Caelum: hey
[07:30] <zyga> Caelum: to answer your question, snappy used to do that in 15.04 days
[07:30] <zyga> Caelum: snappy used a/b updates exclusively
[07:30] <zyga> Caelum: but this method used way too much space
[07:31] <zyga> Caelum: snappy now uses a single writable space and can use any rootfs and kernel without unpacking them, if the architecture supports that
[07:31] <zyga> Caelum: so we can have any number of new core snaps, new kernel and new gadgets to test
[07:32] <zyga> Caelum: and choose the one to run in the boot loader
[07:32] <zyga> Caelum: this is especially important on devices with very littte storage
[07:32] <zyga> Caelum: but in general it means that you have all the space to use
[07:32] <zyga> Caelum: and as for mender, you can ask mborzecki next week, he used to work on mender before he joined canonical
[07:37] <zyga> hackeron: ^
[07:37] <zyga> hackeron: sorry, I'm not really awake yet it seems, this was the answer for your questions
[07:38] <zyga> hackeron: the way we can do this is that the boot loader can pick wich kernel to load and in turn the kernel can pick (based on bootloader data) which rootfs to mount (from squashfs)
[07:59]  * zyga -> breakfast
[09:19] <jamesh> zyga: hi.  w.r.t. my document-portal branch, the main issue at the moment is how to handle systems without the document portal available.  I don't want snapd trying to create missing directories, so what do you think of an extra mount option to tell it to ignore when there is a missing source path? (and maybe target path?)
[09:20] <zyga> hmm
[09:20] <zyga> x-snapd.no-create-{source,target} ?
[09:20] <zyga> something like this?
[09:20] <jamesh> I was just thinking of x-snapd.ignore-missing
[09:20] <jamesh> but no-create could work too
[09:21] <zyga> or x-snapd.skip-if-missing
[09:21] <zyga> something appropriate
[09:21] <zyga> but yeah, +1 on the idea
[09:21] <zyga> I'm wondering what's wrong with CI
[09:21] <zyga> everything is read
[09:21] <zyga> red
[09:21] <jamesh> I'm thinking doing the check on the source only would be sufficient
[09:21] <zyga> for this case, yes
[09:22] <jamesh> this could also be used for the host font mounts, where we currently check if the various font directories exist on the host before adding the mount entries
[09:22] <jamesh> we could just add them unconditionally with the ignore-missing option
[09:25] <zyga> yeah, that's a nice cleanup
[09:27] <jamesh> zyga: btw, CI finally passed on https://github.com/snapcore/snapd/pull/5082
[09:27] <mup> PR #5082: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5082>
[09:28] <zyga> did it pass just now?
[09:28] <jamesh> that was from earlier today
[09:28] <jamesh> 2 hours ago according to Travis
[09:28] <zyga> hmm, let's hope that whatever was slower/wrong is fixed now
[09:29] <zyga> I saw that some branches exceeded 49 minute mark
[09:29] <zyga> perhaps store downloads are much slower (or were) lately
[09:29] <jamesh> I haven't tried to prod https://github.com/snapcore/snapd/pull/5116 again: last time it failed with the debian backend timing out
[09:29] <mup> PR #5116: interfaces: move host font update-ns AppArmor rules to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5116>
[09:29] <jamesh> It's probably okay though
[09:34] <mup> PR snapd#5124 opened: many: add `snapd.seeded` service <Created by mvo5> <https://github.com/snapcore/snapd/pull/5124>
[09:45] <Odd_Bloke> \o/
[10:37] <doko> mvo: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dpkg snapd autopkg test failures
[11:08] <cachio_> Chipaca, I have updated the arch image to avoid this problem when rebooting
[11:08] <Chipaca> cachio_: what was the issue?
[11:08] <cachio_> I found an issue in the snapd test code doing that
[11:08] <cachio_> the issue that the google shutdown script hungs
[11:09] <cachio_> more than 30 minutes when the machine is shuting down
[11:11] <cachio_> Chipaca, we don't configure that shutdown script, it already comes with the image and we don't use it
[11:11] <Chipaca> cachio_: and the state error?
[11:12] <cachio_> Chipaca, still working on the other error where snapd does not start properly after reboot
[11:12] <Chipaca> cachio_: ah ok
[11:13] <Chipaca> cachio_: i thought it was that one that you'd figured out :-D
[11:13] <cachio_> there are 2 issues around arch
[11:13] <Chipaca> cachio_: 1. ar, 2. ch
[11:13] <Chipaca> ?
[11:13] <cachio_> Chipaca, no, the other one
[11:13]  * Chipaca hides
[11:14] <mup> PR snapd#5125 opened: spread: add adt for ubuntu 18.10 <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5125>
[11:14] <cachio_> the other was more important beause it could leave headless machines also preparing the test suite because arch is also rebooted there
[11:15] <Chipaca> cachio_: and it gets expensive, also
[11:15] <cachio_> yes
[11:16] <cachio_> Chipaca, then I found our test code fails when we have an arch image which has not any package to install during the upgrade
[11:16] <cachio_> I need to talk to maciej about this
[11:17] <zyga> doko: addressed in master,
[11:24]  * Chipaca -> lunch, probably
[11:27] <zyga> Chipaca: #5125
[11:27] <mup> PR #5125: spread: add adt for ubuntu 18.10 <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5125>
[11:35] <mup> PR snapd#5126 opened: cmd/snap-update-ns: add support for ignoring mounts with missing source/target <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5126>
[11:36] <jamesh> zyga: ^^^ here's a branch implementing the ignore-missing logic
[11:36] <zyga> jamesh: ack, thank you
[11:42] <zyga> jamesh: reviewed
[11:45] <jamesh> zyga: thanks.  I've made the change
[11:45] <cachio_> Chipaca, https://paste.ubuntu.com/p/gcGHFVYYmf/
[11:45] <cachio_> Service hold-off time over, scheduling restart
[11:46] <cachio_> it is taking few minutes to start after reboot and I see this log
[11:46] <Chipaca> cachio_: the hold off is set to 0, ie no hold off afaik
[11:46] <Chipaca> cachio_: snapd is crashing
[11:47] <Chipaca> or otherwise not happy
[11:48] <cachio_> Chipaca, :(
[11:48] <Chipaca> cachio_: question is, why don't we see the debug messages
[11:48] <cachio_> I'll increase the journlal log to degug
[11:48] <Chipaca> cachio_: SNAPD_DEBUG=1 is set, right? (in the .conf.d thing
[11:48] <cachio_> yes
[11:48] <Chipaca> so we should be seeing them
[11:48] <Chipaca> ah, i don't know how our debug interops with journald's
[11:49] <Chipaca> anyway, i need to get lunch
[11:49] <cachio_> Chipaca, sure
[11:49] <Chipaca> bbiab
[11:49] <cachio_> enjoy it
[11:54]  * cachio_ afk
[11:58] <doko> zyga: I don't care, I need it in cosmic
[11:58] <doko> will haress mvo in person ... ;p
[12:03] <zyga> doko: is c- named now?
[12:13] <jamesh> zyga: I'm knocking off for the day.  I think all my PRs except the xdg-document-portal one (i.e. #5082, #5116, and #5126) should be ready to land if you're happy with the code.
[12:13] <mup> PR #5082: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5082>
[12:13] <mup> PR #5116: interfaces: move host font update-ns AppArmor rules to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5116>
[12:13] <mup> PR #5126: cmd/snap-update-ns: add support for ignoring mounts with missing source/target <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5126>
[12:14] <zyga> yeah, I really hope to get some 2nd review but today may be tough
[12:14] <zyga> thank you for this! it's very close to being all in
[12:15] <jamesh> yeah.  There's probably some more stuff needed to get portals working really well, but I think we're reaching the end of the mount related parts
[12:15] <jamesh> you've been a great help with all this
[12:18] <jdstrand> niemeyer: hey, the forum seems to be down
[12:20] <jdstrand> zyga: can you tg niemeyer? ^
[12:20] <zyga> ack
[12:20] <jdstrand> thanks
[12:21] <niemeyer> Will look into it
[12:22] <niemeyer> Seems back
[12:22] <niemeyer> jdstrand, zyga: ^
[12:22] <zyga> confirmed
[12:23] <doko> let's make it cockroach
[12:24] <jdstrand> huh, weird
[12:24] <jdstrand> niemeyer: it does indeed seem to be working again. it was several pages in the span of a few minutes
[12:24]  * jdstrand is curious if the snap got upgraded
[12:24] <niemeyer> jdstrand: Might have been a forced reboot
[12:39] <zyga> Chipaca: standup today?
[12:40] <zyga> my daughter just asked me to go to a coffee shop for a shake
[12:40] <Chipaca> zyga: I don't have anything
[12:40] <zyga> I'm preparing some code for next week
[12:40] <zyga> and I'm looking at the forum, one case is interesting again
[12:40] <zyga> the lowercase vs uppercase bug
[12:44] <mup> PR snapd#5125 closed: spread: add adt for ubuntu 18.10 <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5125>
[12:47]  * zyga preps laptop for the move
[13:18] <zyga> re
[13:19] <zyga> organizing kids == going into production :)
[13:36] <mup> PR snapd#5127 opened: HACKING: fix typos <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5127>
[13:38]  * zyga removed a bucket load of stale braches
[13:40] <Son_Goku> zyga, it looks like snappy is finally getting looked at in opensuse-factory
[13:40] <Son_Goku> in the ML
[13:41] <zyga> Son_Goku: oh, I need to check then
[13:41] <zyga> I have to file some bugs but I was looking for someone that would be interested in guiding me from the other end, I think we may finally got that
[13:42] <Son_Goku> zyga, well, I could have helped you too :P
[13:42] <Son_Goku> I've gotten my fair share of packages in openSUSE :)
[13:42] <zyga> Son_Goku: you _always_ help :-)
[13:42]  * zyga hugs Son_Goku
[13:42] <zyga> thank you
[13:42] <zyga> and I'm sorry about that vodka
[13:42] <Son_Goku> haha
[13:42] <Son_Goku> it only took you a year to apologize :P
[13:43] <zyga> I was secretly hoping you would enjoy it after some time
[13:43] <Son_Goku> yeah, that didn't happen
[13:44] <zyga> Son_Goku: the systemd unit thing is a clear win for presets
[13:44] <Son_Goku> yes
[13:45] <Son_Goku> but fortunately that's easy to do
[13:45] <Son_Goku> we've done that rodeo before
[13:45] <zyga> Son_Goku: the rpmlint thing is a two fold case: one is easy (I suspect) - the polkit side
[13:45] <zyga> the other one is probably just us aking and waiting but I don't know
[13:45] <Son_Goku> Simon let me know that the FHS compliance check in rpmlint is going to turn from a warning to an error soon
[13:45] <Son_Goku> it's technically an error by policy
[13:45] <zyga> the /snap thing is something I'd like not to change and I would argue that it makes sense to do FHS aside (until FHS allows for /snap eventually when everyone will say "of course it should be /snap, read the FHS man" ;-)
[13:46] <zyga> Son_Goku: it's all about what suse wants
[13:46] <zyga> if they want it in, that's in
[13:46] <Son_Goku> what I never understood is why wasn't it /run/snap/ for snap mounts?
[13:46] <Son_Goku> the mounts are managed as systemd units, so they come up early enough anyway
[13:48] <zyga> Son_Goku: it could be but that's not what (I think) this is about
[13:48] <zyga> it's about the /snap being a first-class concept and the /snap/bin launchers being visible easily
[13:49] <zyga> Son_Goku: even with /run/snap/ with mount points, you need /snap/bin
[13:49] <Son_Goku> ah, right, you need a persistent place for the bin files
[13:49] <zyga> and the concept can be grown, maybe we will do /snap/man/
[13:49] <Son_Goku> that's why we put it in /var/lib/snapd/snap
[13:49] <Son_Goku> I feel like maybe we should split the two
[13:49] <zyga> yeah, which is a "unnice" place because it is "far", I think this is just that
[13:50] <zyga> Son_Goku: splitting it out would be fine IMO
[13:50] <zyga> they are managed by one variable today
[13:50] <zyga> but it should be non-painful to fix
[13:50] <Son_Goku> the location where the mounts are and where the persistent files are would make it better
[13:50] <Son_Goku> and less dumb for other reasons
[13:50] <zyga> what may be more painful is that snapd doesn't manage exisitng mount units
[13:50] <zyga> it doesn't update them in place
[13:50] <zyga> I would say that this is a prerequisite
[13:50] <Son_Goku> doesn't that happen on snap refresh?
[13:50] <zyga> it does
[13:51] <Son_Goku> we could force a refresh on upgrade
[13:51] <zyga> but it also affects unit names
[13:51] <Son_Goku> to migrate all the units
[13:51] <zyga> we would need some non-trivial code to get the transition correctly
[13:51] <Son_Goku> hmm
[13:51] <zyga> (should I stop snap-$SNAP_NAME-$SNAP_REVISION.mount
[13:51] <Son_Goku> maybe a helper program that would be executed for migrating legacy locations to the new split layout?
[13:51] <zyga> or that other ting)
[13:51] <zyga> well
[13:51] <zyga> in all cases
[13:51] <zyga> I think it sucks because it's a transition
[13:51] <zyga> and it can go south on us
[13:52] <Son_Goku> historically, transitions aren't handled very well in snapd :/
[13:52] <zyga> so I'd really do something this cosmetic only iff we had a solid framework for altering those units correctly
[13:52] <Son_Goku> right
[13:52] <Son_Goku> we probably should have it for other reasons
[13:52] <zyga> well, it depepnds on which one but yeah, it's complex to do
[13:52] <zyga> offtopic
[13:53] <zyga> deja-dup / duplicity suck at backups
[13:53] <zyga> they are so worthless I cannot believe there's nothing better that's also simple
[13:53] <zyga> I'm trying to backup while on my LTE data
[13:53] <zyga> and so far I'm streaming the backup back here
[13:53] <zyga> to "compare"
[13:53] <zyga> how moronic is that
[13:53] <zyga> it's been going on for an hour at least
[13:54] <Son_Goku> there's definitely good backup solutions
[13:54] <Son_Goku> I'd probably agree those two aren't it
[13:54] <zyga> Anything that is nice on a laptop and not highly complex?
[14:01] <popey> restic?
[14:05] <zyga> restic?
[14:06] <popey> snap install restic ;)
[14:06] <popey> https://restic.net/
[14:07] <popey> "Backups done right!" (apparently)
[14:19] <popey> cjwatson: I have a snap which appears to have gotten wedged in launchpad https://launchpad.net/~build.snapcraft.io/+snap/4b4138ec2bc6c3cd4339177e27938c64-xenial/+build/208186
[14:19] <popey> it says it's been building for 22 hours.  but looks stuck
[14:23] <kyrofa> zyga: I've been pretty impressed with the nextcloud clients
[14:23] <cjwatson> popey: I've cancelled it to free up the builder, but I don't know what the actual problem is
[14:24] <popey> I'll re-trigger if that's okay, to see if it was a one-time thing?
[14:30] <zyga> kyrofa: thanks for the advice
[14:31] <zyga> Texting while riding a bike is not safe
[15:45] <zyga> re
[16:27] <popey> diddledan: we're looking into the gimp 2.8 issue
[16:27] <mup> PR snapcraft#2120 closed: many: dedup environment entries <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2120>
[16:32] <popey> zyga: how can i find the revision number for a previous release of core, I'm trying to debug something and need to go backwards
[16:32] <zyga> popey: AFAIK you cannot easily
[16:32] <popey> that is frankly insane
[16:32] <zyga> popey: snap list --all
[16:32] <zyga> if you have it
[16:33] <zyga> if you are a contributor you can see the channel map
[16:33] <diddledan> what's the issue, popey ?
[16:33] <zyga> but there is no easy nice history
[16:33] <popey> gimp wont launch at all anymore
[16:33] <diddledan> oh
[16:33] <zyga> !
[16:33] <diddledan> fudge
[16:33] <popey> https://github.com/snapcrafters/gimp/issues/17
[16:33] <diddledan> I'm currently working on getting 2.10 building
[16:33] <popey> broken on 16.04, 17.10, 18.04. All on 2.32.5
[16:33] <popey> and I want to roll back to .4 but see no easy way to do that
[16:34] <zyga> popey: if you have it locally you can rollback
[16:34] <zyga> if you don't you cannot
[16:34] <zyga> .4 and .5 differ a bit
[16:34] <popey> this is not optimal behaviour
[16:34] <zyga> .5 and .6 a little
[16:34] <diddledan> can we just add the gtkrc file into the build (don't unstage it)
[16:34] <zyga> popey: this is the design
[16:34] <zyga> popey: unless you are a snap owner
[16:34] <popey> I _think_ core 4452 is amd64 2.32.4
[16:35] <popey> so how do I debug this?
[16:35] <zyga> no idea actually
[16:35] <zyga> do you have .4 on disk?
[16:35] <zyga> if not you cannot do it
[16:35] <popey> no
[16:36] <popey> i (as a reviewer) can find the snap in the store and manually download it
[16:37] <popey> ok, done it
[16:37] <popey> gimp works fine on 2.32.4, 2.32.5 broke it
[16:38] <popey> perhaps we were unfortunately relying on broken behaviour in 2.32.4 and that got 'fixed' in 2.32.5?
[16:38] <zyga> popey: hmm
[16:39] <zyga> http://people.canonical.com/~mvo/core-changes/html/stable/2.32.3r4407_2.32.5r4486.html
[16:39] <zyga> .4 was not published, was it?
[16:39] <zyga> 4->5 change was AFAIK tiny
[16:40] <popey> shall i file a bug in snapd?
[16:40] <zyga> please
[16:42] <zyga> popey: I bet it is something else
[16:42] <zyga> .4 and .5 are the same really
[16:42] <zyga> it must be something else that is changing
[16:45] <popey> well, it's something in between revision 4452 and 4486
[16:46] <popey> https://bugs.launchpad.net/snapd/+bug/1769210
[16:46] <mup> Bug #1769210: snapd 2.32.5 broke gimp <snapd:New> <https://launchpad.net/bugs/1769210>
[17:00] <diddledan> gimp is working for me on 2.32.5
[17:01] <popey> wat
[17:02] <diddledan> somehow the error message refers to files which are in a different location - it's trying to copy files from $SNAP/usr/etc when they're installed to $SNAP/etc
[17:02] <popey> try removing it completely and reinstalling
[17:02] <popey> perhaps you already had some of this in snap/gimp
[17:04] <zyga> popey: question, could gimp benefit from layouts?
[17:07] <cjwatson> popey: re-trigger> sure
[17:15] <mup> PR snapd#5128 opened: Revert "Skip test lp-1721518 for arch, snapd is failing to start afte… <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5128>
[17:55] <teward> is there a rule against snap applications requiring donation/payment before you can actually use the applications?
[18:17] <diddledan> super helpful errors for the win (AGAIN!)
[18:17] <diddledan> https://www.irccloud.com/pastebin/2wco9wZB/
[18:18] <diddledan> what kind of error is that? surely I need to know why it thinks lib isn't a directory and what it's trying to do with it to figure out what I did wrong?!!
[19:29] <kyrofa> diddledan: I'd need to see the YAML to help
[19:30] <diddledan> hah
[19:30] <diddledan> it's huge
[19:30]  * diddledan pushes it to git
[19:31] <diddledan> kyrofa: https://github.com/diddledan/gimp-snap/blob/2.10-gold/snap/snapcraft.yaml
[19:31] <diddledan> what's 1400 lines between friends
[19:34] <kyrofa> Oh darn, it's a remote part
[19:34] <diddledan> yeah it was fine until I added the pulseaudio part to that yaml
[19:35] <diddledan> alsa normally installs fine but I've tweaked it for this build to not install any prereqs in the `alsa-plugins` part
[19:35] <diddledan> instead the pulseuadio is supposed to be picked up from my shipped pulseaudio part in gimp's yaml
[19:36] <diddledan> I've got this in the gimp yaml:
[19:36] <diddledan> https://www.irccloud.com/pastebin/ZQQ9O5rq/
[19:37] <diddledan> so something with either the dependency on pulseaudio or the build-packages or stage-packages override is killing it
[19:37] <kyrofa> diddledan, from the error, it sounds like a part that gets staged ahead of alsa-plugins has a lib directory, but somehow alsa-plugins is providing a file there instead of a dir
[19:38] <diddledan> nope, there's no ./lib in parts/alsa-plugins/install
[19:38] <diddledan> there is a ./lib in stage, yes, which is why it's complaining, but what it's trying to do with it I can't tell
[19:39] <kyrofa> Is the lib in stage a directory or a file?
[19:39] <diddledan> it's a directory with libraries in it
[19:40] <kyrofa> diddledan, if there's no lib in parts/alsa-plugins/install, why does it have a `stage` keyword with `lib` in it?
[19:40] <diddledan> o_O
[19:41] <diddledan> ok, I see that now. thanks for the eyes :-) the remote part has a define to include ./lib while staging but that folder doesn't now exist because I overrode the stage-packages to be null
[19:42] <diddledan> we could do with an error condition for such cases, then, where stage: or prime: keywords include references to paths that don't exist
[19:43] <diddledan> that was a much simpler problem than I thought it was going to be
[19:44] <diddledan> I'm gonna clean my build and start it anew to be sure that it's definitely that
[19:45]  * diddledan cuddles kyrofa
[19:51] <mup> PR snapd#5129 opened: cmd/snap-confine: allow any base snap to provide /etc/alternatives <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5129>
[19:51] <zyga> jdstrand: ^
[19:56] <mup> PR snapcraft#2122 opened: many: introduce variables for part src and build <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2122>
[20:02] <mup> PR snapd#5130 opened: interfaces/apparmor: allow bash and dash to be in /usr/bin/ <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5130>
[20:02] <zyga> jdstrand: one more
[20:03] <mup> PR snapd#5127 closed: HACKING: fix typos <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5127>
[20:06] <diddledan> yup, kyrofa , that was the problem - having a path specified in stage: that didn't exist
[20:06] <diddledan> (my build finally got there)
[20:07] <diddledan> twenty minutes of building to get to that point :-p
[20:07] <diddledan> it's not a small build by any means :-D
[20:17] <mup> PR snapcraft#1064 opened: pluginhandler: support colliding with directories <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1064>
[20:25] <kyrofa> diddledan, yeah... I'll never understand why you guys use cleanbuild to iterate :P
[20:26] <kyrofa> You could have just cleaned that one part and tried again
[20:26] <diddledan> :-p
[20:28] <kyrofa> Heck I still iterate on bionic before throwing to LP for final builds
[20:29] <kyrofa> I very rarely use cleanbuild
[20:29] <kyrofa> If I have larger projects, I have lxd containers dedicated to iterating on them so I don't dirty my host
[20:30] <kyrofa> With ccache installed on them, haha
[20:30]  * zyga found a bug in base snaps
[20:30] <zyga> (well, a new bug)
[21:35] <mup> PR snapcraft#2123 opened: file_utils: don't let FileNotFoundError escape <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2123>
[23:26] <mup> PR snapd#5131 opened: tests: fix interfaces-network test for systems with partial confinement <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5131>


[07:41] <pwnguin> is there some secret to finding the bylaws of The xorg foundation?
[07:42] <pwnguin> im trying to figure out whether that pledge drive for nouveau could have been handled by xorg foundation, but the lack of meeting minutes and bylaws is already suggesting "no"
[07:42] <pwnguin> oop, found em
[09:43] <crevette> hello there
[09:43] <pwnguin> hi
[09:51] <crevette> is this normal I can running compiz under intel graphic X3100 ?
[09:51] <crevette> "I can't" sorry
[09:55] <tjaalton> on intrepid? yes, currently
[09:55] <tjaalton> there is a patch for it, but the performance is pretty bad
[09:56] <crevette> okay
[09:56] <crevette> that's fine
[09:56] <crevette> there are a lot of changes on the intel graphics side in intrepid (sorry I don't follow closely developement)
[09:56] <crevette> ?
[09:57] <tjaalton> always :)
[09:59] <tjaalton> mesa 7.1 should have a bunch of changes for the DRI driver, and there's -intel 2.4.0 although it's not yet in intrepid
[10:00] <mvo> meh, I had hoped that the new mesa would have fixed the compiz issues
[10:00] <tjaalton> what issues?
[10:01] <crevette> the performance on intel are really poor, resizing a gtk windows lags a lot for me
[10:01] <crevette> this is really choppy
[10:01] <mvo> didn't you said earlier that you can not run it at all?
[10:01] <mvo> tjaalton: the fact that it would not run at all :)
[10:02] <crevette> mvo, just with metacity
[10:02] <tjaalton> mvo: it's fixed upstream, but the performance is not that good :)
[10:02] <crevette> perhaps I need to blame metacity
[10:03] <mvo> tjaalton: aha
[10:03] <tjaalton> since the "force greedy exa" patches haven't been forward ported
[10:03] <mvo> crevette: I'm still confused. so compiz does *not* run, but metacity does but that (== metacity) is slow?
[10:03]  * mvo nods
[10:04] <tjaalton> but seems like the driver only has 12MB of pixmap memory in its disposal, so that could be the reason
[10:04] <tjaalton> so it's trashing a lot
[10:06] <crevette> mvo, with metacity moving a windows is smooth, but resizing it is painfull slow
[13:20] <superm1> tjaalton, how come all of these bugs from releases earlier to intrepid are being assigned to fglrx-installer?  fglrx-installer is intrepid only
[13:29] <tjaalton> superm1: because they aren't going to be fixed on lrm
[13:30] <superm1> tjaalton,  a lot of what i'm seeing though doesn't even have logs and they are from much earlier releases
[13:30] <superm1> tjaalton, just mark them invalid, they're not going to be triaged if they're that old
[13:30] <tjaalton> superm1: feel free to close them :)
[13:31] <tjaalton> ok, will do in the future
[13:31] <superm1> so just skip the step of reassigning packages in those cases
[13:31] <superm1> thanks
[13:31] <superm1> i'd like to be able to track bugs that are fixable by packaging (there are a few here and there)
[13:31] <superm1> so extra bug mail at this stage doesn't help :)
[13:32] <tjaalton> yeah..
[21:04] <tjaalton> bryce: librecord probably will be enabled on debian too, now that there's actually a package that needs it
[21:06] <bryce> tjaalton: ah ok
[21:08] <bryce> tjaalton: btw I have a first cut for the console2fdi.sh script.  dunno if it's correct, but nothing fancy
[21:08] <bryce> http://pastebin.ubuntu.com/32715/
[21:08] <bryce> untested (obviously... already spotted a syntax error)
[21:12] <tjaalton> bryce: nice! btw, model should always be evdev, and it's already defined in 10-keymap.fdi
[21:14] <bryce> ok
[21:18] <bryce> I think I'll start an input hotplug page in the X wiki for keepign notes
[21:18] <tjaalton> XKBRULES is not defined in console-setup. base is set on 10-keymap.fdi, so that can be dropped as well
[21:21] <bryce> so we should only list it if it's set to something other than base?
[21:21] <bryce> or is it just always base?
[21:21] <tjaalton> always base
[21:22] <bryce> ah, so $XKBMODEL and $XKBRULES are always to be ignored?  we only care about $XKBLAYOUT then?
[21:22] <tjaalton> and variant, options :)
[21:23] <bryce> why is rules always base?
[21:23] <tjaalton> the default layout is also defined on 10-keymap.fdi
[21:24] <tjaalton> oops
[21:25] <tjaalton> XkbRules is set in xorg.conf, but not sourced from /e/d/console-setup
[21:25] <tjaalton> and it's 'xorg' by default
[21:25] <bryce> hmm, sounds inconsistent
[21:26] <bryce> is that a bug or by design?
[21:26] <tjaalton> now if I only know the difference between those two
[21:26] <tjaalton> knew
[21:26] <tjaalton> beats me
[21:26] <bryce> does it change the fact that we should ignore it here?
[21:27] <tjaalton> not unless we change 10-keymap.fdi. so better just set it as 'xorg'
[21:30] <bryce> http://pastebin.ubuntu.com/32721/
[21:32] <bryce> sample output:  http://pastebin.ubuntu.com/32722/
[21:32] <tjaalton> heh, looks simple
[21:33] <tjaalton> typo in capabilities :)
[21:33] <bryce> good catch
[21:37] <bryce> btw, do you have a non-us keyboard setup you could run this script on to doublecheck its output?
[21:37] <bryce> http://people.ubuntu.com/~bryce/InputHotplug/
[21:41] <tjaalton> sure, a sec
[21:42] <tjaalton> yep, looks good
[21:44] <tjaalton> what about adding a notice that says "don't edit this file, edit /e/d/c-s instead and run .."
[21:44] <bryce> yeah
[21:48] <bryce> echo
[21:48] <bryce> echo '<!-- This file is automatically generated, so do not edit it. '
[21:48] <bryce> echo '     Edit /etc/default/console-setup instead, and then run '
[21:48] <bryce> echo '     dpkg-reconfigure xorg-server  -->'
[21:50] <bryce> http://people.ubuntu.com/~bryce/InputHotplug/us-keyboard.fdi
[21:52] <tjaalton> sounds good


[13:08] <David_> I'm trying to install Ubuntu 3.10 fresh from a burned dvd.  I'm unable to install ubuntu because the screen is corrupt upon loading, and I can't see anything (no menus, bars, icons, or even a cursor).  I'm running 2 AMD gfx cards, as I understand they have recently been having issues.  Is there any way around this that I can install ubuntu?


[00:19] <wgrant> wxl: It takes the name of an external bug tracker that's registered in Launchpad. See the search icon next to the box, or https://launchpad.net/bugs/bugtrackers. It's not a very commonly used field.
[02:37] <mwhudson> wgrant: am i misremembering or is there going to be a way to request a particular snap build publishes into a particular channel, independent of the way the snap is configured in launchpad?
[02:56] <wgrant> mwhudson: That's not something that exists or is currently roadmapped.
[02:57] <mwhudson> wgrant: ok thanks
[02:59] <wgrant> mwhudson: What's your use case?
[03:00] <wgrant> Only autobuilds can currently publish, because the snap's configuration is trustworthy while the requestBuilds parameters might not be.
[03:00] <mwhudson> wgrant: i can't really remember :)
[03:50] <wgrant> Launchpad will be shortly going offline for a few minutes for another database upgrade.
[04:40] <wgrant> Everything's been back for a while, and all looks good.
[08:34] <alkisg> Hi, I have an import from github to launchpad bzr, for managing my project translations. It's been failing for months: https://code.launchpad.net/~epoptes/epoptes/epoptes/+index
[08:35] <alkisg> I think that the reason may be a "git --amend; git push --force" that I did in the past; how can I bypass the issue now, do I need to delete and re-create the import?
[09:19] <alkisg> cjwatson: hi, can I somehow test your commits in LP bug #1793266 ? I think it affects all repositories that were imports, and I have 3-4 of them that I would like to delete currently...
[09:19] <ubot5`> Launchpad bug 1793266 in Launchpad itself "Unable to delete repository" [Critical,In progress] https://launchpad.net/bugs/1793266
[09:31] <alkisg> Third question: launchpad recipes do NOT support directly importing from github, right?
[09:31] <alkisg> And fourth and last question: launchpad translations do NOT support importing .po from launchpad git branches, but only bzr branches, right?
[10:11] <wgrant> alkisg: recreating the import is easiest, the deletion stuff isn't ready yet but you can always rename the branch and push or import a fresh one, recipes can't pull directly from GitHub but you can do a git import and build a recipe from that, and git translations integration doesn't exist yet but is vaguely being worked on
[10:12] <alkisg> Thank you for everything wgrant :)
[11:48] <rbasak> spam in https://bugs.launchpad.net/bugs/1721223. Would you prefer a question?
[11:48] <ubot5`> Ubuntu bug 1721223 in Snappy "Networkd fail to set ip address between leases if ip address changes on UbuntuCore" [High,Fix committed]
[13:01] <tsimonq2> I'm getting timeouts with PPAs today, probably related to the upgrade, yeah?
[13:02] <tsimonq2> Ahh, nvm, a blip maybe?
[13:37] <rbasak> Filed https://answers.launchpad.net/launchpad/+question/680167
[14:59] <syllogismrxs> Hello. I'm trying to build opencv4 on launchpad. It builds correctly with pbuilder on my local system, but fails on Launchpad because the opencv CMake downloads files from the internet before the actual build starts. Is there anyway for my Launchpad build environment to access the internet to download files during CMake configure time?
[15:12] <brlin> syllogismrxs: Network access is provided via Proxy AFAICT
[15:15] <syllogismrxs> Hmm, ok. For some reason the opencv CMake project reports an error about not being able to download a file from github. Maybe it's a different problem. I'll keep looking.
[20:57] <wgrant> brlin: only snap builds have any Internet access. It is forbidden for a recipe or binary build to use resources from the Internet.


[15:58] <elacheche> Is there any running meeting right now?
[15:59] <beisner> o/
[15:59] <Kilos> nope
[15:59] <beisner> server team meeting is in ~+1 min here
[15:59] <Kilos> dont think so
[15:59] <Kilos> oh yes sorry
[16:00] <elacheche> Was about to make some tests :D x) I'll do that after the server team meeting than :D thanks beisner for the info :)
[16:01] <beisner> will wait a min for folks to collect
[16:01] <jamespage> o/
[16:01] <beisner> #startmeeting ubuntu-server-team
[16:01] <meetingology> Meeting started Tue Jun  2 16:01:41 2015 UTC.  The chair is beisner. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:01] <meetingology> Available commands: action commands idea info link nick
[16:01] <smb> o/
[16:01] <beisner> greetings!
[16:02] <caribou> o/
[16:02] <coreycb> o/
[16:02] <beisner> #topic Review ACTION points from previous meeting
[16:02] <beisner> no action items found.  i suspect we'll have a "check your blueprints" action out of today.
[16:03] <beisner> #topic Wily Development
[16:03] <beisner> #link https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule
[16:03] <beisner> we just passed feature def freeze
[16:04] <beisner> #subtopic Release Bugs
[16:04] <beisner> hrm.  report is awol.
[16:04] <beisner> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-w-tracking-bug-tasks.html#ubuntu-server
[16:05] <beisner> if there were one, it would be there ^
[16:05] <beisner> i'll take an action item to check into that
[16:06] <beisner> #action beisner to check into W qa report automation
[16:06] <meetingology> ACTION: beisner to check into W qa report automation
[16:06] <beisner> does anyone have any W bugs that we should point out?
[16:07] <jamespage> not yet
[16:07] <beisner> if not, onward
[16:07] <beisner> #subtopic Blueprints
[16:07] <beisner> #link http://status.ubuntu.com/ubuntu-v/group/topic-v-server.html
[16:07] <beisner> er um...
[16:08] <beisner> #link http://status.ubuntu.com/ubuntu-v/group/topic-w-server.html
[16:08] <beisner> #link http://status.ubuntu.com/ubuntu-w/group/topic-w-server.html
[16:08] <beisner> ^ is still not a thing fyi.
[16:08] <coreycb> https://blueprints.launchpad.net/ubuntu/+spec/topic-w-server
[16:08] <coreycb> maybe?
[16:09] <beisner> #link https://blueprints.launchpad.net/ubuntu/+spec/topic-w-server
[16:09] <beisner> thanks coreycb
[16:09] <beisner> ok so here we are, blueprinting, right?  ;-)
[16:10] <jamespage> we do need to get ontop of blueprints - I'd like to review openstack ones on Friday if possible
[16:10] <beisner> a reminder to be working on and linking blueprints
[16:10] <beisner> so there is a separate openstack blueprint tree from the server team blueprints now, fyi
[16:11] <beisner> ok cruising on
[16:11] <beisner> #topic Server & Cloud Bugs (caribou)
[16:11] <beisner> hi caribou
[16:11] <caribou> Hi, yes for once I have something :
[16:11] <beisner> woot
[16:11] <caribou> two actually
[16:11] <caribou> I need some help with CEPH upstart jobs
[16:12] <caribou> and curtin - disk partitioning
[16:12] <caribou> who should i ping for those ?
[16:12] <rbasak> Try jamespage for ceph+upstart, and smoser for curtin maybe?
[16:12] <beisner> perhaps smoser re: curtin
[16:12] <jamespage> caribou, I can help with ceph
[16:13] <caribou> jamespage: ok, I'll ping you sometime in the coming days
[16:13] <jamespage> ok
[16:13] <jamespage> any bugs?
[16:13] <caribou> & already bugged smoser a bit about curtin, will do again
[16:13] <caribou> jamespage: not sure I created one for that
[16:13] <caribou> jamespage: I'll email it if I find it
[16:14] <caribou> beisner: that's all I had
[16:14] <beisner> thanks caribou - so you'll find or file corresponding bugs and work with jamespage and smoser on those.
[16:14] <caribou> beisner: yep
[16:14] <beisner> ack
[16:14] <beisner> #topic Weekly Updates & Questions for the QA Team (matsubara)
[16:14] <beisner> hi matsubara
[16:14] <matsubara> Nothing new to report
[16:15] <beisner> alright thanks
[16:15] <beisner> #topic Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges)
[16:15] <smb> Hi, nothing to bring up right now (again). If there are no questions for us we can move along.
[16:15] <beisner> any questions for kernel?
[16:16] <beisner> ...
[16:16] <beisner> #topic Ubuntu Server Team Events
[16:16] <beisner> any fun things we need to let people know about?
[16:16] <beisner> #topic Open Discussion
[16:16] <beisner> or anything at all?
[16:17] <beisner> #topic Announce next meeting date, time and chair
[16:17] <beisner> same time, same place, +1 week.
[16:18] <beisner> and a happy tuesday, all!  i'll see about those reports.
[16:18] <matsubara> thanks beisner
[16:18] <beisner> #endmeeting
[16:18] <meetingology> Meeting ended Tue Jun  2 16:18:13 2015 UTC.
[16:18] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-06-02-16.01.moin.txt
[16:18] <gaughen> thanks beisner !
[16:19] <jamespage> ta beisner
[16:19] <beisner> yw all, now a coffee refill
[16:19] <caribou> ta beisner
[16:58] <elacheche> beisner, am from the Memebership board, do yu think that there is any problem if I try some meetingology commands to make sure that I have the good rights to chair the next meeting?
[17:00] <jsalisbury> ##
[17:00] <meetingology> Meeting started Tue Jun  2 17:00:05 2015 UTC.  The chair is jsalisbury. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:00] <jsalisbury> ##
[17:00] <meetingology> Available commands: action commands idea info link nick
[17:00] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Wily
[17:00] <cking> o/
[17:00] <smb> o/
[17:00] <ogasawara> o/
[17:00] <sforshee> o/
[17:00] <henrix> o/
[17:00] <apw> o/
[17:00] <jsalisbury> [TOPIC] Release Metrics and Incoming Bugs (jsalisbury)
[17:01] <jsalisbury> Release metrics and incoming bug data can be reviewed at the following link:
[17:01] <jsalisbury> [LINK] http://kernel.ubuntu.com/reports/kt-meeting.txt
[17:01] <jsalisbury> ..
[17:01] <jsalisbury> [TOPIC] Status: Wily Development Kernel (ogasawara)
[17:01] <ogasawara> We are still tracking the 4.0.x stable series on wily master-next.
[17:01] <ogasawara> We remain rebased to 4.0.4 and still sorting DKMS testing.  We
[17:01] <ogasawara> will continue to shoot for an official upload to Wily in the next few
[17:01] <ogasawara> weeks.  Tracking of the 4.1 series is taking place in our unstable git
[17:01] <ogasawara> repo on kernel.ubuntu.com.
[17:01] <ogasawara> -----
[17:01] <ogasawara> Important upcoming dates:
[17:01] <ogasawara> [LINK] https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule
[17:01] <ogasawara> Thurs June 25 - Alpha 1 (~3 weeks away)
[17:01] <ogasawara> Thurs July 30 - Alpha 2 (~8 weeks away)
[17:01] <ogasawara> ..
[17:01] <jsalisbury> [TOPIC] Status: CVE's
[17:01] <jsalisbury> The current CVE status can be reviewed at the following link:
[17:01] <jsalisbury> [LINK] http://kernel.ubuntu.com/reports/kernel-cves.html
[17:01] <jsalisbury> ..
[17:02] <jsalisbury> [TOPIC] Status: Stable, Security, and Bugfix Kernel Updates - Precise/Trusty/Utopic/Vivid (bjf)
[17:02] <bjf> tatus for the main kernels, until today:
[17:02] <bjf>   * Precise - Verification & Testing
[17:02] <bjf>   *  Trusty - Verification & Testing
[17:02] <bjf>   *  Utopic - Verification & Testing
[17:02] <bjf>   *  Vivid  - Verification & Testing
[17:02] <bjf>
[17:02] <bjf> Current opened tracking bugs details:
[17:02] <bjf>   * http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
[17:02] <bjf> For SRUs, SRU report is a good source of information:
[17:02] <bjf>   * http://kernel.ubuntu.com/sru/sru-report.html
[17:02] <bjf>
[17:02] <bjf>
[17:02] <bjf> Schedule:
[17:02] <bjf>
[17:02] <bjf> cycle: 23-May through 13-Jun
[17:02] <bjf> [17:02] <bjf>          22-May   Last day for kernel commits for this cycle
[17:02] <bjf> 24-May - 30-May   Kernel prep week.
[17:02] <bjf> 31-May - 13-Jun   Bug verification; Regression testing; Release
[17:02] <bjf>
[17:02] <bjf> ..
[17:02] <jsalisbury> [TOPIC] Open Discussion or Questions? Raise your hand to be recognized (o/)
[17:03] <jsalisbury> Thanks everyone
[17:03] <jsalisbury> #endmeeting
[17:03] <meetingology> Meeting ended Tue Jun  2 17:03:09 2015 UTC.
[17:03] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-06-02-17.00.moin.txt
[20:42] <ubuntiste-msakni> #startmeeting Testing
[20:42] <meetingology> Meeting started Tue Jun  2 20:42:46 2015 UTC.  The chair is ubuntiste-msakni. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[20:42] <meetingology> Available commands: action commands idea info link nick
[20:43] <ubuntiste-msakni> #endmeeting Testing
[20:43] <meetingology> Meeting ended Tue Jun  2 20:43:09 2015 UTC.
[20:43] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-06-02-20.42.moin.txt
[20:43] <ubuntiste-msakni> Good! I have permissions on meetingology..