[02:11] <devin_> can someone here help me with my broadcom wifi card issues?
[09:32] <evand> Thinking out loud, but I am beginning to wonder if we do enough to make integration into the installer easy enough for external entities (ISVs, OEMs, etc).  Not sure what could be done there and to my knowledge we haven't seen requests, so something to put on the back burner, I suppose.
[09:40] <davmor2> evand: you could ask the oem team to get some feedback from oem's see if there is anything they would like to see etc?
[09:41] <davmor2> xivulon: how goes the python conversion?
[09:41] <evand> davmor2: indeed
[09:43] <davmor2> evand: well it might give you an idea of things they do with the installer that might be more easily done, or sanely.
[09:43] <evand> ja
[09:43] <evand> yikes, so it seems there is still a bug in the partitioner if you select english at the CD boot menu, but then switch to another language at ubiquity
[09:43] <evand> arrr
[09:43] <evand> I thought I took care of this
[09:50] <_ruben> when netbooting, you cant specify multiple (remote) preseed files right?
[09:52] <davmor2> evand: do you want me to run a quick test and see
[09:52] <evand> davmor2: nope, I've already confirmed it.  Thanks though
[09:52] <davmor2> np's
[09:55] <evand> _ruben: Template: preseed/include_command
[09:55] <evand> Type: string
[09:55] <evand> Description: for internal use; can be preseeded
[09:55] <evand>  Shell command to run that may output a list of preseed files to load
[10:06] <_ruben> evand: ah sweet .. and that supports http files and the likes?
[10:11] <evand> I believe you can just add wget into the command, though I'd probably put fetching the preseed files in early_command
[10:11] <_ruben> hm.. that'd be a rather decent alternative indeed .. thanks for the tips
[10:15] <davmor2> evand: I'm writing up all the installer testcases does kubuntu use m-a yet or is that not going to happen in the foreseeable future?
[10:16] <evand> davmor2: definitely not going to happen this cycle
[10:16] <davmor2> evand: Okay cool :) one less to write :)
[10:18] <davmor2> evand, cjwatson: Also out of curiosity is it me or do you need to click on the ubiquity shortcut with more than one double click on the latest iso's?
[10:18] <davmor2> on ubuntu
[10:19] <evand> davmor2: I just tried the latest Ubuntu daily-live and it worked fine for me
[10:25] <davmor2> evand: Figured it out if the cd is still active it just highlight and doesn't start ubiquity if you wait for the cd to stop then try it works first time
[10:26] <evand> ah
[10:54] <CIA-3> ubiquity: cjwatson * r2987 ubiquity/ (3 files in 2 dirs):
[10:54] <CIA-3> ubiquity: Default hostname to 'oem-laptop' or 'oem-desktop' as appropriate in OEM
[10:54] <CIA-3> ubiquity: mode, to allow OEM installations to be fully preseeded (thanks, Twisted
[10:54] <CIA-3> ubiquity: Lincoln, Inc.; LP: #321341).
[11:05] <evand> I'm going to track the aforementioned bug here: https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/318564
[12:22] <davmor2> evand, cjwatson: You know when you do a manual install but don't format the drive so you keep the existing home content does this work on alt and live or just live?
[12:24] <cjwatson> theoretically on alternate too, but less well-tested
[12:24] <cjwatson> the code's there, but I'm reluctant to say for sure that it works
[12:24] <davmor2> cjwatson: I think it was poorly tested on both :) that's why we are trying to ensure we cover everything that is possible installer wise this time :)
[12:25] <cjwatson> yeah
[12:25] <cjwatson> definitely worth testing on alternate so we can fix it up
[12:26] <davmor2> http://testcases.qa.ubuntu.com/System is the current list if you guys can think of anything else for these 3 desktops
[12:28] <davmor2> I suppose there is usb based too that I haven't added yet but other than that I think it's getting pretty complete now
[12:28] <cjwatson> rescue mode for alternate
[12:29] <evand> Given some of the recent bugs, I'd really like to see an explicit "install in a language other than en_*"
[12:29] <cjwatson> "free software only" mode on desktops
[12:30] <cjwatson> err actually on both, IIRC
[12:30] <davmor2> that is the ubuntudesktopfree link
[12:30] <davmor2> none of which work yet
[12:30] <cjwatson> yes, we definitely at least need to run both automatic and manual partitioners through in a non-English language - preferably one with reasonable translation coverage
[12:30] <cjwatson> ah, ok, I thought that was "use free space"
[12:31] <davmor2> oh crap
[12:31] <davmor2> that'll be FreeSpace to be added :)
[12:31] <cjwatson> I wouldn't worry about that all that much, TBH
[12:32] <cjwatson> it's similar to "whole disk" in a lot of ways, and the ways in which it isn't similar will be covered by "resize and use free space"
[12:32] <cjwatson> I don't think you need to test it separately
[12:32] <cjwatson> in fact, yes, it's really just a subset of "resize and use free space"
[12:33] <davmor2> cool phew
[12:33] <davmor2> cjwatson: the non-english is that on alt and live?
[12:35] <davmor2> evand: ^
[12:35] <evand> davmor2: ideally both, yes.
[12:36] <davmor2> evand: right so let me get it straight for the test write up.  You select english on the initial language screen but then install in a non-english lang is that correct?
[12:37] <evand> I think selecting a different language at the boot screen would be the most appropriate test
[12:37] <evand> I know it wouldn't catch this current bug, but I think it's the most common path
[12:37] <evand> and testing both paths seems like a bit too much work for humans (some day I will finish setting up automated tests)
[12:38] <davmor2> evand: the testcase that are currently being written are for both humans and auto's so that is so much of an issue :)
[12:39] <evand> so long as one set of tests does not get confused for the other :)
[12:40] <davmor2> infact the only non-auto ones are the networkless installs it's hard to see if they worked without a network connection :)
[12:41] <davmor2> evand: tests layout will look something like http://testcases.qa.ubuntu.com/Ubuntu/Applications/gcalc
[12:41] <evand> noted; thanks
[12:43] <evand> hrm, the difference between language from CD boot and language from ubiquity/localechooser that's triggering this bug is not as obvious as a diff between the debconf databases, it seems.
[12:43]  * evand goes back to digging
[14:09] <evand> ah, got it! Somewhere there's a missing/failing call to locale-gen
[14:10] <davmor2> evand: congrats
[14:10] <cjwatson> evand: um, careful about running locale-gen before partitioning
[14:11] <evand> indeed, this might not be the right solution
[14:11] <cjwatson> it eats lots of memory and we generally try to avoid it before swap is up
[14:11] <evand> ok
[14:11] <cjwatson> debconf ought not to need the locale to be generated
[14:13] <evand> ok, I'm probably missing another piece of the puzzle; noted
[15:19] <DogWater> cjwatson: do you know what 'sections' are required to have a full ubuntu mirror?
[15:29] <cjwatson> DogWater: all of them. Do you really mean sections, or do you mean components?
[15:31] <DogWater> i guess what im wondering is what do i need to put into -s in order to get it? ;-)
[15:35] <DogWater> in the debmirror utility
[15:42] <cjwatson> ah, debmirror uses section to mean component
[15:42] <DogWater> cjwatson: like for example: main,restricted,universe,multiverse
[15:42] <cjwatson> DogWater: -s main,main/debian-installer is the minimum sensible
[15:42] <cjwatson> DogWater: -s main,main/debian-installer,restricted,restricted,restricted/debian-installer is what I use
[15:43] <DogWater> thanks
[15:43] <cjwatson> DogWater: for *everything*, you want something like -s main,main/debian-installer,restricted,restricted/debian-installer,universe,multiverse
[15:44] <DogWater> so were you able to figure out that bug that only I would find? ;-)
[15:50] <cjwatson> I did say I managed to reproduce it
[15:51] <cjwatson> haven't fixed it yet, but that's more because I've been buried in debconf half the day than anything else
[15:52] <cjwatson> I have a test case for it in my code now
[15:53] <cjwatson> basically, the problem is that the preseed command really ought to have slightly different option semantics from everything else
[15:54] <cjwatson> aside from the workaround I suggested, you could also use 'preseed -- preseed/late_command string ...' to work around it
[15:54] <cjwatson> but I'm going to try to make that unnecessary
[15:56] <evand> I think this problem lies slightly lower than I understand at the moment.  LC_ALL=es_ES.UTF-8 df and LC_ALL=es_ES.UTF-8 gedit both fail in jaunty when they worked fine in 8.10.
[15:56] <cjwatson> fail in what way?
[15:57] <evand> df is not translated, neither is gedit.  GTK reports: Locale not supported by C library.  Using the fallback 'C' locale.
[15:58] <cjwatson> right, that will happen if a locale isn't generated
[15:58] <cjwatson> but that shouldn't affect debconf in any way - it does its own localisation handling
[15:58] <evand> ah.  Red herring aside, did we preemptively generate them in 8.10?
[16:00] <cjwatson> I hope not, but they might have been available by way of a language pack on the live CD
[16:01] <evand> hrm
[16:01] <DogWater> oh, okay so just preseed -- then the original command?
[16:01] <DogWater> cool, i think im just going to setup and keep an updated mirror though probably will be easier and more reliable
[16:04] <cjwatson> hmm, maybe not, preseed command handling is more broken than I thought
[16:05] <DogWater> hopefully i can get debian 4 preseeding to work as well as ubuntu's kickstart (now) works.
[16:05] <DogWater> i'm trying to completely automate the installation of every distribution
[16:05] <DogWater> well, every one that has a reasonable install base
[16:08] <DogWater> cjwatson: do you have the link to the fixed amd64 initrd still or should i go fish?
[16:13] <cjwatson> I put it in the bug of which yours is a duplicate
[16:13] <DogWater> damn, i almost got it to install in less than a minute ;-)
[16:13] <DogWater> if this machine was faster i bet it would do it
[16:13] <cjwatson> wow
[16:13] <DogWater> partitioning =/
[16:13] <DogWater> if i use a clean disk its almost instant
[16:14] <cjwatson> that's really very impressive
[16:14] <cjwatson> doesn't it take a while to unpack all the packages?
[16:14] <DogWater> depdends on the machine
[16:14] <DogWater> on the celerons it takes about 30-40 seconds but on some faster ones its pretty quick
[16:15] <DogWater> if i could make it partition faster it would be great
[16:15] <DogWater> but i understand that mkfs.ext3 is a dog at times
[16:15] <cjwatson> I'm really struggling to see how the preseed command in Kickstart ever worked for anything complex :-/
[16:15] <cjwatson> its argument handling is all wrong
[16:16] <evand> mpt: http://people.ubuntu.com/~evand/tmp/ubiquity-9.04-keyboard.png is the current UI for your suggested change to the keyboard layout page.  Please do let me know if this is not suitable or if you have any comments.
[16:19] <cjwatson> could you collapse down the "standard" variant the same way the variant list box does?
[16:19] <mpt> evand, on what evidence is the suggested layout suggested?
[16:19] <cjwatson> so that should be USA, not USA - USA
[16:22] <DogWater> the double dhcp pauses, the formatting take the second longest after 'select and install software', crap this one took 5:45 from pxelinux to reboot
[16:26] <cjwatson> you can shorten the pause with netcfg/dhcp_timeout
[16:26] <evand> cjwatson: we just talked through it (I'm at Millbank today and tomorrow), and now plan to be going with drop down boxes with "(recommended)" next to USA.  Any part of that stand out as wrong to you?
[16:27] <cjwatson> what, replacing the full list boxes with drop-downs?
[16:27] <evand> With the potential to add a small portion of the keyboard selected as a bit of a visual aid
[16:27] <evand> yes
[16:27] <cjwatson> I'm not all that keen on that, I have to say
[16:27] <cjwatson> it sounds clumsy to use
[16:28] <cjwatson> all attempts I've seen to display keyboard layouts visually have been worse than useless
[16:28] <cjwatson> so I wouldn't bother reserving space for that
[16:28] <evand> hmm, ok
[16:28] <cjwatson> and, once you throw that out, the dialog looks awfully empty with just drop-downs?
[16:28] <evand> indeed
[16:29] <evand> so perhaps what we had before, just with "(recommended)" next to the default selection?
[16:29] <cjwatson> the problem with displaying an image of the keyboard is that many layouts and variants differ in rather fine details, and you end up squinting at this tiny little image trying to figure out whether it's right
[16:29] <evand> mpt's suggestion was to show about 1/4th of the keyboard, the top right portion
[16:30] <evand> I'm probably off on the fraction
[16:30] <cjwatson> I actually thought your mockup above was fine, with the exception of "USA - USA" -> "USA"; I'm curious as to what mpt thought was wrong with that
[16:30] <cjwatson> due respect but that's hopeless :)
[16:30] <evand> heh
[16:30] <cjwatson> won't distinguish lots of layouts at all
[16:30] <cjwatson> it would be little more than decoration
[16:30] <evand> mpt: can you elaborate, rather than me possibly paraphrasing you incorrectly :)
[16:30] <cjwatson> and it's lots of fragile code to generate, from what I've seen elsewhere, for pretty minimal return
[16:31] <cjwatson> the only thing I've ever seen try to display a keyboard image is GNOME's layout selector, which is the worst layout selector I've ever seen
[16:32] <evand> oh wow
[16:33] <evand> I see what you mean by squinting
[16:33] <mpt> cjwatson, my hypothesis was that you don't need to see the whole keyboard (like Gnome's, which I agree is horrible) to be able to tell whether the layout matches your keyboard
[16:33] <mpt> That for most layouts, the top right quarter or so is enough
[16:33] <cjwatson> I don't think that holds
[16:33] <mpt> so we could zoom and show that area by default, while still letting you scroll to see the rest.
[16:33] <cjwatson> and I don't think it's useful to show it visually anyway
[16:34] <cjwatson> my laptop keyboard *looks* completely different from a regular PC keyboard, but has the same layout as far as the installer is concerned
[16:34] <cjwatson> it would be worse than useless to show me a picture of a standard PC keyboard
[16:35] <mpt> hmm
[16:35] <cjwatson> we only care about the scancode->keycode->keysym level, not the geometry of the physical keys
[16:35] <mpt> Ok, so how else are people supposed to know what layout their keyboard is?
[16:35] <mpt> (no sarcasm)
[16:35] <cjwatson> the best way to tell whether a keyboard layout matches your keys is to type stuff with it
[16:35] <cjwatson> that's why we provide the test entry box
[16:36] <cjwatson> ideally, we should port the thing from d-i that lets you type some keys and then infers the layout from that
[16:36] <evand> I'm going to give interfacing with that a shot as part of the jaunty-ubiquity-usability specification.
[16:37] <cjwatson> but we should also default to language+location defaults, as they're correct a fairly large percentage of the time (though far from universally) and the layout inference tool takes a little while to walk through
[16:38] <cjwatson> I wish that USB keyboards actually provided reliable layout information, but they don't
[16:38] <cjwatson> (that would have been the ideal fix for this kind of thing)
[16:38] <evand> I take it they often provide wrong information?
[16:39] <cjwatson> well, there are two problems
[16:39] <cjwatson> firstly, the spec is vague - it just has a hardcoded list of languages, rather than what you actually want which is a description of the Unicode codepoints that each key's supposed to generate, or similar
[16:39] <cjwatson> secondly, USB keyboard manufacturers are hopelessly cheap and often just leave out that circuitry so it just says it's English or doesn't say at all
[16:40] <cjwatson> but even if it does say, it's probably not enough information to infer an X keyboard layout :-/
[16:40] <evand> yikes
[16:40] <mpt> This reminds me of the X tell-me-your-dpi issue
[16:40] <cjwatson> mm, except you don't have to get out a ruler
[16:41] <cjwatson> a lot of people, to be honest, will get by by just hitting Next on the current dialog
[16:41] <cjwatson> but we've tried omitting that step in the past, and the proportion of people who weren't satisfied by that was non-trivial
[16:42] <cjwatson> (US keyboards are common nearly everywhere even if the majority of people use a native layout; Canadians are split between English and French layouts in a way that doesn't necessarily match the language they prefer; people move countries and take their old computers with them; etc.)
[16:43] <mpt> This smells like it'll need an "I don't know" radio button
[16:44] <cjwatson> which walks you through the inference tool?
[16:45] <cjwatson> I think the reason I prefer list boxes to drop-downs for this, by the way, is that the list of available layouts is rather long, and drop-downs are clumsier to scroll than list boxes
[16:46] <cjwatson> when I end up in that situation, I usually end up clicking on the drop-down and then using the keyboard to scroll, which is, well
[16:46] <mpt> yeah, to go through the type-to-calculate thing
[16:47] <cjwatson> one problem with that at the moment is that it has no backup
[16:47] <cjwatson> er, by which I mean "go back". It's common to hit the wrong key and then have to go through it all over again
[16:48] <cjwatson> I did try to fix that once but it's a bit labyrinthine - we should, though
[16:48] <mpt> GTK option menus currently are more painful than they should be -- their speed doesn't increase as you move further away from the top/bottom
[16:48] <cjwatson> they also don't get capped to a particular size, but end up filling the whole screen
[16:48] <cjwatson> (or occasionally buggily extending off-screen or something)
[16:48] <mpt> yes, that's kind of a corollary
[16:48] <cjwatson> I tend to prefer things that stay within the window
[16:49] <mpt> If variable speed wasn't useful, it wouldn't matter that they touch the top/bottom of the screen
[16:49] <cjwatson> hm, I think I would still find it visually unpleasant even if the scrolling were fixed
[16:50] <cjwatson> it has an unfinished kind of look when something splats up a piece of tape extending from the top to the bottom of your screen :)
[16:50] <cjwatson> it also makes it less convenient to switch windows in the middle of a task, although that's not so much of a problem in this particular case
[16:54] <mpt> IMO those are both bugs :-)
[16:54] <mpt> The former that the scroll arrows are the wrong height, and the latter that menus eat Alt Tab
[16:55] <cjwatson> ok - nevertheless, we need to work with the widgets we have
[16:56] <mpt> yeah
[17:00] <mpt> hm, actually there are two speeds, but that's not enough
[17:00]  * mpt reports a bug
[17:16] <kirkland> evand: ping
[17:16] <evand> kirkland: pong
[17:17] <kirkland> evand: hey, i was curious about the state of the encrypted home installer option
[17:17] <kirkland> evand: i'm downloading the desktop daily iso now
[17:17] <kirkland> evand: curious if you needed my help with anything, or if you expect it to work?
[17:17] <evand> ah indeed.  Still broken, had to take a break from debugging it to work on other things, but will resume tomorrow.
[17:17] <evand> kirkland: sure, help is welcome
[17:17] <evand> let me find my notes
[17:17] <kirkland> evand: can you describe the problem?
[17:18] <kirkland> evand: i bet we're going to need a similar hack that i had to give cjwatson
[17:18] <kirkland> for the server/alternate installers
[17:18] <kirkland> evand: i'm about to upload a new ecryptfs-utils that adds filename encryption too
[17:18] <kirkland> evand: i was hoping to do that after having verified the installer bits
[17:19] <kirkland> evand: fwiw, i'm flying on Wednesday to .de, so I wanted to try and get the desktop installer working before i left
[17:19] <evand> kirkland: we can always pair up in Berlin if you have some time to hack on it, assuming it's not fixed by then
[17:19] <evand> but that's a week a way, so I imagine it wouldn't have to come to that
[17:20] <kirkland> evand: that's fine too, i was curious how berlin week was going to work
[17:20] <kirkland> evand: ie, coop between teams, plus alpha4 freeze
[17:20] <evand> ah right, now I remember
[17:20] <kirkland> evand: i was thinking the desktop bit is probably something simple and can be fixed ahead of then
[17:21] <evand> there seems to be some wonky interaction between ecryptfs-setup-private and the ecryptfs kernel module
[17:21] <kirkland> evand: what I really want to accomplish in berlin is some symblance of an encrypted swap solution
[17:21] <evand> it doesn't like user=foobar
[17:21] <kirkland> oh, right, i fixed that in this upload
[17:21] <evand> wonderful!
[17:21] <kirkland> evand: that should be a warning, though
[17:21] <evand> I just need to upload a fix for the blacklisting problem, and it should be golden
[17:22] <kirkland> cool, let me get this new ecryptfs-utils uploaded too, then.
[17:22] <evand> I'll review that and upload it tomorrow (ubiquity change, that is)
[17:34] <cjwatson> DogWater: I think I've decided that the right fix for you is in fact a documentation fix
[17:35] <cjwatson> DogWater: and that you should put the whole value to be preseeded in double quotes
[17:35] <cjwatson> DogWater: so: preseed preseed/late_command string "sed -i ...; in-target apt-get update"
[17:35] <cjwatson> or whatever it was
[17:38] <evand> hrm, porting a cdebconf plugin to ubiquity without rewriting it looks like it might involve a large saw and a welding torch.
[17:39] <cjwatson> yes, debconf doesn't have plugins and in any case there's no GTK version of that one; "port" might be a euphemism for "write new code that uses the same backend data"
[17:39] <evand> indeed, I'll try to wrap my head around the latter tomorrow
[17:40] <cjwatson> DogWater: (I did try changing this in kickseed, but the result was that the "preseed" command ended up being treated radically differently from every other command, and in the end I decided it would be far too confusing)
[17:41] <CIA-3> installation-guide: cjwatson * r442 ubuntu/ (debian/changelog en/install-methods/automatic-install.xml):
[17:41] <CIA-3> installation-guide: Document that values for Kickstart's preseed command containing spaces
[17:41] <CIA-3> installation-guide: must be quoted.
[17:56] <CIA-3> ubiquity: evand * r2988 ubiquity/ubiquity/frontend/gtk_ui.py: Only show the keyboard variant selection in the suggested option label.
[19:23] <CIA-3> oem-config: cjwatson * r585 trunk/ (d-i/manifest debian/changelog): Automatic update of included source packages: user-setup 1.23ubuntu7.
[19:55] <CIA-3> oem-config: cjwatson * r586 trunk/debian/changelog: releasing version 1.54.3
[23:49] <kirkland> cjwatson: okay, i dug a bit deeper into the encrypted home problem on the installer...  perhaps this info might help ...
[23:50] <kirkland> cjwatson: the libecryptfs0 gets installed, however, one of the files it owns, doesn't
[23:50] <kirkland> cjwatson: namely, /usr/lib/libecryptfs.so.0.0.0
[23:50] <cjwatson> kirkland: that's the blacklisting issue that evand mentioned, no?
[23:50] <kirkland> cjwatson: however, there are symlinks pointing to ie, ie /usr/lib/libecryptfs.so.0.0 and /usr/lib/libecryptfs.so.0
[23:50] <kirkland> cjwatson: oh, is it?
[23:50] <kirkland> cjwatson: sorry, "blacklisting" was cryptic to me
[23:51] <cjwatson> it's curious that the symlinks are there, but I thought the cause of the missing files was established
[23:51] <kirkland> cjwatson: okey doke, i'll wait until tomorrow, hopefully it'll sort itself out
[23:51] <cjwatson> so, as you know, ubiquity copies the live filesystem to the hard disk, and then removes some packages afterwards
[23:51] <cjwatson> to save time, it doesn't bother copying the files of packages it knows it's going to remove anyway
[23:52] <cjwatson> problem is, if it makes a mistake, it doesn't know how to put those files back
[23:52] <cjwatson> this happens in the event that a package is in the live filesystem but not in the standard desktop install, but some code that runs after the copying process asks for it to be installed
[23:52] <kirkland> cjwatson: smart!
[23:52] <cjwatson> I believe that *a* fix is to move the conditional apt-install in user-setup-apply back to user-setup-ask
[23:53] <kirkland> cjwatson: smart = the optimization (when it works) anyway :-)
[23:53] <cjwatson> but evand was testing this, and ran into trouble due (I think) to the problem you mentioned earlier
[23:53] <cjwatson> so it hasn't been committed anywhere yet


[06:29] <kashem> how do i get source code of ubuntu studio-18?
[11:08] <kashem> is it possible to know if anyone pinging me?plz...Help
[12:24] <BluesKaj> Hi folks
[17:18] <MikeRL> Hmm. What will 18.10 do that's better in terms of security? I'm curious.
[17:21] <BluesKaj> MikeRL, early days for such a question
[17:31] <MikeRL> OK.


[00:03] <Noskcaj> double checked, they have nothing. does anyone have either of the sticks?
[04:38] <Deathspawn> i keep getting error: failed to load 'image-nakasi-jop40d.zip'
[04:38] <Deathspawn> what do i do? im using Nexus 7
[04:41] <^Phantom^> paste your pastie Deathspawn
[06:33] <ivotkl> Hello.
[06:33] <Noskcaj> ivotkl, welcome to "here"
[06:34] <ivotkl> Hahaha. Ok, what does ARM mean? =P
[06:34] <ivotkl> and how do I setup a Raspberry?
[06:34] <ivotkl> Do I connect things just like in a regular machine?
[06:37] <Noskcaj> first
[06:37] <Noskcaj> !raspbian | ivotkl
[06:37] <ubot2> Factoid 'raspbian' not found
[06:37] <Noskcaj> !raspberrypi
[06:37] <ubot2> Factoid 'raspberrypi' not found
[06:38] <Noskcaj> !arm
[06:38] <ubot2> ARM is a specific (RISC) processor architecture used in a variety of applications such as handhelds and networkdevices. For more information see https://wiki.ubuntu.com/ARM . For ARM specific support, stop by the #ubuntu-arm channel.
[06:39] <Noskcaj> arm is there companies. apple, the bbc micro company and one other. they licence cpu designs cheaply
[06:40] <Noskcaj> ivotkl, sinc you seem to like arm stuff, have a look at this http://www.hiapad.com/?p=2018
[06:40] <Noskcaj> quad core 1.2ghz
[06:43] <ivotkl> That's a full computer? =S
[06:43] <ivotkl> Darn.
[06:43] <ivotkl> Price?
[06:43] <Noskcaj> ivotkl, yep, there are cheap, slower ones too. mine arives next week. $90
[06:48] <ivotkl> Noskcaj: Too bad I'm not where you're at. =P
[06:48] <ivotkl> Where do I order one?
[06:50] <Noskcaj> ivotkl, http://www.aliexpress.com/item/Hi802-Android-Mini-PC-HDMI-Dongle-Freescale-imx6-Quad-Core-1-2Ghz-1G-RAM-8GB-Bluetooth/707427957.html
[06:52] <ivotkl> It does not deliver to Argentina. =P
[07:00] <ivotkl> I should leave now. Thank you for the help and the chat.
[19:18] <prpplague> just a reminder, the Call for Participation for the Embedded Linux Conference 2013 ends friday! https://events.linuxfoundation.org/events/embedded-linux-conference/cfp
[20:31] <rhm> hi all, I was looking at the exciting news of Ubuntu on mobile phones. Anybody knows what is the relation with Ubuntu for Android? And if the code is available? Ubuntu for Android was announced last Feb but it is still not available for download.
[20:36] <infinity> rhm: U4A is essentially an Ubuntu desktop chroot (and a bit of glue) running on an existing Android installation.  Ubuntu Phone is Ubuntu running directly as the phone OS, rather than a chroot.
[20:36] <infinity> rhm: So, no relation, really.
[20:37] <morphis> infinity: the ubuntu phone looks really like the one I am holding in my hands :)
[20:38] <rhm> well, the video says it uses (or it can use) Android kernels and drivers so I'm guessing some of the work on UfA went into this UfP (I just made this up :)
[20:38] <tassadar_> morphis: it is probably some dummy device for the renders
[20:39] <infinity> rhm: Reusing the kernel isn't really the same as reusing the entire userspace.
[20:39] <rhm> agreed
[20:39] <infinity> rhm: The obvious difference here being that on a phone with U4A, you're still running Android, Android makes your phone calls, etc.  With Ubuntu Phone, there's no Android anywhere (except, as you note, a kernel in some cases).
[20:40] <morphis> rhm: take a look at libhybris (https://github.com/morphis/libhybris), it's one way to access android drivers within a eglibc based userspace
[20:40] <morphis> and it's what we're using over in webOS ports
[20:41] <tassadar_> what is ubuntu doing by the way?
[20:41] <tassadar_> using proper linux drivers?
[20:41] <rhm> infinity: makes you wonder if it will support Android apps natively. I didn't see any of that announced tho
[20:43] <rhm> morphis: thanks for the link. Will take a look at it. I have ubuntu running chrooted on my HTC Thunderbolt but accessing it via vnc which is pretty slow. I was looking for something like libhybris or any other solution to run the graphics natively
[20:43] <morphis> rhm: don't expect this to be an easy task
[20:44] <rhm> morphis: ha! who said using Linux was ever easy?
[20:44] <morphis> :)
[20:53] <rhm> any idea if the code is going to be released soon as part of any of the regular Ubuntu releases?
[20:54] <rhm> tassadar: I guess we won't know till we can take a look at the code
[20:55] <tassadar_> I mean the nexus 7 port
[21:07] <Noskcaj>  how can i get ubuntu on a hiapad hi802 / zealz gk802? ideally some instructions or an iso
[21:43] <thebishop> hi folks
[21:44] <thebishop> so... is this new Ubuntu Phone UI going to work with the Nexus7 installer?
[21:45] <robin-gloster> thebishop: are you asking if the phone UI will be available on the Nexus7? if so, no, at least it isn't a goal now
[21:46] <thebishop> robin-gloster, correct, and ... bummer
[21:47] <thebishop> so what's the vision for ubuntu on nexus7?
[21:47] <robin-gloster> thebishop: i'm sure it will be possible as soon the code is open, probably someone will look into it
[21:47] <infinity> There's no reason the same packages won't work just fine on the Nexus7 as well, once they're in the archive.
[21:47] <robin-gloster> as far as i have heard at first getting performance and battery lifetime up
[21:48] <infinity> We probably won't switch the Nexus7 images over to it, however.
[21:49] <thebishop> interesting, i have to say i'm a little surprised to hear this.  some of the issues interacting with standard ubuntu through touch seem difficult to solve
[21:49] <infinity> You're not wrong.  We just don't plan to switch the N7 image over right away, that's all.
[21:50] <infinity> Ultimately, all slate devices should be using the shiny new hotness, but that's not an immediate goal for Canonical.  If some enterprising community folk want to make it happen, we can't stand in their way.
[21:50] <tassadar_> so the ubuntu phone will be basically the same thing as nexus 7 (full linux distro) with different UI? That is just great Oo
[21:50] <robin-gloster> infinity: are there plans to modify Unity to be more touch friendly?
[21:50] <infinity> robin-gloster: This is Unity.
[21:51] <robin-gloster> infinity: hmm ok didn't realize it was unity, thought it was something different using the Unity APIs
[21:57] <thebishop> infinity, so the unity interface on ubuntu phone will be cleanly packaged in the archive?  that's pretty awesome
[21:57] <thebishop> infinity, no big need to change the n7 image in that case i suppose
[21:59] <infinity> thebishop: This is the plan, yes.
[22:00] <thebishop> infinity, works on standard laptops/desktops too?
[22:00] <Xavierdarkness> The phone in the video kind of looks like a galaxy nexus
[22:00] <robin-gloster> Xavierdarkness: it is
[22:00] <infinity> Xavierdarkness: That could be because it is.
[22:01] <Xavierdarkness> Figured it was either that or the nexus 4; given that they look similar. But that's cool, I'd definitely run Ubuntu on mine.
[22:04] <tassadar_> They wanna to release their own devices, the gnex is just "dummy device" to show Ubuntu phone UI, isn't that right?
[22:35] <LisaNori1> Has anyone gotten the nexus7 install to work with cellular data?  I can't seem to get it to work.  Just curious if this is a known problem.
[22:52] <LisaNori1> Sorry, I now see that 1091663 seems to address this.  I'll see if I can capture the logs needed.
[23:20] <SailorMoon> Does this Ubuntu Phone thing have any connection to the Ubuntu build seen for the Nexus 7?
[23:21] <lilstevie> SailorMoon: no
[23:21] <SailorMoon> Darn, then what is the Nexus 7 ubuntu build for?
[23:21] <SailorMoon> Theres nothing written about it anywhere, from what ive seen.
[23:22] <lilstevie> the nexus 7 ubuntu build is ubuntu on the nexus 7?
[23:22] <ubuntubhoy> The N7 build is a full ubuntu OS on the N7
[23:22] <ubuntubhoy> The ubuntu for phones OS is quite different
[23:24] <lilstevie> while nice, I don't think it would be as nice on a tablet
[23:33] <cwayne> the point of the n7 build is to make the core of Ubuntu work better on mobile devices
[23:34] <cwayne> i.e., get RAM usage down, and get a speedier core system overall
[23:34] <ubuntubhoy> yip, they have still not said anything about UI changes
[23:36] <cwayne> there aren't any planned for the nexus 7 build
[23:36] <cwayne> it's all about the core :)
[23:39] <ubuntubhoy> but if the core is right, then others can make functioning usable distro's from it
[23:51] <cwayne> ubuntubhoy: of course


[09:28] <elacheche> o/
[14:51] <hassoon> 'sup
[14:53] <elacheche> o/
[14:53] <asghaier> yo
[14:53] <asghaier> how r u doing guys?
[14:53] <elacheche> Good Neo31 ! u?
[14:53] <hassoon> not much, too bored and trying to keep reading a book of wordpress
[14:53] <hassoon> and playing NES games
[14:53] <hassoon> ahah
[15:51] <Neo31> hassoon, sayab 3lik mel wordpress a9ra chwaya Drupal ;)
[15:51] <Neo31> i'm good elacheche thx
[15:51] <Neo31> el madam lebess 3liha?
[15:51] <Neo31> :D
[15:52] <hassoon> Neo31: oui mais wordpress matloub dans la majorité d'offres d'emploie comme je vois
[15:52] <hassoon> Neo31: kammelt licence appliqué, wen7eb n3mel formation rapide le temps que la fac me prépare le diplome
[15:54] <elacheche> Neo31: +1, hassoon WP sucks, try Drupal
[15:54] <elacheche> Good Neo31 thx :)
[15:55] <hassoon> elacheche: it's required in most of the job ofers that's what concerns me, besides , what makes you think that it sucks ?, you too Neo31
[15:56] <hassoon> it's widespread across the internet , yet it empowers like 16% of web sites, according to some statistics i've read
[15:58] <elacheche> hassoon: bad security, no plugin dev standard if I'm not mistaken.. Sure it just do the job, but it do it in the worstway you can imagine (comparing it to Drupal)..
[15:59] <elacheche> Drupal is just better, Neo31 (as a Drupal dev)  can tell you more about that..
[16:21] <Neo31> Microsoft Windows is wide spread hassoon. And also required in more job offers. I would recommend you start to apply your theory to that then we will talk about wordpress.
[16:22] <Neo31> So your argument doesn't have anything with the quality of the job or the project you do with it.
[16:24] <Neo31> You find Drupal in less job offers, but also Skilled drupal developer are rare and "can" work on bigger projects and possibly get paid more.
[16:24] <hassoon> yep
[16:24] <hassoon> i want to get paid more
[16:24] <hassoon> <3
[16:24] <hassoon> moneeeeeey
[16:28] <Neo31> loool
[16:29] <Neo31> that's not a guarantee. a Drupal developer that sucks can end up not finding a job for Drupal nor for Wordpress.
[16:29] <hassoon> Neo31: meh i'm not doing drupal for now
[16:30] <Neo31> the key thing you have to get special kills and be really good at what you do
[16:30] <Neo31> whatever
[16:30] <Neo31> but you'll miss a lot if you don't try it (learn the basics at least)
[16:30] <hassoon> too bored and demotivated to learn drupal honnestly
[16:31] <Neo31> why demotivated?
[16:31] <hassoon> now i'm into wordpress/prestashop/symfony
[16:31] <Neo31> that's too much
[16:31] <Neo31> besides Drupal 8 uses symfony already
[16:33] <Neo31> and integrates with a lot of cool stuff like angularjs twig for theming...
[16:34] <hassoon> do you know some way to work as a freelance here in tunisia to get some money at least, Neo31 ? that would motivate me for a while at least :v
[16:34] <hassoon> Neo31: the job offers in upwork.com are disappointing
[16:34] <Neo31> anyway, not trying to convince you of anything. But it's a fact that Drupal can do more with less code and is preferred for bigger projects. Up to you to pick the technologies you want.
[16:35] <Neo31> If I was you I would try everything I could including wordpress but focus on skills that matter the most.
[16:35] <hassoon> eh what ?
[16:36] <Neo31> In tunisia with no experience in Drupal I wouldn't reccomend that. but see online and do some internships in drupal first
[16:37] <hassoon> should i just google for drupal books and start reading or what
[16:42] <hassoon> un offre d'emploie SIVP ça veut dire quoi
[16:42] <hassoon> le SIVP
[16:59] <elacheche> SIVP hassoon http://www.emploi.nat.tn/fo/Fr/global.php?libre=808&menu=
[17:03] <hassoon> elacheche: thanks reading
[17:12] <hassoon> elacheche: don't you think a SIVP job is a must for new graduates ?
[17:13] <elacheche>  hassoon it's not an option, Companies have some really good perks when they sign SIVP contracts, so, almost no-company will accept to not signing a such contreact with a fresher..
[17:14] <hassoon> elacheche: you mean most of companies will abus ethe fresh graduate ?
[17:14] <hassoon> * abuse the *
[17:14] <elacheche> it depends on the company hassoon, it depends also on the defition of "abuse"
[17:15] <hassoon> otherwise what did you mean in your 1st statement
[17:16] <hassoon> requirements for SIVP contacts are hard for fresh graduates?
[17:16] <elacheche> FIY, if someone signes a 6 months (or 9, I don't remember) of actual contract (CDD), or an undetermined contract (CDI), you'll loose your "right" to sign a SIVP
[17:16] <hassoon> i don't get it
[17:17] <elacheche> No, I meant that if you're a fresher, the company will just offer you an SIVP, nothing else
[17:17]  * elacheche GTG home, see you later
[17:17] <elacheche> :me brb
[17:17]  * elacheche brb
[19:58] <pavlushka> elacheche: I must say, you really make a life out of Ubuntu, :)
[20:44] <hassoon> pavlushka: what is that supposed to mean
[20:46] <pavlushka> hassoon: It means something to whom it concerns, it's secret, :p


[20:28] <Unit193> So I had prepped pasystray (https://sigma.unit193.net/source/pasystray_0.5.2-0ubuntu1.dsc), and now the Debian maintainer has uploaded the new version to mentors, but it doesn't enable support for indicators and last I knew Unity still didn't support tray icons.


[04:52] <mborzecki> morning
[05:04] <zyga> Good morning
[05:05] <mborzecki> zyga: kids already at school, yay ;)
[05:15] <zyga> mborzecki: oldest just went to school
[05:15] <zyga> mborzecki: middle one finished breakfast
[05:15] <zyga> mborzecki: youngest one plays with her toys :)
[05:15] <zyga> mborzecki: our son is 170 now
[05:15] <zyga> he's not even 13
[05:15] <zyga> mborzecki: easy landing for the morning https://github.com/snapcore/snapd/pull/7218#pullrequestreview-272716535
[05:16] <zyga> mborzecki: I added the extra checks you asked for
[05:16] <mup> PR #7218: tests: measure behavior of the device cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/7218>
[05:16] <mborzecki> and it's green :)
[05:17] <zyga> woot, thankyou
[05:17] <zyga> another easy ish is https://github.com/snapcore/snapd/pull/7392
[05:17] <mup> PR #7392: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392>
[05:17] <zyga> needs 2nd +1
[05:17] <zyga> also green
[05:17] <mup> PR snapd#7218 closed: tests: measure behavior of the device cgroup <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7218>
[05:29] <zyga> mborzecki: one more kid to walk to school, ttyl
[06:00] <zyga> back now
[06:30] <mborzecki> mvo: morning
[06:32] <mvo> hey mborzecki
[06:36] <zyga> good morning mvo
[06:36] <zyga> mvo: one more review if I can grab your attention :)
[06:36] <zyga> https://github.com/snapcore/snapd/pull/7392
[06:36] <mup> PR #7392: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392>
[06:37] <zyga> mborzecki: let's start chopping your classic mount namespace PR as we discussed in private
[06:37] <zyga> it will help with the review and will help with figuring out what is wrong
[06:37] <mvo> hey zyga
[06:38] <zyga> :-)
[06:39] <zyga> mvo: do you know who is the upstream of command-not-found nowadays?
[06:42] <mvo> zyga: foundations, why?
[06:42] <zyga> mvo: I have some patches
[06:47] <mborzecki> mvo: zyga: #7393 really simple
[06:47] <mup> PR snapd#7393 opened: cmd/libsnap-confine-private, cmd/s-c: use constants for snap/instance name lengths <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7393>
[06:47] <mup> PR #7393: cmd/libsnap-confine-private, cmd/s-c: use constants for snap/instance name lengths <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7393>
[06:48] <zyga> mborzecki: +1
[06:48] <mborzecki> thx
[06:58] <mup> PR snapd#7394 opened: tests: move debug section after restore <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7394>
[07:05] <pstolowski> morning
[07:05] <zyga> good morning pawel!
[07:11] <pedronis> pstolowski: hi, what's the status of #7277 ?
[07:12] <mup> PR #7277: [RFC] overlord/snapstate: fix undo on firstboot seeding <Created by stolowski> <https://github.com/snapcore/snapd/pull/7277>
[07:12]  * zyga goes to read https://github.com/snapcore/snapd/pull/7381
[07:12] <mup> PR #7381: seed,image,o/devicestate: extract seed loading to seed/seed16.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/7381>
[07:13] <zyga> great for rainy morning focus :)
[07:23] <pstolowski> pedronis: hi, i've addressed your feedback but not yet happy about some aspects, i need to revisit this PR, i haven't looked at it for a while
[07:26] <mborzecki> pstolowski: pedronis: hi
[07:26] <pedronis> pstolowski: it's the last bit of https://trello.com/c/9Clql0BE/299-first-boot-fixes , considering that the initramfs/grub stuff is more nice to have
[07:26] <pedronis> and also not great time given uc20 work
[07:28] <pstolowski> pedronis: ack, going to look at it today
[07:32] <zyga> is it just me or is github not responding very well now?
[07:38] <mup> PR snapd#7393 closed: cmd/libsnap-confine-private, cmd/s-c: use constants for snap/instance name lengths <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7393>
[07:43]  * zyga short break
[07:49] <mup> PR snapd#7394 closed: tests: move debug section after restore <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7394>
[08:38] <Chipaca> zyga: ping
[08:38] <zyga> hey
[08:39] <Chipaca> zyga: hiya
[08:40] <Chipaca> zyga: what's the purpose of osutil.MountOptsToFlags ?
[08:40] <Chipaca> it seems very sensible, but it's not used -- instead, the unchecked MountOptsToCommonFlags is used
[08:41] <zyga> let me look
[08:41] <Chipaca> k
[08:41] <Chipaca> not going to change it, but it caught my attention
[08:41] <Chipaca> (i'm fixing compilation on darwin)
[08:42] <zyga> ah,
[08:42] <zyga> I see it now
[08:42] <zyga> it's the layer on top of common flags that understands x-snapd and filters them out but errors on unknown flags
[08:42] <zyga> let me look at that
[08:42] <zyga> thanks!
[08:43] <Chipaca> zyga: np! tbh it looks like the Common one should be private, if i understand the difference
[08:44] <zyga> if you look at how it is used, common is the one being used because we acknowledge there are flags we don't understand that we just pass to mount
[08:44] <mup> PR snapd#7395 opened: cmd/snap-confine: apply global mount namespace initialization for confined and classic snaps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7395>
[08:44] <zyga> so I think the strict version is just unused and could be removed
[08:50] <pstolowski> zyga: any thoughs on https://bugs.launchpad.net/snapd/+bug/1841137 ?
[08:50] <mup> Bug #1841137: /dev/loopX devices left around for removed snap revisions <snapd:Triaged> <https://launchpad.net/bugs/1841137>
[08:53] <zyga> pstolowski: oooh
[08:53] <zyga> interesting
[08:54] <pstolowski> zyga: garbage collection gone wrong?
[08:54] <zyga> there's no garbage collection, it's explicitly managed malloc/free style
[08:54] <zyga> the deleted aspect is super puzzling!
[08:55] <pstolowski> zyga: i mean gc in the sense of removing old revisions automatically
[08:55] <zyga> pstolowski: nitpick: triaged literally means: we know the severity
[08:55] <zyga> setting it to triaged without setting one is weird
[08:55] <zyga> pstolowski: normally mount does that
[08:55] <zyga> pstolowski: libmount removes loopback devices
[08:56] <Chipaca> agreed about triaged
[08:56] <zyga> since I just rebooted
[08:56] <Chipaca> if you don't know the severity it's confirmed, not triaged :-)
[08:56] <zyga> can everyone with a longer uptime run: sudo losetup | grep deleted
[08:56] <zyga> and see if it shows anything
[08:56] <Chipaca> nothing right now but i have seen them before
[08:57] <Chipaca> that's when they appear in unity
[08:57] <Chipaca> i didn't know it was noteworthy :-)
[08:57] <zyga> that's super curious
[08:57] <zyga> I wonder if that's another lowlevel bug in kernel/libmount/systemd
[08:57] <zyga> normally systemd doesn't handle those so more likely in libmount
[08:57] <pstolowski> Chipaca, zyga noted, thanks :)
[08:57] <Chipaca> what snap is it? here it's always been core when i've looked
[08:58] <zyga> mvo, pedronis, mborzecki ^ perhaps you? (sudo losetup | grep deleted)
[08:58] <pstolowski> Chipaca: btw thanks for updating yesterday's bug ;)
[08:58] <zyga> Chipaca: those that refresh
[08:58] <zyga> Chipaca: I will look at adding a test for this though
[08:58] <zyga> Chipaca: refresh tree times
[08:58] <zyga> Chipaca: maybe that's exactly what I saw in the core 18 leak detector
[08:58] <Chipaca> pstolowski: :)
[08:58] <zyga> I saw deleted revisions
[08:58] <pstolowski> Chipaca: there are more snaps than just core there
[08:58] <zyga> so maybe it's a real bug that just doesn't get measured because refreshes are not 10 a day
[08:58] <zyga> pstolowski: thank you!
[08:59] <pedronis> zyga: a bunch for core
[08:59] <zyga> can you check the changes for those if you still have them
[08:59] <zyga> pedronis: I assume you have high uptime
[08:59] <zyga> but that's great, it's probably easy to reproduce then
[08:59] <pedronis> I doubt, they are actuall old revisions
[09:00] <mvo> zyga: none here it seems
[09:00] <pedronis> < 7700
[09:00] <zyga> thanks guys!
[09:00] <mvo> (just ran your command)
[09:00] <zyga> thank you
[09:00] <zyga> pstolowski: thanks for sharing, I was working on this anyway without realizing it is not limited to our test suite
[09:01] <pedronis> zyga: https://pastebin.ubuntu.com/p/wwXft5wyDg/
[09:01] <zyga> pedronis: 18.04?
[09:01] <pedronis> yes
[09:01] <zyga> perfect, thank you
[09:03] <mborzecki> zyga: isn't this because of preserved mount namespaces?
[09:03] <zyga> no
[09:03] <zyga> well
[09:03] <zyga> I don't think so
[09:03] <zyga> it's more involved
[09:03] <zyga> the most surprising part is the deleted element
[09:03] <zyga> but let me write a test first
[09:04] <mborzecki> zyga: deleted seems fine to me, iirc association of a file with a loopback device is done using a file descriptor
[09:04] <zyga> mborzecki: it's not fine
[09:04] <zyga> IMO
[09:04] <zyga> but let's check out little by litte
[09:05] <zyga> it only happens when the parent dentry is removed AFAIR
[09:05] <pedronis> zyga: is this the highest priority thing on your plate?
[09:05] <zyga> pedronis: in terms of wrapping up, it's what I was doing anyway but I was chasing logs from runs, this gives me an idea for a test to write, maybe it will uncover the bug more directly
[09:07] <pedronis> mborzecki: they are not mounted anywhere
[09:08] <zyga> though there are two separate sides here, losetup deleted vs mountinfo deleted
[09:08] <pstolowski> Chipaca: do you know what's the status of https://bugs.launchpad.net/snapd/+bug/1804245 ?
[09:08] <mup> Bug #1804245: empty response from store when throttled allows switch to nonexistent track <snapd:New> <https://launchpad.net/bugs/1804245>
[09:09] <Chipaca> pstolowski: I think i fixed that one :-) updated the bug to reflect
[09:09] <pstolowski> good :)
[09:10] <Chipaca> i just need to confirm
[09:11] <Chipaca> i was wrong i think
[09:11] <Chipaca> digging
[09:13] <pstolowski> zyga: this can be closed? https://bugs.launchpad.net/snapd/+bug/1805866
[09:13] <mup> Bug #1805866: On core18 system core18 snap was mounted after snapd had started <snapd:New> <https://launchpad.net/bugs/1805866>
[09:14] <zyga> pstolowski: no, why?
[09:14] <zyga> it's a real bug IMO
[09:16] <pstolowski> zyga: ok, it's very old, i assumed it was fixed as otherwise we would probably see it more?
[09:16] <zyga> pstolowski: we don't really boot that often with services, not on classic systems
[09:16] <pstolowski> ok, fair enbough
[09:18]  * pstolowski is stepping down from triaging job for now
[09:23] <jamesh> zyga: is there anything else needed to get https://github.com/snapcore/snapd/pull/6767 merged?
[09:23] <mup> PR #6767: wrappers: allow snaps to install icon theme icons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6767>
[09:24] <zyga> jamesh: no, just need to finish my review
[09:24] <jamesh> zyga: okay, thanks.
[09:27] <Chipaca> pstolowski: confirmed, fixed in 6ce906f7df2
[09:27] <pstolowski> Chipaca: ty!
[09:27] <Chipaca> updating the bug
[09:40] <mup> PR snapd#7396 opened: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>
[09:52] <zyga> pstolowski: I replied to https://github.com/snapcore/snapd/pull/7392#discussion_r320176487 -- let me know if that's okay in your eyes
[09:52] <mup> PR #7392: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392>
[09:52] <zyga> pstolowski: I'm happy to have a follow up
[09:57] <pstolowski> zyga: ty, replied
[09:57] <zyga> woot, thanks.
[09:58] <mup> PR snapd#7392 closed: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7392>
[10:08] <zyga> is there anything we could retry that would help us?
[10:08] <zyga> snap install from the store perhaps
[10:08] <zyga> any ideas?
[10:09] <zyga> though that retries internally so perhaps no
[10:09] <zyga> pstolowski: I cannot immediately reproduce the error with leaking loopback device
[10:09] <zyga> I was wondering if being base is somehow more special
[10:10] <zyga> but then the bug report did include telegram-desktop
[10:10] <zyga> it may also be a more recent-ish environment (a rolling distro)
[10:10] <zyga> I'll run my test on 16.04 and look at finishing some of reviews instead
[10:16] <zyga> pstolowski: ^ quiet in 7397
[10:16] <mup> PR snapd#7397 opened: tests: add --quiet switch to retry-tool <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7397>
[10:17] <pstolowski> zyga: right, i couldn't repro loopback issue either. perhaps we need to observe our systems more close for some time
[10:17] <pstolowski> zyga: thanks for 7397!
[10:17] <zyga> it means we are missing something though :)
[10:17] <zyga> it's going to be good when we finally understand what it was
[10:21] <zyga> pstolowski: I updated https://github.com/snapcore/snapd/pull/7256
[10:21] <mup> PR #7256: tests: adding retry command and use it to delete $XDG directory <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>
[10:23] <mup> PR snapd#7398 opened: boot, etc: simplify BootParticipant (etc) usage <Created by chipaca> <https://github.com/snapcore/snapd/pull/7398>
[10:24] <mup> PR snapd#7399 opened: tests: verify retry-tool not retrying missing commands <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7399>
[10:26] <zyga> pstolowski: replied on https://github.com/snapcore/snapd/pull/7397#discussion_r320200634
[10:26] <mup> PR #7397: tests: add --quiet switch to retry-tool <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7397>
[10:31] <mborzecki> pstolowski: zyga: when that happens, aren't those devices listed in nautilus sidebar too?
[10:31] <zyga> mborzecki: I have *never* seen that in my sidebar on TW
[10:32] <zyga> but I did see some wonkiness in unity a while ago while using a 16.04 vm
[10:32] <mborzecki> zyga:  i have, i recall asking someone during last sprint about that :)
[10:33] <zyga> mmmm
[10:33] <zyga> more interesting to see what causes it
[10:35] <mup> PR snapd#7400 opened: cmd/snap-update-ns: don't propagate detaching changes <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>
[10:36] <zyga> mborzecki: speaking of mounting https://github.com/snapcore/snapd/pull/7400
[10:36] <mup> PR #7400: cmd/snap-update-ns: don't propagate detaching changes <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>
[10:36] <zyga> I'm reviving that MS_SHARED bugfix but this is something I found in that branch
[10:37] <zyga> it's a bit unusual in the sense that it is a fix for something that was hidden by lack of sharing
[10:37] <zyga> but I proposed it ahead of actual sharing
[10:37] <zyga> I explain why in the PR
[10:37] <zyga> I should break for coffee and then really return to reviews or I will never get them done
[10:38]  * Chipaca takes a break
[10:42] <zyga> mborzecki, pstolowski: https://github.com/snapcore/snapd/pull/7397#discussion_r320206281
[10:42] <pstolowski> mborzecki: i think the reporter of that bug mean that when he said gnome file manager
[10:42] <mup> PR #7397: tests: add --quiet switch to retry-tool <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7397>
[10:43] <mborzecki> pstolowski: nautilus?
[10:43] <pstolowski> mborzecki: on my 18.04 box i only have cli so can't verify; on full-blown 19.04 i couldn't reproduce in my short tests
[10:43] <pstolowski> mborzecki: yes, nautilus
[10:44] <mborzecki> woo, it's called files now :/
[10:44] <zyga> files :)
[10:44] <zyga> nice
[10:44] <mborzecki> and i keep on typing nau.. in the search
[10:44] <zyga> until it becomes folders ;)
[10:44] <zyga> after coffee / reviews I'll change my test to refresh bases while running various apps
[10:44] <zyga> and see what happens then
[10:46] <zyga> pstolowski: trivial quickie https://github.com/snapcore/snapd/pull/7399
[10:46] <mup> PR #7399: tests: verify retry-tool not retrying missing commands <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7399>
[10:46] <zyga> this is also pretty obvious but I was unsure if there are any side effects
[10:46] <zyga> https://github.com/snapcore/snapd/pull/7396
[10:46] <mup> PR #7396: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>
[10:46] <zyga> though it feels like the original code was just buggy anyway
[10:47] <zyga> mborzecki: is my reasoning correct? https://github.com/snapcore/snapd/pull/7396#discussion_r320208075
[10:47] <mup> PR #7396: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>
[10:48] <zyga> mvo: can you please finish the review of https://github.com/snapcore/snapd/pull/7362
[10:48] <mup> PR #7362: cmd: unify die() across C programs <Created by zyga> <https://github.com/snapcore/snapd/pull/7362>
[11:00]  * zyga breaks
[11:08] <pstolowski> good idea
[11:08]  * pstolowski lunch
[11:39] <pstolowski> pedronis: #7092 seems to be happy
[11:39] <mup> PR #7092: packaging: use snapd type and snapcraft 3.x <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7092>
[11:44]  * Chipaca goes for lunch
[11:48] <mvo> 6705 needs a second review now
[11:49] <mvo> zyga: will do after lunch
[11:54] <mborzecki> zyga: updated #7387
[11:54] <mup> PR #7387: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7387>
[11:57] <pedronis> Chipaca: comment on #7398
[11:57] <mup> PR #7398: boot, etc: simplify BootParticipant (etc) usage <Created by chipaca> <https://github.com/snapcore/snapd/pull/7398>
[11:57] <pedronis> *commented
[12:13] <mborzecki> zyga: duh, mounts do not look nice when there's more snaps installed https://paste.ubuntu.com/p/BHvpFx7P3X/
[12:23] <mborzecki> zyga: ok, updated #7302 too
[12:23] <mup> PR #7302: cmd/snap-confine: add support for parallel instances of classic snaps <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7302>
[12:36] <mup> PR pc-amd64-gadget#19 closed: UC20 spike changes <Created by cmatsuoka> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/19>
[12:37] <cachio> mvo, pedronis  I need to skip the standup, perhaps arriving late but not sure, forgot I had a meeting in the school
[12:37] <zyga> mborzecki: seeing double :)
[12:37] <zyga> mborzecki: I have an idea about that
[12:37] <zyga> mborzecki: but in the evening after round of reviews
[12:37] <zyga> mborzecki: for tomorrow, ok?
[12:58] <ogra> jdstrand, i have a problem ... trying to use a DHT11 sensor (temp/humidity) and output to an OLED display on a Pi3 with https://github.com/adafruit/Adafruit_Python_DHT ... i end up with https://paste.ubuntu.com/p/Z7PDBTCjkb/ ... could we add these paths to "hardware-observe" ?
[12:59] <Chipaca> pedronis: interesting comments
[13:17] <rbasak> I'm using Docker to run snapcraft inside Travis. Is there anything I need to do to switch to using core18?
[13:17] <rbasak> Currently I'm doing: docker run -v $(pwd):$(pwd) -t snapcore/snapcraft sh -c "apt-get update -qq && apt-get install -qq git && cd $(pwd) && snapcraft"
[13:17] <rbasak> I'm wondering if I need to use a different Docker image based on Bionic?
[13:17] <Chipaca> rbasak: use core18 for what?
[13:17] <Chipaca> does snapcraft in docker not use multipass?
[13:18]  * Chipaca doesn't know
[13:18] <Chipaca> i imagine not, in which case yeah you'd need a bionic image
[13:19] <rbasak> Chipaca: to base my snap on core18 I mean. Ie. "base: core18" in snapcraft.yaml AIUI. Yes - that's what I was thinking.
[13:19] <rbasak> Is there a published snapcraft-that-uses-bionic image?
[13:26] <Chipaca> rbasak: I don't know. Maybe sergiusens does?
[13:51] <zyga> cmatsuoka: can this land? https://github.com/snapcore/snapd/pull/7266
[13:51] <mup> PR #7266:  recovery: update run mode variable name <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7266>
[13:52] <cmatsuoka> zyga: on the uc20 branch, yes
[13:52] <cmatsuoka> zyga: thanks
[14:00] <zyga> cachio: hey, I pushed into the XDG branch of yours
[14:00] <zyga> cachio: I also opened something small for your consideration: https://github.com/snapcore/snapd/pull/7396
[14:00] <mup> PR #7396: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>
[14:00] <cachio> zyga, nice, thanks
[14:00] <jdstrand> ogra: it is likely fine. they are binary files. add to the list for the next round. thanks!
[14:01] <jdstrand> added*
[14:01] <zyga> jdstrand: hello :)
[14:01] <jdstrand> zyga: hi :)
[14:01] <ogra> jdstrand, thanks !
[14:02] <ijohnson> rbasak: there is not, you will need to roll your own docker image
[14:03] <ijohnson> rbasak: if you're building on travis, it is probably much easier for you to just build with lxd and call snapcraft from your job definition directly, travis supports running snapcraft as a snap and lxd as a snp
[14:06] <rbasak> ijohnson: OK, thanks.
[14:06] <rbasak> ijohnson: do you know of any examples?
[14:06] <ijohnson> rbasak, sure one minute
[14:07] <ijohnson> rbasak: take a look at one of the snapcrafters snaps at https://github.com/snapcrafters/sdlpop/blob/master/.travis.yml
[14:08] <rbasak> ijohnson: that's great. Thank you!
[14:13] <cachio> zyga, #7256 needs a +1
[14:13] <mup> PR #7256: tests: adding retry command and use it to delete $XDG directory <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>
[14:13] <cachio> pstolowski, could you please take a quick look to #7256
[14:15] <pstolowski> cachio: yes
[14:15] <cachio> pstolowski, tx
[14:16] <pstolowski> cachio: looks good but as i said in earlier comment i think we should wait for it to fail again an see if #7336 shows anything interesting
[14:16] <mup> PR #7336: tests: add debug section to interfaces-contacts-service <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7336>
[14:22] <roadmr> jdstrand: hi are you around? I have a question :) {"docker": {"allow-auto-connection": "true"} <- this implies allow-installation, right? so a snap with this in the plugs section should automatically pass review, not be held with human review required due to 'allow-installation' constraint (bool) declaration-snap-v2_plugs_installation (docker, docker)
[14:23] <cachio> pstolowski, ok, I'll try to force the error
[14:24] <cachio> pstolowski, otherwise it will take too much time
[14:24] <pstolowski> cachio: force how?
[14:24] <cachio> pstolowski, retrying execution
[14:24] <cachio> until it fails
[14:24] <pstolowski> cachio: ok
[14:25] <cachio> and praying
[14:25] <cachio> heheehe
[14:25] <pstolowski> heh
[14:25] <jdstrand> roadmr: it does not imply allow-installation
[14:26] <roadmr> jdstrand: ah, ok. That makes sense
[14:26] <pedronis> it does for snapd
[14:26] <jdstrand> roadmr: in snapd, auto-connection, connection and installation are all separate from each other. the review-tools only look at auto-connection and installation for when to manual review
[14:26] <roadmr> jdstrand: did this change? did it imply installation?
[14:26] <pedronis> it doesn't respect the conventions though
[14:27] <jdstrand> roadmr: nothing has changed for months
[14:27] <roadmr> jdstrand: (context, someone is saying that a snap for which they have the above used to pass automated review but then started failing
[14:27] <roadmr> )
[14:27] <jdstrand> roadmr: right, months ago it was discovered that we weren't prompting for manual review for the docker interface when we should have. it changed then
[14:28] <jdstrand> roadmr: there were a handful of snaps that were affected. they must not have uploaded anything in a while
[14:28] <roadmr> jdstrand: like, 2 months ago? we narrowed the transition down to "2019-06-17 13:55 - 2 months, 2 weeks ago"
[14:28] <roadmr> jdstrand: perfect, that explains it :) do you mind if I give them allow-installation? this is a snap in a brand store and they'd been using docker previously
[14:29] <jdstrand> roadmr: 693121ef4ad15a0642967d5f7af69e52c1b8969d. Feb 15
[14:29] <roadmr> oh that's more than 2 months ago :)
[14:31] <jdstrand> pedronis: I guess it makes sense that allow-auto-connection implies installation as a practical matter, but that is not how we initially designed the feature. do you recall when that changed?
[14:32] <nessita> roadmr, the date would be relevant for our bump of review tools though, not necessarily when the review tools changed
[14:32] <nessita> (hi all!)
[14:32] <pedronis> jdstrand: it's always been like this
[14:33] <jdstrand> pedronis: oh, you mean because if it has nothing to say about installation, it is allowed
[14:33] <pedronis> yes
[14:33] <roadmr> nessita: indeed, but the gap is still puzzling - we certainly updated the tools between February and June, so it's weird this only started happening in June if the change was in the tools since Feb
[14:33] <nessita> roadmr, right
[14:34] <nessita> roadmr, have you, by any chance, downloaded the two revisions to compare if they changed anything in their manifest?
[14:35] <roadmr> nessita: nope
[14:35] <jdstrand> pedronis: right. that is different than auto-connection affecting installation if something does have something to say about it, which is what I meant
[14:35] <jdstrand> anyhoo, yes
[14:38] <jdstrand> roadmr: can you paste me their snap.yaml?
[14:38] <roadmr> jdstrand: sure, incoming
[14:39] <roadmr> jdstrand: https://pastebin.canonical.com/p/WJyNTTKQ8X/
[14:39] <ackk> hi, testing with the confined maas snap and snapd 2.41, I'm getting https://paste.ubuntu.com/p/cJxN7B4KpP/ all of a sudden, what could it be related to?
[14:40] <zyga> ackk: woah
[14:40] <zyga> ackk: is it /root?
[14:40] <ackk> zyga, what is?
[14:40] <zyga> I think it might be confused by root :)
[14:40] <zyga> ackk: there's a check that $HOME is not something crazy
[14:40] <zyga> ackk: but it may not capture /root
[14:40] <ackk> zyga, yeah "maas --help" works but "sudo maas --help" doesn't
[14:40] <zyga> Chipaca: ^ is that us?
[14:41] <zyga> Chipaca: if so that's a regression
[14:41]  * jdstrand notes that when to manual review is a different question than when to apply at install time
[14:41] <zyga> mvo: ^
[14:41] <ackk> zyga, oddly, I had just run "sudo maas init" a little before, and that must have worked
[14:41] <zyga> huh
[14:41] <zyga> that's more mysterious
[14:41] <ackk> lemme try a reproducer
[14:41] <mvo> zyga: thanks, in a meeting
[14:41] <zyga> ack
[14:41] <Chipaca> ackk: what distro?
[14:41] <zyga> ackk: thank you
[14:41] <ackk> Chipaca, bionic
[14:41] <mvo> zyga: but thanks for the heads up, please keep me updated about your finidings
[14:42] <Chipaca> sudo's path should have /snap/bin on it
[14:42] <mvo> might be the new systemd generator?
[14:42] <Chipaca> (some distros have it in bash but not in sudo which is weird)
[14:42] <Chipaca> ugh
[14:42] <zyga> https://github.com/snapcore/snapd/blob/fa465e97df3b159f18c77786cdc540d2cdcd29d5/cmd/snap-confine/user-support.c#L44
[14:42] <mvo> which went in with 2.41 but only in the debs
[14:42] <ackk> Chipaca, I'm pretty sure cloud images don't
[14:42] <Chipaca> ackk: don't what?
[14:42] <ackk> Chipaca, I'm in a lxd
[14:43] <ackk> don't have /snap/bin in path
[14:43] <ackk> at least, not for root
[14:43] <ackk> oh actually it seems they do now
[14:43] <Chipaca> ackk: in 'sudo visudo', you should see /snap/bin in 'secure_path'
[14:43] <zyga> I just shut down my desktop
[14:43] <zyga> but https://github.com/snapcore/snapd/commit/634a17c85718f15babe9fbe3cd85a36225bcfdd3
[14:44] <zyga> it could be a good attempt to add a /root home directory there to see what happenns (in spread test)
[14:44] <Chipaca> ackk: maybe you installed snapd, and didn't re-login?
[14:44] <ackk> Chipaca, it's there
[14:44] <ackk> Chipaca, nope, that's not a fresh container
[14:44] <ackk> I'm testing now in a fresh one, see if I can reproduce
[14:46] <jdstrand> roadmr: because of that ^ the tools look at the slots side for both *for slots that specifiy an installation constraint in the base decl*. the base decl convention for docker here is that a slot implementation may provide a so-called superprivileged interface but another impl of the same slot might not. again, change was intentional
[14:47] <roadmr> jdstrand: ah ok - got it
[14:47] <ackk> Chipaca, I did relogin just now fwiw, no difference
[14:48] <jdstrand> roadmr: oh, and the review-tools error is correct for that snap.yaml
[14:48] <jdstrand> s/correct/expected/
[14:49] <roadmr> awesome :) yes, just looks like behavior changed here and we didn't update the PD - I'll add allow-installation for them
[14:49] <roadmr> (behavior changed expectedly as you explained)
[14:49] <jdstrand> cool, thanks
[14:49] <roadmr> thank you for explaining :)
[14:50] <roadmr> I mean, it was pretty clear we needed to add allow-installation, the message says as much and fwiw I usually add both anyway - just wanted to understand why this changed
[15:06] <jdstrand> roadmr: speaking of the review-tools, can you pull 20190829-1435UTC? not urgent. only meaningful change for the store is sr_lint.py: improve error message with invalid Icon paths
[15:06] <roadmr> jdstrand: sure thing!
[15:07] <jdstrand> thanks :)
[15:19] <ppd1990> jdstrand: Hi, I'd be glad if you could weigh in on #7366 in the near future :) Am still in the office for a few hours with a little spare time for possible changes
[15:19] <mup> PR #7366: interfaces/gpg-keys: Allow access to gpg-agent and creation of lockfiles <Created by ppd1990> <https://github.com/snapcore/snapd/pull/7366>
[15:20]  * cachio lunch
[15:21] <doko> mvo: snapcraft autopkg test regressions in eoan
[15:23] <jdstrand> ppd1990: yes, it is on my list for today. note there is some history that I need to dig up for why it is the way it is
[15:29] <mvo> doko: hey, thanks for the heads up - sergiusens will take care of it I'm sure!
[15:32] <doko> mvo: well, it would be nice if the snappy team would notice these regressions on their own  by default ...
[15:34] <mvo> doko: right, I hear you and we try to be responsive. snapcraft is a different team though,
[15:40] <popey_> sergiusens: ^ see comments from doko
[15:43] <mvo> second review for 6705 would be great btw
[15:59] <mvo> ackk, zyga, Chipaca still in meetings - is there a tl;dr on this potential regression?
[16:00] <zyga> mvo: no, I took a break but I just stopped and writing a quick regression test
[16:00] <ackk> mvo, I don't have a clean reproducer but it seems related to the fact that I was ending up running snapcraft --destructive-mode with the snap mounted from the prime dir, so maybe that ends up confusing snapd?
[16:00] <mvo> ta
[16:01] <mvo> thanks! please keep me updated, if it turns out to be a regression I want to know as soon as possible
[16:01] <zyga> mvo: understood, sorry for lagging
[16:03] <mvo> zyga: no worries! it was not meant as being pushy :)
[16:04] <rbasak> What's the production status of core18? https://forum.snapcraft.io/t/ubuntu-core-18/5169 suggests it's experimental?
[16:04] <popey_> rbasak: that's a very old post
[16:04] <rbasak> It's the second hit for "snap core18" on Google.
[16:05] <rbasak> The first hit goes to the store page which doesn't answer my question.
[16:05] <pedronis> mvo: I will look at #6705 in my morning, slightly surprised by Chipaca's comments on it
[16:05] <rbasak> I can't find any announcement that says that core18 is production now?
[16:05] <mup> PR #6705: bootloader: little kernel support <Needs Samuele review> <Created by kubiko> <https://github.com/snapcore/snapd/pull/6705>
[16:06] <Chipaca> I will go for a run now and stop surprising people
[16:06] <mvo> Chipaca: enjoy!
[16:06] <zyga> Chipaca: +1
[16:07] <mvo> pedronis: I will fix the things that john mentioned, its a good point
[16:07] <mvo> (good points)
[16:07] <zyga> ackk: hey
[16:07] <zyga> still around?
[16:08] <zyga> ackk: what does "sudo env" say in that machine where it happened?
[16:08] <zyga> ackk: feel free to paste in private if sensitive
[16:09] <cwayne> rbasak: https://ubuntu.com/blog/ubuntu-core-18-released-for-secure-reliable-iot-devices
[16:09] <cwayne> top of https://ubuntu.com/core too
[16:09] <rbasak> cwayne: great. Thanks!
[16:09] <cwayne> np :)
[16:10] <mup> PR snapd#7399 closed: tests: verify retry-tool not retrying missing commands <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7399>
[16:11] <ackk> zyga, https://paste.ubuntu.com/p/gDNq93zrPC/
[16:11] <zyga> ackk: can you walk me through a case
[16:12] <zyga> ackk: this is inside a container, correct?
[16:12] <ackk> zyga, yes
[16:12] <zyga> ackk: how do you access the host of the container, via ssh?
[16:12] <zyga> ackk: when you access the container, how do you "jump into" it, via lxc shell?
[16:13] <ackk> zyga, via ssh, but I have my home bind-mounted in the container, so I ssh with the same user
[16:13] <zyga> ackk: bind mounted from the host of the container?
[16:13] <zyga> ackk: so you ssh into (guest) from (host) or from a different machine?
[16:13] <ackk> zyga, https://paste.ubuntu.com/p/XNq6w2sVGQ/
[16:14] <ackk> zyga, no, ssh from my laptop to the lxd on it
[16:14] <zyga> ackk: so (3rd computer) -> (guest) directly, via ssh?
[16:16] <ackk> zyga, why 3rd computer? the containres are on my laptop as well
[16:16] <zyga> ah, I understand now
[16:17] <zyga> so you ssh from the laptop, which is the host, directly into the container
[16:17] <ackk> zyga, correct
[16:17] <zyga> ackk: and inside the container, so in (guest), the user ack exists because it was added manually?
[16:18] <ackk> zyga, yes
[16:18] <zyga> ackk: and when you run sudo maas, snap-confine complains and quits
[16:19] <zyga> ackk: this is on 2.41 from the archive?
[16:19] <ackk> zyga, 2.41 snapd snap
[16:19] <ackk> from beta
[16:19] <zyga> aha, the snapd snap
[16:19] <zyga> ok, thank you
[16:19] <zyga> let me check stuff
[16:19] <zyga> can you run one simple test
[16:19] <zyga> snap install snapd-hacker-toolbelt
[16:19] <zyga> and see if that works
[16:19] <zyga> it's just a busybox snap
[16:20] <ackk> zyga, so, also the issue doesn't happen right away as I mentioned before. I have the snap installed via snap try, but was then running a sync target which ended up calling snapcraft again
[16:20] <ackk> zyga, sure
[16:20] <ackk> zyga, just run it?
[16:20] <zyga> yeah
[16:20] <zyga> so maas is in try mode?
[16:21] <ackk> zyga, yes
[16:21] <zyga> what is a sync target?
[16:21] <ackk> zyga, (that snap works fwiw)
[16:22] <zyga> ackk: can you try to unsquashfs snapd-hacker-toolbelt, edit it anyway you like (it's a static binary),
[16:22] <zyga> ackk: install it in try mode
[16:22] <ackk> zyga, so we have a makefile target that updates the prime/ dir based on the tree, so you can change code and have it copied. but that because of a recent change ended up calling "snapcraft --destructive-mode prime" again
[16:22] <zyga> and see if you can reproduce the issue somehow
[16:22] <ackk> zyga, it seems after that the snap had the issue
[16:23] <zyga> so there are two aspects
[16:23] <zyga> the message we saw indicates that we failed
[16:23] <zyga> the details only change the error message printed
[16:23] <zyga> so even if /root was handled in that logic, it would at most affect the failure message
[16:24] <zyga> the reason we saw that particular message is that we got EROFS
[16:24] <zyga> so we attempted to create a directory but got an EROFS error from the system
[16:24] <zyga> we can strace that to see what exactly failed
[16:24] <zyga> ackk: actually
[16:24] <zyga> ackk: if you can still reproduce it
[16:24] <zyga> please set SNAP_CONFINE_DEBUG=yes
[16:24] <zyga> and run that command again
[16:24] <ackk> zyga, where in the calling shell?
[16:24] <zyga> that will tell us all the details without the need of strace
[16:24] <zyga> ackk: after sudo
[16:25] <zyga> sudo SNAP_CONFINE_DEBUG=yes maas --help
[16:25] <ackk> oh ok, I don't have it right now but will try to reproduce tomorrow
[16:25] <zyga> ackk: so whatever really happened, it seems something has switched your home directory, or /root to read only mode
[16:55] <mup> PR snapcraft#2695 closed: spread tests: install package marker into ament index <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2695>
[17:47] <jdstrand> roadmr: sorry, can you pull 20190903-1746UTC? not terribly urgent, just an update to an override for core20
[17:48] <jdstrand> xnox: fyi ^
[18:13] <roadmr> jdstrand: sure, her it goes
[19:31] <jdstrand> roadmr: thanks!
[20:05] <sergiusens> doko: mvo I did an upload last week and it was all green
[20:08] <mup> PR snapcraft#2697 opened: Neon extension <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2697>
[20:18] <mup> PR snapd#7401 opened: tests: add unstable stage for travis execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7401>
[22:10] <diddledan> yootoobe: https://youtu.be/cWlYe0CE2iU
[22:15] <mup> PR snapd#7402 opened: daemon, client, cmd/snap: include architecture in 'snap version' <Created by chipaca> <https://github.com/snapcore/snapd/pull/7402>