[00:09] <mrbean> mpalyer video does the same thing.
[00:09] <mrbean> dont have tvtime install right now.
[00:10] <mrbean> so you think its an ivtv issue?
[00:11] <mrbean> i have a pvr500, it uses the ivtv driver/module
[00:19] <laga> probably
[00:26] <mrbean> Ive worked on this all weekend.  Tired of hacking so Im rebuilding it with some different (and less) hardware.
[00:31] <laga> hum
[00:31] <laga> i can't play some recordings on my remote frontend although they're there..
[00:45] <mrbean> you select a recording and what happens?
[00:48] <laga> tries to play back and jumps to the min menu again. must be something in svn trunk, this used to work
[00:48] <laga> getting odd log messages on the backend, too. i suppose i'll have to bug someone tomorrow :)
[01:55] <Aquahallic> Evenin' folks....;)
[03:32] <octogone> i enabled the VNC service via mythbuntu-control-centre, and can connect to it using vncviewer, but the display is all garbage and my mouse clicks seem to do nothing.
[03:33] <octogone> i tried a sudo netstat -pant to find out what process was listening on port 5900 in the hopes that i could track something down, but it just says that the process listening is "X"
[03:34] <octogone> how can i find out the name of the VNC service that the control centre installed so i can read about it?
[03:36] <superm1> restart the comp
[03:36] <superm1> it starts with the x server
[03:37] <superm1> and see if its still like that
[03:37] <superm1> it is an X module that gets loaded
[03:39] <octogone> yeah, i had to restart to get it to even start
[03:40] <octogone> it's running. it listens on 5900. it even authenticates properly
[03:44] <octogone> hmm, it seems to just be a graphics issue...
[03:58] <superm1> are you using the opengl painter?
[04:21] <zouzou> hi all,
[04:22] <zouzou> i installed mybuntu-desktop on my ubuntu box, but when i start the front-end, it says that either the backend isn't started or the IP is not correct, i checked and both are fine
[04:22] <zouzou> i started the backend as follows /etc/init.d/mythtv-backend start (restart)
[04:23] <zouzou> and IP addresses on both the setup and the frontend setup are both :<IP_ADDRESS>
[04:39] <astyler> Hello, I have a question about a mythbuntu installation
[04:40] <astyler> If anyone is out there: is there a 64-bit distro that will work with an intel chip?  (the 64bit distro is listed as AMD64)
[04:52] <astyler> i got the answer over in #ubuntu
[10:49] <MythbuntuGuest92> Mahlzeit!
[10:50] <MythbuntuGuest92> bin newbe und hoffe mir kann einer von euch helfen
[10:50] <MythbuntuGuest92> hab am we Mythbuntu inst und finds vom aufbau her auch klasse
[10:51] <MythbuntuGuest92> aber meine Videos sind auf einem Netzlaufwerk hinterlegt
[10:51] <MythbuntuGuest92> wie kann ich auf der grafischen Oberfläche eine Netzlaufwerkverbindung machen?
[15:13] <mckemie> can I get some newbie help here?
[15:15] <mckemie> Well, I'll just chat along here as if someone is listening.
[15:16] <mckemie> I have a new Mythbuntu install I'm trying to get working.  I have a Hauppauge 350 and only the onboard Compaq video.
[15:17] <mckemie> I was under the apparent misconception that the SVideo connection on the 350 was an output and that I could get by without a "good" video card.
[15:22] <mckemie> I haven't been able to get myth to display any tv programming, though mplayer will play at least one tv (antenna) channel.  However, mplayer will not play using a "-vo xv" option.  How might I get myth to not assume I have a "good" video card?
[15:35] <rhpot1991_laptop> mckemie: https://help.ubuntu.com/community/MythTV_Gutsy_hardware_pvr-350_TV-out
[15:35] <rhpot1991_laptop> can try that out
[15:36] <rhpot1991_laptop> I haven't used the output on my 350 in a while, but have heard a lot of complaining about it not working so well anymore
[17:47] <mckemie> Thanks for the URL to the doc, rhpot1991_laptop.
[17:48] <mckemie> My /proc/fb is empty.  I'm not sure what that means, but I guess I need one for the new module to work.
[18:09] <rhpot1991_laptop> prob need to sudo  modprobe ivtv-fb
[18:09] <rhpot1991_laptop> provided its installed, used to come with the ivtv-dev package IIRC, no idea where it lives today
[18:09] <rhpot1991_laptop> http://www.mythtv.org/wiki/index.php/Hauppauge_PVR-350
[18:09] <rhpot1991_laptop> that might help out some too
[18:15] <mckemie> modprobe ivtv-fb did it, thanks.  Onward through the fog.
[18:17] <superm1> need to get that stuff automated still for hardy.
[18:17] <superm1> bleh.
[18:17] <rhpot1991_laptop> mckemie: you are gonna want to add that to /etc/modules I think
[18:17] <superm1> mckemie, any info not documented on h.u.c's wiki, can you please add
[18:17] <rhpot1991_laptop> to make load on boot
[18:18] <rhpot1991_laptop> yep, thats where I used to have mune, /etc/modules
[18:19] <rhpot1991_laptop> superm1: see what I said about xwrt web interface?
[18:19] <superm1> ah just looked
[18:19] <superm1> interesting
[18:19] <superm1> so you're telling me that's the "easy" way :)
[18:20] <rhpot1991_laptop> appears so
[18:20] <rhpot1991_laptop> though when I tried to restore it was unhappy about uploading that file
[18:20] <rhpot1991_laptop> too large
[18:20] <rhpot1991_laptop> via the web interface that is
[18:20] <superm1> well doing it via command line isn't too bad
[18:20] <superm1> but that's odd
[18:23] <rhpot1991_laptop> multiple ssid's acts strange out of the box too, I added a 2nd one and can connect to that with the authentication for my first one
[18:23] <rhpot1991_laptop> I need to set up some bridges in /etc/network I guess
[18:23] <superm1> yeah i made bridges, but mine is all messed up still too
[18:23] <superm1> every so often my laptop wants to connect to my wep one
[18:23] <superm1> even though the ssid is hidden
[18:24] <superm1> i think i need to reset my keyring or something
[18:24] <rhpot1991_laptop> I messed with the bridges some but was confused at the lines at the top with the "1 2 3 4 5*" and so on
[18:24] <rhpot1991_laptop> ended up losing connectivity all together
[18:24] <superm1> oh that represents the ports on the back
[18:24] <superm1> 1234 are typically physical ports
[18:24] <superm1> 5 is the wifi
[18:24] <rhpot1991_laptop> I figured that much, is 5 wifi?
[18:24] <rhpot1991_laptop> kinda guessed that
[18:24] <superm1> depending on the router either 1 or 4 is the wan
[18:24] <superm1> mine is backwards from the norm
[18:24] <rhpot1991_laptop> I think mine might be 0
[18:24] <rhpot1991_laptop> let me ssh in
[18:25] <rhpot1991_laptop> do you use dyndns btw?
[18:25] <superm1> used to
[18:25] <superm1> havent bothered atm
[18:25] <rhpot1991_laptop> I didn't think it used to let you toss ports onto the host name
[18:25] <superm1> i've got a new philosophy about being too accessible
[18:25] <rhpot1991_laptop> but it is letting me do that now
[18:26] <rhpot1991_laptop> can prob do it yourself, I did some redirect scripts on my server before I started using dyndns
[18:26] <superm1> ah
[18:27] <rhpot1991_laptop> I mess around with my stuff a lot from work and my parents house when I go home to visit on the weekends, so I would be sad about not being able to reach it
[18:27] <superm1> well i try not to do that lately
[18:27] <superm1> its bad having this ipod touch too
[18:27] <superm1> because i'm far less social when i have it on me
[18:27] <rhpot1991_laptop>  option vlan1    "0 5"
[18:27] <laga> superm1: heh :)
[18:27] <rhpot1991_laptop> I think that means my wan is on 0?
[18:28] <superm1> let me check mine
[18:28] <superm1> well i think i'm mixing mine up here now with what they represent
[18:28] <superm1> i understood this before.
[18:29] <superm1> because why would you want your wifi tied to your wan
[18:29] <rhpot1991_laptop> well that is my wan
[18:29] <superm1> that's how mine is (backwards: vlan1 = 4 5
[18:29] <rhpot1991_laptop> I think I tried to make 2 vlans each touching 5 only
[18:29] <superm1> i have a vlan2 that is just 5
[18:30] <superm1> that i use for the second bridge
[18:31] <superm1> awesome: open gconf-editor and look at /system/networking/wireless/networks
[18:31] <superm1> and you can make it forget networks there
[18:32] <rhpot1991_laptop> so you only have one wifi interface in /etc/config/network?
[18:32] <superm1> well /etc/config/network you list bridges only
[18:32] <superm1> so i have one for lan+wifi, one for wan, and one for just wifi
[18:32] <rhpot1991_laptop> ah ok, I get what you are saying now
[18:33] <superm1> http://paste.ubuntu.com/3962/
[18:34] <rhpot1991_laptop> are you only doing opendns in there now, or still how that howto said to?
[18:34] <superm1> still how it said to
[18:35] <rhpot1991_laptop> I wonder if thats part of my problem, I dropped the dns lines from /etc/config/network
[18:38] <rhpot1991_laptop> you were only able to filter mac addresses system wide, right?
[18:39] <superm1> right
[18:39] <superm1> so i haven't bothered with that yet
[18:39] <superm1> i suppose there has to be a really easy iptables rule to do it on just that interface
[18:39] <rhpot1991_laptop> I came across something indicating you could do it per interface
[18:39] <rhpot1991_laptop> though that tab is long closed
[18:40] <superm1> well if you google'd it, it is in your google search history though
[18:40] <superm1> or FF history?
[18:40] <rhpot1991_laptop> it might be, depends if I did it on this laptop or on my box at home
[18:50] <rhpot1991_lapto1> superm1: http://forum.openwrt.org/viewtopic.php?pid=57013
[18:52] <rhpot1991_lapto1> since we are defining our own interfaces for the seperate wifi, one would think you could plug it into that
[18:57] <superm1> rhpot1991_lapto1, no i dont think so
[18:57] <superm1> that is system wide
[18:57] <superm1> for all wifi
[18:57] <superm1> its not like we have a wl1
[18:59] <blkorpheus> YOU DA MAN SUP
[18:59] <blkorpheus> keep up the good work
[18:59] <rhpot1991_lapto1> I'd think if you tossed gwifi in there, it would work
[18:59] <superm1> thx :)
[18:59] <superm1> rhpot1991_lapto1, no i dont think so
[18:59] <superm1> because that is defined at a software level
[19:00] <superm1> this tool works at a hardware level
[19:00] <blkorpheus> did you know on star trek voyager, kes had a girl named Linux?
[19:00] <rhpot1991_lapto1> ah ok
[19:00] <superm1> haha that's great
[19:00] <blkorpheus> if I'm hearing this name correctly
[19:01] <blkorpheus> just needed to share that with someone
[19:01] <compy> anyone know how to set up compiz fusion ?
[19:01] <compy> i installed it but now dont know where to get it
[19:01] <compy> ** config it ^^
[19:02] <rhpot1991_lapto1> I wonder what would happen if you put the wap one into AP Isolation mode, if it would like that one is running that way and another is not
[19:02] <blkorpheus> its easy compy
[19:02] <rhpot1991_lapto1> s/wap/wep one
[19:02] <blkorpheus> compy, try right clicking the desktop
[19:03] <compy> blkorpheus, oh so i used synaptic to install it all, ... ok let me try that
[19:03] <blkorpheus> things shoud stand out
[19:03] <compy> so it comes up w/ all my applications... im running xfce
[19:03] <blkorpheus> ahh
[19:04] <blkorpheus> ok, hmmm, come to think of it I have never run xcfe with compiz, but I suppose its the same deal
[19:04] <blkorpheus> one sec
[19:04] <compy> is there a command line that i can type and set it up
[19:05] <blkorpheus> compy, http://xubuntublog.wordpress.com/2007/12/09/xubuntu-compiz-pretty-pretty-xubuntu/
[19:06] <compy> thanks ill check this out
[19:06] <compy> blkorpheus, what do you run... ubuntu w/ mythtv?
[19:06] <blkorpheus> yes
[19:07] <blkorpheus> exactly that way
[19:07] <blkorpheus> ubuntu with mythtv
[19:08] <rhpot1991_lapto1> what does compiz gain you in reguards to mythtv?
[19:08] <blkorpheus> I was going to say nothing
[19:08] <blkorpheus> but then I was palying around last night
[19:08] <blkorpheus> and while myth takes up a whole screen
[19:08] <blkorpheus> it was very easy for me to just rotate the cube to my workspace
[19:09] <blkorpheus> I could still hear the movie adn all , so I could switch back to video, quickly
[19:09] <rhpot1991_lapto1> so you don't run on a tv only?
[19:09] <blkorpheus> no
[19:09] <rhpot1991_lapto1> ok, that makes a lot more sense then
[19:09] <blkorpheus> yeah
[19:09] <rhpot1991_lapto1> I just run on my tv, and then nx in if I want to do anything
[19:09] <blkorpheus> true
[19:11] <blkorpheus> if I did outputto tv, it would be the tv/monitor for the htpc
[19:11] <compy> hehe yeah i have a desktop at the moment w/ my mythtv set up
[19:11] <compy> i dotn record tv at this point
[19:12] <blkorpheus> compiz shouldbe merged withgnome
[19:12] <blkorpheus> it seems to just fit together
[19:12] <blkorpheus> once they can get compiz rock stable
[19:13] <blkorpheus> recording is the fun part
[19:16] <rhpot1991_lapto1> until you break something and get sad that your recording is gone :(
[19:20]  * rhpot1991_lapto1 has a bad tendency to get everything working and then mess with things till they break
[19:20] <laga> me too
[19:20] <laga> because working stuff is boring.
[19:21] <rhpot1991_lapto1> especially at 2am
[19:21] <laga> heh
[19:21] <rhpot1991_lapto1> the fact that everything has to be working to record the wife's soap opera the next day doesn't help anything either
[19:22] <laga> no
[20:14] <leprasmurf> hello all, anyone know how to get xawtv working with mythbuntu?
[21:46] <compy> is it possible to run compiz under fluxbox or openbox... i dont know if what i just said makes any sense
[22:05] <blkorpheus> compy do you know how to use google?
[22:06] <blkorpheus> http://www.google.com/search?q=fluxbox+compiz&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a
[22:06] <blkorpheus> 4th hit
[22:06] <blkorpheus> first answer
[22:06] <blkorpheus> 15secs
[22:14] <tgm4883_laptop> blkorpheus, compy isn't in here anymore
[22:15] <blkorpheus> doh
[22:45] <MythbuntuGuest27> hi to all
[22:50] <rhpot1992> !logs
[22:50] <ubotu> Channel logs can be found at http://irclogs.ubuntu.com/ - Logs for LoCo channels are at http://logs.ubuntu-eu.org/freenode/ - See also « /msg ubotu ircstats »
[23:54] <dannyboy79> can anyone help me figure out my IVTV says it's in use? I am trying to add options to /etc/modprobe.conf for the ivtv module.


[17:33] <ahasenack_> hi #security, do you have a good document outlining best practices for gpg keys? Considering subkeys
[17:33] <ahasenack_> I know of https://github.com/drduh/YubiKey-Guide which talks a lot about subkeys
[17:37] <Montresor> About all I can tell you is "Don't generate a 2048 key and store it in Dropbox" :>
[17:37] <ahasenack_> check
[17:37]  * ahasenack_ reads https://wiki.debian.org/Subkeys
[17:38] <Montresor> ed25519 keys sounded interesting, but considering how hard it is to get a key signed...I'd be sticking with mine untilI absolutely can't.  I realize of course this doesn't help at all.
[17:41] <ahasenack_> what has ed25519 got to do with being hard to sign?
[17:42] <ahasenack_> or you mean, if you were to change your key, you would have to work hard to get all the signatures again?
[17:43] <Montresor> The latter, any new key is a hard no.
[17:43] <ahasenack_> that's the kind of best practice I'm looking for too. It's my vague understanding that with subkeys that is not a problem, you can rotate the subkeys, and you don't lose the signatures which were done on the parent key, or something like that
[17:43] <Montresor> Which would be good, yeah.
[17:44] <ahasenack_> Montresor: oh, you are unit193
[17:44] <ahasenack_> what happened? :)
[17:44] <Montresor> It's Halloween, so to Poe we go.
[17:44] <ahasenack_> aha
[17:44] <Montresor> (I'll be JackFrost for the winter/Christmas too.)
[18:20] <amurray> ahasenack_: we don't have any great documentation around gpg - probably the best is https://wiki.ubuntu.com/SecurityTeam/GPGMigration but that is quite old now
[18:21] <ahasenack_> ok


[00:07] <mwhudson> uh why are my uploads to the store from launchpad failing?
[00:07] <mwhudson> eg. https://code.launchpad.net/~mwhudson/+snap/go110/+build/405061
[00:23] <mup> PR snapcraft#2427 closed: lifecycle: query for multipass install on darwin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2427>
[06:21] <mborzecki> morning
[06:32] <mup> PR snapd#6299 closed: travis: short circuit failures in static and unit tests travis job <Simple 😃> <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6299>
[06:54] <mup> PR snapd#6307 opened: systemd/systemd.go: add missing tests for systemd.IsActive <Created by mvo5> <https://github.com/snapcore/snapd/pull/6307>
[07:02] <mup> PR snapd#6308 opened: release: 2.36.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6308>
[07:03] <mvo> zyga: 6308 has some interessting bits, would love to understand where the code diff came from
[07:16] <zyga> Hello
[07:17] <zyga> This is because of different approach to fix a bug in master and in the release branch
[07:17] <zyga> I will review it carefully, the master version should be used most likely
[07:28] <mborzecki> zyga: mvo: hi
[08:02] <pstolowski> morning
[08:16] <mvo> zyga: ok, just push to the PR if you are happy
[08:16] <mvo> zyga: I remember now I think :)
[08:16] <mvo> mborzecki: hey, good morning
[08:17] <pstolowski> mvo: oh, still working today?
[08:17] <mvo> pstolowski: fire is not fully over :(
[08:18] <mvo> pstolowski: cloud-init on pi and dragon is acting up, i.e. it runs when it should not run and console-conf does not work correctly too
[08:19] <mvo> pstolowski: hopefully sil2100 (and foundations) can help with these issues
[08:21] <pstolowski> mvo: :(
[08:22] <mvo> pstolowski: it is what it is, I will just take 2 days off in jan
[08:22] <sil2100> Yeah, looking into that as much as I can
[08:22] <mvo> sil2100: \o/
[08:23] <mvo> sil2100: all the details are in the mail I send out ~2h ago or so (I hope, if anything is missing, please do let me know)
[08:32] <zyga> Good morning
[08:33] <mvo> zyga good morning :)
[08:33] <zyga> Some patches required
[08:34] <sil2100> mvo: as per my e-mail, could you attach ds-identify.log from the cloud-init logs?
[08:41] <sil2100> mvo: anyway, I'm building an image for my pi3 now and I'll test it here as well
[08:45] <mvo> sil2100: will do, mail goes out in 2min
[08:46] <pedronis> mvo: hello
[08:49] <mvo> sil2100: you have mail
[08:49] <mvo> sil2100: the pi has booted now so things should be quicker now
[08:49] <mvo> pedronis: good morning
[08:50] <pedronis> mvo: so  cloud-init on arm devices thinks to be on a cloud, that is annyoing/strange, strange because it wasn't doing that with 16
[08:50] <pedronis> otoh is probably a newer cloud-init
[08:50] <mvo> pedronis: yeah, different version and +100 for annoying
[08:51] <mvo> pedronis: also console-conf is acting up and the IP keeps changing for me so not a great experience
[08:51] <mvo> ogra: hey, do you happen to know why the pi3 with 4.15 might switch IP addresses on reboot? (context is UC18 image)
[08:52] <pedronis> mvo: so it think maybe it's an OpenStack
[08:53] <mvo> pedronis: can you elaborate? what makes it think that? is that in the ds-identify log?
[08:53] <pedronis> yes
[08:53] <mvo> pedronis: heh, I see
[08:54] <mvo> pedronis: it does not have more details about the why it seems
[08:54] <pedronis> yea, we need to stare at the code
[08:56] <mvo> pedronis: I just did and had a heart attack
[08:56] <mvo> pedronis: let me find a link
[08:56] <mvo> pedronis: it looks like we get the maybe because https://github.com/number5/cloud-init/blob/master/tools/ds-identify#L960
[08:58] <pedronis> wonderful
[08:59] <sil2100> check for 'OpenStack' returned maybe
[08:59] <sil2100> Oh yeah
[09:00] <mvo> yes, just verfied that code path is taken
[09:00] <mvo> so I guess cloud init does not run much on non-x86 ;)
[09:00]  * mvo weeps a bit in the corner
[09:00] <sil2100> mvo: but we had the same thing in core16, right?
[09:00] <sil2100> Is cloud-init in xenial different?
[09:01] <mvo> ppisati:  hey, do you happen to know why the pi3 with 4.15 might switch IP addresses on reboot? (context is UC18 image)
[09:03] <mvo> no set -e in ds-identify, thats an interessting choice
[09:03] <mvo> anyway
[09:04] <pedronis> mvo: sil2100:  does ubuntu-image write some cloud-init conf
[09:04] <pedronis> ?
[09:05] <sil2100> pedronis: not if it's not asked to, you can explicitly add one if you need to though
[09:05] <pedronis> mvo: sil2000: it seems quickest fix not touching cloud-init would be to configure ds-identify with maybe=none if arch is not x86
[09:07] <mvo> pedronis: yeah, forcing cloud-init to be disabled via ubuntu-image is probably the quickest path forward. iirc --cloud-init can already be passed to u-i so we just need to craft a no-cloud config for it
[09:07] <pedronis> mvo: not disabled
[09:07] <mvo> pedronis: aha, just maybe=none ? ok
[09:07] <pedronis> ds-identify
[09:07] <pedronis> has a different config
[09:07] <pedronis> yes, maybe=none
[09:07] <pedronis> either everywhere or only arm
[09:07] <mvo> ta, I was not aware of this
[09:08] <mborzecki> zyga: can you do another pass on https://github.com/snapcore/snapd/pull/6265 ?
[09:08] <mup> PR #6265: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265>
[09:09] <pedronis> mvo: there's some doc at the top of it, it mentions /etc/cloud/ds-identify.cfg and the kernel cmdline
[09:13] <mvo> pedronis: thanks, playing with this now
[09:13] <mvo> pedronis: I also added a trello card UC18 release
[09:13] <mvo> pedronis: that lists the bugs
[09:13] <mvo> pedronis: or open issues
[09:13] <pedronis> thx
[09:19] <mvo> $ cat /etc/cloud/ds-identify.cfg
[09:19] <mvo> policy: search,found=all,maybe=none,notfound=disabled
[09:19] <mvo> pedronis, sil2100 ^- this has helped and no cloud-init anymore
[09:19] <mvo> pedronis, sil2100 with that I also have a stable IP it seems
[09:19] <pstolowski> mborzecki: hey, if you get to reviewing hotplug PRs, then #6100 and #6114 would be the first to look at; thanks in advance!
[09:19] <mup> PR #6100: overlord/ifacestate: hotplug-remove-slot task handler <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6100>
[09:19] <mup> PR #6114: overlord/ifacestate: handler for hotplug-disconnect task <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6114>
[09:19] <mborzecki> pstolowski: ack
[09:20] <pstolowski> and i've just de-conflicted them
[09:20] <mborzecki> i'm doing 6114 now
[09:20] <pstolowski> thanks
[09:21] <mborzecki> hm need to grab some coffee
[09:22] <mwhudson> mvo: do you have cloud-init logs from when it was causing problems?
[09:22] <sil2100> mvo: btw. from the failed run you had, could you upload the cloud-init log tarball somewhere?
[09:23] <mvo> mwhudson: cloud init logs for the console-conf setup? or just where it thinks its in a cloud?
[09:23] <mwhudson> mvo: one where set-name ended up in places it shouldn't
[09:24] <mvo> mwhudson: I can probably do that but need to rewrite the sd card and start from scratch, this is also tricky because cloud-init keeps the logs in /run but I cannot login with the broken network
[09:25] <mwhudson> mvo: ugh
[09:25] <sil2100> mwhudson: so far I can share with you mvo's cloud-init-generator and ds-identify logs
[09:25] <mwhudson> debug shell time?
[09:25] <mvo> mwhudson: yes, just annoying to add in uboot, I struggle with this everytime because I never remember how to do it correctly :(
[09:26] <mwhudson> everyone loves uboot
[09:26] <mvo> mwhudson: but I give it a poke in some minutes, just trying to debug another failure on this pi
[09:26] <mvo> mwhudson: hahaha
[09:26] <mwhudson> ok
[09:26] <mwhudson> mvo: basically cloud-init does have code that will write netplan with set-name in it
[09:26] <zyga> mborzecki: reviewed
[09:26] <mwhudson> i don't at all understand how it could be triggered in this context
[09:27] <mwhudson> but i also have no other ideas how else it could get there
[09:27] <mwhudson> wait
[09:27] <mwhudson> "cloud-init keeps the logs in /run"
[09:27] <mwhudson> is that a core specific thing?
[09:27] <mwhudson> break in the initramfs and mount /run as a real partition? :)
[09:28] <mwhudson> (systemd might get angry if you do that i guess)
[09:28] <mvo> mwhudson: to break I need to add a kernel comandline and then I might as well add a debug shell. oh well, I think I will do that
[09:28] <mwhudson> oh yeah
[09:28] <mvo> mwhudson: maybe its in /var/log as well, I will check
[09:29] <mwhudson> it certainly is in classic
[09:29] <mvo> mwhudson: pretty sure that the generator log is only in /run but I guess thats not relevant for you, right?
[09:29] <mwhudson> yeah no i want cloud-init.log and cloud-init-output.log
[09:29] <sil2100> Didn't see anything in /var/log
[09:29] <mvo> mwhudson: cool, if thats the case then I can help sooner
[09:30] <sil2100> I had to do a cloud-init collect-logs previously
[09:30] <sil2100> /var/log/cloud-init.log is empty for me
[09:31] <mborzecki> damn gnome-shell crashing on each unlock
[09:32] <mwhudson> sil2100: hmm
[09:32] <mwhudson> sil2100: syslog?
[09:32] <mborzecki> zyga: thanks for the review, i didn't think about adding a selinux backend, but maybe we should once the cleanups are in
[09:34] <sil2100> mwhudson: no syslog + eek, persistent journal not enabled by default
[09:35] <mwhudson> sil2100: i am not surprised :/
[09:35] <mwhudson> (persistent journal vs sd cards?)
[09:35] <sil2100> Let me re-flash and enable persistent journal
[09:38] <zyga> mvo: I pushed to https://github.com/snapcore/snapd/pull/6308
[09:38] <mup> PR #6308: release: 2.36.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6308>
[09:38] <zyga> the diff isn't 0 but it is as close as it should
[09:38] <zyga> yes, the release branch had one more patch that was in the chain of fixing system key issue
[09:38] <zyga> it was because my initial branch got closed and reshuffled and I lost track of that
[09:39] <zyga> anyone interested in 2nd review on https://github.com/snapcore/snapd/pull/6288 ?
[09:40] <mup> PR #6288: cmd/snap-confine: refactor call to snap-update-ns --user-mounts <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6288>
[09:41] <zyga> mvo: do you know what is the status of SRUs into bionic?
[09:41] <zyga> 2.35.5 is in proposed
[09:41] <zyga> 2.34.2 is in main/updates
[09:42] <mvo> zyga I think there were issues with autopkgtest
[09:42] <zyga> aha
[09:43] <zyga> real or just noise?
[09:43] <mvo> zyga: I did not dig into them, iirc autopkgtest killed our tests because they ran too long
[09:43] <zyga> uhhh
[09:43] <zyga> anyway, it's probably not super urgent but it would be good to update the classic package
[09:43] <mvo> zyga I'm not sure what the latest status is though
[09:43] <zyga> and as soon as 2.36.x is out, do that as well
[09:43] <mvo> zyga absolutely
[09:43] <zyga> mvo: no worries, one thing at a time
[09:43] <zyga> mvo: :)
[09:43] <mvo> zyga its a mess - I think we need to disable adt again, its just not working in our cloud :(
[09:44] <zyga> for context, I'm asking because of this bug last evening: https://bugs.launchpad.net/snapd/+bug/1806070
[09:44] <mup> Bug #1806070: snapd.seeded.service never completes preventing full boot to default target <amd64> <apport-bug> <bionic> <snapd:Fix Released> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1806070>
[09:44] <zyga> the package in the archive is preventing snapd seeding and refreshing in some cases
[09:44] <mvo> zyga thanks! I remember we talked about this
[09:44]  * zyga looks at the snow outside
[09:44] <zyga> brr
[09:44] <zyga> I miss my old computer
[09:44] <zyga> the one that doubled as room heater
[09:45] <ppisati> mvo: does the ethernet mac change?
[09:45] <sil2100> ppisati: it's just the IP, I guess it's all good from the kernel side, it's more like a cloud-init thing
[09:46] <mvo> ppisati: yeah, sorry for the noise, it stopped for me AFAICT once I disabled cloud-init
[09:46] <mvo> ppisati: which should not have run in the first place but that is a different story.
[09:46] <ppisati> ack
[09:47] <mwhudson> mvo: i think i have more or less convinced myself that the set-name comes from cloud-init
[09:47] <mwhudson> mvo: and now i am going to bed
[09:47]  * mwhudson zzzz
[09:47] <sil2100> Indeed, mwhudson thanks!
[09:48] <mvo> mwhudson: sleep well
[09:48] <mvo> mwhudson: and thank you!
[09:52] <pedronis> mvo: we should be careful with the notfound value in that config, it was enabled I think in your original log, not sure where that comes from
[09:55] <mvo> pedronis: I don't know what enabled it originally, iirc /etc/cloud is empty
[09:56] <pedronis> mvo: I mean, I'm not sure what happens if it's set to disabled and there's cloud init config
[09:56] <pedronis> or somebody attaches a disk some of that
[09:56] <pedronis> it was working on 16
[10:00] <mvo> pedronis: oh, ok. I suspect that 16 has a different ds-identify
[10:02] <sil2100> Ugh, indeed
[10:02] <sil2100> ds-identify-behavior-xenial.patch
[10:03] <mvo> sil2100: oh, interessting - can you pastebin that one?
[10:03] <sil2100> Wait, one moment, this doesn't look right
[10:07] <pedronis> mvo: 16 had also this:  https://github.com/snapcore/core/blob/master/live-build/hooks/40-cloud-init-run-after-networkd-wait-online.chroot
[10:08] <pedronis> probably not relevant given that in 18 networkd is used in all server images?
[10:08] <mvo> sil2100: one more interessting observation - even when I run console-conf I get a prompt to run it again instead of the usual "here is the machine IP and how you log in". but could be an artifcat
[10:08] <mvo> pedronis: that is the default now unless I very much misremember
[10:09] <mvo> pedronis: I remember looking at this patch and if we still need it
[10:09] <mvo> (I might be wrong though and can double check in a wee bit)
[10:10] <zyga>  mborzecki https://bugzilla.redhat.com/show_bug.cgi?id=1648733
[10:11] <mborzecki> heh
[10:13] <pedronis> mvo: I read dsidentify, nocloud is a kind of cloud,  either the things ubuntu-image writes or a properly labeled fs shoild make dsidentify detect that
[10:13] <pedronis> so that's not a notfound case afaict
[10:13] <mvo> pedronis: hm, ok
[10:14] <pedronis> see dscheck_NoCloud
[10:14] <zyga> Chipaca: heh, this is fun https://bugs.launchpad.net/snapd/+bug/1808450
[10:14] <pedronis> still wondering where the notfound=enabled comes from
[10:14] <zyga> Chipaca: %q needs to be localised :)
[10:14] <pedronis> shouldn't be the default
[10:14] <mup> Bug #1808450: Strings with placeholders don’t include quotation marks so they can’t be changed per locale <snapd:Triaged> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1808450>
[10:14] <Chipaca> zyga: hrm?
[10:15] <mvo> pedronis: interessting
[10:15] <Chipaca> zyga: yeah, no
[10:15] <Chipaca> zyga: somebody's being very ornery there
[10:15] <zyga> well, I kind of agree
[10:15] <sil2100> pedronis: I think it is the default, when you check ds-identify's DI_DEFAULT_POLICY_NO_DMI I guess?
[10:15] <zyga> snapd would not get a passing grade from my polish tearcher
[10:15] <zyga> teacher
[10:16] <pedronis> sil2100: ah
[10:16] <mborzecki> pedronis: left some benchmarks in https://github.com/snapcore/snapd/pull/6265#discussion_r241703113 it's a vm running as a snapshot, though i took care to drop the caches each time, i'll see if i can get some measurements where the are actual writes to a spin drive
[10:17] <mup> PR #6265: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265>
[10:17] <mborzecki> fwiw the numbers aren't terrible, 27s for 600k small files, better than fontconfig
[10:20] <pedronis> mborzecki: this sound like we don't want to do it inconditionally, no?
[10:21] <pedronis> mvo: anyway afaik  we can just set  maybe=none and the parsing will use the defaults for the rest
[10:21] <pedronis> s/afaik/afaict/
[10:21] <mvo> pedronis: cool, I can try in a bit but right now I am running the testsuite
[10:22] <mborzecki> pedronis: the pr was already updated to do it only when the ~/snap (the dir) is not using the default label
[10:22] <mvo> pedronis: it looks like all the issues cachio had with running the arm tests are from cloud-init being enabled, so far I ran the core18 specific tests and all green, main is running now as well
[10:22] <pedronis> good
[10:23] <mvo> pedronis: I'm sure sil2100 will find a good config and a way to get it into the system and then this fire is hopefully also done
[10:25] <Chipaca> zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1808450/comments/1
[10:25] <mup> Bug #1808450: Strings with placeholders don’t include quotation marks so they can’t be changed per locale <snapd:Triaged> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1808450>
[10:25] <pedronis> mvo: sil2100: we can have that file in core18 itself?
[10:25] <pedronis> that file = ds-identify.cfg
[10:26] <Chipaca> zyga: I mean, I agree, except in Spanish guillemots are very much optional / recommended-but-not-required
[10:26] <zyga> I agree about the low priority
[10:26] <Chipaca> zyga: and the 2nd preferred quote symbols are … “”
[10:26] <sil2100> pedronis: so I see that in core 16 we had /etc/cloud/ds-identify.cfg
[10:26] <sil2100> With policy: search,found=first,maybe=none,notfound=disabled
[10:26] <Chipaca> zyga: to which " is a close enough approximation for now
[10:26] <sil2100> Trying to figure out where this file is coming from
[10:26]  * zyga is happy that he can at least read loads of spanish
[10:27] <mvo> sil2100: where did this come from? did u-i put it there ?
[10:29] <sil2100> mvo: that's a good question, trying to figure it out - u-i doesn't really have mechanisms for arbitrary files in /etc
[10:29] <mborzecki> spread jobs hitting travis timeouts?
[10:29] <sil2100> mvo: huh
[10:29] <sil2100> mvo: it's in the core snap
[10:30] <sil2100> mvo: not sure what's adding it, but if you unsquashfs core you can see the file there - I didn't see it created in any hooks so far, cloud-init itself also doesn't seem to ship it (at least as a file, maybe through maintainer scripts?)
[10:32] <mvo> sil2100: oh, run
[10:32] <mvo> sil2100: eh, fun
[10:32] <pedronis> mvo: sil2100: fascinating
[10:32] <mvo> sil2100: ok, we can put it back if that fixes all the issues
[10:32] <pedronis> anyway means doing the same for 18 wouldn't be too crazy :)
[10:32] <mvo> pedronis: :)
[10:33] <sil2100> Yeah, sounds like the best way ;) I'll try to figure out where it's created out of curiosity anyway
[10:33] <sil2100> But this would fix "all the issues"
[10:33] <mvo> sil2100: I think ubuntu-core-config created this
[10:33] <mvo> sil2100: give me a sec
[10:33] <sil2100> mvo: oh, that's something new!
[10:33] <sil2100> I saw it in the image PPA once but didn't know it was used
[10:33] <sil2100> Sweet
[10:33] <mvo> sil2100: we no longer use it
[10:34] <mvo> sil2100: its a pain
[10:34] <pedronis> core build is so byzantine
[10:34] <mvo> sil2100: I mean, the configs are split between gits
[10:34] <mvo> sil2100: so we fixed this in the core18 build but sometimes (like now) we still suffer
[10:34] <mvo> pedronis: indeed
[10:34] <mvo> sil2100: fwiw https://github.com/snapcore/core-build/tree/master/config/etc/cloud
[10:35] <pedronis> ah
[10:35] <pedronis> we have two core related repos?
[10:36] <mvo> pedronis: yes, sadly - core-build and core
[10:37] <sil2100> At least it's all known now \o/
[10:37] <mup> PR core18#105 opened: static: add ds-identify.cfg back <Created by mvo5> <https://github.com/snapcore/core18/pull/105>
[10:37] <pedronis> mborzecki: when you a little bit of time could you look at https://github.com/snapcore/snapd/pull/5712 , it's long lived but now I finally got to make it green, had to adjust for parallel installs changes
[10:37] <mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
[10:37] <mborzecki> pedronis: ack
[10:38] <pedronis> mvo: that config tree seems a bit in the wrong repo to me
[10:38] <mvo> pedronis: you mean core-build?
[10:38] <pedronis> yea
[10:38] <pedronis> if it's basically content of the thing
[10:38] <mvo> pedronis: this is why I created https://github.com/snapcore/core/pull/83
[10:38] <pedronis> it should go into core somehow
[10:39] <mup> PR core#83: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[10:39] <pedronis> ah
[10:39] <mvo> pedronis: and then it did not get merged /o\
[10:39] <sil2100> eeek
[10:39]  * mvo weeps harder in the corner
[10:40] <pedronis> it seems definitely a good idea
[10:42] <mvo> pedronis: I added a card for myself
[10:42] <sil2100> mvo: SHIP IT!
[10:43] <pedronis> mvo: sil2100: there's some other bits of cloud/ that might be relevant there btw
[10:43] <pedronis> I suppose the resize bit is done differently now though
[10:44] <pedronis> or is that done for clouds?
[10:44] <pedronis> and we need it?
[10:46] <mvo> pedronis: we ship https://github.com/snapcore/core18/blob/master/static/etc/cloud/cloud.cfg.d/10_snappy.cfg (ironically)
[10:47] <pedronis> very
[10:47] <mvo> pedronis: which is iirc the same as in uc16 - or am I misunderstanding
[10:47] <pedronis> yes
[10:47] <pedronis> it's ironic indeed because without cloud-init it would have done nothing
[10:48] <mvo> pedronis: :(
[10:48] <mvo> pedronis: so this is why the maybe become a yes?
[10:49] <pedronis> ?
[10:49] <mvo> pedronis: what I meant its ironic that we only had half the config. but you indicate that if we had no config at all cloud-init would not have bothered to run?
[10:53] <pedronis> mvo: sil2100: so it seems we need to port more bits from 16 to static/etc/cloud
[10:54] <mvo> pedronis: what else is missing?
[10:54] <pedronis> there's a bit about azure it seems
[10:55] <mvo> pedronis: pretty sure that is obsolete but worth checking with someone from the cloud team
[10:55] <pedronis> https://github.com/snapcore/core-build/blob/master/config/etc/cloud/cloud.cfg.d/99-snappy-azure.cfg
[10:55] <pedronis> sil2100: can you check if we need this ^ or not anymore ?
[10:56] <pedronis> mvo: ok, probably easiest for sil2100 to do that
[10:56] <mup> PR core18#105 closed: static: add ds-identify.cfg back <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/105>
[10:56] <mvo> building a new core18 with the right ds-identify.cfg now
[10:59]  * mvo also builds 2.36.3 for regular core beta
[11:01] <mup> PR snapd#6296 closed: tests: new backend used to run upgrade test suite <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6296>
[11:04] <pedronis> sil2100: are you looking into why core18 CI is red? seems related to the checks for package removal
[11:09] <zyga> mvo: is new snapd okay but we need changes to core18 or will you do another snapd release to fix the cloud issues?
[11:10] <pedronis> zyga: the last changes are all just in core18 afaiu
[11:10] <zyga> great
[11:12] <mvo> 2.36.3 is now in beta core everything but arm64
[11:12] <mvo> (the later is still building)
[11:13] <sil2100> pedronis: I didn't get to fixing them, but I confirmed that they're not real issues - the test env needs fixing, it's on my plate for ASAP
[11:19] <mup> PR snapd#6309 opened: overlord/ifacestate: addHotplugSeqWaitTask helper <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6309>
[11:22] <pstolowski> zyga: ^ if you have a moment
[11:22] <zyga> yep saw it
[11:30] <zyga> +1
[11:30] <pstolowski> zyga: +1 on 6288, but plese see the comment
[11:32] <zyga> pstolowski: applied!
[11:33] <pstolowski> ty
[11:39]  * pstolowski lunch
[11:42] <zyga> mborzecki: something to garden https://bugzilla.redhat.com/buglist.cgi?component=snapd&product=Fedora
[11:43] <zyga> make sure to select *all* bugs
[11:44] <mup> PR snapd#6310 opened: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6310>
[11:44] <zyga> mvo: found the patch that didn't make it into master https://github.com/snapcore/snapd/pull/6310
[11:44] <mup> PR #6310: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6310>
[11:54] <mvo> zyga: ta
[11:56] <Chipaca> I need to go to the boys' school for 2pm, meaning I'm not going to be here for the standup (although I should be back by 2.30 so I might see y'all if it extends a bit) (but, traffic, so dunno)
[11:57] <Chipaca> I'm still working on the epochs rerefresh thing
[12:00] <zyga> k
[12:00] <pedronis> Chipaca: ok,  let me know if you have questions or something
[12:03] <Chipaca> pedronis: another?
[12:03]  * Chipaca looks
[12:03] <pedronis> Chipaca: ?
[12:04] <Chipaca> pedronis: I split one out from Epochs yesterday
[12:04] <pedronis> Chipaca: forgot to assign it to you?
[12:04] <Chipaca> pedronis: " make sure to check and trigger new refreshes if there are further transitions available"
[12:04] <Chipaca> ah, drat, yes
[12:04] <Chipaca> pedronis: thanks
[12:05] <pedronis> removing mine, and tweaking yours
[12:05] <Chipaca> thanks
[12:05] <Chipaca> and I didn't notice but replied in public to a private message
[12:05] <Chipaca> hope nobody's too confused :-D
[12:05] <Chipaca> or at most as confused as i clearly was
[12:07] <Chipaca> I'm going to have lunch and see if that makes things better :-)
[12:10] <cachio> mvo, 509 and 510 are the right versions?
[12:11] <cachio> for arm devices
[12:16] <mborzecki> pedronis: left one suggestion under https://github.com/snapcore/snapd/pull/5712 otherwise lgtm
[12:16] <mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
[12:17] <pedronis> mborzecki: thx
[12:18]  * cachio afk
[12:21] <zyga> coffee
[12:28] <mborzecki> wtf is going on with fedora repos?
[12:43] <zyga> mborzecki: they have holidays too?
[12:43] <mborzecki> heh
[12:43] <zyga> I need to go run an errand, brb in 30 minutes
[12:43] <Son_Goku> oh god, I'm so happy
[12:43] <Son_Goku> this is my last day of work for 2018
[12:44] <zyga> I wished :)
[12:44] <zyga> Son_Goku: I'm iterating on https://github.com/snapcore/snapd/pull/6111
[12:44] <mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
[12:44] <Son_Goku> zyga, I didn't take much vacation this year, since I only had the one trip for Flock
[12:45] <zyga> I need to run that errand but the last part is the with/bcond work
[12:45] <zyga> and then I need to figure out why go is broken in leap again :)
[12:45] <zyga> afk :)
[12:45]  * Son_Goku waves
[12:46] <mborzecki> zyga: the problem with refreshing fedora repos seem to happen only in gcp
[12:46] <mborzecki> i can refresh just fine here
[12:48] <zyga> cloudscale problem ;)
[12:48] <zyga> mborzecki: idea
[12:48] <zyga> mborzecki: spin up our own mirror
[12:48] <zyga> try against that
[12:51] <mborzecki> zyga: heh, hardly sounds like the thing we ought to be focusing on :)
[13:23] <mvo> cachio: hey, yeah, 508,9 should be the right ones
[13:24] <mvo> cachio: I will be afk for a bit but looking at tg
[13:25] <cachio> mvo, good
[13:35] <zyga> re
[13:35] <zyga> this took forever, sorry
[13:36] <zyga> is it just me or is travis stuck?
[13:40] <pedronis> zyga: we might have hit some limit
[13:44] <cachio> zyga, hey
[13:44] <zyga> yes?
[13:45] <cachio> fedora 29 is taking more time than other systems
[13:45] <cachio> I saw it is taking time to build snapd
[13:45] <zyga> any idea why? download speed? more updates than usual?
[13:45] <cachio> could tha because because it is using go 11?
[13:46] <zyga> did go 11 got introduced?
[13:47] <zyga> as otherwise I don't see how go version is a factor
[13:49] <cachio> not sure when I was introduced
[13:49] <cachio> but after last update it is taking more time to run fedora29
[13:49] <zyga> after last update of what?
[13:49] <cachio> fedora 29
[13:49] <zyga> of the image?
[13:49] <cachio> there was a kernel update
[13:49] <cachio> zyga, yes
[13:49] <zyga> can you diff the package manifest in the old and the new image?
[13:50] <zyga> I don't know what changed
[13:50] <pedronis> zyga: is the description of 6310 up-to-date? didn't we learn that the SIGTERM was coming from systemctl stop snapd ?
[13:50] <zyga> I also don't have an suspicion what could be a factor
[13:50] <cachio> zyga, sure
[13:51] <zyga> pedronis: it's the original patch that got lost in various changes, this is to match the release merge PR that mvo noticed has some delta
[13:51] <pedronis> zyga: this for master though, right?  so an up-to-date description would be best
[13:52] <zyga> yes, it is the same patch as before, just proposed in a branch that got closed
[13:52] <zyga> I can edit the description, sure
[13:52] <pedronis> thank you
[14:00] <cachio> pedronis, I'll join in 2 minutes
[14:26] <thresh> how many snaps in the store are already using core18?
[14:37] <mvo> cachio: core18 is still not good, it looks like /etc/cloud is not populated (cc sil2100)
[14:38] <pstolowski> mborzecki: updated #6114
[14:38] <mup> PR #6114: overlord/ifacestate: handler for hotplug-disconnect task <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6114>
[14:38] <pstolowski> mborzecki: could you also take a look at the #6309 (simple)
[14:38] <pstolowski> ?
[14:38] <mup> PR #6309: overlord/ifacestate: addHotplugSeqWaitTask helper <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6309>
[14:38] <mborzecki> mhm
[14:38] <pstolowski> thanks
[14:39] <cachio> mvo, ouch
[14:39] <cachio> bad news
[14:39] <cachio> mvo, I'll run beta validation for 2.36.3
[14:40] <cachio> until core18 is ready
[14:40] <sil2100> mvo: huh? Something wipes out the /etc/cloud contents?
[14:41] <sil2100> mvo: hm, looking into core18 snap's squashfs I see /etc/cloud/ds-identify.cfg
[14:41] <sil2100> mvo: you don't have it?
[14:42] <sil2100> mvo: are you sure you're testing the right image/core18 snap?
[14:42] <sil2100> Let me build a test image and check on my pi3
[14:42] <mvo> sil2100: if you boot your VM, do you see a populated /etc/cloud ?
[14:42] <mvo> sil2100: x86 should be enough
[14:43] <sil2100> Building
[14:47] <sil2100> mvo: ah, I see what's happening, /etc/cloud is in writable-paths
[14:47] <sil2100> hmmm
[14:47] <mvo> sil2100: I have a theory
[14:48] <sil2100> But it should work
[14:49] <mup> PR core18#106 opened: static,hooks: make /etc/cloud a "synced" dir for now <Created by mvo5> <https://github.com/snapcore/core18/pull/106>
[14:49] <sil2100> AH
[14:49] <sil2100> Holy moly
[14:50] <mvo> sil2100: the rabbit hole is deeper
[14:50] <mvo> sil2100: I just added another paragraph
[14:50] <mvo> sil2100: anyway, I think this is the best we can do for now but we may need to deprecate ubuntu-images --cloud-config option
[14:50] <mvo> sil2100: or push it into cloud.cfg.d or something
[14:51] <mvo> sil2100: but even that has config :/
[14:53] <mvo> sil2100: well, actually I think we need to simply support cloud.cfg and ds-identify.cfg in the gadget
[14:54] <mvo> sil2100: anyway, the above PR will unblock the world
[14:58] <zyga> mvo: fun friday, it seems
[14:59] <sil2100> mvo: ok, this looks good, I'm just wondering - what is creating the empty /etc/cloud directory? Is it part of snap prepare?
[15:00] <sil2100> Since I don't remember we have anything in ubuntu-image that does that explicitly
[15:00] <zyga> https://github.com/snapcore/core18/search?q=%2Fetc%2Fcloud&unscoped_q=%2Fetc%2Fcloud
[15:00] <zyga> sil2100: it is 020-extra-files.chroot
[15:01] <mup> PR snapd#6311 opened: image: do not write empty etc/cloud <Created by mvo5> <https://github.com/snapcore/snapd/pull/6311>
[15:01] <mvo> sil2100: yeah, see 6311 (coming in a sec if mup is attentive)
[15:01] <sil2100> mvo: so maybe it'd be just better to remove that one?
[15:01] <sil2100> I mean, synced is fine I guess, but maybe we don't have to do it, all we need is to not create that empty dir?
[15:02] <mvo> sil2100: we could remove it its a good question, removing requires building the images with a snap command build with 6311
[15:02] <sil2100> ubuntu-image also won't put any files there, the only cloud-init stuff it puts in is the user-data
[15:03] <sil2100> hm
[15:03] <mvo> sil2100: snap prepare-image creaets the dir even if its empty
[15:03] <mvo> sil2100: thats a bug and then u-i puts the empty dir into the writable dir
[15:03] <mvo> sil2100: of course if we can teach u-i to not copy the empty dir that would be even nicer
[15:03] <sil2100> Ah, ok
[15:04] <mvo> sil2100: if you are comfortable with chaning u-i that works for me as well, slightly preferable
[15:04] <sil2100> mvo: ok, I guess it's just safest to go with synced then, since I see there's multiple places where the dir can pop up
[15:04] <mvo> sil2100: we still have a problem with gadgets that ship a cloud.conf because we no longer "merge" the configs but I think this is a feature :)
[15:04] <sil2100> mvo: since as per what zyga pasted we also create the empty /etc/cloud dir in core18 itself
[15:05] <mvo> sil2100: its fine if its in the core18 snap
[15:05] <mvo> sil2100: the problem is really that its also in /writable
[15:05] <mvo> sil2100: and snap prepare-image creates it and then u-i puts it there
[15:05] <sil2100> Ah, right!
[15:06] <sil2100> Stupid me
[15:06] <mvo> sil2100: I can poke a u-i to see if there is a single place to check
[15:06] <mvo> sil2100: no worries a) its friday b) its complicated
[15:06] <mvo> sil2100: (not necessarily in this order ;)
[15:06] <sil2100> mvo: it's certainly possible to do in u-i, no problem
[15:06] <sil2100> Problem is in releasing u-i again ;p
[15:06] <sil2100> i.e. not something to be done on Friday
[15:06] <mvo> sil2100: heh
[15:06]  * zyga hugs sil2100 and mvo
[15:07] <mvo> sil2100: as long as cachio can create correct images we can release monday ;)
[15:07]  * mvo hugs zyga
[15:07] <mvo> zyga: yeah, fun week so far
[15:09]  * sil2100 hugs zyga back
[15:09] <sil2100> mvo: ok, for now I approved the synced MP
[15:09] <sil2100> I'll prepare a hack for u-i in the meantime
[15:12] <mvo> sil2100: does the u-i snap embedd the snap command it uses?
[15:13] <mup> PR core18#106 closed: static,hooks: make /etc/cloud a "synced" dir for now <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/106>
[15:13] <zyga> so leap 42.3 *does* have new go 1.10
[15:13] <mvo> sil2100: I take it for now to unblock sergio - if we have something better we can revert without any harm
[15:14] <zyga> update from 1.9
[15:15] <sil2100> mvo: I don't think the u-i snap ships snap, I think it uses the system one
[15:15] <sil2100> I'll double check
[15:16] <mvo> sil2100: can I become part of the people who can trigger a build in https://code.launchpad.net/~ubuntu-core-service/+snap/core18 ?
[15:16] <mvo> sil2100: aha, nevermind - autobuild started
[15:17] <sil2100> mvo: of course you can o/
[15:30] <mvo> sil2100: fwiw, with an image generated with #6311 cloud-init is disabled so this part is fine
[15:30] <mup> PR #6311: image: do not write empty etc/cloud <Created by mvo5> <https://github.com/snapcore/snapd/pull/6311>
[15:34] <mvo> cachio: new coew18 is ready in beta
[15:39] <cachio> mvo, nice
[15:39] <cachio> I'll start after lunch
[15:39] <cachio> still without iternet at home
[15:39] <cachio> I think I'll need to go to another place
[15:40] <mvo> cachio: uh, good luck
[15:43] <sil2100> mvo: ok I have the u-i hack + tests in place, let me give it a spin in a moment
[15:44] <mvo> sil2100: cool
[15:44] <mvo> sil2100: \o/
[15:44] <mvo> sil2100: the "synced" change also works, tests are running on my pi3 and all the stragness is gone (noe more property set-name error in netplan etc)
[15:46] <sil2100> mvo: it's best to have more options to choose from I suppose ;) And I also think it'd be easier to fast-track ubuntu-image to release pockets than for instance snapd, since our livefs builders use archive packages for building the images
[15:51] <zyga> cachio: I solved the problem with opensuse leap
[15:51] <zyga> cachio: I will push a small update soon
[15:51] <zyga> cachio: but it might be best to refresh all opensuse images
[15:51] <zyga> though let's do this only after my fix is merged
[15:52] <cachio> zyga, sure
[15:52] <cachio> zyga, thanks for that fix
[15:58] <mvo> sil2100: yeah, I like the idea of doing it in u-i
[16:01]  * cachio lunch
[16:02] <cyphermox> mvo: property error for set-name in netplan?
[16:05] <sil2100> cyphermox: yeah, due to cloud-init meddling with the netplan config in some cases the netplan config ends up with a set-name: without a match:
[16:06] <sil2100> Like, it's injecting set-name when it shouldn't
[16:06] <cyphermox> yeah, ok
[16:06] <cyphermox> sil2100: to me "when it shouldn't" for set-name is pretty much always
[16:07] <cyphermox> I feel strongly like it's something that should be avoided at all costs, and kind of sad that it got in, because it's often a cause for confusion :(
[16:16] <sil2100> mvo: https://github.com/CanonicalLtd/ubuntu-image/pull/167 <- seems to work
[16:16] <mup> PR CanonicalLtd/ubuntu-image#167: Do not copy-over /etc/cloud to the rootfs if it's empty <Created by sil2100> <https://github.com/CanonicalLtd/ubuntu-image/pull/167>
[16:24] <sil2100> mvo: I'd like to wait for the autopkgtests to run for those
[16:24] <sil2100> s/those/this PR
[16:26] <mvo> sil2100: nice one
[16:35] <mvo> sil2100: btw, can you commit to https://github.com/snapcore/core18 now? if not we need to ask niemeyer  to give you commit access
[16:36] <mvo> sil2100: I slightly prefer your u-i workaround, if thats ok with you and if we can give cachio a way to create the images I'm +1 on this one and we can revert the core18 commit that uses a synced dir
[16:36] <niemeyer> mvo: sil2100 should have access, as long as he accepted the invitation to join the team
[16:36] <mvo> sil2100: but no super strong opinion, synced is also easy to change later it won't do any harm
[16:39] <sil2100> mvo: so I'd still keep the synced writable-path for now until I push out a new ubuntu-image - I guess it might be enough for us to have it in disco, then I guess it should go relatively fast
[16:40] <sil2100> mvo: not sure if we built core18 images before on disco
[16:40] <sil2100> (like, on the disco livefs)
[16:40] <mvo> sil2100: ok
[16:40] <mvo> sil2100: I leave this to you then
[16:40] <mvo> sil2100: thanks, fwiw, tests on the pi look good now still
[16:44] <sil2100> \o/
[17:02] <zyga> cachio: on second thought
[17:02] <zyga> cachio: please run "zypper refresh && zypper update" on all suse images
[17:02] <zyga> cachio: the fix is really equivalent to doing that and rebooting :/
[17:02] <zyga> so we may just as well do that
[17:06] <kyrofa> Hey zyga, did you have any other thoughts on https://forum.snapcraft.io/t/raspberry-pi-3-install-broken/8957/5 ?
[17:07] <zyga> kyrofa: I bet a beer that it's either ENOSPC or EROFS after ext4 corruption on flaky sd card
[17:09] <kyrofa> zyga, want me to suggest trying another SD card?
[17:09] <zyga> We should first get full logs from systemd
[17:09] <zyga> I don't think we got an answer since yesterday
[17:10] <kyrofa> Indeed, we have not
[17:10] <kyrofa> I'll go ping him on another forum :P
[17:20]  * zyga EODs
[17:20] <zyga> I'll check my PRs later
[17:24] <zyga> I love how this page looks like for communicating features to users https://github.com/github/VisualStudio/issues/1878
[17:41] <sil2100> mvo: ok, autopkgtests were happy with the branch, let me push it out to the archive
[17:42] <sil2100> mvo: I'll make it an interim release, e.g. not 1.6 per-se
[17:57] <sil2100> Actually hmm, I anyway need to get those changes out
[18:00] <sil2100> mvo: ubuntu-image 1.6 pushed to disco, SRUs to other series will follow
[18:39] <diddledan> can I specify something in snap.yaml (using snapcraft's passthrough) that will match the arch-triplet of the current system so that I can move $SNAP/usr/lib/$ARCH_TRIPLET/webkit2gtk-4.0 to /usr/lib via bind mount without adding every arch separately?
[18:39] <zyga> not using passthrough
[18:39] <diddledan> I obviously mean bindmounting it to /usr/lib/$ARCH_TRIPLET/webkit2gtk-4.0
[18:40] <diddledan> and I'm referring to using layouts
[18:40] <zyga> snapd doesn't support arch triplet because it's distro specific
[18:40] <zyga> we tried to and abandoned that
[18:40] <zyga> only snapcraft does
[18:40] <diddledan> so how do I do this?
[18:41] <zyga> manually
[18:41] <zyga> not sure
[18:41] <zyga> using snapcraft?
[18:41] <zyga> why are you using passthrough?
[18:41] <diddledan> for layouts
[18:41] <zyga> you can use layouts now without that
[18:41] <diddledan> layout isn't supported by snapcraft yet
[18:41] <zyga> it is
[18:41] <diddledan> nope
[18:41] <zyga> yep
[18:41] <zyga> since 3.0
[18:41] <zyga> but
[18:41] <zyga> for unknown reason you need to start using "base: core18"
[18:41] <zyga> while technically not required
[18:41] <zyga> it's a snapcraft bait and switch
[18:42] <diddledan> well that's silly
[18:42] <diddledan> :-p
[18:42] <zyga> I don't disagree :)
[18:42] <zyga> it would not be silly if we had shipped core16
[18:42] <zyga> and you could just say "base: core16"
[18:42] <zyga> "layouts: ..."
[18:42] <zyga> now it is silly
[18:44] <zyga> mvo: if you are working by any chance
[18:44] <zyga> could we ship core16 base snap alongside core18?
[18:44] <diddledan> hah: "You need multipass installed to build snaps which use the base keyword" <-- I've already got it!
[18:44] <diddledan> oh!
[18:45] <diddledan> it's trying to install multipass inside a multipass vm because I accidentally left SNAPCRAFT_BUILD_ENVIRONMENT=multipass in the environment
[18:45] <diddledan> turtles all the way down
[18:54] <pedronis> zyga: we really don't want to push core16 much yet
[18:55] <zyga> pedronis: then we should not marry core18 with layouts in snapcraft IMO
[18:55] <pedronis> zyga: did I say we should
[18:55] <zyga> we do :)
[18:55] <zyga> or did
[19:01] <pedronis> also for clarity: core16 is not stable yet
[19:01] <diddledan> well blow me down with a feather! you're right, using base:core18 does indeed enable layout: to work
[19:09] <pedronis> fedora tests are a mess atm
[19:10] <diddledan> yey?
[19:17] <zyga> pedronis: shall I disable it?
[19:18] <pedronis> zyga: maybe, it's causing a lot of red atm
[19:18] <zyga> on it
[19:22] <cachio> sil2100, hey, still don't have internet at home
[19:22] <cachio> sil2100, I'll make the validation over the weekend and I'll send the results
[19:22] <zyga> pedronis: done
[19:22] <cachio> so we can continue to stable
[19:23] <mup> PR snapd#6312 opened: spread: disable fedora-29-64 <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6312>
[19:24] <pedronis> cachio: if you are sending out mails about the results, please cc also me
[19:24] <pedronis> thank you
[19:24] <pedronis> zyga: thx, let's see if that one gets green
[19:32] <cachio> pedronis, sure
[19:32] <cachio> I think I'll send the results tomorrow
[19:33] <cachio> pedronis, today I am using my phone internet and it goes so slow
[19:43] <sil2100> cachio: thanks!
[19:45] <cachio> zyga, opensuse update failed
[19:46] <cachio> zyga, https://paste.ubuntu.com/p/pC9bphSTgr/
[19:46] <cachio> using master
[20:01] <zyga> cachio: this error shows up when you update and not reboot
[20:57] <mvo> zyga: we talked about this, ideally we would just make core an alias for core16 in snapd
[20:57] <mvo> zyga: so that snapd understands that it just needs core for this
[20:57] <zyga> mmm
[20:58] <zyga> mvo: anyway, not urgent
[20:58] <zyga> mvo: I'm trying to land https://github.com/snapcore/snapd/pull/6312
[20:58] <zyga> if you want to look
[20:58] <zyga> it should help
[20:58] <mup> PR #6312: spread: disable fedora-29-64 <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6312>
[20:59] <mvo> zyga: sure
[21:10] <zyga> ha
[21:10] <zyga> you were faster
[21:11] <mup> PR snapd#6312 closed: spread: disable fedora-29-64 <⚠ Critical> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6312>
[21:11] <pedronis> it's merged
[21:11] <zyga> thank you :)
[21:12] <zyga> I restarted a few PRs
[21:12] <zyga> let's see
[21:12] <zyga> mvo: I left a few comments on https://github.com/snapcore/snapd/pull/5845
[21:13] <mup> PR #5845: interface: add new `{personal,system}-files`  interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/5845>
[21:13] <zyga> not sure if you want to do anything about it
[21:13] <zyga> or just merge it
[21:13] <zyga> it's green
[21:23] <roadmr> ohai zyga
[21:23] <zyga> hey :)
[21:23] <roadmr> how's it going? is the glue trick keeping you safe from spaghetti?
[21:23] <zyga> haha
[21:23] <zyga> yes!
[21:23] <zyga> it's a miracle
[21:24] <zyga> printing on 1st go
[21:24] <zyga> I'm shocked
[21:24] <roadmr> great! how do you unglue the piece from the bed when it's done?
[21:24] <zyga> should have learned this months ago
[21:24] <zyga> the bed comes off and you just bend it slightly
[21:24] <zyga> things pop off without any issues
[21:25] <roadmr> zyga: how'd you find out about this?
[21:25] <zyga> about the glue?
[21:25] <zyga> read that it helps
[21:25] <zyga> found some information on the internet by chance
[21:27] <roadmr> interesting, sounds like it'd be a very well-known fact, as I think it's a common problem
[21:27] <roadmr> glad it's working well now :)
[21:27] <roadmr> zyga: hey a snapd-related question - you may know and save me hours of dredging through the code base
[21:27] <zyga> it may be well known, I'm happy I know it too :)
[21:28] <zyga> how can I help?
[21:28] <roadmr> zyga: do you remember at some point, snap deltas were disabled for armhf devices because $REASONS?
[21:29] <zyga> because CPU uber slow
[21:30] <roadmr> zyga: hm, and were they enabled at some point? or are armhf devices still delta-less?
[21:30] <zyga> I don't know that
[21:30] <zyga> I don't know how the delta was disabled
[21:31] <roadmr> zyga: ok.. I found something about enabling deltas for core devices, back in February, but that seems to be arch-agnostic
[21:31] <roadmr> zyga: ok, no problem - thanks! maybe I'll ask ogra whom I remember talked about this at some point
[21:33] <ogra> roadmr, they were in fact not enabled in the beginning because nobody had measured the performance for single core arm, but Chipaca did some research at some point, i thought they were enabled later on
[21:35] <roadmr> hi ogra ! yes, sorry, as I'm here grilling you guys I'm also analyzing download logs and it looks like they were enabled at some point; I'm trying to determine when (basically which version of snapd did that). For instance, I see some armhf devices with  2.35 getting deltas, while others with 2.32 seem to not get deltas
[21:36] <roadmr> ogra, zyga : if I can pinpoint the version that enabled this, I can tell the guy using that old 2.32 to upgrade to 2.3x so they can benefit from awesome bandwidth savings for free
[21:36] <roadmr> if Chipaca is the one who did it, I can ask him on Monday; I'm in no rush :)
[21:45] <mup> Bug #1808593 opened: AppArmor denies ptrace for ufw snap in lxc after purging ufw <Snappy:New> <https://launchpad.net/bugs/1808593>
[21:48] <mup> Bug #1808593 changed: AppArmor denies ptrace for ufw snap in lxc after purging ufw <snapd:New> <https://launchpad.net/bugs/1808593>
[22:08] <mvo> zyga: I want to address the comments but not today :) thanks for those!
[22:08] <pedronis> roadmr: it was done in february, not by John
[22:09] <roadmr> pedronis: https://github.com/snapcore/snapd/pull/4639 ?
[22:09] <mup> PR #4639: store: enable deltas for core devices too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4639>
[22:09] <pedronis> yes
[22:09] <roadmr> pedronis: and that went out in snapd 2.33.1?
[22:10] <thiras> I'm getting "ENOENT: no such file or directory, lstat '/snap/code'"
[22:10] <thiras> at the vscode
[22:10] <thiras> any idea what is this?
[22:11] <pedronis> roadmr: 2.33 already if I believe the changelog
[22:11] <roadmr> pedronis: yay thanks
[22:12] <pedronis> roadmr: yes, 2.33
[22:13] <roadmr> pedronis: great! thanks for helping confirm.
[22:13] <roadmr> this matches what I see in logs, btw
[22:13] <roadmr> thanks for the help folks, I appreciate it, I know it's late for you
[22:37] <mup> PR snapd#6288 closed: cmd/snap-confine: refactor call to snap-update-ns --user-mounts <Per-user mount ns  🐎> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6288>
[22:58] <mup> PR snapd#6307 closed: systemd/systemd.go: add missing tests for systemd.IsActive <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6307>
[22:58] <mup> PR snapd#6309 closed: overlord/ifacestate: addHotplugSeqWaitTask helper <Hotplug 🔌> <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6309>
[22:59] <mup> PR snapd#6263 closed: Retrieving all pages for 'find' command, not only one <Created by WiseRaccoon> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6263>
[23:53] <thiras> is there a way to check if a local snap file (not downloaded from Canonical) has right to access to disk?


[01:45] <Thommas> hello. can someone answer my question. I need different perspective on this issue.
[01:46] <Thommas> hello
[01:48] <Thommas> hi
[01:48] <LeoNerd> Ask your question, don't wait for someone to reply
[01:49] <Thommas> Should we subsidize child rearing?
[01:49] <LeoNerd> There's 117 of us in here, we're not all going to say "go ahead"
[01:49] <Thommas> sorry :/
[01:51] <fullermd> Sure, but not child fronting.  Child siding is great for property values though.
[01:52] <Thommas> what about my question. child rearing
[01:52] <fullermd> I'm not sure.  Is there a bzr plugin for that?
[01:53] <fullermd> (mind you, I'll bet version control would be handy for that...)
[01:58] <poolie> !?
[01:58] <poolie> Thommas: no, i don't think we should
[01:58] <poolie> or are you talking about children in a vcs tree?
[01:59] <Thommas> can you tell me y
[02:04] <poolie> uh, do you have the wrong channel perhaps?
[02:13] <poolie> lifeless: "ker-lick...."
[02:15] <maxb> jelmer: Hi. Apparently we still have a narrow window open to slot 2.2.1 into maverick-release. I guess it will be one of us who does the packaging.
[02:17] <lifeless> poolie: wasn't needed :)
[02:19] <fullermd> Shucks.  I was looking forward to his plugin   :(
[02:55] <poolie> maxb, maybe pitti can do it?
[02:57] <maxb> Does pitti do bzr stuff? I assume he was commenting on the bug in an ubuntu-sru / ubuntu-release approver capacity
[02:57] <maxb> Anyway, I've already done 2.2.1 in the PPA
[02:58] <maxb> So really what we need now is some aggressive verification of the PPA build as specified by the microreleasexception
[03:17] <poolie> ok
[03:17] <poolie> we should also check the diff by hand there
[03:30]  * maxb wonders what to call this package
[03:30] <maxb> 2.2.1-0ubuntu1 I suppose
[04:53] <poolie> maxb, i'm running 2.2.1 from the ppa on maverick and it looks ok so far
[04:53] <poolie> and i read the diff, and posted on bug 636930 that it looks ok to me
[04:53] <ubot5`> Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 5, heat: 48)" [High,Triaged] https://launchpad.net/bugs/636930
[05:43] <GungaDin> is it possible to change the message of a commit?
[05:56] <sidnei> GungaDin, bzr uncommit then bzr commit again?
[05:56] <stub> So being a Launchpad developer I run with the beta PPA. I just got a crash, and it attempted to go via apport, but apport blocks it as I don't have a genuine Ubuntu package. This workflow might need tweaking.
[05:57] <sidnei> stub, +1 for fixing that!
[05:58] <poolie> stub, that's interesting, i thought that was fixed
[05:59] <poolie> please file a but explaining just what happened
[06:00] <stub> Bug #391015  is inprogress , which seems to be the apport issue
[06:00] <ubot5`> Launchpad bug 391015 in Bazaar "apport package hook for Bazaar (affected: 1, heat: 7)" [Medium,In progress] https://launchpad.net/bugs/391015
[06:00] <stub> Oh - I'm running lucid on my main machine so apport changes might not be backported from maverick
[06:05] <GaryvdM> jam: Don't know if you are still awake? The ec2 instance is still up.
[06:16] <poolie> hello GaryvdM
[06:16] <poolie> GaryvdM: do you want me to shut it down?
[06:16] <GaryvdM> Hi poolie
[06:17] <GaryvdM> poolie: Yes please
[06:27] <poolie> GaryvdM: done
[06:27] <poolie> do you have a gpg key?
[06:29] <GaryvdM> poolie: Yes: 018A3A1D
[06:29] <GaryvdM> poolie: The one you signed previously.
[08:07] <vila> hi all !
[08:09] <GaryvdM> Hi vila
[08:10] <vila> GaryvdM: hey ! You're up early or late ? :)
[08:11] <GaryvdM> During work. :-) Having a lull after the storm.
[08:12] <vila> GaryvdM: hehe, thanks for your hard work there !
[08:20] <poolie> hi there vila
[08:25] <GaryvdM> poolie: Got the mail - thanks
[08:26] <poolie> np, thanks for your help
[08:57] <poolie> hi vila, i might ask pitti about the SRU, if you haven't today
[08:58] <vila> poolie: ok. Thanks for adding the diff, I should have thought about that...
[08:59] <vila> poolie: and about the 323111-orphans* reviews ?
[09:00] <lifeless> poolie: do it asap, RC freeze hit about 5 hours back
[09:34] <vila> poolie: I'm not sure I understand: "i might ask pitti about the SRU, if you haven't today", can you ping me when you have talked to pitti ?
[09:35] <poolie> vila i did talk to him
[09:35] <poolie> apparently it froze a few days ago and it's too late for the release but it can go in as an SRU soon afterwards
[09:35] <poolie> we should have asked for it sooner
[09:38] <poolie> vila, we should get maxb or jelmer to upload the package
[09:38] <vila> poolie: ok, so what should we do then ? ha.ok
[09:40] <vila> maxb: is it what you were referring to earlier when you said:
[09:40] <vila> * maxb wonders what to call this package
 2.2.1-0ubuntu1 I suppose
[09:41] <poolie> right
[09:45] <maxb> vila, poolie oh, asked I asked ScottK last night and he seemed to think a post-RC release pocket upload was still an option
[09:45] <poolie> oh, ok
[09:45] <poolie> well, can you do whatever seems best and legal?
[09:46] <maxb> Well, I have no upload perms, so I'll have to loiter on IRC and beg a sponsor
[09:46] <vila> ...and update bug #636930 ?
[09:46] <ubot5`> Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 5, heat: 48)" [High,Triaged] https://launchpad.net/bugs/636930
[09:46] <maxb> Also, anyone know how we decide what bugs to list in debian/changelog?
[09:47] <maxb> jelmer: around? ^^^
[09:47] <jelmer> maxb: otp
[09:47] <maxb> k
[09:52] <jelmer> maxb: hi
[09:52] <poolie> hi jelmer, maxb
[09:53] <maxb> jelmer: Hi. So I started to prepare 2.2.1-0ubuntu1 last night, and of all the minor points, got stuck on wondering how we usually decide what bugs to reference in the debian/changelog
[09:53] <jelmer> 'morning poolie
[09:54] <jelmer> maxb: we mention the ones that were closed by this particular release
[09:54] <jelmer> or more specifically, the ones fixed by this upload since the previous upload.
[09:55] <maxb> so... everything with a LP id in NEWS?
[09:58] <maxb> jelmer: ok, my hesitation was that there don't seem to be enough entries under 2.2.0-1 to account for that policy
[10:00] <maxb> for example,
[10:00] <maxb> * Recursive binding for checkouts is now detected by bzr. A clear error
[10:00] <maxb>   message is shown to the user. (Parth Malwankar, #405192)
[10:00] <maxb> in NEWS but not debian/changelog
[10:00] <jelmer> maxb: Those bug ids are debian bugs, not launchpad bugs
[10:00] <jelmer> maxb: where I close bugs with launchpad ids it would only be for bugs that have a ubuntu bug task
[10:01] <maxb> Ah!, so only list in debian/changelog open ubuntu bugtasks to be closed?
[10:02] <maxb> rather than the entire contents of NEWS
[10:02] <stewart> jelmer, hi! i'm having some issues with rebase. I'm basically wanting to rewrite history before a certain revision in the repository so that revision 3 (and all after it) are the same, but that the history from another repository is inserted before revision 3. i can't seem to get it to recognise that the directories named the same in each repo are actually the same (i just get foo.moved)
[10:02] <stewart> jelmer, any ideas/suggestions?
[10:02] <jelmer> maxb: yep
[10:04] <maxb> jelmer: great. Well then, I need to go to work now, but I could put together a package at lunchtime and hunt for a sponsor
[10:06] <jelmer> stewart: bzr-rebase doesn't really help with different file ids
[10:06] <stewart> jelmer, i had feared that :)
[10:09] <maxb> stewart: Maybe you could use bzr-fastexport/import, plus some manual hackery on the streams?
[10:10] <stewart> maxb, that's my next thought
[10:19] <mgz> morning all.
[10:23] <vila> mgz: morning marting ;)
[10:23] <mgz> ;_;
[10:24] <vila> mgz: I still have a few minutes to joke about this typo, your fix is playing on pqm ;)
[10:31] <jelmer> maxb: thanks for taking care of that, btw!
[10:35] <vila> mgz: wow, I couldn't believe there are *no* thread leaks in bzr.dev (at least in the last runs I did) and just create one to be sure... and it was detected :)
[10:36] <vila> for the record, when I prepared 2.0.6 there was ~2500 leaks
[10:38] <mgz> nix had that many? there's still work to do on window, though.
[10:39] <mgz> and urk, I need to leave already, wanted to review the ~mgordan branch before I went
[10:39] <vila> mgz: yup, but they tend to be stealth... :-/
[12:29] <jml> jam: I'm really really sorry I haven't got to your patches yet.
[12:29] <jml> jam: I haven't forgotten them though.
[12:36] <zyga> my friend is having problems using bzr send
[12:36] <zyga> he is behind a firewall
[12:36] <zyga> and cannot push using regular methods
[12:36] <zyga> gsc, please pastebin the command you executed and the output of that command
[12:37] <zyga> it seems that bzr thinks there are no changes between his tree and the public tree
[12:37] <zyga> gsc, could you do bzr missing and tell us if it shows anything?
[12:37] <gsc> zyga: Using saved parent location: http://bazaar.launchpad.net/~linaro-maintainers/linaro-image-tools/linaro-image-tools/ You have 1 extra revision(s): ------------------------------------------------------------ revno: 121 committer: r65073 <r65073@r65073-imx51> branch nick: linaro-image-tools timestamp: Wed 2010-09-29 17:09:31 -0400 message:   Add imx51 for --dev option support.
[12:38] <gsc> zyga: sorry, how to use pastebin, i'm new to irc
[12:38] <zyga> gsc, go to pastebin.ubuntu.com and paste long output there
[12:40] <gsc> zyga: and then?
[12:40] <zyga> gsc, paste the url of the result ehre
[12:40] <gsc> zyga: how can you guys see that?
[12:40] <gsc> http://pastebin.ubuntu.com/502582/
[12:41] <zyga> gsc, could you try a shorter version, bzr send -o foo.bundle
[12:42] <gsc> http://pastebin.ubuntu.com/502587/
[12:44]  * zyga has no idea what's wrong
[12:44] <zyga> vila, ping
[12:45] <maxb> Please pastebin the output of 'bzr info' in the local branch
[12:46] <gsc> http://pastebin.ubuntu.com/502588/
[12:47] <maxb> Ah, you are being caught out by that bogus definition of submit branch
[12:47]  * zyga never understood what submit branch was
[12:47] <maxb> It is the default location for 'bzr send'ing against
[12:48] <gsc> how should I state the submit branch?
[12:48] <maxb> Just manually edit the .bzr/branch/branch.conf and delete the line defining the submit branch
[12:49] <gsc> maxb: done. what's the correct one?
[12:49] <maxb> Or, bzr send --remember actual-submit-branch
[12:50] <gsc> maxb: i am new to bzr, what's the "actual-submit-branch" in my case?
[12:50] <maxb> uh, lp:linaro-image-tools, I suppose
[12:50] <maxb> So, try bzr send -o foo.bundle --remember lp:linaro-image-tools
[12:51] <gsc> maxb: bzr: ERROR: Connection error: Couldn't resolve host 'xmlrpc.edge.launchpad.net' [Errno -2] Name or service not known
[12:51] <gsc> maxb: fyi, i am beind a firewall
[12:51] <zyga> maxb, he's behind a firewall of some kind
[12:52] <maxb> oh, ok, I guess you'll need to use the long form http://bazaar.launchpad.net/~linaro-maintainers/linaro-image-tools/linaro-image-tools/ then
[12:52] <gsc> Bundling 1 revision(s).
[12:52] <gsc> succeded?
[12:53] <maxb> Sounds like it
[12:54] <zyga> maxb, thanks :)
[12:54] <gsc> maxb: then what's the url for my branch?
[12:54] <maxb> gsc: I don't quite understand your question?
[12:54] <zyga> gsc, there is none
[12:54] <zyga> gsc, you did not publish your branch
[12:55] <zyga> gsc, you made something that you can email
[12:55] <zyga> gsc, without ssh access you cannot publish a branch on lp
[12:55] <gsc> understood.  Thanks a lot, zyga and maxb.
[12:55] <zyga> gsc, well actually you can but it's complex
[12:56] <zyga> gsc, if you can make your branch visible via http
[12:56] <zyga> gsc, you could ask launchpad to mirror your branch
[12:56] <gsc> zyga: sound complicated, forget about it. thanks zyga.
[12:57] <gsc> quick question: how can I change my name and email output by bzr whoami?
[12:58] <zyga> gsc, just pass them as arguments
[12:58] <zyga> gsc 'bzr whoami zygmunt krynicki <my@email>
[12:59] <gsc> zyga: cool, thanks
[12:59] <maxb> Don't forget to quote the entire string
[13:00] <gsc> maxb: yeah, I'm seeing the example in help. Thanks.
[13:24] <vila> gsc: 'bzr send' uses your 'public' branch to reduce the size of the bundle, so you can use any branch that is in the ancestry of your branch, or even the submit branch itself
[13:25] <gsc> vila: Thanks for the info
[13:42] <mgedmin> oh woe is me: I used bzr commit in a svn checkout by accident, now the working dir is all fscked up :(
[13:46] <mgedmin> oh, look removing $Id$ lines and bzr committing seems to have fixed it
[13:47] <mgedmin> no it hasn't
[13:47] <mgedmin> grr!
[13:50] <mgedmin> in case anybody cares: the error is that on svn commit, I get svn: Checksum mismatch for '/home/mg/src/.../.svn/text-base/filename.svn-base'; expected: '2fa79c790b164142e92763cbafd898b7', actual: '01f96e4634bb165ec8d95c4e6ade8e9e' and it aborts the commit
[14:05] <jml> vila: do you use an emacs frontend to bzr?
[14:06] <vila> jml: dvc
[14:07] <vila> but only slightly, the plan is to move to vc itself
[14:07] <jml> vila: your plan or someone else's?
[14:07] <vila> mine :)
[14:07] <dash> dvc is pretty good
[14:08] <vila> dvc targets *all* dvcs and progress is kind of slow and I can't... easily parse the weird lisp macros they use (which more or less forbids debugging)
[14:08] <dash> heh heh
[14:08] <dash> well it's better than eclipse support for bzr
[14:09] <jml> dash, vila: know anyone who's actually using vc for bzr?
[14:09] <vila> it serves me well and did so for the last 4 years but I use only a tiny part of: dvc-status and dvc-diff
[14:09] <vila> jml: emacs hackers ?
[14:09] <dash> jml: i have, briefly, but it just didn't do as much
[14:09]  * jml nods sagely
[14:10] <dash> the diff support is definitely the dvc feature i use the most
[14:10] <jml> dash, vila: btw, have I shown you lp:difftodo before?
[14:10] <vila> jml: ideally vc.el should use direct access to bzrlib instead of bzr
[14:10] <dash> jml: hm! no
[14:10] <vila> jml: shown no, mentioned, yes, several times, did I install it ? stupidly no :(
[14:10] <jml> dash: it's a thing that parses Python diffs, extracts new/modified XXX comments and formats them in a compile-mode friendly way
[14:11] <dash> Fun.
[14:11] <jml> there's a bzr plugin in it, and it's pretty easy to hook up to emacs.
[14:11] <jml> M-x bzr-todo RET
[14:11] <vila> jml: spawning an external bzr or using python from emacs ?
[14:12] <jml> vila: spawning.
[14:12] <vila> :-}
[14:12]  * vila should stop hoping too much :-/
[14:12] <vila> jml: sorry, that was totally unrelated to difftodo
[14:12] <jml> vila: np :)
[14:14] <vila> jml: anyway, as far as emacs and bzr are concerned, the swiss army knive is still diff-mode IMHO when I'm not editing a file, I'm more or less always in a diff-mode buffer (dvc itself only slightly specialize it by adding a list of files at the top and some navigation)
[14:16] <vila> jml: which is why I still haven't installed difftodo, 'alt-z m' brings me a 'diff -rsubmit:' buffer where my TODO/FIXME *are*
[14:16] <jml> vila: ahh, I see.
[14:17] <jml> vila: sometimes having the list can be useful. it's generated from 'di -r submit:'
[14:17]  * vila nods
[14:17] <vila> I still plan to try it
[14:18]  * vila puts it on its TODO now that it's a wikkid instance
[14:18] <jml> heh heh
[14:40] <d1b> hi
[14:40] <d1b> question what file handles https connections
[14:40] <d1b> and can you link me to it ?
[14:40] <d1b> please ;)
[14:42] <GaryvdM> d1b: I think there are more than one implementations in bzr. one is the std python library urllib2
[14:43] <GaryvdM> d1b: What for?
[14:43] <d1b> GaryvdM: i might have a vul to report
[14:43] <d1b> but first i need to see the code
[14:43] <d1b> im on a bug reporting spree atm
[14:43] <GaryvdM> Let me look for you
[14:44] <mgz> it's known that urllib2 doesn't check certs, it's the main reason it's not the only module used
[14:44] <GaryvdM> d1b: Hint: bzrlib/transports
[14:44] <d1b> GaryvdM: thank you - just the file in a http location to your bzr thing
[14:44] <d1b> GaryvdM: im not looking ;)
[14:44] <d1b> im just reporting it if exists
[14:44] <d1b> and i need to see code to do that
[14:45] <d1b> mgz: please link me
[14:45] <mgz> pycurl however does check.
[14:45] <d1b> mgz: but you aren't using pycurl anymore i thought
[14:45] <d1b> bzr doesn't dep on it
[14:45] <d1b> iirc
[14:46] <Glenjamin> it uses it if its there
[14:46] <d1b> Glenjamin: and if it isn't ?
[14:46] <d1b> because by default it won't be
[14:46] <d1b> on ubuntu
[14:48] <GaryvdM> d1b: it's a suggested dep. Maybe we should bump it to a recommended dep.
[14:48] <GaryvdM> d1b: A bug report would be good.
[14:49] <d1b> GaryvdM: dude
[14:49] <d1b> first link me to the file
[14:49] <d1b> i might have a real vul to report
[14:49] <d1b> if you can't do that
[14:49] <d1b> then fail
[14:49] <GaryvdM> bzrlib/transports/http/(_pycurl.py|_urllib.py)
[14:50] <GaryvdM> sorry transport not transports
[14:51] <d1b> um... http://launchpad
[14:51] <d1b> link
[14:51] <d1b>  http://bazaar.launchpad.net/ ...
[14:51] <mgz> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/files/head%3A/bzrlib/transport/http/
[14:51] <d1b> thanks
[14:51] <d1b> and urllib is used if pycurl isn't available right
[14:52] <mgz> yup.
[14:53] <d1b> i have a vul to report
[14:53] <d1b> 50% sure atm
[14:53] <d1b> confirming now
[14:53] <d1b> ok 85% sure
[14:53] <d1b> by default on ubuntu with bzr installed (as pycurl won't be) you are vulnerable to a mitm attack
[14:54] <d1b> as per python bug  http://bugs.python.org/issue1589
[14:54] <dash> d1b: but bzr supports signed revisions, so it doesn't matter. :)
[14:54] <d1b> as you do not check against hte common name
[14:54] <d1b> dash: supports != use
[14:54] <vila> mgz: meh, see my last comment on https://code.edge.launchpad.net/~gz/bzr/use_testtools_timings_625594/+merge/36784
[14:54] <mgz> yeah vila, I just this second read it.
[14:54] <vila> mgz: wth ?
[14:54] <d1b> so by default i can mitm your bzr clients
[14:54] <d1b> gg
[14:55] <mgz> d1b, go ahead and file a report, it'll get to the right people.
[14:55] <d1b> mgz: it shall be done :)
[14:56] <d1b> ill file it against bzr in ubuntu
[14:56] <d1b> but it probably applies to debian / every other project who won't have pycurl isntalled
[14:56] <mgz> vila: I don't quite understand, but I'll try to. this code makes me cry.
[14:57] <d1b> wait
[14:57] <d1b> i think you are now deping on it
[14:57] <d1b> not sure
[14:57] <d1b> weird
[14:58] <d1b> im still going to report it, it exists against any client without pycurl installed
[14:58] <d1b> which is a possability
[14:58] <vila> d1b: people who care about cert verification should use pycurl
[14:58] <vila> d1b: this is known
[14:58] <d1b> vila: yes but aren't told this
[14:58] <d1b> vila: where is it filed?
[14:58] <d1b> in bzr?
[14:58] <d1b>  or told to people
[14:59] <d1b> where do i report the bug to?
[14:59] <d1b> nm found it
[15:00] <vila> https://answers.edge.launchpad.net/bzr/+faq/590
[15:00] <d1b> vila: that has nothing to do with this bug
[15:00] <d1b> read what it says
[15:00] <vila> d1b: I read it long ago
[15:00] <d1b>  Once certificate validation is implemented
[15:00] <d1b> for urllib (easy for 2.6), we can get rid of pycurl. For python
[15:00] <d1b> 2.4 and 2.5 though, that will mean replacing the pycurl
[15:00] <d1b> dependency by a python-https[1] dependency.
[15:00] <d1b> that means
[15:00] <d1b> that the vul im reporting right now
[15:01] <d1b> is kind of there ;)
[15:01] <d1b> vila: because
[15:01] <d1b> ssl was implemented using socket for python 2.6 >
[15:01] <d1b> in bzr
[15:01] <vila> d1b: I wrote this faq, I know what is said there :)
[15:01] <d1b> vila: ok
[15:01] <d1b> so the comment states that when ssl is done using socket and you aren't supporting 2.5 / 2.4 python -> use that
[15:01] <d1b> and drop pycurl
[15:02] <d1b> and your comment here is not really true.
[15:02] <d1b> because now there is an attempt to validate the ssl
[15:02] <d1b> that's why socket is used
[15:02] <d1b> erh ssl()
[15:02] <d1b> but that implemenation is wrong
[15:02] <vila> yes, and the plan is to implement the cert verification *on top* of what the ssl module provides
[15:03] <d1b> vila: at the present time you are vul :)
[15:03] <d1b> get back to me when that is done
[15:03] <vila> hehe, patches welcome
[15:03] <vila> if you want cert verification *now* install pycurl
[15:03] <d1b> patch is remove urllib
[15:03] <d1b> only suport pycurl
[15:03] <d1b> from me ;)
[15:04] <vila> d1b: sure, as long as you had support for ctrl-c pycurl and prompting for passwords and all niceties provided by urllib ;)
[15:04] <vila> s/had/add/
[15:04] <d1b> security >
[15:05] <vila> d1b: use ssh
[15:06] <d1b> vila: this is true :)
[15:06] <d1b> except then you need ssh ;)
[15:06] <vila> d1b: now you're talking about convenience :)
[15:07] <d1b> confirmed
[15:07] <d1b> vila: bzr does not dep on pycurl
[15:07] <vila> d1b: but more importantly, what will a mitm attack will gives ?
[15:07] <d1b> a copy of the repo
[15:07] <d1b> and this is bad for private repos
[15:07] <d1b> aka your corporate users
[15:08] <d1b> and also commit access ;)
[15:08] <vila> which can 1) use pycurl (which is still the default for https if installed) 2) use ssh 3) use private networks
[15:08] <d1b> vila: if installed
[15:08] <d1b> but it isn't a dep!
[15:08] <d1b> it suggests pycurl
[15:08] <d1b> it doesn't dep pycurl
[15:09] <d1b> woops!
[15:09] <vila> no, it was a deliberate decision
[15:09] <d1b> i should state that this is not true i just remembered
[15:09] <d1b> i have recommends disabled
[15:09] <d1b> don't nkow if the default bzr will do that ..
[15:09] <d1b> suggests will be installed right?
[15:09] <vila> I advocate keeping it but the consensus was that the vast majority of users just don't verify certs anyway
[15:10] <d1b> so it should be a dep in anycase
[15:10] <d1b> and not a suggests
[15:12] <d1b> ok via synaptic
[15:12] <d1b> it isn't pulling in pycurl..
[15:12] <d1b> nor via apt-get
[15:12] <d1b>  http://pastebin.com/Ec0cJ0eA
[15:13] <d1b> so recommends is not the same as suggests
[15:13] <d1b> vila: yeah?
[15:14]  * d1b reports
[15:15] <vila> d1b: you'd better add your comments to the existing one so your new bug doesn't get marked as duplicated
[15:15] <d1b> vila: yeah dude how do i make a new bug?
[15:15] <d1b> launchpad is confusing
[15:15] <d1b> nm gotit
[15:15] <d1b> had to put the url in manually can't find a link
[15:17] <vila> let me introduce you to our lovely bot: bug #82086
[15:17] <ubot5`> Launchpad bug 82086 in Bazaar "pycurl transport causes tracebacks if the server's SSL cert cannot be verified. (affected: 3, heat: 43)" [Medium,Confirmed] https://launchpad.net/bugs/82086
[15:17] <vila> thanks ubot5`
[15:17] <d1b> vila: ;)
[15:20] <d1b> vila: reported
[15:20] <d1b>  https://bugs.edge.launchpad.net/bzr/+bug/651161
[15:20] <ubot5`> 'Error: Could not parse data returned by Launchpad: HTTP Error 401: Unauthorized\nResponse headers:\n---\ncontent-length: 21\ncontent-type: text/plain\ndate: Wed, 29 Sep 2010 14:20:55 GMT\nserver: zope.server.http (HTTP)\nstatus: 401\nvary: Accept-Encoding\nvia: 1.1 wildcard.edge.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\nBug 651161 is private\n---\n (https://launchpad.net/bugs/651161)'
[15:21] <d1b> private?
[15:21] <d1b> what no
[15:21] <d1b> this is already public via irc
[15:21] <d1b> fixed
[15:21] <mgz> ha, ubot fail. you ticked the 'security' box I take it?
[15:22] <d1b> mgz: yeah ;)
[15:22] <d1b>  https://bugs.edge.launchpad.net/bzr/+bug/651161
[15:22] <ubot5`> Launchpad bug 651161 in Bazaar "bzr fails to verify ssl validity in https connections - by default --> as pycurl isn't a dep only a suggestion (affected: 1, heat: 260)" [Undecided,New]
[15:22] <mgz> right, can just edit private off via web interface.
[15:22] <d1b> there we go
[15:51] <MTecknology> I pulled a branch, then had to overwrite the latest change to the branch, now I get an error when I try to pull the branch from another location - how can I tell it to ignore this last change?
[15:52] <MTecknology> It says the branches diverged.. I want them back together..
[15:52] <vila> MTecknology: pull --overwrite
[15:53] <MTecknology> :D
[15:53] <MTecknology> vila: awesome- thanks
[16:02] <CardinalFang> Hi all, jelmer.  I'm trying to use the bzr-svn plugin for the first time, (with versions in Ubuntu Maverick,) and I can't figure out what I'm doing wrong, if anything.
[16:02] <CardinalFang> https://android-client.forge.funambol.org/source/browse/android-client/
[16:03] <CardinalFang> Branching "https://guest@androi" gets me 'unknown bzrdir format ""'
[16:04] <CardinalFang> No http-basic "guest@" and I get 'No route to host' error (perhaps some SSL problem?).
[16:05] <CardinalFang> Er, no , that gets me 'Unable to handle http code 401', even though I (think) I set "user = guest" in my locations.conf .
[16:05] <CardinalFang> Finally, "svn://" gets me the no-route-to-host.
[16:07] <CardinalFang> Hmm, the doc says the plugin can do several things, but none of them is "branch".  I don't think "pull" counts.
[16:12] <Glenjamin> CardinalFang: whatever location you'd pass to svn checkout, bzr branch/pull/checkout should accept
[16:13] <Glenjamin> oh, i see you've got some pycurl problems, try using https+urllib://
[16:13]  * CardinalFang tries.
[16:14] <CardinalFang> Hell yeah.  Glenjamin, she goes!
[17:40] <jeremyw> I see in bzrlib.builtins.cmd_ls.run(), there is a cleanup like this: self.add_cleanup(tree.lock_read().unlock)
[17:40] <jeremyw> What's that for?
[17:42] <mgz> jeremyw: it's a slightly confusing spelling of "this operation needs a read lock for the duration, that then gets unlocked"
[17:44] <mgz> roryy: was hoping to catch you, one of the things we need before your branch can land is for you to do this: <http://www.canonical.com/contributors>
[17:45] <roryy> mgz: hi.  was wondering about that, assumed the patch was too small
[17:45] <roryy> mgz: will get on it
[17:46] <mgz> great, shout if you have any questions.
[17:47] <jeremyw> mgz: Thanks.
[17:57] <roryy> mgz: send it to<EMAIL_ADDRESS>and Martin Pool?
[17:57] <mgz> yup.
[17:58] <roryy> ok, done
[18:04] <mgz> cool. when australia wakes up you'll get added to the right team.
[18:04] <fullermd> Australia's so lazy.  Sleeping all day, every day...
[18:07] <jeremyw> Anyone got a minute to help me better understand locking?  I see this stuff is abstracted in the command logic and I just need to better understand it.
[18:09] <jeremyw> I think I figured it out and was actually confused by my test repository lacking content.  ;)
[18:16] <jeremyw> So...let's say I have an Inventory[Directory|File], how might one go about getting the last revision the item was changed in?
[18:19] <jeremyw> I'm looking into the API but if someone beats me to it...
[18:20] <ovnicraft> hi folks i was searching for alias for location i want to use for push,pull, etc i search in man but nothing result
[18:20] <fullermd> jeremyw: BTW, did those docs help you back a week or so?
[18:22] <jeremyw> fullermd: Yeah.  I am figuring out how to get deeper and deeper.  Now, I've got a working tree and I'm listing the files.  In doing so, I'd also like to get more information like the revision at which the files were last modified.
[18:22] <jeremyw> Of course your docs don't cover that so I'm tracing the API as I go.
[18:22] <fullermd> Yeah.  I don't really go below the UI  :)
[18:22] <jeremyw> fullermd: It helped a lot actually.  I know the difference between the higher level objects and can go between them easily.
[18:24] <ovnicraft> how i can do this?
[18:25] <fullermd> ovnicraft: I'm not sure I understand the question...
[18:25] <jeremyw> fullermd: I need to go below the UI.  It's not difficult.  :)  It just takes some deeper learning and it's coming along nicely, I'm just missing something that takes an Inventory[Directory/File] and gives me revision information.
[18:25] <roryy> ovnicraft: does "bzr help location-alias" help?
[18:26] <ovnicraft> roryy, yes i found this http://doc.bazaar.canonical.com/bzr.2.1/en/user-reference/location-alias-help.html
[18:30] <ovnicraft> roryy, but i have 2 locations for pull
[18:30] <ovnicraft> i want to bzr pull location1 and bzr pull location2
[18:31] <roryy> ovnicraft: i'm no expert, i'm afraid.  perhaps you can use a command alias for that ('bzr pl1' and 'bzr pl2') or write two shell scripts or cmd files?
[18:32] <ovnicraft> bzr must do this hg do it XD
[18:32] <ovnicraft> btw thx
[18:32] <roryy> does what?  user-specifiable location aliases?
[18:37] <mgz> got OOPS-1733N1768 commenting on an mp, but comment seems to have gone through anyway
[18:37] <ubot5`> https://lp-oops.canonical.com/oops.py/?oopsid=1733N1768
[19:03] <mgz> hm, don't think I quite worded that properly. ah well, lifeless will understand.
[19:19] <jeremyw> Does anyone know of a better way to get a revision object, or just the revision id, that a file was last changed based on the file's id?
[20:28] <jam> jeremw: better than what way?
[20:28] <jam> tree.inventory[file_id].revision ?
[20:29] <jeremyw> jam: That might be what I need.  :)  Basically, I've looked at how the log module does it and it's very slow.
[20:29] <jeremyw> jam: Basically, my intent is to get the last modified revision of a path.
[20:29] <jeremyw> The quickest way.
[20:37] <bfrog> is there a large repo that has bzr git and hg versions?
[20:37] <bfrog> linux?
[20:38] <bfrog> like there's a hg mirror of the kernel which is useful to compare git and hg with
[20:41] <fullermd> I presume you could translate one with bzr-git or fast-{im,ex}port if nothing else.
[20:43] <fullermd> https://code.launchpad.net/~vcs-imports/linux/trunk looks like an import of the Linux kernel.
[20:45] <bfrog> launchpad, joy, so that'll only take like 10 hours to clone
[20:46] <bfrog> launchpad has to be the slowest site on the internet to host a project, I never get anymore than about 15kbps from there, meanwhile kernel.org is like 1.5mb ...
[20:47]  * fullermd shrugs.
[20:47] <fullermd> I didn't say it was better than a chocolate chip cookie.  Just a good first guess to look for a pile of imports of projects in $OTHER_VCS.
[20:48] <bfrog> yeah I hear you
[20:48] <bfrog> its more a complaint towards launchpad than anything else
[20:50] <bfrog> thanks
[21:17] <roryy> wow - 3000 branches in vcs-imports
[21:20] <vila> roryy: you mean https://code.edge.launchpad.net/~vcs-imports ?
[21:20] <vila> hmpf
[21:21] <vila> talk about ruining jokes... I was about to propose him to have a look at https://code.edge.launchpad.net/ubuntu
[21:22] <maxb> oooookay
[21:35] <thumper> hey
[21:35] <thumper> anyone have definitive knowledge if bzr reconfigure --unstacked works on LP?
[21:36] <fullermd> I was told the other day that it does.
[21:37] <maxb> thumper: yes, it does, provided the old stacking location is valid
[21:37] <thumper> cool
[21:37] <thumper> yay
[21:38] <thumper> now I don't have to write an annoying script
[21:38] <thumper> does it do it server side or client side?
[21:38] <thumper> over bzr+ssh?
[21:40] <maxb> Um. Are stacking changes *ever* clever enough to be server-side?
[22:17] <jam> maxb, thumper: actually the design is explicit that smart process can't see the stacked-upon repository, so it *can't* be done via bzr+ssh smart rpc
[22:18] <jam> and thumper, we never had our conversation about Branch Revision
[22:18] <thumper> jam: ok
[22:18] <thumper> jam: no, we didn't
[22:18] <thumper> jam: just in the standup now
[22:18] <jam> thumper: the joys of daylight savings changes
[22:35] <tsmith> is it possible to get bzr-svn to remember my svn username and password?
[22:40] <thumper> tsmith: you can add the username and password in the url
[22:40] <tsmith> i'm not about to save the password in bash_history :O
[22:40] <tsmith> but thanks for the tip
[22:41] <jam> tsmith: I think you can look at "bzr help authentication"
[22:41] <jam> also, I thought there was something about setting username via svn, which we would then remember
[22:41] <tsmith> jam: omg that worked (remembering the pass via svn)
[22:41] <tsmith> thanks
[22:41] <tsmith> !
[23:07] <jbowtie> Hello all.
[23:10] <thumper> jam: are you still around?
[23:11] <jam> thumper: I actually need to go pick up my son now. if you want to talk via phone, we could talk in about 20 min
[23:13] <thumper> jam: yeah, that could work