[05:20] <mapps> morning
[05:25] <mapps> sweet
[05:25] <mapps> judge judy on:D
[07:31] <diplo> Morning all
[07:31] <diplo> mapps: Really.... judge judy! :/
[07:32] <MooDoo> diplo: phew, glad you said that
[07:34] <diplo> :P
[08:27] <JamesTait> Good morning all; happy Safety Pin Day!   No but he does scream like a girl
[09:43] <JamesTait> How rude!
[09:46] <MooDoo> Everyones servers patched?
[09:47] <brobostigon> yes.
[09:49] <awilkins> I get spamtxt from Domino's Pizza
[10:24] <davmor2> MooDoo: I'm still trying to run the test on mine it doesn't like starttls it appears :(
[10:34] <MooDoo> davmor2: :(
[10:42] <bashrc> I patched my server yesterday
[10:43] <foobarry> i run scientigic linux- self patching
[10:44] <bashrc> you also have to regenerate any SSL certificates
[10:47] <MooDoo> foobarry: is that any good?  I've been looking at it
[10:47] <foobarry> WFM
[10:49] <foobarry> i've run large desktop infrastructures too using it
[10:49] <foobarry> and servers of course
[10:50] <foobarry> i also like centos
[10:50] <foobarry> but i dont think centos is configged for security updates via cron OOTB
[10:53] <foobarry> i want to get the blue shell ! http://www.amazon.co.uk/gp/product/B00B8QDNW2/ref=s9_simh_gw_p63_d0_i3?pf_rd_m=A3P5ROKL5A1OLE&pf_rd_s=center-2&pf_rd_r=1J9THJXHCE26R14R2XM6&pf_rd_t=101&pf_rd_p=455344027&pf_rd_i=468294
[10:54] <foobarry> oh, not at that price
[11:35] <MooDoo> bloomin heart bleed
[12:08] <awilkins> Yeah
[12:08] <awilkins> Do we really think we need to change passwords?
[12:09] <awilkins> I have about 80 in my password manager
[12:09] <popey> i changed a few
[12:09] <popey> based on advice from the lastpass security audit tool
[12:09] <awilkins> Yeah, I might change my gmail at least
[12:09] <popey> which is fricking amazing
[12:09] <popey> i have 2fa on gmail
[12:09] <awilkins> Yeah, I suppose I should sort that out
[12:18] <MooDoo> https://www.dropbox.com/s/n96uuv10ehjspng/BLOG-HEARTBEAT.jpg :D
[12:27] <popey> hah
[12:28] <popey> i used to love that show
[12:28] <popey> uh, 20 years ago
[12:31] <MooDoo> yeah just throught it was funny as i'm dealing with a lot of heartbleed issues :D
[12:33] <MartijnVdS> MooDoo: everyone is :|
[12:35] <SuperMatt> MooDoo: lawls
[12:35] <SuperMatt> MooDoo: you have *no idea* how many heart bleed issues I'm dealing with
[12:36] <SuperMatt> let's just say that we're only a little snowed under, and you have to imagine that with immense levels of sarcasm
[12:37] <MartijnVdS> SuperMatt: now imagine dealing with (local council) government
[12:39] <SuperMatt> MartijnVdS: ouch
[12:39] <SuperMatt> the one thing I keep hearing though is "no, don't restart httpd now" and I'm just like "lol you mean that your security is less important than 10 seconds downtime? OK!"
[12:40] <MartijnVdS> SuperMatt: good thing we had DigiNotar here a few years ago, and there are procedures/protocols now
[12:44] <MooDoo> SuperMatt: yup we're soo busy
[12:48] <SuperMatt> just take the number of servers you're dealing with, then scale it up *many* times and you'll realise how busy we are!
[12:53] <MooDoo> SuperMatt: pah i've more servers that you :p
[13:06] <popey> I had zero to patch \o/
[13:06] <popey> hurrah for no ssl
[13:06] <MartijnVdS> popey: ...
[13:06] <MartijnVdS> I even had to patch my Synology NAS
[13:06] <popey> i have nothing that does https, nothing at all
[13:07] <foobarry> i'm on holiday this week
[13:07] <popey> \o/
[13:07] <foobarry> not sure if \o/ or /o\
[13:07] <popey> nice timing
[13:08] <MooDoo> MartijnVdS: oh rats forgot about my NAS
[13:08] <MartijnVdS> MooDoo: http://ukdl.synology.com/download/criticalupdate/update_pack/4458-2/ if it's a synology
[13:09] <MooDoo> no netgear, but it's old, so I'm not sure if it's even affected lol
[13:10] <foobarry> most of my servers self updated but applications might need a closer look
[13:11] <MartijnVdS> yeah, I rebooted my servers to be on the safe side
[13:12] <foobarry> its amazing how quickly 4yr olds can get good as games like mario kart
[13:12] <foobarry> :-|
[13:13] <foobarry> although he's clicked on internet play sometimes. explains a lot. sometimes i've played on the internet and thought..is this guy drunk or just 4yrs old
[13:13] <MartijnVdS> foobarry: you could too.. if you only played it as intensely and often as they do
[13:14] <foobarry> heh.. he plays prob 1hr a week on sat mornings
[13:14] <foobarry> and talks about it for 7 days in between
[13:18] <MooDoo> foobarry: my son is 5 and the same with minecraft, i've just let him use fraps so he can record his own videos lol
[13:31]  * popey coughs up http://podcast.ubuntu-uk.org/2014/04/10/s07e02-the-one-where-everybody-finds-out/
[13:32] <brobostigon> :)
[13:49]  * Laney just heard the f-bomb
[13:49] <Laney> OUTRAGEOUS
[13:49] <MooDoo> the what?
[13:50] <brobostigon> is it a gasous anal axpulsion.?
[13:50] <brobostigon> expulsion*
[13:51] <Laney> similar
[13:51] <popey> yeah ⍨
[13:52] <brobostigon> i see.
[13:52]  * brobostigon gets a match
[14:05] <andrewebdev> was listening to a linux podcast last night regarding mir, and just as it got to the point where I was too frustrated to continue listening, reason popped it's in the door in the form of popey
[14:05] <popey> haha
[14:05] <popey> Linux Unplugged?
[14:05] <andrewebdev> yeah
[14:06] <popey> thanks
[17:03] <daftykins> hrmm, probably not wise for a web server to be going 20MB into swap?
[17:56] <mapps> sweet
[17:56] <mapps> hey daftykins
[17:56] <mapps> prob not
[17:56] <mapps> :D
[17:56] <daftykins> ^_^
[17:57] <daftykins> hallo
[17:58] <mapps> :)
[18:46] <diddledan> lots of interesting announcements: https://cloud.google.com/events/google-cloud-platform-live/
[19:26] <mapps> hm
[19:26] <mapps> cloud sucks daftykins
[19:27] <daftykins> tab complete fail!
[19:51] <SuperMatt> cloud doesn't suck, it's just most people suck at using it!
[19:53] <SuperMatt> for instance, if you want to use wordpress on a bunch of load balanced servers, you're going to have a bad time
[19:58] <bigcalm> Good morning peeps :)
[19:59] <SuperMatt> it's morning already? but I don't want to go back to work yet
[19:59] <SuperMatt> there are still too many heartbleed tickets!
[19:59] <daftykins> lol
[20:00] <shauno> ugh.  I had to deal with that today, which was unexpected
[20:01] <shauno> mostly trying to find a reassuring way to say "don't worry, we're so hopelessly out of date that we weren't exposed"
[20:02] <SuperMatt> I'm still unsure about resetting passwords and renewing certs
[20:02] <SuperMatt> I figure that if attacks against heartbleed were going to affect me, I would have been got by now
[20:04] <shauno> honestly, I think for most people it's largely hypothetical
[20:05] <shauno> the more realistic worry (imho) is that people like yahoo were exposed.  targets big enough for someone to go fishing if they had some shiney new sploit before it was public
[20:05] <SuperMatt> indeed
[20:06] <shauno> I mean, it's nice that there's a dance to go through if you want the peace of mind.  but I'd be more worried about my accounts on others' systems, than my own
[20:07] <shauno> one thing that did raise an eyebrow though, is people scanning 443 on their own ranges to see what needs to be updated
[20:08] <diddledan> shauno: "we're aware of the issue and at this point we believe our systems are no-longer vulnerable"
[20:08] <diddledan> where no-longer == hadn't been in the first place
[20:08] <shauno> rather than just "update all the things", they're assuming https is the only place they're using ssl
[20:08] <diddledan> at least ssh isn't an issue :-)
[20:09] <diddledan> but smtps and pop3s and imaps are probably vulnerable
[20:09] <diddledan> I donno what microsoft-world uses for ssl?
[20:10] <diddledan> some in-house thing I guess
[20:10] <diddledan> microsoft closed sauce
[20:11] <SuperMatt> the command I've used most today: lsof -n | grep ssl | DEL
[20:11] <SuperMatt> to see if any services had a preloaded version of openssl still in memory
[20:11] <diddledan> | DEL?
[20:11] <daftykins> what's the third portion?
[20:11] <SuperMatt> oops, grep DEL
[20:11] <shauno> I wouldn't be surprised to find openssl on windows.  it's bsd licensed, so it'll crop up everywhere
[20:12] <diddledan> I used sudo grep libcrypto /proc/*/maps | grep '(deleted)' | cut -d/ -f3 | uniq | xargs ps
[20:12] <diddledan> that way it tells me what processes I need to restart
[20:12] <SuperMatt> mine's a little quicker :P
[20:12] <SuperMatt> but it does the same
[20:13] <shauno> I think mine's been "paste" :(  so much email.  so so much.
[20:15] <daftykins> lol
[20:16] <shauno> (my first day back since the start of the month, so ..)
[20:22] <daftykins> shauno: you part timer!
[20:22] <shauno> I try :D
[20:22] <shauno> I even booked "bring your child to work day" off as vacation
[20:28] <bigcalm> Potato batteries!
[20:28] <diddledan> shauno: but you don't have a child
[20:29] <bigcalm> Perfect reason not to be in work that day
[20:29] <bigcalm> Children do not make for a productive work environment
[20:29] <shauno> it's for their benefit, really.  they don't need a humbug :)
[20:30] <daftykins> lol
[20:31] <daftykins> bag of humbugs!
[20:31] <daftykins> that'd pacify them
[20:32] <diddledan> shauno: but the lolz
[20:32] <diddledan> shauno: of being humbuggery
[20:33] <diddledan> I know being a grouch can take a lot of effort, but it's surely worth it when you ruin everyone's day, no?
[20:53] <diddledan> http://blog.fastmail.fm/2014/04/10/when-two-factor-authentication-is-not-enough/
[20:56] <denny> Heyla. I seem to have lost the ability to listen to 'net radio stations. I'm inclined to blame my new ISP, but just before I call them up and shout at them, what else should I check?  Rhythmbox on 12.04, happy to install something else to see if that works, less happy to upgrade distro version right this second.  Tried running Rhythmbox from command-line, didn't get any useful errors (just the usual Gtk mess).
[21:00] <daftykins> denny: what are you testing?
[21:03] <denny> actually, it just occurred to me to try from the laptop.  That works.  So um... Rhythmbox on my 12.04 desktop doesn't work (but did a week ago when I last used it), Rhythmbox on my 13.10 laptop on the same network does work.  You tell me what I should test.  :)
[21:03] <denny> Trying to play http://radio.bassjunkees.com:8442/listen.pls (as an example, although no 'net radio station works.   I have some Ubuntu 12.04 boot error. Please help.
[23:35] <daftykins> it's quite late here. you'd be better off with asking in #ubuntu
[23:35] <Alue> ???
[23:35] <daftykins> ask in #ubuntu
[23:36] <Alue> well thanks.
[23:59] <diddledan> denny: I've just tried that radio station on a 12.04.4 freshly installed - it worked fine for me
[23:59] <diddledan> that's 64bittyness
[23:59] <diddledan> I can try on a 32bit install if you like


[01:39] <beantaxi> Hola all. Revisiting a question of mine from ealier today ...
[01:39] <beantaxi> I have a VPS on OVHCloud. They use cloud-init. Data Source = OpenStack. I see no obvious onramps like AWS/EC2 provides to make cloud-init initialize an instance with my scripts. How does one do this? Thanks!
[07:00] <beantaxi> From the code, the systemd services, and cloud-init --help, it looks like scripts are run during the final stage, which can be manually invoked by cloud-init modules --mode final. But, despite spending some time (re)visiting main.py, stages.py, cc_script_user.py, etc, I can't quite figure out how cloud-init 'knows' it's already run a per-instance script so it knows not to run it again. Thanks!
[07:38] <meena> beantaxi:
[07:39] <meena> that knowledge is stored in /var/lib/cloud-init
[07:39] <meena> cloud-init and can be mademade to forget
[16:08] <beantaxi> meena: Thanks you ... I'm not seeing /var/lib/cloud-init.
[16:09] <beantaxi> ('thanks you' ... good heavens)
[16:20] <beantaxi> I do see a /var/lib/cloud/sem/ which looks like it might be relevant
[16:35] <beantaxi> From a look at some of the code in helpers.py, around Runners and FileSemaphores and such, it looks as though it's checking for files in that folder and bailing if they already exist.
[16:43] <beantaxi> And my /v/l/c/sem folder has one file named config_scripts_per_once.once. So I guess I _cloud_ just copy script files to /v/l/c/s/per-* folders, but that seems a little hacky, and that I'd be better off creating a proper cloud config file or gzip and coercing cloud-init to work with that file
[16:44] <beantaxi> How might I do that?
[16:51] <meena> beantaxi, yes, i got the folder wrong, but in there there's all the info cloud-init needs to decide whether it needs to run or not
[20:23] <beantaxi> meena: Thanks! I was offline for a few hours, so I may have missed some messages. But now that I have some more clues, I'm going to reread the docs and see what clicks.
[21:00] <beantaxi> K. So it looks like I can create my userdata file with make-mime as per usual ... copy it to /var/lib/cloud/instance ... then follow a few cloud init steps from the FAQ ... and then reboot, and my initialization script should get executed.
[21:00] <beantaxi> One question: how exactly does cloud-init know its been run per-instance? The /v/l/c/sem folder has a per.once file but that's it. Thanks!
[21:09] <meena> we had that recently documented
[21:09] <meena> let me see if i can find it
[21:15] <meena> https://cloudinit.readthedocs.io/en/latest/topics/faq.html that's a good start
[21:17] <meena> https://cloudinit.readthedocs.io/en/latest/topics/boot.html#first-boot-determination
[21:23] <beantaxi> Thanks ... I read that and the First Boot Determination as well. They were both very helpful, but neither had detail on what file is used to indicate the instance has already booted. But perhaps that is the point of the /var/lib/cloud/instance/sem folder, as opposed to the /var/lib/cloud/sem folder? (I just now found the instance level sem folder)
[21:47] <meena> they should just be links to each other
[21:49] <meena> see, in theory, something in your virtual machine could change, and then your cloud decides this is a new instance and it needs a new instance id and it needs a new run, one that's essentially like the first run
[22:58] <beantaxi> I see two separate folders, /var/lib/cloud/sem and /var/lib/cloud/instance/sem. /v/l/c/sem has just one file: config_scripts_per_once.once. /v/l/c/instance/sem has many files, all of the form config_XXX, all of which seem to correspond to stages listed in /etc/cloud/cloud.cfg though I did not check every single one.
[23:00] <beantaxi> And /v/l/c/instance is indeed symlinked to /v/l/c/instance-very-long-guid, which I read is there in case this happens to a volume or filesystem that began life on one instance but the got started up when attached to a different instance, and so cloud-init can determine if it needs to run again; and there's a flag that controls this behavior in cases where that behavior is not what you want.


[02:14] <Bashing-om> guiverc: Huh ? https://discourse.ubuntu.com/t/vanillafied-uwn/40838 :D
[02:18] <guiverc> yeah I saw it thanks Bashing-om ,  a copy (or url) of it would be useful to see what needs to be altered script wise.. some of our 'unusual' formatting was to make it easier for scripts
[02:20]  * guiverc just back from re-walking my morning walk; dropped keys first time so was looking for them.. found them (yeah) but didn't find any roos (boo; this morning a wildlife officer was looking for roo; park is too small for roos so they get rehoused to larger park)
[02:21] <Bashing-om> guiverc: While I am all for an enhanced public appearance - I do not see this as such - seeing a full copy might improve my sight.
[02:23] <Bashing-om> guiverc: Walking about - never can tell what might perchance - adventures await :D
[02:25] <guiverc> I'm not fussed how it looks; just that i can semi-understand format & work with it... kryten does all scripting for us so changes need to go thru him possibly; but first is just a simple copy/paste now (no URLs) so lack if its script no real issue..    you do most of the others
[02:28] <Bashing-om> guiverc: Uh Huh untill we play with the code - will not get fussed.
[02:29] <guiverc> sorry i didn't read what I typed; "but first" should have been "but fridge"...
[02:29]  * guiverc going to get a drink.... de-hyrdated after walking in sun...
[02:31] <Bashing-om> guiverc: Presently have all on my plate I care to deal with - not looking to add more.
[03:28]  * guiverc notes mostly for self-use https://ubuntu.com/blog/vanilla-4-0-release  (4.5.1 appears current)   (historical https://ubuntu.com/blog/design-and-web-team-summary-8-february-2021 )
[03:31] <Bashing-om> reading
[03:32] <guiverc> most dropped here as place marker or reminder to self.. i'm trying to 'learn' about it .. no idea if useful yet
[03:32] <guiverc> the first looks easy; however using the discourse API I have no idea yet
[03:51] <Bashing-om> guiverc: My 1st look > compile >> I do not have the disk space on my daily driver to mess about. >>> Pass :(
[04:13] -ubottu:#ubuntu-news- ::planet:: Ubuntu Blog: Canonical joins the Sylva project @ https://ubuntu.com//blog/canonical-joins-the-sylva-project
[04:13] -ubottu:#ubuntu-news- ::planet:: Ubuntu Blog: How to use Ubuntu in GKE on nodes and in containers @ https://ubuntu.com//blog/how-to-use-ubuntu-in-gke-on-nodes-and-in-containers
[11:27] -ubottu:#ubuntu-news- ::ubuntuonair:: Container Craftsmanship: from a Pebble to a ROCK @ https://www.youtube.com/watch?v=BDXZxp3aFBY
[11:27] -ubottu:#ubuntu-news- ::ubuntuonair:: Move Data Science Beyond Experimentation with MLOps Platforms @ https://www.youtube.com/watch?v=TBPIIHH8wsQ
[11:27] -ubottu:#ubuntu-news- ::ubuntuonair:: Local Communities and their Role in Opensource Communities @ https://www.youtube.com/watch?v=uNXPUMzNGj0
[17:43] -ubottu:#ubuntu-news- ::omg!ubuntu:: Double-Clicking Pages & Numbers Docs in Ubuntu Now iWorks @ https://www.omgubuntu.co.uk/2023/12/open-apple-pages-documents-ubuntu-fixed


[15:08]  * cwillu_at_work has successfully booted a btrfs root on a beagleboard with rootstock
[15:09] <cwillu_at_work> I'm tempted to suggest it has a default rootfs, as it doesn't have the issues that ext3/4 has on sd cards re: journalling, nor the issues that ext2 has with the lack of journalling/consistency
[15:12] <Martyn> I've managed to put together a ubi/ubifs as well... but that means you need direct access to the MTD to do UBI
[15:12] <Martyn> Any issues on getting a btrfs root working that you found?
[15:13] <cwillu_at_work> not really
[15:13] <cwillu_at_work> uou need a kernel with the appropriate modules compiled in, or available in an initramfs, although rcn's kernel packages have it enabled for a month or so now
[15:14] <cwillu_at_work> the ssd optimizations are supposed to be automically enabled if it detects non-rotating media, although I just err on the side of caution and put "btrfs.ssd" on the kernel boot line
[15:14] <cwillu_at_work> I've been using it on a server for a while now, and also just started using it on my laptop, mainly to flush out these sorts of issues
[15:15] <cwillu_at_work> update-grub doesn't get along with it very well, but that's not really an issue with arm
[15:16] <cwillu_at_work> an amusing trick would be to hotswap rootfs devices:  boot off the sd card, plug in a usb reader with another card, add the new card to the btrfs root, and then remove the original card :)
[15:17] <cwillu_at_work> for those uptime critical embedded installations where the sd is starting to give write errors, but you can't afford to reboot \o/


[01:43] <mup> PR snapcraft#1915 closed: snap: patch ctypes for the snap <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1915>
[02:17] <thomi> niemeyer: Oh! I didn't realise I had edit rights to that post myself, or I would have just edited it directly, sorry :D
[02:18] <niemeyer> thomi: All good! I was still tuning it nevertheless, but yeah, if you want to tweak in the future feel free
[02:19] <niemeyer> and the magic happens ... https://snapdocs.labix.org/getting-started/3876
[02:19] <thomi> nice
[03:20] <mup> PR snapcraft#1912 closed: lxd: unset SNAP to work-around LXD deb thinking it's a snap <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1912>
[03:47] <niemeyer> Forum going down for maintenance.. assume impact position please.
[03:51] <niemeyer> Forum is back up
[06:11] <mborzecki> morning
[06:32] <zyga> good morning
[06:34] <mborzecki> zyga: mvo_: hey
[06:36] <mvo_> hey mborzecki - good morning
[06:52] <zyga> hey guys
[06:58] <mvo_> hey zyga
[06:59] <zyga> hey :-)
[07:00] <mup> PR snapd#4611 closed: overlord/configstate/config: make [GS]etSnapConfig use *RawMessage <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4611>
[07:03]  * zyga iterates on the feedback from jamie
[07:03] <zyga> jdstrand thank you :)
[07:03] <zyga> oh, I have a conflict to resolve first
[07:38] <mup> PR snapd#4604 closed: cmd/snap-confine: create lib/{gl,gl32,vulkan} under /var/lib/snapd and chown as root:root <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4604>
[08:01] <mup> PR snapd#4612 opened: snap: exclude `gettimeofday` from `snap run --strace` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4612>
[08:01] <kalikiana> sliff
[08:13] <pstolowski> good morning!
[08:16] <zyga> hey pawel
[08:17] <mvo_> hey pstolowski !
[08:18] <zyga> mvo_ 4590 is now ready, I pushed some WIP patches by accident but they are gone now
[08:19] <zyga> I'll add a spread test before jumping into sun profiles more
[08:19] <mvo_> zyga: ta
[08:20] <kalikiana> o/ pstolowski
[08:21]  * kalikiana coffee
[08:21] <zyga> jamesh hey
[08:21] <jamesh> zyga: hi
[08:21] <zyga> I wanted to catch up with you
[08:21] <mborzecki> pstolowski: morning
[08:22] <zyga> how is that branch, I saw jamie gave you a review, are you just waiting on a re-review from him?
[08:22] <zyga> I also wanted to give you an update on some of the work I'm doing that intersects (though I don't anticipate any problems)
[08:23] <zyga> we will soon have per-snap profiles for snap-update-ns
[08:23] <ackk> mvo_, hi, was the updated base-18 with distro-data built?
[08:23] <zyga> (apparmor profiles that is)
[08:23] <jamesh> zyga: I still need to get the mountinfo stuff working: I had other things on my plate on Friday, and was flying home on Monday
[08:23] <mvo_> ackk: it was, iirc it was sitting in the review queue, we need to poke jdstrand about accepting the updated base-18 snap
[08:24] <ackk> mvo_, oh, I see
[08:24] <zyga> jamesh did my suggestion help you in any way?
[08:26] <jamesh> zyga: I still need to think it over a bit more.  I wasn't even looking at the device numbers before.
[08:26] <zyga> okay
[08:27] <zyga> my changes for per snap s-u-n profiles will touch snap-confine a little and mostly the backend code
[08:27] <zyga> there will be some new logic before running s-u-n from C
[08:29] <zyga> the idea behind sun profiles is that they can be tailored to the given snap and describe the operations we anticipate to perform
[08:29] <zyga> so that s-u-n doesn't have to carry very broad write and mount permissions
[08:30] <zyga> jamesh when do you think your branch will be ready for re-review?
[08:30] <jamesh> zyga: well, I need to be able to add the check jdstrand requested, which so far I haven't been able to implement
[08:31] <zyga> jamesh ok, I'll look at that part, maybe I can help somehow
[08:32] <zyga> jamesh do you mind if I push there directly?
[08:40] <zyga> woot, 4590 is ready for 2nd review
[08:40] <zyga> ~100 diff
[08:41] <zyga> (and most of that is in apparmor which was acked by jamie)
[08:41] <zyga> anyone? :)
[08:55] <zyga> hey Chipaca
[08:55] <Chipaca> moin moin
[09:01] <zyga> Chipaca maybe I can grab you for a 2nd review of about 100 lines
[09:01] <zyga> https://github.com/snapcore/snapd/pull/4590
[09:01] <mup> PR #4590: many: allow constructing layouts (phase 1) <Created by zyga> <https://github.com/snapcore/snapd/pull/4590>
[09:05] <mup> PR snapd#4613 opened: release: snapd 2.31 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4613>
[09:18] <Chipaca> zyga: missed your message before, looking now
[09:20] <zyga> thank you
[09:23] <Chipaca> fmt's widths and precision are pretty messed up
[09:23] <mup> PR snapd#4614 opened: data/systemd: for debugging/testing use /etc/environment also for snap-repair runs <Created by pedronis> <https://github.com/snapcore/snapd/pull/4614>
[09:23] <pedronis> mvo_:   ^ trivial fix/tweak to snap-repair  service unit
[09:24] <mvo_> pedronis: looking
[09:25] <mvo_> pedronis: ta
[09:26] <zyga> have we tested repairs for real yet?
[09:29] <pedronis> zyga: no, they have been tested in staging,  it's been 2nd highest prioritity thing for a while though,  next weeks might be the charm though
[09:29] <zyga> cool, it's a very important thing to see work as it can save our skin one day
[09:31] <pedronis> zyga: anyway that PR is the result of me trying to reload state about them
[09:33] <pedronis> zyga: it's also been delayed by meltdown/spectre, as many other things
[09:33] <zyga> yeah, timing is not on our side
[09:49] <ikey> do you guys regret picking go yet? :)
[09:49] <pedronis> ikey: instead of?
[09:49] <ikey> i mean in general
[09:50] <ikey> seems to me the lower down you go with go the more ugly warts are there waiting to be found
[09:52] <mup> PR snapd#4614 closed: data/systemd: for debugging/testing use /etc/environment also for snap-repair runs <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4614>
[09:52] <mup> PR snapd#4615 opened: overlord/snapstate/backend: perform cleanup if snap setup fails <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4615>
[09:52] <mborzecki> ikey: how far down?
[09:53] <ikey> mborzecki, process level attributes and sandboxing
[09:53] <ikey> namespaces, etc
[09:54] <ikey> (also process vs thread)
[09:54] <ikey> sorta stuff we ran into with solbuild in solus, kinda assumed similar brick walls would be hit and worked around with snapd
[09:54] <mborzecki> right, that doesn't work so well (at all) in go
[09:55] <ikey> then again i suppose the flipside is not dealing with berkley sockets :]
[09:55] <pedronis> it mostly affects snap-confine though (wich now is split between C and go helpers)
[09:55] <ikey> ah so thats why its split, makes sense
[09:55] <ikey> so the design is more like "bootstrap environment and then exec" in a sense?
[09:55] <zyga> yes
[09:55] <zyga> and actually, we managed to move a lot of it to go now
[09:55] <ikey> neat way of doing it :]
[09:56] <zyga> snap-update-ns and snap-confine do stuff together
[09:56] <zyga> and we can move much more to go
[09:56] <ikey> oh nice
[09:56] <pedronis> otherwise we mostly hit issues with go threads and exec
[09:56] <zyga> there are just a handful of things that cannot be done from go
[09:56] <ikey> yeah go threads are.. special
[09:56] <zyga> (where C pre-go code doesn't count as "go" ;-)
[09:56] <mborzecki> there are workaround those
[09:56] <mborzecki> i mean, iirc libcontainer is all go right?
[09:56] <ikey> huh spose yea
[09:57] <mborzecki> probably quite a lot of (un-)lockosthread and maxprocs fun
[09:57] <ikey> yea
[09:57] <mborzecki> not that i would like to do it though :)
[09:57] <ikey> but ofc. :D
[09:57] <ikey> i think the most evil go issue i had wasn't actually go's fault, cgo/xz
[09:57] <pedronis> the other issue is that go moves faster than some distros (this one we haven't tackled but probably should somehow)
[09:58] <ikey> i suspected i had a memory leak but my peanut gallery training told me that nope, that memory will get returned, its just virtual memory
[09:58] <mborzecki> oh and we haven't done anything with go assembly, which is quite nice actually :)
[09:58] <ikey> that was until it OOM'd with 30GB used
[09:58] <ikey> hadn't heard about go assembly, gonna have to google it
[09:59] <mborzecki> ikey: try this https://talks.golang.org/2016/asm.slide
[09:59] <zyga> mborzecki note that even with those some things just cannot be done in go (several syscalls require you to have ever only had one thread in a process)
[09:59] <ikey> mborzecki, danke
[10:00] <mborzecki> zyga: hm i wonder if that couldn't be doen with GOMAXPROCS=1 and LockOsThread in init()
[10:00] <ikey> o cheeky
[10:00] <zyga> no
[10:00] <zyga> we tried
[10:00] <zyga> go does stuff in library initialization
[10:00] <ikey> go needs a -pleasebelikec flag lol
[10:00] <zyga> and it's too late then
[10:00] <zyga> hence the magic in snap-update-ns
[10:00] <zyga> and the split in general
[10:01] <ikey> so i assume you just wanna do the bare minimum in C land
[10:01] <ikey> i.e. what cant be done in go
[10:01] <ikey> er what cant be done /safely/sanely/ *
[10:03] <mborzecki> if not c then probably d or rust could be used as alternatives
[10:03] <zyga> I think we'll stick to C
[10:03] <mborzecki> provided you can actually build those on older systems
[10:03] <zyga> no need to introduce a new language for a tiny fragment
[10:04] <zyga> we really need C for pivot_root and some of the early namespace manipulation
[10:29] <mup> PR snapd#4590 closed: many: allow constructing layouts (phase 1) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4590>
[10:31] <mup> PR snapd#4616 opened: interfaces/apparmor: remove leaked future layout code <Created by zyga> <https://github.com/snapcore/snapd/pull/4616>
[10:51] <mvo_> Chipaca: bad news, powerpc is failing since some days and it looks the change is the addition of the osutil/context.go stuff
[10:51] <Chipaca> mvo_: can i see?
[10:51] <zyga> mvo_ is that going to block the release?
[10:51] <zyga> and do you need my powerpc box?
[10:52] <mvo_> Chipaca: https://launchpadlibrarian.net/355941418/buildlog_ubuntu-xenial-powerpc.snapd_2.31~rc2+git540.4a4ed58~ubuntu16.04.1_BUILDING.txt.gz
[10:52] <mvo_> zyga: its just master afaict
[10:52] <Chipaca> so much "reading database"
[10:52] <mvo_> Chipaca: silly dpkg
[10:52] <mvo_> Chipaca: we are getting rid of this ;)
[10:52] <Chipaca> i thought that was apt
[10:53] <mvo_> Chipaca: that part is dpkg
[10:53] <mvo_> Chipaca: or, hold on
[10:53] <mvo_> Chipaca: yeah, thats dpkg
[10:54] <Chipaca> zyga: mind if i use your powerpc box?
[10:55] <zyga> not at all
[10:55] <zyga> please coordinate with mvo, there's just 1GB ram
[10:55] <mvo_> Chipaca: the backtrace is not helpful at all
[10:55] <Chipaca> mvo_: are you going to use zyga's powerpc?
[10:56] <mvo_> Chipaca: yeah, I was about to. but if you are on it, I will leave it, its almost lunchtime anyway
[10:56] <Chipaca> mvo_: yeah if it's my context thing it's fair that i bash my head on it
[10:56] <mvo_> Chipaca: it probably is (this is the merge when the builds start to fail). thanks for looking into it!
[10:57]  * Chipaca sees a 'if runtime.GOARCH == "powerpc" { throw a fit }' in his future
[10:59] <Chipaca> zyga: do i have sudo on the ppc box?
[11:00] <zyga> checking
[11:01] <zyga> yes
[11:01] <zyga> you should
[11:01] <Chipaca> zyga: what i might not have is a password :-)
[11:01] <zyga> aha :D
[11:02] <mborzecki> your voice is ..
[11:02] <Chipaca> .. not what it was
[11:02] <mborzecki> ha ha :)
[11:07] <Chipaca> ok, I've seen this error once before and thought it was weird gamma ray thing :-) but this being the second time, I need to bring it up
[11:07] <Chipaca> + mkdir -p /home/test/snap/test-snapd-tools/6/
[11:07] <Chipaca> + touch '/home/*/snap/test-snapd-tools/6/mock-data'
[11:07] <Chipaca> touch: cannot touch '/home/*/snap/test-snapd-tools/6/mock-data': No such file or directory
[11:07] <Chipaca> what the *what*
[11:08] <ikey> did you quote the wildcard?
[11:08]  * Chipaca looks at the test
[11:08] <Chipaca> ikey: that's a good question :-)
[11:08] <Chipaca> thank you
[11:08] <ikey> np
[11:08] <Chipaca> ikey: although if it was that, it wouldn't fail just sometimes
[11:09] <Chipaca> still, looking
[11:09] <Chipaca> ikey: the script actually has
[11:10] <Chipaca>     mkdir -p /home/*/snap/test-snapd-tools/$rev/
[11:10] <Chipaca>     touch /home/*/snap/test-snapd-tools/$rev/mock-data
[11:10] <ikey> o
[11:10] <Chipaca> it expands the first one, but fails to expand the second one
[11:11] <ikey> but what.
[11:11]  * ikey scratches head
[11:11] <zyga> Chipaca concurrent magic?
[11:11] <Chipaca> in spread?
[11:11] <zyga> suggestion: get rid of the * and use a one-time expansion to know what the thing is called
[11:12] <Chipaca> zyga: in the log above, it logs it expanded
[11:12] <zyga> hmm hmm
[11:12] <pedronis> Chipaca: you have  '' there
[11:12] <pedronis> so no * expansion
[11:12] <pedronis> afaict
[11:12] <ikey> looks like the set +x escape put the ' in
[11:13] <pedronis> Chipaca: it might also be, the file doesn't exist, so it doesn't expand
[11:13] <pedronis> there's no match for that
[11:14] <Chipaca> hmmmm
[11:14] <pedronis> but then why it works for the dir
[11:14] <Chipaca> gasp
[11:15] <Chipaca> bah
[11:15] <Chipaca> I'm going to push a PR that changes the test, dunno why we're using a * but it's hard to think about
[11:15] <Chipaca> meanwhile restarting this individual run should be good enough for now
[11:15] <Chipaca> thanks
[11:24] <pstolowski> pedronis, hey, struggling a bit with autoconnect test based on content interface, policy check prevents autoconnect, what to do in my mocked snaps to make it happy?
[11:24] <pedronis> pstolowski: where are you writing the test?
[11:24] <pstolowski> pedronis, in overlord/managers_test.go
[11:26] <pedronis> pstolowski: you need to setup snap declarations from the same publisher, we should have some tests like that there
[11:30] <pstolowski> pedronis, thanks, looking
[11:31] <pedronis> pstolowski: it's mostly tedious and long
[11:31] <pedronis> there are some helpers though
[11:31] <pedronis> I think
[11:34] <cachio_> mvo_, hey, unit tests failing in the PR which is removing gettimeofday
[11:35] <zyga> - Download snap "test-snapd-control-consumer" (2) from channel "stable" (Get https://api.snapcraft.io/api/v1/snaps/download/a8xXlpZKNsesIzT1wxZ4kP0DaCzeDUtj_2.snap: dial tcp <IP_ADDRESS>:443: i/o timeout)
[11:36]  * zyga restarts
[11:39] <Chipaca> mvo_: there are many changes in debian/ between what I get via apt, and git
[11:39] <Chipaca> mvo_: to the point where dpkg-buildpackage from master doesn't work
[11:41] <mvo_> Chipaca: what version do you get via apt?
[11:41] <mvo_> Chipaca: try "apt build-dep ./" if build-deps are missing
[11:41] <Chipaca> mvo_: snapd-<IP_ADDRESS>
[11:41] <mvo_> Chipaca: or are vendor/ dirs missing?
[11:41] <Chipaca> mvo_: I did, nothing new brought in
[11:41] <mvo_> Chipaca: what is the failure?
[11:41] <Chipaca> mvo_: oh i thought dpkg-buildpackage does that?
[11:41]  * Chipaca does that
[11:43] <Chipaca> govendor does _not_ like ppc
[11:43] <Chipaca> powerpc*
[11:43] <Chipaca> I can't even install govendor :-(
[11:44]  * Chipaca copies his vendor tree from a reasonable architecture
[11:45] <pstolowski> pedronis, ok, i see store signing stack is already created in managers_test; it will work if I install snaps via InstallPath and with devmode provide correct SideInfo?
[11:47]  * zyga found a CD with the doors in one of the boxes yesterday
[11:47]  * zyga never listened to that
[11:49] <Chipaca> zyga: the doors! (beep tweedle bip bip)*
[11:49] <zyga> it sounds nice
[11:50] <Chipaca> zyga: talk to me when your beep-tweedle-bip-bip counter reaches 10k
[11:51] <Chipaca> mvo_: it was the vendor tree missing that was thwarting me, silly me, and thank you
[11:55] <mvo_> Chipaca: happy that it works now
[11:56] <mup> PR snapd#4617 opened: many: implement "refresh-mode: survive" for services <Created by mvo5> <https://github.com/snapcore/snapd/pull/4617>
[11:59] <Chipaca> mvo_: hmm. I think you dropped these from around a word there: ❝❞
[12:00] <Chipaca> but hey the package is building :) so that's something
[12:01] <zyga> hmm hmm lunch time
[12:03] <mup> PR snapcraft#1916 opened: lxd: initialize remote lazily <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1916>
[12:05] <Chipaca> hmm, gccgo doesn't seem to find things from vendor/
[12:05] <ackk> hi, I have a snapcraft question: I'm including a python lib from a deb via stage-packages, but the resulting library in the snap seems laid out differently. does snapcraft do anything special?
[12:09] <ackk>  kalikiana, ^ perhaps you can help?
[12:11] <pedronis> pstolowski: yes, it should work with SideInfo
[12:14] <pstolowski> pedronis, thanks, got it working!
[12:19] <mborzecki> pstolowski: should i restart the travis job in 4584 or will you be pushing more patches to that branch?
[12:20] <ikey> sadface. looks like snap mounts are regressing my boot
[12:20] <ikey> blocks early boot: https://ibin.co/3qlqeUao9o5w.png
[12:20] <pstolowski> mborzecki, yeah, pls restart, thanks, no more commits
[12:23] <kalikiana> ackk: can you be more specifc? in what sense are the files laid out differently?
[12:23] <mborzecki> anyone feels like looking at #4615?
[12:23] <mup> PR #4615: overlord/snapstate/backend: perform cleanup if snap setup fails <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4615>
[12:23] <ackk> kalikiana, I think I found the issue, locally I have a deb which is more recent than the one in the repo, but snapcraft pulls deb from the archive directly, so it's using a different version fro the one installed locally
[12:24] <ackk> kalikiana, if I copy my updated deb in .cache/snapcraft/...... will it pick the latest?
[12:24] <ackk> kalikiana, or does it only use what's in the archive
[12:24] <zyga> ikey idea: use auto mounts
[12:24] <ikey> ?
[12:25] <zyga> ikey they will start only when accessed
[12:25] <ikey> these are the mount units written by snapd
[12:25] <ikey> not me
[12:25] <zyga> 3 min
[12:25] <zyga> yes
[12:25]  * ikey blinks
[12:25] <zyga> it would be a patch
[12:25] <ikey> oh you mean patch it to mungle it
[12:25] <ikey> hm
[12:25] <ikey> could do yeah
[12:25] <zyga> *chew chew*
[12:25] <zyga> sorry, I stuffed a sandwitch into my mouth to type
[12:25] <zyga> so
[12:26] <zyga> systemd can do that mount lazily by installing an automount unit
[12:26] <zyga> I believe it's a tiny one word patch in each .mount unit
[12:26] <zyga> do an experiment
[12:26] <zyga> let me tell you ...
[12:27] <zyga> add x.systemd-automount to mount options
[12:27] <zyga> just edit those mount units and change that
[12:27] <zyga> and reboot
[12:28] <zyga> aww, systemd needs foo.automount as unit name
[12:28] <zyga> but maybe the option will be sufficient
[12:28] <zyga> (option in a mount unit)
[12:28] <zyga> ah wait
[12:28] <zyga> no
[12:28] <zyga> so reading systemd.automount
[12:28] <zyga> keep the mount units
[12:29] <ikey> right
[12:29] <zyga> just add a .automount unit next to vanilla mount units
[12:29] <zyga> so if you do that experiment and it works we can consider that as a feature to add
[12:29] <zyga> it would be nice as it would help boot time and also improve memory use
[12:29] <ikey> yeah
[12:29] <ikey> not having every possible snap mounted unless it needs to be
[12:29] <zyga> yep
[12:30] <zyga> I believe we could also do automatic deactivation so they would go away over time, when unused
[12:30] <zyga> maybe there are dragons (because it's tricky what we do) but worth a check
[12:30] <ikey> aye
[12:33] <mborzecki> zyga: TimeoutIdleSec= ?
[12:33] <zyga> yeah
[12:33] <mborzecki> right, doesn't look like too much work
[12:35] <kalikiana> ackk: Hmmm why do you have a different version? Do you want to use the local version? You could specify the .deb file in that case
[12:35] <ackk> kalikiana, yes I wanted to user the newer version I have installed. So, I can specify the path to a deb file instead of just the name in stage-packages?
[12:37] <kalikiana> ackk: You can use a part with plugin: dump and source: foobar.deb
[12:40] <kalikiana> ackk: The files will be extracted relative to the part ie. ./usr/bin/foobar
[12:41] <ackk> kalikiana, does this work for libs too?
[12:42] <kalikiana> ackk: Sure
[12:42] <ackk> kalikiana, thanks, TIL
[12:43] <Chipaca> ikey: zyga: in my experience automount is a pain in the pudenda
[12:43] <Chipaca> ikey: zyga: maybe you can get the same effect by giving snap .mounts a reasonable After=?
[12:44] <ikey> possible
[12:44] <Chipaca> mvo_: so, I have a super easy way for tests to pass on powerpc
[12:44] <Chipaca> mvo_: (beyond "skip this test" :-)
[12:45] <Chipaca> but … hmm
[12:45] <zyga> Chipaca after=5 minutes ;-)
[12:46] <Chipaca> mvo_: i suspect gccgo has not been well tested [in general but especially] on uniprocessors
[12:47] <mup> PR snapd#4616 closed: interfaces/apparmor: remove leaked future layout code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4616>
[12:50] <mup> PR snapd#4618 opened: tests: new snaps to test installs nightly <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4618>
[12:54] <zyga> mvo_ trivial feedback on https://github.com/snapcore/snapd/pull/4617
[12:54] <mup> PR #4617: many: implement "refresh-mode: survive" for services <Created by mvo5> <https://github.com/snapcore/snapd/pull/4617>
[12:55] <mup> PR snapd#4576 closed: cmd/snap-update-ns: large refactor / update of unit tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4576>
[12:59] <mvo_> zyga: ta
[12:59] <zyga> for wht?
[12:59] <zyga> :)
[12:59] <zyga> oh, meeting
[12:59] <mvo_> Chipaca: I look forward to the fix
[12:59] <Chipaca> mvo_: ah, oh, hm
[12:59] <mvo_> zyga: the feedback in my PR
[12:59] <Chipaca> mvo_: the fix is "run go test with GOMAXPROCS=<something bigger than 1>"
[13:00] <mvo_> heh
[13:00] <Chipaca> mvo_: which I suspect means actual gccgo programs don't work well on uniprocessors
[13:00] <zyga> Chipaca: buy bigger machine
[13:00] <Chipaca> mvo_: I need to test this obvs
[13:00] <mvo_> ok
[13:48]  * kalikiana lunch
[13:48] <Chipaca> zyga: "on any supported Fedora system you be good to," -> "on any supported Fedora system you should be good to go,"
[13:48] <Chipaca> zyga: imho
[13:48] <zyga> ah
[13:48] <zyga> should
[13:48] <zyga> I should add should
[13:50] <zyga> Thanks for spotting
[13:55] <zyga> I could use some coffee
[13:56]  * genii slides zyga a large shiny Ubuntu mug full of strongly brewed Somalian Arabica, at just the right temperature for sipping
[13:56] <zyga> man
[13:56] <zyga> I wish there was "snap install coffee"
[13:56] <genii> :D
[13:57] <zyga> coffee sounds like a nice name for software
[13:57] <zyga> what would it do though?
[13:57] <zyga>  grind?
[13:58] <genii> Keep you awake, ideally
[13:59] <Chipaca> zyga: you are a step away from reinventing java
[13:59] <zyga> oooh
[13:59] <Chipaca> zyga: are you sure you want to continue [n/N/WTFNO]
[13:59] <zyga> it could do coffee in containers known as *capsules*
[13:59]  * zyga stands up and walks to the coffee machine
[14:01]  * pstolowski lunch
[14:11] <jdstrand> mvo_: re base-18> as of last night, it wasn't in the review queue. I didn't see it all last week. I feel like I *did* see it at some point and accepted it. yes, r5 was accepted. r6 has some extra 'unusual' files in it. if you request a manual review, I'll accept it
[14:12] <zyga> hey jamie! thank you for the feedback there
[14:12] <Saviq> niemeyer: hey, we've had a handful of jobs fail today with spread tasks getting stuck (?) on linode https://travis-ci.org/MirServer/mir/jobs/337880107
[14:12] <jdstrand> you're welcome. sorry if I was a bit confused :)
[14:13] <Saviq> niemeyer: shall we add -v on top of the -v to see what's what if this hits us again?
[14:13] <zyga> I'll have more soon, I'm working on tests for existing, non-hardened implementation
[14:13] <Chipaca> niemeyer: @attache in the forum (on the planet jumper post) has the exact same cpu/gpu as i do
[14:14] <Chipaca> and the error is the same
[14:15] <mup> PR snapd#4619 opened: tests/main/user-data-handling: get rid of ordering bug <Created by chipaca> <https://github.com/snapcore/snapd/pull/4619>
[14:15] <jdstrand> mvo_: so, I've add sudo and the ssh binaries to the review tools, but the /var/log/journal setgid dir is weird. did you actually want to include that?
[14:16] <Chipaca> mvo_: why do we worry so much about powerpc if we don't have a core for it?
[14:16] <mvo_> jdstrand: aha, good point, will kill it
[14:16] <mvo_> jdstrand: we don't want this to prevent wear out o
[14:17] <mvo_> f the mmc
[14:17] <mvo_> Chipaca: don't ask
[14:17] <Chipaca> mvo_: OK.
[14:17] <mvo_> Chipaca: well, I will answer anyway
[14:17] <Chipaca> mvo_: oops too late, already retracted my question
[14:17] <Chipaca> I can't undo the undo! the universe will fall apart!
[14:17] <jdstrand> mvo_: ping me when r7 is uploaded and you request a manual review and I'll push it through
[14:18] <mvo_> Chipaca: we should stop supporting it, but that means a bit of paperwork, i.e. add this to the exception for our SRU policy etc. which probably needs approval and discussion. the end result is most likely that supporting is cheaper than stopping
[14:18] <jdstrand> *this* is the week that I will *finally* request a pull of the review tools, but ping me until that is in prod
[14:18] <mvo_> jdstrand: will do, let me kill that dir, I think it sneaked in due to a systemd change
[14:21]  * jdstrand nods
[14:31] <Chipaca> pedronis: niemeyer: is there any obvious (or non-obvious) bug in this: https://pastebin.ubuntu.com/26530120/ ?
[14:32] <Chipaca> pedronis: niemeyer: symptom I'm seeing is that in some environments it never prints a dot, and hangs forever
[14:32] <Chipaca> pedronis: niemeyer: gccgo and the playground
[14:33] <Chipaca> and, where do bugs on gccgo get reported :-)
[14:34] <mvo_> jdstrand: there is a r7 now for base-18
[14:35] <mborzecki> niemeyer: https://paste.ubuntu.com/26530133/ TLS handshake timeout, are we abusing linode too much?
[14:38] <Chipaca> zyga: do you have a bionic system to hand?
[14:39] <zyga> mborzecki, niemeyer: I updated 4610
[14:47] <kalikiana> re
[14:47] <jdstrand> mvo_: can you request a manual review? (if I do, then I can't process it)
[14:48] <mvo_> jdstrand: ups, sorry, done. thank you
[14:49] <jdstrand> mvo_: approved but not published to a channel
[14:51] <mvo_> jdstrand: ta
[14:51] <mborzecki> niemeyer: edited the https://forum.snapcraft.io/t/core-configuration-options/87 and added info on refresh.timer, feel free to review and redact as needed
[14:51] <mvo_> ackk: please check the latest base-18 in edge
[14:52] <ackk> mvo_, ah, thanks, checking now
[14:52]  * Chipaca bbiab
[14:52] <mup> PR snapd#4619 closed: tests/main/user-data-handling: get rid of ordering bug <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4619>
[14:59] <pedronis> Chipaca: sounds like a compiler that doesn't put, let's give a chance to other goroutines checkpoints, in some cases ?
[15:04] <mup> PR snapd#4607 closed: wrappers: cleanup enabled service sockets <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4607>
[15:08] <mvo_> cachio_: I triggered a new 2.31 core snap build, it seems the builders are quite busy right now, so hopefully in ~1h it will be there
[15:08] <cachio_> mvo_, great, tx
[15:27] <cwayne> mvo_: do we expect it in beta today?
[15:40] <andyrock> mvo_ , niemeyer: hi! In bionic we  are almost ready to push the changes (in udisks2 and gnome-disk-utility) to hide snap loop devices from gnome-disks
[15:40] <Chipaca> pedronis: yeah, going to file a bug
[15:41] <zyga> for context, we need a way to refresh existing .mount units to get the benefits for all the snaps people have installed
[15:41] <Chipaca> pedronis: as soon as i check it isn't yet fixed in a more recent build
[15:41] <pedronis> didn't we have already something else that required .mount updates?
[15:41] <Chipaca> hence me asking around for a B
[15:41] <andyrock> yeah thanks zyga
[15:42] <zyga> I was thinking we could port that code to use the ensure dir state code so that we can freely change mount units in the future
[15:42] <zyga> but I wasn't sure where to put the call, probably just like interface manager
[15:42] <zyga> (on interface startup)
[15:43] <zyga> er
[15:43] <zyga> s/interface/overlord/
[15:44] <ackk> mvo_, so I got further then bafore with base-18, but maas snap now fails with django.db.utils.DataError: invalid value for parameter "TimeZone": "UTC"
[15:45] <mvo_> ackk: aha, the I think this one if from the timezone database
[15:45] <mvo_> ackk: if you use the beta core snap, you can probably use "snap run --strace" when starting your app to see what files it tries to access
[15:45] <ackk> mvo_, so the build you gave a while ago add something that's still missing in edge I guess
[15:46]  * cachio_ lunch
[15:46] <mvo_> cwayne: yeah, it should be in beta today
[15:46] <mvo_> cwayne: builds are a bit slow though
[15:47] <mvo_> cachio_: i386/amd64/ppc64el are ready
[15:51] <zyga> mvo_, do you think this can be a 2.32 roadmap item?
[15:53] <mvo_> ackk: let me check the timezone db, is that something that the snap could ship?
[15:53] <mvo_> zyga: what is "this"?
[15:53] <zyga> mvo_ what I described above, a way to refresh .mount units
[15:53] <ackk> mvo_, maybe yes
[15:54] <ackk> mvo_, fwiw http://paste.ubuntu.com/26530521/ is the diff between the content of the custom built you gave me and the one in edge
[16:06] <mvo_> ackk: I think its the -./usr/share/zoneinfo/Etc/UTC zoneinfo stuff
[16:08] <mvo_> cachio_: armhf/arm64 are ready now too
[16:14] <Chipaca> pedronis: https://github.com/golang/go/issues/23721 fwiw
[16:14] <ackk> mvo_, yeah I think so, could that be included too?
[16:14] <Chipaca> mvo_: ^that's our powerpc issue :-)
[16:14] <Chipaca> mvo_: workaround coming in a pr rsn
[16:20] <niemeyer> andyrock: Thanks for that
[16:20] <andyrock> niemeyer the problem is that this is not going to work for existing mounted snaps
[16:21] <andyrock> so zyga proposed a way
[16:21] <andyrock> but we (the desktop team) need to know it this is going to get done before B is released
[16:22] <mup> PR snapd#4620 opened: debian/rules: workaround for https://github.com/golang/go/issues/23721 <Created by chipaca> <https://github.com/snapcore/snapd/pull/4620>
[16:24] <mup> PR snapd#4619 opened: tests/main/user-data-handling: get rid of ordering bug <Created by chipaca> <https://github.com/snapcore/snapd/pull/4619>
[16:28] <niemeyer> andyrock: I'm a bit out of context about what this is fixing and what we want to achieve at the end. Is there a thread I could read?
[16:29] <andyrock> niemeyer: https://www.irccloud.com/irc/canonical.com/messages/zyga
[16:29] <andyrock> sorry
[16:29] <andyrock> https://github.com/snapcore/snapd/pull/4294
[16:29] <mup> PR #4294: Mount with x-gdu.hide option <Created by azzar1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4294>
[16:30]  * zyga raises his ear
[16:30] <zyga> (feel free to pull me into the conversation)
[16:31] <zyga> jdstrand replied
[16:31] <zyga> 37 seconds after you asked :)
[16:36] <niemeyer> andyrock: Thanks, get it now
[16:37] <andyrock> niemeyer so zyga proposed this:
[16:37] <andyrock> https://www.irccloud.com/pastebin/EwM37tE1/
[16:38] <andyrock> if we know that this is going to be done before B is released we push the changes as they're upstream
[16:39] <zyga> andyrock why not push the changes already?
[16:39] <andyrock> otherwise for the moment we apply also a distro patch to work around this (in gnome-disk-utilities)
[16:39] <andyrock> zyga to avoid pushing twice
[16:39]  * zyga doesn't get it
[16:39] <andyrock> first push: the generic fix (already upstream)
[16:40] <andyrock> second push: the ubuntu specific fix
[16:40] <zyga> what is the difference between them?
[16:40] <zyga> I assumed we would just carry the patch in the package
[16:40] <andyrock> if we know that this is not going to get done we push both
[16:40] <zyga> aha, I see
[16:41] <niemeyer> I don't quite see yet.. one way or the other the fix will work out
[16:41] <zyga> I think the answer is, it will be done, the only question is how soon
[16:41] <andyrock> in Ubuntu
[16:41] <andyrock> not in other distros
[16:41] <niemeyer> In one scenario it gets gradually cleaned, in other it gets cleaned at once
[16:41] <zyga> and the patch won't hurt, in other places everyone will benefit from new upstream udisks
[16:41] <niemeyer> For anyone installing 18.04, they have no previous mounts
[16:41] <zyga> and all new installs are not affected anymore
[16:42] <niemeyer> I'd actually prefer to do nothing on that basis.. at least for now.. rewriting all mount units feels uncomfortable from a sanity standpoint, if nothing else
[16:42] <andyrock> seb128: ^^^
[16:43] <andyrock> so at this point we could just apply the workaround
[16:43] <jdstrand> andyrock: as an aside, thank you for your work on this. this will be a nice improvement
[16:43] <seb128> andyrock, in a call atm but I read later, if it's not perfect / have some mounts still showing that clean over time that's not the end of the world
[16:44]  * jdstrand only just now saw that PR
[16:44] <andyrock> seb128: kk. So what I suggest is the following:
[16:45] <andyrock> both in bionic, artful and xenial we distro patch to use the workaround (just hide if the loop backing file has the ".snap" suffix)
[16:45] <andyrock> the workaround is just in gnome-disk-utilities
[16:46] <zyga> andyrock is that released? I still see them
[16:46] <andyrock> upstream will benefits from the upstreamed patches
[16:46] <seb128> zyga, not yet, should be uploaded to bionic tomorrow
[16:46] <zyga> ah
[16:47] <niemeyer> andyrock: Sounds nice
[16:48] <andyrock> seb128: If you arealdy started the uploading process we can keep it
[16:49] <andyrock> it can be used somewhere else too
[16:49] <seb128> andyrock, not, I'm in a call, I'm going to do that tomorrow morning
[16:49] <seb128> but yours patches are still good/right
[16:49] <Chipaca> zyga: finished with the powerpc box
[16:49] <seb128> so why not including them?
[16:49] <andyrock> kk
[16:49] <andyrock> but I'll proposed another workaround too
[16:50] <andyrock> but we can discuss about this in #ubuntu-desktop after the call
[16:51] <seb128> right, let's discuss that tomorrow morning
[16:51] <seb128> that call is still ongoing for a while and then I need to go
[16:52] <zyga> Chipaca glad I could help, sad I could help
[16:57] <andyrock> kk
[17:04] <philroche> Is there a way to enable site-packages in the virtualenv in a snap built with the python plugin? I have a requirement python-apt that cannot be installed using pip. I can't see anything in the docs or examples on how to do this
[17:09]  * kalikiana wrapping up for today
[17:10] <kalikiana> philroche: not quite an answer to your question, but Snapcraft uses a tarball in requirements.txt to achieve the same thing. See https://github.com/snapcore/snapcraft/blob/master/requirements.txt#L10
[17:11] <philroche> kalikiana: Interesting. Thank you
[17:44] <lotuspsychje> good eveing to all
[17:44] <jdstrand> mvo_: I see new revisions for base-18. can you request manual review for the ones you are interested in?
[17:45] <lotuspsychje> someone might know why skype doesnt come anywhere latest here? http://feeds.feedburner.com/uAppExplorerNewSnaps
[17:47] <kyrofa> lotuspsychje, uAppExplorer is a third-party site, we have no control over it
[17:48] <lotuspsychje> kyrofa: ok, im trying to find an rss the way sudo snap find lists the latest ones, got any idea?
[17:55] <Chipaca> mvo_: question about #4617
[17:55] <mup> PR #4617: many: implement "refresh-mode: survive" for services <Created by mvo5> <https://github.com/snapcore/snapd/pull/4617>
[17:55] <Chipaca> mvo_: if it's survive, and has a reloadcommand, wouldn't you fire that?
[17:56] <Chipaca> hm, maybe i'll ask it on the pr :-)
[17:56]  * Chipaca sees it's dinnertime in mvoland
[18:01]  * Chipaca EOWs (mostly)
[18:11] <el_tigro1> kurofa: Thanks again for the help yesterday
[18:12] <el_tigro1> zyga: I ran into this great documentation today which I'm assuming you wrote
[18:13] <zyga> which documentation was that?
[18:13] <el_tigro1> zyga: https://github.com/snapcore/snapd/wiki/Snap-Execution-Environment
[18:13] <zyga> ah, yes
[18:14] <el_tigro1> Question about the last paragraph "Preserving the mount namespace". The "/run/ns/snapd/" directory doesn't seem to exist on my system
[18:14] <zyga> sorry, that's backwards, it should be /run/snapd/ns
[18:15] <zyga> let me fix that
[18:15] <el_tigro1> Ohh I should have caught that :D
[18:19] <el_tigro1> zyga: Also I was wondering in what order "snap-confine" does its job. I'm assuming it handles the mount namespace stuff first, and then applies the apparmor/seccomp confinement?
[18:19] <zyga> it's complicated, I should write something more in depth
[18:20] <zyga> it handles all of mount namespace handling first, using itself and a helper process (snap-update-sn)
[18:20] <zyga> it applies seccomp and apparmor and cgroup handling before running the application
[18:20] <zyga> normally the order should not matter to apps, it should just work
[18:22] <el_tigro1> really? the reason I assumed that was the order is that I thought apparmor/seccomp could disable the "mount" system call
[18:23] <el_tigro1> Actually I mean the unshare/clone system calls
[18:23] <el_tigro1> Actually I'm confused. Just ignore what I'm saying :P
[18:23] <zyga> yes it can
[18:23] <zyga> during the whole process the sandbox changes a few times
[18:23] <zyga> snap-confine itself is confined with one profile
[18:23] <zyga> snap-update-ns is confined with another profile
[18:24] <zyga> and the application being started is confined with its own profile
[18:24] <zyga> (and some of the work I'm doing now will also tailor snap-update-ns to have different profile per snap)
[18:24] <zyga> all of this is so that it's harder to attack the system and so that super-power wielding things are as confined as possible
[18:25] <zyga> mount is confined both at syscall level through seccomp and at path/device/options level through apparmor
[18:27] <el_tigro1> Thanks. I find this stuff really interesting
[18:28] <el_tigro1> I guess 'snap-confine' uses the 'pivot_root' system call to change its root?
[18:28] <zyga> yes, that's correct
[18:28] <zyga> it also jumps in and out of namespaces
[18:28] <zyga> inspects them, invalidates them when necessary
[18:28] <zyga> it handles cgroups (freezer and device)
[18:29] <zyga> it uses snap-update-ns to construct and update existing namespaces
[18:29] <zyga> and saves them on disk to preserve them across process lifecycle
[18:31] <el_tigro1> 'pivot_root' takes an 'put_old' argument, which I guess is the '/var/lib/snapd/hostfs'?
[18:31] <zyga> yes
[18:32] <el_tigro1> And in that documentation link from above "Certain directories from the host file system are mapped (bind-mounted) to the mount namespace (see below).". They directories are the ones listed below the "The mount profile of the snap is applied (e.g. content sharing uses this)" bullet point right?
[18:33] <zyga> yes
[18:33] <zyga> though that's an incomplete list now, it also depends on interfaces
[18:33] <zyga> and it also depends on nvidia driver being used
[18:34] <el_tigro1> Wow thanks a lot for your time. You've given me quite a few leads. Back to experimenting/studying :D
[18:34] <zyga> feel free to ask questions
[18:34] <zyga> perhaps you would like to contribute back by writing documentation
[18:35] <zyga> let me know if you'd like to help
[18:35] <el_tigro1> Defintely. Once I feel like I have a solid enough understanding
[18:55] <mvo_> ackk: I added tzdata now, it will be part of the next base-18 build
[18:55] <mvo_> ackk: (sorry for the delay)
[18:57] <el_tigro1> One thing that I noticed is that older versions of snaps are not removed. For example if I do 'ls /snap/lxd' I see 3 folders and a symbolic link 'current' pointing to the latest version. Would removing the directories containing the older versions be a bad idea?
[18:57] <zyga> this is on purpose
[18:57] <zyga> you also have three revisions of the snap installed, but not active
[18:58] <zyga> (only one is active)
[18:58] <zyga> when something goes bad and you want to revert to a prior version (e.g. broken update) the data is kept around
[18:58] <el_tigro1> ahh I see
[18:58] <zyga> over time old revisions are removed, no need to do that manually
[19:29] <zyga> niemeyer +1 to merge 4610?
[19:29] <niemeyer> zyga: Should be.. let me check
[19:32] <niemeyer> zyga: Looks fine, thanks for double checking
[19:33] <zyga> great, thank you!
[19:33]  * zyga gets a coffee and works on some more :)
[19:33] <mup> PR snapd#4610 closed: interfaces/apparmor: early support for snap-update-ns snippets <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4610>
[20:16] <philroche> Can anyone see what is wrong with my snapcraft.yaml as I can not get the organize section to work with the python plugin https://github.com/philroche/ubuntu-watch-packages/blob/master/snap/snapcraft.yaml ? Thanks
[20:17] <nacc_> philroche: i think it's your .'
[20:17] <nacc_> philroche: so i believe, it's going to be running form the root of your source
[20:17] <nacc_> it won't find 'wrapper' there
[20:18] <mup> PR snapd#4621 opened: tests: skip alsa interface test when the system does not have any audio devices <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4621>
[20:18] <nacc_> philroche: i put wrappers in their own part that's dump'd into the snap
[20:18] <nacc_> philroche: alternatively, you put it i your MANIFEST.in
[20:19] <nacc_> philroche: but otherwise, i don't thinkt he setup.py will see it and soo the python plugin won't
[20:19] <philroche> nacc_: I tried it with wrapper in root too and the same error "The specified command 'wrapper' defined in the app 'ubuntu-watch-packages' does not exist or is not executable"
[20:19] <philroche> nacc_: Yeah using a second dump part was my next approach
[20:20] <nacc_> philroche: i would try that first (the dump part)
[20:20] <philroche> nacc_: I hadn't thought of using the MANIFEST.in either but that seems a bit dirty by introducing snap stuff to the python package
[20:21] <nacc_> philroche: yeah i woulldn't recommend it :)
[20:31] <sergiusens> jdstrand stgraber in case you have a couple of minutes https://forum.snapcraft.io/t/disconnected-issue-a-cocktail-of-running-snapcraft-cleanbuild-in-multipass-with-the-lxd-snap/3891
[20:34] <philroche> nacc_: Thanks. Trying dump method now
[21:25] <cachio_> niemeyer, https://travis-ci.org/snapcore/snapd/builds/338037140
[21:25] <cachio_> Cannot allocate linode:ubuntu-14.04-64: cannot perform Linode request: Post https://api.linode.com: net/http: TLS handshake timeout
[21:26] <cachio_> that happened today
[21:26] <cachio_> it is not so frequent but I see 1 or 2 of those every day
[21:27] <niemeyer> cachio_: Thanks, also keeping an eye on those
[21:27] <niemeyer> cachio_: But the most important issue is still the state corruption they seem to observe
[21:27] <niemeyer> cachio_: Without that sorted we'll need to go elsewhere in the near future.. fingers crossed
[21:28] <cachio_> niemeyer, good, tx
[21:56] <kyrofa> zyga, I can't seem to reproduce the LXD issue as of 2.30. I'm not sure what changed
[21:56] <zyga> maybe lxd shipped some workaround?
[21:56] <kyrofa> Yeah that's my only clue as well
[21:56] <zyga> are you sure you are on 2.30?
[21:57] <kyrofa> Yeah, rev 3748
[21:58] <kyrofa> (tracking stable)
[22:08] <mup> Issue snapcraft#1918 opened: Add y/n support for sending errors back <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1918>
[22:08] <mup> Issue snapcraft#1919 opened: Add Always/neVer support when sending errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1919>
[22:08] <mup> Issue snapcraft#1920 opened: Design error reporting <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1920>
[22:44] <mup> PR snapd#4622 opened: strutil: introducing MatchCounter <Created by chipaca> <https://github.com/snapcore/snapd/pull/4622>
[22:45] <mup> PR snapd#4620 closed: debian/rules: workaround for https://github.com/golang/go/issues/23721 <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4620>


 What app do you want to install?
[00:13] <timon_> some app cold super tux kart
[00:14] <timon_> i think that is what it is cold
[00:18] <KTrad[A]> sorry laptop crashed
[00:18] <KTrad[A]> what app?
[00:19] <timon_> i meant to say called not cold
[00:19] <timon_> can you help me find the app manager i can not find it
[00:20] <timon_> i know there is one
[00:20] <timon_> i just cant find it
[00:21] <timon_> it is called super tux kart
[00:21] <timon_> i think
[00:22] <timon_> i can not find the software center
[00:23] <KTrad> Is software center not installed?
[00:23] <KTrad> If not just open up a terminal and type: supd apt install software-center
[00:23] <timon_> okay i will try that
[00:23] <KTrad> https://www.linuxbabe.com/games/install-supertuxkart-0-9-2-ubuntu-16-04
[00:23] <KTrad> also follow that to install super tux kart
[00:24] <KTrad> brb have to go pickup my kid
[00:25] <timon_> okay thanks i used the link and it worked
[00:25] <timon_> and i installed the software center
[00:25] <timon_> okay
[01:24] <Jack_Sparrow__> !find filezilla
[02:51] <jonathan_> saludos
[02:52] <jonathan_> speak spanis ?? \
[02:58] <KTrad> no
[07:03] <codrin> salutare am o problema cu ubuntu mate 16.04 nu isi instaleaza update-urile de nici o culoare daca ii dau sa caute dupa update-uri nici macar nu imi apare sa ma autentific
[07:04] <codrin> ce distributie imi recomandati pentru un calculator cu un procesor pentium dualcore 4 gb ram (insa joc f mult minecraft care ocupa pe putin 1.5 gb
[07:06] <alkisg> !en
[07:07] <alkisg> !!ro
[08:09] <apollo_> How to install online tv in ubuntu
[08:54] <ouroumov> alkisg, you there?
[08:54] <alkisg> Hi ouroumov
[08:54] <ouroumov> hi
[08:54] <ouroumov> alkisg, can you reproduce this? https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1697891
[08:55] <alkisg> ouroumov: ah, I'm not on zesty, I would need to fire up a VM etc; could you remind me tomorrow?
[08:55] <ouroumov> Sure
[08:55] <alkisg> Does that happen on zesty client or on zesty server?
[08:55] <ouroumov> Zesty client
[08:56] <alkisg> OK, will be easy to test
[08:56] <ouroumov> (Xenial server)
[08:56] <alkisg> Btw, could you check if printing to pdf (or printer) from firefox, says date=1970?
[08:56] <ouroumov> checking
[08:56] <alkisg> Go to any page and print to pdf, and check bottom right of the page
[08:56] <alkisg> For me it's stuck in 1/1/70, 1:41 pm
[08:57] <ouroumov> Yeah alkisg, file is marked as being created at the UNIX epoch, lol
[08:57] <alkisg> Heh
[08:57] <alkisg> OK, will report it tomorrow
[08:58] <ouroumov> oh wait alkisg
[08:58] <ouroumov> Actually I missed the "firefox" part
[08:59] <ouroumov> I've just printed from Atril
[08:59] <alkisg> Atril puts banners?
[08:59] <alkisg> Ah, I meant, that firefox puts that there,
[08:59] <alkisg> either in .pdf or in printer
[08:59] <alkisg> And of course if it's in the pdf, however you print it later on, it will still be there
[09:00] <alkisg> So it's a firefox bug, not an atril bug; atril just prints what the .pdf has
[09:00] <alkisg> s/banner/footer
[09:00] <ouroumov> oh, so epoch is normal
[09:00] <ouroumov> checking in firefox
[09:01] <ouroumov> Hm, I don't see any problem
[09:01] <alkisg> So if you go e.g. to www.google.com, and print it to a pdf,
[09:02] <alkisg> and then you open the result, google.pdf,
[09:02] <alkisg> you don't see the epoch there?
[09:02] <ouroumov> Yeah it writes 14/06/2017
[09:03] <alkisg> Is that xenial or zesty?
[09:03] <ouroumov> Zesty with Firefox 53.0.3
[09:03] <alkisg> ty; will check if it only affects xenial or my installation then
[09:06] <alkisg> ouroumov: ssh -X xenial-pc pluma, works for me from my zesty vm
[09:06] <ouroumov> weird, I tried in a VM too just now and it doesn't work for me
[09:09] <ouroumov> Maybe my Xenial machine is screwed up
[09:13] <ouroumov> Okay, so that's likely the case, I've just tried against a Trusty server and it works
[11:18] <jbyd> buenos dias
[11:19] <jbyd> por favor me enseñan a compartir archivos o carpetas entre ubuntu mate y win10 a traves de una red wifi
[13:37] <barberi> HI
[13:37] <Jack_Sparrow__> Hey
[13:50] <shantorn> is anyone familiar with accomplishing the tor browser install using the software boutique installer, mine keeps timing out no matter what mirror i use or asks me if i am connected to the internet
[13:51] <shantorn> it sits at downloading signature for a bit then errors
[13:51] <ouroumov> hi shantorn
[13:51] <shantorn> hi
[13:51] <ouroumov> have you run the update first?
[13:52] <ouroumov> did you *
[13:52] <shantorn> from software boutique?
[13:52] <ouroumov> No, system update, then subscribed to Welcome updates
[13:52] <shantorn> hmm not like that no, apt-update then?
[13:53] <ouroumov> yeah, sudo apt update && sudo apt full-upgrade
[13:53] <ouroumov> shantorn, btw what version of Ubuntu MATE are you using?
[13:53] <shantorn> its been since 15 since i have used ubuntu so i have forgotten a bit, sorry
[13:54] <ouroumov> no problem
[13:54] <shantorn> 17.04 and its all up to date
[13:55] <shantorn> @bamboo:~$ sudo apt full-upgrade
[13:55] <shantorn> Reading package lists... Done
[13:55] <shantorn> Building dependency tree
[13:55] <shantorn> Reading state information... Done
[13:55] <shantorn> Calculating upgrade... Done
[13:55] <shantorn> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[13:55] <shantorn> dang sorry
[13:55] <shantorn> i know better i appologise
[14:00] <shantorn> ouroumov, also i could use some help setting up my optimus graphics if there is someone versed in that
[14:01] <Astro7467> @shantorn: before the apt full-upgrade, did you run sudo apt update?
[14:01] <shantorn> yes
[14:02] <Astro7467> Okay
[14:03] <shantorn> thank you for asking though, it prompted me to review my terminal to verify i wasnt going bonkers
[14:07] <Astro7467> is your repository source set to main or a country specific one? sometimes being of main causes greif
[14:09] <Astro7467> try; sudo apt-cache policy torbrowser-launcher
[14:09] <Astro7467> I get;
[14:09] <Astro7467>   Installed: 0.2.7-1
[14:09] <Astro7467>   Candidate: 0.2.7-1
[14:19] <shantorn> i show the same
[14:29] <shantorn> brb
[14:41] <shantorn> Astro7467, any other ideas on how to get the tor-launcher to not time out or error 404?
[15:36] <Astro7467> @shantorn could try to download the deb directly from Ubuntu thru browser and install with dpkg or gdebi
[15:36] <Astro7467> give me a sec to find the URL
[15:38] <Astro7467> in the meantime, are you able to install any other pkgs from the Ubuntu repository? eg debian-goodies?
[15:41] <Astro7467> unverified src : https://ubuntu.pkgs.org/17.04/ubuntu-universe-amd64/torbrowser-launcher_0.2.7-1_amd64.deb.html
[15:46] <alkisg> He left
[15:53] <Astro7467> Okay - missed the notice - thanks
[15:54]  * alkisg likes pidgin; it shows persons that are no longer here, in italics, so it's easy to see if someone left or not
[15:56] <Astro7467> using IRCcloud cos I'm too time poor for a znc install
[16:34] <raspberrymateUK> hello!
[17:09] <teward> kudos to Mate, it's faster than Unity lol
[17:10] <Akuli> yeah it is :)
[17:58] <DarkPsydeLord> and better looking
[17:58] <DarkPsydeLord> also a lot more customizable
[17:59] <KTrad> I was actually a fan of Unity. Preferred MATE obviously but Unity was nice.
[18:00] <DarkPsydeLord> i hate unity the most thats why i got into mate :)
[18:01] <KTrad> I got into MATE because it was the only DE that ran at a reasonable speed on my old iMac G5 when I compiled it for FreeBSD
[18:01] <DarkPsydeLord> KTrad, well theres plenty of options, im using i3 + mate on my arch build
[18:02] <DarkPsydeLord> i threw marco compositor out of the window
[18:03] <KTrad> I like i3 just not my choice for my daily computer
[18:05] <DarkPsydeLord> back in time i used crunchbang also which was super light and awesome to use
[18:05] <DarkPsydeLord> today its justr arch and ubuntu mate
[18:05] <KTrad> I miss #!
[18:05] <KTrad> was my distro of choice for aging computers
[18:17] <DarkPsydeLord> i liked puppy for that purpose
[18:21] <KTrad> was never a fan of puppy
[18:21] <KTrad> DSL was nice though
[18:33] <DarkPsydeLord> damn small linux
[18:33] <DarkPsydeLord> is it going on still?
[18:34] <KTrad> no it's dead
[18:34] <DarkPsydeLord> what a shame it was nice tough
[18:35] <KTrad> yea
[18:40] <DarkPsydeLord> anyway we have mate :D
[18:41] <KTrad> very true
[18:41]  * KTrad pets her powerbook dualbooting OSX 10.4.11 and Ubuntu MATE 16.04
[18:44] <KTrad> I have a 486DX4-100 that has TinyCore installed. Runs pretty slow but the 48mb of ram is just enough to open up a text editor haha
[18:49] <DarkPsydeLord> hahaha
[18:50] <DarkPsydeLord> i had my 386 working till 2014
[18:51] <KTrad> Still have one but the HDD finally died on it. All 500mb of it lol
[18:52] <KTrad> my 8088 on the other hand is dead. Just keep it around as decoration
[19:24] <yo2> hello
[20:46] <mate|84473> hi guys
[20:47] <mate|84473> I use UMATE on raspberry PI3
[20:47] <mate|84473> I have 2 wifi interface (internal on and usb one)
[20:48] <mate|84473> How can I had a static route each time an interface is up ?
[20:53] <Astro7467> @mate|84473: ur question is probably to non-MATE related to find assistance here
[20:54] <Astro7467> a Google of "Ubuntu wifi static routes" provides what look to be many promising results
[20:56] <mate|84473> The thing is that my route disappear when the interface is down
[20:57] <mate|84473> I think writting a script which recreate the route automatically, each time the interface comes up
[21:29] <stain> hi i have a problem
[21:29] <stain> is the pentium p6100 good for a 32 bit??
[21:46] <Jack_Sparrow__> Dont buy 32 bit
[21:48] <rahtgaz> stain: yes. it includes the x86 instruction set
[21:49] <stain> thanks
[21:49] <rahtgaz> i mean to say the full x86 instruction set. but he got it
[23:01] <johnjay>  3
[23:58] <motobot> Hi All! I'm new to RPi and Ubuntu Mate
[23:58] <motobot> I want to setup my RPi as a headless server that I will connect with via ssh


[18:53] <Linnak_> Hi, I've just bought a BQ Aquaris M10 FHD Ubuntu version. After an update I can't find a lot of applications. I missunderstood maybe the whnole Ubuntu Touch system. So there is no Ubuntu repos?