[00:03] <mtaylor> FAIL
[00:03] <mtaylor> oh, NEVERMIND
[00:03] <mtaylor> sorry
[00:12] <rowinggolfer> any idea when the the site will be up again?
[00:12] <rowinggolfer> I am itching to do my first ever push
[00:12] <thumper> rowinggolfer: see the topic
[00:13] <thumper> rowinggolfer: it should be back shortly
[00:13] <rowinggolfer> thumper: thanks
[00:13] <thumper> rowinggolfer: I'm certain there will be some form of announcement here when it's back
[00:14] <rowinggolfer> cool
[00:14] <rowinggolfer> bad karma that my first ever push co-incided with maitenance
[00:14] <rowinggolfer> hope It wasn't something I did ;)
[00:15] <thumper> no, nothing to do with you
[00:15] <rowinggolfer> thanks thumper.
[00:27] <spm> FYI ALL. Most parts of LP are back up now. Regular tasks are still down while we verify all is a-ok.
[00:36] <thumper> joey: Expected back: 23.30 UTC 15nd April ???
[00:37] <rowinggolfer> that's correct. it is still yesterday as far as UTC is concerned
[00:37] <thumper> rowinggolfer: 15nd of April?
[00:38] <rowinggolfer> well I made a push
[00:38] <thumper> cool
[00:39] <rowinggolfer> thumper: this is the first code I have ever stuck on launchpad
[00:39] <thumper> rowinggolfer: congrats then
[00:39] <rowinggolfer> I am getting a "this branch has not been scanned yet"
[00:40] <thumper> rowinggolfer: it takes a minute or two
[00:40] <rowinggolfer> ok.
[00:40] <rowinggolfer> first time using bzr also.
[00:40] <thumper> rowinggolfer: we are working to reduce that time
[00:40] <thumper> rowinggolfer: have you used other DVCSs ?
[00:40] <rowinggolfer> launchpad is a beautiful experience though
[00:40] <joey> thumper, :-)  15th
[00:40] <rowinggolfer> thumper: only ever to grab code... never before to push
[00:42] <thumper> rowinggolfer: I'm pleased you like it
[00:42] <rowinggolfer> oh dear... my branch is empty
[00:42] <rowinggolfer> I have mucked up somewhere
[00:42] <thumper> rowinggolfer: locally, do a `bzr revno`
[00:42] <rowinggolfer> ok
[00:42] <thumper> rowinggolfer: and maybe a `bzr info`
[00:42] <thumper> or `bzr info -v`
[00:43] <thumper> that should say the number of revisions in the repository
[00:43] <thumper> revno will give you the number of mainline revisions in the branch
[00:43] <thumper> not sure what it says if the branch is empty
[00:43] <rowinggolfer> ah... I get 0 revisions
[00:44] <rowinggolfer> so I should touch all the files?
[00:44] <thumper> no
[00:44] <thumper> what exactly have you done?
[00:44] <thumper> can you give me your bzr command history?
[00:44] <rowinggolfer> ok. here's what I did
[00:44] <rowinggolfer> I made a directory and populated it with my code
[00:44] <rowinggolfer> I'm on ubuntu BTW
[00:45] <thumper> ok
[00:45] <rowinggolfer> I navigated into said directory
[00:45] <rowinggolfer> bzt inti
[00:45] <rowinggolfer> bzr init
[00:45] <rowinggolfer>  bzr push lp:~rowinggolfer/rowinggolfer/trunk
[00:45] <thumper> rowinggolfer: ok, you missed two steps:
[00:46] <thumper> bzr add
[00:46] <thumper> bzr commit
[00:46] <thumper> add recursively adds the files
[00:46] <thumper> and commit makes it happen
[00:46] <thumper> then push will work
[00:46] <rowinggolfer> thanks
[00:46] <thumper> (as you expect it to)
[00:46] <rowinggolfer> bzr commit has open a nano
[00:47] <thumper> yes it expects a commit message
[00:47] <thumper> normally I pass one in on the command line
[00:47] <rowinggolfer> so I simply save that
[00:47] <thumper> bzr commit -m "Initial import" or whatever
[00:47] <rowinggolfer> cool
[00:48] <rowinggolfer> ok pushing now
[00:48] <rowinggolfer> this is very exciting
[00:48] <rowinggolfer> makes me feel like a real geek
[00:48] <thumper> heh
[00:48] <rowinggolfer> many, many thanks for your help
[00:49] <thumper> rowinggolfer: np
[00:49] <rowinggolfer> BTW - is the launchpad podcast still ongoing?
[00:50] <thumper> I think so
[00:50] <thumper> mrevell does them
[00:50] <rowinggolfer> I haven't seen any turn up on my drive for a while....
[00:50] <thumper> I think there was a podcast just yesterday
[00:51] <rowinggolfer> ok... fault at my end then...
[00:51] <rowinggolfer> again.
[00:51] <rowinggolfer> :(
[00:52] <rowinggolfer> ok.. revision 1 pushed
[00:52] <rowinggolfer> I bid you goodnight
[00:52] <rowinggolfer> thanks again
[00:52] <thumper> rowinggolfer: good day here :)
[03:32] <poolie> sinzui: i didn't mean to be negative about RDF
[03:33] <poolie> it's potentially cool, it's just that if there's nothing that most people can do with it, it should be less prominent
[03:33] <poolie> like the thing about having invented cans but not yet the can opener
[03:33] <sinzui> poolie: I love RDF. I was an early subscriber to the list and I hacked on it at places I worked
[03:33] <poolie> (which was apparently true for some long time, like 30 years, i guess they banged on them with rocks or something)
[03:34] <poolie> or, more relevantly, like launchpad issuing openid but not yet accepting it
[03:34] <sinzui> poolie: We should publish enough information about projects so that it can be used to make a catalog of apps or people in a different way from how we made Launchapd.
[03:35]  * sinzui is also a jaded OpenID hacker
[03:36] <poolie> i don't have a problem with publishing it
[03:36] <poolie> it would be great if someone did make such a thing
[03:37] <poolie> i'm just disinclined to have links on the project homepage that when cilcked just cause the browser to ask you to save an xml file
[03:37] <sinzui> I agree. RDF is for a machine, not a person
[03:38] <jamesh> poolie: we implemented OpenID in Launchpad at the time when we had another service that needed to rely on it.
[03:38] <sinzui> we need an <link alternate> in the header to support RDF for machines.
[03:38] <jamesh> for shop.canonical.com
[03:38] <poolie> jamesh, if you mean "not because we misunderstood user demand" then i agree
[03:39] <poolie> sinzui: that would be good - and a blog.l.n post about how you can use it
[03:40] <poolie> like a script that will poke that rdf into freshmeat automatically would be nice
[03:40] <jamesh> poolie: well, prior to OpenID, the only shared auth solutions we had involved users entering their password on the remote site.  That was not an option for the shop site, since the site isn't directly managed by us.
[03:40] <poolie> though, hard, because fm insists on ugly passive voice phrasing for announcements
[03:41] <sinzui> I think we did misunderstand openid. We changed the user OpenID Identifiers because users see it as a social identity, which is not what was built in the first two rounds of development
[03:43] <sinzui> I would be happier if lazr changes and releases were sent to PyPI by RDF. I think publishing and distributing requires too much work between sites.
[03:44] <lifeless> poolie: I'm quite convinced that fm has gone insane
[03:45] <lifeless> poolie: they used to be far more relaxed
[03:45] <jamesh> I don't think I've bothered sending release announcements to freshmeat for a very long time
[03:45] <poolie> did you see their (apparently accidentally) snarky reply to bob in 1.13?
[03:45] <wgrant> I've always wondered about the purpose of the RDF stuff.
[03:46] <lifeless> poolie: yes, I was copied on that thread
[03:46]  * poolie hungers
[03:46] <sinzui> wgrant: I seems to be a broken promise, or one that has yet to be fulfilled.
[03:47] <jamesh> wgrant: it was originally going to be DOAP and FOAF exports.  Our data model didn't quite fit DOAP, which is why a different set of properties were used.  I think there is an equivalence in t he schema, but I could be wrong.
[03:48] <jamesh> the people/team RDF is pretty standard.
[03:48] <wgrant> Actually, I forgot about the team RDF. I used to use that a bit.
[03:48] <wgrant> But not the project stuff.
[03:48] <wgrant> I've never seen a use for that.
[03:49] <sinzui> wgrant: what did you use the team RDF for?
[03:49] <wgrant> sinzui: It was for a long time used for creating the REVU keyring.
[03:49] <wgrant> REVU would regularly grap the RDF for the keyring team and get the OpenPGP IDs.
[03:50] <wgrant> And later it was used for SSH public keys.
[03:52] <wgrant> Why is the list of proposed team members not batched like the active and former lists?
[03:53] <sinzui> The active members was batch to address an immediate concern that the page would not load
[03:53] <sinzui> And batching requires a hack if there is more than one batching list on a page
[03:53] <sinzui> The right answer would be to use ajax to get more items to add to the list
[03:54]  * sinzui want to do that for big lists of bugs and specs
[03:55] <sinzui> wgrant: The members lists should be searchable too.
[03:55] <sinzui> paging though launchpad-users is neigh impossible.
[03:56] <wgrant> sinzui: There are two batches on +members.
[03:56] <sinzui> wgrant: it is a hack
[03:56] <wgrant> It is.
[03:56] <wgrant> But why not the third one as well?
[03:57] <sinzui> I don't think I'll get to team member pages for two months. I wanted to do them this month, but guide project registration needs a lot of help
[03:57] <wgrant> I see.
[03:57] <sinzui> wgrant: because we need to hack a third batch navigator to work on the page
[03:58] <sinzui> The team page work was no scheduled. I just wanted to make the pages more usable
[03:58] <wgrant> sinzui: Sure, but I wouldn't think that would be too difficult once you'd done it once.
[03:58] <wgrant> Ah.
[03:58] <sinzui> none-the-less I agree that the inconsistency is a problem
[03:59] <wgrant> Teams like ~ubuntumembers have an obscenely large number of proposed members.
[03:59] <sinzui> kiko has me look go through that page when large teams are involved to encourage me to make them nice
[03:59] <wgrant> Heh.
[04:00] <sinzui> wgrant: right. I was going to hack on a bug to take the use to the proposed member review page from the team page
[04:01] <wgrant> I don't think I've ever seen /~launchpad-users/+mailing-list-subscribers not time out.
[04:01] <wgrant> sinzui: EPARSE
[04:02] <sinzui> bug 326998 would let the user  link from the list of recently applied to the approval page
[04:02] <wgrant> sinzui: And the applications page would be split out of +members?
[04:05] <sinzui> wgrant: I wanted to link to the screen that lets the admins do bulk/single approvals
[04:06] <wgrant> sinzui: That would be nice.
[05:12] <meoblast001> hi
[05:12] <meoblast001> launchpad sent me an email saying i wouldnt get anymore emails from my mailing list and told me i can corect it by clicking on of the dead links below
[05:16] <Ursinha> meoblast001, can you show me the dead links, please?
[05:16] <meoblast001> ok
[05:17] <meoblast001> https://lists.launchpad.net/mailman/confirm/mysticgalaxies/a37b41225f8fbfd6462b522672bc22a7b1966cfc
[05:17] <meoblast001><EMAIL_ADDRESS>[05:34] <Ursinha> meoblast001, what do you get when clicking on them?
[05:34] <meoblast001> Ursinha: the good old 404
[05:34] <Ursinha> (sorry the delay, pretty late over here :)
[05:34] <meoblast001> The requested URL /mailman/confirm/mysticgalaxies/a37b41225f8fbfd6462b522672bc22a7b1966cfc was not found on this server.
[05:36] <Ursinha> weird
[05:37]  * Ursinha looks at beuno
[05:38] <meoblast001> well... if i could just be unbanned from my own mailing list that would be fine
[05:42] <spm> meoblast001: when did you get the email that asks to click on the link?
[05:42] <meoblast001> a while ago but i clicked the link the day of or the day after i got it
[05:42] <spm> meoblast001: like > 12 hours ago received and clicked?
[05:43] <meoblast001> probably
[05:43] <spm> probably? :-) I ask as we had major update about 4-5 hours ago. may *not* be related, but ... may.
[05:44] <meoblast001> oh no... it was >12 hours ago
[05:44] <meoblast001> i thought you meant did i click it > 12 hours after receiving it
[05:44] <meoblast001> got it on April 8
[05:48] <meoblast001> i need to go to bed
[05:48] <meoblast001> goodnight everyone... i'll be back another day
[05:59] <Ursinha> spm, maybe that link expired? no clue
[05:59] <Ursinha> brain not working
[05:59] <spm> Ursinha: possibly
[05:59] <spm> Ursinha: given how late it is your way? not surprised :-)
[05:59] <Ursinha> spm, writing the handover email :)
[06:00] <Ursinha> and reviewing projects
[06:00] <Ursinha> do you know what comes next?
[06:00] <Ursinha> the losas fun!
[06:00] <spm> Ursinha: you are an evil evil person. nice, but evil. :-P
[06:00]  * Ursinha laughs evilly
[06:00] <Ursinha> :P
[06:00] <Ursinha> lol
[06:01] <spm> see! QED. spm 1, Ursula 0.
[06:01] <Ursinha> hey... you're cheating
[06:01] <Ursinha> I have way more than that 0, where are my points
[06:01] <Ursinha> spm, oh, I see, that karma rebalancing took them away
[06:02]  * Ursinha is funny today
[06:02] <spm> Ursinha: nah. that was me. DELETE from karma where uid=ursinha; I was bored earlier.
[06:02] <Ursinha> lol
[06:02] <Ursinha> THAT is cheating
[06:03] <spm> it also won't work, but never mind that :-D
[06:34] <wgrant> spm: Is staging meant to be out of date?
[06:34] <johnf> anyone know if there is a problem with ppa building? I've had something in the queue for over 2 hours and now it doesn't even have an estimate. Normally I have things build in less 20 mins
[06:34] <spm> wgrant: probably - the reboots this morning wouldn't have helped
[06:34] <johnf> Is there an overall build status page?
[06:35] <spm> johnf: yes. we're having some buildd issues atm. No eta on a fix unf. :-(
[06:35] <wgrant> spm: I have data on there from 5 days ago, and it is running db-devel from the 10th or so AFAICT...
[06:36] <wgrant> johnf: https://launchpad.net/builders/
[06:36] <johnf> wgrant: thanks. I'll go blog that as my google searching discovered nothing
[06:37] <wgrant> I wonder if I can find a link to it.
[06:37] <wgrant> IIRC I was only able to get to it from the breadcrumbs of a builder, which I got to from a build.
[07:49] <maxb> window level all
[10:03] <thp> i have a permission problem on launchpad
[10:04] <thp> i can access bug 362045, but not but 347483. (the former is a duplicate of the latter)
[10:05] <wgrant> thp: Both are private bugs, because the crash dumps may have confidential data. I'll check the latter to see if it's appropriate to open it up.
[10:06] <wgrant> Oh, only the latter is public.
[10:06] <wgrant> s/public/private/
[10:06] <wgrant> thp: You can now see bug #347483
[10:06] <thp> wgrant: thanks :)
[10:29] <rowinggolfer> hey popey
[10:29] <popey> hello
[10:30] <rowinggolfer> I have pushed a project onto launchpad
[10:30] <rowinggolfer> if you get a minute, do tell me if I have fouled up in any way
[10:30] <popey> url?
[10:30] <rowinggolfer> http://launchpad.net/rowinggolfer
[10:31] <popey> did you want rowinggolfer as the project name? would it not make more sense to be called openmolar?
[10:31] <rowinggolfer> popey: yes it would... I screwed up
[10:31] <popey> heh
[10:32] <popey> I dont know if it's possible to rename a project on launchpad, you might need the assistance of a launchpad admin
[10:32]  * popey pokes mrevell
[10:32] <mrevell> hello
[10:32] <mrevell> :)
[10:32] <rowinggolfer> I asked in here... and was told to wipe it and start again
[10:32] <popey> ah
[10:32]  * mrevell reads up
[10:32] <rowinggolfer> hey mrevell
[10:32] <mrevell> rowinggolfer: Who told you to wipe and it start again?
[10:32] <rowinggolfer> popey: I am delighted your podcast has restarted. I was worried
[10:33] <popey> thanks rowinggolfer
[10:33] <rowinggolfer> mrevell: I can't remember. it was over a month ago
[10:33] <mrevell> rowinggolfer: To rename a project, you'll need to file a request at https://answers.launchpad.net/launchpad
[10:33] <popey> excellent, that easier
[10:34] <rowinggolfer> mrevell: thanks!!
[10:34] <mrevell> np :)
[10:34] <rowinggolfer> ah... that's ringing bells now
[10:34] <popey> \o/
[10:34] <rowinggolfer> that is where I asked
[10:34] <rowinggolfer> let me find where
[10:34] <mrevell> oh really?
[10:35] <popey> https://answers.edge.launchpad.net/launchpad/+question/62436
[10:36] <popey> calvin misunderstood by the look of it
[10:36] <popey> confusion between your username and the project name
[10:37] <rowinggolfer> I asked the wrong question?
[10:37] <popey> no, not imo
[10:38] <danilos> rowinggolfer: we'll have admins rename the project for you
[10:38] <rowinggolfer> danilos: many thanks
[10:38] <mrevell> rowinggolfer: I'm sorry no one picked up on Calvin B's erroneous answer
[10:39] <rowinggolfer> can I just commend you fellas on a wonderfully designed code hosting site
[10:39] <rowinggolfer> this is my first ever commit to anything of this type
[10:39] <mrevell> thumper, jml, abentley, rockstar ^^^ See rowinggolfer's props for Code Hosting :)
[10:40] <mrevell> thanks rowinggolfer :) If you need any help we're here most of the time
[10:40] <rowinggolfer> mrevell: thumper helped me out last night.
[10:40] <mrevell> because we're spread across the world, there's usually someone here :)
[10:40] <rowinggolfer> thanks.
[10:40] <rowinggolfer> good luck with july 31st BTW
[14:13] <lukeW> hi - is it possible to edit a bug comment... I inadvertently left a phone number (via an email signature reply) and I'd like to remove this
[14:13] <beuno> lukeW, you can't edit it
[14:14] <beuno> but you can ask for an admin to remove it
[14:14] <beuno> in: https://answers.launchpad.net/launchpad
[14:14] <lukeW> okay .. thank beuno
[14:14] <lukeW> *thanks
[14:15] <intellectronica> lukeW: bear in mind that by the time you get to remove the comment, emails with bug notifications will have already been sent. that makes your situation either more or less serious, depending on how you judge it
[14:16] <lukeW> intellectronica; it's okay really - i just don't want the phone number on the web (via searches etc)
[14:23] <lukeW> will editing ever be introduced to launchpad?
[14:23] <intellectronica> lukeW: no
[14:23] <lukeW> I suppose it could lead to confusion?  Is that the reason it's not allowed?
[14:24] <intellectronica> lukeW: exactly. once you've said something and people have added other comments, potentially referring to yours, having your previous comment removed can be confusing
[14:25] <lukeW> the ability to make minor edits could be useful - if only for the archive / web version
[14:25] <intellectronica> lukeW: maybe, maybe, one day in the very distant future we'll have an undo available for a few minutes after posting, like you get in gmail now
[14:25] <lukeW> ah okay
[14:25] <lukeW> i still haven't worked out how to access the gmail undo
[14:26]  * beuno stares into the future
[14:26] <lukeW> lol
[14:26]  * lukeW sees the future stare back
[14:26] <intellectronica> lukeW: you turn it on in the "labs" tag in the yellow settings box
[14:26] <lukeW> ah okay
[14:26] <lukeW> i'll do that
[14:26] <lukeW> will be quite useful
[14:37] <wgrant> Are product/distribution/sourcepackagename changes going to be interleaved in 2.2.4?
[14:38] <beuno> wgrant, interleaved with what?
[14:38] <beuno> and hi  :)
[14:39] <wgrant> beuno: With the comments, like a few change types were in 2.2.3.
[14:40] <wgrant> Ah, I mean in bugs.
[14:40] <beuno> good question
[14:40]  * beuno stares at gmb
[14:51] <danilos> beuno: stop those cross-eyed looks!
[15:02] <gmb> wgrant: You mean as in "I rename my project, that gets reflected in its bug tasks' activity logs"?
[15:03] <wgrant> gmb: No, as in "I retarget this task from launchpad to malone"
[15:03] <gmb> wgrant: Oh, thank fuck for that. :)
[15:04] <gmb> wgrant: Er, if we have time. It's not a big change; I might get time to land it in week 4.
[15:04] <wgrant> gmb: Although that would certainly be nice, it would certainly complicate everything.
[15:05] <gmb> wgrant: More than somewhat, yes :). Although in terms of actual code it's probably not all that hard to do.
[15:07] <wgrant> gmb: Anyway, I was going to bed. Thanks.
[15:07] <gmb> np.
[15:53] <johnf> do packages in a ppa have higher preferences than packages in ubuntu when the ppa is building?
[15:57] <al-maisan> johnf: it's not as simple, the build scoring algorithm uses a number of factors
[15:57] <johnf> al-maisan: is it documented anywhere?
[15:57] <al-maisan> johnf: I do not believe so.
[15:58] <james_w> johnf: you mean when installing build-dependencies?
[15:58] <johnf> james_w: yes
[15:58] <james_w> my guess is no
[15:59] <al-maisan> johnf: sorry, I misunderstood you ; I thought you meant the scoring of builds
[15:59] <johnf> ie if my ppa has ruby-dev 1.8.6 and ubuntu has  ruby-dev 1.8.7 and I have another package with build-depends on ruby-dev. Will it use ruby-dev from my ppa even though it has a lower version  number
[16:00] <cprov> johnf: no, it will use the highest version.
[16:00] <johnf> hmm ok looks like I'll have to increment the epoch
[16:02] <cprov> johnf: and if we are talking about exactly same versions, we can't reliably predict which version will be installed (as far as I can tell)
[16:02] <johnf> hmm https://help.launchpad.net/Packaging/PPA?action=show&redirect=PPAQuickStart#Dependencies seems to indicate it will prefer the PPA
[16:02] <cprov> johnf: ubuntu archive comes first in the buildd sources_list, but I'm not sure if it matters.
[16:03] <johnf> cprov: so there isn't an apt-preferences for the ppa?
[16:03] <johnf> Will be wonderful when this is all open source, then I could just go check for myself :)
[16:03] <cprov> johnf: no, in the help there is no *explicit* indication that PPA build-deps are preferred
[16:07] <cprov> johnf: I can't find anyone to answer that quickly, could you please open a question in the soyuz product about it ?
[16:07] <cprov> johnf: it's a nice FAQ candidate.
[16:08] <johnf> cprov: sure
[16:08] <cprov> johnf: thank you.
[16:11] <maxb> Hmm. If you have exactly the same version in the Ubuntu primary archive and an Ubuntu PPA, I think the answer is You're Doing It Wrong :-)
[16:12] <cprov> maxb: yes, yes, but I'm curious about which version will be installed. If it's somehow predictable either by apt or sbuild.
[16:13] <maxb> If it's up to apt, it'll be the first one in sources.list afaik
[16:13] <cprov> maxb: right, I vaguely remember of reading it
[16:14] <cprov> in this case, primary archive always goes first (you can tell by looking at the buildlog)
[16:15] <johnf> The example use case is say I need ruby 1.8.6 for intrepid (which has 1.8.7). I can upload this to my PPA and it will build
[16:16] <johnf> but then if I upload libmysql-ruby to my ppa it will build against the primary ruby instead of the ppa ruby. Well I assume it will anyway. Giving it a quick test now
[16:18] <maxb> johnf: You really need such a specific version?
[16:18] <johnf> maxb: In this specific case I'm patching ruby with the enterpirse edition patches which only apply against 1.8.6-p286. So yes very specific :)
[16:21] <maxb> Perhaps you should package it as ruby-ee, and declare a conflict on the standard ruby packages
[16:23] <johnf> maxb: I tried that initially but then I need to create new packages -ee packages for every single package I need that depends on ruby. Rather than just copying them into my ppa.
[16:24] <johnf> At this stage I think I'll bump the epoch on my ruby package to make sure it becomes the builddep
[16:24] <maxb> johnf: Is this PPA just for you personally, or for a wider audience?
[16:25] <johnf> maxb: Just for me
[16:25] <maxb> Hmm, actually, why would you need to create new packages?
[16:25] <maxb> And for that matter, why would you need to copy them into your PPA, even?
[16:25] <johnf> so right now libmysql-ruby depends on ruby1.8-dev
[16:26] <johnf> If my ppa packages where prefered I could just copy it into the ppa and it would build against my ruby packages
[16:26] <johnf> I can achieve that by adding an epoch version I suppose
[16:27] <johnf> but if I did the -ee method I would need to change the build depends for libmysql-ruby to depend on -ee
[16:27] <johnf> or am I missing some easier way of doing this/
[16:27] <johnf> ?
[16:27] <maxb> Hmm, no, you would have to change the build-depends.
[17:25] <jere21> Hi, I accidentally created a second ppa. Can i delete it?
[17:27] <Ursinha> jere21, hi, you can ask the deletion file a question in answers.launchpad.net/launchpad-project
[17:27] <Ursinha> again
[17:27] <jere21> thx!
[17:28] <Ursinha> jere21, hi, you can ask the deletion, just file a question in https://answers.launchpad.net/launchpad-project
[17:28] <Ursinha> sorry the messed answer :)
[17:28] <jere21> np :-)
[17:28] <Ursinha> jere21, no problem :)
[18:16] <scott_ev> so, who lost 75% of their points besides me
[18:17] <scott_ev> change the point system, fine, just don't take peoples points  away
[18:18] <scott_ev> I WAS spending 20 hours a week triaging bugs....no more
[18:19] <scott_ev> there are plenty of places I can help without getting messed  around
[18:22] <matsubara> scott_ev: http://blog.launchpad.net/general/karma-where-did-mine-go
[18:23] <scott_ev> oh, I've read it and it's BS
[18:23] <exarkun> You should get a 3x karma multiplier for reading that page
[18:23] <scott_ev> thange the point system, fine, but don't take peoples points away
[18:24] <scott_ev> I went from 6500 - 1900
[18:38] <maxb> scott_ev: If everyone's karma was adjusted down, that's fair, no?
[18:43] <scott_ev> it just feels wrong to take away.  change the rules, ok
[18:44] <scott_ev> maxb: did you loose 75%?
[18:44] <maxb> Don't know what I had before.
[18:45] <scott_ev> all I know is that since I don't work anymore, I spend most of my time helping in launchapd and I got screwed
[18:45] <scott_ev> someone will take my place
[18:53] <rockstar> scott_ev, what did you karma really provide for you?
[18:54] <scott_ev> a sense of accomplishment.  goals to set and accomplish
[18:54] <scott_ev> and something to show when I interview for ubuntu membership
[18:55] <intellectronica> scott_ev: your frustration is understood, but consider that we too like to have our work appreciated, and this sort of attitude is kinda' frustrating
[18:56] <scott_ev> change the rules, fine.  but don't take points away that have already been given
[18:56] <scott_ev> it's crap
[18:56] <intellectronica> scott_ev: karma is relative, but appears to be absolute, and because of that, the change looks kinda' scary, but consider that when you, say, interview for ubuntu membership, your karma will be evaluated in relation to others, not as an absolute
[18:57] <intellectronica> scott_ev: karma is relative, the rules for behaviour in this community aren't. please stop
[18:57] <scott_ev> stop what, voicing an opinion?
[18:57] <scott_ev> i don't think so
[18:58] <intellectronica> scott_ev: your opinion is very welcome, that's what this channel is about. but you're expected to voice it in a civilised and friendly manner. even when you are frustrated
[18:59] <scott_ev> I believe I have
[18:59] <scott_ev> what?  you're upset that I used the worr crap?
[18:59] <scott_ev> sorry
[19:00] <intellectronica> scott_ev: and finally, yes, this was a mistake, and it was corrected. it _is_ annoying when that happens, and we work very hard to try and make sure it doesn't. but when it does, it's nice if we can get your understanding
[19:01] <scott_ev> ok, I'll leave you to it. There are more productive things I can do with my time that will be appreciated
[19:02] <intellectronica> scott_ev: indeed. and once again, apologies for the karma problems on behalf of the launchpad team
[19:03] <scott_ev> well think things through and maybe warn people that changes are  comming.  I woke up to find 75% of my karma gone with no explaination for 2 days
[19:04] <exarkun> intellectronica: I wonder why it was a "mistake" and how the change was a "correction"
[19:04] <intellectronica> scott_ev: yes, that's definitely one of the lessons to learn from this
[19:05] <exarkun> (I don't think I pay as much attention to my karma as scott_ev does to his, but I pay /some/ attention, and I am stimulated negatively when it goes down due to no actions on my part)
[19:05] <scott_ev> I'm nit so frustrarted that it happened; it's more in the 'how' and why.  you just don't take things from people, period...not when they are volunteers
[19:05] <intellectronica> exarkun: have you read danilo's blog about this? i think it clarified it quite well. the most important thing to take from it, i guess, is that karma is relative, even though it may seem absolute
[19:05] <exarkun> intellectronica: I did, and it didn't really address the question I'
[19:05] <exarkun> m trying to ask
[19:05] <exarkun> Since karma doesn't actually /mean/ anything, I wonder what the motivation for using it to make me feel bad is.
[19:05] <javierder> joey, ping
[19:06] <joey> and hi here jacob
[19:06] <joey> er javierder
[19:06] <joey> lol
[19:06] <joey> tab tab tab tab atab
[19:06] <exarkun> The only thing I could derive from danilo's blog post is that the lp developers thought they had done something "unfair" in granting too much karma.
[19:06] <exarkun> But since karma /doesn't/ mean anything, I wonder how "unfair" it really could be.
[19:07] <exarkun> Is it that other people who weren't participating while karma was being inflated might feel cheated because they have to do more work to catch up to people who were?
[19:08] <LarstiQ> exarkun: I use karma to get an idea of how involved someone is with a project
[19:09] <exarkun> LarstiQ: It seems to me like it is a value which is deceptive in the indication it gives of that.
[19:10] <exarkun> Even ignoring the likelihood that it is very easily gamed, how do you know how much value to assign to a point of karma?  Perhaps there is a correct way to do that which I am just not aware of.
[19:12] <intellectronica> exarkun: after the fix, karma is more reflective of a user's participation than it was before _in relation to other users_
[19:12] <LarstiQ> exarkun: relative to the other people active in the project
[20:59] <kkubasik> bac:  hey, hows it going?
[20:59] <bac> kkubasik: hi.  things are going well.
[21:04] <MTecknology> Is it ever going to be possible to allow users that aren't in a team to sign up for the mailing list?
[21:04] <MTecknology> I noticed this in the new layout "Policy:  You must be a team member to subscribe to the team mailing list." and was wondering if I can make that change :)
[21:05] <beuno> MTecknology, it's...  complicated
[21:05] <beuno> maybe
[21:05] <beuno> but it opens up spam again
[21:07] <MTecknology> ok - so the functionality exists, but it's not open in order to prevent spam?
[21:07] <beuno> no, it doesn't exist
[21:07] <beuno> because it creates all sorts of problems
[21:07] <beuno> we do want to make it easier
[21:07] <MTecknology> ok
[21:07] <beuno> so we'll figure out something eventually
[21:08] <MTecknology> good 'nuf for me :) - :P
[21:08] <MTecknology> thanks
[21:08] <beuno> welcome'
[22:02] <scott_ev> hello whoever you are
[22:11] <ikus060> Hi, it's my first time with launchpad and I want to register a new project. May anybody give me some help ?
[22:11] <beuno> ikus060, sure. What seems to be the problem?
[22:11] <ikus060> So far, i'm looking to 'upload' my code into a bazaar branch
[22:12] <ikus060> The branche is https://code.launchpad.net/~ikus060/libnotify-mozilla/trunk
[22:12] <beuno> ikus060, do you have your branch already locally?
[22:12] <beuno> ikus060, I see
[22:12] <ikus060> I don,t think so cause it's the first time i'm using bazaar
[22:12] <beuno> you haven't pushed to the branch yet
[22:12] <ikus060> nope
[22:12] <ikus060> this is what I'm trying to do
[22:12] <beuno> do you have the branch ready locally?
[22:13] <beuno> ikus060, also, have you seen: https://help.launchpad.net/BzrHowto
[22:13] <ikus060> well .. I have the code ready, but I don't have any 'branchs' setup locally
[22:13] <beuno> ikus060, that page explains how to do it
[22:13] <ikus060> great ..
[22:14] <ikus060> I will look into it and come back in case of problem
[22:14] <ikus060> Thanks
[22:22] <ikus060> beuno : I guess there is some information missing : To interact with launchpad in any way, you must have an account and a SSH key registered, so make sure you have both.
[22:23] <jcastro> barry: it seems my permissions to the mailing list approval queue has been removed. Has this responsibility been given to someone else? (woohoo?)
[22:26] <beuno> jcastro, I think it's broken
[22:26] <beuno> I can't access it either
[22:26] <beuno> possibly related to another bug bac is working on
[22:27] <bac> jcastro: barry has landed the fix to that bug but it isn't on edge yet
[22:27] <bac> jcastro: it only happens when the team is private and you aren't a member
[22:30] <jcastro> ah ok, cool, thanks guys
[22:35] <ikus060> Hi, Is there a HowTo tu upload download file ?
[22:40] <barry> bac, jcastro hopefully tomorrow ;)
[22:42] <bac> ikus060: this page should help:  https://help.launchpad.net/Projects/FileDownloads
[22:42] <ikus060> bac: thanks
[22:46] <thumper> morning
[23:09] <savvas> does anyone know why bug 136435 shows an error on the upstream debian bug tracker?
[23:09] <savvas> "Launchpad couldn't import bug #454679 from Debian Bug tracker."
[23:11] <tonyyarusso> Hi, I uploaded a system hardware report through System>Admin>System Testing on Ubuntu 9.04 beta, and now I need to post a corrective comment on it.    Very nice!
[23:14] <jkakar> As time goes on, more and more of the surprises from Launchpad are making me smile, instead of frown.  Nice work. :)
[23:14] <savvas> I'm getting an oops while trying to search for bugs :\ OOPS-1202EB388
[23:14] <beuno> jkakar, you're comment almost makes me cry
[23:14] <tonyyarusso> savvas: No, it's jaunty, but it has comment boxes on each step on the tests.
[23:15] <jkakar> beuno: :)
[23:17] <savvas> tonyyarusso:  I have no idea then, mine just asks for my email address that I used to register myself at Launchpad :) the package is checkbox-gtk and I'm using 0.7.1 at the moment, maybe I'm outdated :)
[23:24] <kirkland> i'm trying to convert https://bugs.edge.launchpad.net/ubuntu/+source/openssh/+bug/362427 into a question
[23:32] <meoblast001> hi
[23:32] <meoblast001> by any chance was i removed from the "do not send" list on my mailing list?
[23:32] <meoblast001> if not i think i'm going to file a bug


[02:25] <Flare183> Any howtos that I can write?
[03:38] <mpt> Howto ask questions on IRC that don't get answered? :-]
[03:55] <nixternal> lol
[08:27] <mdke> mpt: I think the magic way is to stay around for more than 90 seconds
[08:56] <mdke> popey: around this time of day?
[10:01] <mpt> mdke, yes, that was what I was implying :-)
[02:53] <mpt> A Yelp window has just appeared on my screen
[02:53] <mpt> It says nothing except "checkboxes checkboxes FALSE"
[02:53] <mpt> and "About This Document"
[02:54] <mpt> the "About This Document" link does nothing when I click on it
[02:54] <mpt> trs bizarre
[02:55] <mpt> er, trs bizarre
[07:55] <nixternal> man, translations this go round are a mess
[07:56] <nixternal> warning: failed to load external entity "add-applications-zh_CN/.xml"
[07:56] <nixternal> mdke: ^^ did you see that when you did your translations?
[07:57] <nixternal> and also, it is creating directories named document-cc/ instead of just cc/
[11:23] <CIA-18> Ubuntu Documentation: nixternal gutsy * r4464 /kubuntu/ (2385 files in 800 dirs): Kubuntu translation love - not fun at all
[11:33] <nixternal> yowsers!
[11:33] <nixternal> now lets hope it all builds :)
[11:43] <CIA-18> Ubuntu Documentation: nixternal gutsy * r4465 /kubuntu/about-kubuntu/desktop/ (about-kubuntu.desktop about-kubuntu.desktop.in po/): desktop translation
[11:58] <CIA-18> Ubuntu Documentation: nixternal gutsy * r4466 /kubuntu/about-kubuntu/desktop/about-kubuntu.desktop: more desktop translations
[12:11] <CIA-18> Ubuntu Documentation: philbull * r4467 ubuntu/switching/C/applications.xml: Several small improvements (patch by Mads Rommedahl)


[03:01] <mwhudson> where did libburnia upstream go?
[03:03] <mwhudson> oh the git bits are still around
[06:23] <icey> is there any way I can re-poke something that's marked ftbfs in proposed (Groovy)? It failed yesterday but I think it's not an issue with my package (Depends: python3 (>= 3.8.3-1~) but 3.8.2-0ubuntu2 is to be installed)
[06:39] <RikMills> icey: what package? If you have upload rights, there will be a retry button on the build
[06:41] <icey> RikMills: I don't have upload rights, https://launchpad.net/ubuntu/+source/python-os-traits/2.4.0-0ubuntu1/ is the package that failed to build
[06:42] <icey> RikMills: I do suppose I'll be working to get upload rights for the OpenStack packages sometime soon
[06:43] <RikMills> icey: ok. that is in main, so I can't do it. so you need a core dev to poke, unless as you say it in another set
[06:44] <RikMills> FYI the reason for that dep wait 'should' be fixed
[06:45] <icey> RikMills: yeah - I can't reproduce the failure locally this morning, and I heard some conversation about it yesterday :)
[06:49] <RikMills> jibel: this is still happening with ubiquity 20.10.8 https://i.imgur.com/4LTUds6.png
[06:51] <RikMills> icey: looks like it got poked ;) thanks LocutusOfBorg
[06:55] <icey> thanks LocutusOfBorg
[06:55] <icey> and RikMills: Where are you seeing who poked it?
[06:56] <RikMills> icey: You can't, which is a lack in launchpad. I know because I asked in another chat if someone could poke
[06:57] <jibel> RikMills, yeah, I saw the comment on the bug report.
[06:57] <jibel> looking at Mate now
[06:58] <RikMills> jibel: thanks. obviously I confirmed in a VM from that screenshot
[06:58] <icey> RikMills: well, now I'm wondering where else I should be :-D
[06:59] <icey> RikMills: any chance you could ask about getting neutron-vpnaas poked as well, seems to be the same failure :)
[06:59]  * icey goes back to hiding in the corner
[07:00] <Unit193> It's a pretty fun place to be, lurking the corner in the shadows. :3
[07:00] <icey> :-D
[07:00] <RikMills> icey: here is just fine. it was a not public telegram thing. there are plenty of core devs in here, but IRC lacks being able to see who is online (or recently so)
[07:01] <icey> RikMills: indeed it does lack that :)
[07:03] <LocutusOfBorg> icey, done
[07:03] <icey> thanks again LocutusOfBorg
[07:04] <Unit193> Closest you have is /wii $name, which shows you idle time.
[07:04] <LocutusOfBorg> I'm also mass retrying the last 69 packages in excuses age
[11:10] <juliank> trying to bisect make but shit this is though
[11:10] <juliank> There's all sorts of weird incarnations you have to do to bootstrap the build environment
[11:10] <juliank> e.g. po/ is empty
[11:10] <juliank> and then it complains about missing .po files
[11:11] <juliank> And doing this over SSH in a cloud on a different continent is not exactly fun
[11:11] <cjwatson> Doesn't ./bootstrap do the job?
[11:12] <juliank> cjwatson: In 4.3, yes, if you have git:// access
[11:12] <juliank> cjwatson: It's not there in 4.2, and I'm bisecting between those two
[11:13] <cjwatson> Ah
[11:13] <juliank> Now it's trying to rsync from translationproject.org - ugh
[11:13] <juliank> this ain't going to work
[11:13] <juliank> I can only do http*
[11:14] <juliank> If I do make make, it does nice things but ultimately fails with
[11:14] <juliank> /usr/bin/ld: /tmp/make/glob/glob.c:1342: undefined reference to `__alloca'
[11:14] <juliank> why can't people have decent build systems?
[11:42] <juliank> it's done
[11:43] <juliank> xnox: So, I finished bisecting make on s390x for the flatpak-builder/s390x issue. The cause of the issue was a change to make it use posix_spawn() instead of fork()/exec().
[11:44] <juliank> xnox: I'm not sure if there's an issue with posix_spawn() on s390x, or make's use of it, but I did upload a make 4.3-4ubuntu1 that passes --disable-posix-spawn to configure to make it work again
[11:44] <juliank> I also forwarded that change to Debian
[11:45] <juliank> This is the offending commit: https://paste.ubuntu.com/p/tYhbJFKN76/
[11:47] <juliank> Maybe there's undefined behavior in there and we compile s390x at -O3, could also be the reason, who knows
[11:47] <juliank> debian doesn't test s390x
[11:47] <juliank> debian bug 964541
[11:56] <xnox> juliank:  we should be compiling s390x at -O2, we only use -O3 for ppc64el by default
[11:56] <juliank> xnox: ah ok
[11:57] <xnox> juliank:  is there a launchpad bug about this too? we could try to escalate it to IBM
[11:57] <juliank> xnox: I don't think so
[11:57] <xnox> juliank:  ok, i can open a new one.
[12:00]  * xnox learns word heisenbug
[14:22] <seb128> bah, I don't understand the util-linux build failure in groovy :(
[14:22] <seb128> debian/bsdextrautils.install has
[14:23] <seb128> +#!/usr/bin/dh-exec --with=install
[14:23] <seb128> +usr/bin/write => usr/bin/write.ul
[14:23] <seb128> (well, that's the diff, the actual file doesn't have the +)
[14:23] <seb128> and the build fails on
[14:23] <seb128> dh_install: warning: Cannot find (any matches for) "=>" (tried in ., debian/tmp)
[14:23] <seb128> debian/tmp/usr/bin/write does exist
[14:24] <seb128> and the same .install / rules work in Debian (unless I overlooked a diff/change)
[14:27] <seb128> hum, it's just the error being misleading
[14:29] <Unit193> Silly question, but I presume that install file has +x?
[14:31] <ahasenack> I haven't seen --with=install in the sheban line before
[14:33] <seb128> Unit193, not silly at all, thanks a lot for pointing that out
[14:33] <ahasenack> was that it?
[14:34] <mdeslaur> TELL US WHAT IT WAS!!!
[14:34] <mdeslaur> WE WANT TO KNOW!!!
[14:35] <seb128> lol
[14:35] <Unit193> Uh oh, someone appears to have made mdeslaur's coffee too strong.
[14:35] <seb128> build is ongoing, ut it was missing a +x yes
[14:35] <Unit193> Happy to have been of help.
[14:36] <mdeslaur> Unit193: perhaps I didn't put enough rum in it
[14:36] <seb128> will teach me to merge by just applying the debdiff :p
[14:37] <Unit193> If the diff is generated correctly (eg, git) `patch` can understand to set the correct permissions.
[14:38] <seb128> right, well it wasn't in this case because I wrongly assumed it was a simple diff and doing complicated things wasn't needed :p
[14:38] <seb128> the error is really unhelpful though
[14:38] <seb128> 'dh_install: warning: Cannot find (any matches for) "=>" (tried in ., debian/tmp)'
[14:38] <seb128> it doesn't even tell you the item it tries to match
[14:39] <Unit193> It tried to install, literally, '=>'
[14:39] <seb128> not to mention the permission, feels like something could warn about a dh-exec script not being +x
[14:46] <seb128> ahasenack, but yeah, that was the issue :/
[14:46] <ahasenack> good to know
[14:47] <seb128> indeed
[14:47] <seb128> Unit193, thank you again!
[14:47] <Unit193> Sure thing.
[14:47] <ahasenack> it's in the same category of weird errors when you try to run a shell script what has windows line endings
[14:49] <seb128> right, 'fun ones" :)
[14:50] <Unit193> Or the error when pkg-config is missingg..
[17:34] <realtime-neil> How does one build the various artifacts listed here? https://releases.ubuntu.com/20.04/
[18:58] <sarnold> realtime-neil: I think this is the starting point https://code.launchpad.net/ubuntu-cdimage
[18:59] <realtime-neil> sarnold: much thanks
[20:09] <mwhudson> it's pretty hard to get going on your own machine unfortunately
[20:23] <ahasenack> hi +1 maintenance team, I'm looking over the nginx and python-certbot/python-acme migrations
[20:23] <ahasenack> is there a highlight word for this team, btw?
[21:00] <ahasenack> I'm noticing a larger than usual delay between a dep8 run disappearing from the /running url, and its result showing up in autopkgtest.u.c, anyone else wondering?
[21:00] <ahasenack> so much that earlier today I kicked another run, thinking "didn't I trigger this before?", and an hour later both results came back
[21:01] <ahasenack> specifically, I'm waiting for a result on http://autopkgtest.ubuntu.com/packages/p/python-certbot-apache/groovy/armhf
[21:16] <mwhudson> vorlon: should we seed shim-signed and grub-pc on all bootable amd64 images? some flavours currently end up with grub-efi-amd64 to satisfy shim-signed's alternate dep and then install fails


[09:09] <adi1992> how to use cloud-init on ubuntu 14.04  to  configure a vm  ubuntu.qcow2 image with kvm hypervisor . Not able to virt-install with cdrom option whith user-data and meta-data .iso files . any help ?
[09:24] <adi1992> where should I post queries on cloud-init , I am new to IRC , if there is a separate page or something please provide the link .
[19:50] <rharper> smoser: on the ntp fix, did you want me to drop the tox changes altogether from the branch? or just rebase into collapsed comments (tox change, test-case update,  cloud-init module changes, unittests) ?
[19:50] <rharper> s/comments/commits
[19:51] <smoser> drop the tox
[19:52] <smoser> changes
[19:52] <smoser> they shoudl be in another pull request
[19:52] <rharper> ok
[19:53] <rharper> that'll get updated whenever you merge in magicalChicken updated branch;


[02:57] <GTRsdk> tonyyarusso: have you heard anything from Brian recently?
[02:58] <tonyyarusso> Nope - been out of town since we last spoke.  I'll probably see him tomorrow though.
[02:58] <GTRsdk> Okay.


[05:43] <mborzecki> morning
[06:46] <mup> PR snapd#8636 closed: tests: add dependency needed for next upgrade of bionic <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8636>
[06:48] <mup> PR snapd#8634 closed: usersession/agent,wrappers: fix races between Shutdown and Serve <Test Robustness> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8634>
[06:49] <mborzecki> mvo: hey
[06:49] <mvo> good morning mborzecki
[06:50] <mup> PR snapd#8630 closed: tests: inject snapd from edge into seeds of the image in manual preseed test <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8630>
[06:53] <mup> PR snapd#8617 closed: tests: new directory used to store the cloud images on gce <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8617>
[06:54] <mup> PR snapd#8611 closed: tests: not fail when boot dir cannot be determined <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8611>
[07:00] <pstolowski> morning
[07:06] <mvo> good morning pstolowski
[07:13] <mup> PR snapd#8577 closed: secboot,cmd/snap-bootstrap: move initramfs-mounts tpm access to secboot <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8577>
[07:17] <mvo> mborzecki: there is one comment from ian in 8628, is that still relevant to address? this looks like a fine 2.45 piece
[07:18] <zyga> o/
[07:18] <mborzecki> mvo: yes, i'll be pushing a patch there, filepath.Glob() sorts internally but it isn't mentioned in the doc so it's fair to call it an implementation detail and just sort eplxiciltly outside
[07:18] <zyga> hey guys
[07:22] <mborzecki> zyga: hey
[07:23] <mvo> mborzecki: thanks, I want to cherry pick this to 2.45 so I will wait for this update first :9
[07:23] <mvo> hey zyga
[07:35] <mborzecki> mvo: updated #8628
[07:35] <mup> PR #8628: cmd/snap: coldplug auto-import assertions from all removable devices <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8628>
[07:40] <mvo> mborzecki: thank you
[08:18] <mborzecki> zyga: something random? https://paste.ubuntu.com/p/V7PhBg73zj/
[08:18] <zyga> 1;1
[08:19] <mborzecki> btw. 14.04 deb does not build anymore?
[08:19] <mborzecki> https://paste.ubuntu.com/p/f4CdkXsVwm/ getting 2020-05-11T07:32:20.0517313Z E: Unable to locate package dbus-user-session on 14.04
[08:21] <mborzecki> mvo: the ci job in #8628 has finished, please take a look and merge, there's a couple of unrelated failures in the tests
[08:21] <mup> PR #8628: cmd/snap: coldplug auto-import assertions from all removable devices <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8628>
[08:22] <mvo> mborzecki: thanks, in a meeting
[08:32] <zyga> mborzecki: maybe new image?
[08:33] <zyga> I think it's the new image with a new package preinstalled
[08:37] <zyga> re
[08:37] <mborzecki> zyga: we try to install dbus-user-session in prepare, but there's no such package on 14.04 apparently
[08:37] <zyga> mborzecki: is it on master now
[08:37] <mborzecki> zyga: yeah, it's on master
[08:37] <zyga> mborzecki: is that on 14.04?
[08:37] <zyga> mborzecki: IIRC it only was a factor on 16.04
[08:37] <zyga> ubuntu-16.04-64
[08:37] <zyga> the log says 16.04
[08:37] <zyga> sergio preinstalled that package
[08:37] <zyga> it landed this morning
[08:37] <zyga> so we just need a matching test correction
[08:38] <zyga> the test measures what's the state of our image
[08:38] <zyga> so that we understand what to do in tests and what to expect
[08:38] <mborzecki> zyga: i'm confused, which log?
[08:38] <zyga> ah
[08:38] <zyga> you said: "something random? ..."
[08:38] <mborzecki> zyga: that's separate issue :)
[08:38] <zyga> right
[08:39] <zyga> yeah, this package does not exist in 14.04
[08:39] <zyga> we should not try to install it there
[08:39] <zyga> hmm, didn't this land after a spread run?
[08:39] <zyga> anyway, both need to be fixed
[08:39] <mvo> zyga: 8633 is the one that fails in core with the strange ownership, right?
[08:40] <zyga> mvo: yes
[08:40] <mvo> zyga: so if I run this in core16 I should see the same failure?
[08:40] <zyga> mvo: checkout that PR and run core16 spread tests
[08:40] <zyga> yeah
[08:40] <mvo> zyga: I wonder if it also fails on qemu, maybe it's really something cloud specific
[08:40] <zyga> mvo: aaah
[08:40] <zyga> brilliant idea
[08:40] <zyga> I'm sure it will be a decisive test for the cloud-init theory
[08:42] <mvo> zyga: running it now locally here
[08:42] <zyga> ok, I'll grab one thing from upstairs and look at the thing maciek reported
[08:46] <zyga> ok
[08:46] <zyga> let's get to it
[08:50] <pedronis> #8613 needs a 2nd review and is fairly straightforward
[08:50] <mup> PR #8613: o/configcore: pass extra options to FileSystemOnlyApply <Created by stolowski> <https://github.com/snapcore/snapd/pull/8613>
[09:09] <zyga> mborzecki: testing a fix, should be available shortly
[09:09] <mborzecki> zyga: thanks
[09:20] <mborzecki> pedronis: mvo: should i start looking into snap repair for uc20 perhaps or the cli bits for recovery systems?
[09:21] <mup> PR snapd#8637 opened: tests: test adjustments and fixes for recently published images <Created by zyga> <https://github.com/snapcore/snapd/pull/8637>
[09:22] <zyga> mborzecki: ^
[09:22] <pedronis> mborzecki: probably reviews
[09:26] <pedronis> mborzecki: also I think Ian PR can panic in some cases: https://github.com/snapcore/snapd/pull/8635#discussion_r422906005
[09:26] <mup> PR #8635: o/devicestate: support doing system action reboots from recover mode <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8635>
[09:26] <mborzecki> pedronis: ok, let me check that, i can push a fix if needed
[09:36] <mup> PR snapd#8628 closed: cmd/snap: coldplug auto-import assertions from all removable devices <Squash-merge> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8628>
[09:36] <mborzecki> yay
[09:36] <mvo> mborzecki: thank *you* - and cherry-picked to 2.45
[09:37] <mborzecki> mvo: anything else we need to do for auto import right now? (aside from little tweaks)
[09:37] <mvo> mborzecki: I think that's it, this should work now
[09:37] <mvo> mborzecki: once it's on beta/edge I will ask taipei to test it
[09:37] <mborzecki> mvo: great, thanks!
[09:45] <pedronis> we broke 14.04 testing ?
[09:45] <zyga> pedronis: yes
[09:45] <zyga> pedronis: fix is up
[09:45] <pedronis> :/
[09:45] <zyga> 8637
[09:46] <zyga> pedronis: I updated https://github.com/snapcore/snapd/pull/8566
[09:46] <mup> PR #8566: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
[09:47] <zyga> pedronis: it was merged earlier today https://github.com/snapcore/snapd/pull/8636
[09:48] <mup> PR #8636: tests: add dependency needed for next upgrade of bionic <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8636>
[09:53] <pedronis> zyga: again a pulseaudio failure as well: https://pipelines.actions.githubusercontent.com/xS8oSnypZkPEQZqiZgDaRp2kdvQJKbOY08TesHp7E8vn7g4hYR/_apis/pipelines/1/runs/4124/signedlogcontent/31?urlExpires=2020-05-11T09%3A53%3A40.8345409Z&urlSigningMethod=HMACV1&urlSignature=CGXZSIWuB1%2B%2FEaA9iyF9qXEMhUFFa5d0nk8fHPh%2BXic%3D
[09:54] <zyga> that's interesting, it looks like a real issue, look that within the same test we did interact with pulse already
[09:54] <pedronis> and also issues with session agent on core16
[09:54] <zyga> I have an idea about that failure
[09:54] <zyga> pedronis: is that a random or have you seen this more than once?
[09:55] <pedronis> is the one when we cannot talk to the socket
[09:55] <pedronis> but this time is the a different socket not root
[09:55] <pedronis> read unix @->/run/user/12345/snapd-session-agent.socket: read: connection reset by peer
[09:57] <zyga> do you think that the agent is crashing or just shutting down at the wrong moment?
[09:58] <zyga> pedronis: perhaps a debug line would help, something like
[09:58] <zyga> session-tool -u test journalctl --user
[10:02] <zyga> brb,
[10:18] <mborzecki> pedronis: hm perhaps we should error out when trying to request a system action and the system is not yet fully seeded
[10:19] <mborzecki> pedronis: looking at current code, the 'current' system would also be incorrectly detected in such case
[10:19] <mborzecki> so any systemLabel == current.Label checks make no sense at all
[10:19] <pedronis> mborzecki: well, it's complicated
[10:19] <pedronis> you don't get any run or recover
[10:19] <pedronis> action
[10:19] <pedronis> if there's no current I think
[10:20] <mborzecki> pedronis: yes, that also
[10:20] <pedronis> it's install that is strange
[10:20] <pedronis> honestly I think we should just error if you try to install while installing
[10:21] <pedronis> even if it's the same system
[10:21] <pedronis> is just a strange request
[10:21] <mborzecki> maybe just error out early if in install mode
[10:21] <mborzecki> yeah
[10:27] <zyga> re
[10:28] <zyga> pedronis: we could do two things that would have better perception of working
[10:28] <zyga> 1) if we are already performing an operation that is being requested (.e.g. refresh while refreshing) we could just display the progress instead of failing
[10:28] <zyga> this sometimes fails when you open gnome software and it tries to refresh snaps but we're already doing that
[10:29] <zyga> 2) we could perhaps queue a install command if we are in a special state (not seeded, but perhaps other states as well)
[10:34] <zyga> https://github.com/snapcore/snapd/pull/8637 fixes master and needs a 2nd review
[10:35] <mup> PR #8637: tests: test adjustments and fixes for recently published images <Created by zyga> <https://github.com/snapcore/snapd/pull/8637>
[10:43] <pedronis> zyga: this is about mode, not normal snap operations
[10:43] <zyga> I see
[10:43] <zyga> so run vs other?
[10:45] <pedronis> mborzecki: actually, I was confused, we set things into seeded-systems even for the ephemeral ones?
[10:46] <pedronis> mborzecki: it sounds slightly wrong (in terms of defining what is current)
[10:46] <zyga> mvo: did your qemu experiment turn up passing or failing?
[10:47] <mborzecki> pedronis: yes, it's set in mark seeded, which ephemeral does too for itself
[10:47] <mvo> zyga: it failed but in a different test :( in snap-user-service-socket-activation on uc16
[10:47] <pedronis> mborzecki: it sounds kind of wrong
[10:47] <mvo> zyga: sounds like I need to run it again
[10:47] <zyga> mvo: that's a known warning
[10:47] <pedronis> mborzecki: we need to think a bit
[10:47] <zyga> mvo: dit it fail on just that? roughly how many tests did you get throguh?
[10:48] <zyga> mvo: in GCE I see the failure really quickly
[10:48] <pedronis> mvo: all kind of snap-user-service tests fail sometimes on UC16
[10:54] <mborzecki> pedronis: upated #8635
[10:54] <mup> PR #8635: o/devicestate: support doing system action reboots from recover mode <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8635>
[10:55] <pedronis> mborzecki: thx
[10:58] <mvo> zyga: around ~100, I can run it again on gce
[10:58] <zyga> mvo: I'm running int on GCE now with some more ideas
[10:58] <zyga> mvo: but I think this shows it's cloud-init and, presumably, around tests that reboot
[10:58] <zyga> mvo: the naive workaround I added just fixes one reboot case (the initial reboot)
[10:59] <zyga> need to think where to put a fix for something that can happen at any time
[10:59] <zyga> I wonder if we could turn off cloud-init somehow as well, not sure if it should do stuff on core during CI
[11:02] <pedronis> in which sense? some our CI flows use cloud-init
[11:02] <zyga> pedronis: it seems that cloud init data in GCE causes creation of an "ubuntu" user with broken home directory
[11:02] <zyga> but only on core16/18
[11:02] <zyga> (though only *broken* there, it may be that we create it everywhere0
[11:03] <pedronis> well, it's easy to know
[11:03] <pedronis> look what's the user data there
[11:03] <zyga> at cloud-init data? I'm not deeply familiar with it but I looked that some on Friday and
[11:04] <zyga> 1) cloud-init.service sets up the password for ubuntu user, so it's likely it is creating it as well (this is evident in the log file)
[11:04] <zyga> 2) user data contains gustavo's account but I was not able to find the string "ubuntu" there - perhaps I looked at the wrong files as I'm not familiar with cloud-init that much
[11:05] <pedronis> ok, but I doubt turning it off completely is an option
[11:05] <zyga> I see
[11:06] <pedronis> anywway I have no time to help with this atm
[11:10] <pedronis> zyga: is this breaking some tests directly? or it's breaking some sanity checks?
[11:10] <zyga> just a sanity check
[11:10] <zyga> I was wondering where it came from
[11:11] <pedronis> given all the things we have to fix it, seems it should go in the ignore for now bucket
[11:13] <zyga> indeed,
[11:16] <mvo> zyga: running it again in qemu/google on core18, maybe that is more robust
[11:22] <zyga> ok, the 14.04 issue is gone
[11:23] <mup> PR snapd#8637 closed: tests: test adjustments and fixes for recently published images <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8637>
[11:27] <mup> PR snapcraft#3112 opened: spread: remove dead code for lxd setup and add debug prints <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3112>
[11:27] <mup> PR snapd#8638 opened: tests: do not add pkg dbus-user-session on ubuntu-14.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8638>
[11:29] <mup> PR snapd#8334 closed: many: add core.resiliance.vitality-hint config setting <Needs Samuele review> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8334>
[11:36] <zyga> mvo: I added a workaround as samuele suggested, I'll rebase on top of the master fixes and pushed
[11:36] <zyga> mvo: we can return there if we are really bored one day ;-)
[11:37] <mvo> zyga: heh, maybe what is running already contains this workaround, no failure so far on gce
[11:37] <mvo> zyga: anyway, I have lunch now
[11:37] <zyga> oh?!
[11:37] <zyga> weird
[11:37] <zyga> I saw this very quickly
[11:37] <zyga> (before the workaround)
[11:37] <zyga> on core16 or core18?
[11:37] <zyga> I kept running core16
[11:40] <mup> PR snapd#8639 opened: o/cmdstate: handle ignore flag on exec-command tasks (1/N) <Services ⚙> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8639>
[11:50] <zyga> re
[11:51] <zyga> in the times of home schooling, fixing the printer is a rather important duty :/
[11:51] <zyga> mvo: we can close https://github.com/snapcore/snapd/pull/8638
[11:51] <mup> PR #8638: tests: do not add pkg dbus-user-session on ubuntu-14.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8638>
[11:53] <mup> PR snapd#8572 closed: packaging: add the inhibit directory <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8572>
[11:54] <zyga> pedronis: is there a particular name we can settle on in https://github.com/snapcore/snapd/pull/8578
[11:54] <mup> PR #8578: interfaces: add host-docs interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
[11:55] <zyga> pedronis: I'd like to do a small pass, update the name, adjust the test as pawel suggested, and be done with it
[11:57] <pedronis> zyga: so  :   session-tool -u test journalctl --user  gets a permission error about test not being systemd-journal,  and I haven't found an easy way to see the same logs when driving things as root
[11:58] <zyga> curious, let me look
[11:59] <zyga> I mean, the whole point of journalctl --user is to look at your own logs
[11:59] <zyga> was this on core 16?
[11:59] <pedronis> yes
[12:00] <zyga> can you paste the entire message if you have it handy
[12:00] <zyga> I'm looking now
[12:01] <pedronis> session-tool -u test journalctl --user
[12:01] <pedronis> Hint: You are currently not seeing messages from other users and the system.
[12:01] <pedronis>       Users in the 'systemd-journal' group can see all messages. Pass -q to
[12:01] <pedronis>       turn off this notice.
[12:01] <pedronis> No journal files were opened due to insufficient permissions.
[12:01] <zyga> huh, that's very confusing
[12:02] <zyga> checking what happens under the cover
[12:03] <zyga> interesting, it could be a permission error on core
[12:04] <zyga> user logs are in /var/log/journal/*/user-UID@*
[12:04] <zyga> so presumably part of that path is not available to the test user
[12:04] <zyga> it could be that we are lacking some basic group ownership
[12:05] <zyga> oddly all logs are owned by root and systemd-journal group (on classic)
[12:05] <zyga> I'll check if we can simply create the test user with systemd-journal group to solve it
[12:06] <pedronis> it's core so groups is readonly, maybe there's a way around that
[12:06] <zyga> we work around that alreay
[12:06] <zyga> core has extra setup for it
[12:13] <zyga> pedronis: trying something like this now
[12:13] <zyga> https://www.irccloud.com/pastebin/DL4hLdWP/
[12:16] <mup> PR snapd#8640 opened: wrappers: pass 'disable' flag to StopServices wrapper <Services ⚙> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8640>
[12:27] <mup> PR snapcraft#3108 closed: tools: install wheel in snapcraft-dev <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3108>
[12:28] <zyga> almost but not quite ;)
[12:30] <mup> PR snapcraft#3103 closed: python v2 plugin: set path to the interpreter <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3103>
[12:39] <zyga> pedronis: re, can we settle on the final name for the host-docs proposal? I'd love to have that branch behind us :)
[12:40] <pedronis> zyga: I made some proposals, nobody gave feedback on them
[12:40] <zyga> pedronis: I think the word "misc" is probably bet to be avoided
[12:40] <zyga> so perhaps just system-doc?
[12:41] <pedronis> no
[12:41] <pedronis> they are eally not the system docs
[12:41] <zyga> though I personally perfer the plural because there's more than one document there
[12:41] <zyga> what do you mean?
[12:41] <pedronis> they are not the main system doc
[12:42] <pedronis> the manpages and mayb share/info are
[12:42] <zyga> I see what you mean
[12:42] <pedronis> as I said,  the FHS call them miscelleanous documentation, I didn't make that up
[12:42] <zyga> arguably we could explore providing both info and man pages but I would not expect those to be much use
[12:43] <zyga> I think FHS naming is not really that great, it's only misc from a mainframe era point of view
[12:44] <zyga> on my system there are nearly 200MB in /usr/share/doc and only about 50 in both info and man pages
[12:45] <zyga> pedronis: I was wondering about "system" as well, because it's a dual-purpose word in snap world - it can mean the "system" as as a whole, including the core part of it, or the "host system" when thinking about classic systems with snapd also installed
[12:47] <pedronis> I made a 2nd proposal as well: system-packages-doc
[12:48] <zyga> I'm happy with that one, because packages are plural and the "doc" refers to the directory name, not to "documentation" or "documents"
[12:48] <zyga> if you are okay I can apply that quickly
[12:48] <mup> PR snapcraft#3105 closed: build provider: clean incompatible build-environments <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3105>
[13:09] <mup> PR snapcraft#3111 closed: elf: fix parsing of notes after patchelf mangling <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3111>
[13:11] <mborzecki> cmatsuoka: if you can access the shell after booting in recovery mode and chooser failed to trigger, can you try to obtain the log from snapd.recovery-chooser-trigger.service ?
[13:11] <cmatsuoka> mborzecki: will do
[13:11] <mborzecki> cmatsuoka: thanks!
[13:14] <cmatsuoka> mborzecki: I'll re-image ian's PR because sudo doesn't work in this image
[13:23] <mup> PR snapd#8638 closed: tests: do not add pkg dbus-user-session on ubuntu-14.04 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8638>
[13:39] <mup> PR core-build#59 closed: initramfs: add new handle_writable_defaults() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/59>
[13:41] <pedronis> mborzecki: this how Pool is going to be used in the end: https://github.com/snapcore/snapd/pull/8569/files#diff-763375e1fe8805703f81dfb94060286f
[13:41] <mup> PR #8569: o/assertstate,asserts: use bulk refresh to refresh snap-declarations <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8569>
[13:56] <mup> PR snapd#8641 opened: tests: improve debugging of user session agent tests <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8641>
[14:08] <mborzecki> cmatsuoka: chooser seems to start correctly with core20_634.snap, pc_100.snap, pc-kernel_495.snap in recover mode here
[14:09] <cmatsuoka> mborzecki: did you remaster the kernel?
[14:09] <mborzecki> cmatsuoka: no, i did not try to repack it
[14:09] <cmatsuoka> mborzecki: in my tests this situation works too
[14:09] <cmatsuoka> mborzecki: once you repack the kernel it starts to fail
[14:10] <cmatsuoka> you don't really need to inject anything or even change the efi
[14:14] <mup> PR snapd#8642 opened: tests: add dbus-user-session to bionic and reorder package names <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8642>
[14:15] <cachio> zyga, hey, when you have 5 minutes, could you please take a look to #8642
[14:16] <mup> PR #8642: tests: add dbus-user-session to bionic and reorder package names <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8642>
[14:16] <zyga> I'm looking
[14:17] <zyga> does it affect anything? I mean session-tool already shows 18.04 has this, or is that just because the current image has recommended packages?
[14:18] <cachio> zyga, I was testing and the images dont have it
[14:19] <zyga> do you mean the upcoming images?
[14:19] <cachio> zyga, yes, upcomming https://paste.ubuntu.com/p/PRTDY963dY/
[14:19] <zyga> ok
[14:19] <zyga> yeah, looks good
[14:19] <zyga> pedronis: this should help https://github.com/snapcore/snapd/pull/8641
[14:19] <mup> PR #8641: tests: improve debugging of user session agent tests <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8641>
[14:20] <cachio> zyga, once we have that, I can push the image which will fail with the mount-ns test
[14:21] <zyga> cachio: sounds good
[14:21] <cachio> zyga, nice, thanks
[14:23]  * zyga goes for lunch
[14:31] <cmatsuoka> mborzecki: https://pastebin.ubuntu.com/p/67KsBSvCP4/
[14:32] <mborzecki> cmatsuoka: does it reboot?
[14:33] <mborzecki> hmm
[14:33] <cmatsuoka> sorry, I didn't wait again
[14:33] <cmatsuoka> I just rebooted it by hand to get the other log
[14:34] <cmatsuoka> mborzecki: the other log: https://pastebin.ubuntu.com/p/Gkz77ksFK3/
[14:36] <mborzecki> cmatsuoka: from what i've seen you need to hold it super long to trigger the chooser in recovery
[14:37] <cmatsuoka> I press it then the tianocore logo is still on screen, and release it only when the key fingerprints appear
[14:38] <cmatsuoka> and I got a lot of<PHONE_NUMBER> during the boot messages
[14:41] <mborzecki> hmm ok i think i know what's going on
[14:42] <cmatsuoka> ah excellent
[14:42] <mvo> pstolowski: fwiw I uploaded https://github.com/snapcore/core-build/pull/59 to bionic,xenial so the next kernel rebuild should have support for _writable_defaults
[14:42] <mup> PR core-build#59: initramfs: add new handle_writable_defaults() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/59>
[14:42] <pstolowski> mvo: great! thanks!
[14:43] <mborzecki> cmatsuoka: mvo: looking at the logs here, when system is booting in recovery mode, the trigger watch is started in initramfs (your only chance to trigger the chooser is now!), then once we switch root snapd won't start the trigger monitor since it has `# X-Snapd-Snap: do-not-start`, so there's no chance to trigger it during first boot
[14:44] <cmatsuoka> mborzecki: but why does it work when you don't repack the kernel snap?
[14:53] <pedronis> mborzecki: it's a bit unclear why snapd shouldn't start if it's not started already
[14:53] <pedronis> *start it
[14:54] <mborzecki> cmatsuoka: idk, if the log can be trusted, the key triggered in < 10s? weird
[15:10] <cachio> zyga, does it makes sense to have a script which created the github actions workflows based on a cofiguration file?
[15:10] <zyga> cachio: if we end up editing them a lot, maybe, otherwise I would not bother
[15:11] <zyga> cachio: depending on how actions evolve I would expect to see unification, not further shattering of the workflow files
[15:11] <cachio> so it is easy to have a workflow by system
[15:11] <cachio> and it is easy to restart just 1 system
[15:11] <zyga> cachio: it's not quite easy becaues the script doesn't matter to github
[15:11] <zyga> once still has to edit and run the script and commit the result
[15:12] <zyga> *because
[15:12] <zyga> I mean, if we find editing those files a burden, sure
[15:12] <cachio> the idea is to have an script which will create the workflows, the we push that
[15:12] <cachio> so then we just need to edit the template
[15:12] <mup> PR snapcraft#3113 opened: colcon: use packages.ros.org/ros2 repository <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3113>
[15:13] <zyga> cachio: I do understand but did you read what I said above?
[15:13] <zyga> since it's an additional step it doesn't buy us anything over just editing the script once in a while (you need to commit both the script changes and the actual workflow files)
[15:13] <cachio> yes, we don't need to edit/update those
[15:13] <zyga> and I'm not opposed to it in principle but I don't see the need for it either
[15:15] <cachio> zyga, the idea is to avoid this
[15:15] <cachio>       matrix:
[15:15] <cachio>         system:
[15:15] <cachio>         - ubuntu-14.04-64
[15:15] <cachio>         - ubuntu-18.04-64
[15:15] <cachio>         - ubuntu-core-18-64
[15:15] <cachio>         - debian-9-64
[15:15] <cachio>         - arch-linux-64
[15:15] <cachio>         - amazon-linux-2-64
[15:15] <cachio>         - centos-7-64
[15:15] <cachio> 1 workflow 1 system
[15:16] <cachio> does it makes sense?
[15:16] <cachio> until we are able to restart sytems independently
[15:16] <zyga> so that's not quite what you described earlier
[15:16] <zyga> that's a different cahnge
[15:17] <zyga> the problem here is that now you run unit tests way many more times
[15:17] <zyga> this will perform differently
[15:17] <cachio> zyga, we could run unit tests just on some systems
[15:18] <zyga> then we would run spread if unit tests failed
[15:18] <zyga> because you cannot have cross-workflow relationships
[15:19] <cachio> we could use tags for that
[15:19] <zyga> what kind of tags?
[15:20] <cachio> in a gce bucket
[15:20] <zyga> can we do that without doing the script?
[15:20] <zyga> IIRC mvo has implemented this already, it's under review
[15:20] <cachio> zyga, I'l take a look
[15:20] <cachio> that that change, I didn't see that
[15:20] <mup> PR snapd#8643 opened: wrappers: add RestartServices function and ReloadOrRestart to systemd (3/N) <Services ⚙> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8643>
[15:26] <mborzecki> cmatsuoka: repacked ekrnel, added some timestamps to the trigger monitor and can't trigger chooser anymore
[15:29] <zyga> pedronis, jdstrand: updated https://github.com/snapcore/snapd/pull/8578
[15:30] <mup> PR #8578: interfaces: add host-docs interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
[15:30] <zyga> mainly renamed to system-packages-doc
[15:32] <zyga> pedronis: ha, we have logs from the faliure now
[15:32] <zyga> *failure
[15:32] <pedronis> there's no there there
[15:32] <pedronis> fascinating
[15:32] <zyga> snap is gone
[15:32] <zyga> what :D
[15:32] <zyga> right?
[15:32] <pedronis> we are probably leaving a mess in the maint script I suppose
[15:32] <pedronis> and things get confused
[15:33] <pedronis> wondering why it doesn't affect other systems though
[15:33] <zyga> I'll get to the bottom of this
[15:33] <zyga> but I need to do an errand now
[15:33] <zyga> but it's paying off
[15:33] <pedronis> ah, no
[15:33] <pedronis> this is core16
[15:33] <pedronis> but is saying /snapd
[15:33] <pedronis> ??
[15:33] <zyga> ha
[15:33] <zyga> I have a hunch :D
[15:33] <zyga> let's see if the log has this
[15:34] <pedronis> we do have a core16->core18 test
[15:34] <pedronis> maybe
[15:34] <pedronis> and leaving stuff around?
[15:34] <zyga> I bet it's something like that
[15:34] <pedronis> anyway I suspect we don't quite the right thing with the user services
[15:34] <pedronis> and cleanup / restore
[15:34] <zyga> google:ubuntu-core-16-64:tests/core/reboot google:ubuntu-core-16-64:tests/core/remodel google:ubuntu-core-16-64:tests/core/os-release google:ubuntu-core-16-64:tests/core/apt google:ubuntu-core-16-64:tests/core/network-config:system google:ubuntu-core-16-64:tests/core/snap-auto-import-asserts google:ubuntu-core-16-64:tests/core/swapfiles google:ubuntu-core-16-64:tests/core/writablepaths
[15:34] <zyga> google:ubuntu-core-16-64:tests/core/device-reg google:ubuntu-core-16-64:tests/core/snap-core-fixup google:ubuntu-core-16-64:tests/core/grub-no-unpacked-assets:vmlinuz google:ubuntu-core-16-64:tests/core/snap-set-core-config google:ubuntu-core-16-64:tests/core/grub-no-unpacked-assets:initrdimg google:ubuntu-core-16-64:tests/core/create-user-2 google:ubuntu-core-16-64:tests/core/services
[15:34] <zyga> google:ubuntu-core-16-64:tests/core/gadget-config-defaults:ssh_oneline google:ubuntu-core-16-64:tests/core/classic-snap16 google:ubuntu-core-16-64:tests/core/gadget-config-defaults:rsyslog google:ubuntu-core-16-64:tests/core/snapd-failover google:ubuntu-core-16-64:tests/core/gadget-update-pc google:ubuntu-core-16-64:tests/regression/lp-1599891 google:ubuntu-core-16-64:tests/main/snap-services
[15:34] <zyga> google:ubuntu-core-16-64:tests/main/system-usernames-illegal google:ubuntu-core-16-64:tests/main/interfaces-personal-files google:ubuntu-core-16-64:tests/main/services-snapctl google:ubuntu-core-16-64:tests/main/security-dev-input-event-denied google:ubuntu-core-16-64:tests/main/install-remove-multi google:ubuntu-core-16-64:tests/main/auto-aliases google:ubuntu-core-16-64:tests/main/interfaces-content-mkdir-writable:common
[15:34] <zyga> google:ubuntu-core-16-64:tests/main/snap-user-service-start-on-install + echo '# free space'
[15:35] <zyga> there's the snapd failover test
[15:36] <zyga> prime candidate :)
[15:37] <zyga> pedronis: looking at the failover  test I don't see what removes snapd actually, perhaps it assumes some global cleanup
[15:37] <zyga> I'll look
[15:37] <zyga> but _after_ an errand, I'll be late soon
[15:37] <mborzecki> cmatsuoka: this is so weird, https://paste.ubuntu.com/p/kB7QyDMmrx/ can't trigger this when i remove the firmware from the kernel snap, same when i pass dangerous systemd.debug-shell=1
[15:38] <pedronis> well, we assume globabl cleanups but probably they don't do the right thin about this services
[15:38] <pedronis> *these
[15:38] <zyga> I'm not entirely sure this is really that, it's just a command that fails to find an executable,
[15:38] <zyga> but we'll find out once we look closer
[15:39] <pedronis> well it's wrong service file content
[15:39] <pedronis> for UC16
[15:41] <cachio> pedronis, do you know is there is a publis user assertion for uc20 beta images?
[15:41] <zyga> pedronis: but the service file is fixed
[15:41] <zyga> pedronis: it's just /usr/bin/snap userd --agent
[15:45] <pedronis> zyga: that's not what the log says
[15:45] <pedronis> or the .in
[15:45] <zyga> can you explain?
[15:45] <zyga> what does the .in file say?
[15:46] <pedronis> ExecStart=/snap/snapd/x1/usr/bin/snap userd --agent
[15:46] <pedronis> @bindir@/snap userd --agent
[15:46] <zyga> that's from the log, I wonder if that's actually true (the first line)
[15:46] <zyga> I don't recall us rewriting those units
[15:46] <zyga> but maybe I'm mistaken
[15:47] <pedronis> we rewrite them for 18
[15:47] <pedronis> that's why as I said I suspect an interaction between testing snapd on UC16 vs cleanup
[15:47] <pedronis> logic
[15:47] <pedronis> but I might be off
[15:48] <zyga> mmm, I see, I grepped for the snapd.session-agent but I didn't find anything in snapd proper, looking at the test code
[15:48] <zyga> anyway, it's much more closer to the light now :)
[15:49] <pedronis> it's the code in wrappers/core18.go
[15:49] <pedronis> it's very indirect so it's not easy to grep
[15:49] <pedronis> I think
[15:49] <zyga> ah, I see it now
[15:49] <zyga> writeSnapdUserServicesOnCore
[15:49] <pedronis> yes
[15:49] <zyga> yeah, it's cleary this
[15:50] <zyga> this makes me wonder why it got stale, perhap the code is just naive and is happy with any file it finds
[15:50] <pedronis> I'm not sure we undo
[15:50] <pedronis> except via the general cleanup
[15:50] <pedronis> restore
[15:50] <pedronis> but as I said I'm not sure that code
[15:50] <pedronis> does things with this files
[15:51] <mup> PR snapd#8641 closed: tests: improve debugging of user session agent tests <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8641>
[15:52] <pedronis> the snap-mgmt tests or something need to grow I suppose
[15:52] <zyga> oh I see
[15:52] <zyga> when we install snapd this happens
[15:52] <zyga> we don't have an equivalent call path for "but I want back to core"
[15:53] <zyga> the core in wrappers is actually pretty smart already
[15:53] <mup> PR snapd#8559 closed: boot, bootloader: adjust comments, expand tests <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8559>
[15:53] <zyga> we could fix this with an explicit test changes
[15:53] <zyga> but I suspect it's also a real bug
[15:54] <zyga> that would show up in practice
[15:54] <pedronis> yes, but I'm not sure apt purge snapd
[15:54] <pedronis> does the right thing
[15:54] <pedronis> was user services
[15:54] <pedronis> atm
[15:54] <pedronis> there's probably a real bug there
[15:55] <pedronis> *fo ruser services
[15:55] <zyga> yes, we don't consider user services
[15:55] <zyga> oh well, so many things
[15:55] <zyga> I'll run now because I'm already late
[16:04] <cachio> mvo, you said I should test pending images on cdimage for beta channel
[16:04] <cachio> mvo, I tried amd64 and didn't work
[16:04] <cachio> mvo, I should use pending images just for rpi?
[16:05] <mvo> cachio: thanks! in a meeting right now, please hop into #uc20
[16:23]  * cachio lunch
[16:23] <zyga> condensed debug data in case someone wants to figure out how we ought to fix the bug pedronis identified:
[16:23] <zyga> user session services debug data https://www.irccloud.com/pastebin/Cbp1aJFm/
[16:23] <zyga> the failover test does indeed corrupt the system
[16:23] <zyga> it's also possible that many other tests that have similar interactions behave the same way
[16:25] <zyga> rm /etc/systemd/user/snapd.session-agent.service && systemctl --user cat snapd.session-agent.service is sufficient to work around it
[16:25] <zyga> but it highlights a deeper bug
[16:25]  * zyga -> AFK
[16:43] <mup> PR snapcraft#3101 closed: package repositories: avoid setting up on host when not the target <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3101>
[17:02] <cachio> zyga, hey
[17:02] <mup> PR snapd#8642 closed: tests: add dbus-user-session to bionic and reorder package names <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8642>
[17:04] <cachio> zyga, once you have the fix for the mount ns test I'll promote the failing image
[17:04] <cachio> zyga, I mean I'll promote the bionic image which fails running mount-ns test
[17:11] <mup> PR snapd#8613 closed: o/configcore: pass extra options to FileSystemOnlyApply <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8613>
[17:34] <mup> PR snapcraft#3113 closed: colcon: use packages.ros.org/ros2 repository <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3113>
[17:37] <mpontillo> hi friends; I noticed today that some of my snaps are out out of date. I thought I was maybe hitting bug #1754345, but logging out and logging in again didn't fix things. any ideas? https://paste.ubuntu.com/p/prCzJTGjnZ/
[17:37] <mup> Bug #1754345: Returns "invalid credentials" error while trying to refresh an invalid macaroon <snapd:Triaged by chipaca> <https://launchpad.net/bugs/1754345>
[19:28] <mup> PR snapd#8644 opened: cmd/snap-bootstrap/initramfs-mounts: append uuid to ubuntu-data when decrypting <UC20> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8644>
[19:55] <mup> PR snapd#8645 opened: secboot: append uuid to ubuntu-data when decrypting <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8645>
[19:58] <mup> PR snapcraft#3114 opened: npm v2 plugin: update doc string <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3114>
[20:58] <mup> PR snapcraft#3112 closed: spread: remove dead code for lxd setup and add debug prints <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3112>
[22:52] <mup> PR snapcraft#3115 opened: build providers: ignore missing LXD instance when cleaning project <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3115>