[01:31] <WW36> Tried to install Lubuntu a couple times. Keeps stating an error that dev/sda could not be installed. Any suggestions?
[01:43] <xangua> And that happens when?
[02:25] <budder> hello
[02:25] <budder> i can't find lubuntu 15.04
[02:26] <krytarik> !15.04
[02:29] <budder> i mean i can't find the DL link
[02:30] <krytarik> Well, you shouldn't download it anymore.
[02:31] <budder> why is that?
[02:32] <krytarik> Because, like I had the bot tell you, it's EOL for a year now.
[02:34] <budder> my CPU is affected by a bug and I can't use Kernel 4.x
[02:35] <LuMint> budder: go for 14.04
[02:35] <LuMint> like I do
[02:35] <budder> so i am resorting to an older release
[02:35] <LuMint> it's supported as opposed to 15.04 which is totally deprecated
[02:36] <LuMint> budder: what's the cpu?
[02:36] <budder> LuMint: i believe the LTS enablement stack makes it so taht 14.04 still have the updated kernel
[02:36] <LuMint> only if you want it to
[02:37] <budder> LuMint: celeron n2940.
[02:37] <LuMint> you have a choice, 3.13, 3,16, 4,{4,5 - not sure}
[02:37] <budder> https://bugzilla.kernel.org/show_bug.cgi?id=109051
[02:37] <budder> LuMint: wut
[02:38] <budder> do you mean I can still have 14.04 but retain the 3.x kernel?
[02:38] <budder> idk what this enablement stack is. i'm very new to linux in general
[02:38] <LuMint> budder: didn't I told you that?
[02:39] <LuMint> uname-a: Linux office-desktop 3.13.0-107-generic #154-Ubuntu SMP Mon Dec 19 19:20:26 UTC 2016 i686 i686 i686 GNU/Linux
[02:39] <LuMint> convinced?
[02:40] <budder> LuMint: wait a second, so it is OPTIONAL to use the newer kernel? can you please link me to some more information on this? and how about going to do this?
[02:41] <LuMint> yes. google/duck it. install 14.04
[02:42] <krytarik> budder: Just get the 14.04.1 release, it has the initial kernel still.
[02:44] <budder> duck it>
[02:44] <budder> LuMint: duck it?
[02:44] <LuMint> ducduckgo.com
[02:44] <budder> krytarik: ok
[02:45] <budder> thanks both of you
[02:45] <budder> wait LuMint are you also affected by the same bug?
[02:46] <LuMint> no I'm affected by a different bug, which is not really a bug but a dropped support for my GPU drivers.
[02:46] <LuMint> so I can't use anything newer than 3.7 and still have nvidia-173 proprietary drivers
[02:47] <LuMint> well actually, I can if I used arch or if I somehow ported the patches from aur to enable it.
[02:47] <LuMint> but that's technicalities.
[02:47] <LuMint> why bother if 3.13 is still supported
[02:48] <budder> got it... mostly
[02:49] <budder> thnx again
[02:50] <LuMint> 14.04 is supported for at least two more years.
[05:35] <Vialas_> hello everyone
[05:35] <Vialas_> hope you are all well
[05:35] <Vialas_> first time in here... i installed Lubuntu for the first time today ... wohooo
[05:35] <Vialas_> i already have a question.. if i may
[05:35] <Vialas_> Q is : how do i update the kernal on my raspberry pi ?
[05:35] <Vialas_> sudo apt-get install --reinstall raspberrypi-bootloader
[05:36] <Vialas_> is that the correct command i should use? i would use this on say my normal ubuntu box... unsure about how it works on lubuntu for RasPi
[05:37] <wxl> Vialas_: are you trying to reinstall your kernel or update it? because that command doesn't update anything. just reinstalls it. it also doesn't refer to the kernel, but the bootloader.
[05:38] <Vialas_> rofl ok so i have no idea what im doing rofl
[05:38] <Vialas_> i want to update my kernal
[05:38] <wxl> so just run updates like normal and it will take care of it
[05:38] <wxl> sudo apt update && sudo apt upgrade
[05:38] <Vialas_> according to a podcast i head there was a security issue with the Raspi Krnal
[05:39] <Vialas_> oh not apt-get?
[05:39] <wxl> what security issue?
[05:39] <wxl> apt is a nicer version of apt-get
[05:40] <Vialas_> oh i never used apt before hehe
[05:40] <Vialas_> i am not sure of the specifics - was on a podcast let me check...
[05:42] <wxl> found it https://www.ubuntu.com/usn/usn-3170-2/
[05:43] <Vialas_> wow
[05:43] <Vialas_> how you find it so fast :O
[05:43] <wxl> all the security issues in ubuntu are listed under ubuntu.com/usn
[05:43] <wxl> anyways if your isp doesn't support ipv6, i wouldn't even worry about it
[05:43] <Vialas_> oh cool cool
[05:43] <wxl> still, it's good to fix it
[05:43] <Vialas_> yea
[05:43] <Vialas_> and you know what
[05:44] <wxl> what kernel you have now? uname -a
[05:44] <Vialas_> i did the dist-upgrade
[05:44] <Vialas_> i do that quite religiously
[05:44] <wxl> then yeah, no need to sweat
[05:44] <wxl> it
[05:44] <Vialas_> oh haha sweet :)
[05:44] <wxl> security updates are always the highest priority
[05:44] <Vialas_> i am running 4.1.19-v7+
[05:44] <lynorian> yes if you dist-upgrade everyday you probably are much better patched than most companies
[05:44] <Vialas_> woot woot
[05:44] <wxl> oh so you're a bit behind
[05:45] <wxl> you're on xenial?
[05:45] <Vialas_> ive thought about doing sudo apt update && sudo apt dist-upgrade -Y on a crhon job :P
[05:45] <wxl> cuz THAT issue only affects yakkety
[05:45] <Vialas_> raspberry pi
[05:45] <wxl> lsb_release -a
[05:45] <wxl> what version of lubuntu
[05:45] <Vialas_> i thought i was on the msot up to date version :(
[05:46] <Vialas_> ubuntu 16.04
[05:46] <Vialas_> xenial
[05:46] <wxl> yep xenial
[05:46] <wxl> so there's no issues for you anyways :)
[05:46] <Vialas_> 16.04.1
[05:46] <Vialas_> woot woot
[05:46] <Vialas_> why am i behind then :(
[05:46] <wxl> yeah i'm a little shocked as to why you're behind
[05:46] <Vialas_> :(
[05:47] <Vialas_> i just installed it today
[05:47] <Vialas_> literaly
[05:48] <wxl> try dpkg -l | grep -E 'linux-image-.*-[0-9]+'
[05:48] <wxl> that'll list all the kernels you have installed
[05:48] <wxl> oh bother remove the -.*
[05:48] <wxl> that'll just show up the extra package which is irrelevant
[05:49] <wxl> you might still be running the original kernel even though you updated to the new noe
[05:51] <Vialas_> one sec
[05:54] <Vialas_> dpkg -l
[05:54] <Vialas_> is that a L or a pipe?
[05:54] <LuMint> l
[05:55] <LuMint> u should install a normal font
[05:55] <Vialas_> im on a mac :(
[05:55] <Vialas_> lol
[05:55] <Vialas_> there is NO normal
[05:55] <LuMint> Vialas_: besides, there couldn't be TWO pipes in a row
[05:55] <Vialas_> oh lol
[05:56] <LuMint> and a pipe preceded by dash will presumably not work
[05:56] <LuMint> well, it does.
[05:56] <LuMint> Vialas_: but that dash can potentially cause all kinda weird thigns so you don't use | with - before it :)
[05:58] <LuMint> wxl: forgive my curiousity, but what does + sign do?
[05:59] <wxl> LuMint: regex for "one or more" of the previous character
[06:01] <wxl> could have used * for zero or more but that'd be weird :)
[06:02] <Vialas_> dpkg -l | grep -E 'linux-image-[0-9]+'
[06:02] <Vialas_> didnt give any output
[06:04] <LuMint> that's weird
[06:04] <LuMint> try dpkg -l | grep linux-image
[06:04] <Vialas_> nothing...
[06:04] <wxl> um
[06:05] <LuMint> wxl: thanks, didn't know one can mix it with * ? [] and {}, that is bash stuff
[06:05] <wxl> try grepping just for just linux
[06:05] <Vialas_> ?
[06:05] <LuMint> dpkg -l | grep linux
[06:05] <LuMint> Vialas_:
[06:05] <wxl> LuMint: [0-9] is actually NOT bash stuff. that's regex. the fact that the regex is contained within single quotes indicates that bash will not attempt to expand it
[06:06] <wxl> e.g. `echo '$SHELL'` won't show you your shell
[06:06] <Vialas_> bingo
[06:06] <Vialas_> we have output :)
[06:06] <LuMint> wxl: ty
[06:07] <wxl> !pastebin | Vialas_
[06:07] <Vialas_> http://paste.ubuntu.com/23892115/
[06:08] <Vialas_> hey i have to duck out real quick... do you mind if i come back and continue
[06:08] <Vialas_> or are you going to leave soon?
[06:08] <Vialas_> sorry for being anoying :$
[06:08] <wxl> i'm about out
[06:08] <Vialas_> ok
[06:08] <wxl> but still very confused
[06:08] <Vialas_> im very confused myself :(
[06:08] <Vialas_> maybey we can continue tomorrow :D
[06:08] <wxl> k
[06:09] <LuMint> wouldn't think arm stuff would be so complicated
[06:09] <wxl> i'm about to ragequit mode anyways (not your fault)
[06:09] <LuMint> why?
[06:09]  * wxl smells sarcasm on LuMint's breath
[06:09] <Vialas_> :(
[06:09] <Vialas_> dont ragequit
[06:09] <Vialas_> you seem too nice to rage!!!
[06:10] <wxl> oh i'm having issues with an image not behaving properly on a virtual machine
[06:10] <Vialas_> oh golly
[06:10] <wxl> it's a figure of speech of course Vialas_ :)
[06:10] <Vialas_> story of my life
[06:10] <Vialas_> thats good wxl :)
[06:10] <Vialas_> hehe
[06:10] <LuMint> yeah, don't, you are by far one of the most helpful and nice people here
[06:10] <Vialas_> i gave up using debian
[06:10] <Vialas_> hence why im now using lubuntu
[06:10] <wxl> well welcome to ubuntu :)
[06:10] <LuMint> Vialas_: what was wrong with your debian?
[06:10] <Vialas_> thanks wxl
[06:11] <LuMint> Vialas_: problems with something proprietary/firmware?
[06:11] <Vialas_> well it is a pain to install, when i do install it the graphcis drivers dont work
[06:11] <Vialas_> yes exactaly LuMint
[06:11] <Vialas_> i use ubuntu and it just works
[06:11] <LuMint> you should just add the nonfree repo
[06:11] <Vialas_> i tried LuMint ... didnt seem to work
[06:11] <Vialas_> i like Lubuntu im just woried about the conical stuff in it :S
[06:11] <LuMint> weird
[06:11] <Vialas_> very weird
[06:11] <LuMint> canonical?
[06:11] <LuMint> conical?
[06:11] <Vialas_> yea
[06:11] <Vialas_> :$
[06:11] <Vialas_> lol
[06:12] <wxl> the only stuff canonical owns is the trademarks
[06:12] <wxl> like "lubuntu"
[06:12] <wxl> as far as actual code, not really
[06:12] <Vialas_> fewwwwww
[06:12] <Vialas_> and no amazon crapware on lubuntu
[06:12] <Vialas_> or that stupid unity
[06:12]  * Vialas_ vomits
[06:12] <Vialas_> sorry everyone... ill clean it up
[06:13] <wxl> i mean they have their pet projects like um
[06:13] <wxl> man i can't think of the name of the darn thing now hahaha
[06:13] <wxl> i keep wanting to say upstream
[06:13] <wxl> upstart!
[06:13] <wxl> that's it
[06:13] <LuMint> Vialas_: what are you going to do with your raspberry?
[06:13] <Vialas_> hmm ok
[06:13] <LuMint> wxl: not anymore :(
[06:13] <Vialas_> well i have heaps of pis
[06:13] <Vialas_> lol
[06:13] <wxl> but those are things they push upstream as well, so it's not really proprietary
[06:13] <Vialas_> i am an adict
[06:13] <Vialas_> 1 is a VPN server
[06:13] <wxl> LuMint: yeah yeah
[06:13] <Vialas_> another is a every day linux box
[06:13] <LuMint> upstart is almost deprecated by now
[06:13] <xangua> Lubuntu does use the "indicators"
[06:13] <LuMint> will probably only be supported until 19'
[06:13] <Vialas_> another i use as an intranet webserver
[06:13] <xangua> That's a canonical stuff
[06:14] <Vialas_> xangua whatis an "indicators"
[06:14] <LuMint> Vialas_: do you ssh into it?
[06:14] <Vialas_> yep
[06:14] <Vialas_> SSH all the way
[06:14] <LuMint> I see
[06:14] <Vialas_> love ssh!
[06:14] <wxl> xangua: if you're referring to some aspect of unity, even that's open sourced
[06:14] <LuMint> Vialas_: btw you can do that with a vmware VM
[06:14] <LuMint> and forward X, too
[06:14] <Vialas_> what u mean LuMint ?
[06:14] <lynorian> Well you can run lubuntu in lubuntu with virt manager
[06:15] <xangua> Vialas_: indicators are like notification icons/area but "better"
[06:15] <wxl> yes but can you run lubuntu in lubuntu in lubuntu?
[06:15] <Vialas_> xangua right...
[06:15] <LuMint> Vialas_: i mean you don't need a dedicated linux box to be able to use it from windows.
[06:15] <wxl> good use of quotes, xangua
[06:15] <Vialas_> yea LuMint but i like to have a linux box
[06:15] <LuMint> understood
[06:15] <Vialas_> mac is propiatary and leeeks tooooo much info
[06:15] <Vialas_> i like linux
[06:15] <Vialas_> :D
[06:16] <LuMint> Vialas_: well block he hell out of it with a firewall on the router
[06:16] <Vialas_> ok time for dinner
[06:16] <Vialas_> hope i get to talk to you all soon
[06:16] <Vialas_> block it?
[06:16] <Vialas_> how so LuMint ?
[06:16] <LuMint> yeah, unwanted ips/servers
[06:16] <Vialas_> mmm true
[06:16] <Vialas_> oh these servers
[06:16] <Vialas_> sorry
[06:16] <Vialas_> they are at my house
[06:16] <Vialas_> i own them
[06:16] <Vialas_> so behind my router
[06:16] <Vialas_> safe :D
[06:16] <wxl> or better yet set up a freebsd box with pf on it and block everything!
[06:17] <LuMint> openbsd would be a more secure choice, I guess
[06:17] <LuMint> since a router doesn't really need anything GUI
[06:17] <LuMint> or pretty much any user software
[06:19] <Vialas_> yay... ok lesson learnt dont talk to fast and hit enter.... Drone` will not be happy wiht you
[06:19] <wxl> XD
[06:19] <Vialas_> ok got to run
[06:19] <Vialas_> hope to talk to you all very soon. thanks wxl and LuMint and otehrs :)
[06:19] <Vialas_> bbl
[06:19] <wxl> ta
[06:20] <LuMint> see you
[06:20] <LuMint> wxl: incidentally, do you happen to know if it's possible to apply a patch from aur so I could use nvidia-173 with a kernel newer than 3.7 (3.13 in fact)?
[06:20] <LuMint> the arch guys somehow managed to get it working with new kernels
[06:20] <wxl> LuMint: never tried, but i'm sure it will need some massaging
[06:21] <wxl> ok that's it
[06:21]  * wxl kicks the virtual machine to the curb and goes to bed
[06:22] <LuMint> good night
[13:20] <dminca> hi guys
[13:20] <dminca> is the `dbus-launch` command supposed to fork multiple pids of `dbus-daemon` ?
[13:21] <dminca> because I'm having 914 dbus-daemon pids
[13:21] <dminca> and I don't want to killall as I'll fuck up systemd
[13:22] <dminca> what's the best approach in this case? How can I launch a process via `dbus-launch` without making it to fork so many `dbus-daemon` pids
[16:25] <Gochy> Hi, I need some help with a problem while upgrading from 14.04 LT to 16.04 LTS
[20:00] <RainMan28> Hi, I am trying to run a command via a Lubuntu LiveUSB and when I do it with sudo it tells me: 'dd: failed to open '/dev/sda': Permission denied'. Any idea what I am doing wrong?
[20:00] <RainMan28> I am logged in as the lubuntu user
[20:01] <RainMan28> My command is: sudo xzcat file.img.xz | dd of=/dev/sda bs=1M
[20:02] <krytarik> RainMan28: Move the 'sudo' after the pipe, to the 'dd' - then it should work.
[20:03] <RainMan28> oh i see, thank you
[20:03] <krytarik> Sure.
[20:03] <RainMan28> that is working, krytarik, thanks!
[20:03] <krytarik> Welcome.


[03:01] <zzxc> Hey does anyone have any experience with setting up AFP?
[03:03] <sarnold> zzxc: I used netatalk 13, 14 years ago with good success. Of course that predated OS X clients... :)
[03:04] <zzxc> sarnold: Is there a need to create an afp user and password like there is with samba?
[03:08] <markthomas> zzxc: afp uses user-based authentication if that's what you're asking.
[03:09] <sarnold> zzxc: In a quick search of the code, initscripts, I don't see any code that'd require creating a user for netatalk, it looks like it should run as root in the usual case
[03:11] <zzxc> markthomas: If it works as it does for osx I would imagine that it would just be the user's login (as in the same that you ssh into)
[03:11] <markthomas> yes.
[03:13] <zzxc> sarnold markthomas: I"m trying to share the /mount directory. I get prompted for a user name and password, but the login creds error.
[03:14] <zzxc> I'm going to make the pretty obvious guess that the reason is that my user may not have be the owner or have rwx premissions for that directory...
[03:14] <markthomas> zzxc: why afp?
[03:15] <zzxc> markthomas: primary os is osx. I also have a samba share right now but honestly its a pain in the ass.
[03:16] <sarnold> yup, that sounds like samba. :/
[03:17] <markthomas> I have smb and afp here, and between linux and mac i find smb less of a hassle. and yes, i just used samba and "less hassle" in the same context.
[03:17] <sarnold> zzxc: does netatalk use pam to authenticate users? if so does your /etc/pam.d/netatalk look correct?
[03:17] <zzxc> sarnold: Let me check one second.
[03:21] <zzxc> sarnold: The pam.d/netatalk doesn't have any documentation. It includes common-{auth,account,password,session). But I'm not really sure what its suppost to look like
[03:21] <sarnold> zzxc: okay, that'd probably be sufficient for the user to log in at the console.
[03:22] <sarnold> zzxc: is there anything more useful in the logs?
[03:22] <sarnold> check both /var/log/auth.log and netatalk logs
[03:22] <zzxc> markthomas: honeslty the majority of my issues boil down to premissions, though being able to let other users login in should they want and having it broadcast via bonjour (since only two of my close friends have windows) would be nice.
[03:26] <zzxc> sarnold: There are afp log messages in auth, but when I tail it nothing and try the same creds, nothing happens/
[03:32] <sarnold> zzxc: *sigh* sorry, I'm not seeing anythjin in the manpages or source that looks useful. :/
[03:33] <sarnold> zzxc: if you give it username/password you know are bogus, do you get the same or different error?
[03:34] <zzxc> sarnold: Nope tells me its a bad login and reprompts me.
[03:34] <sarnold> zzxc: different error?
[03:34] <zzxc> That please contact you're network admin message is soo irrating when you're the network admin.
[03:35] <sarnold> hehehe, yes
[03:35] <zzxc> sarnold: No error message, the login prompt shakes and prompts you to try agian.
[03:36] <sarnold> zzxc: is that the same or different than happens when you give it the good username and password?
[03:36] <sarnold> I'm curious if the authentication works but it fails somewhere else..
[03:37] <zzxc> sarnold: "Check the server name or IP address, and then try again. If you continue to have problems, contact your system administrator." is when its a valid user and password. Otherwise it just shakes the prompt and ask me for it agian.
[03:38] <zzxc> sarnold: Nothing is showing up in the netatalk logs, and when it does error out I don't get a message in the auth logs.
[03:40] <sarnold> zzxc: okay, cool, a thread to pull on. :) are you trying to mount a filesystem / directory that isn't exported? how do permissions look like for that directory and all directories above it?
[03:42] <zzxc> sarnold: I'm trying to mount my /mount/sda directory.
[03:43] <zzxc> sarnold: Orginally I was just trying to mount my /mount drive, figuring it would be nice to have access to everthing there.
[03:44] <zzxc> and orginally mount was owned by root, Its currently owned by me now and I ahve full permissions to it and everything inside.
[03:45] <zzxc> sarnold: this is the line from the how to guide I was looking up "/mount/sda BlackBox allow:james options:userdots,upriv"
[03:54] <sarnold> zzxc: sorry, got into a conversation...
[03:54] <sarnold> zzxc: how about ls -ld /mount /mount/sda  ?
[03:56] <zzxc> sarnold: No worries rwxr-xr-x and james:root on both
[03:57] <sarnold> zzxc: man. that sounds like it ought to work. :(
[03:58] <zzxc> yeah I know its getting super annoying at this point.
[03:58] <sarnold> zzxc: so I guess it's time to bring out the unfun tools -- you could use fatrace to see what files are being accessed, or you could strace -p <pid of the server> -- and see if you can follow the system calls that lead to the decision to reject access.
[03:59] <sarnold> zzxc: if neither of those give you much to work with, you can try ltrace -- that traces function / library calls, not just system calls -- maybe it'll be more direct about the problem, but it's often like drinking from the firehouse
[03:59] <sarnold> firehose :)
[04:00] <zzxc> ack. I think I'll call it quits and look at it later with a fresh pair of eyes.
[04:00] <sarnold> zzxc: good luck! if you figure it out and don't mind, I'd be curious to hear the result.
[04:00] <sarnold> zzxc: time for me to call it a day too :)
[04:01] <zzxc> sarnold: Thanks for you help with it. I'll let you know if I figure it out.
[04:36] <blueking> hello again
[04:41] <blueking> just wonder:  route -n shows <IP_ADDRESS>     netmask <IP_ADDRESS> are added to routing table  right out of sky...  interfaces file or hosts file does not have this ip/netmask    saw  one could Append the following directive: NOZEROCONF = yes  in file /etc/sysconfig/network     but there are NO sysconfig folder in /etc on ubuntu 13.10 installation
[04:41] <blueking> I am lost :(
[05:07] <fishcooker> im on ubuntu server there is an option about the kernel thing?
[05:07] <fishcooker> which one should i choose
[05:10] <fishcooker> im on ubuntu server installation.. there is options about to choose the kernel, which one should i choose?
[05:13] <e_t_> fishcooker: Choose the one with the highest version number, probably the one at the top of the list.
[05:32] <fishcooker> thanks e_t_: i go with linux-image-generic
[05:33] <fishcooker> https://help.ubuntu.com/community/ServerFaq#Is_a_dedicated_SMP_kernel_available_from_the_Ubuntu_Server_installation_CD.3F
[09:13] <eagles0513875> hey guys any samba experts in here. I have a question in regards to ACL's im guessing samba ignores the ACL's on ubuntu server and uses its own correct?
[09:31] <jamespage> zul, I uploaded webtest again with waitress as depends - it really is needed
[09:31] <jamespage> the package won;t work without it - however pyquery and lxml are suggests IMHO so did that as well
[11:28] <jamespage> zul, I took a libbo and re-introduced the sqlite patch you dropped back into the heat packaging - it was causing a dep-8 failure
[11:28] <jamespage> pushed and uploaded
[11:34] <jamespage> zul, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728425 is blocking backporting python-babel - which is preventing other things from passing tests right now
[11:34] <jamespage> nova
[11:47] <makara> what was to blame for the Ubuntu Forums being hacked?
[11:55] <jamespage> zul, babel fixed - I've submitted the fix back upstream
[11:55] <jamespage> non-deterministic test cases - gotta love-em
[12:40] <blueking> hello
[12:42] <blueking> kernel sets iprouting <IP_ADDRESS>   netmask <IP_ADDRESS>     been reading that one can set  nozeroconf=yes in /etc/sysconfig/network   but on ubuntu 13.10 there are no folder  /etc/sysconfig     couldn't find solution on ubuntu   someone who can help me ?
[12:43] <blueking> when I connect  ethernet cable to laptop   it gets two IP  <IP_ADDRESS>   and  was given auto  169.254.x.x     and net unreachable
[13:05] <blueking> anyone knows if one can put nozeroconf= yes in /etc/network/interfaces ?
[13:09] <rbasak> blueking: can you specify exactly what you're trying to do? Ubuntu people aren't necessarily familiar with RH/Fedora config syntax.
[13:10] <blueking> rbasak:  problem are  kernel somehow adds iprouting  <IP_ADDRESS>
[13:10] <blueking> I need to disable that
[13:11] <blueking> I disabled some avahi stuff but  kernel kept on putting iprouting <IP_ADDRESS> back
[13:11] <rbasak> blueking: are you getting this address on a desktop machine? Or a server machine?
[13:12] <blueking> route -n show  <IP_ADDRESS>
[13:13] <blueking> and mine laptop   that I connect to net with cable  gets  <IP_ADDRESS> AND 169.254.x.x
[13:13] <blueking> and the net    are pending on off   all the time
[13:13] <blueking> when connect to another  basic router  no problem
[13:13] <rbasak> It sounds like you have a desktop issue. Try #ubuntu.
[13:14] <blueking> not desktop issue
[13:14] <rbasak> It sounds like you need to adjust your network manager settings in some way, since that's what gets you your address on a desktop machine by default.
[13:14] <blueking> route -n show that kernel adds iproute <IP_ADDRESS>
[13:14] <blueking> on  other distro they can set nozeroconf= yes to turn it off
[13:15] <rbasak> blueking: are you getting this address on a desktop machine? Or a server machine?
[13:20] <blueking> rbasak:  on server machine
[13:20] <blueking> with route -n that is
[13:22] <rbasak> blueking: I don't understand why you'd get that. A default Ubuntu server installation does not use Zeroconf.
[13:22] <blueking> rbasak:  I even tried to set up static ip to my laptop   and turned off dhcp on laptop   and put in ip manual  still it received 169.254.x.x adress
[13:22] <rbasak> If your laptop gets a 169.254 address it is because it cannot find a DHCP server to give it a correct address (or, very unusually, a DHCP server is handing out bad addresses)
[13:23] <rbasak> Do you have a DHCP server daemon running on your server?
[13:25] <blueking> isc-dhcp-server
[13:26] <rbasak> It sounds like you have some significant non-default thing going on either on the server or on your laptop. Getting a Zeroconf 169.254 address is automatic. There's nothing to disable on a server for this since normally there is no server component that "issues" such an address; a client just picks up one that is available without the help of a server.
[13:27] <zul> jamespage:  cool
[13:28] <rbasak> Exceptionally, I suppose a DHCP server could be misconfigured to hand these out, but that seems unlikely. I suggest you run a tcpdump on both the server and laptop to figure out where from and how you get that address.
[13:28] <jamespage> zul, babel is backported now
[13:28] <jamespage> I think that might mean nova can build ok on precise now :-)
[13:28] <blueking> ok have to figure out how to make tcpdump
[13:28] <zul> jamespage:  cinder as well
[13:29] <jamespage> zul, unfortunately it missed the last b-o-m run
[13:29] <blueking> rbasak:  think problem came after I installed webmin
[13:30] <rbasak> blueking: could be.
[13:30] <rbasak> !webmin | blueking
[13:30] <blueking> and had some issues with making isc server visible on it... and might be that dhcp3 server been enabled somehow
[13:30] <blueking> oh so webmin are reason
[13:31] <jamespage> rbasak, what was so bad about how webmin managed configuration files?
[13:31] <rbasak> jamespage: no idea. All I know is that everyone says it's broken!
[13:31] <jamespage> rbasak, well I agree that webmin is probably so out-of-date
[13:32] <jamespage> but was it not superceded by ebox and then zentyal?
[13:32] <rbasak> I'm not saying that it is webmin in this case. Just that webmin does stuff, and is not recommended, and blueking seems to have had stuff done to his server and it's not working, so it's worth investigating that possibility.
[13:32] <jamespage> right
[13:32] <jamespage> fair enought
[13:33] <blueking> could u mention how to search/find packages that currently are installed on system ?
[13:33] <blueking> without webmin that is
[13:34] <blueking> apt-cache search  looks for all packages   but want to check what are current in system
[13:39] <rbasak> blueking: dpkg -l
[13:39] <blueking> ok
[13:39] <rbasak> blueking: that'll also show you removed packages that aren't purged. See the dpkg manpage for details, but I think "dpkg -l|grep ^ii" or something will filter to installed packages.
[13:49] <jamespage> zul, cinder and heat have flushed through to the CA staging area
[13:49] <jamespage> zul, I think everything else is still held up in trusty-proposed right now
[13:49] <zul> jamespage:  ok ill kick off the builds for precise testing (nova/cinder)
[13:49] <jamespage> ?
[13:50] <zul> precice-icehouse-nova/cinder
[13:50] <jamespage> zul, nova should go through next run - it missed new babl
[13:50] <jamespage> precise-icehouse-nova is running right now
[13:50] <zul> ack
[14:23] <zul> jamespage/roaksoax: https://code.launchpad.net/~zulcss/keystone/tests-refresh/+merge/198066
[14:26] <zul> jamespage/roaksoax: https://code.launchpad.net/~zulcss/python-heatclient/mox3/+merge/198068
[14:29] <zul> jamespage:  it looks like swift-bench has moved out into its own project
[14:36] <jamespage> zul, your heatclient branch conflicts
[14:36] <zul> jamespage:  damn it
[14:41] <zul> jamespage:  better branch https://code.launchpad.net/~zulcss/python-heatclient/mox3/+merge/198072
[14:42] <jamespage> yolanda, did you push a new update with more unit tests for the heat charm?
[14:43] <zul> jamespage:  i added a WI for swift-bench
[14:43] <zul> jamespage/roaksoax:  https://code.launchpad.net/~zulcss/swift/swift-bench/+merge/198073
[14:46] <jamespage> zul, minor niggle on keystone
[14:46] <jamespage> zul, swift +!
[14:46] <jamespage> 1 rather
[14:48] <zul> jamespage:  keystone niggle fixed
[14:49] <jamespage> zul, nova just b-o-m'ed
[14:49] <jamespage> gonna milk this for all its got!
[14:49] <zul> jamespage:  sweet
[14:50] <jamespage> zul, oh - I tried your patch for libvirt - that was OK _ but I got a test failure - any chance you can take a look sometime today and see if its easily fixable/reproducable?
[14:50] <zul> jamespage:  it was failing on some client test?
[14:51] <zul> jamespage: (backporting python-mox3)
[14:52] <jamespage> zul, http://paste.ubuntu.com/6530065/
[14:52] <jamespage> zul, so I see
[14:52] <hallyn_> stgraber: might be nice to have options to the ubuntu and ubuntu-cloud templates to specify apparmor profile
[14:52] <hallyn_> (preferably by shorter names)
[14:52] <hallyn_> lemme know if you have thoughts on that
[14:52] <jamespage> zul, I get email on uploades (james page == openstack ubuntu testing bot)
[14:53] <zul> jamespage:  yeah i had the same problem
[14:54] <zul> jamespage:  unfortunately the libvirt tests are  light on the verbage
[14:56] <jamespage> zul, any idea on the qemu failuer?
[14:57] <zul> jamespage:  not yet
[14:57] <zul> jamespage:  i blame hallyn somehow ;)
[14:58] <hallyn_> i accept nothing
[15:05] <jamespage> zul, python-crypto builds OK locally - odd
[15:05]  * jamespage looks deeper
[15:05] <zul> jamespage:  looking at qemu
[15:06] <jamespage> zul, ta
[15:06] <jamespage> something about DTC not being avaliable
[15:10] <zul> jamespage:  it would help if i used the right release :)
[15:12] <hallyn_> zul: all right, re-running the libvirt tests on trusty, first without your ppa then with.
[15:14] <zul> hallyn_:  ack
[15:15] <zul> jamespage:  "ERROR: DTC not present." ?
[15:20] <roaksoax> rbasak: when an arm machine is first booted in MAAS, it loads an i386 ephemeral image to get it enlisted?
[15:21] <rbasak> roaksoax: ?
[15:21] <rbasak> roaksoax: no, it uses an armhf ephemeral image.
[15:21] <rbasak> Did I say i386 somewhere?
[15:21] <roaksoax> rbasak: how does it know to use one?
[15:21] <rbasak> Ah. Now that's a very good question :-)
[15:22] <roaksoax> rbasak: i mean, when it pxe boots, config.commissioning.template is used, and that itself tests for amd64 or i386
[15:22] <rbasak> Right now, highbank does it by falling back to fetching /pxelinux.cfg/default.arm.highbank (or something like that), then default.arm, then finally default.
[15:22] <rbasak> MAAS' dynamic TFTP implementation picks up on that, and serves a suitable default file, which fetches the correct arch kernel/initrd.
[15:23] <rbasak> I never had to connect anything between the correct arch kernel/initrd and the correct arch ephemeral as far as I can remember. I presume the code already DTRT.
[15:23] <rbasak> Another possible mechanism is a DHCP vendor identifier option, which U-Boot does provide. But we ended up not using that.
[15:24] <rbasak> So the amd64/i386 differentiating pxelinux template is never used in the armhf case.
[15:24] <yogeshsarwate> Hi all i got a dns addresses on noip.com i want to run my own email server and irc chat server can anybody guide
[15:25] <zul> qemu: i think it needs a newer libfdt-dev so i back ported it
[15:25] <rbasak> roaksoax: notice that /etc/maas/templates/pxe/config.commissioning.armhf.template is distinct from the more generic  config.commissioning.template
[15:26] <rbasak> IMHO it should be the other way round, as it's the Intel case that's special, but never mind.
[15:26] <roaksoax> rbasak: yeah... for some reason I thought it, by default, any type of hardware uses cponfig.commissioning.template, but I guess for arm it uses config.commissioning.armhf.template before the machine is even enlisted
[15:26] <rbasak> Right
[15:26] <rbasak> The TFTP server does the detection.
[15:26] <rbasak> (currently)
[15:27] <roaksoax> rbasak: where in the code is that exactly, do you know?
[15:28] <rbasak> Looking
[15:28] <rbasak> roaksoax: http://bazaar.launchpad.net/~maas-maintainers/maas/trunk/view/head:/src/provisioningserver/tftp.py
[15:28] <rbasak> roaksoax: the regex picks up the default-(whatever) in lines 93-111.
[15:28] <roaksoax> rbasak: eah that's where I'm looking
[15:29] <roaksoax> rbasak: i see now, cool thanks!
[15:29] <rbasak> The code that used the resulting match used to be in there, but I guess it's moved now.
[15:29] <jamespage> zul, for some reason python-crypto won't build in the lab
[15:29] <jamespage> its OK on ppa and locally
[15:29] <zul> jamespage:  weird
[15:32] <hallyn_> zul: what time is the openstack-lxc mtg?
[15:33] <jamespage> zul, i see the issue
[15:33]  * jamespage twiddles a knob
[15:37] <jamespage> zul, fixed - for reference the schroot's where not providing a /dev/shm
[15:37] <jamespage> (using tmpfs)
[15:38] <jamespage> zul, you need to fix that niggle for keystone harded - forwarded is spelt incorrectly
[15:38] <yogeshsarwate> Hi
[15:51] <jamespage> zul, urgh - heatclient needs mox and well as mox3 btw
[15:52] <jamespage> I'll fix that and merge your change if thats ok
[15:52] <zul> jamespage:  okies
[15:53] <zul> jamespage:  that needs to be fixed upstream it should use mox3
[15:53] <jamespage> zul, ah - OK
[15:53] <jamespage> zul, well I pushed it with both for the time being
[15:54] <zul> jamespage:  yeah im submitting a patch upstream
[16:45] <jamespage> zul,  keystone and we are all green in ci for icehouse btw
[16:45] <zul> jamespage:  ill poke at keystone
[16:46] <jamespage> zul, your mp is not merged yet
[16:46] <zul> jamespage:  qemu is building in bom btw
[16:46] <jamespage> yeah - I see
[16:46] <jamespage> nice
[16:58] <zul> jamespage:  https://code.launchpad.net/~zulcss/keystone/tests-refresh/+merge/198066
[17:02] <w0rmie> i've some problems with tftp-hpa configuration, the package is installed, but no file such /etc/default/tftpd-hpa to set
[17:02] <w0rmie> any ideas?
[17:05] <markthomas> w0rmie: check /etc/default/tftp-hpa
[17:16] <w0rmie> markthomas: the default folder with a simple ls does not contain any file named tftp-hpa
[17:16] <jamespage> zul: just checking that now - I'll merge it if its good
[17:17] <zul> jamespage:  okies we just have libvirt and libunwind to worry about
[17:17] <w0rmie> markthomas: should i create a file to set the tftp-hda to default task?
[17:18] <markthomas> w0rmie: checking.  sec
[17:18] <jamespage> zul, I did an install of everything from the trunk testing ppa
[17:18] <markthomas> w0rmie: trying to figure out why I have one.
[17:18] <jamespage> swift appears to have lost all is upstart configs for some reason
[17:19] <markthomas> w0rmie: yes, the upstart job for tftp-hpa loads /etc/default/tftp-hpa
[17:20] <w0rmie> markthomas: ok, should i create a new file with the defaults for tftp-hpa or i should fin an existing file into /etc/defaults/ named tftp-hpa?
[17:21] <markthomas> There are four options listed in the tftp-hpa defaults file.  You can find them in the upstart script.
[17:22] <zul> jamespage:  er?
[17:22] <markthomas> w0rmie: have a username of tftp, directory is whatever, address is <IP_ADDRESS>:69, options="--secure -vvv"
[17:22] <jamespage> zul, its odd - non of the packages have upstart configs any longer
[17:23] <zul> jamespage:  wtf?
[17:23] <jamespage> zul, same on trusty and precise
[17:23] <highvoltage> it was zapped with lennart's deathray
[17:24] <zul> jamespage:  keystone does.
[17:24] <jamespage> zul, yes - it appears to be isolated to swift
[17:24] <zul> jamespage:  hmm...ill have a look
[17:25] <jamespage> zul, I'm looking
[17:25] <zul> jamespage:  ok ill poke libvirt then
[17:26]  * jamespage breaths again
[17:26] <jamespage> the release version in saucy/trusty does
[17:26] <jamespage> must be something in the branch
[17:26] <jamespage> zul, keystone merged
[17:27] <zul> jamespage:  cool thanks
[17:27] <zul> jamespage:  could be over zealous cleanup by me
[17:30] <jamespage> zul, http://paste.ubuntu.com/6530751/
[17:30] <jamespage> wanna +1 that? saves a mp
[17:30] <zul> jamespage:  arrgh...yeah +1
[17:32] <jamespage> zul, I've dropped b-o-m to run daily instead of hourly now
[17:34] <zul> jamespage:  ack
[17:42] <jwal> Hi.  I am trying to setup a non-interactive install of roundcube from the debs.  It is all working - using debconf-set-selections - except I am being prompted for a password.  I just have to hit enter for it to continue (using pgsql ident).  Can somebody help me debug what is happening? (also asked in #ubuntu, sorry for cross post)
[17:43] <zul> jamespage:  maybe leave it at daily and when the milestones come around turn it on for hourly?
[17:44] <ersi> Kind announcement: Today is the last day to do the FLOSS survey 2013: http://floss2013.libresoft.es/
[17:47] <jamespage> zul, well it can be run manually as well
[17:48] <zul> jamespage:  true just thinking
[17:48] <jamespage> smoser, I'm getting bored of syncing image data - have you started on a simplestreams charm yet  - or can I start hacking on one
[17:49] <smoser> jamespage, not started on said charm.
[17:49] <smoser> you are welcome to do that for sure.
[17:49] <jamespage> great
[17:50] <smoser> i dont know that i understood why you think its a separate charm thoug
[17:50] <smoser> rather than just confiuration of glance charm
[17:50] <jamespage> smoser, so when we want to use it with maas - its not tied to glance :-)
[17:51] <smoser> i dont follow
[17:51] <jamespage> that's entirely hypothetical
[17:51] <smoser> oh. maybe i see a bit.
[17:51] <jamespage> smoser, I actually pushed back on a MP to include this in the glance charm this week; I think it complicates the glance charm when it does not need to
[17:52] <smoser> boo
[17:52] <smoser> link to mp ?
[17:54] <jamespage> smoser, can't find it now
[18:51] <jwal> The answer was to 1) run install in interactive mode 2) copy the relevant output from debconf-get-selections 3) [the step I was missing] change any line ending "password" to "select" (for an empty password) 4) apply the config using debconf-set-selections
[19:24] <bitbyte> hey guys I have a quick question any one able to answer ?
[19:24] <bitbyte> basically i'm setting up strong swan with my home router and its not got a static ip and the server sits behind a firewall performing NAT I keep getting policy=PSK error. Am i going to be able to resolve this issue ? as some suggest the L2TP/IPSEC vpn can not work if the router is performing NAT which the server sits behind
[19:25] <bitbyte> Basically i'm setting up strong swan with my home router and its not got a static ip and the server sits behind a firewall performing NAT I keep getting policy=PSK error. Am i going to be able to resolve this issue ? as some suggest the L2TP/IPSEC vpn can not work if the router is performing NAT which the server sits behind
[19:26] <markthomas> bitbyte: why IPSEC and not OpenVPN?
[19:27] <bitbyte> I've elected to use Strongswan and try setup IPSEC
[19:28] <markthomas> bitbyte: Is this a learning project, or does it fit a specific business or technical need?
[19:29] <bitbyte> It's just personal learning to setup a strong IPSEC VPN
[19:29] <sarnold> I don't know the technical details since our admin set it all up for us eight years back, but we used ipsec for our vpn and we all had NAT systems at home and at the office and things worked out great. though our admin did have the ability to set up the ipsec gateway on the firewall itself, iirc.
[19:30] <bitbyte> the real issue i can see at the moment is that I'm having issues defining the inbound ip's cause they will all be dynamic ones connecting as it will be from different locations.
[19:31] <bitbyte> but I did think that having right=%any and rightsubnet=<IP_ADDRESS>/24 would resolve that
[19:31] <bitbyte> but I keep running into this pesky PSK error
[19:35] <markthomas> bitbyte: It's been quite a few years since I deployed an IPSec VPN as well.
[19:36] <bitbyte> It's been a challenging project the security guys at my work suggested strong swan but only get to quiz them during work hours sadly
[19:37] <sarnold> an excuse to stay home! :)
[19:38] <bitbyte> I work for a banks technical support so their very "official" and shy away from any personal project items
[19:38] <bitbyte> I feel in my config i'm missing something so simple gerrr
[20:17] <zul> jamespage:  libvirt fixed
[20:22] <hallyn_> zul: which libvirt is fixed?
[20:22] <zul> hallyn_:  1.1.2 backport for precise
[20:23] <hallyn_> stgraber: if you happen to have time to add an apparmor profile to trusty's lxc that allows mount fstype=ext*, please feel free :)
[20:23] <hallyn_> you know, in case youthought i'd feel you were stepping on my toes...
[20:23] <hallyn_> zul: ok
[20:26] <stgraber> hallyn_: I found the source of the IPv6 bug, one char fix :)
[20:27] <hallyn_> excellent
[20:27] <stgraber> hallyn_: http://paste.ubuntu.com/6531493/
[20:27] <hallyn_> i'm drafting a message to satan's advisory group^W^W^W dbus m-l
[20:28] <stgraber> (I was looking for bugs in the parser instead of the writer... once I looked at the latter, the bug was rather obvious...)
[20:53] <hallyn_> stgraber: no way!
[20:53] <hallyn_> i swear i straightened those out...
[21:27] <kieppie> hi folks
[21:27] <kieppie> anyone here familiar with LXC?
[21:28] <kieppie> I've been giving it a go on vanilla Debian (wheezy) - but the "stable" & docco's are fubar & it seems absolutely nothing has even been tried to remedy the situation since 2011/2012
[21:30] <e_t_> !anyone
[22:37] <hallyn_> zul: ok, the new failures in libvirt 1.2.0 are http://paste.ubuntu.com/6532080/
[22:38] <hallyn_> perhaps just a virt-install regression
[22:42] <hallyn_> re-running to get the exact error msg
[23:33] <hallyn_> zul: d'oh, virtinst was not installed.

[23:33] <hallyn_> zul: but, do you have a fix yet for libvirt-python upgrade?
[23:55] <hallyn_> zul: all right.  so virtinst depend on python-libvirt which conflicts with libvirt-python.
[23:55] <hallyn_> so if you're not going to rename libvirt-python to python-libvirt, then you must at least create an empty python-libvirt depending on libvirt-python.


[09:10] <pitti> sure, I just try to understand the reason :-)
[09:10] <elmo> pitti: leave him be, he's happy with his old skool tools that most people don't even know exist
[09:10] <elmo> ;P
[09:10] <Kamion> heh
[09:10] <pitti> elmo: I learned about join some months ago
[09:10] <pitti> elmo: I was impressed that all database operations can be done at the shell level :-)
[09:12] <Kamion> pitti: can't reproduce just by putting that in debconf
[09:12] <Kamion> which doesn't surprise me
[09:12] <pitti> Kamion: hmm, I can...
[09:12] <pitti> Value: de_DE ISO-8859-1, de_DE@euro ISO-8859-15, en_GB ISO-8859-1, en_GB.ISO-8859-15 ISO-8859-15, en_GB.UTF-8 UTF-8, fr_FR ISO-8859-1, fr_FR.UTF-8 UTF-8, fr_FR.UTF-8@euro UTF-8, fr_FR@euro ISO-8859-15, ja_JP.EUC-JP EUC-JP, ja_JP.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8
[09:13] <pitti> Kamion: oh yes, I used elmos' original file, too
[09:13] <Kamion> ah, there we go
[09:16] <Kamion> ok, it's postinst breakage I think, working on it
[09:17] <Kamion> look at that suspicious uncommenting/commenting code
[09:18] <Kamion> pitti: do you have a glibc upload in progress? I'll send you a patch when I'm done
[09:18] <pitti> Kamion: I sent my stuff to jbailey
[09:18] <pitti> Kamion: he still has some things to fix
[09:18] <Kamion> ok
[09:18] <pitti> Kamion: so maybe just send it to him
[09:19] <jbailey> Kamion: There's still time.
[09:20] <zyga> why can't we just get rid of all ISO- EUC and KOR stuff?
[09:21] <zyga> it's not like they're here to stay
[09:21] <Kamion> zyga: deleting locales that users might be using is bad karma
[09:22] <Kamion> hence why we just generate UTF-8 equivalents
[09:22] <zyga> Kamion: hyhy
[09:22] <zyga> Kamion: UTF-8 incompatible file deletion tool ;-)
[09:22] <zyga> wipe-your-disk-wizard
[09:22] <Kamion> zyga: utf8-migration-tool :P
[09:23] <Kamion> pitti: aha; locales.postinst generates 1 + 2*(n-1) copies of each locale - so it's fine if n==1
[09:23] <zyga> Kamion: yeah.. but still my /etc/locale.alias has UTF-8 entries :/
[09:23] <Kamion> pitti: once you somehow end up with n>1 copies of any given locale, it will multiply without end
[09:25] <lamont_r> Kamion: base-mumble adds the user to /etc/aliases, but does not run newaliases...  I don't think postfix should automatically do it at startup, since the admin could have some other source for /etc/aliases.db than /etc/aliases... thoughts (#8067)
[09:25] <dholbach> thank you, elmo
[09:25] <Kamion> lamont_r: passwd.config is responsible for that; I don't have time to look at it just now but you're welcome to change as appropriate ...
[09:26] <lamont_r> ok.  is that post debootstrap?
[09:26] <Kamion> lamont_r: yeah
[09:26] <Kamion> lamont_r: pre-reboot though
[09:26] <lamont_r> that's fine - I just need newaliases to be != /bin/true. :-)
[09:27] <drspin> is the default hoary kernel bootsplash ready?
[09:27] <Kamion> drspin: no.
[09:27] <lamont_r> drspin: and it won't be kernel bootsplash, either... it'll be userspace bootsplash, and post-hoary
[09:28] <drspin> lamont_r: thanks for the tip - sorry to bug ;)
[09:28] <lamont_r> np
[09:29] <lamont_r> kernel bootsplash is too invasive, and breaks some hardware, etc, etc.
[09:29] <zul> lamont_r: i bet you have canned resposnes dont you
[09:29] <lamont_r> zul: nah, I just type fast
[09:29] <zul> lamont_r, sure sure
[09:30] <drspin> I've heard that before thanks for reinforcing :)
[09:31] <Kamion> elmo: ok, getting rid of the old dups is a bit complicated, but I've stopped them reproducing
[09:32] <lamont_r> hrm... why does 'acpi' print nothing on my laptop... wonder what we broke.
[09:33] <zul> lamont_r: not me for once
[09:33] <lamont_r> zul:  it's been that way for a while..
[09:33] <zul> lamont_r: still i didnt do it :)
[09:33] <lamont_r> lol
[09:35] <drspin> I have a question - in Hoary on my dual celerons even with acpi=off in my kernel options I still get apic errors on both of my CPUS occassionally
[09:35] <lamont_r> drspin: you know that's really a #ubuntu question, right?
[09:36] <Kamion> elmo: *ah*, I see how it happened
[09:36] <Kamion> elmo: it generated one UTF-8 locale for de_DE ISO-8859-1, and another for de_DE@euro ISO-8859-15
[09:37] <lamont_r> Kamion: damn euros anyway.:-)
[09:38] <ogra> lamont_r, hey, we pay with them....
[09:38] <Kamion> easy fix
[09:38] <ogra> Kamion, pay with pound ?
[09:38] <drspin> lamont: the only response I always get is acpi=off -- no one ever mentioned that I should turn off APM in my bios because it's not SMP safe -- and even if I do what the need I still get the errors -- I've googled like crazy and always just get the ACPI=off solution which doesn't seem to work and I can't find any rhyme or reason to it
[09:39] <dholbach> hm, why didnt  openscenegraph  build on amd64, i mean... didnt even try to?
[09:39] <mdz> dholbach: it looks like it might need some porting, looking at the rules file
[09:40] <mdz> dholbach: it's probably failed in the past and been added to the exclusion list
[09:40] <mdz> lamont_r: can confirm
[09:41] <drspin> should I maybe take it to lkml for a solution?
[09:42] <mdz> drspin: try google first
[09:42] <Mitario> hey everyone
[09:43] <dholbach> mdz: hmmm, should build on amd64    ( * Patch to fix FTBFS on amd64 (closes: #286674)  )
[09:44] <lamont_r> drspin: the short answer is to look at http://people.ubuntu.com/~lamont/buildLogs/Lists/hoary.all.amd64
[09:44] <lamont_r> and see what that says...
[09:44] <dholbach> mdz: that's why i wanted mdz to sync it
[09:44] <dholbach> mdz: erm elmo :-)
[09:45] <mdz> dholbach: the buildds have a list which excludes packages known not to build on certain architectures, in order to avoid wasting time on them.  this needs to be updated when this type of problem is fixed
[09:46] <Kamion> jbailey<EMAIL_ADDRESS>[09:46] <dholbach> mdz: ok thanks, i see
[09:47] <jbailey> Kamion: Please.
[09:51] <Kamion> jbailey: sent
[09:52] <drspin> lamont_r: "short answer" LOL
[09:52] <drspin> thanks I'll google a bit more
[09:53] <Kamion> drspin: I think lamont_r mentioned that to you by accident, rather than to dholbach
[09:53] <lamont_r> drspin: er, sorry.  that was really aimed at dholbach
[09:53] <drspin> heh - LOL
[09:53] <drspin> no worries - I thought it was rather funny
[09:53] <dholbach> lamont_r: thanks, i'll have a look
[09:55] <lamont_r> dholbach: if it says it's depwaited on something in error, holler...
[09:56] <Kamion> jbailey: the sort -u when initialising SELECTED_LOCALES probably applies to Debian too; and in fact it turns out to be an alternative way to fix #271526
[09:56] <dholbach> lamont_r: it says: Dep-Wait by buildd+king [optional:uncompiled]   Dependencies: giflib-dev            - which is provided by giflib3g-dev
[09:56] <jbailey> Kamion: Thanks for that.
[09:57] <dholbach> lamont_r: the other buildds resolved that, hmmmm
[09:57] <Kamion> jbailey: (Denis' patch looks valid too, and there's probably no reason not to apply both :-))
[09:58] <dholbach> hey mvo
[09:58] <mvo> hey dholbach
[09:59] <ogra> hi mvo
[09:59] <mvo> hi ogra
[10:07] <LeeJunFan> anyone else see us.archive.ubuntu.com (<IP_ADDRESS>) as being down?
[10:08] <dredg> it pings
[10:08] <LeeJunFan> no http
[10:08] <dredg> that's different to it being down
[10:09] <LeeJunFan> which screws apt.
[10:09] <LeeJunFan> ok - so http on it is down.
[10:09] <Kamion> yeah, seems so from here too
[10:09] <LeeJunFan> if it doesn't work - it's down :)
[10:10] <dholbach> what does   [Category: none]     not ours     in   http://people.ubuntu.com/~lamont/buildLogs/Lists/hoary.all.amd64    mean?   (sdl-stretch)
[10:10] <LeeJunFan> ftp is working on it.
[10:11] <lamont_r> dholbach: 'amd64 not in arch list ....
[10:11] <lamont_r> debian/control needs an edit to include amd64 where appropriate.
[10:11] <mdz> it's answering, it's just very slow
[10:11] <dholbach> lamont_r: ok, good
[10:11] <mdz> lamont_r: debian/control is Arch: any
[10:14] <lamont_r> mdz: ??
[10:15] <mdz> mizar:[/tmp]  zcat openscenegraph_0.9.8-2.diff.gz| filterdiff -i '*/debian/control' | grep Architecture| sort -u
[10:15] <mdz> +Architecture: all
[10:15] <mdz> +Architecture: any
[10:15] <lamont_r> mdz: sdl-stretch
[10:15] <mdz> oh
[10:15] <lamont_r> ok.
[10:16] <lamont_r> 'not ours' is _ALWAYS_ 'arch not in arch list', and since we auto try faileds (but not d-w's) on upload, it's self clearing.
[10:16] <lamont_r> hrm.. filterdiff
[10:16] <lamont_r> cool
[10:16] <dholbach> lamont_r, mdz: sorry for asking two questions at once
[10:16] <lamont_r> Architecture: i386
[10:17] <lamont_r> dholbach: that's not to say that it _should_ be i386-only...
[10:17] <lamont_r> i386 assembly, I guess that's ok...
[10:17] <lamont_r> but if it builds on amd64, that's easy to fix.
[10:18] <seb128> pitti: around ?
[10:18] <lamont_r> and it's just !m68k in PaS, so you're good there too
[10:18] <pitti> seb128: yes
[10:18] <seb128> pitti: new ping about https://bugzilla.ubuntu.com/show_bug.cgi?id=7725
[10:18] <seb128> pitti: if you know about this file
[10:19] <pitti> seb128: uh, no clue
[10:20] <seb128> pitti: but /usr/share/gnome-volume-manager/gnome-volume-manager-gthumb.sh is a warty thing ?
[10:20] <seb128> if not just close it as NOTWARTY
[10:21] <pitti> seb128: this actually might be a regression in Hoary
[10:21] <seb128> k
[10:21] <pitti> seb128: I deliberately moved this script into /usr/share/g-v-m
[10:21] <pitti> seb128: probably it got dropped in a sync
[10:21] <Kamion> mdz: is casper 0.56 not in arch yet?
[10:22] <seb128> hum
[10:22] <Kamion> mdz: the changelog in casper--main--0 doesn't seem to match up
[10:22] <lamont_r> but I don't _want_ to make a custom install CD... </whine>
[10:23] <zyga> seb128: it had them for a while now
[10:28] <Kamion> mdz: please merge<EMAIL_ADDRESS>up to patch-2<EMAIL_ADDRESS>[10:29] <zyga> Kamion: ah, you arch pepole :)
[10:31] <thom> Kamion: rocking, thanks
[10:31] <mdke> jdub, ping
[10:50] <mdz> Kamion: my mirror isn't up-to-date
[10:50] <mdz> Kamion: updating it now
[10:52] <mdz> ...and merged
[10:57] <Kamion> mdz: ta
[10:57] <Kamion> though still doesn't show as up-to-date
[10:58] <mdz> I bet you're looking at the old chinstrap mirror
[10:58] <mdz> I'm publishing to people.u.c now
[10:58] <mdz> hmm, no, I removed the chinstrap one when I moved it
[10:58] <mdz> ** adding revision casper--main--0--patch-8
[10:58] <mdz> do you not see patch-8?
[10:59] <mdz> community council meeting -> #ubuntu-meeting
[11:00] <Kamion> $ baz archives matt
[11:00] <Kamion><EMAIL_ADDRESS>[11:00] <Kamion><EMAIL_ADDRESS>[11:00] <Kamion> mdz: I'm using that
[11:00] <mdz> that's correct
[11:00] <mdz> and that should have patch-8
[11:00] <Kamion> hmm, something is odd
[11:01] <mdz> mdz<EMAIL_ADDRESS>$ ls -ld patch-8
[11:01] <mdz> drwxr-xr-x    3 mdz      warthogs     4096 Mar 22 21:53 patch-8
[11:01] <pitti> doko: OO.o is certainly a lot more difficult?
[11:02] <doko> :-(
[11:04] <Kamion> mdz: oh, heh. You know what lifeless said earlier about proxy issues?
[11:05] <mdz> ick, why does that break?
[11:05] <Kamion> mdz: I think that could do with a more descriptive changelog though ...
[11:06] <Kamion> mdz: the cache's copy of .listing only went up to patch-4
[11:06] <mdz> Kamion: I'll fix it when I actually go back and see what it is you changed ;-)
[11:06] <Kamion> hah
[11:06] <mdz> one of these days one of us needs to write a tool for this
[11:06] <Kamion> 'baz changelog' says
[11:06] <mdz> to manage patch-logs vs. changelogs
[11:06] <mdz> patch-logs vs. debian/changelog I mean
[11:07] <mdz> ideally I would be able to merge changelog entries along with your changes
[11:07] <mdz> but creating new versions in different branches is a big mess
[11:07] <mdz> and merging changelogs in general
[11:07] <Kamion> yeah, currently I'm avoiding creating debian/changelog entries for that exact reason
[11:07] <Kamion> even for my own packages, I create them only when doing a new release
[11:08] <Kamion> but that sucks for other reasons, it's more awkward to build test versions
[11:09] <mdz> yeah
[11:09] <Kamion> pitti: took a few hours to do the installer support, too
[11:09] <Kamion> although it got quicker as I went through
[11:09] <mdz> what I've started doing (when I think of it) is to put in a changeset which does nothing but open a new version in changelog
[11:09] <mdz> and then commit changelog entries along with the changes
[11:09] <pitti> Kamion: yeah, I didn't have to upload half of the world for it :-)
[11:09] <mdz> this is something to be addressed with the next rev of the source package format
[11:10] <Kamion> sounds more like a special hct merge op, to me ...
[11:10] <Kamion> I mean upstreams that keep ChangeLog files have the same problem
[11:10] <mdz> the existing changelog format is not very suitable
[11:11] <mdz> ChangeLog is easier in this respect
[11:32] <mdz> thom: iirc, the maintainer script and/or a script it calls does that ON PURPOSE
[11:32] <mdz> oh, it uses mktemp -d now
[11:32] <mdz> and sets home to that
[11:33] <thom> hrrrm
[11:33] <thom> mdz: thanks, i'd forgotten about that
[11:33] <thom> mdz: that seems to be part of the cause of 7711
[11:33] <mdz> /usr/lib/mozilla-firefox/firefox is a nightmare of HOME madness
[11:35] <thom> yeah; none looks to be setting HOME to something whacky unless you're running under sudo, tho
[11:35] <mdz> it's the chrome update script which does the mktemp madness
[11:39] <Amaranth> woohoo, pyxdg patched upstream
[11:41] <lamont> Kamion: could you kick hoary_outdate.txt to current for me?
[11:43] <Kamion> lamont: done as best I can (can only kick the mirror)
[11:44] <dholbach> lamont: openscenegraph built fine on amd64, what do i have to do to make it build on the buildd too?   (Dep-Wait by buildd+king [optional:uncompiled]   Dependencies: giflib-dev)
[11:44] <pitti> infinity: here?
[11:46] <mdz> lamont: giflib-dev is provided by giflib3g-dev and libungif4-dev, both of which are built on amd64
[11:46] <dholbach> and the other buildds have no hassle at all
[11:46] <elmo> yes, but it's a virtual
[11:46] <elmo> w-b doesn't understand virtuals
[11:46] <elmo> a simple give-back will fix
[11:47] <elmo> I suspect the dep-wait pre-dates lamont's auto-depwaiter, or maybe the ordering of the building was just unfortunate on amd64
[11:49] <elmo> who uploaded pinfo?
[11:51] <dholbach> elmo: me
[11:52] <dholbach> sponsored the upload to a wannabe-motu
[11:52] <elmo> dholbach: please remember to either fix the Changed-By: field or ask me to whitelist the email address
[11:52] <elmo> (the latter is almost no work for me, and preferable in the long run)
[11:52] <dholbach> elmo: just ask you and state the mail adress?
[11:53] <elmo> dholbach: yah
[11:53] <Kamion> latter definitely preferable so that the changed-by: field is there for future MOTU approvals and such
[11:53] <dholbach> elmo: no signed mails by them to<EMAIL_ADDRESS>[11:53] <dholbach> Kamion: i totally agree
[11:53] <elmo> dholbach: nah, it's just an email whitelist, doesn't give them any privs
[11:53] <dholbach> elmo: alright, will do
[11:53] <dholbach> elmo: and pass the word :-)
[11:54] <zenwhen> hey Amaranth
[11:55] <elmo> pitttttttttttttti
[11:55] <mdz> elmo: can you give-back openscenegraph, if you haven't already?
[11:55] <pitti> ellllllllllllmo?
[11:55] <elmo> mdz: done
[11:55] <elmo> pitti: got some more security reviews for you, sorry dude
[11:56] <mdz> thanks
[11:56] <pitti> darn, I wasn't fast enough, just wanted to go to sleep :)
[11:56] <pitti> elmo: which ones?
[11:56] <pitti> elmo: ... and would tomorrow (i. e. now + 9 hours) be enough?
[11:57] <elmo> pitti: sure
[11:57] <elmo> I'll mail you
[11:57] <elmo> go sleep
[11:57] <pitti> okay, fine
[11:57] <pitti> night everybody!


[03:44] <amurray> would be good to get snaps listed on this page https://github.com/google/sandboxed-api/blob/master/sandboxed_api/docs/sandbox-overview.md
[06:09] <mborzecki> morning
[06:09] <zyga> Good morning
[06:10] <mborzecki> just been outside, really feels like spring
[06:10] <zyga> amurray: interesting
[06:10] <zyga> mborzecki: I’m just stepping out
[06:10] <zyga> My back is killing me today, way too many hours coding yesterday
[06:11] <zyga> I will need a longer walk today
[06:11] <mborzecki> zyga: buy a standing desk
[06:11] <zyga> Eventually :-)
[06:12] <zyga> I need to buy new NAS disks next month
[06:12] <mborzecki> zyga: every couple of months tehre are some nice discouts at ikea
[06:15] <zyga> Does one go with mdraid or zfs nowadays?
[06:17] <zyga> I plan to get 3x(~5) TB in raid-5 and a 10+ TB drive for weekly snapshot off-case in case the main nas melts
[06:46] <mborzecki> looking at gadget validation again, obviously forgot to check that size must be set at the structure level :/
[07:02] <zyga> back in the office
[07:13] <zyga> mborzecki: could you please look at https://github.com/snapcore/snapd/pull/6636
[07:13] <mup> PR #6636: cmd: prevent umask from breaking snap-run chain <Created by zyga> <https://github.com/snapcore/snapd/pull/6636>
[07:13] <zyga> it's not big but I want a second pair of UNIXy eyes :)
[07:16] <mborzecki> zyga: LOOKING
[07:20] <mborzecki> damn caps
[07:21] <mborzecki> mvo: morning
[07:21] <mvo> hey mborzecki
[07:21] <mvo> mborzecki: good morning
[07:29] <mborzecki> zyga: lgtm, left a comment about trying out umask 000 in the spread test too
[07:30] <mborzecki> after all if it's supposed to be restored fully
[07:38] <zyga> mborzecki: thank you, I will add more tests
[08:02] <zyga> linux is funny
[08:02] <zyga> mborzecki: you can have a process that lives in a current working directory that doesn't exist in its own mount namespace at all
[08:02] <zyga> funny things happen
[08:05] <pstolowski> morning
[08:07] <mborzecki> pstolowski: hey
[08:08] <zyga> hey pawel :)
[08:08] <zyga> hey mvo
[08:14] <mvo> hey zyga and pstolowski
[08:23] <ackk> zyga, hi, I just hit that issue with the snap (under try) reporting not found on executables inside the snap
[08:23] <ackk> zyga, how do I cat mountinfo in the right ns again?
[08:24] <zyga> hey! thank  you for asking: use sudo nsenter -m/run/snapd/ns/foo.mnt
[08:24] <zyga> then inside the new shell run cat /proc/self/mountinfo
[08:24] <zyga> this information will be very useful
[08:24] <zyga> a bit of usabilty warning: there cannot be a space between -m and the path
[08:25] <ackk> ah that's what was hitting me
[08:26] <ackk> zyga, btw strace doesn't seem to give much info: https://paste.ubuntu.com/p/xf3WQRZWyw/
[08:28] <ackk> zyga, what should I look for in the mountifo?
[08:28] <zyga> deleted
[08:28] <zyga> but I would love to see the whole listing
[08:28] <ackk> zyga, http://paste.ubuntu.com/p/zBq4X3TMXb/
[08:28] <ackk> (this is in the ns)
[08:28] <ackk> no deleted
[08:29] <zyga> interesting
[08:29] <zyga> hmm hmm
[08:29] <zyga> can you run snap run --shell maas?
[08:29] <ackk> same errorr (execv failed)
[08:30] <zyga> hmmm
[08:30] <zyga> mborzecki: ^ any ideas
[08:30]  * zyga reads the mountinfo data
[08:31] <ackk> zyga, ftr I've run the rsync like hundred times yesterday and no issue
[08:31] <ackk> it's always like that, it randomly happens once in a while
[08:31] <zyga> ackk: what I find curious is that you can clearly nsenter
[08:31] <zyga> ackk: what's the base snap?
[08:31] <ackk> zyga, core18
[08:31] <zyga> ackk: what are you tracking (which channel of the base snap)
[08:32] <zyga> ackk: did it refresh recently?
[08:32] <ackk> oh, I'm on core18 edge
[08:32] <mborzecki> hm that strace doesn't have much content
[08:32] <ackk> ah yes esterday
[08:32] <mborzecki> is that a classic snap?
[08:32] <ackk> refresh-date: yesterday at 13:38 UTC
[08:32] <zyga> ackk: did it break at around the same time it refreshed?
[08:33] <zyga> ackk: ahhh
[08:33] <zyga> I know :D
[08:33] <zyga> man
[08:33] <zyga> hold on please
[08:33]  * ackk curious
[08:34] <zyga> ah, no :/
[08:34] <zyga> man, I thought this is it
[08:34] <zyga> we don't support try mode base snaps
[08:34] <zyga> but that's clearly not it
[08:34] <mborzecki> zyga: looks like it faiedl executing snap-confine, unless i'm missing something
[08:34] <zyga> ackk: when you rsync, what do you do exactly?
[08:35] <zyga> Permission denied is curious
[08:35] <ackk> zyga, https://github.com/maas/maas/blob/master/Makefile#L781
[08:35] <zyga> ackk: do you have any apparmor denials?
[08:36] <ackk> zyga, it doesn't seem so
[08:36] <ackk> I mean I have stuff in dmesg but I don't see new errors if I try to run it
[08:36] <mborzecki> ackk: can you run /snap/core/6531/usr/lib/snapd/snap-confine --base core18 snap.maas.maas /usr/lib/snapd/snap-exec maas at all?
[08:36] <zyga> mborzecki: don't forget SNAP_INSTANCE_NAME=maas
[08:37] <ackk> no, same error
[08:37] <zyga> permission?
[08:37] <zyga> check dmesg again please
[08:37] <ackk> $ SNAP_INSTANCE_NAME=maas /snap/core/6531/usr/lib/snapd/snap-confine --base core18 snap.maas.maas /usr/lib/snapd/snap-exec maas
[08:37] <ackk> execv failed: No such file or directory
[08:37] <zyga> wait
[08:37] <zyga> before it was a permission denied error
[08:37] <ackk> no new error
[08:37] <zyga> ackk: since this a  core18 snap
[08:37] <zyga> snapd (and snap-exec) come from another snap
[08:37] <zyga> can you check one more thing
[08:38] <zyga> run that same SNAP_INSTANCE_NAME=... line but run /bin/sh at the end
[08:38] <zyga> instead of snap-exec that is
[08:38] <zyga> once on the inside
[08:38] <zyga> run ls -ld /usr/lib/snapd/snap-exec
[08:38]  * zyga looks at mountinfo list again
[08:38] <zyga> er
[08:38] <mborzecki> zyga: s-c does some work, if it ran i'd expect to see taht in strace log
[08:38] <ackk> $ SNAP_INSTANCE_NAME=maas /snap/core/6531/usr/lib/snapd/snap-confine --base core18 snap.maas.maas /bin/ls -ld /usr/lib/snapd/snap-exec
[08:38] <ackk> /bin/ls: cannot access '/usr/lib/snapd/snap-exec': No such file or directory
[08:39] <zyga> there's no /usr/lib/snapd!
[08:39] <ackk> there is but it's empty
[08:39] <zyga>  SNAP_INSTANCE_NAME=maas /snap/core/6531/usr/lib/snapd/snap-confine --base core18 snap.maas.maas /bin/sh
[08:39] <zyga> then cd /usr/lib
[08:39] <zyga> ls -ld snapd
[08:39] <zyga> ls -l snapd
[08:40]  * zyga checks stuff
[08:40] <ackk> $ ls -lad snapd
[08:40] <ackk> drwxr-xr-x 2 root root 0 Mar 21 11:41 snapd
[08:40] <ackk> $ ls -l snapd
[08:40] <ackk> total 0
[08:40] <ackk> the dir is there, but empty
[08:40] <ackk> is that a mountpoint?
[08:40] <ackk> I mean, does snapd bind-mount stuff on top?
[08:41] <zyga> it should be a mountpoint
[08:41] <ackk> zyga, so you think it could be related to the core refresh?
[08:41] <zyga> that explainswhat you are seeing
[08:41] <zyga> perhaps
[08:42] <zyga> can you collect snap changes and add this to the bug report
[08:42] <ackk> it might well be that's been broken since yesterday,but I haven't restarted the service (nor called the cli) since then, although I think I did
[08:42] <zyga> ackk: do you have snapd.snap?
[08:42] <ackk> zyga, where?
[08:42] <zyga> is snapd the snap installed on your system
[08:43] <ackk> no
[08:43] <zyga> snap list | grep snapd :)
[08:43] <zyga> ok
[08:43] <zyga> thank you
[08:43] <zyga> ackk: I think we have enough to explore this now
[08:43] <zyga> the key question is what happens when core18 + core + app combo has a refresh of core18
[08:43] <zyga> or a refresh of core
[08:43] <zyga> when core refreshes it's different
[08:43] <zyga> actually
[08:43] <zyga> that's a separate bug
[08:43] <zyga> we will never update the tooling
[08:43] <zyga> mvo: core18/core bug
[08:44] <ackk> are core18 apps still somewhat dependent on core?
[08:44] <ackk> I think I had filed a bug a long time ago about it, and I've still seen the issue recently
[08:44] <zyga> mvo: when /usr/lib/snapd comes from core on a core18 base snap app, the core refresh is not reflected in the mount namespace of the app
[08:44] <zyga> that is
[08:44] <mvo> zyga: they shouldn't be - hm, hm
[08:44] <zyga> mvo: future snapd is using old snap-exec
[08:44] <zyga> mvo: it's like a stale base snap prolem
[08:44] <mvo> zyga: oh, snap-exec is not coming from snap?
[08:44] <zyga> mvo: but a stale core snap sub-problem
[08:44] <mvo> zyga: not from the snapd snap?
[08:45] <zyga> mvo: when it comes from core
[08:45] <pedronis> there is snapd snap aroung yet
[08:45] <zyga> mvo: core18 + core (as source of snap tools) + app
[08:45] <pedronis> there is *no*
[08:45] <zyga> mvo: core refreshes
[08:45] <zyga> mvo: now you have stale tools in the app snap
[08:45] <mvo> ok
[08:45] <zyga> mvo: or perhaps that is exactly what ackk observed, an tools just disappear somehow
[08:45] <ackk> zyga, fwiw "core" refreshed 10 days ago
[08:45] <pedronis> zyga: basically  all the snaps that compose the mount namespace can have a staleness prolem no?
[08:45] <pedronis> also content snaps
[08:45] <zyga> mvo: thank you
[08:46] <zyga> pedronis: yes
[08:46] <mvo> zyga: what do we need to do to unstable the mount namespace?
[08:46] <pedronis> zyga: we check only base though?
[08:46] <zyga> pedronis: content snaps are better
[08:46] <zyga> pedronis: because those are new paths that change in the mount profile
[08:46] <zyga> pedronis: so they are correctly updated
[08:46] <zyga> pedronis: it's just the core tooling for now
[08:46] <zyga> pedronis: nothing else exists outside of the snap-update-ns system
[08:47] <zyga> pedronis: yes, we check for base only explicitly because that's the do-I-rebuild-from-scratch decision
[08:47] <zyga> mvo: can you rephrase the question please?
[08:47] <ackk> zyga, should I try refreshing core18 (to stable perhaps)?
[08:47] <zyga> ackk: to aid in debugging? no, to lower the inconvenience for your development: yes
[08:47] <mvo> zyga: what do we need to do to fix this .) ?
[08:47] <zyga> ackk: you can discard the mount namespace to fix it
[08:48] <zyga> mvo: I dont know yet, I don't fully undestand the reason /usr/lib/snapd was empty
[08:48] <zyga> but I think we should be able to reproduce it now
[08:48] <ackk> zyga,  the var/lib/snapd in the snap?
[08:48] <zyga> ackk: sorry?
[08:48] <zyga> mvo: perhaps it's one issue after all
[08:48] <ackk> zyga, oh sorry, discard the namespace I see
[08:49] <ackk> zyga, I thought you meant unmounting something
[08:49] <zyga> mvo: sudo /usr/lib/snapd/snap-discard-ns mass
[08:49] <zyga> er
[08:49] <zyga> ackk: ^ :)
[08:49] <ackk> zyga, thanks
[08:49] <ackk> zyga, oh refreshing to stable also worked
[08:50] <zyga> yes
[08:50] <zyga> because then you have new base
[08:50] <zyga> and you get a fresh mount ns
[08:50] <ackk> I see
[08:50] <zyga> ackk: thank you very much for this
[08:50] <zyga> please do report the bug
[08:51] <zyga> we may split it if this turns out to be a pair of issues
[08:51] <ackk> zyga, thank you for digging it
[08:51] <zyga> I will work on it next week for sure
[08:51] <pedronis> fyi, I need to do some non-PR work before getting back to reviewing
[08:52] <ackk> zyga, is "snap stops working after base refresh" accurate as a title?
[08:52] <zyga> ackk: /usr/lib/snapd unmounted in app + core18 + core (tooling) use case; possibly on core refresh
[08:52] <zyga> that is the summary in my head
[08:53] <ackk> zyga, but it was a core18 refresh, not core
[08:53] <zyga> ah, sorry
[08:53] <zyga> I will check all combinations though
[08:54] <zyga> there are clearly missing bits there
[08:55] <zyga> brb, coffee ran out
[08:59] <ackk> zyga, https://bugs.launchpad.net/snapd/+bug/1821302
[08:59] <mup> Bug #1821302: /usr/lib/snapd unmounted in app + core18 + core (tooling) use case; possibly on core18 refresh <snapd:New> <https://launchpad.net/bugs/1821302>
[09:06] <zyga> ack :)
[09:07] <zyga> this is the week of snap-confine fixes and changes
[09:22] <ackk> zyga, IDK if it could be related, but I still see the issue where if I install a core18-based snap on a clean system (no core snap) it fails to install (the configure hook fails)
[09:22] <ackk> zyga, e.g. snap install --edge maas
[09:22] <zyga> ackk: yes, this is related
[09:22] <zyga> ackk: we track that bug separately now
[09:22] <ackk> zyga, do you have the link?
[09:22] <zyga> ackk: I have a draft solution on my system but it will not be ready yet
[09:24] <zyga> ackk: there's a forum thread aboug this, i have not upgraded it to a bug report yet: https://forum.snapcraft.io/t/problems-installing-a-base-core18-snap-on-bionic/10084/
[09:25] <ackk> zyga, ah cool thanks
[09:28] <zyga> mborzecki: https://www.omgubuntu.co.uk/2019/03/linux-data-cap-survey
[09:29] <mborzecki> aah survey
[09:29] <mborzecki> nice
[09:31] <pstolowski> mvo: hey, added some extra tests you suggested for #6591
[09:31] <mup> PR #6591: overlord/ifacemgr: basic measurements <Created by stolowski> <https://github.com/snapcore/snapd/pull/6591>
[09:33] <mborzecki> zyga:  haha 'RSS feeds' in question 'How would you prioritise these data to download if you had limited internet access?'
[09:33] <zyga> yeah
[09:33] <zyga> who cares about that
[09:33] <zyga> who ordered RSS?
[09:34] <mvo> pstolowski: thanks, looking
[09:35] <zyga> completed the survey
[09:35] <zyga> as someone who is on capped links 24/7 it's important that people care about this
[09:36] <mup> PR snapd#6637 opened: interfaces: deal with the snapd snap correctly for apparmor 2.13 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6637>
[09:38] <pedronis> mvo: there's a card for that https://trello.com/c/1h4hrY3W/180-implement-snapd-snap-support-in-apparmor-backend-dbus-backend-setup-etc  ^
[09:39] <pedronis> also I think there were todo left in other backends too
[09:40] <mvo> pedronis: indeed, added the PR and will see what else needs to be done there
[10:00] <pedronis> mvo: should also be moved to doing :)
[10:31] <pedronis> mborzecki: hi, do you know why we would get a line like this:
[10:31] <pedronis> content                   gnome-calculator:gtk3-themes      gtk-common-themes:gtk3-themes
[10:31] <pedronis> in connections,  there is not content discriminant there
[10:31] <mborzecki> pedronis: that with 2.38?
[10:31] <pedronis> with edge
[10:32] <pedronis> but anyway I get the other ones with []
[10:32] <pedronis> but not that one
[10:32] <pedronis> I thought we always set one internally
[10:32] <pedronis> mborzecki: I'm doing snap connections gnome-logs
[10:32] <mborzecki> pedronis: mhm, installing the snap right now
[10:34] <mborzecki> hmmm pinner with 'Automatically connect eligible plugs and slots of snap "gnome-calculator"', didn'g we have a fix that would switch to showing progress of the download if a dependncy is being installed?
[10:34] <mborzecki> s/pinner/spinner/
[10:36] <mborzecki> pedronis: .38 has 		//
[10:36] <mborzecki> content[gnome-3-28-1804]  gnome-calculator:gnome-3-28-1804  gnome-3-28-1804:gnome-3-28-1804  -
[10:37] <mup> PR snapd#6638 opened: interfaces: add support for the snapd snap in the dbus backend  <Created by mvo5> <https://github.com/snapcore/snapd/pull/6638>
[10:37] <pedronis> mborzecki: I'm talking about gtk3-themes
[10:37] <pedronis> but I don't see that in the snaps
[10:37] <pedronis> mmh
[10:37] <mborzecki> content[gtk-3-themes]     gnome-logs:gtk-3-themes     gtk-common-themes:gtk-3-themes   -
[10:37] <mborzecki> content[icon-themes]      gnome-logs:icon-themes      gtk-common-themes:icon-themes    -
[10:38] <mborzecki> content[sound-themes]     gnome-logs:sound-themes     gtk-common-themes:sound-themes   -
[10:38] <pedronis> mborzecki: it's the issue that we don't remove non-existent connections I suppose
[10:38] <pedronis> mborzecki: it's  not a connections problem, it's other issues
[10:38] <pedronis> mborzecki: if you just installed it you won't see that
[10:39] <mborzecki> pedronis: buf if i disconect, remove and reinstall?
[10:39] <pedronis> yes, a different case
[10:47] <zyga> mvo: fun bug, command-not-found is still in use while in snap run- --hell
[10:47] <zyga> (I meant --shell)
[10:47] <zyga> but the binary is not there anymore
[10:52] <pstolowski> failed to prepare google:opensuse-15.0-64:project, do we have an issue with opensuse in gcloud again?
[10:54] <mup> PR core18#122 opened: hooks: add apt/apt-get/apt-cache warning <Created by mvo5> <https://github.com/snapcore/core18/pull/122>
[11:03] <zyga> pstolowski: what was the failure?
[11:04] <zyga> pstolowski: ah, I see it now
[11:04] <zyga> cachio: ^ we need to change how we install packages
[11:04] <zyga> mborzecki: ^ any ideas, is that a stale cache?
[11:05] <zyga> openSUSE Leap 15.0 package installation issue in spread https://www.irccloud.com/pastebin/Z5UvBD4B/
[11:06] <mborzecki> hmm
[11:07] <pstolowski> zyga: interesting, i didn't see any error output for google:opensuse-15.0-64:project, just failed to prepare
[11:07] <zyga> I saw this in one of my own runs
[11:07]  * zyga needs to take a break
[11:08] <zyga> to avoid the chronic back pain
[11:08] <zyga> mborzecki: there will be an interesting patch later today
[11:08] <zyga> mborzecki: another unixy thing :)
[11:09] <mborzecki> no clue about that opensuse thing, perhaps unfinished mirror sync?
[11:09] <zyga> I think it's like dnf upgrade vs dnf distrosync
[11:10] <pedronis> pstolowski: is there anything left for 6491 that can't be follow ups about improving the test?
[11:10] <zyga> we are probably doing something wrong and should be using "dnf dup" instead of another operation
[11:10] <mborzecki> but it's leap, zypper up should be enough
[11:10] <zyga> mborzecki: up != dup
[11:10] <zyga> mborzecki: but not sure :/
[11:10] <zyga> anyway, I spawned some larger testing for an important snap-confine change, I will break for an hour to move around a bit
[11:10] <mborzecki> zyga: i mean zypper up should be enough for leap, tw has it's own weirdnness :)
[11:10] <zyga> I'm on telegram if anyone needs me urgently
[11:11] <MattJ> \\\\\\!
[11:11] <MattJ> Sorry, words of wisdom from my daughter there
[11:12] <zyga> haha :)
[11:16] <ackk> zyga, just to confirm, I hit the issue again (no core refresh this time) and calling snap-discard-ns fixed it
[11:19] <ackk> zyga, actually not so much, now I get a "read only filesystem" error
[11:21] <ackk> cannot create user data directory: /root/snap/maas/x1: Read-only file system
[11:25] <zyga> ackk: x1 got unmounted somehow?
[11:26] <ackk> zyga, well I suspect it's because of the discard ns ?
[11:26] <zyga> ackk: is your snap "broken" (as in snap list shows broken next to it)
[11:26] <zyga> no, that's not doing that
[11:26] <ackk> no it wasn't
[11:26] <zyga> discard will not change /snap/anything
[11:26] <ackk> (now I actually removed it)
[11:26] <zyga> ah, wait
[11:26] <zyga> I misread that
[11:26] <zyga>  what is /root/snap/maax/x1
[11:26] <zyga> is that a bind mount?
[11:27] <zyga> it would only be a ROFS in case it's a bind mount or if /root inside the mount namespace was unmounted
[11:27] <zyga> but if _that_ is the case then I would really like to know what's going on
[11:28]  * zyga is AFK now
[11:29] <ackk> zyga, it's the user dir
[11:39] <mborzecki> the fun start when offset 0 is a valid value
[11:40] <mborzecki> looks like some of the fields in our gadget structures should be pointers
[11:46] <mborzecki> off to the kids' school for a bit
[12:12] <pstolowski> pedronis: sorry, missed your earlier message; no, nothing left to do in #6491
[12:12] <mup> PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491>
[12:14] <pstolowski> nb it failed on 14.04 with 'system does not fully support snapd: cannot mount squashfs image' ?!
[12:14] <pstolowski> among 2 other unrelated test failures.. interfaces-daemon-notify seems to be flaky
[12:17] <geodb27> People : hi ! I've come to this issue with the snap version of lxd : https://github.com/lxc/lxd/issues/5590 is that related to snap or to lxd and is there a way to get things work as they are expected to ? To be more specific, I guess that snap don"t like user's home directory to be out of /home
[12:19] <pstolowski> geodb27: correct, user homes need to be in /home currently, no way around that
[12:21] <geodb27> So, my guess was right, thanks for you answer pstolowski. However, to my knowledge, snap is the only one I encounter that relies on this. Is there any technical reason for that (I'm only curious) ? There is an env var set at user login which is filled in with the home directory. Why not use it ?
[12:21] <pedronis> pstolowski: did it have a recent master merge?
[12:21] <pstolowski> pedronis: hmm possibly not, i merged yesterday. doing
[12:26] <pstolowski> geodb27: it's more complicated due to confinement (apparmor profiles etc)
[12:28] <geodb27> oki, I see, thanks again for your kind explanation pstolowski. This will lead me to to many changes on my servers... I'll see how I can go with the less damages.
[12:28] <pstolowski> geodb27: you're welcome!
[12:35] <cachio> zyga, taking a look  to opensuse now
[12:36] <zyga> geodb27: I can refer you to the technical reasons but I am AFK now
[12:36] <zyga> Thanks cachio
[12:53] <mborzecki> re
[12:58] <mup> PR snapd#6639 opened: snap: tweak parsing errors of gadget updates <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6639>
[13:19] <ackk> zyga, why would snapd try to create that directory (/root/snap/maas/x1 when starting a service?
[13:30] <zyga> ackk: we create SNAP USER DATA
[13:30] <zyga> because snaps themselves cannot
[13:31] <ackk> yeah but that dir is there
[13:31] <ackk> why does the snap  suddenly thinks it's readonly
[14:41] <mup> PR snapd#6640 opened: spread: refresh metadata on openSUSE <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6640>
[14:47] <mborzecki> zypper tell me the latest version of libudev is 234-lp<IP_ADDRESS>, not 234-lp150.19.1.x86_64
[14:49] <mborzecki> cachio: was opensuse-15.0 image already updated?
[14:57] <diddledan> did the forum fall over? https://usercontent.irccloud-cdn.com/file/kZeiOkOL/image.png
[15:02] <diddledan> seems opening a different tab rectified it
[15:02] <diddledan> ignore me
[15:06] <cachio> mborzecki, no yet
[15:07] <cachio> mborzecki, found more problems
[15:07] <cachio> mborzecki, some package digests are different
[15:20] <cachio> mborzecki,  the image is ready and uploaded
[15:21] <cachio> uploading
[15:28] <mborzecki> cachio: cause before asking i tried running zypper in <packages> that were failing in the test and it worked, so maybe just a mirror sync problem
[15:28] <mborzecki> cachio: still, zypper up show a number of updates avaialble at that point, will try with an updated image now
[15:33] <cachio> mborzecki, yes, the mirrors are giving us problems
[15:33] <cachio> mborzecki, I already updated all the packages to make the update process faster
[15:33] <cachio> I is almost uploaded
[15:36] <cachio> mborzecki, image ready
[15:38] <mborzecki> cachio: it probably was something with mirror sync, #6640 started before an updated image was uploaded and it's green
[15:38] <mup> PR #6640: spread: refresh metadata on openSUSE <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6640>
[15:41]  * cachio lunch
[15:42] <Wimpress> The next Snapcraft Summit has been announced - https://snapcraft.io/blog/snapcraft-summit-montreal
[15:46] <mup> PR snapd#6641 opened: snap-gdb-shim: switch to the SUDO_UID when available <Created by mvo5> <https://github.com/snapcore/snapd/pull/6641>
[15:46] <kenvandine> zyga: we're continuing to see reports on the forum of users not able to run the gnome snaps because the content interface isn't mounted
[15:47] <kenvandine> zyga: it's something i've only seen a couple times and  snap-discard-ns seems to resolve it
[15:48] <kenvandine> zyga: latest reference https://forum.snapcraft.io/t/gnome-calculator-problem/4579
[15:48] <mup> PR snapd#6640 closed: spread: refresh metadata on openSUSE <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6640>
[15:50] <kenvandine> zyga: if i can't find an existing bug report, i'll file a new one
[15:51] <pstolowski> pedronis: you've requested John's review on #6591; is it required or can it land now that it has mvo's review?
[15:51] <mup> PR #6591: overlord/ifacemgr: basic measurements <Created by stolowski> <https://github.com/snapcore/snapd/pull/6591>
[15:51] <pedronis> pstolowski: it can land, I asked him in case mvo didn't have time
[15:51] <pstolowski> ack
[15:52] <pstolowski> thx
[15:52] <mup> PR snapd#6591 closed: overlord/ifacemgr: basic measurements <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6591>
[15:54] <kenvandine> zyga: bug 1785410
[15:55] <mup> Bug #1785410: Can not open Gnome snaps as they are not connected to «gnome platform snap» <amd64> <apport-bug> <bionic> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1785410>
[16:05] <popey> zyga: what do we need to do to bump the priority of that bug? It's pretty harmful as people use it as a reason to remove snaps entirely
[16:05] <kenvandine> mvo: ^^
[16:07] <mvo> kenvandine: in a meeting, adding it to our trello, we get back to you
[16:07] <kenvandine> mvo: thanks
[16:09] <diddledan> user: "compiling this application is difficult with no docs on what it depends upon proving that linux sucks" my reply: "I made a snap of this app so you don't need to compile it!" their retort: "another packaging system isn't the solution. compiling stuff is proving that linux is terrible" <-- I tried to point out that compiling the application on Windows or Mac would be just as difficult, but they insisted that it proves
[16:09] <diddledan> linux is crap
[16:10] <mvo> kenvandine: I have not looked at all at this though, sorry :/ will also check with zyga
[16:10] <diddledan> specifically starruler2 (game) was what they were trying to compile
[16:17] <zyga> re
[16:17]  * zyga reads backlog
[16:18] <zyga> kenvandine: I will investigate several related reports next week,
[16:18] <zyga> kenvandine: thank you for the bug report
[16:19] <zyga> kenvandine: right now no immediate smoking gun but we know of one issue related to core18
[16:19] <zyga> kenvandine: but perhaps there's more magic to uncover there
[16:20] <zyga> kenvandine: anyone with instructions on how to reporduce would be awesome as all of those bugs are "not sure how I got there but..."
[16:21] <zyga> kenvandine: I will write a few new tests next week, specifically when there's a mount namespace consisting of an app snap a base snap (e.g. core18) and the core or snapd snaps providing the tools, each of those can refresh / change
[16:21] <zyga> kenvandine: we don't have full test coverage for that scenario as we learned
[16:21] <zyga> kenvandine: all of the snap-update-ns / snap-confine bugs are my priority and I will investigate them ASAP
[16:22] <kenvandine> zyga: yeah, this is something we've seen randomly for ages now, since the gnome-24 content snap
[16:23] <zyga> kenvandine: we fixed one known issue: base snap refresh was buggy (in two ways actually)
[16:23] <zyga> kenvandine: we know of several more issues: when base snap changes (core -> core18) we do bad stuff if the app is still running
[16:24] <zyga> kenvandine: and when the snapd tooling (snap-exec snapctl) is coming from core/snapd on a snap using base: core18 there is no handling for that becoming stale
[16:24] <zyga> kenvandine: I was discussing with ackk earlier today when his try snap was misbehaving
[16:24] <zyga> kenvandine: and some of the observations indicated that various things got unmounted
[16:25] <zyga> kenvandine: next week I will collect all the bugs and recent forum postings, try to file missing bugs and triage them, then write extra tests to see if anything can be reproduced this way
[16:42] <kenvandine> zyga: thanks
[16:42] <pedronis> pstolowski: I created a meeting for Monday, let me know if it doesn't work
[16:44] <pstolowski> pedronis: it's fine, thank you
[17:24] <cachio> mvo, I see this error on nightly test suite https://paste.ubuntu.com/p/Bp2xw9H8p6/
[17:28] <mvo> cachio: this looks like a store timeout: Client.Timeout
[17:28] <mvo>        exceeded while awaiting headers
[17:28] <cachio> mvo, it is weird because it failed many times
[17:29] <cachio> yesterday and today
[17:29] <mvo> cachio: oh, ok - maybe a real problem on the store, might be best to ask in #snapstore
[17:29] <cachio> ok
[17:34]  * zyga resumes work on the cwd fixes
[18:54] <zyga> first test corrected
[18:55] <LinAGKar> I can't run any snaps on OpenSUSE Tumbleweed. I just get "cannot read mount namespace identifier of pid 1: Permission denied", and prevously I have gotten "libmount.so.1 snap shared library not loading".
[18:56] <zyga> second test also corrected
[18:56] <zyga> jdstrand: do you want to see it?
[18:56] <zyga> LinAGKar: hello
[18:56] <zyga> LinAGKar: what version of snapd are you on?
[18:57] <zyga> LinAGKar: can you look at /var/log/audit/audit.log (as root) and grep for "DENIED"
[18:57] <zyga> LinAGKar: give me the denials please
[18:57] <zyga> and thank you for reporting this!
[18:58] <LinAGKar> I have `type=AVC msg=audit(1553279757.513:482): apparmor="DENIED" operation="ptrace" profile="/usr/lib/snapd/snap-confine" pid=24430 comm="snap-confine" requested_mask="read" denied_mask="read" peer="unconfined"` there.
[18:59] <zyga> LinAGKar: wow, thats' curious
[18:59] <zyga> LinAGKar: uname -a?
[18:59] <LinAGKar> zyga: I have snapd 2.37.4-1.8
[18:59] <zyga> I will upload 2.38 tomorrow
[18:59] <zyga> I wonder if that's something that was fixed there
[18:59] <LinAGKar> zyga: `Linux sudda.kvasta 5.0.2-1-default #1 SMP Thu Mar 14 08:29:17 UTC 2019 (d1f1d19) x86_64 x86_64 x86_64 GNU/Linux`
[18:59] <zyga> 5.0 hmm
[18:59] <zyga> maybe apparmor regression
[19:00] <zyga> LinAGKar: thank you for reporting this, would you mind opening a bug
[19:00] <zyga> LinAGKar: can be either launchpad or opensuse bugzilla
[19:00] <zyga> LinAGKar: I will fix it, if I can, for next week
[19:00] <zyga> and sorry for the trouble
[19:02] <zyga> jdstrand: ^ this is also interestign
[19:02] <zyga> *interesting even :-)
[19:03] <LinAGKar> zyga: I'll go file a bug report.
[19:03] <zyga> thank you very much
[19:08] <jdstrand> the snap-confine profile already has ptrace read peer=unconfined,
[19:09] <zyga> yeah
[19:09] <zyga> maybe some funky 5.0 behavior?
[19:09] <jdstrand> I'm on 5.0
[19:09] <zyga> but with ubuntu sauce
[19:09] <zyga> perhaps the non-upstreamed patches are relevant here
[19:09] <jdstrand> no sauce for ptrace
[19:09] <zyga> aha
[19:09] <zyga> well, that's a good data point
[19:09] <zyga> I will attempt to reproduce this as soon as I'm done with this patch
[19:10]  * jdstrand is still heads down on other things. can't look at cwd today
[19:10] <zyga> jdstrand: sure :)
[19:10] <zyga> jdstrand: we'll chat next week
[19:10] <zyga> I will finish the extra descriptions and open the PR
[19:10] <zyga> enjoy your weekend :)
[19:11] <LinAGKar> zyga: Bug report here: https://bugs.launchpad.net/snapd/+bug/1821396
[19:11] <mup> Bug #1821396: cannot read mount namespace identifier of pid 1: Permission denied, on OpenSUSE Tumbleweed with Linux 5.0 <snapd:New> <https://launchpad.net/bugs/1821396>
[19:11] <zyga> LinAGKar: assigned, thank you
[19:12] <zyga> I will check if 2.38 fixes it and upload ASAP
[19:12] <zyga> if not, I will debug further
[19:12] <LinAGKar> I guess I didn't need to put it her myself.
[19:13] <zyga> LinAGKar: snapd will soon-ish be in the opensuse repository
[19:14] <zyga> LinAGKar: I'm sure this will improve the quality aspect as it will be so much easier to just try it
[19:14] <LinAGKar> zyga: In the official repos?
[19:15] <zyga> yes
[19:15] <zyga> I suspect that 2.37.5 will be first
[19:15] <zyga> and then 2.38 and onwards, I'm not sure what the release schedule impact will be though, yet
[19:39] <zyga> regression test added
[19:49] <zyga> mvo: https://github.com/snapcore/snapd/pull/6642 patch of the day
[19:49] <mup> PR #6642: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <https://github.com/snapcore/snapd/pull/6642>
[19:49] <mup> PR snapd#6642 opened: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <https://github.com/snapcore/snapd/pull/6642>
[19:49] <mvo> zyga: nice
[19:54] <zyga> LinAGKar: I've booted my TW machine, let me update to see if I'm missing something
[19:54] <zyga> LinAGKar: on 5.0.2-1 it is still working but I often use bleeding edge local builds
[19:57] <zyga> jdstrand: I pushed the regression test for TIOCSTI
[19:57] <mup> PR snapd#6643 opened: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <https://github.com/snapcore/snapd/pull/6643>
[19:57] <zyga> okay, that's all for today for me
[19:58] <zyga> have a fantastic weekend everyone
[19:58] <zyga> LinAGKar: in case it keeps working for me, can you think of any customization you did on top of the vanilla installation?
[20:01] <LinAGKar> zyga: I've done quite a bit, hard to tell what would affect it. This machine did originally run OpenSUSE 13.2.
[20:02] <zyga> aha
[20:02] <zyga> I will investigate
[20:02] <zyga> not giving up :)
[20:02] <LinAGKar> zyga:  I've also had it suspended, no sure if that affects it.
[20:02] <zyga> but not tonight, need to sleep
[20:02] <zyga> no, it would not
[20:02] <zyga> can you be on IRC next week?
[20:03] <LinAGKar> zyga: I will.
[20:03] <zyga> thank you
[20:03] <zyga> enjoy your weekend too :) see you on Monday
[20:03] <LinAGKar> Enjoy your too
[20:03] <LinAGKar> Thank you
[20:05] <mup> PR snapcraft#2511 opened: build providers: modify the _run signature <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2511>
[21:32]  * cachio EOW
[23:23] <mup> PR snapcraft#2510 closed: Release changelog for 3.3 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2510>