[04:32] <Audioburn> oi
[05:28] <Squirm> morning
[05:39] <Wraz> Is it that time allready
[05:57] <Squirm> unfortunately Wraz, It is Monday
[05:57] <Squirm> and I have stuff to do
[05:57] <Squirm> meh
[05:57] <Squirm> busy Monday
[06:01] <Kilos> morning gremble theblazehen inetpro nuvolari Squirm and others too
[06:02] <theblazehen> Hi Kilos
[06:18] <ThatGraemeGuy> mornings
[06:20] <Kilos> hi ThatGraemeGuy \
[06:20] <Kilos> without the \ too
[06:34] <Squirm> hey Kilos
[06:41] <Kilos> haha theblazehen what happened to your testimonial?
[06:41] <Kilos> morning superfly
[06:49] <theblazehen> Kilos: ai.. Need to do it still
[06:50] <Kilos> lol
[06:50]  * theblazehen is liking the look of rust
[06:51] <theblazehen> but not the lack of crypto libraries
[06:51] <theblazehen> Kilos: logged in, but can't edit..
[06:59] <Kilos> oi
[07:00] <Kilos> what id o is , make my browser remember the login password then only go to the link and it opens with the edit option showning
[07:00] <Kilos> showing
[07:01] <Kilos> you supposed to be teaching me man
[07:08] <theblazehen> theblazehen.com/noedit.png it's not htere, and I'm logged in..
[07:11] <Kilos> ai!
[07:12] <Kilos> https://wiki.ubuntu.com/ZATeam/ReVerificationApplication2014
[07:13] <Kilos> i tick that and it shoes the page with edit option top left
[07:13] <Kilos> shows
[07:14] <Kilos> did you login after getting to the first page?
[07:16] <Kilos> my browser remembers the login stuff and when i open the link i see everything
[07:16] <Kilos> i cant get to take a screenshot
[07:16] <Kilos> hmm...
[07:18] <Kilos> where are the clever peeps when i need them
[07:19] <Kilos> i go take sheep out quick
[07:19] <superfly> hi Kilos
[07:25] <theblazehen> I think I maybe need permission to edit?
[07:25] <Kilos> as far as i know all you need is a launchpad account
[07:25] <theblazehen> eish
[07:26] <theblazehen> Maybe if I write it here, and you add it?
[07:26] <Kilos> didnt you get one yet?
[07:26] <Kilos> the launchpad account will then also show you as another member i think
[07:27]  * Kilos wonders how gremble did it
[07:32] <theblazehen> ya, I have an account
[07:33] <Kilos> then login with that account
[07:33] <theblazehen> I am logged in
[07:33] <Kilos> ~blaze.launchpad.net
[07:33] <Kilos> something like that
[07:34] <Kilos> ok then tick that more actions button
[07:34] <Kilos> i found edit there the first time i think
[07:34] <theblazehen> did, no edit for me.
[07:34] <theblazehen> But page is marked as immutable
[07:34] <Kilos> what does that do if you tick it
[07:35] <theblazehen> shows a list of stuff
[07:35] <theblazehen> but no edit
[07:35] <Kilos> eish
[07:36] <Kilos> ok ill post your testimonial for you, but would like to know why you cant get in
[07:36] <Kilos> bang on the door
[07:36] <Kilos> hit the pc
[07:36] <Kilos> sear at it
[07:36] <Kilos> swear
[07:36] <theblazehen> No hitting :(
[07:36] <theblazehen> Unless it's the crt
[07:36] <theblazehen> hit that, but not TOO hard
[07:37] <Kilos> lol
[07:38] <Kilos> ok you can mail me your testimonial
[07:38] <Kilos> dont want freenode kicking you for spam
[07:40] <theblazehen> Kilos: I'll just PM
[07:51] <theblazehen> gremble: ping
[07:58] <Kilos> haha he is lost in the house he is looking after
[07:58] <Kilos> in the old days houses looked after themselves
[08:02] <Kilos> nlsthzn: you awake?
[08:08] <Kilos> hmm... maybe at work
[08:09] <gremble> Hmm>
[08:10] <gremble> You need to log in on the wikipedia page, not just launchpad. You need to connect the two accounts
[08:11] <theblazehen> hmm..
[08:15] <Kilos> sjoe
[08:15] <gremble> There is a login button on the edit page
[08:15] <gremble> just follow that
[08:15] <theblazehen> gremble: Kilos added testimonial for me, but ty anyway
[08:16] <Kilos> theblazehen: go try it man
[08:16] <gremble> mmkay
[08:16] <theblazehen> Kilos: ok
[08:16] <Kilos> once its working then you good only
[08:16] <theblazehen> gremble: when you say wikipedia, you mean the wiki page?
[08:17] <Kilos> 2 years from now its your job to edit it all
[08:17] <Kilos> haha
[08:17] <theblazehen> Kilos: ai..
[08:17] <theblazehen> Anyone here use oVirt?
[08:17] <theblazehen> Gonna replace ESXi with it soon here
[08:18] <theblazehen> well, in 4 hours..
[10:32] <Kilos> hi TinuvaMac
[10:32] <TinuvaMac> hi how goes?
[10:59] <Kilos> good ty and you?
[10:59]  * Kilos busy making a major curry
[11:01] <theblazehen> nice Kilos :)
[11:01] <Kilos> TinuvaMac: how clever are you?
[11:02] <Kilos> see if you can add your testimonial to say why you like our community
[11:02] <gremble> theblazehen: yes, wiki, not wikipedia haha
[11:02] <Kilos> Maaz: re-evaluation
[11:02] <Maaz> Kilos: Excuse me?
[11:02] <Kilos> ai!
[11:02] <Kilos> why i always forget
[11:03] <Kilos> Maaz: re-verification
[11:03] <Maaz> https://wiki.ubuntu.com/ZATeam/ReVerificationApplication2014
[11:03] <gremble> maaz: re-verification
[11:03] <Maaz> https://wiki.ubuntu.com/ZATeam/ReVerificationApplication2014
[11:03] <gremble> :P
[11:03] <Kilos> haha
[11:03] <Kilos> TinuvaMac: ^^
[11:04] <theblazehen> Hmm. 71 people downloaded my firfox extension
[11:04] <gremble> Nice
[11:04] <gremble> What does your extension do?
[11:04] <theblazehen> gremble: opens the reddit comments for a URL
[11:04] <theblazehen> or view the comments in a sidebar
[11:04] <gremble> Oh ok, neat
[11:05] <theblazehen> dunno if they approved sidebar update yet
[11:05] <theblazehen> yeah, it's approved
[11:05] <theblazehen> I think adding "Sorry..." as the only text in the review notes made it take longer :(
[11:07] <nlsthzn> Kilos, just got home from training... what I miss?
[11:08] <Kilos> hi nlsthzn we battled with the thing again
[11:08] <Kilos> you poegaai now
[11:09] <nlsthzn> I will survive...
[11:09] <Kilos> neelsie you can look at the verify thing and if you happy ill ask maia if she wants more or if she thinks its adequate
[11:10] <Kilos> you going to have a late night on the 16th
[11:11] <Kilos> hi Private_User
[11:11] <Private_User> hi Kilos
[11:11] <theblazehen> hoi Private_User
[11:11] <theblazehen> hi *
[11:12] <Kilos> theblazehen: rev him now
[11:12] <Kilos> im tired
[11:13] <Private_User> hi theblazehen
[11:13] <Kilos> half my curry never gets to other peeps, i start eating while frying the onions and garlic
[11:13] <Private_User> lol
[11:13] <theblazehen> lol
[11:15] <Kilos> Private_User: do you have a launchpad account?
[11:17] <Kilos> oh my that frightened him away
[11:17] <theblazehen> lol
[11:36] <TinuvaMac> Kilos: I dont think I have a testimonial yet. I have tried to help here in the past, haven't asked for help yet
[11:37] <Kilos> you dont have to ask for help man, you can help others or lurk or just come for coffee
[11:39] <Kilos> i dont think gremble has asked for help yet either
[12:04] <nlsthzn> oh yes I have to send out a mail about the launchpad account :p
[12:08] <Kilos> hmm...
[12:13] <nlsthzn> done
[12:17] <Kilos> what about nlsthzn
[12:18] <Kilos> oh ya
[12:19] <Kilos> sometimes i read and understand, other times i just read
[12:20] <nlsthzn> lol
[13:03] <gremble> bropages.org
[13:03] <gremble> Pretty nice, unfortunately ruby
[13:03] <gremble> haha
[13:03] <gremble> "P
[13:03] <gremble> :P
[13:23] <theblazehen> gremble: saw that a few months ago.. Reminds me of the command line fu website
[13:32] <gremble> Learning new mathematics is hard
[13:32] <gremble> D:
[13:35] <theblazehen> https://www.debian.org/distrib/pre-installed#za TIL
[13:35] <theblazehen> gremble: oh? What you learning?
[13:37] <gremble> Lambda calculus
[13:37] <gremble> But from Church's initial paper on
[13:37] <gremble> it
[13:43] <theblazehen> That bad?
[13:49] <gremble> There is a lot of assumed understanding I suppose. I don't think he does the best job at explaining what he is doing
[14:14]  * Kilos waits for loadshedding
[14:15] <Kilos> will rather go off, drives are too expensive to mess up
[14:18] <gremble> Cheers
[14:18] <gremble> I also switched my stuff off
[14:18] <gremble> Laptop has its own power at least
[14:31] <inetpro> haha
[14:32] <inetpro> he logged off even when there's no loadshedding?
[14:32] <gremble> Yes because when the power cuts out it damages the drives
[14:33] <gremble> And it sounds like he has wonky drives already
[14:35] <inetpro> hmm... I thought I noticed @CityTshwane saying there was no more loadshedding today but looking again, can't find that tweet now
[14:35] <gremble> They said it to make everyone feel better, then quickly deleted it so that no one can hold them accountable when they switch it off later
[14:37] <gremble> ewn.co.za/2014/12/08/Load-shedding-to-continue-until-10pm
[17:01] <inetpro> good evening
[18:12] <theblazehen> hi inetpro, nice storm we having
[18:22] <gremble> o/
[18:29] <theblazehen> hi gremble
[18:32] <gremble> If any of you are in the brooklyn area, Tashas has delicious food :o
[18:33] <theblazehen> gremble: worth driving from centurion?
[18:34] <gremble> If you are going to drive here from centurion, I would rather suggest Pachas
[18:34] <gremble> They are supurb
[18:34] <gremble> One of those family owned restaurants where the chef sends salads that are complimentory
[18:42] <theblazehen> ah, kk, ty
[18:42] <gremble> It is really one of those places where you could take your girlfriend for a special occasion
[18:42] <gremble> Where you don't have to pay through your ass
[18:43] <theblazehen> ah, nice
[18:45] <Kilos> evening all.
[18:46] <gremble> Hey Kilos
[18:47] <Kilos> whats news here gremble ?
[18:48] <Kilos> i been offline for hours
[18:48] <Kilos> at least its raining softly
[18:48] <gremble> Nothing much. I was out, took my mother and
[18:48] <gremble>  \sister out for dinner
[18:48] <gremble> Sorry
[18:48] <gremble> Fightin
[18:48] <Kilos> good man
[18:48] <gremble> G WITH THE CAT
[18:49] <Kilos> sjoe i wont say anything
[18:49]  * Kilos not a cat fan
[18:49] <gremble> Why? you should like them on the farm, they keep rats and snakes away
[18:50] <Kilos> they do nothing but meow for food
[18:50] <Kilos> they killed many of my racing pigeons back then and im allergic to them and their flees
[18:51] <Kilos> we have one that lives outside, and catches the odd dove but rats are like hard work for it
[18:52] <Kilos> and we got snakes that steal fowls eggs regularly
[18:52] <Kilos> rhinkals
[18:52] <Kilos> hmm...
[18:52] <Kilos> spitting cobra
[18:52] <Kilos> rinkhals
[18:52] <Kilos> hmm...
[18:53] <gremble> Rinkhals is not actually a cobra
[18:53] <gremble> Pretty cool
[18:53] <Kilos> hmm... you sure its not called a spitting cobra
[18:55] <gremble> If it is brown, it is a mozambiquan spitting cobra
[18:55] <gremble> If it is black with white stripes around its neck, it is a rinkhals
[18:55] <gremble> A rinkhals has a smaller hood, it is usually called a psuedo-hood
[18:56] <Kilos> im sure they kinda yellow
[18:56] <Kilos> im looking if i can find them online
[18:56] <gremble> oh, then you have something else
[18:56] <gremble> ;o
[18:56] <Kilos> big hoods
[18:56] <Kilos> killed one 2 metres long here already
[18:57] <gremble> Saw a Night adder here a couple of years ago
[18:57] <gremble> I wanted it so badly, but I was too fatigued to handle it, so I just let it fo
[18:57] <gremble> go*
[18:57] <Kilos> sjoe, what you want to do with it?
[18:58] <gremble> Feed it and love it :P
[18:58] <Kilos> snakes are only good to sell to snake parks or to stomp their heads in
[18:58] <Kilos> eeeek
[18:59] <Kilos> me needs to go ask sis what colour they are here
[19:00] <Kilos> she says one was near black with the ring and others were golden cobras
[19:00] <Kilos> she just asked what did south africa use before candles
[19:00] <gremble> :P
[19:00] <Kilos> electricity
[19:03] <Kilos> how do you love a snake gremble ?
[19:03] <Kilos> sjoe
[19:03] <gremble> Depending on how venomous it is, very carefully
[19:03] <Kilos> adog or cat you can hug even
[19:04] <Kilos> hahaha
[19:04] <Kilos> ya here the one http://en.wikipedia.org/wiki/Rinkhals
[19:05] <gremble> Yup, called a spitting cobra, but not actually a cobra
[19:05] <gremble> :P
[19:05] <Kilos> ah
[19:05] <gremble> I'm trying to find that golden one that you mentioned
[19:06] <Kilos> im looking too . sis remembers these things
[19:06] <Kilos> hi magespawn
[19:06] <magespawn> hi Kilos
[19:07] <gremble> Kilos: en.wikipedia.org/wiki/Mozambique_spitting_cobra Did it look like that?
[19:09] <Kilos> she says the cape cobra is what we had here
[19:10] <Kilos> http://en.wikipedia.org/wiki/Cape_cobra
[19:11] <Kilos> dunno where she got the name golden cobra from
[19:11] <magespawn> it would unusual for a Mfezi to up there Kilos
[19:11] <gremble> It would be very unusual for the cape cobra to be there
[19:11] <gremble> Would be worthwile to catch
[19:11] <Kilos> oh now i remember  something, the pro also found a snake that wasnt supposed to be up here
[19:12] <Kilos> could have been escaped from some snake place
[19:12] <Kilos> so must i catch the next snake i see?
[19:13] <gremble> Only if it is a cape cobra
[19:13] <gremble> :P
[19:13] <Kilos> and you come fetch
[19:13] <gremble> I will come get it
[19:14] <Kilos> i think there was some probs at a snake park just west of us here that lost a lot of snakes
[19:14] <Kilos> maybe thew pro remembers
[19:14] <gremble> I haven't been at that park since it opened
[19:14] <gremble> Was just there once before
[19:19] <Private_User> evening people
[19:19] <Kilos> hi Private_User
[19:19] <Private_User> hi Kilos
[19:19] <Private_User> quick question how do you check the amount of memory a machine has in ubuntu?
[19:20] <Kilos> hmm...
[19:20] <Private_User> sorry I was lazy to search on the net, its a friend of mine who wanted to know
[19:20] <Kilos> i dunno right now but dmidecode will tell you about everything
[19:21] <Kilos> not sure if it shows ram too
[19:21] <Private_User> so just type dmidecode at the terminal?
[19:21] <Kilos> but you can see ram when booting
[19:21] <Kilos> ya type in then read spanne stuff
[19:22] <gremble> You can use free
[19:22] <gremble> or htop
[19:22] <theblazehen> Private_User: free -h
[19:22] <gremble> or... some others I think
[19:22] <gremble> :P
[19:22] <gremble> top also works
[19:22] <Kilos> there Private_User
[19:22] <Private_User> thanks
[19:22] <Private_User> thanks gremble, theblazehen, Kilos
[19:22] <Private_User> let us try that
[19:22] <theblazehen> yw
[19:22] <Kilos> lol
[19:23] <gremble> np
[19:23] <gremble> Now go write a testimonail about how super helpful we are
[19:23] <gremble> testimonial even
[19:23] <Kilos> oh ya
[19:23] <gremble> maaz: re-verification
[19:23] <Maaz> https://wiki.ubuntu.com/ZATeam/ReVerificationApplication2014
[19:23] <gremble> there ^
[19:23] <gremble> :P
[19:23] <Kilos> Private_User, go
[19:23] <Private_User> ok maybe I will
[19:23] <theblazehen> remove the maybe
[19:24] <Kilos> no maybe man do it. it we fail this channel closes
[19:24] <Private_User> just a question I am typing these things exactly as you guys give it?
[19:24] <theblazehen> Kilos: ouch.. /me missed that detail :(
[19:24] <gremble> Yes Private_User
[19:24] <Private_User> ok Kilos, I will
[19:24] <Private_User> ok thanks gremble
[19:24] <gremble> The channel won't close >.>
[19:24] <theblazehen> Can't we just refuse to leave the channel?
[19:24] <gremble> We just won't get free CD's
[19:24] <gremble> :P
[19:24] <theblazehen> ah, good, ty gremble
[19:25] <Private_User> ah do you guys have to do this verification every year?
[19:25] <gremble> I think it is every couple of years
[19:25] <gremble> But I'm new, I don't know shit
[19:25] <Kilos> sjoe ek sukkel
[19:26] <Kilos> every 2 years Private_User
[19:26] <Private_User> ah ok
[19:26] <Private_User> let me visit that link
[19:29] <gremble> testify comes from the Roman tradition to "swear on your testes"
[19:30] <gremble> Imagine they still did that in court
[19:30] <Kilos> lol
[19:33] <Kilos> inetpro, waar kruip jy weg?
[19:38] <Kilos> i go sleep now peeps. have a good evening and sleep tight
[19:44] <magespawn> good night all
[19:48] <inetpro> kilo[tab]: hier's ek
[19:48] <inetpro> good evening
[19:59] <theblazehen> Hi inetpro
[19:59] <inetpro> hi theblazehen


[00:35] <mup> PR pc-amd64-gadget#22 closed: Store changes <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/22>
[00:39] <ogra> hrm
[00:41] <ogra> why does the home interface not allow me to read data produced by one snap via the other in a ~/snap/<snapname>/current/ subdir
[00:41] <ogra> ogra@acheron:~/snap/arduino-mhall119/current/Arduino/test$ esptool -cp /dev/ttyUSB0 -cd none -ca 0x40000 -cf test.ino.generic.bin
[00:41] <ogra> produces :
[00:41] <ogra> Nov 05 01:39:38 acheron audit[4633]: AVC apparmor="DENIED" operation="open" profile="snap.esptool.esptool" name="/home/ogra/snap/arduino-mhall119/5/Arduino/test/test.ino.generic.bin" pid=4633 comm="esptool" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[00:42] <ogra> funnily enough i can copy the file to ~/ and am allowed to open it
[00:42] <ogra> i'd have thought he home interface allows this ?
[06:06] <zyga> ogra: that is by design
[06:06] <zyga> Snaps cannot read each other’s data
[06:15] <mborzecki> morning
[06:16] <mup> PR snapd#7718 closed: sandbox/seccomp: accept build ID generated by Go toolchain <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7718>
[06:27] <zyga> hey mborzecki
[06:27] <mborzecki> zyga: hey hey
[06:27] <zyga> mborzecki: we should talk today
[06:28] <zyga> mborzecki: about how to salvage app tracking
[06:33] <mborzecki> zyga: do we need mvo for this discussion too?
[06:33] <zyga> mborzecki: we can split the call into more technical and more strategic parts
[06:33] <zyga> mborzecki: in this sense we can discuss without him
[06:37] <zyga> mborzecki: let's try to have a call in an hour or so
[06:37] <zyga> mborzecki: I have one idea for a frankenstein that might owrk
[06:37] <zyga> mborzecki: but it's all terrible
[07:29] <zyga> how can I remove this *** tracker
[07:29] <zyga> it spawns every few seconds logging stuff
[07:30] <mborzecki> zyga: what tracker?
[07:30] <zyga> Started Tracker metadata database store and lookup manager.
[07:30] <zyga> this shows up every few seconds
[07:30] <zyga> it is a systemd unit in the user session
[07:30] <zyga> tried disabling it
[07:30] <zyga> doesn't hel
[07:30] <zyga> help
[07:30] <zyga> disabled search in gnome
[07:30] <zyga> removing it would remove half of ubuntu
[07:31] <mborzecki> zyga: try the tracker command, `tracker daemon <something>` iirc
[07:31] <mborzecki> hm didn't know it's already hooked up as user service
[07:32] <zyga> thanks, let's see if that helps
[07:59]  * zyga break
[08:10] <pstolowski> morning
[08:19] <mborzecki> pstolowski: mvo: hey
[08:19] <mborzecki> mvo: https://github.com/snapcore/snapd/pull/7665 is green
[08:19] <mup> PR #7665:  devicestate: add support for gadget->gadget remodel  <Priority 🏇> <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>
[08:20] <mvo> mborzecki: yes, I just looked at this and thats great
[08:20] <mvo> it just needs a second review
[08:22] <mvo> pstolowski: do you think you could have a look at 7665 ?
[08:22] <pstolowski> mvo: sure
[08:24] <mvo> thank you :)
[08:25] <mborzecki> pstolowski: thanks!
[08:25] <mborzecki> mvo: in #7715 there's a check whether a base/kernel needsInstall, and otherwise it's just adding task set with link snap task, do you think we need to do the same for gadget snap?
[08:25] <mup> PR #7715: overlord: add base->base remodel undo tests and fixes <Priority 🏇> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715>
[08:27] <mvo> mborzecki: its done this way so that the bootloader is updatd
[08:27] <mvo> mborzecki: link-snap is a bit overkill actually, all we really need there is just "set-next-boot"
[08:28] <mvo> mborzecki: we may want something similar for gadget but its much less important, for bases its quite common to go e.g. core18->core20 but having core20 already installed because its used by some app snaps
[08:29] <mborzecki> mvo: ok, so maybe there's a case missing after all, iirc snapstate.Install() errors out if the snap is already installed, so a remodel back to the old one when the old gadget snap is still around could fail?
[08:34] <mvo> mborzecki: correct
[08:34] <mvo> mborzecki: I think this is not terrible, a followup is ifne
[08:34] <mborzecki> mvo: rigth, so land 7665, 7715 and then a followup using some code from 7715
[08:34] <mvo> mborzecki: its really a corner case
[08:34] <mvo> mborzecki: correct
[08:34] <mborzecki> mvo: sgtm
[08:34] <mvo> mborzecki: cool
[09:08] <zyga> re
[09:10] <Chipaca> zyga: feeling better today?
[09:10] <zyga> Chipaca: I'll feel good if we can make the feature work
[09:10] <zyga> Chipaca: last evening was grim
[09:10] <zyga> but some light at the end of the tunnel
[09:10] <Chipaca> zyga: imagine if you'd found out after implementing the whole thing
[09:14] <mborzecki> Chipaca: and merging to master ;)
[09:16] <Chipaca> mborzecki: and then steal it again!
[09:17] <Chipaca> wait no that's https://www.youtube.com/watch?v=ALZZx1xmAzg
[09:25] <mborzecki> hahah
[09:28] <Chipaca> man lubuntu is *fast*
[09:42] <mup> PR snapd#7547 closed: many: use a dedicated named cgroup hierarchy for tracking <⛔ Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7547>
[09:45] <mborzecki> mvo:  can you cherry-pick to 5995e03cf8b2e34ef4327a6419922fe49d41332f ?
[09:45] <mborzecki> mvo: to 2.42 ofc :)
[09:48] <mborzecki> mvo: looks like we're missing the release artifacts for 2.42.1
[09:53] <mvo> mborzecki: oh, right, let me fix that
[09:53] <mvo> mborzecki: cherry-picked :)
[09:53] <mborzecki> mvo: thanks!
[10:03] <mvo> mborzecki: published, sorry for that
[10:03] <mborzecki> mvo: np, i can update the arch and fedora packges now
[10:05] <mvo> ta
[10:10] <mborzecki> need to run an errand, back online in 40 or so
[10:17]  * Chipaca not feeling too good today
[10:17] <zyga> take care Chipaca
[10:17] <Chipaca> i am :) thanks
[10:18]  * dot-tobias waves
[10:22] <Chipaca> eh, might as well do this mandatory training now
[10:24] <zyga> mvo: I discussed ideas with mborzecki
[10:29] <mvo> zyga: nice
[10:29] <zyga> mvo: the idea is to use a sub-directory of whatever cgroup is assigned by systemd
[10:29] <mup> PR snapd#7659 closed: snap/snapenv: preserve XDG_RUNTIME_DIR for classic confinement <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7659>
[10:31] <mvo> zyga: oh, that will work?
[10:31] <zyga> mvo: not for notification, but we can scan /proc and find out what we need in a loop
[10:32] <Chipaca> zyga: wrt xdg thing, ask also for non-issue
[10:32] <Chipaca> zyga: otherwise nobody trying it, and everybody trying it and finding no issues, looks the same :)
[10:32] <zyga> Chipaca: pardon, I don't follow
[10:32] <zyga> Chipaca: ah
[10:32] <zyga> I see
[10:32] <zyga> +1
[10:32] <zyga> good idea
[10:35] <zyga> my mind is blank but I'll do my best to implement it
[10:35] <zyga> it's more likely to succeed than the idea from last evening
[11:07] <mborzecki> re
[11:09] <mborzecki> pstolowski: thanks for the review, i'll be addressing your comments shortly
[11:10] <pstolowski> mborzecki: np, ping me for re-review
[11:13] <mborzecki> mvo: can you also cherry pick<PHONE_NUMBER>8150c6fd796ceb974557c0e19d6085 to 2.42?
[11:15] <mvo> mborzecki: yes, done
[11:15] <mvo> mborzecki: thank you!
[11:16] <mvo> pstolowski: thanks for the review of 7665!
[11:18] <ogra> zyga, hrm ... we should really have some kind of interface to allow this ... coyping files to home first is very annoying
[11:18] <pstolowski> yw
[11:18] <mborzecki> mvo: cool, thanks!
[11:19] <zyga> ogra: it'd be somewhat tricky to make since there's a bunch of special code to make sure you cannot read /home/*/snap/ using home
[11:21] <ogra> i mean, it is the first time i hit this and i can probably mke the arduino ide store to home but it kind of hinders productivity since snaps typically point to ~/snap/snapname/current for their default paths ... and i can imagine a lot of use cases where one snap uses data created by another
[11:23] <ogra> (i.e. creating graphics with the gimp snap that i want to use in a libreoffice presentation with the libreoffice snap ... forcing people to copy around the world for that wont really make us freinds among users :) )
[11:23] <dot-tobias> zyga, mvo, jdstrand: Re: https://github.com/snapcore/snapd/pull/7655 → Thanks for the 2.42.1 candidate, I tested my snap against the new version. Does the change also cover the post-refresh hook? When I run the code that requires the Introspectable interface from a plugged app, it works fine now. But when the same code is run during post-refresh, I still get the same AppArmor denial. network-manager is plugged in top-level > hooks >
[11:23] <dot-tobias>  post-refresh > plugs, and I also added a top-level “plugs” dict with `network-manager: {}` to no avail. Holding it wrong?
[11:23] <mup> PR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>
[11:24] <zyga> dot-tobias: can you check the generated apparmor profile in /var/lib/snapd/apparmor/profiles/snap.$SNAP_NAME.hooks.post-refresh
[11:24] <zyga> and see if it has the introspection chunk
[11:24] <mvo> dot-tobias: I don't recall cherry-picking anything for post-refresh, its probably in edge only. if you tell me a git rev I can cherry pick in case we do a 2.42.2
[11:25] <zyga> mvo: it wasn't for post refresh, it was for network-manager introspection on dbus
[11:25] <mvo> dot-tobias: otherwise in the next stable release in ~4 weeks
[11:25] <zyga> mvo: I could find the patch number if you want
[11:25] <mvo> zyga: aha, sry, in any case, if anything needs cherry picking please let me know but only if its really important
[11:25] <zyga> mvo: 5bc7682f2ef572f074dd0764015358cbe139d35d
[11:25] <zyga> dot-tobias: note that it was made to only affect core
[11:26] <mvo> aha, right
[11:26] <mvo> thanks
[11:26] <mvo> well, if its really important I can cherry pick, otherwise its in 2.43 (its not clear we do a 2.42.2 at this point)
[11:26] <zyga> I didn't check if that's in a point release
[11:26] <mvo> pstolowski: while in the remodel review swing, maybe you can have a look at 7715?
[11:27] <zyga> I think it might but please check what's in the apparmor profile I mentioned first
[11:27] <mvo> pstolowski: it should be very similar in style to the gadget one you just reviewed :)
[11:30] <pstolowski> mvo: sure, will do
[11:31] <dot-tobias> zyga: https://paste.ubuntu.com/p/yJbVPHnXsX/ → apparmor profile seems to contain the necessary chunk for post-refresh. Note this is after I refreshed the snap from a local unsquashed FS via `snap try`, which had the part of its post-refresh hook disabled where Introspectable would be called.
[11:31] <zyga> dot-tobias: please don't use snap try for refresh-related hooks
[11:32] <zyga> they don't operate correctly
[11:32] <zyga> because snapd is confused by "before" and "after" being the same revision
[11:33] <dot-tobias> zyga: Testing on a Core device. Oh ok, would it suffice if I reset the snap to an older revision and then `snap try` the newer revision with the patched post-refresh hook? The older revision doesn't plug network-manager for the hook, so I don't know how to test otherwise.
[11:33] <zyga> dot-tobias: I think using snap try in testing the refresh hook is not useful
[11:33] <zyga> just snap pack the new version
[11:34] <dot-tobias> zyga: And then refresh from this local .snap file?
[11:35] <zyga> correct
[11:35] <dot-tobias> Will test, brb
[11:41] <dot-tobias> zyga: Nope, still the same AppArmor denial. I packed the modified version (changed meta/snap.yaml to include a top-level plug `network-manager: {}` and incremented version number) + installed via snap install. Relevant log entry: https://paste.ubuntu.com/p/HjC6pjcb8K/
[11:42] <zyga> dot-tobias: can you look at journalctl
[11:42] <zyga> dot-tobias: perhaps we run the hook before the profile of network-manager is updated?
[11:44] <zyga> dot-tobias: if so that would be a separate bug, which would be unfortunate
[11:46] <dot-tobias> zyga: What should I look for in journalctl specifically? When I search for the AppArmor denial, the lines above indicate that the network-manager profile *is* updated before: `Nov 05 12:37:29 localhost kernel: audit: type=1400 audit(1572953849.274:306): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.network-manager.networkmanager" pid=14712 comm="apparmor_parser"`
[11:46] <dot-tobias> (same for the other network-manager 3 profiles)
[11:57] <dot-tobias> zyga: So … I checked the AppArmor profile for NetworkManager itself and it seems that even if I plug network-manager for my post-refresh hook, the profile doesn't seem to be updated. I'll open a forum thread about this.
[11:57] <zyga> dot-tobias: re
[11:57] <zyga> sorry, watching some internal HR stuff
[11:58] <zyga> dot-tobias: so in journal - look at the *order* for the events where apparmor_parser is invoked
[11:58] <zyga> for the hook
[11:58] <zyga> and for the network-manager service
[11:58] <zyga> ok
[11:58] <zyga> looking
[11:58] <zyga> it's interesting because it says "same as current"
[11:59] <zyga> perhaps the bug is not fixed afer all
[11:59] <zyga> because network manager ought to get the permission to receive it
[12:00] <dot-tobias> no worries, appreciate all the help from your side 😊
[12:01] <dot-tobias> zyga: ^ and: I'm double-checking if I made a mistake, but what trips me up is that the Introspectable access works fine once my snap is refreshed (which only works when I disable the NM-related parts of my post-refresh hook, ofc).
[12:01] <zyga> dot-tobias: review the patch I sent for fixing this and check if there is anything that looks wrong
[12:01] <zyga> it should be symmetric
[12:06] <dot-tobias> zyga: You mean the two snippets in https://github.com/snapcore/snapd/pull/7655/files#diff-323f555eb7f1a661aaa0bea83295e4f1R297 right? I'm writing up my test procedure and results, brb
[12:06] <mup> PR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>
[12:06] <zyga> yes
[12:08] <pstolowski> Chipaca: hey, what's the status of https://bugs.launchpad.net/snapd/+bug/1660970 ?
[12:08] <mup> Bug #1660970: snap info could autocomplete against installed snaps <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1660970>
[12:09] <Chipaca> pstolowski: still in progress: snap run doesn't complete yet
[12:10] <Chipaca> pstolowski: I've got it tagged to reply in more detail when i can
[12:10] <Chipaca> pstolowski: (from zyga asking me(
[12:10] <Chipaca> ))
[12:11] <pstolowski> Chipaca: great, thanks
[12:25] <pstolowski> Chipaca: there is one other bug where zyga asked you for a status - https://bugs.launchpad.net/snapd/+bug/1750527
[12:25] <mup> Bug #1750527: dashboard does not validate text fields <review-tools:Fix Released by jdstrand> <Snapcraft:New> <snapd:In Progress by chipaca> <Snap Store:Fix Released by matiasb> <https://launchpad.net/bugs/1750527>
[12:30] <Chipaca> pstolowski: yep, also tagged
[12:30] <pstolowski> 👍
[12:33] <dot-tobias> zyga: https://paste.ubuntu.com/p/pq29pv6zK8/ → It seems to me that your hunch is right: the NetworkManager slot rule is not updated for the post-refresh hook
[12:33] <zyga> dot-tobias: that's interesting, if you disable and enable n-m (via snap disable/enable)
[12:33] <zyga> if so that's a serious bug
[12:34] <Chipaca> pstolowski: also the ellipsis in utf8 one
[12:35] <Chipaca> and the snapd on 1804 proxy settings one
[12:35] <zyga> mborzecki: question on the idea
[12:35] <zyga> mborzecki: can we use the unified hierarchy in v1
[12:35] <dot-tobias> zyga: snap disable n-m / enable n-m shows no change to the Introspectable chunks … (don't know if *that* is the serious bug or if it would update 😉 )
[12:35] <zyga> dot-tobias: that's not bad then, it's a regular bug then
[12:35] <zyga> dot-tobias: we should check why there's no snippet there though
[12:35] <zyga> one second please
[12:36] <dot-tobias> sure
[12:36] <zyga> mborzecki: the logic I have so far looks for non-v2 cgroup hierarchy that has name=systemd
[12:36] <zyga> mborzecki: but also supports the v2 nameless, controllerless one
[12:36] <zyga> but this other choice, id=0 one is always present as /sys/fs/cgroup/unified in v1 world
[12:36] <zyga> and we can put processes there
[12:37] <zyga> so... perhaps that's consistency?
[12:37] <zyga> (after all?)
[12:41] <mborzecki> zyga: id=0 (i.e. 0::/some/path) is actually v2 hierarchy
[12:41] <zyga> I know
[12:41] <mborzecki> zyga: so yeah, we can do it ;)
[12:41] <zyga> that's why I menitoned id
[12:41] <zyga> yeah
[12:41] <zyga> I will go for it
[12:41] <zyga> it's consistent and easier
[12:41] <zyga> and actually
[12:42] <mborzecki> zyga: double check on 14.04 if we still care
[12:42] <zyga> I don't know how to make use of the ID otherwise
[12:42] <zyga> the only other piece that references it is /proc/cgroups
[12:42] <mborzecki> zyga: 0 is reserved for v2 anywya
[12:42] <zyga> but from there it's hard to match to /proc/self/mountinfo
[12:42] <zyga> unless I need to match the ID to controller
[12:42] <zyga> and then consider anything with that controller viable
[12:42] <zyga> but I don't see any supporting evidence in the documentation
[12:42] <zyga> I will check 14.04 before proceeding
[12:43] <mborzecki> zyga: w8, why matching with data from /proc/self/mountinfo?
[12:43] <zyga> mborzecki: because you don't know where the cgroup is mounted
[12:43] <zyga> is might be /sys/fs/cgroup or /sys/fs/cgroup/unified
[12:43] <zyga> I know we can check for v1-v2 mode
[12:43] <zyga> but it'd be nicer if this was not so "based on assumption"
[12:44] <zyga> hmm, my nas is down (didn't power up after last power outage)
[12:44] <zyga> so my 14.04 image os off, I'll just spawn spread
[12:44] <mborzecki> zyga: duh, right
[12:45] <mborzecki> zyga: hm there's only one possible instance of v2 so just looking for mount of type cgroup2 will do
[12:45] <zyga> yes
[12:45] <zyga> that's why I want to do it
[12:45] <zyga> it's non-ambiguous
[12:45] <zyga> unlike v1
[12:45] <zyga> it also has one more property
[12:45] <zyga> we _could_ actually use the events file
[12:45] <mborzecki> haha
[12:45] <zyga> though I didn't think about how deeper yet
[12:45] <zyga> but we could
[12:45] <zyga> anyway
[12:45] <mborzecki> zyga: double check on 14.04 ;)
[12:45] <zyga> back to checking
[12:46] <zyga> I wish spread had -workers 1 or something
[12:46] <zyga> oh well
[12:46] <mborzecki> zyga: cachio's spread does
[12:46] <zyga> yeah but you know
[12:46] <zyga> ...
[12:46] <zyga> I only have one spread
[12:46] <mborzecki> spread-ng ;)
[12:48] <cachio> zyga, https://cachio.s3.amazonaws.com/spread/spread2
[12:48] <zyga> cachio: thanks!
[12:48] <zyga> cachio: any outlook for merging -workers 1 into spread?
[12:49] <cachio> zyga, you can use -workers 1 -order
[12:49] <cachio> to follow the specific order also
[12:49] <zyga> dot-tobias: let me know if you find out more please
[12:49] <zyga> cachio: right
[12:49] <cachio> zyga, there is a PR for this https://github.com/snapcore/spread/pull/79
[12:49] <mup> PR spread#79: New -workers option used to define the number of workers by system <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/79>
[12:50] <cachio> but not reviews yet
[12:50] <zyga> cachio: try pinging gustavo maybe
[12:50] <zyga> he's really receptive when pinged IMO
[12:50] <zyga> mborzecki: we're good,
[12:50] <zyga> mborzecki: 14.04 has it and it's full of stuff already (not barren)
[12:52] <dot-tobias> zyga: Will do, is there something specific I should test? Not quite sure where to start here. In any case, I'll put the tasks that post-refresh should do for my snap in a service startup; shouldn't be too much overhead to run them on each startup instead of once per refresh.
[12:52] <zyga> dot-tobias: I think the mystery is why n-m doesn't have the new snippet
[12:52] <zyga> dot-tobias: look at the patch and at the file, I don't know why it might not be present
[12:52] <zyga> maybe our assumptions are wrong somehow?
[12:55] <dot-tobias> zyga: Slightly of my depth on this (should become my motto here …) 😄 As a starter, how is ###PLUG_SECURITY_TAGS### generated in https://github.com/snapcore/snapd/pull/7655/files#diff-323f555eb7f1a661aaa0bea83295e4f1R312 ?
[12:55] <mup> PR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>
[12:56] <zyga> dot-tobias: it's generated in the line above, hidden in the diff: https://github.com/snapcore/snapd/pull/7655/files#diff-323f555eb7f1a661aaa0bea83295e4f1L480
[12:57] <zyga> that returns a string that describes the labels of all plugs connected to the slot
[12:59] <dot-tobias> I'm assuming the profile for n-m is only updated if there are new rules, and if my snap's post-refresh hook is somehow not recognized by the plugAppLabelExpr helper, it won't be included there?
[13:00] <dot-tobias> https://github.com/snapcore/snapd/blob/aebfc2b83d7ac3ec49ff6811ddf8bc8c4c93b92d/interfaces/builtin/utils.go#L73 → would plug.Apps() also return hooks?
[13:01] <zyga> dot-tobias: the profile is generated in memory and reloaded if it changes; we even reload them if they don't change for a specific reason, this is why you saw the message that profile was the same as before
[13:02] <zyga> dot-tobias: yes, that's correct
[13:02] <zyga> plug.Apps would not return hooks
[13:02] <zyga> perhaps that is the bug?!
[13:02] <zyga> that's cool
[13:02] <zyga> that's the bug IMO
[13:03] <dot-tobias> zyga: A shy “yes … maybe??” from me 😄
[13:03] <zyga> pstolowski: ^
[13:03] <zyga> dot-tobias: can you add that the the existing bug or open a new one
[13:03] <zyga> I think it's unfortunate for you but this is should be easy to address
[13:03] <zyga> but on the up side, now that it is know it can be fixed, otherwise the next release would be equally buggy
[13:04] <zyga> dot-tobias: thank you! you nailed it
[13:04] <dot-tobias> Hey, happy to help out once instead of just receiving help 😊 I'll open a new bug since this probably affects all hooks, brb
[13:06] <zyga> yes, I think a new bug is more appropriate
[13:06] <pstolowski> zyga: why should Apps return hooks too?
[13:06] <zyga> they should not
[13:07] <zyga> but the label ought to include hooks too
[13:07] <zyga> using slotAppLabelExpr is just wrong
[13:07] <zyga> it ought to say slotAppOrHookLabel(slot)
[13:07] <zyga> because why would we refuse to allow hooks to have those permissions?
[13:07] <dot-tobias> zyga: That might also explain why my connect-plug-network-manager hook kept failing with similar AppArmor denials for n-m:service, even though that's the whole point of connect-plug-* hooks 😄
[13:08] <zyga> oops /o\
[13:08] <zyga> thank you for catching that!
[13:08] <zyga> and I'm sorry for not writing a spread test
[13:08] <zyga> it would show this
[13:09] <zyga> mborzecki: offtopic, I learned to love #pragma once
[13:09] <zyga> every production toolchain supports it
[13:09] <zyga> and it's far less silly than the ifndef approach
[13:09] <zyga> no need to invent names
[13:10] <pstolowski> zyga: i see
[13:11]  * pstolowski school run, bbiab
[13:11] <dot-tobias> zyga: No worries, you people have so much on your plate with the snap ecosystem … there's always some workflow to improve, and resources are constrained. Happy to help 😊
[13:11] <zyga> dot-tobias: I'll gladly help you fix this if you want to
[13:12] <mborzecki> pstolowski: pushed fixes to https://github.com/snapcore/snapd/pull/7665
[13:12] <mup> PR #7665:  devicestate: add support for gadget->gadget remodel  <Priority 🏇> <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>
[13:12] <dot-tobias> zyga: Very much wanted, because I'd probably overlook some helper or introduce even worse bugs 😄
[13:13] <zyga> dot-tobias: expand AppLabelExpr to take a map of hooks as well
[13:13] <zyga> the rest is a consequence of that
[13:14] <zyga> adjust names of the functions to convey the fact that it is not just apps now
[13:14] <zyga> I think this bug is silly
[13:14] <zyga> it's an old design that we lifted
[13:14] <zyga> but buggily so
[13:14] <zyga> we designed it so that hooks could not have interfaces initially, not all of them
[13:14] <zyga> I think we never noticed when this restriction went away
[13:14] <zyga> that the label expression is only for apps
[13:14] <zyga> there's some tricky code in that function
[13:14] <zyga> as it tries to produce nicer output than brute force
[13:15] <zyga> my suggestion would be to cahng it so that it considers not hooks or apps
[13:15] <zyga> but just a slice of names
[13:15] <zyga> whatever they are
[13:15] <zyga> and have the names be a concatenation of app labels and hook labels
[13:15] <dot-tobias> “apps” in that context are apps + services in snapcraft lingo?
[13:16] <zyga> dot-tobias: there are no tests for appLabelExpr so I would suggest to start with that
[13:16] <mborzecki> ok, moving back home
[13:16] <zyga> just create a test that checks the label for the current code
[13:16] <zyga> dot-tobias: yes, apps are all apps, equally
[13:16] <zyga> services are just certain apps
[13:16] <zyga> dot-tobias: there is code that tests this indirectly
[13:16] <dot-tobias> zyga: Ok, I'll install go, set up snapd locally and then get back to you in a week or two 😉
[13:17] <zyga> but a direct test that generates snap.pkg.*, snap.pkg.{app1,app2} and snap.pkg.app3 as output would be good
[13:17] <zyga> as those are all the variants the current logic handles
[13:17] <zyga> dot-tobias: let us know if you need help but I think this is fairly nicely scoped
[13:18] <zyga> dot-tobias: you can build a new function, move code over from the old function, remove the old function in stages
[13:18] <dot-tobias> zyga: Will do. I have some spare time atm, so this should be a nice way to a) contribute code and b) learn something new
[13:18] <zyga> dot-tobias: this definitely affects lots of interfaces, just git grep AppLabelExpr
[13:19] <dot-tobias> zyga: Would you recommend setting things up directly on a Ubuntu host, or can I use my main macOS env to develop?
[13:19] <zyga> dot-tobias: linux is strongly recommended, you will have issues as our code has many parts that only build on linux
[13:19] <zyga> dot-tobias: personally I use vmware fusion
[13:20] <zyga> dot-tobias: as for the host, any linux will do really
[13:20] <zyga> dot-tobias: for this sort of change at least
[13:20] <dot-tobias> zyga: thought so, check. Ok, I'll start with completing the bug report 😄
[13:26] <zyga> uh
[13:26] <zyga> found an issue
[13:26] <zyga> but I'll wait for maciek
[13:31] <dot-tobias> zyga: ^ does this relate to the issue we discussed, or sth else?
[13:31] <zyga> no no
[13:31] <zyga> it's for the cgroup thing
[13:31] <dot-tobias> 👍
[13:35] <zyga> mvo: I'll run the new plan by stgraber and xnox today
[13:35] <zyga> maybe to avoid and learn from the last experience?
[13:35]  * zyga needs a break
[13:35] <zyga> see you all at the standup
[13:53] <mvo> zyga: cool, thanks for chasing this
[14:04] <xnox> mvo:  so.... model assertions
[14:05] <xnox> mvo:  $ snap known --remote model series=20 model="ubuntu-core-20-amd64" brand-id=canonical
[14:05] <mvo> xnox: in a meeting
[14:05] <xnox> tells me that none are found =)
[14:05] <mvo> xnox: right, will reply in a wee bit
[14:05] <xnox> who should i talk to, about making a core20 pc-kernel model? =)
[14:05] <xnox> ack
[14:10] <mvo> xnox: you can try https://paste.ubuntu.com/p/DpZ2c3y4h9/ ?
[14:11] <mvo> xnox: its "my" model, not the canocnial one yet
[14:11] <mvo> xnox: but I get error: cannot use gadget snap because its base "" is different from model base "core20" with that so I need to look
[14:11] <mvo> xnox: either pc is not quite right (the snap) or something else, haven't had time yet to dig (meeting)
[14:28] <xnox> mvo:  why is it series=16?
[14:28] <mvo> xnox: loooooong story
[14:28] <xnox> mvo:  would be nice to be series 20 and make that the default track
[14:29] <xnox> mvo:  why is there no snapd snap listed?
[14:29] <mvo> xnox: the "series" is about the "format" of the entire architecture of snaps
[14:29] <xnox> mvo:  how does one specify to use "edge"?
[14:29] <mvo> xnox: its implicit, I guess we could/should make it explicit though
[14:29] <mvo> xnox: ubuntu-image --channel=edge
[14:29] <mvo> xnox: that should work
[14:29] <xnox> ok
[14:30] <mvo> xnox: I got further, my image creation is now exploding that "dangerous" is not yet supported
[14:30] <xnox> mvo:  how does one create model assertions?
[14:30]  * xnox wants to play with this stuff
[14:30] <xnox> mvo:  also do we have git models committed anywhere? or is it simply in the store?
[14:31] <mvo> xnox: use https://paste.ubuntu.com/p/VfkNwGQCHK/ as input, modify brand-id and then run snap sign
[14:31] <xnox> mvo:  ack
[14:31] <mvo> xnox: there is a doc that describes this, still in a meeting so can give you only 15% of my attention
[14:31]  * xnox ponders to commit them into the pc gadget git repo, on respective branches
[14:37] <xnox> i am confused what are the magic values of like authority-id brand-id id
[14:38] <mvo> xnox: its in your account page
[14:38] <xnox> ack
[14:38] <mvo> xnox: meeting over, now you can have more attention :)
[14:38] <mvo> xnox: https://dashboard.snapcraft.io/dev/account/
[14:38] <mvo> xnox: there is the accound-id there
[14:39] <mvo> xnox: use that for brandh-id, authority-id
[14:40] <xnox> mvo:  ok, and ids on snaps? is that the unique ids of the snaps, in addition to just their name?
[14:40] <Chipaca> xnox: snap info --verbose will show you the snap id
[14:40] <mvo> xnox: correct, snap info --verbose <name> will give you those
[14:42] <xnox> mvo:  can timestamp be in the future? we should set it to 2020-04-23T20:04:00:00.0Z
[14:42] <mvo> xnox: not sure that this will work
[14:43] <xnox> mvo:  because you think hardware clocks have real time?! that's just silly.
[14:45] <xnox> mvo:  grade dangerous is invalid, no? it's called "devel"
[14:53] <mvo> xnox: that sounds slightly outdated, let me try to find where this was written down but I can point you to the code. its "unset", "secured", "signed" and "dangerous" there
[14:53] <xnox> mvo:  i find it extremly odd to use key "grade" in both model & snapcraft, with widely different meaning and values.
[14:54] <mvo> xnox: https://github.com/snapcore/snapd/blob/master/asserts/model.go#L320
[14:54] <mvo> xnox: right, unfortunately samuele is on vac, that's a topic for him
[14:54] <xnox> mvo:  then it should be called like model-grade, not just grade =/
[14:56] <xnox> mvo:  imho we should be able to build "signed" one today, no need for "dangerous"
[14:56] <mvo> xnox: yeah, if you feel strongly, please mail samuele to discuss this, I don't think its set in stone but it will get harder to change the closer we get :)
[14:57] <xnox> mvo:  also, this implies we will have two models, and two images for core20 => with and without tpm-fde? but current working assumption is that a single image can be both.
[14:58] <xnox> i.e. "signed" should be allowed to be "secured", wheres as "secured" should not be. Ie. "signed" should be a superset of "secured", and ditto "signed" and "dangerous" should be supersets of previous one.
[14:58] <xnox> i.e. it's totally fine to have "dangerous" one effectively running as "secured" if all pieces work.
[14:59] <mvo> xnox: dangerous can still have fde, it just allows to sideload stuff, or am I misunderstanding?
[14:59] <mvo> xnox: also, my next meeting starts now ./ so back to 15% of my attention for you
[14:59] <mvo> xnox: sorry!
[15:02] <roadmr> ETOOMANYMEETINGS? 🤔
[15:05] <xnox> snap sign cannot do GPG it seems.... it cannot find a key named "default" wtf?!
[15:05]  * xnox uses a smartcard
[15:09] <mborzeck1> cmatsuoka: some comments under #7687
[15:09] <mup> PR #7687: snap-bootstrap: check gadget versus disk partitions <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7687>
[15:11] <kjackal> hey snappy people, in a classic snap, when I use sudo, should i use the "sudo" binary of core?
[15:14] <xnox> kjackal:  you should simply use sudo, with PATH discovery. ie. just "sudo" not any absolute path.
[15:14] <kjackal> I see MicroK8s in Centos 8.0 and fedora 29 failing when using sudo and I am wondering if I should package sudo or use the host's, or use the core's
[15:14] <xnox> note sudo is not universal, and is not guaranteed to be installed, or usable.
[15:15] <xnox> one might be root already, then no sudo should be needed, etc.
[15:15] <kjackal> xnox: this is the error I am getting https://forum.snapcraft.io/t/pam-account-management-error/14026
[15:16] <xnox> kjackal:  some of it, looks like a broken core snap
[15:16] <kjackal> in my case sudo is available but the libraries are not in the right places (?)
[15:17] <xnox> or rather mixed up LD configuration / overrides / preloads, ie. system pam is used with libraries from a core snap, which will never work =)
[15:18] <xnox> kjackal:  i wonder if environment that snap setup for you, is interfering with using system PAM session correctly
[15:18] <zyga> Back home now
[15:20] <kjackal> xnox: I am setting some env variables here: https://github.com/ubuntu/microk8s/blob/master/microk8s-resources/wrappers/microk8s-enable.wrapper#L4 could these be a problem?
[15:20]  * cachio afk
[15:20]  * cachio lunch
[15:32] <xnox> kjackal:  yes, all of them.
[15:32] <xnox> kjackal:  these are good, for using binaries from inside the snap, but bad if one tries to dlopen system installed ones (like pam does for pam modules which dlopen things)
[15:33] <kjackal> xnox: but i am doing for example "sudo <something_in_my_snap>" so... ?
[15:34] <xnox> kjackal:  which is operating sudo itself with those environment variables in effect. which is bombing out.
[15:35] <xnox> because sudo, tries to open a pam session, as per system wide config, loads pam modules from the system-wide, yet with LD_ path pointing inside the snap which is incompatible with with system-wide libraries
[15:36] <xnox> kjackal:  store and export original path, ie. with export STOCK_PATH=$PATH ditto for STOCK LD_LIBRARY_PATH
[15:36] <xnox> kjackal:  and i expect something like this will work:
[15:36] <xnox> PATH=$STOCK_PATH LD_LIBRARY_PATH=$STOCK_LD_LIBRARY_PATH sudo PATH=$PATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH sed -i
[15:37] <xnox> kjackal:  ie. use system wide sudo, with system-wide PATH & LD_LIBRARY_PATH, but use snap paths for sed.
[15:37] <xnox> although imho one can rely on system sed too, as it's fundamental too.
[15:37] <xnox> although imho one can rely on system sed too, as it's fundamental tool.
[15:37] <kjackal> I see, will try that
[15:38] <kjackal> thank you xnox
[15:38] <xnox> kjackal:  your problem is that one cannot really create and use pam session from inside a snap, and expect it to work with the system-wide pam config. Meaning one has to use system-wide sudo
[15:38] <xnox> because all of those things use absolute paths to dlopen() libraries which all must match.
[15:39] <xnox> it "works" by magic on like Ubuntu due to e.g. snap build on xenial, and libraries staying compatible for basic things like that
[15:39] <xnox> (i.e. when host == snap abi's by accident)
[15:40] <xnox> kjackal:  also note that i have no idea what i'm talking about and i'm jsut a random person on irc who has zero idea about how snaps work =)
[15:41] <kjackal> :)
[15:43] <mborzecki> snapd in AUR has been updated to 2.42.1
[15:43]  * mvo hugs mborzecki
[15:47] <pstolowski> spread tests in #7715 and #7665 are very alike, i'm not sure who was first ;) fwtw i'm adding same comments ;)
[15:47] <mup> PR #7715: overlord: add base->base remodel undo tests and fixes <Priority 🏇> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715>
[15:47] <mup> PR #7665:  devicestate: add support for gadget->gadget remodel  <Priority 🏇> <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>
[15:51] <xnox> mvo:  error: cannot override channels, add local snaps or extra snaps with a model of grade higher than dangerous
[15:52] <xnox> mvo:  hm..... prepare-image fails..... but i'm confused about these constraints. How do I build image of a model, using edge channels? model doesn't allow to specify channel does it?
[15:52] <mvo> xnox: yeah, I hit this too, I'm looking into it
[15:52] <mvo> xnox: basicly we need to land one more PR (7712
[15:53] <mvo> xnox: then we can have a "grade: dangerous" model that allows overriding
[15:53] <mvo> xnox: I was also looking into: https://paste.ubuntu.com/p/5bhBPMvVJj/
[15:53] <mvo> xnox: but that fails with a strange error, that it can't find core20 which I think is a lie
[15:54] <pstolowski> mvo: reviewed #7715
[15:54] <mup> PR #7715: overlord: add base->base remodel undo tests and fixes <Priority 🏇> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715>
[15:54] <xnox> mvo:  hm.... i'm not sure if that's what i am hitting..... because all the snaps i'm using are acked and in store. I'm not using any unsigned, or unasserted snaps
[15:55] <mvo> xnox: you did specify --channel=edge, maybe?
[15:55] <mvo> pstolowski: cool, will look
[15:55]  * mvo needs to taxi kids around for ~30min
[15:55] <mvo> bbiab
[15:57] <xnox> for me it's fetching the wrong gadget snap!
[15:58] <zyga> re again
[15:58]  * zyga had dinner and an unexpected encounter
[15:59] <zyga> my neighbor was venting old stuff and asked me if ... I want any of his 90s games collection
[15:59] <zyga> so now I have a CD-ROM with dungeon master 2
[15:59] <zyga> and a few similar games
[15:59] <zyga> anyway
[15:59] <zyga> back to work
[15:59] <zyga> xnox: hey
[16:00] <zyga> xnox: we have an idea and before pursuing further wanted to ask you for advice
[16:00] <zyga> xnox: it is related to systemd and cgroups
[16:00] <zyga> xnox: the idea is: when snaps are invoked they put themselves into a new leaf under wherever systemd had placed them
[16:00] <zyga> xnox: in the unified v2 hierarchy
[16:01] <zyga> xnox: so for example, on<EMAIL_ADDRESS>[16:01] <zyga> xnox: or something equally appropriate for system services
[16:01] <zyga> xnox: we'd be stealing the process from systemd
[16:01] <zyga> xnox: but placing it deeper in the same hierarchy
[16:02] <zyga> xnox: casual testing shows that systemd is not confused and still manages services correctly
[16:03] <zyga> xnox: we intend to use the unified hierarchy in v2 mode, obviously, because we have no other choice
[16:03] <zyga> xnox: but also in the v1 mode
[16:03] <zyga> xnox: because it is seemingly working the same way for what we intend (associating PIDs with snaps)
[16:04] <xnox> so i have this https://bugs.launchpad.net/snapd/+bug/1851401
[16:04] <mup> Bug #1851401: snap prepare-image downloads wrong snaps <snapd:New> <https://launchpad.net/bugs/1851401>
[16:07] <xnox> zyga:  "when snaps are invoked they put themselves into a new leaf under wherever systemd had placed them"  using children, and further scoping is always safe. Moving "up" is usually either not-allowed, or is a priviledged operation. Systemd should not get confused, as long as you don't change notification agents on it. And yes it should be fine under v1/v2/hybrid. BTW why do you want to do this?
[16:07] <xnox> i.e. what are you trying to solve?
[16:07] <zyga> xnox: that's good news
[16:07] <zyga> xnox: we want this to implement a feature where snapd pauses refreshes while an app is open
[16:08] <xnox> that's insecure and abusable.
[16:08] <zyga> xnox: and can, having tried to refresh but deciding not to
[16:08] <xnox> as unpriviledged user can create those cgroups and put arbitrary processes into them.
[16:08] <zyga> xnox: then decide to refresh it reasonably fast after it was closed
[16:08] <zyga> xnox: that's ok, we have safeguards for that
[16:08] <zyga> xnox: that is, firefox running forever in a snap will eventually referesh anyway
[16:08] <zyga> *refresh
[16:09] <xnox> i.e. you could make binaries be "systemd-run actual binary" cause then pid1 will put the process into a system cgroup, which is authoritative.
[16:09] <zyga> xnox: we considered that but we don't have systemd-run across all versions we support
[16:10] <zyga> xnox: but it's also a problem there
[16:10] <zyga> xnox: because we want to have this available uniformly across all apps
[16:10] <zyga> xnox: including services
[16:10] <zyga> xnox: and using systemd-run from inside what is effectively a service file with Exec line
[16:11] <xnox> zyga:  you do have sytemd-run everywhere.... given that it's in core16
[16:11] <zyga> xnox: we are at the mercy of what systemd allows us to do here sadly, as snaps need to integrate with existing system services and be managed by systemd directly
[16:11] <xnox> zyga:  you don't need systemd-run for services, as pid1 already placed them into an authoritative cgroup
[16:11] <zyga> xnox: I think we don't have that on 14.04
[16:11] <zyga> xnox: but even then the other problem is more severe
[16:11] <zyga> xnox: "apache", "firefox" and "grep" type workloads need to be supported in this mode
[16:11] <xnox> zyga:  systemd-run is inside core snap, and on 14.04 it runs against subordinate systemd which has it.....
[16:12] <zyga> xnox: I see but core is not mandatory and it would also complicate startup, what if you install a snap with bare base on 14.04?
[16:12] <xnox> zyga:  if you only do this for "user" apps, that's fine. I.e. i don't want to hold up daemon refreshes, due to unpriviledged user controlled cgroups.
[16:13] <zyga> xnox: we want this to work uniformly for all applications but there's some smarts for services
[16:13] <xnox> i.e. somebody executing "snap --help" and freezing it, should not prevent snapd refresh for example
[16:13] <zyga> xnox: snap --help won't prevent snapd from refreshing
[16:13] <xnox> zyga:  it's insecure, thus you must have security team review / signoff on this logic.
[16:14] <zyga> xnox: can you specify what is insecure specifically
[16:14] <zyga> xnox: (we always get security review for features like that)
[16:14] <xnox> zyga: arbittrary users can create the cgroups like<EMAIL_ADDRESS>which have never been executed via snap/snapd
[16:15] <xnox> with zombie /bin/true process
[16:15] <zyga> indeed, this is true
[16:15] <zyga> xnox: at this point we ran out of ideas for things that work across the stack unfortunately
[16:16] <xnox> you could use kernel keyrign to list snap invocation_ids which is read only, to then lock that up. Cause that's what e.g. systemd-run does
[16:16] <zyga> xnox: users don't have to be nasty, they can just run the real app
[16:16] <zyga> xnox: so it is not a new problem of the feature
[16:16] <xnox> zyga:  also i challenge you on the 14.04 assertion, i believe systemd-run is available there.
[16:16] <zyga> xnox: invocation IDs?
[16:17] <xnox> systemd creates process keyring and puts a unique key there and makes it readonly and exports it as an evironment variable. Then processes can share that keyring (ie. group of services) and then they can all know that they are part of the same "reexec" for example. Kind of like a cohort key.
[16:18] <xnox> but with kernel protection that nobody can modify or fake it
[16:18] <zyga> xnox: interesting, which syscalls govern that? I'll read about it
[16:18] <zyga> xnox: and do you know if this will work inside LXD
[16:18] <zyga> xnox: as whatever we need to do needs to work in lxd across the stack
[16:18] <xnox> it does work in lxd today, but i don't remeber when it was added.
[16:18] <zyga> (we are in this situation after we realized mounting a v1 name=snapd cgroup doesn't work)
[16:18] <xnox> zyga:  why do you care about 14.04?
[16:19] <zyga> xnox: it's still supported, we cannot abandon it without some official kick
[16:19] <zyga> xnox: but I would not hold onto 14.04
[16:19] <zyga> xnox: it's just that systemd-run doesn't do what we want to AFAIK
[16:19] <xnox> zyga:  it's passed end of basic support, and excludes support for snapd in ESM
[16:19] <zyga> xnox: unless I misunderstand
[16:19] <xnox> zyga:  it's dead to you
[16:20] <xnox> and i.e. subordinate systemd is not supported there for sure.
[16:20] <zyga> xnox: I need mvo to tell me that, I asked recently and I got a different answer
[16:20] <xnox> mvo
[16:20] <xnox> not in this channel
[16:20] <zyga> it seems he is not connected now
[16:20] <zyga> xnox: but even assuming we can run systemd-run
[16:20] <zyga> xnox: can you outline how we could use that to identify all snap execution entry points?
[16:21] <zyga> that is, all apps, hooks and services
[16:21] <zyga> so that when scanning PIDs
[16:21] <zyga> we can see where they came from
[16:21] <xnox> zyga:  and 14.04 is very unconfined, as far as i understand. i.e. most interesting interfaces are not supported on 14.04 anyway.
[16:21] <zyga> xnox: I think actually only fuse is not, everything else is not special cased on 14.04
[16:21] <zyga> it's not supported for desktop apps but that is all
[16:22] <xnox> vorlon:  what's status of supporting snapd on 14.04? i thought it's dead and not part of ESM.
[16:23] <zyga> xnox: so would snap-run invoke systemd-run which would invoke snap-confine and then snap-exec?
[16:23] <vorlon> xnox: I don't know why you had that impression; you should look to the Security Team for a specific support statement, but I'd be surprised if snapd wasn't in scope
[16:23] <zyga> I suspect that the nature of ESM is that it's too soon to say something is not supported
[16:24] <zyga> the policy in snapd team, for now, as far as I know, is that 14.04 is still a target
[16:24] <xnox> zyga:  imho that call chain "makes sense" but potentially breaks a lot of desktop integration, unless one is careful to do --user / --system for the systemd-run bit.
[16:24] <zyga> and we are not introducing features that don't support it
[16:25] <zyga> xnox: can you walk me through the operations of systemd-run, what do we get by using it and how should we invoke it?
[16:25] <xnox> zyga:  i'm very busy, and i've spend too much time talking to you already. So no, i don't. plese read man pages for systemd-run, they have a lot of details.
[16:26] <zyga> xnox: I will, thank you for the advice and for the discussion, it's very useful
[16:27] <zyga> xnox: I don't think we can use systemd-run
[16:27] <zyga> xnox: based on the man page itself
[16:27] <xnox> vorlon:  zyga: snapd is explicitely called out as an exclusion for 14.04 ESM that's where i got this impression from https://wiki.ubuntu.com/SecurityTeam/ESM/14.04#Exclusions
[16:27] <zyga> xnox: but we should be able to use the cgroup sub-directort leaf
[16:28] <xnox> zyga:  it starts an invocation, as a dynamic .service unit. meaning one can query it with systemctl list-units snapd-execs.* for example
[16:28] <xnox> and it can like prevent user from having two copies of the thing running in parallel, etc.
[16:29] <zyga> yes, but it doesn't give me a way to run a classic snap this way, e.g. a classic installation of python, to get interactive pty
[16:29] <vorlon> xnox: well, if it's published as an exclusion, there's your answer :-)
[16:29] <zyga> it needs to support all the kinds of interactions snap apps support: desktop apps, services and all the command line stuff, including classic snaps
[16:29] <xnox> mostly useful to start "dynamic" things but monitored, i.e. executing user-written hooks, which can be arbitrary long, with journald logging, confiment, etc.
[16:30] <xnox> it does break the scope & confiment, even basic things like "what is my stdin"
[16:30] <zyga> yeah, so while we could use it for services, for services arguably systemd is already giving us all of that already
[16:30] <zyga> I think it will also be a less invasive change
[16:30] <zyga> I'm very curious about the keyring operation
[16:30] <zyga> as that seems like a way out of the too-easy-to-spoof problem
[16:31] <xnox> zyga:  start with keyctl manpage about kernel keyring, and invocation_id stuff inside systemd
[16:31] <zyga> though it doesn't really solve the problem as you can just run the real thing (real snap app) and not close it for the same effect
[16:32] <zyga> it seems like a potentially interesting replacement for the snap cookie concept though
[16:32] <zyga> but I need to read on it more now
[16:32]  * zyga hugs xnox
[16:32] <zyga> thank you :)
[16:40]  * cachio afk
[16:55]  * ijohnson hugs zyga after reading backlog
[16:55] <zyga> ijohnson: what specifically? :
[16:55] <zyga> :)
[16:55] <ijohnson> the many changes to refresh awareness, sounds like quite a rollercoaster
[16:55] <zyga> ijohnson: the only question is
[16:56] <zyga> ijohnson: is it still going up or are we already going down? ;)
[16:56] <zyga> but yeah, it's quite a feature
[16:56] <ijohnson> haha :-)
[16:57]  * ijohnson is not really around today, still in Arizona for meetings
[16:57]  * ogra waits for the time where the snapd snap is bigger than his kernel snaps on core images
[16:58]  * ijohnson quietly shoves edgex snap inside snapd to get ogra to stop waiting
[16:58] <ogra> haha
[16:59] <ogra> ijohnson, reading that ... we'll need to talk about edgex before EOM ... (got another exhibition and we want to shw edgex finally)
[16:59] <ogra> the setup doc we have seems outdated
[16:59] <ijohnson> sure that doc is probably out of date, but let's try to keep Tony and Don in the loop too
[16:59] <ijohnson> ogra: when is your exhibition?
[17:00] <ogra> last week of nov.
[17:00] <ogra> (i think at least ... /me checks)
[17:01] <ogra> yeah, 26 to 28 https://sps.mesago.com/nuernberg/en.html
[17:05] <ijohnson> ogra: ack are you going to be in vancouver next week for the sprint?
[17:11] <zyga> ogra: we will link everything into one binary so that it can stay at comfortable 20MBs forever
[17:11] <zyga> mvo: heye
[17:11] <zyga> mvo: you missed some nice discussion about systemd stuff with xnox
[17:12] <zyga> mvo: I think I will wrap it for today
[17:12] <zyga> mvo: the big takeaway is that xnox effectively confirmed that the idea from Maciek is workable
[17:12] <zyga> mvo: he also raised a number of important points for us to discuss
[17:12] <zyga> mvo: but I will try to propose the branch implementing this tomorrow
[17:13] <xnox> mvo:  everything is broken and nothing works, but i made progress!
[17:14] <mvo> hey zyga
[17:14] <zyga> mvo: hey :)
[17:15] <mvo> xnox: ha!
[17:15] <mvo> zyga: cool
[17:15] <mvo> xnox: I think we have a bug in the core20 getting
[17:15] <mvo> xnox: what kind of progress did you made?
[17:16] <mvo> xnox: the pending PR#7712 should make everything easier, I will review it tomorrow morning
[17:22] <xnox> mvo:  see email from me. if that PR helps that's great, will try that if/when it's available to me in a track/grade/branch to me
[17:22] <xnox> mvo:  some things i can work around with, by like passing locally downloaded snaps etc. but other things seem broken - i.e. ubuntu-image doesn't do anything for me.
[17:23] <mvo> xnox: aha, nice
[17:23] <mvo> xnox: got the mail now
[17:23] <xnox> mvo:  and i question some design choices in the model assertion, which i guess i need to type up and send.
[17:31] <zyga> I'm wrapping up
[17:32] <ogra> ijohnson, no vancouver for me ...
[17:32] <ijohnson> ogra: cool maybe we could setup a hangout early next week then
[17:33] <ogra> yeah, that sounds fine
[17:59] <Chipaca> ok, EOD for me
[17:59] <Chipaca> 👋
[18:48] <mup> PR snapd#7720 opened: asserts: add "snapd" type to valid types in the model assertion <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7720>
[21:04] <mup> PR snapcraft#2792 opened: pluginhandler: use well-formed build package/snap lists <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2792>
[21:10] <mup> PR snapcraft#2793 opened: tests: enable SNAPCRAFT_BUILD_INFO for spread <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2793>


[00:51] <spiv> Gar, gnome-terminal just crashed.
[00:52] <spiv> Hmm, an assertion error from vte in xsession-errors.
[00:55] <mwhudson> ow
[01:50] <chmac> `bzr branch lp:~vcs-imports/wordpress/2.9 wp29`, `cd wp29`, `bzr up` tells me the repository is at 11084, but there are new revisions in launchpad that it's not pulling down.
[01:50] <chmac> I'm guessing I've misunderstood how branching / updating works. Any pointers?
[01:50] <chmac> Hmm, maybe I need to merge...
[01:51] <gutworth>  bzr pull
[01:51] <chmac> gutworth: Aha, ok, thanks
[01:54] <spiv> chmac: 'bzr up' is for making a checkout of a branch up-to-date.  You did 'bzr branch', so you simply have a branch, not a checkout.
[01:54] <chmac> spiv: Thanks. I'm starting to wrap my head around those concepts... :-)
[01:54] <spiv> chmac: hence why you need to 'pull'
[03:28] <spiv> Odd, https://code.edge.launchpad.net/~johnf-inodes/bzr/serve-init/+merge/12938 hasn't been automatically marked as merged.
[03:50] <poolie> jam, i guess you're asleep?
[04:08] <poolie> feeding pqm...
 nom nom nom
[04:35] <jam> poolie: not asleep yet, just not near the machine
[04:35] <jam> poolie: what's up?
[04:45] <poolie> hi jam
[04:45] <poolie> i was just thinking about your thing of getting changes in more quickly
[04:45] <poolie> because a couple of relevant things came up today
[04:45] <poolie> one being, could we test LockDir.peek
[04:45] <poolie> and the other, should you check for existing users of the module featuers
[04:45] <poolie> features*
[04:46] <poolie> in both cases it would have some value- it's possible the test could fail, today or later
[04:46] <poolie> but it's the kind of thing that tends to change something from being 5m into an hour, or an hour into a day
[04:50] <lifeless> poolie: changing symbol names added the concern about checking for users of the symbols
[04:50] <lifeless> poolie: So its clearly possible to do a 5m thing there :)
[04:50] <poolie> ?
[04:51] <lifeless> 15:45 < poolie> and the other, should you check for existing users of the module featuers
[04:51] <poolie> so one thing could have been to take a smaller step
[04:51] <poolie> of just changing the implementation not the name
[04:54] <lifeless> yes
[11:07] <chx> hi. how cna i do a commit after a merge w the merge tips as commit message?
[11:26] <awilkins> What do you chaps use for requirements tracking? Standard issue tracker?
[11:27] <lifeless> yes
[12:32] <Solipsist> ive attempt to revert local changes using 'bzr revert' but keep getting this error message: bzr: ERROR: The file id "xxxx" is not present in the tree , what does it mean?
[12:34] <spiv> Solipsist: if you're getting that and you aren't passing any arguments to 'bzr revert' then that would be a bug I think.  Which version of bzr?
[12:35] <Solipsist> using v 2.0.3
[12:35] <Solipsist> so i deleted a directory and now i want to restore it from the local repost
[12:36] <Solipsist> being used to git, i tried bzr checkout, but that's a no go so i looked at the commands and tried bzr revert directory/, then just bzr revert
[12:36] <Solipsist> is there a page describing bzr for us used to SVN, and lately GIT?
[12:48] <spiv> Solipsist: 'bzr revert DIR' or just 'bzr revert' in a working tree are supposed to do that.
[12:48] <spiv> Solipsist: so it sounds like you've hit a bug, which is a bit surprising but not impossible.
[12:49] <spiv> Solipsist: so please do file a bug report
[12:51] <Solipsist> ok, but filing a bug won't help me much right now, so what can i do to remedy this?
[12:52] <Solipsist> i have no changes i wish to keep so i could throw away the working tree and restore it from the local repos ive created, the local repos has been updated from the remote with bzr pull
[12:57] <Solipsist> i guess this whole bazaar concept of a branch confuses me, if i understand it correctly a branch is an actual filesystem directory structure?
[12:58] <Solipsist> as im sure yoy know in GIT and CVS, a branch is a meta concept and two branches can be the exact same directory structure and you can switch between them without having to have separate sets of directories for each branch, it seems more natural to me
[12:58] <ronny> currently yes
[12:58] <Solipsist> currently?
[12:59] <Solipsist> so i want to checkout the branch from my local repos?
[12:59] <ronny> Solipsist: i overheard that git style branching is on the way
[13:00] <Solipsist> that would be very welcome :)
[13:00] <Solipsist> anyhow, i got a directory with a .bzr directory and a set of subdirectories, i want to restore the files in the subdirectories to those in the local repos
[13:00] <Solipsist> so i type bzr checkout
[13:00] <ronny> its bzr revert
[13:00] <ronny> bzr revert reverts the workdir state
[13:01] <ronny> bzr checkout makes a new workdir from a branch of any location
[13:01] <Solipsist> ronny: look above, bzr revert throws an error
[13:02] <ronny> cna you paste the complete output of bzr revert, also use the -v parameter to get it more verbose
[13:03] <Solipsist> ronny: preferably not in a public channel, can i query you?
[13:04] <ronny> i'd prefer here since im not sure if i can help
[13:04] <ronny> well, make a private paste on paste.pocoo.org to begin with
[13:04] <Solipsist> ronny: i appreciate the offer but i cant post it publicly, plus it's bad manners pasting a lot of text in an IRC channel
[13:05] <ronny> Solipsist: start by making a private paste on paste.pocoo.org
[13:48] <Solipsist> bzr seems to have issues with special characters in filenames when dealing with different file systems, HFS+ on this machine and ext3 on the machines of the other committers
[14:03] <ronny> Solipsist: sounds like a unicode normalisation issue
[14:07] <Solipsist> perhaps, never had the same issue with git
[15:26] <mangerduchien> hi all
[15:29] <mangerduchien> I am facing a problem with bazaar and proxy. I am using Ubuntu Karmic Koala (9.10) with bazaar version 2.0.2 and I configured my environment with http_proxy="myproxy". However bazaar do not take the proxy into account
[15:29] <mangerduchien> Does anyone could help me ?
[15:34] <Pilky> Am I right in thinking that bzr ships with Ubuntu by default?
[15:36] <beuno> Pilky, it is not
[15:37] <beuno> it's in main, but not included in the default install
[15:37] <Pilky> right
[15:37] <mangerduchien> bzr is in Ubuntu repository and the last version is 2.0.0. I was having the same problem with this version so I installed 2.0.2 that can be found on https://launchpad.net/bzr/2.0
[15:38] <mangerduchien> but nothing changed
[15:42] <jam> morning all
[15:43] <mangerduchien> morning
[15:51] <jam> mangerduchien: generally, we respect http_proxy, are you sure you 'export'ed it appropriately?
[15:52] <jam> also, there is a bug in resolving lp: urls
[15:52] <jam> that is only fixed in the 2.1 series
[15:52] <jam> (xmlrpc needed custom code to handle proxies)
[15:52] <mangerduchien> i am facing the lp: url problem
[15:52] <mangerduchien> i have to use bazaar 2.1 ?*
[15:52] <jam> 2.1.0b4 will fix it for you, but I don't think it is packaged
[15:53] <jam> mangerduchien: well, the quick fix is to use "http://bazaar.launchpad.net/...." or "https://code.launchpad.net/..."
[15:53] <jam> the latter redirects to the former
[15:53] <jam> but lets you use  the short form
[15:53] <jam> so I tihnk
[15:53] <jam> bzr branch https://code.launchpad.net/foo
[15:53] <jam> will evaluate to the same as
[15:53] <jam> bzr branch lp:foo
[15:53] <mangerduchien> i am trying to get : lp:~launchpad-pqm/launchpad/devel
[15:54] <jam> mangerduchien: bzr branch http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel
[15:54] <jam> or bzr branch bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel
[15:54] <mangerduchien> ok thanks, i'll try
[15:54] <jam> if you have registered an ssh key
[15:54] <jam> the latter should be faster
[15:55] <mangerduchien> ok, it seems to work
[15:55] <mangerduchien> thank you  very much
[15:58] <jelmer> hi jam, mangerduchien
[15:58] <mangerduchien> hi jelmer
[20:09] <Davidbrcz> Hi all
[20:09] <Davidbrcz> i'm a noob with bazaar
[20:09] <Davidbrcz> i want to extract a spefic version of a project
[20:09] <Davidbrcz> but i've not found in the doc a way do to it
[20:10] <Davidbrcz> someone could help me ?
[20:14] <mwhudson> Davidbrcz: bzr branch -r $revsion trunk old-version will work
[20:16] <Davidbrcz> mwhudson, hum
[20:16] <Davidbrcz> strange error
[20:17] <Davidbrcz> i want to extract the first revision of this http://bazaar.launchpad.net/~sean-pringle/musca/dev/files
[20:17] <Davidbrcz> i'v created a folder
[20:17] <Davidbrcz> and the i did bzr init; bzr branch http://bazaar.launchpad.net/~sean-pringle/musca/dev/files
[20:17] <Davidbrcz> but the second command gives me an error
[20:17] <mwhudson> oh
[20:18] <mwhudson> right, you want to do bzr branch http://bazaar.launchpad.net/~sean-pringle/musca/dev
[20:18] <Davidbrcz> why oh ?
[20:18] <mwhudson> not with the /files on the end
[20:18] <Davidbrcz> ok
[20:19] <Davidbrcz> i've got the current version
[20:19] <Davidbrcz> and to get the first one ?
[20:19] <Davidbrcz> hum
[20:19] <Davidbrcz> i get it
[20:19] <Davidbrcz> thx
[20:20] <Davidbrcz> :)
[21:25] <toabctl> hi. i have a question:
[21:25] <toabctl> i want to merge abzr-branch with: bzr merge --pull lp:~mhall119/loco-directory/0.2-loco-events
[21:26] <toabctl> the merge works, but when i commit i have to add the commit message and after the commit there is no message or something about mhall119, but he was the guy who made the changes.
[21:27] <toabctl> can anybody help with this problem?
[21:27] <mwhudson> toabctl: try bzr log --include-merges
[21:31] <toabctl> mwhudson, that's it. thanks a lot!
[21:32] <mwhudson> toabctl: bzr qlog (from qbzr) or bzr viz (from bzr-gtk) might be interesting too
[22:05] <wgrant> If I look at http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/gnome-chemistry-utils/lucid/revision/19, I see that there are two merges involved. If I click on one of the merges, it says that it was merged at revision 18.
[22:05] <wgrant> Is that a Loggerhead bug?
[22:13]  * beuno looks
[22:13] <beuno> wgrant, it does look like a LH bug
[22:14] <beuno> could you file it?
[22:14] <wgrant> beuno: Sure.
[22:14] <beuno> thanks
[22:14] <wgrant> I've noticed it on a couple of other branches too, so it's probably universal.
[22:15] <poolie> hello beuno, wgrant
[22:16] <wgrant> Morning poolie.
[22:16] <beuno> hey hey poolie
[22:16] <beuno> wgrant, I have a suspicion on what it could be
[22:16] <beuno> my next bug to fix is in bzr-upload, but I may tackle that one tomorrow
[22:21] <wgrant> Bug #499614
[22:21] <wgrant> Hm, not long to go now.
[22:32] <poolie> till 500k?
[22:39] <mwhudson> hm, i was sure i'd fixed that...
[22:40] <mwhudson> maybe it's time to update the loggerhead that launchpad uses
[22:41] <poolie> hi jam, spiv, igc
[22:41] <jam> hi poolie
[22:41] <poolie> thanks for the reviews
[22:43] <jam> poolie: thank *you* for doing mine :)
[22:43] <jam> poolie: small update on the "set a larger socket size for transmission"
[22:43] <jam> as near as I can tell
[22:43] <jam> ssh itself will allow up to 2MB to be written to stdin
[22:44] <jam> before it blocks
[22:44] <poolie> k
[22:44] <jam> well, at least our 'out.write()' gets to write about that much
[22:44] <jam> certainly > 1MB
[22:44] <jam> at least, after the last server side "I wrote XX bytes" I see 28 64kB reads on the local side
[22:45] <poolie> jam, regarding update -r
[22:45] <jam> and many of the writes finish in 0.000 s
[22:45] <poolie> ok that's not surprising
[22:45] <jelmer_> ooh, update -r is finally happening ? :-))
[22:45] <poolie> i think this branch is worth adding regardless of where we think it will end up
[22:46] <jam> poolie: I approved your changes
[22:46] <poolie> jelmer_: https://code.edge.launchpad.net/~mbp/bzr/45719-update-r/+merge/16476 reviews welcome
[22:46] <poolie> and hi
[22:46] <jam> certainly it shouldn't block on internal disagreement, which I think blocked it so far
[22:46] <jam> which is a bit silly
[22:46] <poolie> you're definitely coming to vila's villa?
[22:47] <jam> wow... fetching in 'groupcompress' order generated 70.5MB, vs 50MB fetching in 'unordered' ...
[22:48] <jam> poolie: are you sure Calvin Rose's email isn't spam :)
[22:49] <poolie> jam: i had to moderate it too
[22:49] <poolie> which was a bit sad
[22:49] <poolie> i did wonder
[22:49] <jam> poolie: I realized you moderated it from the timestamp, which is why I brought it up
[22:51] <poolie> jelmer, do you have any idea based on knowledge of cifs why in bug 498378, after renaming a directory, we don't immediately see it under the new name?
[22:51] <jam> poolie: speaking of which, just checking that vila's villa is start Mon Jan 25, leave after Fri Jan 29th
[22:51] <poolie> i can imagine there is some cache incoherency or something
[22:51] <poolie> but if we know what specifically it is, we might be able to work around it
[22:52] <poolie> correct
[23:15] <lifeless> bombs away
[23:24] <poolie> on testtools?
[23:24] <lifeless> yes
[23:55] <mwhudson> does "NotImplementedError: SilentUIFactory doesn't support make_output_stream" mean anything obvious to anyone?
[23:56] <spiv> mwhudson: apart from the bleeding obvious?  Not to me :)
[23:59] <mwhudson> darn