[21:23] <j0sh> how do i propagate an instance variable to dependent jobs?
[21:23] <j0sh> eg, jobs that rely on "start on foo" behavior, and if 'foo' depends on an instance, how can i pass that information along?
[22:02] <JanC> j0sh: you want to start on a particular instance of foo?
[22:03] <JanC> particular instance of foo being started?
[22:08] <JanC> you can do something like: "start on started foo INSTANCE=bar"
[22:13] <j0sh> JanC: i need to start on all instances
[22:14] <j0sh> i think i figured something Close Enough by exporting the environment variable i'm trying to capture the instance into
[22:15] <JanC> http://upstart.ubuntu.com/cookbook/#standard-environment-variables --> you can probably export those
[22:17] <j0sh> yeah but im not sure if the INSTANCE environment variable is exported across dependencies (and i dont know how to check)
[22:17] <j0sh> but doing something like this worked okay
[22:17] <j0sh>   4 instance $PORT
[22:17] <j0sh>   5 export PORT
[22:19] <j0sh> is there any way to manipulate that variable, eg arithmetically?
[22:27] <JanC> you can change environment variables in a script section...


[00:56] <mgrandi> it seems bzr explorer does not like huge trees
[00:58] <mgrandi> http://bpaste.net/show/24322/
[01:17] <poolie> hi
[01:17] <poolie> yes it's a known bug
[01:17] <poolie> i thought bialix was going to turn file watchers off by default
[01:18] <poolie> it is too risky to be on til it's more stable
[01:18] <mgrandi> it was going to be turned off on windows by default
[01:18] <mgrandi> cause of its wonderful practice of one thing locking a file and then nothing else can use it
[01:18] <mgrandi> i'm on a mac atm
[01:20] <poolie> ah, maybe it should be off everywhere
[01:21] <mgrandi> well
[01:21] <mgrandi> this is a pretty extreme case, i'm just running a script (thats in a bzr directory) and by default it outputs stuff to the same dir the script is in
[01:21] <mgrandi> and it has 6,721 items totaling 800 mb sooo =P
[01:34] <mgrandi> be back on later~
[03:22] <AfC> bzr 2.5 is released, right? Does that mean in will be in ppa:bzr/ppa soon?
[03:42] <poolie> afc, right, quite soon
[04:09] <AfC> poolie: cheers (just hit a github repo that I'm trying to branch that gave me an error to do with nested trees; I'm hoping that 2.5 will parse it)
[05:45] <mgrandi> so, does bzr-git support pushing to github?
[06:10] <mgrandi> dont want to push to test it cause i dont wnat to mess up the branch >.>
[06:40] <LarstiQ> mgrandi: afaik it does
[06:40] <mgrandi> well
[06:40] <mgrandi> one way to find out
[06:40] <mgrandi> haha
[06:45] <mgrandi> and aww yeah thats sexy.
[06:51] <mgrandi> requires a dpush but it works perfectly.
[06:59] <mgrandi> anyway, bedtime~
[07:28] <Milky> Hello all
[07:28] <Milky> I am going to host a private bazaar for an internal team development
[07:28] <Milky> but can't come across a descent doc/manual that goes through this...
[07:29] <Milky> especially users administration
[07:30] <Milky> I still have no idea how this works, assigning branches to specific users, setting read-only one a mainstream branch for all users but one for example... etc
[07:30] <Milky> could anyone point me to the right direction?
[07:30] <Milky> Thanjs in advance
[07:50] <Milky> ...
[08:02] <mgz> morning
[08:17] <jelmer> hi mgz
[08:18] <mgz> hi!
[10:17] <poolie> o/ jelmer, mgz
[10:17] <mgz> hey poolie
[10:18] <jelmer> hey poolie
[10:19] <poolie> hi there, sorry i missed you before
[12:32] <stefanct> i am trying to setup a daily build recipe for a svn import, but i obviously have problems with the the deb-version string (or to be more precise with fulfillment of its prerequisites).
[12:33] <stefanct> i have included a nest-part statement for the debian part of the ubuntu package
[12:33] <stefanct> the first line of the recipe is bzr-builder format 0.4 deb-version {debupstream-base}-0~r{svn-revno}
[12:35] <stefanct> http://paste.ubuntu.com/860449/ is the complete recipe + bzr dailydeb output
[13:04] <jelmer> stefanct: hi
[13:04] <stefanct> hi jelmer
[13:04] <jelmer> stefanct: I think the 0.4 recipe format still has issues on launchpad
[13:05] <jelmer> stefanct: you might want to try 0.3 (though that unfortunately doesn't support some of the variables you're using
[13:05] <stefanct><EMAIL_ADDRESS>but i am testing locally. shouldnt it work there?
[13:05] <jelmer> stefanct: it should work locally indeed
[13:06] <jelmer> stefanct: there isn't any packaging in lp:flashrom I guess?
[13:06] <jelmer> in that case you want {debupstream-base:packaging}
[13:07] <stefanct> a "packaging" directory?
[13:07] <jelmer> stefanct: packaging refers to the branch you're nesting
[13:08] <jelmer> stefanct: your deb-version has {debupstream-base} which would take the version string from the 'debian/changelog' file in the root branch (lp:flasrom)
[13:08] <jelmer> except there is no such file in the root branch
[13:08] <jelmer> {debupstream-base:packaging} makes it look at the branch nested under the 'packaging' name
[13:09] <stefanct> ah!
[13:09] <stefanct> are there any good docs about that? this is all missing from the help.launchpad.net pages :/
[13:10] <stefanct> well.. i should recheck that first before blaming.. :)
[13:10] <stefanct> "Here fix-build is a unique short name that we'll use to refer to this branch throughout the recipe." my bad.
[13:13] <jelmer> stefanct: see also 'bzr help builder'
[13:14] <stefanct> ah. i was looking at the man page...
[13:17] <stefanct> jelmer: thanks a lot! --no-build completes now successfully locally and i think i know enough to solve the ppa build on my own
[13:19] <jelmer> cool
[13:25] <stefanct> but it explodes ofc on launchpad due to https://bugs.launchpad.net/launchpad-buildd/+bug/915505 :)
[13:27] <jelmer> stefanct: yep, that's the bug I had in mind earlier
[13:29] <stefanct> last question hopefully: is it possible to have comments in recipes? # obviously is not ignored :) i would like to add a 0.4 template for later when that bug is solved
[13:30] <jelmer> stefanct: yes, you can have comments but they have to start at the beginning of a line
[13:30] <jelmer> I'm not sure if launchpad preserves them
[13:38] <stefanct> it does not
[13:43] <jelmer> stefanct: I guess you can put it in the recipe description
[13:44] <stefanct> good idea, but i dont trust launchpad... ill save it locally too :)
[18:17] <wilx> Hi.
[18:18] <wilx> Is it possible to sync-pipeline and then work with the pipeline in the other location?
[18:19] <wilx> I have done this: 1) created a pipeline and done some changes. 2) bzr sync-pipepile /my/usb/flash/memory. 3) bzr sync-pipeline /home/wilx/mysharedrepo.
[18:19] <wilx> Now, it has created two branches in the shared repor with the names of the pipes in the pipeline.
[18:19] <wilx> But the branches are not the pipeline it seems.
[18:20] <wilx> I cannot bzr swp in them.
[18:21] <wilx> While bzr pipes still shows the pipeline pipes in each of the branches.
[18:21] <wilx> Ideas?
[18:34] <stefanct> jelmer: first binary package just built successfully by the recipe, thanks again and bye :)
[19:11] <jelmer> wilx: hi
[19:11] <jelmer> wilx: no idea, you might want to talk to abentley
[19:13] <abentley> wilx: you ought to be able to, but I haven't tested it recently.
[19:23] <wilx> http://codepad.org/AUt0awX5
[19:24] <wilx> Here is a log of what I have done. The bottom shows the problem.
[19:35] <abentley> wilx: Right, you need to create a lightweight checkout of branch1 or pipe2.
[19:37] <wilx> Would that be bzr co --lightweight in the branch1 dir?
[19:38] <abentley> wilx: co --lightweight $PATH_TO_BRANCH1 anywhere except the branch1 dir.
[19:39] <wilx> Ah.
[19:42] <wilx> I see. It works that way.
[19:42] <wilx> However it makes layout different from the inital pipeline which is surprising.
[19:44] <abentley> wilx: I mostly use sync-pipeline for pushing to Launchpad, and producing that sort of layout wouldn't work.  Launchpad needs the branches to be separate.
[19:46] <wilx> I see.
[19:46] <wilx> Maybe there should be a switch to allow the original repo layout for other destinations/transports.
[19:48] <abentley> wilx: probably the easiest way to reproduce that layout manually is to colo-init, and then sync-pipeline into colo/.bzr/branches
[19:55] <abentley> wilx: btw, until recently, the layout produced by reconfigure-pipeline is one I never used.  I would do "bzr init-repo --no-trees branches; bzr init branches/branch1; bzr checkout --lightweight branches/branch1/"
[19:56] <wilx> I see.
[20:00] <abentley> wilx: if you're using reconfigure-pipeline, init-repo isn't strictly necessary.  reconfigure-pipeline creates a shared repository.
[20:05] <jono> hey all
[20:05] <jelmer> hey jono
[20:05] <jono> hey jelmer!
[20:06] <jono> if I have a branch that I want to merge into another one, and the branch I want to merge in has much of the same code structure, but re-factored, is bzr smart enough to find the right code fragment and merge the branch?
[20:07] <jelmer> jono: the branches aren't related in any other way?
[20:07] <jono> jelmer, so this is what is happening:
[20:07] <jono> I have a branch and someone is re-factoring the code
[20:07] <jono> but moving the code around, changing some of the method names etc
[20:07] <jono> much of the original code logic is the same
[20:08] <jono> but I want to write some changes and I am not sure if I should hold off
[20:08] <wilx> Are your changes conflicting his changes?
[20:08] <wilx> Then hold off. Otherwise proceed.
[20:09] <jono> wilx, this is the thing, I don't know - I suspect they won't because he is just moving some code around - the code itself doesnt change
[20:09] <jono> but as an example if I patch my_func() and the file my_func() is in changes, would the patch still apply?
[20:09] <jelmer> jono: if you're going to be changing the same code that he is moving around then I would wait
[20:09] <jono> thanks jelmer
[21:21] <lifeless> jono: best way to tell: just try merging :)
[21:21] <lifeless> jono: you can always do your changes on top of his branch, rather than in trunk
[21:21] <lifeless> jono: or you can do yours in trunk and let him(or her) merge from you before they submit
[21:31] <thomi> jelmer: I just saw your bug on indicator-jenkins - I didn't think anyone knew about that yet
[21:32] <thomi> jelmer: the bug's been fixed in trunk, and there's a package building - should be done in 1 hour
[21:33]  * jelmer hugs thomi
[21:33] <jelmer> I don't remember where I learned about indicator-jenkins, but it seemed like a nice thing to try
[21:33] <thomi> let me know if you have any more problems with it. I'll get it working well then send an email out to the canonical QA lists...
[21:37] <wilx> jelmer: Hey, thanks for the quick patch for the bzr:// URI mirroring.
[21:59] <jono> thanks lifeless
[22:29] <poolie> hi all
[22:34] <wgz> hey poolie
[22:44] <jelmer> hi poolie, wgz


[00:54] <fcuk112> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/481479 in order to fix this bug, should cdrecord be added as a dependency of the package?
[00:54] <ubot4> Launchpad bug 481479 in linux "xcdroast doesn't work in Karmic Koala" [Undecided,Confirmed]
[00:57] <dtchen_> does it *really* need xcdroast?
[00:57] <dtchen_> sorry
[00:57] <dtchen_> does it *really* need cdrecord?
[00:58] <fcuk112> dunno, if the app errors with that message it should do?  should i check if that string is hard-coded?
[00:58] <kklimonda> isn't it duplicate of bug 380144 ?
[00:58] <ubot4> Launchpad bug 380144 in xcdroast "xcdroast+wodim can't setup (1st run as root)" [Undecided,Confirmed] https://launchpad.net/bugs/380144
[00:59] <kklimonda> debian bug 523639 may have more info about it and some patches
[00:59] <ubot4> Debian bug 523639 in xcdroast "xcdroast: Failed to access cdrecord" [Normal,Open] http://bugs.debian.org/523639
[00:59] <kklimonda> fcuk112: ^^^
[01:01] <micahg> hi yoasif
[01:03] <fcuk112> thanks guys.
[01:37] <jtniehof> I'm confused by https://wiki.ubuntu.com/Bugs/HowToTriage/ ...it says (under Confirming) 'Change the "Assigned to" field to "Nobody"', but that doesn't seem possible. i.e. there's no "Nobody" as a special option, just lots of Launchpad users who put "nobody" as their name
[01:38] <jtniehof> should I just leave it as "Unassigned"?
[01:38] <micahg> jtniehof: yes, bugs should be unassigned unless someone is working on it
[01:38] <micahg> as in a developer
[01:39] <jtniehof> thanks. I'll edit the wiki then....
[02:50] <FFEMTcJ> can someone wishlist Bug #481688
[02:50] <ubot4> Launchpad bug 481688 in gnome-system-monitor "Can you add features like 'power consumed' ?" [Undecided,New] https://launchpad.net/bugs/481688
[02:52] <WeatherGod> Is there a better way to edit the wiki page than through the browser?
[02:53] <WeatherGod> the text comes out so big that it is hard to find the line I want in the text box
[03:01] <micahg1> FFEMTcJ: done
[03:01] <micahg> WeatherGod: that's the only was I know of
[03:02] <FFEMTcJ> thanks micahg
[03:02] <micahg> FFEMTcJ: the bug still needs triage though :)
[03:04] <WeatherGod> ok, just annoying that I can't get Firefox to search for the bug number within an edit box, it seems
[03:04] <WeatherGod> also, any idea why bug 425166 was listed as a new bug when it was also listed in the "send upstream" list as well?
[03:04] <ubot4> Launchpad bug 425166 in nautilus "Nautilus *.txt file behaviour" [Low,Triaged] https://launchpad.net/bugs/425166
[03:05] <hggdh> bug 478962
[03:05] <ubot4> Launchpad bug 478962 in udev "After upgrade to Karmic, CD/DVD drive no longer works" [Low,New] https://launchpad.net/bugs/478962
[03:06] <micahg> WeatherGod: are you trying to record stuff for the hugday?
[03:06] <WeatherGod> record stuff?
[03:07] <micahg> add your name and mark it
[03:07] <WeatherGod> hggdh, yeah, that's epic one
[03:07] <hggdh> heh
[03:07] <WeatherGod> micahg, yes, I notice that that bug I already worked on was in the other list as well
[03:07] <micahg> WeatherGod: https://wiki.ubuntu.com/UbuntuBugDay/Tools
[03:07] <hggdh> good work there, though. Although you went way far than needed ;-)
[03:08] <WeatherGod> she reminds me of one of my aunts
[03:08] <hggdh> WeatherGod: if you are triaging a bug, and you ask for more data, it is OK (and actually expected) to change the status to INCOMPLETE
[03:09] <hggdh> darn, she *does* remind me on one of mine also
[03:09] <WeatherGod> yeah, i have been doing that more recently
[03:09] <WeatherGod> I gotta go back over my old ones and fix that
[03:09] <WeatherGod> although, it seems like apport keeps on resetting it to new?
[03:09] <hggdh> but good work
[03:09] <WeatherGod> or it is the user themselves
[03:10] <WeatherGod> hggdh, thanks
[03:12] <WeatherGod> micahg, I'll install those tools right now
[03:13] <WeatherGod> the problem with the nautilus focus today is that I use UNR, and a lot of these things I can't even verify
[03:13] <micahg> WeatherGod: sorry, I didn't get what you meant initially when you said edit the wiki
[03:13] <WeatherGod> micahg, np
[03:14] <micahg> WeatherGod: just do what you can :), you can tackle the ones that need upstreaming :)
[03:15] <hggdh> WeatherGod: another good package to install (if you are running firefox) is firefox-lp-improvements
[03:15] <WeatherGod> any idea why the *.txt bug was listed twice?
[03:15] <WeatherGod> oh?
[03:16] <hggdh> er. which *.txt bug?
[03:17] <WeatherGod> bug 425166
[03:17] <ubot4> Launchpad bug 425166 in nautilus "Nautilus *.txt file behaviour" [Low,Triaged] https://launchpad.net/bugs/425166
[03:19] <WeatherGod> Ok, installing the qa tools, and it is having me do a bunch of postfix stuff...
[03:19] <mrand> I don't have time to push it upstream - but Bug 472437 looks to have a valid stack trace that may make it easily actionable.
[03:19] <ubot4> Launchpad bug 472437 in gnome-system-monitor "gnome-system-monitor keeps crashing with signal 7 (on a Jaunty booted from USB)" [Medium,New] https://launchpad.net/bugs/472437
[03:19] <mrand> If someone would like to take it.
[03:20] <WeatherGod> just needs to go upstream to gnome?
[03:20] <WeatherGod> I can push it there
[03:21] <mrand> WeatherGod: cool.  Take credit for it on hugday
[03:22] <hggdh> WeatherGod: personally, the txt bug is a wontfix. But let's see what upstream says
[03:22] <WeatherGod> personally, I think that is one of those "seems easy to fix, but has a lot of nasty implications" type things
[03:23] <WeatherGod> I think my writeup on the gnome site was fair
[03:23] <hggdh> yes, this is the point. The OR (original reporter) is expecting file suffix to always match windows. This will not happen
[03:24] <hggdh> WeatherGod: it was.
[03:24] <WeatherGod> and using mime-types is bad
[03:25] <WeatherGod> quite honestly, i think just having the fat32 and ntfs partitions mount as noexec would be a better solution
[03:26] <WeatherGod> but I don't think others would be happy with that
[03:26] <hggdh> about bug 472437 -- I would like the OR to run gnome-system-monitor from a terminal, and attach the output to the bug
[03:26] <ubot4> Launchpad bug 472437 in gnome-system-monitor "gnome-system-monitor keeps crashing with signal 7 (on a Jaunty booted from USB)" [Medium,New] https://launchpad.net/bugs/472437
[03:27] <WeatherGod> ok, I'll add that to the report as well as filing upstream
[03:27] <hggdh> it would be safer to mount them noexec, I agree. This is what I personally used to do, when I had to mount NTFSs
[03:28] <WeatherGod> what repo is the firefox improvements package in... can't seem to find it?
[03:29] <hggdh> oh, the version there is from jaunty...
[03:29] <hggdh> hold on, there is a ppa with it
[03:29] <WeatherGod> I am using Jaunty
[03:29] <micahg> https://launchpad.net/~gm-dev-launchpad/+archive/ppa
[03:29] <WeatherGod> I haven't fully moved to Karmic yet
[03:29] <hggdh> WeatherGod: use the PPA
[03:30] <hggdh> more up-to-date
[03:30] <WeatherGod> ok
[03:33] <hggdh> micahg: thank you, BTW
[03:33] <micahg> hggdh: np
[03:44] <micahg> hggdh: can you tell me if an upstream for a bug seems correct?
[03:44] <micahg> bug 448343 and gnome bug 579026
[03:44] <ubot4> Launchpad bug 448343 in nautilus "While brasero records a disk nautilus keeps trying to mount it" [Low,Confirmed] https://launchpad.net/bugs/448343
[03:44] <ubot4> Gnome bug 579026 in general "Nautilus should ignore blank CD/DVD insertion when a CD/DVD is being copied" [Enhancement,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=579026
[03:44] <hggdh> micahg: looking
[03:46] <hggdh> micahg: they really sound like the same thing
[03:46] <hggdh> you take care of it, or I?
[03:46] <micahg> I'll take care of it
[03:46] <hggdh> k
[03:46] <micahg> thanks
[03:47] <micahg> ugh
[03:47] <hggdh> ugh?
[03:47] <micahg> can you add the downstream link on bgo
[03:47] <micahg> and I'll update the LP bug
[03:47] <micahg> I don't think I have a bgo account yet
[03:48] <hggdh> will do. I was going to propose you that ;-)
[03:48]  * micahg just wanted to add one for the hugday
[03:48] <hggdh> cuz I also want to upgrade the nautilus version
[03:52] <hggdh> done
[03:52] <micahg> thanks
[03:52] <micahg> hggdh: unfortunately, the reported didn't include a version :)
[03:52] <micahg> neverming
[03:52] <hggdh> well, yes, the OR stated running karmic
[03:53]  * micahg can';t read tonight :)
[03:53] <hggdh> heh
[03:53]  * hggdh has a migrane
[03:53] <WeatherGod> nor type
[03:53] <WeatherGod> finally got the stuff installed
[03:53] <WeatherGod> stupid key auth... kept mistyping it
[03:54] <hggdh> and the migrane was made worse by an (unrelated) email denying the holocaust :-(
[03:54] <WeatherGod> shouldn't those go to spam?
[03:55] <WeatherGod> I pretty much trained mine to spot all those no-global-warming emails my parents keep trying to send me
[03:55] <hggdh> it was a serious email, up to this point
[03:55] <WeatherGod> ugh, that sucks
[03:55] <hggdh> yup
[03:55] <micahg> another example of why filetypes don't work...people can have files with spaces after the extension :)
[03:56] <WeatherGod> I *hate* those!
[03:56] <hggdh> good one, micahg! We usually do not think about spaces *after* the dot
[03:56] <micahg> yep '.png ' :)
[03:56] <WeatherGod> he isn't talking about after the dot, he is talking about after the extention
[03:57] <micahg> WeatherGod: he knows
[03:57] <WeatherGod> try doing a "eog foobar.png '
[03:57] <WeatherGod> hehe
[03:57] <micahg> WeatherGod: it's still after the dot
[03:57] <micahg> just not right after
[03:57] <hggdh> eof foobar. png
[03:57] <WeatherGod> ah, true
[03:57] <WeatherGod> hehe
[03:57]  * hggdh cannot type either
[03:58] <WeatherGod> I once accidentially named a file to start with a hyphen... *that* was annoying
[03:58] <hggdh> fun
[03:58] <WeatherGod> "rm -badfile.txt".... "unknown option"
[03:58] <dtchen_> thank you, --
[03:59] <WeatherGod> yeah, that was a few years ago, didn't know about that, neither did the sys admin
[03:59] <WeatherGod> just went to the gui instead
[03:59] <hggdh> :-)
[04:00] <WeatherGod> ok, let's see if I can figure these tools out
[04:00] <WeatherGod> I'll try this out with 472437
[04:03] <WeatherGod> sweet, the  hugday program is cool
[04:03] <WeatherGod> wonder if I can get it working on Fedora?
[04:04] <WeatherGod> will have to repackage it for rpms, of course... but then I could do hugdays while at work
[04:04] <micahg> WeatherGod: you can use the bzr repo
[04:04] <WeatherGod> ah, and compile from source?
[04:05] <micahg> WeatherGod: they're python scripts...no compiling AFAIK
[04:05] <hggdh> but will have prereqs, at least the lp library
[04:05] <hggdh> still, should not be difficult
[04:06] <WeatherGod> ok... I'll look into it tomorrow at work
[04:07] <micahg> hggdh: there's more stuff in ubuntu-qa-tools than the hugday stuff
[04:07] <hggdh> yes
[04:08] <hggdh> and thank you for remembering me to bzr pull my local image ;-)
[04:09] <WeatherGod> np
[04:29] <WeatherGod> anybody else find it funny what the command is to look up the man pages for 'hugday'?
[04:33] <WeatherGod> 'man hugday'
[04:38] <WeatherGod> ok, I pushed bug 472437 upstream, and added a note to the OR for more info
[04:38] <ubot4> Launchpad bug 472437 in gnome-system-monitor "gnome-system-monitor keeps crashing with signal 7 (on a Jaunty booted from USB)" [Medium,New] https://launchpad.net/bugs/472437
[04:39] <WeatherGod> mrand passed this one off to me, I thought it was listed for hugday, but I don't see it
[04:41] <WeatherGod> I'll look at it some more tomorrow...
[07:45] <bossekr> hi all; within the last two days I tried to use the<EMAIL_ADDRESS>email interface to change bugs in Ubuntu as Debian developer for "my" package but nothing happens
[07:50] <bossekr> loot at my email at http://pastie.org/696927 and find the problem why<EMAIL_ADDRESS>does not work, thx
[12:08] <ikt> https://bugs.launchpad.net/nautilus/+bug/476958 <- needs to be set to triaged
[12:08] <ubot4> Launchpad bug 476958 in nautilus "Cannot share a folder via right click on folder->sharing options->share this folder" [Low,Confirmed]
[12:10] <pedro_> ikt, done, thanks for sent it upstream
[12:10] <ikt> np :)
[13:06] <bddebian> Boo
[13:35] <qense> hello bug channel
[13:37] <ror> every single time I restart my computer I need to reinstall libdvdread4. Every single reboot!
[13:37] <ror> this is getting old :(
[13:50] <qense> pedro_: could you renew my membership? It's about to expire very soon and I wouldn't want to be kicked out of bugcontrol ;)
[13:51] <pedro_> qense, sure, 'qense' is your lp id ?
[13:57] <pedro_> qense, renewed
[14:03] <qense> pedro_: sorry, wasn't paying attention. Thanks for the renewal!
[14:03] <pedro_> qense, you're welcome
[14:24] <dacone> hi'lo #ubuntu-bugs
[14:25] <dacone> im haveing corrupted data after using "dvgrab" it happens randomly, and i can't seem to find similar issues using google, any idea?
[15:03]  * bcurtiswx_ waves to room
[15:10]  * nigel_nb waves to bcurtiswx_
[15:26] <nigel_nb> hggdh: were you by any chance able to find me a mentor?
[15:31] <nigel_nb> about bug 481753
[15:31] <ubot4> Launchpad bug 481753 in netbook-launcher "Can't make an app launcher" [Undecided,New] https://launchpad.net/bugs/481753
[15:32] <nigel_nb> it seems more like a question
[15:50] <hggdh> nigel_nb: sorry for the delay. I am still looking for mentors in the UTC+6 TZ
[15:50] <nigel_nb> hggdh: it doesnt matter where the person is
[15:50] <hggdh> OK. I will take you on, then
[15:51] <nigel_nb> hggdh: ah, great :)
[15:51] <hggdh> please be aware that -- right now -- I am working remote, so I am logged in pretty much as I show in the https://wiki.ubuntu.com/BugSquad/Mentors page
[15:53] <hggdh> nigel_nb: for bug 481753: this is not really a question, but could be looked at as a wishlist: .jar-deployed applications would have to be either mime-typed, or prefixed by a 'java -jar' call
[15:53] <ubot4> Launchpad bug 481753 in netbook-launcher "Can't make an app launcher" [Undecided,New] https://launchpad.net/bugs/481753
[15:53] <nigel_nb> ah
[15:54] <hggdh> nigel_nb: what is your LP id?
[15:54] <nigel_nb> nigelbabu
[15:55] <hggdh> done
[15:55] <nigel_nb> thank you :)
[15:55] <nigel_nb> I'll be working the whole night today
[15:57] <nigel_nb> bug 482189 is not exactly a bazaar bug
[15:57] <ubot4> Launchpad bug 482189 in bzr "wrong permissions of .bazaar" [Undecided,New] https://launchpad.net/bugs/482189
[15:57] <nigel_nb> bazaar behaves as it is supposed to
[15:58] <nigel_nb> its a universe package which created a problem by bringing home folder under bazaar
[16:02] <hggdh> nigel_nb: ask the reporter how was the installation of bazaar and etckeeper done. This may be, indeed, misuse
[16:02] <dacone> what could be the cause for jammed data from using dvgrab?
[16:02] <hggdh> dacone: have you searched LP for a similar bug?
[16:03] <dacone> hggdh, LP?
[16:03] <dacone> launchpad
[16:03] <dacone> yes
[16:03] <nigel_nb> in the meantime, couldnt he run "sudo bzr remove /home" ?
[16:03] <dacone> no one seems to have problems once dvgrab works
[16:06] <hggdh> !dvgrab
[16:06] <ubot4> Factoid 'dvgrab' not found
[16:06] <hggdh> !info dvgrab
[16:06] <ubot4> hggdh: dvgrab (source: dvgrab): grab digital video data via IEEE1394 and USB links. In component universe, is extra. Version 3.4-1build1 (karmic), package size 134 kB, installed size 356 kB (Only available for alpha amd64 arm armel armeb hppa i386 ia64 mips mipsel powerpc ppc64 s390 sparc)
[16:07] <WeatherGod> oh, neat!
[16:07] <WeatherGod> nice bot there
[16:07] <hggdh> indeed
[16:07] <dacone> [X] agree
[16:08] <hggdh> dacone: so you use dvgrab and, after using it you start having data corruption? Can you explain a bit more?
[16:09] <hggdh> nigel_nb: better not 'sudo bzr remove /home' ...
[16:09] <dacone> hggdh, setup: we have a miniDV camcorder attached via ieee1394-firewire, a huge load of miniDV tapes and enough time.
[16:09] <nigel_nb> hggdh: I read up that software, its meant to keep track of changes made to /etc
[16:09] <dacone> hggdh, the firewirelink seems to be ok (although dvgrab complains about lost frames at startup)
[16:09] <hggdh> nigel_nb: yes. One way to test... install the beast
[16:10] <nigel_nb> hmm...
[16:10] <nigel_nb> lemme do that
[16:11] <WeatherGod> hggdh, quick question, how should I triage bug 482166?
[16:11] <ubot4> Launchpad bug 482166 in ubuntu "Ubuntu 9.10 installation grub error 15" [Undecided,New] https://launchpad.net/bugs/482166
[16:11] <WeatherGod> looks like it was an error with installation process
[16:11] <dacone> hggdh, dvgrab does apparently everything we want (winding, rewinding playing etc.) but when used to rip the tapes dvgrab produces huge files and none of our programs seem to be able to read them
[16:12] <dacone> hggdh, i use dv2 to store the data -opendml and -a to actually split the dump into files matching the chapters -t to set the date to each filename
[16:12] <hggdh> dacone: so the problem seems to be 'ripping DV tapes with dvgrab produces bad output', or similar, correct?
[16:13] <bcurtiswx_> WeatherGod: where does the MBR get stored?
[16:13] <dacone> hggdh, yes, but "randomly" i cant find out when the error occurs
[16:13] <hggdh> dacone: so sometimes it *does* produce good output?
[16:13] <hggdh> bcurtiswx_: in the MBR? ;-)
[16:13] <WeatherGod> that's what I was going to say
[16:13] <dacone> hggdh, its a bit like there was a hardcoded "only write 50% of files correclty, then change endieness"
[16:14] <bcurtiswx_> hggdh: idk these things... :P which is on the motherboard? on a drive? what?
[16:14] <hggdh> bcurtiswx_: it gets written on the disk
[16:15] <WeatherGod> bcurtiswx_, the MBR (Master Boot Record) goes at the very beginning of the disk
[16:15] <M1Tn1Ck> hy
[16:15] <WeatherGod> the bios checks it to start the boot process
[16:15] <hggdh> dacone: can you provide a sample input and output?
[16:15] <dacone> hggdh, to speak in human readable terms: approx. 11Gbyte data/tape and 1-7Gbyte unreadeable...
[16:15] <bcurtiswx_> if you say it's on the MBR then I wasn't paying attention in computer building class
[16:15] <hggdh> heh
[16:16] <bcurtiswx_> sorry, my wireless keps DC at work
[16:16] <dacone> hggdh, i dont know how, input is miniDV-tape and output is DV2-AVI
[16:16] <bcurtiswx_> ok so that bug IMO seems huge is Ubuntu is installed on a hard drive which the BIOS doesn't read at first?
[16:16] <WeatherGod> bcurtiswx_, also, that is a good reason why you shouldn't have the boot on RAID5
[16:17] <hggdh> dacone: sounds like a good bug for me. There is probably a way of running dvgrab in debug mode
[16:17] <WeatherGod> bcurtiswx_, yeah, the install process seems to have chosen the wrong disk, which is *very* dangerous!
[16:17] <hggdh> bcurtiswx_: when you partition/format your disks, usually you select one (disk or partition) to be the bootable device. The MBR will be written there
[16:18] <WeatherGod> I once almost messed up a software RAID that way
[16:18] <bcurtiswx_> hggdh: so if you install ubuntu using the liveCD on a drive that the BIOS reads second... it could be very dangerous?
[16:19] <WeatherGod> bcurtiswx_, it is dangerous if you accidentially write where you didn't intend to
[16:19] <bcurtiswx_> i know that........
[16:19] <bcurtiswx_> i apparently suck at getting my point out
[16:19] <dacone> hggdh, i also notices crashes when dvgrab is invoked with "-a" (autosplit) when -t (timecode) is missing, my explanation is, that dvgrab doesnt provide filenumbering without this timecode function
[16:20] <hggdh> dacone: this is a bug, certainly
[16:20] <WeatherGod> bcurtiswx_, most of the time, for most people, this is not an issue as they only have one drive
[16:21] <bcurtiswx_> WeatherGod: yeah, I get all this... i just didn't say things right.... maybe i need to start drinking coffee
[16:21] <WeatherGod> but it is still bad, nevertheless
[16:21] <WeatherGod> heh, if you like drinking burnt toast, sure...
[16:23] <bcurtiswx_> I don't drink coffee.. but it seems with the lack of caffeine in the mornings my IQ seems to average around 20 until lunch
[16:23] <bcurtiswx_> anything in specific that grub bugs should have....? <as i look for a wiki page on this>
[16:24] <hggdh> bcurtiswx_: I *do* drink coffee, and still my IQ hovers on the cretin level, sometimes the whole day
[16:24] <WeatherGod> sounds like a personal problem to me...
[16:24] <bcurtiswx_> hggdh: lol
[16:24] <dacone> hggdh, as i said i have time, and the need to fix this, which way would you suggest i should go? launchpad?
[16:25] <hggdh> dacone: certainly opening a bug on LP seems a good option. Additionally, you may want to find who is upstream for dvgrab, and search there
[16:26] <dacone> hggdh dvgrab seems to be part of the kinodv.org, i'll try LP first.
[16:27] <hggdh> dacone: opening a bug on LP will (hopefully) indicate to some other sufferer that this has been seen
[16:27] <hggdh> but checking upstream will probably get you a faster response
[16:28] <dacone> hggdh, you mean i should try to find the package maintainer for dvgrab@ubuntu
[16:28] <hggdh> this might help, yes -- it will be a MOTU.
[16:30] <bcurtiswx_> ubuntu livecd installer = ubiquity.. right?
[16:30] <hggdh> debian-installer?
[16:30] <WeatherGod> bcurtiswx_, yes
[16:34] <bcurtiswx_> bug 482166 taken care of WeatherGod
[16:34] <ubot4> Launchpad bug 482166 in ubuntu "Ubuntu 9.10 installation grub error 15" [Undecided,New] https://launchpad.net/bugs/482166
[16:34] <bossekr> hi all; I'm looking for help with<EMAIL_ADDRESS>interface. I send an email with following content http://pastie.org/697459 with my debian email and nothing happens
[16:35] <mrand> bossekr: did you sign your message?
[16:36] <WeatherGod> bcurtiswx_, thanks, but I am not quite sure what they can do for Karmic... any changes to Ubiquity means that the LiveCD images have to be redone
[16:36] <bossekr> yes, another try with my PGP I send is here http://pastie.org/697465; both without success
[16:37] <bossekr> s/PGP/GnuPG/g
[16:37] <mrand> bossekr: do you have that key registered on launchpad?
[16:37] <bcurtiswx_> WeatherGod 9.10.1 should get a fix for that..
[16:37] <bcurtiswx_> WeatherGod: well... i'm hoping
[16:39] <dacone> pizza_set_size: assertion `pizza != NULL' failed, no pizza left in space
[16:40] <bcurtiswx_> maybe in 100 years we'll be programming computers to create pizza...
[16:40] <bcurtiswx_> :P
[16:40] <WeatherGod> pizza is better than cookies
[16:44] <bossekr> mrand, do I did not; I will do it right now
[16:47] <bcurtiswx_> <drum hit>
[16:48] <WeatherGod> bcurtiswx_, you are later than smitty on Leno
[16:49] <WeatherGod> :-P
[16:49] <bcurtiswx_> i got DC again... hopefully i didn't miss much... i wonder why my wireless is soo flaky..
[16:49] <bcurtiswx_> 11:43-11:47ET i missed
[16:49] <WeatherGod> sounds like another bug report to me
[16:50] <bcurtiswx_> could be the broadcom driver....
[16:51] <WeatherGod> could be... I was having trouble last month with random drops
[16:53] <WeatherGod> This is a very nice webpage: https://wiki.ubuntu.com/DebuggingProcedures
[16:53] <WeatherGod> but it needs more
[16:53] <WeatherGod> there is nothing here about Software Center
[16:54] <bcurtiswx_> dont' hesitate to update it if you want to... everytime ubuntu changes a large chunk of wiki pages become "outdated"... its hard to keep up
[16:54] <WeatherGod> and I don't see anything about UbuntuOne
[16:54] <bcurtiswx_> comma between changes and a
[16:55] <WeatherGod> well, before adding anything, I would want to make sure I have my facts straight
[16:56] <WeatherGod> for example, with Software Center, I have noticed that you have to run synaptic first (with a Refresh) before SC starts working again
[16:56] <WeatherGod> I have no clue if that is an official fix or what is the bug to link to for that, though
[16:57] <bcurtiswx_> Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)
[16:57] <bcurtiswx_> = flaky
[16:57] <WeatherGod> yeah, very
[16:58] <bcurtiswx_> is there a non-free driver for it? ubuntu didn't recognize anything
[16:58] <WeatherGod> Atheros is the non-free driver, I believe
[16:58] <WeatherGod> I was using madwifi for a while
[16:58] <WeatherGod> don't know what happened to that project though
[16:59] <WeatherGod> also required a recompile for each kernel update
[16:59] <WeatherGod> really annoying
[17:00] <bcurtiswx_> in synaptic search typing "atheros" i get hostapd
[17:00] <bcurtiswx_> mentiones madwifi
[17:02] <WeatherGod> I'll look into it for the next update for that machine
[17:02] <WeatherGod> haven't turned it on in ages, though
[17:02] <bcurtiswx_> lol, k
[17:02] <bcurtiswx_> i installed hostapd.. maybe something will change...
[17:03] <bcurtiswx_> brb
[17:08] <WeatherGod> got a bug report here about a failure to install LinuxMint... should I mark it as invalid?
[17:08] <bdmurray> what number?
[17:09] <WeatherGod> bug 481852
[17:09] <ubot4> Launchpad bug 481852 in ubiquity "Mint-8RC1 Installer crashed" [Undecided,New] https://launchpad.net/bugs/481852
[17:10] <bdmurray> Yes, because they aren't using the ubuntu version of ubiquity
[17:10] <bdmurray> Nov 13 10:41:45 mint ubiquity[3844]: Ubiquity 2.0.8-1mint3
[17:10] <WeatherGod> ok
[17:12] <bdmurray> you might double check in the installer channel though
[17:13] <bdmurray> that's #ubuntu-installer
[17:13] <WeatherGod> ah, thanks
[17:13]  * bcurtiswx_ waves to bdmurray
[17:15]  * bdmurray waves back
[17:16] <bcurtiswx_> bdmurray: you going to UDS?
[17:17] <bdmurray> bcurtiswx_: yes
[17:18] <bcurtiswx_> bdmurray: awesome, enjoy.  One of these days I'll go as a people watcher...
[17:24] <WeatherGod> haha: bug 481840
[17:24] <ubot4> Launchpad bug 481840 in evolution "Package should be named with a name not a word" [Undecided,Invalid] https://launchpad.net/bugs/481840
[17:25] <WeatherGod> I think I will call Evolution, "Steve" from now on
[17:27] <qense> I've found a bug in Steve!
[17:27] <qense> mailist discussions would be a lot more interesting to watch
[17:27] <WeatherGod> "Gotta get Steve to send out the notice"
[17:34] <hggdh> I am confused. The moment 'evolution' got to be used as a package name it got to be a name.
[17:35] <WeatherGod> well, I took it to mean that the person wanted descriptive names
[17:35] <WeatherGod> kinda like OpenOffice Writer
[17:35] <hggdh> 'evolution is an important word'
[17:36] <WeatherGod> now I can't get the Beatles out of my head
[17:37] <hggdh> actually, I liked the answer. On this case I am unsure I would be able to be as nice
[17:37] <nigel_nb> bug 482189, is reproducible when I install etckeeper
[17:37] <ubot4> Launchpad bug 482189 in bzr "wrong permissions of .bazaar" [Undecided,New] https://launchpad.net/bugs/482189
[17:37] <nigel_nb> but I think normal bzr usage can be continued though
[17:38] <WeatherGod> what package should I select for issues during boot?
[17:38] <bdmurray> it depends on the issue
[17:38] <WeatherGod> more precisely, devices not ready before mount commands start
[17:38] <hggdh> nigel_nb:  I will also install it; meanwhile, please document your findings on the bug
[17:38] <nigel_nb> should I confirm it?
[17:39] <WeatherGod> the person selected "usplash" which is obviously not right
[17:39] <hggdh> nigel_nb: yes. It sounds like etckeeper is doing the wrong thing
[17:39] <nigel_nb> hggdh: yep, its an upstream bug
[17:40] <hggdh> oh, we already have an upstream bug on that? then please add the link to it, and I will set it as triaged
[17:40] <nigel_nb> I dont think we have
[17:41] <WeatherGod> looks like bcurtiswx's drivers are still not fixed...
[17:42] <WeatherGod> bdmurray, it is bug 481836
[17:42] <ubot4> Launchpad bug 481836 in usplash "Fails to mount /home on sd-card during boot" [Undecided,New] https://launchpad.net/bugs/481836
[17:44] <nigel_nb> hggdh: got the problem
[17:45] <hggdh> I just installed, and did not get it
[17:45] <nigel_nb> hggdh: bazaar is installed for the root user...when running bzr as root, there is no problem
[17:45] <bdmurray> WeatherGod: http://www.ubuntu.com/getubuntu/releasenotes/910#Login%20screen%20presented%20before%20optional%20filesystems%20are%20mounted
[17:45] <nigel_nb> did u try running bzr status?
[17:45] <hggdh> my (already existing) ~/.bazaar did not get to be root
[17:45] <nigel_nb> ah
[17:46] <nigel_nb> then I think it does not effect you if bazaar is already installed
[17:46] <nigel_nb> I tried it on my vm, where there was no bazaar
[17:46] <WeatherGod> bdmurray, thanks!
[17:47] <hggdh> nigel_nb: yes, it does seem so. Now I am trying to find where etckeeper put the bzr config
[17:47] <nigel_nb> hggdh: lemme try purging it, installing bazaar first, and then etckeeper
[17:48] <hggdh> yes, good test
[17:53] <hggdh> nigel_nb: on my install etckeeper installed a bzr branch under /etc
[17:53] <nigel_nb> but inside your home, its not causing any problem right?
[17:54] <nigel_nb> hggdh: its supposed to create a branch under /etc
[17:54] <hggdh> there is no .bzr under my home. I *do* have a .bazaar, with my basic config
[17:54] <hggdh> which, in my case, it did
[17:54] <hggdh> ah
[17:55] <hggdh> what it is doing is creating you user bzr configuration as root under ~
[17:55] <nigel_nb> yep
[17:55] <nigel_nb> so the entire app is causing a sorta problem right?
[17:56] <nigel_nb> hggdh: I'm stilling getting that "No handlers can be found for "bzr"
[17:56] <hggdh> it is probably missing a chown on the post install, or similar
[17:57] <nigel_nb> hmm, so a confirmed bug, but mostly a packaging problem?
[17:57] <hggdh> nigel_nb: what is the content of your ~/.bazaar? pastebin it
[17:57] <hggdh> it is a bug, I *think* on packaging
[17:57] <WeatherGod> is it desired behavior for new folders to have their permission bits set to rwxr-xr-x?
[17:58] <WeatherGod> I can't remember
[17:58] <hggdh> WeatherGod: usually this depends on the umask
[17:58] <WeatherGod> see bug 481825
[17:58] <ubot4> Launchpad bug 481825 in ubuntu "Add User GUI assigns 777 to ALL users, even when not wanted" [Undecided,New] https://launchpad.net/bugs/481825
[17:59] <WeatherGod> I guess I am asking what is the default umask for Ubuntu?
[17:59] <hggdh> well
[18:00] <WeatherGod> kinda huffy, huh?
[18:00] <nigel_nb> hggdh: I only have an "ignore" file
[18:00] <hggdh> two answers: default umask is 022; the "Add User" GUI (whatever that is) may force its own view
[18:01] <hggdh> nigel_nb: ooooh, good, I *did* get an ignore owned by root
[18:02] <quinda1> I'm looking through the Needs Packaging bugs.  I've found one with no activity for ~ 9 months, where the requested package was abandoned by the developer in Jan 2008 anyway.  Should I add a comment to that effect and mark it as Invalid?   It's bug 126210
[18:02] <ubot4> Launchpad bug 126210 in ubuntu "[needs-packaging] ChatSniff" [Wishlist,Confirmed] https://launchpad.net/bugs/126210
[18:02] <nigel_nb> hggdh: so somewhere packaging screwed up huh?
[18:03] <hggdh> nigel_nb: sounds like it
[18:03] <quinda1> Back when it was confirmed the project was still active - the bug was reported in 2007.
[18:04] <nigel_nb> hggdh: I'll confirm the bug then
[18:04] <hggdh> quinda1: please document your findings in the bug. If this project is orphaned upstream (and there is no similar Debian version, or it was not taken over by some other group) then it will probably be closed INVALID/WONTFIX
[18:05] <quinda1> OK, thanks!
[18:05] <hggdh> quinda1: welcome, and thank you for helping
[18:06] <WeatherGod> hggdh, just had to read up on umask... I don't think the guy really understood what he was talking about
[18:07] <hggdh> WeatherGod: there are different views on what umask should be by default. On my personal laptop, it is set as 022 (and I have no problems with that)
[18:07] <hggdh> but on my servers, it is usually 077
[18:07] <WeatherGod> hmm, on Fedora 11, it is 002
[18:07] <hggdh> even more open...
[18:08] <WeatherGod> of course... we practice what we preach!
[18:08] <hggdh> yeah, until security trumps over ;-)
[18:08] <hggdh> brb
[18:14] <nigel_nb> hggdh: just read an interesting article, which says that is how etckeeper is supposed to behave http://daniel.hahler.de/track_changes_to_etc_configuration_files
[18:16] <micahg> etckeeper rocks
[18:16] <WeatherGod> !info etckeeper
[18:16] <ubot4> WeatherGod: etckeeper (source: etckeeper): store /etc in git, mercurial, bzr or darcs. In component universe, is optional. Version 0.38ubuntu1 (karmic), package size 29 kB, installed size 372 kB
[18:17] <WeatherGod> oh, sweet!
[18:17] <WeatherGod> I so need that for my servers
[18:17] <WeatherGod> does it support svn?
[18:17] <micahg> WeatherGod: it's made to keep a local repo
[18:17] <micahg> svn is centralized
[18:17] <WeatherGod> but, you can keep a local repo
[18:18] <micahg> in svn?  no, you need a server
[18:19] <WeatherGod> right... there is a daemon running to receive my URLs
[18:19] <WeatherGod> so, ok, I see the difference
[18:19] <WeatherGod> haven't used git yet
[18:21] <WeatherGod> I have a bluetooth mouse bug report, should that go against xserver-xorg-input-mouse, or bluez?
[18:22] <micahg> depends on the error
[18:22] <WeatherGod> stops responding if the computer goes idle
[18:22] <micahg> probably bluez
[18:23] <WeatherGod> ok
[18:24] <nigel_nb> micahg: etckeeper isn't that great if u want to use bzr at the same time
[18:24] <micahg> nigel_nb: etckeeper uses bzr by default in ubuntu
[18:25] <nigel_nb> micahg: no, I meant, if u want to use bzr for working with launchpad too, etckeeper gives problems
[18:25] <nigel_nb> just tried it out... it does
[18:25] <micahg> nigel_nb: no it doesn't
[18:25] <micahg> you have a bug then :)
[18:25] <WeatherGod> micahg, actually, looking at his XsessionErrors.txt file, I wonder if something else is the problem
[18:25] <micahg> I use it fine with my laptop and server and interact with LP
[18:26] <nigel_nb> huh
[18:26] <WeatherGod> bug 481824
[18:26] <ubot4> Launchpad bug 481824 in bluez "Bluetooth mouse stops working if computer is idle for too long" [Undecided,New] https://launchpad.net/bugs/481824
[18:26] <nigel_nb> i just installed it on my vm machine and it gave me the same error as him
[18:26] <micahg> nigel_nb: bug #?
[18:26] <nigel_nb> bug 482189
[18:26] <ubot4> Launchpad bug 482189 in bzr "wrong permissions of .bazaar" [Undecided,New] https://launchpad.net/bugs/482189
[18:28] <micahg> nigel_nb: a bug :)
[18:28] <nigel_nb> micahg: ;)
[18:28] <nigel_nb> micahg: but I suspect in packaging
[18:28] <micahg> yeah
[18:28] <micahg> etckeeper runs as root
[18:29] <micahg> shouldn't use the user's home dir
[18:29] <micahg> but I"m not sure if the bug should be in etckeeper or bzr
[18:30] <micahg> WeatherGod: idk
[18:31] <nigel_nb> definitely not bzr,
[18:31] <nigel_nb> its how etckeeper implements bzr
[18:31] <WeatherGod> ok, I'll leave it in bluez
[18:48] <nigel_nb> isn't bug 407405 a wishlist?
[18:48] <ubot4> Launchpad bug 407405 in network-manager-applet "nm-applet does not offer to restart NetworkManager if it crashed" [Undecided,New] https://launchpad.net/bugs/407405
[18:51] <hggdh> it is an etckeeper bug
[18:51] <mr_steve> nigel_nb, that's a papercuts bug isn't it? I think I looked at it earlier
[18:51] <nigel_nb> mr_steve: yes
[18:52] <mr_steve> makes sense as wishlist to me. I'm still learning the ropes though.
[18:54] <nigel_nb> hggdh: there was an earlier bug about same issue with etckeeper
[18:54] <nigel_nb> marked it as dup
[18:56] <hggdh> good call, nigel_nb
[18:57] <nigel_nb> hggdh: I was actually hunting for an upstream bug tracker
[18:57] <nigel_nb> and ended back to launchpad ;)
[18:57] <hggdh> I was wondering about it... keeping etckeeper's bzr config under the home dir has optential impacts on other (user-level) usages of bzr
[18:57] <nigel_nb> yep, thats what we witnessed
[18:58] <nigel_nb> it works, but u get funny messages
[18:59] <dacone> hggdh i filed a new LP that can be found searching for dvgrab in case you want to follow this subject. thanks for your help
[18:59] <hggdh> dacone: welcome
[18:59] <nigel_nb> hggdh: papercut bugs are wishlist?
[19:00] <hggdh> WeatherGod: re. bug 481825 -- I am unsure this would be on base-files. We have to find out what "add user GUI" is this the reporter is talking about
[19:00] <ubot4> Launchpad bug 481825 in base-files "Default umask is 777 for ALL users, even when not wanted" [Undecided,Incomplete] https://launchpad.net/bugs/481825
[19:02] <WeatherGod> I am assuming it has to do with the gnome's add user gui
[19:03] <WeatherGod> also, I didn't move it to base-files, the people for gnome-system-tools did
[19:03] <WeatherGod> although, I thought that it was a bit hastey
[19:06] <hggdh> MIlan knows what he is talking about...
[19:07] <hggdh> also, the description of the bug is sort of flakey: the default permissions (i.e., umask) look more like 022 than 000
[19:08] <WeatherGod> I kinda figured that... either he was quick because he didn't want to deal with it or he actually knows
[19:08] <hggdh> (there is no write permission set for either group or others)
[19:08] <hggdh> he knows ;-)
[19:08] <WeatherGod> that's what I though
[19:08] <hggdh> he is the maintainer of g-s-t on b.g.o
[19:08] <WeatherGod> bgo?
[19:08] <hggdh> bugs.gnome.org
[19:09] <WeatherGod> ah
[19:09] <WeatherGod> well, that would make him something of an authority, huh?
[19:13] <bcurtiswx> no they aren't fixed... darn things
[19:18] <nigel_nb> about bug 466321
[19:18] <ubot4> Launchpad bug 466321 in software-center "After Ubuntu installation, nothing in universe is installable until package list is updated" [High,Confirmed] https://launchpad.net/bugs/466321
[19:18] <WeatherGod> oh?
[19:18] <nigel_nb> well... to a new user, it would seem very daunting
[19:18] <nigel_nb> saw your comments WeatherGod
[19:18] <WeatherGod> yes
[19:19] <WeatherGod> I am wondering if this got past testing because the testers are used to using Synaptics
[19:19] <nigel_nb> it might not, coz they update daily
[19:19] <nigel_nb> this is noticeable only on clean installs
[19:19] <nigel_nb> and for 24 hours
[19:20] <WeatherGod> I came across some similar reports where the users continued to claim that it wouldn't work
[19:20] <WeatherGod> which is why I asked my question
[19:21] <nigel_nb> it should be addressed anyhow
[19:21] <WeatherGod> yes, what is the cause of it?
[19:21] <nigel_nb> when i faced it and asked in support channels, they asked me to use add/remove
[19:21] <nigel_nb> the cause is that the cache update is not running on launch
[19:22] <WeatherGod> so, it isn't software-center in particular?
[19:22] <nigel_nb> unlike in add/remove
[19:22] <WeatherGod> sorry, of course it is software-center...
[19:23] <WeatherGod> you meant the launch of software-center
[19:23] <WeatherGod> duh
[19:24] <bossekr> need help with<EMAIL_ADDRESS>send this message http://pastie.org/697692 and waiting for respond or any change of the affected bugs
[19:24] <bossekr> how long will it place until launchpad process my email ?
[19:24] <WeatherGod> the problem with bugs like these is that people installing from a image still will have this problem unless the images are redone
[19:25] <hggdh> bossekr: first question, are you a member of bugcontrol?
[19:25] <hggdh> bug 419700
[19:25] <ubot4> Launchpad bug 419700 in bugzilla "package bugzilla3 <IP_ADDRESS>-1 failed to install/upgrade: ?????????? post-installation script ????????? ??? ?????? 1" [Undecided,New] https://launchpad.net/bugs/419700
[19:26] <hggdh> bug 463215
[19:26] <ubot4> Launchpad bug 463215 in bugzilla "Bugzilla3 crashes out when it is end of installation" [Undecided,New] https://launchpad.net/bugs/463215
[19:27] <bossekr> hggdh, I do not know but thing not, because regestered at lauchpad as users is not enought to be bugcontrol member, is it ?
[19:28] <bossekr> ubot4, is this my email ?
[19:28] <ubot4> bossekr: Error: I am only a bot, please don't think I'm intelligent :)
[19:28] <hggdh> bossekr: no, it is not. You cannot set Importance and status=triaged unless you are a bug-controller
[19:28] <hggdh> bossekr: also, an "in-progress" requires an assignee
[19:29] <bossekr> hggdh, I'm the debian maintainer of this package and would like to change the status for ubuntu
[19:29] <hggdh> bossekr: I thought you were the DD ;-)
[19:29] <bossekr> hggdh, hmm I hoped the assignee is set to my if the email address match
[19:30] <bossekr> hggdh, DD?
[19:30] <bossekr> hggdh, debien developer ?
[19:30] <hggdh> bossekr: PVT, if you do not mind?
[19:30] <bossekr> hggdh, how to contine here ?
[19:32] <mr_steve> Am I insane, or should bug #482245 be Invalid now that the OR solved it? He's fiddled with the status a few times.
[19:32] <ubot4> Launchpad bug 482245 in rhythmbox "Rhythmbox runs automatically by starting X session" [Undecided,Fix released] https://launchpad.net/bugs/482245
[19:35] <WeatherGod> I would mark it as invalid
[19:35] <WeatherGod> pedro originally invalidated it anyway
[19:36] <WeatherGod> the OR is the one who messed around with it
[19:37] <mr_steve> That's what I thought, i just had to double check, since I'm pretty new and have been awake for 30 hours or so..
[19:38] <hggdh> yes, it certainly should not be fix released
[19:38] <hggdh> user error
[19:39] <mr_steve> Well I've set it back to invalid, if he changes it I suppose I'll come up with a polite "please stop doing that"
[19:40] <hggdh> and explain why it is invalid instead of fix released
[19:40] <WeatherGod> maybe he didn't like be called an "Invalid"...
[19:41] <hggdh> with a link to https://wiki.ubuntu.com/Bugs/Status
[19:49] <WeatherGod> can anyone confirm bug 482286?
[19:49] <ubot4> Launchpad bug 482286 in openoffice.org "OpenOffice Writer crashes when moving mouse over menu bars" [Undecided,New] https://launchpad.net/bugs/482286
[19:49] <WeatherGod> sounds like a serious one, but I don't have my Karmic install available
[19:59] <etali> WeatherGod: Just tried that OO Writer bug, not happening here (updated this morning too, so should be running the same version as they are).
[20:00] <WeatherGod> ok, thanks... I'll ask him to reboot and double-check to see if he is completely updated
[20:00] <WeatherGod> maybe something happened with the java updates
[20:55] <WeatherGod> !info metacity
[20:55] <ubot4> WeatherGod: metacity (source: metacity): A lightweight GTK2 based Window Manager. In component main, is optional. Version 1:2.28.0-0ubuntu1 (karmic), package size 260 kB, installed size 704 kB


[02:02] <vivus> Hello all.
[02:03] <vivus> Are snaps basically LXC containers running different applications?
[03:46] <xnox> vivus, and so much more. some of the underlying security and confinment technology is similar, but that's only the basic building blocks. Cause there is a lot of mediation and support around installing/updating/upgrading snaps, allowing/disallowing snaps to do things on the host OS, and to/with other snaps to connect to each other. and the core systems, ship everything as the snap including bootloaders and kernel.
[03:47] <xnox> vivus, and that's definately so much more than just "containers" and "applications"
[03:47] <vivus> xnox: so how do I make my snap-installed IDE see my development environment such that I get code auto-complete, etc. ?
[03:49] <xnox> vivus, usually i would expect it to connect with a home plug to access user's home.
[03:49] <xnox> vivus, are you creating the IDE snap? or are you just using some IDE snap created by somebody else?
[03:49] <vivus> xnox: so I still need to install lots of dependencies on the main system then?
[03:49] <xnox> no, none.
[03:49] <xnox> well depends what you build.
[03:50] <vivus> its mostly hypothetical at this stage. Im seeing if I should switch from LXC to snaps
[03:50] <xnox> vivus, play around with examples to understand what snaps are. they are more like android/iphone apps then chroots/containers/vms.
[03:51] <xnox> since the snap app itself is read-only typically, but can have data in strict ways on the host system.
[03:51] <xnox> so e.g. there is golang provided as a snap, which gives one compiler.
[03:51] <vivus> xnox: by lots of dependencies I mean dev-environment deps. For example, let's say I install PyCharm. Now I want to use PyCharm with autocomplete for my Python environments. Where do I install the Python environment stuff?
[03:52] <xnox> typically in a pyenv in like ~/code
[03:52] <vivus> is the pyenv a snap also?
[03:52] <xnox> no
[03:52] <vivus> so that's on the host?
[03:52] <xnox> yeah... cause you'd need it read-write, don't you?
[03:53] <vivus> that seems like going a bit backwards for me then. all my dev stuff are isolated in LXC containers, because of the bloat they create on the host.
[03:53] <vivus> can i attach and modify a snap container?
[03:54] <xnox> right but pycharm itself could be a snap. and all of its dependencies would be inside the snap and do not leak on the host at all.
[03:54] <xnox> and you can have multiple things co-installed which use same deps, but different versions, without any conflicts on the host.
[03:54] <vivus> yeah but say I want to install a python package that has lots of system dependencies, like Pillow, then my host would still accumulate system-deps just for Pillow
[03:55] <xnox> this is generic development stuff. you would not be installing those as snaps typically, no. you would use some form of confinement.
[03:55] <xnox> but you would not need to install it on the host into /usr
[03:56] <xnox> vivus, and e.g. Pillow -> i'd be installing that in a virtual env, in project directory in a reproducible way. https://docs.python.org/3/tutorial/venv.html
[03:57] <xnox> cause with python, one typically creates a virtual-env which contains this project dependencies only, and develops / runs / tests code there.
[03:57] <vivus> xnox: yeah, but Pillow and some other Py packages will sometimes need system-deps to compile
[03:57] <xnox> true
[03:58] <vivus> now say you have to do this for Python, and then maybe Node too. Creates lots of bloat
[03:58] <vivus> The other day I had to install mono and I used isolation to specifically avoid the bloat
[03:58] <xnox> maybe you want to look at snapcraft
[03:59] <vivus> *on the host
[03:59] <xnox> that's tooling to build snaps, with isolation, which has a lot of tooling to use lxd containers to build all the layers/dependenices of your app, including your app, and bundle everything as a snap.
[03:59] <vivus> Perhaps I can create the snaps myself. but they are immutable right? I cannot `sudo lxc-attach -n snapcontainer` right?
[04:00] <xnox> but that's mostly for "from scratch build & deploy" scenario. not meant for interactive coding/iterations.
[04:00] <xnox> vivus, snap filesystem structure, is a bind-mounted squashfs -> so no, attaching into its mountspace will not gain you much.
[04:00] <xnox> and paths and prefixes may look odd to you
[04:01] <xnox> vivus, what's your actual problem and why did you start looking at snaps? =)
[04:02] <xnox> vivus, are lxd containers not working out for you? (i find $ lxc launch ubuntu:cosmic etc so much nicer than old lxc-* commands)
[04:02] <xnox> vivus, have you used lxd already?
[04:08] <vivus> xnox: ill reply in 5. just afk
[04:14] <vivus> xnox: the distro I use doesn't have first-class support for LXD, but I've been using LXC for a few years now, so that's not the pain-point. I was hoping I'd get to use some type of containerized desktop IDEs that can help me do code auto-complete, etc.
[04:15] <vivus> right now what I use is Vim
[04:15] <vivus> and I kind of prefer mouse interaction at times
[04:19] <Doctor_Nick> if anyone could help me out with this in this post, i would greatly appreciate it, I need to kick this out the door soon: https://forum.snapcraft.io/t/getting-a-part-build-artifact-into-another-parts-build-before-pull/7082
[05:04] <mborzecki> morning
[05:40] <zyga> o/
[05:40] <zyga> good morning
[05:44] <mvo> hey zyga
[05:44] <zyga> hey, how are you doing?
[05:48] <mvo> zyga: doing well, thank you
[05:48] <mvo> zyga: how are you?
[05:52] <mborzecki> zyga: mvo: hey
[05:58] <mvo> mborzecki: hey hey
[06:22] <mborzecki> zyga: pushed the changes to https://github.com/snapcore/snapd/pull/5713
[06:23] <zyga> looking
[06:24] <zyga> there is a conflict with your other patch in master now
[06:24] <mborzecki> zyga: i'm really bad at naming things, feel free to suggest something different than ExpandSnapMountVariables()
[06:24] <zyga> ExpandSnapVariables(perspectiveHost,perspectiveSnap) # maybe?
[06:24] <zyga> that is maybe a flag rather than a new function
[06:25] <zyga> because then anyone using it must face the fact that perspective matters
[06:25] <zyga> but I didn't read all so just quick reaction
[06:25] <mborzecki> idk, i'm open for alternatives
[06:26] <zyga> let's use the word perspective for that across the tree
[06:26] <zyga> though not sure if it is sufficient:
[06:27] <zyga> there's the outside perspective (host perspective?)
[06:27] <zyga> there is the inside perspective for strictly and devmode confined snaps
[06:27] <zyga> (perhaps for classic snaps the inside perspective should just error or be the same as outside perspective)
[06:27] <zyga> mvo: btw: did we decide to do something about "snap install classic"
[06:27] <zyga> mvo: I had some ideas on that
[06:28] <zyga> mborzecki: but then there's the inside perspective of instance snaps, what should is say for $SNAP - /snap/foo/42 or /snap/foo_bar/42
[06:28] <mborzecki> zyga: hm that sounds good
[06:28] <zyga> mborzecki: if the instance aware path is rare we could do ExpandSnapVariables(innerPerspective | instanceAware)
[06:28] <mvo> zyga: snap install classic is on my todo
[06:29] <zyga> mborzecki: but normally just pass innerPerspective
[06:29] <mvo> zyga: funny enough it will work, it will just be the wrong classic
[06:29] <zyga> mborzecki: from what I guess there's just three places that need to be instanceAware
[06:29] <mborzecki> zyga: and it has an upside that i could push this as a pr outside of 5713
[06:29] <mvo> zyga: it will pull in "core"
[06:29] <zyga> mvo: right :)
[06:29] <zyga> mvo: remember that on core18 all the snaps use pivot_root
[06:29] <zyga> so yeah :)
[06:33] <mborzecki> zyga: naming aside, please take a look at the rest of the changes and the spread test and i'll start looking into this change with perspective flag
[06:36] <zyga> I
[06:36] <zyga> OK
[06:50] <zyga> the instance layout test is very nice
[06:56] <mborzecki> zyga: do you think i could add something to the content interface test?
[06:56] <zyga> reading it now
[06:58] <abeato> mvo, hey, would it be possible to make sure https://forum.snapcraft.io/t/pulling-network-online-target-as-prerequisite-target-slows-down-starting-services/6063 does not happen on UC18?
[07:00] <mborzecki> zyga: omg, found some bad merge
[07:01] <mvo> abeato: indeed, sorry, it is still on my TODO let me move it up
[07:01] <zyga> mmm? where?
[07:01] <mvo> mborzecki: yeah, tell us more
[07:01] <mborzecki> mvo: my code :) no worries
[07:01] <mvo> puhhh :)
[07:01] <abeato> mvo, awesome, thanks a lot
[07:01] <mborzecki> zyga: in info.go, ExpandSnapMountVariables, around SNAP_DATA
[07:02] <zyga> I'm not there yet
[07:02] <mborzecki> hm wonder why it was picked up by vet on travis, but not locally, iirc go test is supposed to run vet now too?
[07:04] <zyga> is it? I was never using go vet automatically, it's always manual
[07:06] <mborzecki> zyga: https://golang.org/doc/go1.10#test-vet
[07:06] <zyga> ah,go 1.10!
[07:07] <zyga> so I was using it without being aware of it
[07:07] <mborzecki> they mention high confidence checks though, idk how unreachable code is not among those
[07:08] <zyga> I'd love unused code detector
[07:08] <mborzecki> zyga: try gometalinter
[07:08] <zyga> e.g. public functions that are not used
[07:08] <mborzecki> there's deadcode checker
[07:09] <zyga> yeah but $standard vs $toolbox
[07:09] <zyga> I agree I'm just lamenting it is not a standard issue feature
[07:10] <mborzecki> btw. deadcode actually picks up some stuff in the project, just didn't open any PRs yet
[07:14] <pstolowski> morning
[07:15] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/5713/files#r213925025
[07:15] <zyga> the path discussion summarized
[07:15] <zyga> hey pawel
[07:15] <mvo> hey pstolowski
[07:15] <mborzecki> pstolowski: cześć
[07:19] <mborzecki> zyga: wonder if that's a bit too many flags
[07:19] <zyga> mborzecki: four?
[07:19] <zyga> really we need the two flags for perspective + one flag that "flips" the natural instance awareness
[07:19] <zyga> so three
[07:20] <zyga> but the reality is that I think we just need it
[07:25] <mborzecki> zyga: i'm taking yagni angle here, all the use cases are inside mount ns now https://paste.ubuntu.com/p/RZF98hg8hd/
[07:26] <zyga> snapshots need the outside path
[07:26] <zyga> inside you need both the instance and non-instance paths
[07:26] <zyga> (or we can just craft the instance paths with instance key manually
[07:26] <zyga> +1 on yagni though, if you can get it to work
[07:26] <zyga> we can add the override flag if needed
[07:28] <mborzecki> zyga: i'd expect snapshots to use snap.Info methods, those do instance-specific paths
[07:28] <zyga> interesting
[07:28] <zyga> yeah
[07:30] <mborzecki> zyga: to recap, the snap.Info.SomeSuchDir() return all instance path, then the package level helpers snap.MountDir() et al take a snapName, so you can do snap.MountDir(info.SnapName(), info.Revision)
[08:10] <mborzecki> zyga: hm need to update that symlink path in layouts test
[08:10] <zyga> ah, right
[08:10] <zyga> +1
[08:15] <mborzecki> zyga: actually something broke there with /etc/demo, i'm looking into this right now, will ping you if i need a hand
[08:15] <zyga> ok
[08:15] <zyga> what was the error?
[08:16] <mborzecki> /etc/demo/writable is not created in $SNAP_COMMON for some reason
[08:16] <mborzecki> zyga: the fstab looks ok to me https://paste.ubuntu.com/p/wMw8hrWZmq/
[08:17] <zyga> mmm
[08:17] <zyga> ok
[08:18] <mborzecki> zyga: i can see /etc/demo/writable inside snap mount ns, but it's not in $SNAP_COMMON/etc/demo for some reason (and not in /var/snap/test-snapd-layout_foo/common either)
[08:18] <zyga> is it because /etc is the real /etc and it is writable and then you don't get a private-namespace copy?
[08:18] <zyga> aka, trespassing bug
[08:19] <zyga> maybe we can revive my branch for that
[08:19] <mborzecki> zyga: mountinfo inside, https://paste.ubuntu.com/p/FXrp8Cmymc/
[08:19] <mborzecki> zyga: hm it worked before fwiw
[08:20] <zyga> 894 737 8:1 /var/snap/test-snapd-layout/common/etc/demo /etc/demo rw,relatime master:1 - ext4 /dev/sda1 rw,data=ordered
[08:20] <zyga> so /etc/demo is /var/snap/test-snapd-layout/common/etc/demo
[08:22] <zyga> anyway, I'll revive it
[08:22] <zyga> I need to land htat
[08:23] <mborzecki> zyga: hmm https://paste.ubuntu.com/p/3MXW6fz5RC/ what if it's not? :)
[08:24] <zyga> and on the host :D
[08:24] <zyga> because this really tells you what happens
[08:24] <zyga> ext4 filesystem on /dev/sds1, the slice at /var/snap/test-snapd-layout/common/etc/demo is at /etc/demo
[08:25] <zyga> 977 764 8:1 /var/snap/test-snapd-layout_foo /var/snap/test-snapd-layout rw,relatime master:1 - ext4 /dev/sda1 rw,data=ordered
[08:25] <zyga> this hides it from your namespace (it's later in the sequence)
[08:25] <zyga> (sequence matters)
[08:25] <zyga> but just check on the host
[08:25] <zyga> am I right?
[08:27] <mborzecki> hm on the host, /etc/demo is there, /var/snap/test-snapd-layout_foo/common/etc/demo/writable is not, but /var/snap/test-snapd-layout/common/etc/demo/writable is and contains what was written by the _foo instance :/
[08:27] <mborzecki> zyga: ^^
[08:27] <zyga> right
[08:27] <zyga> that's what I expected
[08:27] <zyga> I mean, mountinfo doesn't lie
[08:27] <zyga> it's just non-obvious what the outcome is
[08:29] <mborzecki> zyga: heh, ok, i'll just leave a comment in the test that this part blows up too
[08:39] <zyga> mborzecki: I'm looking at my trespassing fix onw
[08:39] <zyga> the part I got stuck on is something you could help me with
[08:39] <zyga> if you want we can HO today and I'll walk you through it
[08:39] <zyga> maybe the solution will become obvious as we d oit
[08:39] <MattJ> Is there a way I could grant a snap read-only access to /etc/ssl without going all the way and changing it to a classic one? Is there an interface I'm missing? If not, is there a potential for one to be added?
[08:40] <zyga> MattJ: let me look
[08:40] <mborzecki> zyga: ok, sure
[08:41] <zyga> so
[08:41] <zyga> MattJ: the network interface does that
[08:42] <zyga> but you need to know that /etc/ssl is not from the host
[08:42] <zyga> it is the one from the base snap of your app
[08:42] <zyga> so you cannot add ssl certs by adding them to your host
[08:43] <MattJ> Ah, ok :/
[08:44] <MattJ> Thanks - do you see any easy way around this or should I give up and switch to classic confinement?
[08:44] <zyga> it depends on what you want to do
[08:44] <zyga> you can add ssl certs from your snap to your snap's runtime
[08:44] <zyga> that is
[08:44] <MattJ> Another thing I thought was if I could just run one command without confinement to import the certs to the data path or something
[08:44] <zyga> any given snap can add certs for itself
[08:45] <MattJ> Well it's a server process, but it needs valid certificates for the domain it is serving
[08:45] <MattJ> Most people these days will already have these via Let's Encrypt/etc.
[08:45] <zyga> mmm
[08:45] <zyga> where do you need that cert to be exactly?
[08:46] <MattJ> I need it anywhere that can be read by the server process launched in the snap
[08:46] <zyga> copy it to $SNAP_COMMON
[08:46] <zyga> and have your snap read it from there
[08:46] <MattJ> I guess I could provide a script in the snap that does this, and the user could execute it manually
[08:48] <MattJ> Thanks for the thoughts :)
[08:50] <Chipaca> MattJ: a script can detect if it's being run or being sourced, and error if it's being run, with an error along the lines of 'you need to source this'
[08:51] <Chipaca> MattJ: in bash, that is: check whether ${BASH_SOURCE[0]} is $0
[08:51] <MattJ> This would probably need to be actually run as root, from cron
[08:51] <MattJ> But thanks for the tip
[08:51] <Chipaca> MattJ: systemd timers ftw
[08:53] <MattJ> Sure, though that can't be installed by the snap... but I guess it could be installed by this script, hmm :)
[08:56] <Chipaca> MattJ: OTOH you're not the only person asking us to be able to add certificates
[08:57] <MattJ> I think it's easier for web-based apps that may be the only thing on the system, they can bind to port 80 and include certbot in the snap
[08:57] <Chipaca> so maybe we need to think about a more general solution
[08:58] <Chipaca> MattJ: if your snap was installed on a core device, where /etc/ssl is readonly, what would your users do?
[08:59] <MattJ> Probably install some Let's Encrypt/certbot snap
[09:00] <MattJ> (I would like the snap to work on a core device for sure, so I would also like a solution for that - but I haven't got that far yet)
[09:01] <Chipaca> MattJ: so from your POV getting the cert is never your snap's concern, it always needs to come from outside
[09:02] <Chipaca> MattJ: why would the copying need to be put on a timer? because presumably the certs get updated periodically in some other place and the whole tree needs to be in sync?
[09:03] <t1mp> should the app version number always be "hard-coded" in the snapcraft.yaml file?
[09:03] <t1mp> I'd like to get it from my_python_package.__version__ instead
[09:04] <mborzecki> zyga: i'm looking at the log from test-snapd-layout_foo, https://paste.ubuntu.com/p/j5WSWJtyJH/ if the mount changes are pefroemd in the order they are logged in line 178 then this will be incorrect, won't it?
[09:04] <mborzecki> zyga: i mean i see it's doing all the layout stuff before parallel instance setup, although fstab lists parallel instance pieces first
[09:05] <zyga> hmmm
[09:05] <mborzecki> zyga: before it worked because layouts used instance-specific paths and the instance -> snap bind mount would not confclit
[09:05]  * zyga looks
[09:06] <zyga> aha
[09:06] <zyga> interesting
[09:06] <zyga> hmmm
[09:06] <zyga> right
[09:06] <zyga> we sort them in a specific way
[09:07]  * zyga thinks
[09:07] <mborzecki> hm parallel-instance then should come first?
[09:07] <Chipaca> t1mp: you can tell snapcraft to grab the version from elsewhere
[09:07] <zyga> lines 162-190 of the log
[09:07] <zyga> not sure if that's correct
[09:07] <mborzecki> zyga: we have x-snapd-origin we could use
[09:07] <MattJ> Chipaca, Let's Encrypt certificates are only valid for 3 months, and are typically updated more often than that
[09:07] <zyga> yes but it's super super tricky what happens
[09:07]  * mborzecki looking
[09:08] <zyga> the rationale for the ordering is specific
[09:08] <zyga> I was thinking if we need to do batching
[09:08] <MattJ> Chipaca, so either the snap needs constant access to them, or they need to be imported periodically by something with access to them
[09:08] <Chipaca> t1mp: look up "snapcraftctl set-version", i think that'll lead you to the how
[09:08] <mborzecki> zyga: like parallel instances first, then layouts, then the rest (if needed?)
[09:09] <zyga> perhaps
[09:09] <Chipaca> MattJ: yeah, that's what i thought
[09:09] <zyga> but it's all non-trivial
[09:09] <mborzecki> zyga: computing changes would be tricky
[09:09] <zyga> not sure if this remains correct
[09:09] <t1mp> Chipaca: thanks, reading.
[09:11] <zyga> mborzecki: what if we do a stable sort
[09:11] <zyga> and sort by (target, source)
[09:11] <zyga> not just by target
[09:11] <zyga> I think what is happening that is wrong is
[09:12] <zyga> we order things by where they appear
[09:12] <mborzecki> zyga:  i can try that
[09:12] <zyga> ignoring the what they bring aspect
[09:12] <zyga> and what they bring is also relevant
[09:12] <zyga> we need to correctly order the desired state
[09:12] <zyga> but then the question becomes;
[09:12] <zyga> is this breaking any invariants the current code has
[09:13] <zyga> will it undo correctly
[09:13] <mborzecki> zyga: i'll do some experimentation and we can later meet in HO
[09:15] <mborzecki> zyga: heh, finny that it worked before by accident :)
[09:15] <mborzecki> and i was like, 'oh hey it works, so nice' ;)
[09:19] <zyga> mborzecki: I need to go to the post office
[09:19] <zyga> mborzecki: we can HO after that
[09:19] <zyga> ok?
[09:19] <mborzecki> sure
[09:19] <zyga> brb
[09:21] <mborzecki> niemeyer: hi, when you're around could you take a look at https://github.com/snapcore/snapd/pull/5735 ?
[09:22] <niemeyer> mborzecki: Looking
[09:23] <mborzecki> niemeyer: thanks
[09:29] <niemeyer> mborzecki: Reviewed, np
[09:34] <Chipaca> t1mp: this: https://forum.snapcraft.io/t/extracting-information-from-sources-in-snapcraft-parts/4642
[09:42] <t1mp> Chipaca: thanks.
[09:42] <t1mp> I see there is also a version-script property in the yaml file, but not a lot of docs on that yet.
[09:45] <zyga> re
[09:47] <mborzecki> zyga: i'm playing with this naiive change https://paste.ubuntu.com/p/K54npKZzFg/
[09:49] <zyga> sure but think about the consequences as well
[09:50] <mvo> zyga: do you think 5307 needs another look by jamie ? or can we squash it?
[09:50] <mborzecki> zyga: just verifying that moving those mounts to be firs fixes the issue at hand
[09:58] <zyga> mvo: looking
[09:59] <zyga> mvo: ideally jamie would look but he's been busy
[09:59] <zyga> also gustavo asked for +1 from jamie
[10:10] <mborzecki> zyga: the tests are passing now (expectedly)
[10:18] <t1mp> Chipaca: version-script looks like it will do what I want, but still the 'version' property is required. I assume that version-script will override that (but it is not documented what will happen). I guess I'll have to try it
[10:18] <niemeyer> WOAH
[10:18] <niemeyer> There's no a "Resolve conversation" button in GH..
[10:18] <niemeyer> So simple and so useful
[10:19] <pstolowski> pedronis: hey, wrt your comment about revert & Sequence after currentIndex, what're the semantics of Sequence?
[10:19] <niemeyer> And "Show resolved" and "Hide resolved".. OMG.. my day just got better
[10:21] <Chipaca> niemeyer: nice
[10:22] <niemeyer> https://usercontent.irccloud-cdn.com/file/uMovdf2m/image.png
[10:24] <mvo> xnox: that reminds me, can I do an sru for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936 or do you plan to do one anyway where you could include this change?
[10:29] <ogra> mvo, hmm, you said SNAP_ARCH_TRIPLET was not implemented ... this one is very curious though ... :
[10:29] <ogra> $ snap run --shell qemu-virgil -c "/usr/bin/env"|grep SNAPCRAFT
[10:29] <ogra> SNAPCRAFT_ARCH_TRIPLET=x86_64-linux-gnu
[10:29] <ogra> seems the snapcraft var is actually inside the installed snap
[10:29] <ogra> (whihc is great but smells like it should not be like that)
[10:31] <mvo> ogra: I did not follow what snapcraft was doing there
[10:31] <ogra> mvo, well, somehow SNAPCRAFT_ARCH_TRIPLET ends up in my runtime env
[10:32] <ogra> that snap has no wrappers or anything so this is very curious
[10:33] <ogra> i mean, i appreciate that ... but it doesnt feel right that a SNAPCRAFT var ends up in my installed snap package
[10:34] <ogra> $ grep SNAPCRAFT /snap/qemu-virgil/current/command-qemu-virgil.wrapper
[10:34] <ogra> $
[10:34] <ogra> it is definitely not in the default wrapper
[10:34] <ogra> so i wonder where it comes from
[10:34] <ogra> gar
[10:35] <ogra> ignore that ... somthing exported it into the shell i'm in
[10:35] <ogra> (which is also curious ... should snap run --shell not wipe my env ? )
[10:42] <Chipaca> ogra: nope, only remove some of it
[10:51] <ogra> ah
[10:53] <mborzecki> pstolowski: left you some comments on #5680
[10:54] <pstolowski> mborzecki: ty!
[11:37] <zyga> hmm, if a test panics the panic breaks the test
[11:37] <zyga> but if a test panics and teardown uses c.Assert() that fails then the assertion error is show but the panic is gone
[11:38] <zyga> is this expected?
[11:58] <Chipaca> grr grr grr integration tests grr
[11:58]  * Chipaca ~> lunch
[12:11] <zyga> mborzecki: hey
[12:11] <zyga> do you want to HO?
[12:11] <mborzecki> sec
[12:11] <zyga> I'm progressing on the trespassing fix, I rebased it and solved a blocker I had the last time
[12:11] <zyga> now going through tests that ... well, need some love since syscalls changed
[12:12] <zyga> but it's mostly inserting a syscall in a chain and going on
[12:12] <mborzecki> zyga: ok, ready
[12:12] <zyga> standup?
[12:37] <pedronis> mvo: can #5583 be reviewed again?  I might not get to it today tough
[12:46] <ogra> hmm, an install hook should also run on upgrades, right ?
[12:47] <mvo> pedronis: yes, I updated it ~1h ago
[12:48] <pedronis> ok
[12:48] <mvo> pedronis: it has a minimal wait and tracks the idle connections now
[12:48] <mvo> s/tracks/checks/
[12:49] <pedronis> mvo: likely I will look at it tomorrow, trying to getting started with something today (but had a bit of a cut up day by errands so far)
[12:49] <pstolowski> ogra: no
[12:49] <mvo> pedronis: no worries, its not urgent
[12:49] <pstolowski> ogra: on upgrades we run pre-refresh and post-refresh hook sinstead
[12:49] <pstolowski> *instead
[12:52] <ogra> pstolowski, hmm, so i need two scripts if i want something to work on install as well as on upgrades ?
[12:52] <ogra> hooks/install and hooks/*-refresh ?
[12:53] <zyga> jdstrand: hey, there's a pr that is blocked on you (the one about /mnt)
[12:53] <zyga> jdstrand: do you think you will have time to review it today
[12:53] <pstolowski> ogra: yes
[12:53] <jdstrand> I got through some yesterday. will try to get to that one
[12:53] <ogra> boo
[12:54] <ogra> ok
[12:54] <zyga> jdstrand: thank you!
[12:54] <pstolowski> ogra: if the logic is the same you can move it to a helper.. or maybe a symlink will work (not sure)
[12:54] <ogra> well, i#ll just cp it ...
[13:33] <zyga> I must say I love our standups
[13:33] <mborzecki> guys, any clue why i'm not able to edit https://forum.snapcraft.io/t/security-policy-and-sandboxing/554 ?
[13:34] <zyga> it's not a wiki
[13:34] <zyga> the irony there hurts ;)
[13:35] <zyga> oh boy!!
[13:36] <zyga> I used 1TB of data this month
[13:36] <zyga> and I actually hit my cap
[13:36] <zyga> wow
[13:36] <zyga> (LTE cap)
[13:36] <zyga> I need better visibility into this, who is using this data ....
[13:37] <mborzecki> nasty neighbours :)
[13:38] <mborzecki> zyga: hm i can edit this https://forum.snapcraft.io/t/the-snap-format/698 but not the other one
[14:33] <axino> hi
[14:33] <axino> I have a snap containing some rust code, it compiles fine on amd64/i386 but not on arm64/armhf
[14:34] <axino> error is "error[E0658]: non-reference pattern used to match a reference (see issue #42640)"
[14:34] <axino> has anyone seen this ?
[14:34] <axino> https://launchpad.net/~build.snapcraft.io/+snap/17fc91e19f932bd8a75175923b533019-xenial builds are here
[14:39] <Chipaca> axino: is this specific to the snap?
[14:40] <axino> Chipaca: I can't answer that
[14:41] <Chipaca> axino: why not?
[14:41] <axino> Chipaca: I haven't tried to build sentry outside of the snap context
[14:41] <axino> Chipaca: or maybe I misunderstood your question
[14:42] <Chipaca> axino: the error does not seem to be about snaps at all
[14:43] <Chipaca> axino: I'm not sure how we could help
[14:43] <axino> Chipaca: maintainers of multi-arch rust snaps might have seen this behaviour
[14:46] <axino> I guess I'll try #rust
[14:56] <Chipaca> axino: if you don't have luck there, try a topic on the forum
[14:56] <axino> Chipaca: yup I will - thanks
[15:17] <Chipaca> mup: ping
[15:17] <Chipaca> mup: how much chug would a moose chug … wait
[15:41] <popey> jdstrand: I'm getting a snap suddenly getting rejected by the store, which was fine previously
[15:41] <popey> jdstrand: https://dashboard.snapcraft.io/snaps/scummvm/revisions/466/
[15:42] <popey> "unknown keys in snap/manifest.yaml: snapcraft-os-release-id,snapcraft-os-release-version-id,snapcraft-version lint-snap-v2_snap_manifest "
[15:43] <jdstrand> popey: tools needs an update. thanks!
[15:43] <jdstrand> popey: can you request a manual review?
[15:43] <jdstrand> popey: we'll get that fixed fast
[15:43] <popey> done, thanks
[15:48]  * zyga goes for a bike for 1..2 hours
[15:48] <jdstrand> popey: can you do the same for 466 (i386)?
[15:49] <popey> jdstrand: done
[15:49] <zyga> jdstrand: I'm making good progress on the trespassing bug (it was unblocked today), I'll bug you about that tomorrow
[15:49] <jdstrand> zyga: great. fyi, I'm off tomorrow/Monday (will send email later)
[15:50] <zyga> ah
[15:50] <zyga> ok, then on Tuesday
[15:50] <zyga> can you try to look at https://github.com/snapcore/snapd/pull/5307 - you're the last +1 needed :)
[15:50] <zyga> (regardless, I'm heading out)
[15:51] <jdstrand> zyga: yes, we talked about that already today :P
[15:51] <zyga> I know, sorry :|
[15:53] <diddledan> snapd 2.35 is installing the .snap files as root:root 600 - previous snapds installed root:root 644
[15:53] <diddledan> caused an error that I've documented in the cft for snapcraft 2.43: https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-43/7024/5
[15:53] <popey> i had this the other day too
[16:00] <Chipaca> diddledan: popey: that is known and fixed on master fwiw
[16:01] <Chipaca> master of snapcraft that is
[16:01] <diddledan> how can snapcraft, running as me, decide to override root-only access?
[16:05]  * diddledan eyes it suspiciously
[16:11] <Chipaca> diddledan: say again?
[16:11] <Chipaca> diddledan: it doesn't
[16:11] <Chipaca> diddledan: it no longer tries to copy those files into the container
[16:12] <diddledan> you said it was fixed in snapcraft, but snapcraft can't override the root-only access
[16:12] <diddledan> aah
[16:12] <diddledan> gotcha
[16:12]  * diddledan removes suspicious eyes
[16:12] <Chipaca> diddledan: in the future we'll bring the caching back by adding api to snapd to stream the snaps
[16:12]  * diddledan inserts googley eyes instead
[16:12]  * Chipaca whacks diddledan over the head just watch the googley eyes bobble
[16:13]  * ogra steals diddledan's goggley eyes and replaces them with xeyes for nostalgic reasons
[16:13] <diddledan> https://www.youtube.com/watch?v=BBFqGHgCFiY
[16:13]  * popey runs wayland on diddledan  to break the xeyes
[16:13] <diddledan> haha
[16:14]  * ogra secretly shoves XWayland underneath popey's injection ... just to notice the xeyes became stills due to securit reasons
[16:14] <ogra> +y
[16:15] <Chipaca> clearly the way to have it  work again is to make diddledan be all eyes
[16:15] <jdstrand> roadmr: hi! can you pull r1123 of the review-tools. this should be considered fairly urgent since anything using a new snapcraft will end up in manual review
[16:16] <jdstrand> roadmr: ideally done today since I'm off tomorrow/Monday
[16:16] <ogra> http://www.davidmelling.co.uk/blog/wp-content/uploads/2012/05/monster5-e1337951522979-1024x602.jpg
[16:16] <jdstrand> roadmr: fyi, https://paste.ubuntu.com/p/553Jg578yF/
[16:17] <jdstrand> roadmr: (r1123 changed sr_common.py)
[16:17] <jdstrand> popey: that has your fix ^
[16:17] <popey> yay
[16:17] <popey> ta
[16:19] <Chipaca> fair warning, a lot of our argentine colleagues might be a bit distracted these days
[16:19] <ogra> we should just pay them in euros then
[16:20] <ogra> (or is there more than the crazy inflation ?)
[16:20] <Chipaca> ogra: it's the chaos and turmoil that with this
[16:21] <ogra> yeah
[16:38] <Chipaca> could I get a review or two of https://github.com/snapcore/snapd/pull/5744 ? reasonably straightforward (might even qualify as Simple)
[16:39] <Chipaca> tests are green despite what github says (at least  here)
[16:39] <sergiusens> niemeyer, kyrofa: wrt out conversation from Monday, are we good on s/templates/extensions/ ?
[16:40] <niemeyer> So far it sounds good
[16:45] <sergiusens> niemeyer: great, we will rename them
[16:52] <roadmr> jdstrand: hi! I'll put it in the pipeline
[17:10] <popey> jdstrand: i take it you've seen the review tools themselves got rejected? :)
[17:11] <popey> (also, lol)
[17:11] <roadmr> haha
[17:11] <mvo> heh
[17:17] <zyga> Returned
[17:17] <zyga> TIL police does not arrive even after 25 minutes of waiting
[17:26] <ogra> oh gosh ... thats a lot of additional apt sources in that "16.04 snap missing" thread !
[17:26] <ogra> ... what could possibly go wrong ...
[17:34] <roadmr> zyga: why did you call police? 😱
[17:54] <zyga> roadmr: some drunk assholes were harassing a young couple
[17:54] <roadmr> oh not nice :(
[18:04] <ogra> jdstrand, hmm ... i just had three weird rejects of a plain package rebuild ... " unknown keys in snap/manifest.yaml: snapcraft-os-release-id,snapcraft-os-release-version-id,snapcraft-version lint-snap-v2_snap_manifest"
[18:06] <ogra> jdstrand, https://dashboard.snapcraft.io/snaps/qemu-virgil/revisions/30/ (and 31, 32) in case you want to take a look ... it is built using build.snapcraft.io and there were no fancy changes or anything ... the former build went through for all arches
[18:08] <ogra> jdstrand, oh, ignore me, just saw the backlog ... i guess it will magically fix itself
[18:12] <Caelum> zyga: I'm getting that exact fail on my tw server with 'osc build'
[18:12] <zyga> Caelum: hey
[18:12] <zyga> Caelum: I talked to some golang people from suse
[18:13] <zyga> Caelum: apart from some issues in test suite (unicode vs ascii output) I'm re-working the use of golang helpers
[18:13] <zyga> Caelum: tl;dr; version is that people that make golang helpers recommend not to use golang helpers
[18:13] <Caelum> zyga: so you found the issue, was it a segfault or something like that?
[18:14] <Caelum> zyga: yeah figures
[18:14] <zyga> Caelum: ish, I have not confirmed it on pure i586 system
[18:14] <Caelum> zyga: the go build stuff is very weird to be honest
[18:14] <zyga> "go build" is very nice but %go_build is horrible
[18:29] <Caelum> zyga: honestly I've never yet built snapd with the regular tools, the patches I ran through osc
[18:29] <Caelum> zyga: but I'm going to try again now
[18:39] <zyga> Caelum: actually it's pretty easy, just go build :)
[18:39] <zyga> Caelum: anyway, I'm reading now, but I will push updates to my home branch
[18:42] <Caelum> zyga: looks like ./run-checks is all I really need
[18:49] <Caelum> zyga: looks like fixing things for gentoo is going to be non-trivial, already ran into a needed dependency that gentoo doesn't have
[19:14] <jdstrand> roadmr: thanks for putting it in the pipeline-- do you have an eta?
[19:16] <roadmr> jdstrand: I'll do my best to roll out today but no promises; if not, it'd be until Monday/Tuesday
[19:16] <jdstrand> roadmr: ok, thanks
[19:17] <jdstrand> roadmr: Monday/Tuesday is going to be a problem. basically, all snapcraft.io/LP builds are getting blocked
[19:18] <jdstrand> roadmr: I apologize for this. I wasn't aware of the changes
[19:19] <roadmr> :(
[19:19] <roadmr> I'll do my best to get this out today
[19:19] <popey> sorry, but +1 to getting this fixed asap. We're already getting mails about stuff failing
[19:35] <cjwatson> Do we need to revert LP's snapcraft?
[19:35] <cjwatson> (Is it a snapcraft change that caused this?  I have no idea TBH.)
[19:58] <jdstrand> cjwatson: yes, snapcraft
[19:58] <jdstrand> cjwatson: but lets hold off on the revert and see what roadmr can do
[19:59] <roadmr> jdstrand, cjwatson : if it's easyish to revert, it might be faster than what I can do :(
[19:59] <jdstrand> I don't personally have a preference, but I don't know what snapcraft is fixing
[20:00] <roadmr> jdstrand: at this point the store release pipeline involves a CI run which might take 2 hours, then requesting the rollout which, assuming someone from IS is around to process and I nag them hard enough, might take another hour. But it's already 4 PM for me so that puts me past EOD (my son is very strict in enforcing EOD)
[20:00] <roadmr> jdstrand: we put a veto on Friday releases since last Friday's broke the world :D so if not done today, that's why it would have to wait for Monday. Monday is Labor Day in some countries so coverage will be low as well
[20:00] <roadmr> (I'm off on Monday for one, and so are you :D)
[20:00] <cjwatson> roadmr: unless I'm missing a quicker way, we'd do it by building a reverted version with a higher version number and put it in the snappy-dev/ubuntu/tools PPA
[20:01] <jdstrand> cjwatson: would it be possible to revert until next Monday/Tuseday when roadmr pings us that the fix is in place?
[20:01] <cjwatson> That doesn't require (or even really benefit from) an LP person being available, which is a good thing since I'm about to walk out the door
[20:01] <cjwatson> Anyone in ~snappy-dev could do it
[20:01] <jdstrand> I'm in snappy-dev
[20:02] <cjwatson> This works because LP puts "deb http://ppa.launchpad.net/snappy-dev/tools/ubuntu %(series)s main" (with the appropriate series substituted for "%(series)s", but it's usually xenial and in particular it's xenial for all build.snapcraft.io builds) in the sources.list for every snap build
[20:02] <cjwatson> For exactly this sort of reason
[20:02] <pedronis> how did this snapcraft got throught anyway? should have it broken some store integration tests?
[20:03] <jdstrand> cjwatson: https://launchpad.net/~snappy-dev/+archive/ubuntu/tools seems to have ancient stuff...
[20:03] <cjwatson> Yes, it hasn't been actively used for a while
[20:03] <cjwatson> But it's still in sources.list
[20:03] <jdstrand> cjwatson: oh, you're saying take the last xenial from -updates and shove it there
[20:04] <jdstrand> (with proper versioning, etc)
[20:04] <cjwatson> It needs to have a higher version number than anything else in the snap build's sources.list, but yes
[20:04] <jdstrand> sure
[20:04] <cjwatson> I mean you should probably alert the snapcraft team that you're doing this
[20:04] <cjwatson> o hai
[20:04] <roadmr> once that thing is in the PPA, how does Launchpad pick it up? magic?
[20:05] <jdstrand> pedronis: that will be my next question. snapcraft should definitely have some tests that run snaps it produces through the review tools
[20:05] <sergiusens> cjwatson, roadmr: what's up?
[20:05] <cjwatson> roadmr: snap builds are dispatched to builders with a sources.list that includes that PPA
[20:05] <cjwatson> so not particularly magic
[20:05] <roadmr> cjwatson: it is magic! https://www.youtube.com/watch?v=tYh94XTJTDU
[20:06] <cjwatson> sergiusens: latest snapcraft apparently breaks the store until a new click-reviewers-tools is rolled out, which may not be until Monday depending on how things go.  we were planning to have jdstrand drop a reverted version into ppa:snappy-dev/ubuntu/tools until such time as that happens, so that e.g. BSI users don't suffer in the meantime
[20:06] <jdstrand> sergiusens: the review-tools got grumpy over some added manifest.yaml keys. I've added them (and one could argue they shouldn't do that) but atm LP/build.s.io builds are failing review
[20:06] <sergiusens> jdstrand: heh, those are the manifest keys you asked for :-) the irony :-P
[20:06] <jdstrand> sergiusens: the problem is even though they are fixed, they can't get to prod fast enough
[20:07] <jdstrand> sergiusens: indeed. I seem to be paying the price for that request
[20:07] <pedronis> something seems still broken process wise
[20:07] <jdstrand> pedronis: I mentioned that
[20:07] <sergiusens> this hassle just also proves that my calls for testing are useless
[20:07] <sergiusens> should probably just stop doing them
[20:07] <jdstrand> 15:05 < jdstrand> pedronis: that will be my next question. snapcraft should definitely have some tests that run snaps it produces through the review-tools
[20:08] <cjwatson> jdstrand: anyway, as mentioned, I'm about to go out.  all clear on what needs to be done if you do go the revert route?
[20:08] <jdstrand> that could be part of SRU, autopkgtest, travis, whatever
[20:08] <roadmr> thanks cjwatson
[20:08] <pedronis> sergiusens: this would have broken any  good enough integration test with the store, unless I'm missing something, or those don't run making a manifest
[20:08] <pedronis> so we are missing that
[20:08] <jdstrand> cjwatson: yes. you said xenial is all I need to fix?
[20:08] <cjwatson> jdstrand: I'll have my phone with me so feel free to SMS the number in the directory if you get stuck
[20:08] <sergiusens> pedronis: we use the staging store
[20:08] <sergiusens> pedronis: explicitly told not to use the prod store for any testing
[20:08] <cjwatson> jdstrand: for BSI, yes.  for other LP builds, that'll still catch nearly everything so it should be fine
[20:08] <jdstrand> cjwatson: I'll be fine. thanks for the offer
[20:09] <roadmr> sergiusens, pedronis : this should have broken even with the staging store, since the reviewer-tools that support this only landed on staging today after jdstrand brought the problem up
[20:09] <pedronis> indeed, still not understanding
[20:09] <pedronis> are we not checking enough? not testing the manifest case?
[20:10] <roadmr> I wonder if the store pre-release tests  would have caught them; but we don't run those when snapcraft changes, only when we're about to do a prod release
[20:10] <sergiusens> roadmr: it should of broken all your travis runs too fwiw, as this functionality is in since late May
[20:10] <jdstrand> cjwatson: on monday/whenever, I guess we could simply remove the packages from the ppa, then all is good cause builders are ephemeral?
[20:10] <cjwatson> jdstrand: yes
[20:10] <roadmr> sergiusens: oh! and it hasn't broken anything!
[20:10] <jdstrand> cool
[20:10]  * jdstrand updates the ppa
[20:10] <jdstrand> cjwatson: thanks
[20:10] <pedronis> roadmr: sounds either that we don't check that the test go past review tools or the tests are generating manifests
[20:10] <sergiusens> roadmr: oh, this is missing coverage about generating manifests for those tests.
[20:10] <jdstrand> cjwatson: enjoy your evening :)
[20:10] <cjwatson> I plan to.  thanks
[20:11] <jdstrand> hehe
[20:11] <cjwatson> good luck
[20:11] <roadmr> thanks!
[20:11]  * roadmr needs to step out for a bit but will read backscroll later
[20:16]  * cachio afk
[20:50] <hunterk> ok, reading the scrollback, I'm not the only person with the 'unknown keys' build failure, and that's something the snapcraft folks will sort out on their end?
[20:50] <ogra> yes
[21:04] <hunterk> kk, thanks :)
[21:06] <LargePrime> hi,  can i get a link or keyword to enable write areas in a snap?
[21:06] <LargePrime> am tryint to have a snap packager to fix his snap
[21:06] <LargePrime> please ping
[21:09] <popey> LargePrime: snaps have writable areas. $SNAP_USER_DATA and $SNAP_USER_COMMON - see https://docs.snapcraft.io/reference/env  for details
[21:09] <popey> LargePrime: which snap out of interest?
[21:09] <LargePrime> popey, https://github.com/diddlesnaps/starruler2/issues/2
[21:10] <LargePrime> star ruler 2 has lots of mods and modability.  and they seem mostly borked with current ackage
[21:11] <popey> one possibility that i don't know if diddledan has tried, is you can copy the moddable stuff out to a writable area on first launch
[21:12] <popey> I did this with one or two snaps
[21:12] <popey> can end up wasting space though
[21:12] <popey> the other option is to patch upstream to look in multiple places
[21:12] <diddledan> I've not had a change to look into it yet
[21:12] <diddledan> chance*
[21:12] <LargePrime> popey, would it be a small ask for you to reply to the issue?
[21:12] <LargePrime> ther he is
[21:13] <LargePrime> haha
[21:13] <diddledan> afaict it requires shoving stuff into the binaries directory
[21:13] <popey> ahh
[21:13] <popey> that's unfortunate
[21:13] <diddledan> aye
[21:13] <popey> how big is the binaries directory?
[21:13] <LargePrime> diddledan, also we cannot add portraits
[21:13] <popey> can that be copied out and then launched?
[21:14]  * diddledan goes looksee
[21:15] <diddledan> 858MB
[21:16] <diddledan> most of that in ./data which is probably one of the places that people want to fiddle
[21:16] <diddledan> there's also ./maps, and ./mods
[21:17] <diddledan> ./mods we can probably sync across, and put a symlink in place instead
[21:20] <popey> that might work
[21:20] <popey> what happens when they have traditionally packaged ones
[21:23] <popey> like, if you install from a deb (is there a deb?)?
[21:23] <diddledan> there is no deb that I know of
[21:25] <popey> is there a mac dmg or somehting
[21:25] <popey> Or do you just unpack a zip and run it in place?
[21:26] <diddledan> for the snap it's compiled from sauce
[21:26] <diddledan> I know not how it's distributed elsewhere :-)
[21:38] <jdstrand> roadmr (cc cjwatson): I uploaded 2.43+0really2.42.1 to the ppa. it's building
[21:38] <roadmr> jdstrand: I love the version number :)
[21:38] <jdstrand> roadmr: yeah, Sergio is uploaded 2.43.1 on Monday, so it should all be good
[21:38] <jdstrand> uploading*
[21:39] <roadmr> nice
[21:39] <roadmr> jdstrand: meanwhile the dashboard rollout process toils along :/ I'm still waiting for the CI run to complete.
[21:39] <roadmr> should finish in the next 40 minutes or so \o/ *sob*
[22:23] <diddledan> if a snap with layouts passes manual review can anybody install it? i.e. do users still need to opt-into layouts experiment for a manually approved store snap?
[22:41] <jdstrand> jeez it takes snapcraft two hours to build
[22:41]  * jdstrand taps fingers
[22:41] <jdstrand> (in LP)
[23:23] <jdstrand> Get:11 http://ppa.launchpad.net/snappy-dev/tools/ubuntu xenial/main ppc64el snapcraft all 2.43+0really2.42.1 [199 kB]
[23:30] <cjwatson> good good
[23:30] <jdstrand> fyi, things should start passing again
[23:30] <jdstrand> see https://forum.snapcraft.io/t/builds-failing-automated-review/7112/3
[23:30] <jdstrand> my review-tools upload grabbed the downgraded snapcraft, built and reviewed successfully
[23:30] <jdstrand> cjwatson: thanks for the tip :)
[23:34] <cjwatson> np