[09:15] <Phuzzy> Hi All, have a wierd issue with a isntallation disk im customising as an experiment for internal use...
[09:16] <Phuzzy> started with a 12.04.2 disk, stripped out all .debs from the pool, and then ran apt-ftparchive. repackaged as an ISO, and attempted to install.
[09:17] <Phuzzy> its now failing with cdrom-retriever not being able to find fs-core-modules.... but if i go and look, the udebs are all exactly where they are supposed to be
[09:17] <Phuzzy> md5's for the files (compared to packages and another working 12.04 disk) are correct too
[12:23] <Phuzzy> found my problem... mangled filenames from extracfing the ISo badly


[01:17] <darkxst> here is a summary of the meeting https://docs.google.com/document/d/1dFwOEAyjhZa0KvKzleaMg_fM_i61YcVEwL8wi3ZxMxQ/edit?usp=sharing
[01:37] <phillw> Thanks
[12:23] <gingitsune> Hey
[12:24] <gingitsune> So I'm running the 16.04LTS and gnome ir restarting everyonce in a while and I can't quite figure out why would that be?
[12:24] <gingitsune> The only thing I'm running is Chromium and terminal \w tmux, vi, irssi
[13:27] <fleetfox> nothing in syslog?
[13:27] <fleetfox> are you sure it's os restarting and not your hardware
[14:17] <phillw> gingitsune: from the top of my head?.... over heating.
[14:22] <mozgiii> Hello, I think I've found a bug in gnome-terminal @ 16.04, what to do?
[14:45] <mozgiii> https://bugzilla.gnome.org/show_bug.cgi?id=706927
[14:45] <troif> Hi there. Maybe silly question, but: Is it possible to make 2 seperate menuentries in rEFInd to boot into Ubuntu GNOME (option 1: with nouveau driver and option 2: proprietary nvidia driver), just by setting different boot options?
[14:50] <troif> Is this the wrong place to ask such a question? If so, could someone gently point me to the right direction?
[14:50] <troif> Thank you.
[20:22] <conthy> Hello everyone. I just installed Ubuntu Gnome for the first time after 16.04 came out and it is almost certainly the best distro I've ever used. I want to help contribute so I came here to introduce myself and find out what the team needs the most.
[22:32] <numbers> Hey, I don't know how report a bug, but it ubuntu site said it could be mentioned here?
[22:39] <SonikkuAmerica> numbers: If it's particularly against Ubuntu GNOME it can be posted here
[22:41] <numbers> ok cool. I downloaded 16.04 -64bit 3 times by torrent. hashtags didn't match up for 3 tries. Downloaded iso through regular download link and that one matched up though.
[22:42] <numbers> Figured I should mention it somewhere so other people don't accidently get a bad version of the iso...
[22:43] <SonikkuAmerica> Well, torrenting the images can usually be fixed by zsync
[22:45] <numbers> I didn't wanna try them with md5's and sha incorrect... Wondered if a corrupted version is in the torrent pool linked to the ubuntugnome.org site
[23:25] <SonikkuAmerica> numbers: I would install zsync, then cd to the directory your ISO is in and run [ zsync http://cdimage.ubuntu.com/ubuntu-gnome/releases/16.04/release/ubuntu-gnome-16.04-desktop-amd64.iso.zsync ]
[23:25] <SonikkuAmerica> to repair the image you torrented.


[02:09] <pleia2> is there a mt view ubuntu hour on thursday? akk mentioned one but I haven't seen any notifications about it, I don't want to miss another (missed palo alto one when I was in town last month too)
[02:13] <pleia2> ugh, meetup doesn't show events without joining, and to join you need to do an introduction and connect it to social media stuff :\
[02:16] <pleia2> jtatum: can you add this to the loco directory and announce it so the whole team knows about it without signing up for meetup? we also use loco to announce stuff on twitter/facebook/etc
[02:16] <pleia2> if it's just on meetup it's really hard for us to include it in team reports and everything
[02:18] <pleia2> (trying to do team reports for October now, and I've pretty much given up tracking all these down because it's taking forever and we can't link to the meetup pages because you need to be logged into see anything)
[02:19] <pleia2> if someone who has time and access to Ubuntu SV stuff could add these to the report each month that'd be great
[02:26] <pleia2> I wish there was a way to automate this further, mailing list posts from loco.ubuntu or something, having all these ways to update events is really getting away from us :\
[02:29] <pleia2> ok, this is my stab at the report, please add anything that's missing :) https://wiki.ubuntu.com/CaliforniaTeam/TeamReports/12/October
[02:29] <darthrobot`> Title: [CaliforniaTeam/TeamReports/12/October - Ubuntu Wiki]
[03:45] <pleia2> doh, no Mt View Ubuntu Hour for me (just nudged my fiance to make sure he can drive me home, and he reminded me that we have a meeting that night for wedding stuff)
[03:45] <pleia2> wasn't on my calendar, oops
[03:48] <akk> Darn -- maybe next time.
[03:48] <akk> Wedding stuff obviously takes priority!
[03:49] <pleia2> exhausting stuff :) at least I finally bought my dress
[03:49] <pleia2> even if the people at the store were all shocked I had waited until just 6 months before the wedding to get it (isn't 6 months enough? no, should do it a YEAR in advance!)
[03:50] <pleia2> crazy, I was 25lbs heavier a year ago, that wouldn't have been any good :)
[04:01] <akk> That does sound crazy.
[04:01] <akk> Maybe they want you to buy it early then spend money altering it.
[04:03] <pleia2> hah, probably
[07:02] <bkerensa> Has anyone seen David Wonderly lately?
[07:02] <bkerensa> :D
[15:57] <pleia2> bkerensa: he is online, just not here (probably since he's not in california anymore :))
[18:25] <nhaines> pleia2: I was sad about it, but found that Meetup was pretty much not helpful at all whatsoever for Ubuntu Hours.
[18:26] <nhaines> pleia2: and btw, congrats on the dress and on the proper measurements.  :)
[18:27] <pleia2> nhaines: apparently in silicon valley it's working very well for them (lots of new people), but I suspect that's an exceptional area :)
[18:27] <akk> Yes, it's working well in silicon valley.
[18:27] <pleia2> but it is making it hard to track what's going on with the team (I emailed them to confirm they still wanted to be part of the loco since they weren't announcing them to the team anymore)
[18:27] <akk> Though I wonder if it might have worked just as well if we'd had all those UHs announced on our loco mailing list.
[18:28] <akk> Even before meetup they often weren't posted to the list, or not until the very last minute.
[18:28] <pleia2> yeah :\
[18:29] <akk> I wonder if a team google calendar (or equivalent) might work for pre-planning, in a way that's more open and less annoying than meetup.
[18:29] <pleia2> loco.ubuntu.com creates an ical feed that I use, I have email alerts that tell me to update twitter
[18:30] <pleia2> so I've been asking people to update loco.ubuntu for events so we can track them for reporting, it updates our calendar, shows up in "Events" link we have on the site..
[18:31] <pleia2> also, looking for a job! http://princessleia.com/journal/?p=7185
[18:31] <darthrobot`> Title: [Time for a new challenge – pleia2's blog]
[18:31] <pleia2> if anyone knows of anything that may be good for my skillset ;)
[18:32] <pleia2> (I'm still employed, but training my replacement and really want something by the end of the year)
[18:34] <akk> Cool -- I hope you find something awesome and perfect.
[18:35] <akk> Sure is nice to leave a job on good terms like that, with a transition period and training your replacement.
[18:36] <nhaines> pleia2: having such a heads up and being able to properly train your replacement seems to speak to a lot of mutual respect between you and your employer.  :)
[18:36] <akk> Agreed.
[18:37] <akk> Also, even being able to post something like that, rather than sneak around hoping your current employer won't find out you're hunting.
[18:37] <nhaines> That's an extra bonus.  :)
[18:52] <pleia2> it's a tiny company so we do have the benefit of a very good personal relationship :)
[18:53] <pleia2> of course now the pressure is on to get a new job soon, since paying me and my replacement indefinitely would not be optimal
[19:22] <bkerensa> pleia2: I hear this company called Canonical is hiring
[19:22] <bkerensa> ;)


[04:33] <tonyyarusso> Hi..I have a question regarding device drivers and development bounties:
[04:35] <tonyyarusso> I just bought a digital voice recorder, and while it registers in /var/log/syslog and 'lsusb', it doesn't seem to show up in /dev as anything recognizable or mount itself.  Googling hasn't come up with anything yet (still looking), but I may be stuck unless I can get someone to write a driver for it.
[04:36] <tonyyarusso> I would be willing in principle to offer a bounty for such a thing, but given my budget I would not be able to make it very much - certainly not market rate for a programmer.  So, with bounties, are most people happy to see any sort of bounty being offered, or would they find a small one (say, ~$15) insulting and actually be less likely to help me?
[04:39] <LaserJock> I suppose you could find like-minded people and pool resources
[04:40] <tonyyarusso> Do you think there would be enough people with this particular recorder using Linux for that to make a difference?
[04:41] <LaserJock> well, you only need to find 1 rich one ;-)
[04:41] <tonyyarusso> haha
[04:42] <tonyyarusso> So....college buddies - who's rich?  Darn.
[04:42] <tonyyarusso> But anyway, the more important point is, even if they wouldn't do it for a low amount, would I at least not be offending anyone by offering it?
[04:44] <LaserJock> I'd think as long as you are upfront in saying you realize that it isn't equal to the amount of time required
[04:44] <LaserJock> more of a token offering
[04:45] <tonyyarusso> Okay.
[04:45] <tonyyarusso> Thank you.
[08:58] <Hobbsee> hey ogra
[08:58] <ogra> yo
[09:05] <Lathiat>
[09:06] <dade`>
[10:42] (ogra/#ubuntu-devel) /usr/lib/pygtk/2.0/demos/colorsel.py
[10:46] <viller> can I acces the color selector directly in pygtk (i'm a n00b sorry :P)
[10:47] <viller> ?
[10:52] <ogra> viller, hit alt+F2 and type in: python /usr/lib/pygtk/2.0/demos/colorsel.py
[10:52] <viller> I already tested it
[10:53] <ogra> if you want to run it from a program you write look at the code of /usr/lib/pygtk/2.0/demos/colorsel.py
[10:53] <viller> ok
[10:54] <viller> the gtk color selector should have a value slider IMO
[03:16] <sivang> jono: ping
[03:17] <sivang> jono: actually, unping
[03:17] <sivang> nm
[05:36] <ogra> BenC, any idea about bug 73336 ?
[05:36] <Ubugtu> Malone bug 73336 in linux-source-2.6.19 "linux-libc-dev is missing linux/linkage.h header" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73336
[06:51] <mhb> hi all, do you know if one can translate the "Unsafe device removal" message that appears when you remove a USB stick without ejecting it first? I tried grepping /usr/share/locale-langpack but I can find it neither there or in Rosetta
[07:57] <pianoboy3333> Where can I get the latest libnautilus-burn?
[08:40] <theCore> who should I ask for getting a mailing list for my team?
[09:34] <corduroy> i have edgy installed and use the courier mail server.  i want to the latest release of courier.  before i start building my own new packagage, is there a repo of "testing" packages for ubuntu.. stuff that hasn't been qa'd yet?
[09:37] <corduroy> grimboy: you mean /etc/motd?
[09:41] <mdke> theCore<EMAIL_ADDRESS>(it says it on the front page, near the top)
[09:54] <theCore> mdke, I did send an email but I didn't receive any responses
[09:54] <theCore> that why I am asking
[10:47] <ssam> is pitti around? i have a possible security bug (i think restricted to powerpc)
[10:48] <Mithrandir> pitti: ^^
[10:50] <ssam> or a developer with a powerpc machine who i can talk to
[11:42] <mdke> theCore: that's the address
[11:42] <Chipzz> ssam: if you're referring to the libwv crash, there was a little discussion about that here yesterday, and IIRC the consensus was that it was not a security bug
[11:44] <theCore> mdke, thanks
[11:45] <theCore> mdke, I resent my email a few hours ago
[12:04] <FliesLikeABrick> has it ever been discussed to have a minimal CD that downloads the packages needed for a ubuntu installation at install time, resulting in a 50MB image or so rather than a 600+MB image?
[12:04] <FliesLikeABrick> like debian has
[12:04] <mdke> theCore: fine. It may have just arrived at the wrong time (summit)
[12:05] <Burgundavia> FliesLikeABrick: that is called netinstall and it already exists
[12:06] <FliesLikeABrick> I have never seen a CD image for it and I'm not talking about a full CD-less net install
[12:06] <FliesLikeABrick> I'm talking about something that looks and feels like an alternate install CD, but instead of using packages on the disk it downloads from apt repos
[12:07] <FliesLikeABrick> hm
[12:07] <stgraber> http://archive.ubuntu.com/ubuntu/dists/edgy/main/installer-i386/current/images/netboot/mini.iso
[12:07] <FliesLikeABrick> yeah just found that
[12:08] <FliesLikeABrick> why isn't that advertised at all?
[12:08] <FliesLikeABrick> I think that a ton of people would use that if they knew about it


[06:56] <NerdyBiker> morning all o/
[06:59] <NerdyBiker> I'm having an issue when using the cloud-init chef functionality on a box that already has chef installed on it. Cloud init appears to be doing nothing, doesnt change the client.rb or the firstboot.json :S Is there an issue using it on a box with chef already installed? (cloud-init 0.7.5)
[07:02] <NerdyBiker> actually it appears that the force_install isn't taking hold either. Testing this on a Centos7 machine.
[14:04] <rharper> NerdyBiker: not that I know of, can you file a bug in launchpad and provide some user-data and possibly the cloud-init.log from a failed run ?
[14:56] <smoser> NerdyBiker, there were recent-ish fixes in that area
[16:00] <mdorman_> so we’ve been testing with the following patches the last couple days (under RHEL7) and they’re working well, and are interested in getting these merged soonish so we can get off our fork.  what can we do to help move these forward and make that happen?
[16:00] <mdorman_> https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/305882
[16:00] <mdorman_> https://code.launchpad.net/~nrezinorn/cloud-init/+git/cloud-init/+merge/306562
[16:06] <rharper> mdorman_: thanks for the feedback and testing on those
[16:06] <rharper> smoser: is on a merge mission today
[16:06] <rharper> so hopefully soon
[16:19] <smoser> powersj, magicalChicken
[16:19] <smoser> while ! lxc exec "$name" -- [ -f /run/cloud-init/result.json ]; do sleep 1; done
[16:27] <mdorman_> rharper:  cool thanks.  please ping me or nrezinorn if we can do anything to help
[16:28] <smoser> nrezinorn, ok. i'll take alook
[16:28] <smoser> i have one of nrezinorn's others.
[16:28] <smoser> sorry mdorman_
[16:35] <mdorman_> cool
[16:39] <powersj> smoser: I did have another question, do you use root to run bddeb?
[16:39] <smoser> bddeb shoudl run as non-root
[16:39] <smoser> i think
[16:40] <rharper> powersj: smoser: right; you don't need root
[16:40] <powersj> without it I got permission errors on some files in /etc/cloud/*
[16:40] <rharper> after installing ?
[16:40] <rharper> not following
[16:41] <powersj> while building, let me pastebin
[16:41] <rharper> k
[16:41] <rharper> it's basically doing a debuild -us -uc (after creating tarball of the git repo in a tempdir)
[16:43] <powersj> https://paste.ubuntu.com/23354559/
[16:43] <powersj> (although it is apparently all on one line lol)
[16:44] <rharper> powersj: what does git status show ?
[16:44] <powersj> clean
[16:44] <powersj> On branch master
[16:45] <rharper> somethings not right, the maas-99 is only present on images that have been deployed via maas
[16:45] <powersj> Your branch is up-to-date with 'origin/master'.
[16:45] <powersj> nothing to commit, working directory clean
[16:45] <rharper> maybe something in ENV
[16:45] <rharper> for example, you'll not find the maas.cfg file in cloud-init/config/
[16:45] <powersj> rharper: ah so this is on torkoal our baremetal slave, where we want to run ci integration
[16:45] <rharper> but it's mentioned in the output
[16:45] <rharper> I wonder if we have a leak in importing config
[16:51] <rharper> nTraceback (most recent call last):\n  File "/tmp/tmpvkejmell/cloud-init-0.7.8-19-g7ae2011/tests/unittests/test_data.py", line 375, in test_unhandl
[16:51] <rharper> powersj: looks like unittest isn't mocking path
[16:51] <rharper> when it attempts to read config
[16:51] <rharper> powersj: can you file a bug ?
[16:52] <powersj> rharper: sure!
[16:58] <powersj> LP# 1635350
[17:09] <smoser> harlowja, ping
[17:10] <smoser> http://paste.ubuntu.com/23354699
[17:10] <smoser> those are on top of your sys-io-errors ... thoughts ?
[17:14] <harlowja> smoser seems ok with me
[17:16] <smoser> i commented on the merge
[17:16] <smoser> just hit submit
[17:16] <smoser> are you able to test those easiliy-ish ?
[17:18] <harlowja> mdorman and nrezinorn are in a better place to test it in a fully image
[17:18] <harlowja> but i can do basic stuff
[17:18] <harlowja> (they are in part the image builders/owners)
[17:18] <harlowja> @godaddy
[17:23] <mdorman> so what exactly is the question?
[17:25] <harlowja> mdorman nothing yet, will get back to u :)
[17:26] <mdorman> kk
[18:28] <smoser> mdorman, ok. so for the first one, i put a comment ther... it'd be nice to test my changes.
[18:28] <smoser> and commented on the second one also.
[18:28] <smoser> i could put toether a suggested diff if you want.
[18:32] <mdorman> yeah that would be helpful.  i’m hoping to work on these this afternoon


[19:25] <mup> Issue snapcraft#4472 opened: Dependency Dashboard <Created by renovate[bot]> <https://github.com/snapcore/snapcraft/issues/4472>
[22:06] <mup> PR snapcraft#4473 opened: chore(deps): update bugfixes <Dependencies> <Created by renovate[bot]> <https://github.com/snapcore/snapcraft/pull/4473>
[22:46] <mup> PR snapcraft#4474 opened: chore(deps): update internal packages <Dependencies> <Created by renovate[bot]> <https://github.com/snapcore/snapcraft/pull/4474>
[22:46] <mup> PR snapcraft#4475 opened: chore(deps): update dependency importlib-metadata to v7 <Dependencies> <Created by renovate[bot]> <https://github.com/snapcore/snapcraft/pull/4475>


[00:01] <tsimonq2> cjwatson, wgrant: Could I get some eyes on this? https://answers.launchpad.net/launchpad/+question/675414 It's going to hit the hard limit somewhat soon, because builds are about halfway through (a few hours left) that take up a few GB.
[00:01] <tsimonq2> I noticed this just now, sorry.
[00:56] <cjwatson> tsimonq2: done
[00:57] <tsimonq2> cjwatson: Much appreciated.
[22:56] <wxl> i want to remove ~lubuntu-packaging from bug 1472376, which they are subscribed to due to a subscription on leafpad bugs. however, this one doesn't affect lubuntu. i can't figure out how to do this without potentially removing the subscription on all leafpad bugs. what am i missing?
[23:48] <cjwatson> wxl: ~lubuntu-packaging is subscribed to the package, so there's no way to unsubscribe from just one of those.  The best you can do is mute bug mail from it (via "Edit bug mail").


[01:29] <mup> PR snapd#9558 opened: cmd/snap, snapmgr, tests: cleanups after #9418 <Simple 😃> <Skip spread> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9558>
[02:17] <mup> PR snapcraft#3342 opened: unit tests: mock os.environ.copy() for deb tests <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3342>
[02:35] <mup> PR snapd#9489 closed: daemon,client: write and read a maintenance.json file for when snapd is shut down <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9489>
[02:40] <mup> PR snapd#9542 closed: interfaces: deny connected x11 plugs access to ICE <Bug> <Needs security review> <⚠ Critical> <Created by zyga> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9542>
[02:40] <mup> PR snapd#9559 opened: client, daemon, cmd/snap: cleanups from #9489 + more unit tests <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9559>
[03:50] <mup> PR snapd#9560 opened: gadget/many: drop usage of gpt attr 59 for indicating creation of partitions <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9560>
[06:40] <zyga> good morning
[06:59] <zyga> hey mvo
[07:00] <mvo> hey zyga
[07:00] <zyga> hey mbeierl
[07:00] <zyga> mborzecki,
[07:00] <mborzecki> morning
[07:00] <mborzecki> zyga: heya
[07:03] <mvo> hey mborzecki
[07:03] <zyga> mborzecki, last nigth I was cursing at selinux
[07:04] <zyga> mborzecki, I totally failed to fix that denial, after hours of wasted effort trying things
[07:07] <mborzecki> zyga: heh, i'm pretty sure you're not the only one unhappy with selinux :P
[07:08] <zyga> I felt so lost because the denial and the rules are so far away from each other
[07:08] <zyga> I give up on that,
[07:08] <zyga> I want to actually spend my days on productive progress
[07:08] <zyga> maybe you could look when you have a moment
[07:47] <mborzecki> hmm not good `13 files changed, 891 insertions(+), 86 deletions(-)`
[07:54] <mborzecki> need to chop it up into more reviewable bits
[08:06] <zyga> hey pawel
[08:06] <pstolowski> heya
[08:06] <mup> PR snapd#9561 opened: secboot: version bump, unlock volume with key <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9561>
[08:06] <mvo> good morning pstolowski
[08:07] <mborzecki> mvo: can you take a look at #9561?
[08:07] <mup> PR #9561: secboot: version bump, unlock volume with key <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9561>
[08:07] <mborzecki> pstolowski: hey
[08:08] <mborzecki> zyga: btw. yday i ran a loop with this test https://github.com/bboozzoo/spread-mini/blob/master/mini/vendor-sync/task.yaml on tumbleweed, 27 iterations, all good
[08:09] <mborzecki> wonder whteher we're doing something wrong there
[08:09] <mvo> mborzecki: sure
[08:14] <zyga> mborzecki, that's great
[08:15] <zyga> mborzecki, so is that using our images?
[08:15] <mborzecki> zyga: yes
[08:15] <zyga> that is even more surprising
[08:17]  * zyga grabbed small breakfast
[08:21] <mup> PR snapd#9562 opened: tests: improve uc20-create-partitions-reinstall test <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9562>
[08:22] <mborzecki> mvo: thanks ;) now i need to get +1 from pedronis and a green merge button
[08:32] <zyga> pedronis, o/
[08:32] <zyga> good morning
[08:32] <zyga> I've replied to some questions and sent a few small patches in response to others
[08:32] <zyga> let's discuss the rest at 10
[08:32] <zyga> I will try to make all the changes as fast as possible
[08:43] <mborzecki> pedronis: hi, can you take a look at #9561?
[08:43] <mup> PR #9561: secboot: version bump, unlock volume with key <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9561>
[08:43] <pedronis> yes, in a bit
[08:48] <mborzecki> pedronis: thanks
[08:55] <pedronis> mborzecki: can you look at https://github.com/snapcore/snapd/pull/9560 it seems to simple to me
[08:55] <mup> PR #9560: gadget/many: drop usage of gpt attr 59 for indicating creation of partitions <Run nested> <UC20> <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9560>
[08:55] <mborzecki> pedronis: yeah, just left a comment there
[08:56] <mborzecki> heh, ok see you left one too
[08:57]  * zyga grabs laptop
[08:57] <pedronis> mborzecki: I think we use the offset indirectly because we run ensureLayoutCompatibility first
[08:57] <pedronis> but is still all a bit fragile
[08:59] <mborzecki> pedronis: hm it should probably identify the role of the partition based on gadget info from laid out volume and then double check it's the same partition (i.e. look at offset, though a bit of belt & suspenders maybe?)
[09:02] <mborzecki> loos like ensure layout compatibility runs later
[09:05] <mbeierl> zyga, hello!
[09:05] <dot-tobias> hi all
[09:27] <mup> PR snapd#9558 closed: cmd/snap, snapmgr, tests: cleanups after #9418 <Simple 😃> <Skip spread> <Test Robustness> <Created by anonymouse64> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9558>
[09:38] <pedronis> zyga: pasted https://github.com/snapcore/snapd/pull/9546#issuecomment-717813825
[09:38] <mup> PR #9546: overlord: add inert export manager <Created by zyga> <https://github.com/snapcore/snapd/pull/9546>
[09:38] <zyga> pedronis, thank you!
[09:45] <zyga> pedronis, one more thing that I just thought of is gadget/kernel copy-exporting assets\
[09:45] <zyga> pedronis, like device tree files or kernel images copied to FAT
[09:45] <zyga> pedronis, but I think this is all in sync with this approach
[10:01] <zyga> pedronis, changes look good, I think this will be over quickly :-)
[10:09]  * zyga coffee or tea, depending on what's made upstairs, brb
[10:25] <zyga> re
[10:25] <mborzecki> pedronis: i have the code that passes luks2 format options, but i wonder whether we should just pick something in the snapd/secboot package rather than expose it all the way to gadget/install, the patch here: https://github.com/snapcore/snapd/commit/603fee44875e73a9c129e06574bf41bcad0eeadd
[10:47] <mup> PR snapd#9557 closed: tests/snap-advise-command: re-enable test <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9557>
[10:50] <pedronis> mborzecki: I moved something in the TODO list
[10:50] <pedronis> mborzecki: should we quickly sync about your question and other bits?
[10:51] <mborzecki> pedronis: sure, let me jump into standup HO
[11:16] <zyga> pedronis, I ran into one bump, Manifest stores SnapName and ExportedVersion but we mangle core_revision or revision as both "snapd". When you look at ExportedFile.SourcePath you cannot use /snap/$snapName/$revision directly, instead we must unpack that special case there
[11:17] <zyga> I was wondering if this would warrant a distinction between (true) SnapName, SnapRevision and ExportedSnapName and ExportedVersion
[11:18] <zyga> if we were to store SnapName: "core", SnapRevision: "1234", ExportedSnapName: "snapd", ExportedVersion: "core_1234" then we would not have to parse anything
[11:18] <zyga> we might even make ExportedSnapName and ExportedVersion omitempty, and fall back to SnapName/SnapVersion
[11:19] <mvo> mborzecki, pedronis 9561 is green, ok if I merge?
[11:19] <zyga> I think this is better than trying to bake the logic there
[11:19] <zyga> for clarity, I am trying to write a pair of functions ExportedFilePathName and ExportedFileSourceName
[11:19] <zyga> that both take the following arguments: manifest *Manifest, set *ExportSet, exported *ExportedFile
[11:31] <zyga> pedronis, I made those modifications, I will post this soon
[11:31] <zyga> it's much more natural now
[11:32] <pedronis> sorry, I was syncing with Maciej about something else
[11:32] <mup> PR snapd#9561 closed: secboot: version bump, unlock volume with key <Run nested> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9561>
[11:33] <zyga> for reference https://paste.ubuntu.com/p/vt7Xg4frcH/
[11:34] <pedronis> mmh, I'll need to look, I worry a bit if it's confusing or not confusing
[11:35] <pedronis> I need to go have lunch
[12:09] <pedronis> zyga: it's probably fine but we need to be careful how we name things and where we put the fields
[12:10] <pstolowski> mvo: updated #9553
[12:10] <mup> PR #9553: tests: add spread test for refreshing from an old snapd and core18 <Run nested> <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9553>
[12:12] <mvo> pstolowski: thank you! and sorry that I did not think about this earlier
[12:12] <pstolowski> np!
[12:14] <cachio> zyga, hey
[12:14] <cachio> zyga, I left a comment https://github.com/snapcore/snapd/pull/9556#issuecomment-717890459
[12:14] <mup> PR #9556: tests: testing new fedora 33 image <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9556>
[12:14] <cachio> do you know how to fix that?
[12:24] <zyga> pedronis, ack
[12:24] <zyga> cachio, looking
[12:25] <zyga> oh that's serious
[12:25] <zyga> but again related to how we test things IMO
[12:25] <zyga> mborzecki, ^ fedora bumped libc?
[12:25] <zyga> new libc baked into snap-exec
[12:25] <zyga> I thougth we made it static
[12:25] <zyga> but perhaps not really?
[12:25] <mborzecki> hm maybe?, it should be static, there's a check in snapd.spec for it
[12:26] <zyga> : /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /usr/lib/snapd/snap-exec)
[12:32]  * mvo hugs mborzecki for 9528
[12:34] <pedronis> zyga: I didn't notice this yesterday, bit confused:  https://github.com/snapcore/snapd/pull/9546/files#r513405431
[12:34] <mup> PR #9546: overlord: add inert export manager <Created by zyga> <https://github.com/snapcore/snapd/pull/9546>
[12:36] <zyga> mmmm, replied
[12:36] <zyga> do you want to re-think?
[12:36] <zyga> should I pause the changes?
[12:37] <zyga> I think, as a first instinct, that this _is_ fine
[12:37] <zyga> especially with what we said about a higher level mapper for things like aliases/man pages
[12:37] <mborzecki> zyga: i can take a look a bit later
[12:37] <zyga> mborzecki, thank you!
[12:38] <zyga> pedronis, as one more data point, this is exactly why you designed core_$rev as the exported name before
[12:43] <dot-tobias> How do I completely reset a part in snapcraft that pulls in stage-packages? I'm testing which packages are required for a cmake-based build; is snapcraft clean my-part && apt autoremove enough?
[12:44]  * zyga doesn't know, sorry
[12:45]  * ogra just uese a fresh lxd container for such cases
[12:45] <ogra> *uses
[12:46] <dot-tobias> ogra: That would be my go-to approach if it would't need ~ 10min for each run to get to the part I'm working on 🙈
[12:51] <pstolowski> zyga: do you have some time for #9535?
[12:51] <mup> PR #9535: o/snapstate: generate snapd snap wrappers again after restart on refresh <Bug> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9535>
[12:51] <zyga> yes, I remember that
[12:55] <zyga> pstolowski, why is the new logic only applied to core?
[12:55] <pstolowski> zyga: only on core we generate wrappers. this check is repeated anyway in AddSnapdServices in wrappers
[12:55] <zyga> ah, I see
[12:59] <pedronis> zyga: two things come to mind, in general what is in .../export/* is really the input for another round of indirection in most cases, this is a bit hidden right now because we have only use case. because of that though there is really no good reason to do the dance we are doing conflating snapd/core and host for anything but snapd
[12:59] <pedronis> *only 1 use case
[12:59] <mborzecki> zyga: heh, so snap-exec is not statis, wtf is our check doing even
[12:59] <zyga> mborzecki, ;D
[12:59] <zyga> mborzecki, it's on strike today
[13:00] <mborzecki> haha, i think i know
[13:01] <zyga> pedronis, if we ever want to remove that special case we could create one more layer which updates snapd-tools -> core/tools or host/tools or otherwise, so I think we are safe here
[13:01] <zyga> mborzecki, ldd is naive
[13:01] <zyga> mborzecki, readelf FTW
[13:01] <mborzecki> zyga: ldd is good enough, just that it prints to stderr now apparently
[13:01] <pedronis> zyga: yes, we could do that. but my point here is more that we need to make clear that the strange bits are really only for this special case
[13:02] <mborzecki> zyga: and the check is ldd .. | grep withouth 2>&1
[13:02] <mborzecki> without
[13:02] <zyga> mborzecki, readelf has issues with some things in my experience but I'm happy the issue is easier this time :)
[13:02] <pedronis> zyga: there's no reason to abuse them later for something else, it's probably a bad idea even
[13:02] <zyga> pedronis, ack
[13:03] <zyga> pstolowski, approved
[13:04] <pstolowski> zyga: thank!
[13:04] <pstolowski> *thanks
[13:08] <mup> PR snapd#9535 closed: o/snapstate: generate snapd snap wrappers again after restart on refresh <Bug> <Needs Samuele review> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9535>
[13:08] <mup> PR snapd#9563 opened: secboot: set metadata and keyslots sizes when formatting LUKS2 volumes <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9563>
[13:12] <mborzecki> zyga: fun fact, i had a fix for f33, but not proposed yet, it's a sync between fedora packaging and our snapd.spec in tree
[13:14] <zyga> mborzecki, related https://forum.snapcraft.io/t/apps-wont-run-and-crash-on-gnome-wayland/20322?
[13:14] <zyga> mborzecki, or is that for the x11 socket?
[13:14] <zyga> ah sorry
[13:14] <zyga> ignore em
[13:14] <zyga> *me
[13:23] <mup> PR snapd#9564 opened: secboot: fix doc comment on helper for unlocking volume with key <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9564>
[13:23] <pstolowski> pedronis: NewRequestWithContext is available from go 1.13 :( they actually show version numbers, see https://golang.org/pkg/net/http/#NewRequestWithContext (it's on right-hand side)
[13:24] <pedronis> sad :(
[13:25] <pstolowski> pedronis: is upgrade out of question
[13:25] <pstolowski> ?
[13:25] <pedronis> we need to talk with mvo
[13:26] <pedronis> I think there's a older way to do what we want
[13:26] <pedronis> is just messier
[13:27] <pedronis> I didn't notice the versions on the right, I suppose is recent-ish change
[13:30] <pedronis> pstolowski: btw I think we do set some other timeouts via httputil/transport.go
[13:31] <pedronis> pstolowski: the old way is to use cli.Transport.CancelRequest
[13:33] <ijohnson> pedronis: mborzecki: perhaps we can chat sometime this morning re gpt attrs ?
[13:33] <ijohnson> I guess I'm a bit confused how to implement it using offsets given that we essentially already do that exact check in verifyLayoutCompatibility
[13:33] <mborzecki> ijohnson: i'm ok with after/before standup
[13:35] <pedronis> ijohnson: I don't think the issue is strictly the offsetts, you reasoning is not wrong, the issue is more about what is the marker/what we correlate with, the fs label might not be set
[13:35] <pstolowski> pedronis: hmm, i missed that, got confused by &ClientOptions{} and Timeout: opts.Timeout in NewHTTPClient
[13:36] <ijohnson> pedronis: ok, yeah I suppose it makes sense to not use the fs label in that case and more rely on the partition label, but again we won't have the partition label on mbr
[13:36] <ijohnson> let me have a look at the code again then perhaps we can chat after the SU
[13:36] <pedronis> ijohnson: we could use offset everywhere then?
[13:36] <pedronis> anyway my other issue with the PR as is, is that the flag seems more and more of a danger
[13:36] <mborzecki> ijohnson: offet will work for gpt and mbr
[13:37] <ijohnson> pedronis: I think as you said we need to just get rid of that CreatedDuringInstall flag entirely and then just compare the offsets after we have both the ondisk and the laidout from the gadget
[13:37] <ijohnson> mborzecki: right
[13:38] <mborzecki> ijohnson: you'll probably need to thing about fitting that with the rest of the code, iirc ensureLayoutsCompatible runs later and looks at IsCreatedDuringInstall flag
[13:38] <pedronis> does it?
[13:38] <pedronis> it says it does
[13:38] <pedronis> but I missed where
[13:38] <ijohnson> mborzecki: I think we should just drop that IsCreatedDuringInstall flag because yes ensureLayoutsCompatible runs after we build up the on disk layout (obviously)
[13:39] <ijohnson> I think I know what to do now
[13:39] <ijohnson> I just need to see if I know _how_ to do it :-)
[13:39] <pedronis> mmh, it does
[13:39] <pedronis> so I'm confused indeed
[13:40] <zyga> hip hip hippo!
[13:42] <ogra> shave it !
[13:43] <pstolowski> pedronis: CancelRequest is marked deprecated in current go docs, not a huge problem but means we may need to redo this in the future
[13:44] <pedronis> yea, I know
[13:46]  * ijohnson is slightly sad my suggestion to use hyrax was not taken
[13:46] <zyga> hyrax?
[13:46]  * zyga googles
[13:46] <ijohnson> it's like a little african prairie dog
[13:46] <zyga> oh wow
[13:46] <zyga> all the new words :)
[13:46] <ijohnson> I guess my comparison requires you know what a prairie dog looks like :-)
[13:46]  * ogra would have voted for homunculus
[13:46] <zyga> hasty hummus
[13:47] <ogra> (given it is the first one after an LTS that seemed to fit)
[13:47]  * ijohnson plans to try again in 13 years
[13:47] <ijohnson> haha
[13:50] <pedronis> mborzecki: you bumped secboot to current tip in your PRs?
[13:50] <mborzecki> pedronis: yes
[13:51] <mborzecki> pedronis: hmmm
[13:53] <mborzecki> pedronis: not quite the tip apparently, it's a this commit https://github.com/snapcore/secboot/commit/7c5ed6888746f5a798e475c02d23c08678a5ede8
[13:53] <pedronis> ah, so will need another bump
[13:53] <mborzecki> yup, the activation with multiple keys isn't there
[14:00] <zyga> cannot join
[14:00] <zyga> one sec
[14:09] <ogra> zyga, LOL ... did you see the journal at LP#1898869 ?
[14:09] <zyga> in a call
[14:09] <ogra> its an atom laptop 4GB that runs boinc !
[14:10] <ogra> +with 4GB
[14:17] <zyga> ogra, I'm running focal on a core2 duo with 3GB ram and it runs, pretty great actually
[14:18] <ogra> zyga, yeah, but you didnt install BOINC ... and a ton of broken "screen share" gnome-shell extensions
[14:19] <ogra> and your focal surely also doesnt have ifupdown installed (which seems to confise NM)
[14:19] <ogra> i'm refreeing to https://bugs.launchpad.net/bugs/1898869
[14:19] <mup> Bug #1898869: System slow on booting <amd64> <apport-bug> <focal> <ubuntu> <snapd (Ubuntu):New> <systemd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1898869>
[14:20] <ogra> in the light of what he installed it is actually booting pretty fast
[14:24] <zyga> ogra, wait, what is boinc?
[14:24] <zyga> I thought you said "bionic"
[14:24] <ogra> the successor of "seti at home"
[14:25] <ogra> https://en.wikipedia.org/wiki/Berkeley_Open_Infrastructure_for_Network_Computing
[14:26] <zyga> LOL
[14:27] <ogra> so someone installs all possible 3rd party SW that puts high load on the machine on boot ... uses the lowest end CPU, 4GB RAM and a rotary disk and complains about 1.5min boot time 🙂
[14:27] <ogra> i'd say that system actually flies given what it has installed 🙂
[14:32]  * pstolowski lunch
[14:48] <mup> PR snapd#9553 closed: tests: add spread test for refreshing from an old snapd and core18 <Run nested> <Test Robustness> <Created by stolowski> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9553>
[14:49] <mup> Issue core20#93 opened: forward port things to 22 branch <Created by xnox> <https://github.com/snapcore/core20/issues/93>
[14:49] <mup> PR core20#91 closed: hooks: add /var/lib/snapd/save <Created by bboozzoo> <Merged by xnox> <https://github.com/snapcore/core20/pull/91>
[14:59]  * cachio lunch
[15:04] <mborzecki> xnox: thanks!
[15:14] <zyga> pedronis, I've pushed the big change, I'll look at the SetStatus part now but it seems to be somewhat problematic
[15:15] <zyga> the task has now DoneStatus even though it is undone
[15:15] <zyga> on disk behavior is correct
[15:15] <zyga> but I wanted to ask if that is expected
[15:20] <zyga> pedronis, a few misc comments remain but I think the bulk of it is good now
[15:21] <zyga> I'll break for an hour and rebase the rest on top to ensure that it still works end-to-end
[15:48] <mup> PR snapd#9564 closed: secboot: fix doc comment on helper for unlocking volume with key <Simple 😃> <Skip spread> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9564>
[15:49] <zyga> rebased, running export smoke test now
[15:54] <pedronis> zyga: there' something off about instances (because of how we do current), there's is probably a bit more to simplify
[15:56] <zyga> mmm
[15:58] <zyga> found a trivial one liner bug, will add some tests and push again
[15:59] <zyga> I will look at instances after that
[16:00] <zyga> pedronis, if we do .../export/instance_key/revsion directly we can indeed simplify
[16:00] <zyga> pedronis, neither bases nor snapd allow instances so that's compatible with the goal
[16:00] <zyga> pedronis, we could also eventually allow that, for whatever reason, by having the mapping layer we discussed
[16:00] <zyga> so I think that yes, we can further simplify this
[16:02] <pedronis> zyga: when we discussed this I didn't consider that most other cases will need another indirection anyway
[16:02] <zyga> yeah, this turns the export manager mostly into a "mechanical" layer
[16:02] <zyga> which is good
[16:04] <zyga> I wonder if we should do the snapd special case differently, perhaps by using a different symlink which picks current tool provider, pointing at snapd/current/tools, core/current/tools or host/current/tools
[16:04] <zyga> then the whole special case would go away and only one, distinct symlink would be custom
[16:06] <pedronis> zyga: that would need more design
[16:09] <zyga> pedronis, I've rebased the other branch, tests are passing,
[16:09] <zyga> pedronis, this change was entirely self-contained, good :)
[16:15] <ijohnson> ugh gadget tests are very difficult to write - they require doing arithmetic!
[16:16] <zyga> ijohnson, easy as pi
[16:16] <ijohnson> it's as easy as finding a rational representation of pi
[16:17] <zyga> you are being irrational!
[16:17]  * zyga shoots upstairs to check up on kids
[16:17] <zyga> more export manager push tomorrow
[16:59] <mborzecki> mvo: still around? can you merge #9528 ? the failure on 18.04 is mount-ns:inherit
[16:59] <mup> PR #9528: cmd/snap-bootstrap: mount ubuntu-save during boot if present <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9528>
[16:59] <ijohnson> that test has been failing more consistently recently
[16:59] <ijohnson> for whatever reason the cgroup mountsh ave different options
[17:01] <mborzecki> heh
[17:07] <mvo> mborzecki: sure, let me do this
[17:08] <mvo> mborzecki: done, I guess that means that 9563 is now also unblocked?
[17:09] <mup> PR snapd#9528 closed: cmd/snap-bootstrap: mount ubuntu-save during boot if present <Run nested> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9528>
[17:09] <mborzecki> mvo: thanks, yes, i'll merge and push
[17:10] <mvo> mborzecki: \o/
[17:14] <mup> PR snapd#9565 opened: [RFC] overlord/devicestate: bind mount ubuntu-save under /var/lib/snapd/save on startup <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9565>
[17:14] <mborzecki> mvo: pedronis: ^^
[17:15] <mborzecki> and #9563 has been updated too
[17:15] <mup> PR #9563: secboot: set metadata and keyslots sizes when formatting LUKS2 volumes <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9563>
[17:16] <pedronis> mborzecki: thanks
[17:17] <mborzecki> pedronis: it does a mount via systemd-mount, felt it may be a bit cleaner and easier to test than fiddling with syscall.Mount again
[17:17] <mborzecki> anyways, need to wrap it up and help kids with the homework
[17:17] <pedronis> sounds good
[17:22] <mvo> pedronis: I'm working on the new location for lockout/policy-auth. should the recovery key also change location (I guess not but wanted to double check)
[17:28] <pedronis> mvo: they are in /var/lib/snapd/device/fde right now ?
[17:29] <mvo> pedronis: correct
[17:29] <pedronis> so they would got to .../save/device/fde
[17:29] <mvo> pedronis: ok
[17:29] <pedronis> about the recovery keys I don't have strong opinions atm
[17:38] <cmatsuoka> pedronis: I'm a bit confused with the save partition key, will it exist in both sealed and unsealed forms?
[17:39] <mup> PR snapd#9559 closed: client, daemon, cmd/snap: cleanups from #9489 + more unit tests <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9559>
[17:42] <pedronis> cmatsuoka: yes
[17:42] <pedronis> cmatsuoka: there will be an unsealed copy inside encrypted ubuntu-data
[17:42] <pedronis> and sealed copy inside a fallback sealed object
[17:43] <cmatsuoka> but not with the normal data sealed key, is that correct?
[17:44] <pedronis> cmatsuoka: the ubuntu-data key exists only sealed (once in the run object, once in a fallback object for recover paths only)
[17:45] <pedronis> cmatsuoka: we discussed this design with Chris, the reason to do this way is that the normal run path needs to unseal only one object
[17:45] <pedronis> and unsealing is a bit expensive, so we avoid the run boot slow down
[17:45] <cmatsuoka> ok, that makes sense now, thanks
[17:46] <cmatsuoka> pedronis: is it more expensive or otherwise worse if I seal the ubuntu-data key as the only key using the SealMultiple call?
[17:47] <pedronis> cmatsuoka: not really, actually secboot internally does that, the single object calls use the multi object ones
[17:47] <pedronis> now
[17:47] <cmatsuoka> ok, great
[17:47] <cmatsuoka> thanks
[17:48] <pedronis> SealKeyToTPM does SealKeyToTPMMultiple(tpm, []*SealKeyRequest{{Key: key, Path: keyPath}}, params)
[18:09] <mup> PR snapd#9566 opened: boot: store the TPM{PolicyAuthKey,LockoutAuth}File in ubuntu-save <Run nested> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9566>
[18:29] <mup> PR snapd#9567 opened: tests: using the nested-state tool in nested tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9567>
[18:29]  * cachio afk
[18:45] <zyga-mbp> ogra: that's one badass gramma, running postfix
[18:45] <ogra> haha, yeah ... that laptop is a mess
[18:46] <ogra> "lowlatency makes granny faster" 🙂
[18:46] <ogra> (or not)
[19:09] <zyga-mbp> lowlatency 4GB folding at home arch linux
[19:46] <pmart> hi. i need to access user mounts from snap. i connected removable-media interface but /media is still missing from snap root directory
[19:46] <pmart> is this the correct interface?
[19:48] <ijohnson> pmart: what directory are you trying to access ?
[19:48] <pmart>  /media/user/stuff
[19:52] <pmart> it's present in chromium snap e.g. but chromium has additionaly system-files connection
[20:10] <pmart> wait it works, kinda
[20:11] <pmart> it's just missing from "ls /" output
[20:15] <mup> PR snapd#9562 closed: tests: improve uc20-create-partitions-reinstall test <Simple 😃> <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9562>