[13:46] <JHOSMAN> Hello, has anyone here worked with compiling Ubuntu ISO images with support UEFI? I tell you, I'm making an ISO Unattended Ubuntu, but I can not make it do the UEFI boot  in mode EFI active in bios, the iso says BosyBox and the install not running, in mode legacy run OK.
[13:59] <mdeslaur> JHOSMAN: this is a repo containing the tools that generate the official images, perhaps that can help: http://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/files
[13:59] <jalt> Hi, is there any better-maintained documentation about ubiquity than https://wiki.ubuntu.com/Ubiquity? More precisely documentation related to unattended/preseeded installs, and how to control which tasks/packages get installed?
[14:00] <xnox> jalt, one cannot controlled tasks/packages that get installed in ubiquity, as it is doing live-installer based installation and the squashfs is copied as a whole blob over to the installed system.
[14:01] <xnox> you want to use d-i, or use server.iso squashfs (as that only has base bootstrapped and nothing else)
[14:01] <xnox> or generate your own squashfs.
[14:01] <jalt> hmm i sort of knew that but I didn't realise the base squash-fs had ALL the packages
[14:01] <xnox> hence e.g. using xubuntu.iso one has xubuntu squashfs and all of it is copied over.
[14:01] <xnox> jalt, on a live cd -> yes it does.
[14:01] <xnox> cause the livecd environment is more or less what is copied onto target.
[14:01] <jalt> thanks for the quick response :)
[14:02] <xnox> (there is an overlayfs thin layer that differentiates base vs live; e.g. with default user setup)
[14:02] <xnox> that magic is done in casper
[14:03] <jalt> basically my goal was to get a preseeded install for a thinner xubuntu environement, something like xubuntu-core, but from the pristine official isos, i.e., no remastering
[14:13] <Sevio> jalt: the casper/filesystem.manifest-remove file may be useful to you for removing packages present on the live iso after installation, but to add stuff you'd have to remaster I think
[14:13] <jalt> is there any way to debug the install or check the post-install logs and see *exactly* which directives of the preseed file were executed vs. ignored? I know that netcfg, lvm/raid, pkgsel/tasksel and a few others are not honored by ubiquity, but I'd like to double check with the intention of trimming down the preseed file to make it easier to read and manage in the future.
[14:13] <Sevio> gtg
[14:13] <jalt> thanks Sevio
[14:14] <Sevio> got most of my info from here: http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/annotate/head:/doc/README
[14:33] <JHOSMAN> mdeslaur: This are my files: http://paste.ubuntu.com/23085214/
[14:33] <JHOSMAN> A normal iso says this: http://paste.ubuntu.com/23084984/ (from canonical)
[14:34] <JHOSMAN> My iso make unnatended says: http://paste.ubuntu.com/23084986/
[14:35] <xnox> jalt, ubiquity has support for lvm & crypto these days.
[14:36] <xnox> most things are ignored =) the things that are used, are around partman, user account setup, timezone/language selection, and minimal apt sources setup (with or without restricted extras)
[14:37] <jalt> perhaps I should have added that I already got it to "work" and now I was trying to fine tune it, but that is tough when the docs are so outdated and, well, plainly poorly undocumented to begin with
[14:38] <jalt> someone with wiki access should delete the whole thing and replace with this gem I found online: https://docs.google.com/document/d/1_4fDkd9TXQ0nUIL5Q-5W61TKrVpyS32x34GksL1uR8Q/edit?pref=2&pli=1#
[14:39] <xnox> which wiki?
[14:39] <jalt> all ubuntu wiki pages related to unattended installation ;)
[14:39] <xnox> haha
[14:40] <jalt> seriosuly, they are terribad, even for ubuntu standards.
[14:40] <jalt> and it's sad because stuff actually works
[14:40] <xnox> jalt, that google doc is very bad imho =) most people who use unattended desktop installs, use PXE / nfs boot of the live iso exported on the server. To reinstall thousands of desktops in one go, with preseeds fetched over the network.
[14:40] <xnox> that google doc doesn't work with secureboot uefi
[14:41] <xnox> and yes, it is possible to do unattended installs with desktop iso without remastering it
[14:41] <JHOSMAN> jalt: this documentation running?
[14:41] <jalt> almost jhosman. i didn't remaster the cd, and i am using a slightly different preseed file, but i got the boot parameters from it
[14:44] <jalt> xnox, i didn't want to depend on infrastructre to have pxe/tftp/nsf (and then maintain it). as for uefi and secureboot, burn it with fire. besides, if i was going to do a true mass deployment I'd use cloning software, or MaaS - if it ever gets good.
[14:45] <xnox> jalt, are you after something like "dd .iso to usb-stick; but append this pressed to it"
[14:45] <jalt> yep xnox
[14:45] <xnox> "boot into unattended install"?
[14:45] <jalt> precisely that
[14:45] <jalt> sadly i know i will need to remaster the iso at some point
[14:45] <jalt> or always add the boot params, which is annoying
[14:46] <xnox> i thought at one point we were talking about discoving pressed file on external media. E.g. boot official iso with a pressed on a usb stick plugged in.
[14:46] <xnox> kind of like cloud-init metadata style.
[14:46] <jalt> is that even possible? lol
[14:46] <JHOSMAN> I will use the steps of the document and emulate a machine with UEFI, I will be telling how it goes'll use Ubuntu 14.04 32 bits.
[14:46] <xnox> i386 install media has no support for uefi.
[14:48] <JHOSMAN> :( really=
[14:50] <jalt> i think fedora was going places with 32-bit UEFI, but I haven't followed that too closely. they wanted to get the cheap atom tables working, and they all have 64 bit processors but 32 bit UEFI, so it was very messy.
[14:50] <jalt> *atom tablets
[14:50] <xnox> in practice all of i386 uefi boards, support or have 64-bit cpus.
[14:51] <xnox> and they have gave up on 32bit uefi, and newer boards ship with 64-bit uefi, or are reflashable to 64-bit uefi.
[14:51] <xnox> with a bit of hacking one can install i386 system, and 32 or 64 bit grub-efi support. but it's not trivial.
[14:51] <jalt> xnox: can you tell me more about booting from an official iso and loading preseed files from a usb drive? or optimally dd an official iso to an usb and magically modify it via normal mounted fs operations?
[14:53] <xnox> neither is supported out of the box. I was talking hypothetically.
[14:53] <jalt> alas :(
[14:53] <xnox> e.g. preceed.cfg is loaded by default, but that means in d-i case modifying the initrd, or the .iso. .iso fs is iso9660 thing so even after dd to a usb disk it's not modifyable.
[14:54] <jalt> yep
[14:54] <xnox> usb-creator creates a modifyable bootable usb stick, but that doesn't have uefi support, but could support custom preseed.
[14:54] <jalt> right now i am loading the pressed from http url via modifying boot parameters on the dd'ed usb
[14:54] <xnox> we do automount certain usb disk-drives -> e.g. disk-inject-drives, but then one would still need to change bootprompt to load preseed file from tehre.
[14:54] <jalt> but of course that is not very practical
[14:54] <jalt> yep, that's what i am doing
[14:54] <jalt> for testing
[14:55] <xnox> modifying boot parameters on the dd'ed usb stick yeah that's the closest.
[14:55] <xnox> well, i think one can "update" iso9660 hopefully without destroying uefi support with a pressed.cfg file.
[14:55]  * xnox ponders about that for a second.
[14:56] <jalt> at that point you are better off replicating the official iso release procedure, like mdeslaur suggested
[14:56] <jalt> and simply replace the boot meny entries file and add a new custom.preseed file
[14:59] <JHOSMAN> jalt: Then I try to make the process with Ubuntu 14.04 64 bit with your documentation, and that would be fully desatentida installation and support UEFI right?
[14:59] <jalt> i don't know about uefi, but works with bios/legacy.
[15:01] <jalt> here's a similar guide: http://blog.utrescu.cat/Xubuntu_unattended/ it's in catalan, but it's very recent.
[15:03] <jalt> the magic ought to be on the parameters to burn the iso, i think. especially if you also need it to be hybrid (so it can be dd'ed into a usb pendrive)
[15:06] <JHOSMAN> what is the name of the keyboard Spanish / LatinAmerica?
[15:14] <jalt> JHOSMAN: is it not es-LA?
[15:15] <JHOSMAN> i dont know :(
[15:15] <JHOSMAN> :P jeje
[15:16] <JHOSMAN> in the night i try make a new iso file whit your Google Document.
[15:16] <JHOSMAN> But also what worries me is not work with UEFI :(
[15:21] <jalt> JHOSMAN, from google: http://askubuntu.com/questions/457528/how-do-i-create-an-efi-bootable-iso-of-a-customized-version-of-ubuntu
[15:21] <jalt> if you don't need iso-hybrid to boot from usb, those instructions apparently work (for 64 bit at least)
[15:23] <JHOSMAN> jalt: Last night I followed the same guide and why I come here, it did not work, did not start the installation emo do UEFI.
[15:23] <JHOSMAN> i use Ubuntu 14.04 x64 bits
[15:24] <jalt> sorry :( but i really have no experience with UEFI
[15:24] <JHOSMAN> example mkisofs no supported now, it's very older!
[15:24] <JHOSMAN> i use other software relationated of mkisofs
[16:57] <JHOSMAN> it's posible only enable text mode installer?
[17:51] <jalt> JHOSMAN: not from any of the desktop isos
[17:51] <JHOSMAN> ok
[17:52] <jalt> you need to use Ubuntu Server iso or mini.iso, but i can share my experiences with them
[17:52] <jalt> Server ISO uses pure d-i, so preseeding worked immediately
[17:52] <jalt> but i could not get xubuntu-desktop task to work (everything else was working)
[17:53] <jalt> mini.iso I kept overwriting the usdrive itself, so I gave up after a while
[17:53] <jalt> for either of them to work, you need auto=true priority=critical on the boot options.
[18:05] <JHOSMAN> mini iso no have desktop?
[18:09] <jalt> no, it's only 50MB and you need to download all packages from the repos.


 @Flohack What is QFuse in the Angler?
 Is that basically a eFuse, like in Samsung Devices?
[03:43] <ubptgbot> Rudi Timmermans was added by: Rudi Timmermans
 I was thinking before that the reinstall all apps feature isn't used anymore but it helped me move from arm64 to armfh without losing data. Not all apps were updated though...might need to try again
 hmmm, it's really not all apps are being reinstalled...
 I really thought I saw someone using fingerprint on and xperia x but it's also not on amrfh...I'm imagining things 😂
[05:44] <ubptgbot> Xatusbetazx17 was added by: Xatusbetazx17
 hi how are you i want to know i have a moto e secon generation p30 is conpatible with ubport ?
 For any that were missing it (as it seemed to have disappeared for at least a couple of weeks) -  Sailbook, the UT Facebook client webapp, is now back in the Open Store - continued thanks to Rudi Timmermans for maintaining it - https://open-store.io/app/sailbook.sailbook
 he seems to be back in this group as well. I'm happy to see that 😄
 @Javacookies [he seems to be back in this group as well. I'm happy to see that 😄], me as well!
 @SomeIrrelevantPerson0000 [@Flohack What is QFuse in the Angler?], No idea, where did you find it ?
 I noticed on Fastboot QFuse enabled
 Ah ok. No idea what it is ;)
 Florian, hi!
 @Flohack on device page, you added OnePlus 6T, but it is displayed not correctly, and his url is: https://devices.ubuntu-touch.io/device/codename/ .
 @Flohack [Ah ok. No idea what it is ;)], It's alright, did a bit of research.
 Does anybody have problems with adding gmail account to dekko?
 nvm imap was turned off
 Is anyone aware of an OTP client on UT?
 @bugsbenny [Is anyone aware of an OTP client on UT?], https://open-store.io/app/tfamanager.cibersheep
 @joeth [https://open-store.io/app/tfamanager.cibersheep], Much thanks!
 In morph browser, if I opening gitea page and logining, browser crashing!
 @bugsbenny [Much thanks!], no problem :D
[10:02] <ubptgbot> Nono 𝘠𝘦𝘴 𝘠𝘦𝘴 was added by: Nono 𝘠𝘦𝘴 𝘠𝘦𝘴
 @sevralti [@Flohack on device page, you added OnePlus 6T, but it is displayed not correctly …], If you ping me here there is no use in also sendingme pm
 It will make fixing the problem slower
 Because then im bothered and will ignore you for some time ;)
 Ping?
 @sevralti [Ping?], Using the @username is called pinging. PM = private message is writing someone in a individual chat, not a group. With the @ the other person gets a notification.
 ok
 Sorry
[11:02] <ubptgbot> C was added by: C
 Hello
 I have old andriod phone Lenovo k4 note  … Model no: A7010a48 … Android version : 6.0
 Please give the step by step tutorial to install ubantu touch in it
 That phone looks like it's not supported
 Yes! it's not supported
 Is any other method to root the phone and install ubantu touch
 YOUR phone NOT supported Ubuntu Touch!
 Ubuntu Touch is not Android
 This is other OS
 @sevralti [This is other OS], Yes I know
 Which phone supports ubantu touch
 https://devices.ubuntu-touch.io/
 @C [Is any other method to root the phone and install ubantu touch], You can build a port for this device. Is not easy...
 First you need to port Halium
 And use ubports-gsi
 If I buy old one plus phone how can I I install on them give instructions .I have a windows pc also with windows 7
 UBPorts Inatller
 @C [If I buy old one plus phone how can I I install on them give instructions .I hav …], OnePlus one phone
 Can install for 1 click
 For example I am using OnePlus 6T
 And Ubuntu Touch
 @sevralti [Can install for 1 click], Any video or step by step instructions to easy for me
 video on oneplus device page
 https://devices.ubuntu-touch.io/device/bacon/
 @mimecar [https://devices.ubuntu-touch.io/device/bacon/], A video only on nexus 5
 the process es similar
 [Edit] the process is similar
 It's universal instruction! For devices supported installer
 [Edit] It's universal instruction! For devices supported by installer
 [Edit] It's universal instruction! For devices supported installing by installer
 Hewwo from ububtu touch
 @amyosx [Hewwo from ububtu touch], which device?
 Wow, my name in the last q&a trasformed from "aurelio" to "Orwellio" I did not know that the  misspelling service was a free service I thought you have to be a patreon to have the name misspelled 🤣
 😹😹
 Hi there, has anyone ever had issues receiving text messages from a foreign number? (a uk number to an italian one)
 @Hunter616 [Hi there, has anyone ever had issues receiving text messages from a foreign numb …], Some company's charge for texts ,are they set up to allow them (at&t charges USA to UK) … Cheaper texting thru skype
 iphone
 iphone
[13:48] <ubptgbot> Nathan was added by: Nathan
 (Sticker, 461x512) https://irc.ubports.com/F8scR0cm.webp
 Hello
 Is it possible to screen record Ubuntu Touch?
 no in device way as far as I know … there's `mircast` IIRC which sends the frames to your PC … perhaps screen recording commands for wayland would work on the pinephone
 @amyosx [Hewwo from ububtu touch], E4.5
 @Javacookies I'm using the Nexus 5.ill try recording with Adb
 Just a random thought: am i the only person who thinks the ubports installer looks a little bit like kingroot?
 @amyosx [Just a random thought: am i the only person who thinks the ubports installer loo …], i don't have fond memories of that piece of sooftware
 @amyosx [Just a random thought: am i the only person who thinks the ubports installer loo …], [Edit] i don't have fond memories of that piece of software
 Pain to get rid of yeah, but ubports installer looks a little like it imo
[18:30] <ubptgbot> <Yann Escarbassiere> Hello, I would like to know about UT is there PyQT5? Thank you for your precious info
 @Yann Escarbassiere [Hello, I would like to know about UT is there PyQT5? Thank you for your precious …], there is not. there is `pyotherside` which is designed for use with QtQuick (QML) applications
[18:59] <ubptgbot> <Yann Escarbassiere> Thanx you Radney
[18:59] <ubptgbot> <Yann Escarbassiere> [Edit] Thanx you Rodney
 Anyone know why teleports isnt sending messages?
 I am using WebTelegram rn because of this bug
 (Photo, 1027x369) https://irc.ubports.com/iyO3SL9s.png Hello I do not know what to do next to put your smartphone port onclite on the official site ubuntu touch do I received this message in the mail?
 (Photo, 1027x369) https://irc.ubports.com/B2SX0Rdf.png Hello I do not know what to do next to put your smartphone port onclite on the official site ubuntu touch. I received this message by email. What should I do next?
 nothing. it says it was merged
 (Photo, 1196x622) https://irc.ubports.com/PbEi2lrY.png When why did I not notice on the official website of my device Xiaomi Redmi 7 online https://devices.ubuntu-touch.io/
 (Photo, 1196x622) https://irc.ubports.com/DU1DOVXA.png When why did I not notice on the official website of my device Xiaomi Redmi 7 https://devices.ubuntu-touch.io/
 @supirlelik96 [<reply to media>], it doesn't appear immediately. i don't know what needs to be done next, but i guess all you need to do is just wait.
 @dohbee [it doesn't appear immediately. i don't know what needs to be done next, but i gu …], thank you
 @dohbee [it doesn't appear immediately. i don't know what needs to be done next, but i gu …], [Edit] thank you    I understood
 @amyosx [Anyone know why teleports isnt sending messages?], That was an issue related to draft messages. It got solved in v0.8.1 yesterday
[20:56] <ubptgbot> 👑 King 👑 was added by: 👑 King 👑
 @supirlelik96 unrelated to particular website issue, but did you publish everything needed to build it?
 last time I checked, there were no repos
 [Edit] last time I checked, there were no device repos
 @NotKit [last time I checked, there were no device repos], I don't know exactly but can you tell me what you need to do to get my port on the site


[00:31]  * babbageclunk goes for a walk
[02:06] <axw> jam: FYI, https://azure.microsoft.com/en-au/updates/ga-multiple-ips-per-nic/ & https://azure.microsoft.com/en-au/updates/dual-nic-support/
[02:18] <rick_h> axw: oooooh
[02:19] <axw> rick_h: :)
[02:19] <axw> rick_h: also, did you see there's SR-IOV support, so you can have moar faster mellanox networks
[02:19] <axw> rick_h: still in preview tho
[02:20] <rick_h> axw: no, I didn't. I get the summary emails from GCE and AWS but not from Azure. I need to find that I guess.
[02:21] <axw> rick_h: I'm not subscribed, I just stumbled across it. not sure where to subscribe to these sorts of things
[02:25] <rick_h> axw: https://cloud.google.com/newsletter/ and https://aws.amazon.com/new/ (via rss) are the things I follow I think
[02:25] <axw> rick_h: thanks. i'm on the google one already, prob should read aws too
[02:26]  * rick_h tries https://azure.microsoft.com/en-us/community/newsletter/subscribe/ to see if that'll send news
[02:51] <babbageclunk> wallyworld, axw - I'm assuming we don't rely on the name of the firewalls created by GCE to be the hash of the rules, it's just how we make them unique. Does that sound right?
[02:51] <wallyworld> babbageclunk: that's my understanding, but to change the algorithm would require upgrade steps
[02:51] <wallyworld> maybe
[02:51] <wallyworld> or at least compatibility code
[02:52] <axw> babbageclunk: no idea sorry
[02:52] <axw> that's what I would expect though
[02:55] <babbageclunk> wallyworld: I'm not changing the way the name's generated, just not updating it when we change the rules it contains (since it looks like that's not supported). The code finds firewalls by rules, not by relying on the name, so I don't *think* we'll need any upgrade steps.
[02:55] <wallyworld> that sounds ok
[03:37] <babbageclunk> wallyworld: easiest review ever: https://github.com/juju/juju/pull/7246
[03:38] <wallyworld> ok
[03:38] <babbageclunk> I mean, I guess I have seen 1-line PRs, so it could technically be easier
[03:43] <wallyworld> babbageclunk: sorry, was just otp. don't we need to rename the rule with the new hash so it can be found next time?
[03:44] <wallyworld> or so that the name matches the hash
[03:46] <babbageclunk> wallyworld: I don't think so - we don't find it by name, otherwise we wouldn't have been able to find existingFirewallName. You can see above in OpenPorts that it finds it by CIDR and/or port.
[03:48] <wallyworld> babbageclunk: ok, something is bothering me about having the name start out as a hash of the ports and then not being the hash. what happens if a new sec group is created with the old rules, there will be a name clash?
[03:49] <babbageclunk> wallyworld: hmm, I see what you mean.
[03:52] <babbageclunk> wallyworld: so in that case maybe we need to delete the firewall and add a new one? Although I guess that could kill connections. :(
[03:52] <wallyworld> babbageclunk: could do. can we rename a firewall?
[03:53] <babbageclunk> wallyworld: oh right - maybe as a separate call from updating its rules.
[03:53] <babbageclunk> wallyworld: reading some docs
[03:53] <wallyworld> ok
[04:20] <babbageclunk> wallyworld: I can't find any way to rename one.
[04:20] <wallyworld> babbageclunk: create new one and then delete old?
[04:21] <wallyworld> babbageclunk: or maybe just use a uuid type thing to generate a unique name up front and not tie to rules hash
[04:21] <babbageclunk> wallyworld: yeah, I was just about to say that
[05:24] <babbageclunk> wallyworld: ugh, using a random number requires stitching errors through and making the tests handle nondeterministic results. Do you think I should do the add and then delete thing instead? Feels a bit more fragile though
[05:25] <wallyworld> babbageclunk: you can mock out the name generation for the tests using a func that doesn't error
[05:25] <wallyworld> and that returns a deterministic result
[05:35] <babbageclunk> wallyworld: yeah, but there are are higher-level tests that also (incidentally) check the name because they're looking at calls.
[05:36] <babbageclunk> wallyworld: oh, you mean reassign the function in export_test?
[05:36] <wallyworld> something like that, or pass in as a dep, so the test can control the name generated
[05:39] <babbageclunk> wallyworld: yeah, I was passing it in as a dep (since I've seen people object to the rebinding), but it means that I need to pass it down multiple levels
[05:40] <babbageclunk> wallyworld: tempted to make the tests not look at the random bit of the name.
[06:30] <wallyworld> babbageclunk: sgtm
[06:31] <axw> jam: teeny review please? https://github.com/juju/gomaasapi/pull/69
[06:32] <jam> axw: I assume that information was always in the API response, even for older versions of MAAS?
[06:32] <axw> jam: yeah, and we use it when connecting to MAAS 1.x
[06:37] <jam> sgtm
[07:14] <wallyworld> axw: no rush, if you get a chance at some point https://github.com/juju/juju/pull/7239
[07:15] <axw> wallyworld: sure. pool leak dude is here, bbs
[07:15] <wallyworld> ouch, hope it's not too bad
[08:44] <axw> wallyworld: pool has been losing water for months, just recently got to 3-4cm each day. my regular pool guy was hopeless, had a few shots at finding the leak
[08:44] <axw> wallyworld: so called up a specialist and he found it in 30 minutes...
[08:44] <axw> wallyworld: haven't seen the invoice yet, hopefully that's not too special
[08:48] <wpk> $1 for hitting it with a hammer, $999 for knowing where to hit
[08:54] <axw> wpk: yeah, pretty much. except the guy who didn't solve the problem still charged $1000 (figuratively, not really that much)
[11:26] <wallyworld> axw: was it in a connecting pipe? or the pool itself?
[11:29] <anastasiamac> wallyworld: wow \o/ m just curious if it's fixed :D regardless of where it is.. altho the location would probably determine the price of work..
[11:39] <axw> wallyworld anastasiamac: bottom of the pool. he swam down and filled the crack with some type of glue/filler
[11:41] <anastasiamac> axw: niiice :) how old is the pool? some builders have extended warantees...
[11:41] <axw> anastasiamac: good question/idea. I don't know - I'll check later
[20:47]  * babbageclunk is popping out, back in a bit


[00:08] <Chipaca> not finished, will carry on tomorrow
[00:08] <Chipaca> off to zzz :-)
[00:54] <mup> PR snapd#4835 opened: tests: add bionic system to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4835>
[05:27] <zyga-ubuntu> Good morning
[06:07] <mborzecki> morning
[07:15] <zyga-ubuntu> re!
[07:15] <zyga-ubuntu> kids are handled, wife at work, dog is sleeping (again) and I can finally get to work :)
[07:19] <mborzecki> zyga-ubuntu: hey
[07:19] <zyga-ubuntu> hey :-)
[07:21] <mborzecki> zyga-ubuntu: so the kernel bug with dangling symlinks is real, quite a lot of these came up in your pr
[07:21] <zyga-ubuntu> yes, it's real
[07:21] <zyga-ubuntu> now it's unclear if it is related to the issues we saw
[07:21] <zyga-ubuntu> or if it is just a harmless issue
[07:22] <mborzecki> zyga-ubuntu: does it also appear in debian sid, or is this part of apparmor ubuntu specific?
[07:22] <zyga-ubuntu> I don't know
[07:23] <zyga-ubuntu> my gut feeling is that it's not specific to ubuntu
[07:25] <zyga-ubuntu> oops, I managed to get an appointment with a doctor at 11
[07:36] <zyga-ubuntu> good morning mvo
[07:36] <mvo> zyga-ubuntu: hey! good morning
[07:39] <mborzecki> mvo: hey
[07:39] <mvo> hey mborzecki
[07:39] <mvo> time for 2.32~rc2!
[07:43] <mvo> zyga-ubuntu: sorry for being a pain, what is the (rough) status of the layout fix we need for 2.32?
[07:44] <zyga-ubuntu> no change since last week, I know what the problem is and I worked on the first of the two problems (symlink problem) but put this on hold earlier this week
[07:44] <zyga-ubuntu> I'm adding unit tests
[07:44] <zyga-ubuntu> though I think I will be changing that code a little as well
[07:44] <mvo> zyga-ubuntu: thanks!
[07:44] <zyga-ubuntu> so the status is: known bugs, in progress
[07:44] <mvo> zyga-ubuntu: could we disable parts of the functionality to get there quicker? or is that a) stupid b) not-needed c) all of the above?
[07:45] <zyga-ubuntu> it's not worth it, we need the experimental feature flag anyway
[07:45] <mvo> zyga-ubuntu: aha, ok
[07:45] <zyga-ubuntu> the symlink bug is "don't make symlinks if one is in place and has good value"
[07:45] <zyga-ubuntu> the writability leak problem is "don't write over things that are not tmpfs"
[07:46] <mborzecki> hm the opensuse kernel that we use has apparmor disabled apparently
[07:46] <mborzecki> uname shows 4.15.7-x86_64-linode102, linode specific kernel?
[07:47] <zyga-ubuntu> yes, apparently
[07:47] <mvo> anyone working on the vet failures on 18.04? if not I will do now
[07:48] <mborzecki> damn, kernel-default-4.4.27-2.1.x86_64 this is installed, but it's running a different kernel, pfff
[07:48] <mborzecki> mvo: i can take a look
[07:49] <mvo> mborzecki: its about the vet failures in the test log of 4835
[07:50] <zyga-ubuntu> there are some people who want to contribute to the gentoo overlay
[07:50] <zyga-ubuntu> https://github.com/zyga/gentoo-snappy/issues
[07:50] <zyga-ubuntu> some PRs and issues
[07:50] <mup> PR snapd#4803 closed: snap-confine, snap-seccomp: utilize new seccomp logging features - 2.32 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4803>
[07:50] <mup> PR snapd#4831 closed: tests: force profile re-generation via system-key <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4831>
[07:51] <mup> PR snapd#4828 closed: many: support holding refreshes by setting refresh.hold (2.32) <Critical> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4828>
[07:52] <mvo> zyga-ubuntu: how safe is 4830?
[07:53] <mvo> zyga-ubuntu: I am inclinded to merge
[07:53] <zyga-ubuntu> I don't know of any issues
[07:53] <mvo> zyga-ubuntu: this runs in edge for some time, right?
[07:53] <zyga-ubuntu> yes
[07:53] <zyga-ubuntu> I think it's safe
[07:53] <zyga-ubuntu> also on reverts
[07:53] <zyga-ubuntu> since reverting brings the reverted snap-confine
[07:53] <zyga-ubuntu> and its own profile and startup behavior
[07:54] <zyga-ubuntu> the only potential downside is if we made a mistake in the apparmor profiles
[07:54] <mvo> ok
[07:54] <zyga-ubuntu> but nobody complained so far
[07:54] <mup> PR snapd#4830 closed: many: generate and use per-snap snap-update-ns profile (2.32) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4830>
[07:55] <zyga-ubuntu> mvo: hmmmm
[07:55] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/4765
[07:55] <mup> PR #4765: interfaces: harden snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4765>
[07:55] <zyga-ubuntu> actually, I'm drunk
[07:55] <zyga-ubuntu> since that PR you just merged is just the split of the profiles
[07:55] <zyga-ubuntu> this is the hardening
[07:56] <zyga-ubuntu> and this is the part when I meant that maybe we missed something
[07:56] <zyga-ubuntu> the first PR is safe
[07:56] <zyga-ubuntu> mvo: this PR is the interesting one that jamie wanted to see.
[07:56] <zyga-ubuntu> man, I thought we merged it already
[07:57] <zyga-ubuntu> and is full of policy
[07:57] <zyga-ubuntu> mvo: can you review it?
[07:58] <mvo> zyga-ubuntu: yes, in a bit, let me go over the essential bits for 2.32 first
[07:58] <zyga-ubuntu> mvo: I think this is also for 2.32 but I understand if you lack it
[07:58] <zyga-ubuntu> NACK it
[07:58] <zyga-ubuntu> (silly spellchecker on macOS)
[08:00] <kalikiana> moin moin
[08:01] <zyga-ubuntu> hey kalikiana
[08:03] <mup> PR snapd#4836 opened: tests: force profile re-generation via system-key <Created by mvo5> <https://github.com/snapcore/snapd/pull/4836>
[08:06] <pstolowski> morning!
[08:06] <mborzecki> kalikiana: pstolowski: morning guys
[08:07] <mborzecki> woow, we use testable examples in snap/info_test.go, never seen it being used before
[08:07] <mvo> mborzecki: we want 4826 - right?
[08:07] <mborzecki> mvo: for 2.32?
[08:07] <mvo> mborzecki: I mean we want it for 2.32
[08:07] <mvo> mborzecki: yes
[08:07] <mvo> pstolowski: good morning!
[08:08] <mborzecki> mvo: yes, it'd be nice to include it, it's a bugfix :)
[08:08] <mvo> pedronis: 4825 looks almost ready, just one question from gustavo left afaict?
[08:08] <mvo> mborzecki: cool, lets see if we can find a second reviewer
[08:15] <mvo> zyga-ubuntu: do we know how the feature flag will look like? environment key?
[08:16] <zyga-ubuntu> Core setting
[08:16] <zyga-ubuntu> snap set core experimental.layouts true
[08:16] <mborzecki> hmm vet does not handle struct methods defined in export_test.go files
[08:19] <mvo> zyga-ubuntu: do you have code for this or shall I add some? asking because I think with that in place ~rc2 would be ready
[08:20] <mvo> zyga-ubuntu: I can work on it
[08:29] <mborzecki> https://github.com/golang/go/issues/23701
[08:33] <zyga-ubuntu> mvo: I don't have that yet
[08:33] <zyga-ubuntu> so if you want to pick it up, thanks please do
[08:33] <mvo> mborzecki: hm, this reads as if the issue should be fixed? do we just need a golang update in bionic?
[08:34] <mborzecki> go version go1.10 linux/amd64 locally and i can still see this
[08:34] <mvo> zyga-ubuntu: yeah, I want 2.32~rc2 today if layout have bugs thats ok, we need one more upload for 2.32(-final) anyway
[08:34] <zyga-ubuntu> ack
[08:34] <mvo> mborzecki: hm, does that have https://go-review.googlesource.com/c/go/+/92215 ?
[08:36] <mborzecki> mvo: yes, the commit is in 1.10 branch
[08:37] <mvo> :(
[08:37] <mvo> ok
[08:37] <mvo> mborzecki: if you have a fix for the other vet issues, please push
[08:41] <mup> PR snapd#4837 opened: many: go vet cleanups <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4837>
[08:41] <mborzecki> mvo: ^^
[08:41] <mvo> mborzecki: \o/
[08:42] <mborzecki> as for the bug that's supposed to be resolved in 1.10, i can still reproduce it with the sample that's provided in the original ticket on both 1.10 from golang.org download and 1.10 from arch packages
[08:43] <mvo> mborzecki: ok, so we need to reopen upstream? and/or find a local workaround :/
[08:44] <mvo> and/or disable vet on go1.10 (which would suck)
[08:45] <mborzecki> i have a sort of a workaround but it's labor intensive :)
[08:45] <mborzecki> basically changing the struct methods to simple funcs
[08:46] <mborzecki> and update all call sites
[08:47] <mvo> mborzecki: hm, that sounds slightly nasty
[08:50] <Chipaca> moin moin
[08:51]  * Chipaca realises he still has time for more coffee before official start-of-day
[08:52] <mborzecki> mvo: it isn't that bad https://paste.ubuntu.com/p/ZPgmsKpM6s/
[08:53] <mborzecki> mvo: i can push that too
[08:53] <mvo> mborzecki: yeah, that looks reasonable
[08:53] <mvo> mborzecki: unfortunate but reasonable
[08:53] <mvo> Chipaca: hey! good morning!
[08:54] <mborzecki> Chipaca: morning, more coffee yes, that's a splendid idea :P
[08:54] <om26er> elopio: Hi! I see you did initial snap packaging for keybase client. Are there any blockers on the way, anyway I could help get that finished ?
[08:55]  * Chipaca hugs elopio
[08:56]  * Chipaca hugs his coffee, also
[08:58] <mborzecki> mvo: pushed the workarounds
[09:02] <mborzecki> need to run an errand, bb in ~1.5h
[09:27]  * zyga-ubuntu -> doctor
[09:27] <zyga-ubuntu> ttyl
[09:40] <mup> PR snapd#4838 opened: snapstate: put layout feature behind feature flag <Created by mvo5> <https://github.com/snapcore/snapd/pull/4838>
[09:57] <zyga-ubuntu> mvo: commented, thank you for writing that
[09:57]  * zyga-ubuntu waits at the doctors
[09:58] <zyga-ubuntu> This will take a while (hopefully not too long)
[10:04] <mvo> zyga-ubuntu: thank you
[10:08] <mvo> zyga-ubuntu: heh, spread tests> probably, I guess the spread run will be very unhappy!
[10:08] <mvo> zyga-ubuntu: good catch
[10:08] <Chipaca> mvo: can you remind me what advise-snap's supposed to do without --command?
[10:09] <mvo> Chipaca: advice on snap name
[10:09] <Chipaca> mvo: what's the apt equivalent of that one?
[10:09] <mvo> Chipaca: so that "apt install spotify" could say something nice like "The spotify snap is available at version 2.0, see snap info spotify for additional versions"
[10:09] <Chipaca> ah
[10:09] <Chipaca> a'ight
[10:09] <mvo> Chipaca: its a bit under speced right now
[10:09] <mvo> Chipaca: we also probably want mispell there
[10:09] <mvo> (which should be trivial)
[10:11] <Chipaca> speling is trivial indeed
[10:17] <Chipaca> we really struggle with 'temporarily'
[10:17] <Chipaca> so far i've found temporarely and temporariy
[10:23] <mvo> Chipaca: *cough* s/we/I/
[10:24] <zyga-ubuntu> mvo: I will miss standup. I need to do an X-ray now :-(
[10:25] <zyga-ubuntu> Not sure how soon I will be back today
[10:25] <zyga-ubuntu> I can work on reviews from my phone
[10:26] <mvo> zyga-ubuntu: uhh, good luck
[10:27] <pstolowski> yay, found a bug in go-udev
[10:27] <zyga-ubuntu> pstolowski: that was quick
[10:30] <pstolowski> zyga-ubuntu: it's a small project and just a few functions really. and fix is trival thankfully
[10:37] <Chipaca> huh, there's a new rpi
[10:38] <zyga-ubuntu> Yep
[10:38] <zyga-ubuntu> And it has a heat spreader on the chip
[10:38] <zyga-ubuntu> And does PoE with a hat
[10:38] <zyga-ubuntu> That latter thing makes it really interesting but there is no information about the availability of the hat yet
[10:39] <Chipaca> I didn't know Poe used a hat
[10:39]  * Chipaca imagines ravens with trilbies
[10:40] <Chipaca> anyway, bbiab
[10:51] <zyga-ubuntu> Chipaca it is a very stylish poe
[10:51]  * zyga-ubuntu waits for X-ray
[10:55] <mup> PR snapd#4839 opened: errtracker: respect the /etc/whoopsie configuration <Created by mvo5> <https://github.com/snapcore/snapd/pull/4839>
[11:02] <zyga-ubuntu> mvo: reviewed
[11:03] <abeato> mvo, it looks like the root reason for the bug we chatted around yesterday is device cgroups: https://forum.snapcraft.io/t/race-condition-between-snapd-and-nm-when-providing-permissions/4451/3
[11:03] <abeato> zyga-ubuntu, ^^
[11:03] <zyga-ubuntu> Hey
[11:03] <abeato> zyga-ubuntu, o/
[11:03] <zyga-ubuntu> I’m AFK so sorry if I don’t respond quickly
[11:04] <zyga-ubuntu> Let me read the forum thread
[11:04] <abeato> thanks
[11:04] <zyga-ubuntu> So a quick question
[11:04] <zyga-ubuntu> What created the additional device nodes
[11:05] <abeato> zyga-ubuntu, a script that needs to set some GPIO to power on the device. That takes a few seconds
[11:05] <zyga-ubuntu> It feels like we are missing an udev rule that adds tags such devices
[11:05] <zyga-ubuntu> Is it udev tagged by any part of network manager interface?
[11:05] <abeato> the udev rule is fine, it tags /dev/tty*
[11:06] <abeato> it is in the ppp interface, used by NM
[11:06] <zyga-ubuntu> Can you please paste the udev profile generates by snapd for this snap
[11:06] <abeato> sure
[11:06] <zyga-ubuntu> Thanks
[11:06]  * zyga-ubuntu only has a phone with him
[11:07] <abeato> zyga-ubuntu, https://pastebin.canonical.com/p/jGBrPdkZZq/
[11:08] <zyga-ubuntu> Aww
[11:08] <zyga-ubuntu> My token is at home
[11:08] <zyga-ubuntu> Is it sensitive?
[11:08] <abeato> zyga-ubuntu, nah, not really: https://paste.ubuntu.com/p/sGWRcj7Ts4/
[11:09] <abeato> who creates the device cgroup, snap-confine?
[11:09] <zyga-ubuntu> Yes
[11:10] <abeato> it would make sense that it adds only the present devices
[11:10] <abeato> and if a new one appears, apparmor rules are fine thanks to udev, but not the device cgroup
[11:10] <abeato> which is not updated
[11:11] <mborzecki> re
[11:11] <abeato> (well, not thanks to udev, it is just that apparmor has a tty*)
[11:13] <zyga-ubuntu> Re
[11:13] <zyga-ubuntu> Well it should be updated
[11:13] <zyga-ubuntu> Look at those rules
[11:13] <zyga-ubuntu> We run a tool to change the device cgroup as devices come and go
[11:14] <zyga-ubuntu> Unless we are hit by a bug
[11:14] <zyga-ubuntu> We renamed that tool now
[11:15] <abeato> hm then a bug must be
[11:15] <abeato> which is that tool?
[11:15] <zyga-ubuntu> Can you confirm it exists in your system with the given path you see in the udev rule
[11:15] <zyga-ubuntu> Read the rule please
[11:15] <zyga-ubuntu> It is raining
[11:15] <zyga-ubuntu> And typing on a phone is not easy
[11:16] <abeato> sure :)
[11:16] <abeato> ok, /usr/lib/snapd/snappy-app-dev
[11:19] <zyga-ubuntu> Yes
[11:19] <abeato> zyga-ubuntu, mvo is it possible that core in candidate has been recently upgraded? now I cannot reproduce the issue anymore, although it is a race so I am not 100% sure
[11:20] <mvo> abeato: candidate got updated on monday
[11:20] <mvo> abeato: from 2.31.1 to 2.31.2
[11:20] <abeato> hm...
[11:20] <mvo> abeato: http://people.canonical.com/~mvo/core-changes/html/candidate/2.31.1r4110_2.31.2r4206.html
[11:21]  * abeato trying to reproduce again
[11:23] <zyga-ubuntu> abeato: do you see this on core or on classic
[11:23] <abeato> core
[11:23] <zyga-ubuntu> I see
[11:23] <zyga-ubuntu> Hmm hmm
[11:23] <zyga-ubuntu> Well
[11:23] <zyga-ubuntu> If it shows up please tell us
[11:23] <abeato> yup
[11:24] <zyga-ubuntu> To the best of our knowledge the system supports devices that are added after startup
[11:24] <zyga-ubuntu> One possible thing to check for would be a race during cgroup construction
[11:24] <zyga-ubuntu> That may indeed be buggy
[11:24] <zyga-ubuntu> I would have to look at the code to confirm this
[11:25] <zyga-ubuntu> Perhaps the tool should be grabbing the per-snap lock
[11:25] <zyga-ubuntu> As that would probably rule out the race
[11:25] <abeato> I can control when the device is created, will tell you if I can reproduce that way in 1min
[11:25] <zyga-ubuntu> So to be clear
[11:26] <zyga-ubuntu> If the udev event fires at the same moment as the first process of that snap
[11:26] <zyga-ubuntu> We may have an issue in that specific case
[11:26] <zyga-ubuntu> Ok
[11:26] <zyga-ubuntu> I have my X-ray but results won’t be available till 4PM, I’m heading home
[11:30] <abeato> zyga-ubuntu, definitely I can reproduce (ping me when you are back again)
[11:31] <zyga-ubuntu> Do can you reproduce that and capture udev logs as things happen?
[11:31] <abeato> yes
[11:31] <zyga-ubuntu> Please add all findings to the forum thread
[11:32] <abeato> will do, thanks
[11:32] <zyga-ubuntu> And can you look at the resulting cgroup and ensure the devices are not there
[11:32] <zyga-ubuntu> I wonder if we can make the small helper tool log something
[11:32] <abeato> that's how I checked that I reproduced it :)
[11:33] <abeato> the new devices are not in devices.list
[11:33] <abeato> (and I got the EPERM too)
[11:33] <zyga-ubuntu> Ok
[11:34] <zyga-ubuntu> Which device is that? The serial port?
[11:34] <abeato>  /dev/ttyACM0 from a modem
[11:35] <mborzecki> abeato: is there any indication in dmesg that the port may go away and appear again?
[11:35] <zyga-ubuntu> The rule looks ol
[11:35] <zyga-ubuntu> Can you check one more thing
[11:35] <zyga-ubuntu> Run the tool as udev would
[11:35] <abeato> mborzecki, it appears and it is kept there
[11:36] <zyga-ubuntu> Pass the right tings (cannot tell you from the top of my head)
[11:36] <zyga-ubuntu> And see if it gets added
[11:36] <abeato> sure, let me try that
[11:39] <abeato> zyga-ubuntu, https://paste.ubuntu.com/p/hZFQ5XS62g/ :/
[11:40] <zyga-ubuntu> Woah
[11:40] <zyga-ubuntu> That looks like a bug
[11:40] <zyga-ubuntu> Is the tool anywhere in the filesystem?
[11:40] <abeato>  /lib/udev/snappy-app-dev
[11:40] <abeato> bad path
[11:40] <jjohansen> zyga-ubuntu: just a quick update before I bail, I have a patch thats is a wip, I should have something for you to test tomorrow (today?) sometime
[11:41] <abeato> zyga-ubuntu, so there is a bad path in the udev rule, that's it
[11:41] <zyga-ubuntu> That is great news jjohansen. Thank you for getting this so quickly! I can test the patch when you have it
[11:42] <zyga-ubuntu> Mvo: we need a small fix for what abeato just found
[11:42] <zyga-ubuntu> abeato: which version is that?
[11:42] <abeato> zyga-ubuntu, 4209
[11:43] <zyga-ubuntu> And in snap —version parlance?
[11:43] <mvo> zyga-ubuntu: oh, what fix is needed?
[11:43] <zyga-ubuntu> jjohansen: is there any indication that the bug may have other side effects?
[11:43] <abeato> zyga-ubuntu, https://paste.ubuntu.com/p/tWkMJRP84Y/
[11:43] <zyga-ubuntu> mvo: udev rules use a wrong path to the helper tool
[11:44] <zyga-ubuntu> Woah
[11:44] <abeato> mvo, /usr/lib/snapd/snappy-app-dev -> /lib/udev/snappy-app-dev
[11:44] <zyga-ubuntu> abeato your snapd is wonky
[11:44] <zyga-ubuntu> Can you reproduced that on vanilla 2.31.2
[11:44] <zyga-ubuntu> I will be home soon
[11:44] <zyga-ubuntu> ~40 minutes maybe
[11:45] <mvo> abeato: this is slightly strange, the snapd version is pretty out of sync with the snap version
[11:45] <zyga-ubuntu> (That not super soon though)
[11:45] <abeato> zyga-ubuntu, mvo well, it is the core from candidate, no hacks I promish
[11:45] <zyga-ubuntu> That is cery ul ujęły
[11:45] <zyga-ubuntu> Unlikely
[11:46] <zyga-ubuntu> Did you push a locally built snapd over?
[11:46] <mvo> abeato: when I grep snappy-app-dev in master I get only a compat symlink hit, I'm a bit puzzled why its looking in /usr/lib/snapd/snappy-app-dev, is that in the udev rule? or where do you see it?
[11:47] <zyga-ubuntu> It is in the udev rule but it looks like the snapd there is old or at least based on an old dirty build
[11:48] <abeato> zyga-ubuntu, hm, wait, I remember I pushed one snapd and mounted it on boot to measure a performance issue
[11:48] <abeato> let me remove that
[11:48] <zyga-ubuntu> Thank you!
[11:56] <mup> PR snapd#4840 opened: many: add `core.problem-reports.disabled` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/4840>
[11:56] <mborzecki> heh, go vet is flaky in 1.10 and even more so in master, this is what I get with master atm: https://paste.ubuntu.com/p/B2vc9F3CGr/ using a test case https://github.com/golang/go/issues/23701#issuecomment-363187224
[11:57] <mvo> mwhudson: hm, do you have an opinion about go vet in bionic? we have some problems with 1.10 -^
[11:57] <mvo> mborzecki: maybe the default of 1.10 is a bit too aggressive :/
[11:58] <mborzecki> there will be an update to 1.10.1 though?
[11:58] <mborzecki> i think i'd prefer a slightly broken version if that helps from getting stuck with 1.9 for the next 5 years
[11:59] <mvo> mborzecki: I guess, worst case is that we disable vet on 1.10 for now
[11:59] <mborzecki> mvo: the workarounds are there, we can revert them once we know it's fixed again
[11:59] <abeato> zyga-ubuntu, mvo after reverting the snapd version I see the right path in /etc/udev/rules.d/70-snap.network-manager.rules, so this was my fault. Sorry for the noise
[12:01] <mvo> mborzecki: aha, ok. I thought you mentioned there are additional errors, am I outdated :) ?
[12:01] <mvo> abeato: no worries, thanks for reporting it, better this way than if we let a bug escape :)
[12:02] <abeato> at least I've learned a bit about device cgroups ;)
[12:02] <mborzecki> mvo: i mean i tried go master, built it and was able to reproduced the problem using a test case posted in the original ticket, got a nice backtrace from go internals :P at least 1.10 did not panic
[12:04] <zyga-ubuntu> abeato: thank you for confirming that!
[12:04] <zyga-ubuntu> mvo: alarm is over :)
[12:05] <abeato> zyga-ubuntu, thank you in fact
[12:08] <zyga-ubuntu> and I'm back
[12:08] <zyga-ubuntu> resuming work on fixes
[12:08] <mvo> mborzecki: ok
[12:08] <mvo> zyga-ubuntu: thank you for handling it!
[12:26] <mup> PR snapcraft#1983 closed: snap: update revision of patchelf to use <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1983>
[12:54] <mup> PR snapd#4841 opened: snap/pack, cmd/snap: add `snap pack --check-skeleton` <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4841>
[13:39] <zyga-ubuntu> Chipaca: would you mind if I bother you with a symlinkat review later today?
[13:39] <pstolowski> niemeyer: that's the project I was referring to: https://github.com/pilebones/go-udev
[13:39] <niemeyer> pstolowski: Yeah, that's one I looked into as well, given my browsing history
[13:39] <niemeyer> pstolowski: Looking for others now
[13:40] <Chipaca> zyga-ubuntu: yes, I'd be very upset with myself if you asking me for a review bothered me
[13:43] <Chipaca> niemeyer: wrt the 'halp' pr (#4809) your comments on 'snap pack' seem to imply you want a change of behaviour of snap pack
[13:43] <mup> PR #4809: cmd/snap: tweak and polish help strings <Created by chipaca> <https://github.com/snapcore/snapd/pull/4809>
[13:43] <niemeyer> Chipaca: Hmm.. it wasn't intentional at least
[13:43] <niemeyer> Chipaca: What did I miss?
[13:43] <Chipaca> i won't be working on that pr until this evening so there's no rush, but
[13:43] <Chipaca> niemeyer: 'snap pack' already defaults both arguments to '.'
[13:43] <niemeyer> Chipaca: Huh, ok
[13:44] <niemeyer> Chipaca: So what's the delta with try?
[13:44] <niemeyer> Chipaca: That it doens't look for "prime"?
[13:45] <Chipaca> niemeyer: essentially yes, but also it only sets it to . if there's a meta/snap.yaml in .
[13:45] <Chipaca> and it only sets it to prime if there's a snapcraft.yaml in one of the usual places
[13:45] <niemeyer> Chipaca: Okay, I indeed missed those details.. so +1 on your suggestion
[13:45] <Chipaca> (curiously it doesn't look for meta/snap.yaml in the prime directory, but that's a tweak)
[13:46] <niemeyer> Chipaca: I think we should ignore snapcraft.yaml and just look for meta/snap.yaml as you suggest
[13:46] <Chipaca> niemeyer: it's still slightly awkard that it'll happily drop a snap inside the snap (and there are snaps with snaps in them in the store, so it's a real problem)
[13:46] <niemeyer> (in prime, in .)
[13:46] <niemeyer> Chipaca: Is there a way to make snap pack ignore those?
[13:47]  * niemeyer --help
[13:47] <Chipaca> niemeyer: not currently; snapcraft has an ignore list, but not snap pack
[13:48] <Chipaca> OTOH most people will be using it via snapcraft so it'll be fine :-)
[13:48] <Chipaca> anyway, glad that's cleared up, i'll tweak the text and the behaviour (but possibly in a followup)
[13:48] <Chipaca> this evening though; now to the cache
[13:49] <Chipaca> hm, maybe, maybe target should default to the parent dir of snap-dir
[13:49] <mborzecki> Chipaca: or soem /tmp location
[13:50] <Chipaca> mborzecki: it might not be the best example, but dpkg-buildpackage plops the debs in ..
[13:50] <niemeyer> Chipaca: Yep, -e works
[13:50] <niemeyer> Chipaca: Although it's completely undocumented apparently
[13:50] <niemeyer> Chipaca: -e <filename>
[13:50] <niemeyer> Chipaca: I suggest using that for any *.snap in the root directory
[13:50] <Chipaca> niemeyer: fair 'nuff
[13:51] <niemeyer> Chipaca: I've seen actual snaps shipping the prior revision of their own snaps
[13:51] <Chipaca> niemeyer: IKR
[13:51] <niemeyer> Chipaca: Built with snapcraft
[13:51] <niemeyer> So it looks like a common issue
[13:52] <niemeyer> In the rare circumstances where people do want to ship snaps, they can just put it in a subdir
[13:53] <Chipaca> niemeyer: https://i.imgflip.com/26d5u0.jpg
[13:53] <niemeyer> Yeah :)
[13:53]  * Chipaca forgets the whole conversation and moves to the hash cache stash
[13:57] <cachio> mvo, I have tried the upgrade test issue with the last bionic image in google and I see the same problem
[13:57] <cachio> all the snaps appear as broken
[13:58] <cachio> mvo, any idea?
[13:58] <cachio> I could get a debug session with the error
[14:03] <Chipaca> my / has inode number 2
[14:03] <Chipaca> how
[14:03]  * Chipaca doesn't really care and gets back to work
[14:04] <mvo> cachio: yeah, happy to get into  a debug session
[14:04] <mvo> cachio: what did you run to trigger it?
[14:05] <cachio> mvo, https://github.com/snapcore/snapd/pull/4835
[14:05] <mup> PR #4835: tests: add bionic system to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4835>
[14:05] <cachio> this branch
[14:05] <cachio> mvo, but using this image
[14:05] <cachio> ubuntu-os-cloud-devel/daily-ubuntu-1804-bionic-v20180307
[14:05] <cachio> which is the last one
[14:05] <cachio> mvo, nad run spread -debug google:ubuntu-18.04-64:tests/upgrade/basic
[14:31] <mborzecki> mvo: I'll close #4597 if you don't mind
[14:31] <mup> PR #4597: snapstate: allow core config via $core <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4597>
[14:39] <mvo> mborzecki: ok, hope some of the code will still be useful for your work in this area
[14:40] <mborzecki> mvo: yes, i'll pull in your commit and work on top of it
[14:42] <mup> PR snapd#4597 closed: snapstate: allow core config via $core <Blocked> <Created by mvo5> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4597>
[14:43] <mvo> mborzecki: \o/
[14:44] <mup> PR snapd#4842 opened: interfaces: make hash of apparmor profile for snap-confine in core part of the system-key <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4842>
[14:44] <mvo> ^- this is to test the theory that the system-key needs extending to get rid of the errors we saw with 2.32 and the out-of-sync of the profiles, please ignore until green
[14:44] <zyga-ubuntu> mvo: interesting
[14:45] <mvo> zyga-ubuntu: yeah, it usually this is covered by the core rev but not in our tests
[14:45] <mvo> zyga-ubuntu: lets see if its green or not
[15:02] <kyrofa> Hey Chipaca, if/when you're able, can I get a sanity check review from you on a snapcraft PR? We're adding the ability to call functions from scriptlets which are then handled by the running Snapcraft instance, and we're doing it via fifos: https://github.com/snapcore/snapcraft/pull/2002
[15:03] <mup> PR snapcraft#2002: pluginhandler: add builtin functions to scriptlets <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2002>
[15:03] <Chipaca> kyrofa: fifos, as in fifo(7)?
[15:04] <kyrofa> Yessir
[15:05] <kyrofa> Relevant parts of the PR are python (https://github.com/snapcore/snapcraft/pull/2002/files#diff-313e8dc0aa8d02f56e6ec918c25ddd93R74) and shell (https://github.com/snapcore/snapcraft/pull/2002/files#diff-8b247ab4b649deb9ee488e09837eba39R30)
[15:05] <mup> PR snapcraft#2002: pluginhandler: add builtin functions to scriptlets <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2002>
[15:19] <kyrofa> Wonder if it would be simpler with a more snapctl-like approach
[15:23] <Chipaca> kyrofa: what does the 'status' variable get used for?
[15:23] <kyrofa> Chipaca, to block
[15:23] <kyrofa> Until the function has been handled
[15:23] <kyrofa> Otherwise once the "call" fifo has been read, the scriptlet goes on its merry way
[15:25] <Chipaca> kyrofa: does this work?
[15:26] <kyrofa> Chipaca, in my testing anyway, yeah. Do you see issues?
[15:26] <Chipaca> kyrofa: only things that seem strange but they might be connected outside of my limited window into the code
[15:26] <Chipaca> like, cwd of the popen is not tempdir
[15:27] <Chipaca> but it finds the fifos
[15:27] <Chipaca> ?
[15:27] <kyrofa> The fifos are an absolute path, handed to the script run by the popen
[15:28] <Chipaca> ah :-)
[15:31] <Chipaca> hmmm
[15:33] <Chipaca> kyrofa: another question: why nonblocking?
[15:34] <kyrofa> Chipaca, on the Python side? So that the scriptlet can actually exit and Snapcraft can move on even if they don't utilize the fifos
[15:34] <kyrofa> Otherwise Snapcraft will block checking for a function call, and the scriptlet will exit in the meantime
[15:41] <Chipaca> kyrofa: i'm having trouble hitting that failure mode
[15:41] <cachio> Pharaoh_Atem, hey
[15:42] <cachio> Pharaoh_Atem, do you haave time to continue with the dbus test?
[15:42] <Pharaoh_Atem> cachio: I will in ~20 minutes
[15:42] <cachio> Pharaoh_Atem, great, thanks
[15:43] <cachio> Pharaoh_Atem, I'll prepare the environment in that case
[15:43] <Chipaca> kyrofa: granted my code is a butchering of yours just to test it (mostly because my experience with fifos is that they are finickity)
[15:45] <kyrofa> Chipaca, that's exactly the kind of info I was hoping you'd have! This approach does not give you warm and fuzzies, then?
[15:45] <Chipaca> kyrofa: it can work, and when it does it's brilliant
[15:45] <Chipaca> kyrofa: and most of my bad experiences have been around things deadlockinig, which the nonblocking thing should avoid? I think
[15:45] <Chipaca> if i understand it correctly at least
[15:46] <kyrofa> Indeed. But your hacking is confusing, let me try removing the non-blocking and see if I can get it to fail like I expect, hold on
[15:46] <Chipaca> but, with it nonblocking you do end up spinning quite a bit
[15:46] <kyrofa> Yeah totally
[15:46] <kyrofa> It's not beautiful
[15:50] <kyrofa> Yeah Chipaca remove ` | os.O_NONBLOCK` in `_NonBlockingFifo` and then run a YAML that looks like this: https://pastebin.ubuntu.com/p/V2tZ7GfzBn/
[15:50] <kyrofa> Whereas, if you add a `snapcraft_build` call to the bottom of the `build` scriptlet, things start working again since you wrote to the fifo to unblock snapcraft
[15:54]  * zyga-ubuntu goes to pick up xray results, ttyl
[15:55]  * Chipaca plays with this
[16:02] <cachio> Pharaoh_Atem, env ready
[16:03] <Chipaca> kyrofa: I'm not seeing it getting blocked
[16:03] <kyrofa> Huh. I can't explain that
[16:03] <Chipaca> kyrofa: https://pastebin.ubuntu.com/p/xpPwjyvKQS/
[16:04] <Chipaca> that's with O_NONBLOCK commented out
[16:06] <Chipaca> kyrofa: but it might not be picking up my changes
[16:06] <kyrofa> Chipaca, how do you have it installed?
[16:06] <kyrofa> venv?
[16:07] <Chipaca> kyrofa: i don't, i'm running it from the git repo + venv
[16:07] <Chipaca> i don't think i installed it to the venv
[16:07]  * Chipaca checks
[16:07] <Chipaca> dangit
[16:07] <Chipaca> yes it's there
[16:07] <kyrofa> And it's installed into the venv with --editable ?
[16:07] <Chipaca> there we go
[16:08] <kyrofa> Oh phew
[16:08] <Chipaca> kyrofa: somehow doing 'pip install -r requirements.txt .' (as per HACKING) also installed snapcraft itself
[16:08] <Chipaca> i guess that's the . there :-)
[16:09] <kyrofa> Indeed. Although below is the guide for actually _developing_ using that method, which requires --editable
[16:09] <kyrofa> Although even that falls on its face sometimes
[16:09] <kyrofa> Every once in a while I need to reinstall it and I never know why
[16:10] <Chipaca> kyrofa: is there a way to tell it to do a clean and then a build?
[16:10] <kyrofa> snapcraft clean && snapcraft build
[16:10] <Chipaca> or to jfd a build?
[16:10] <Chipaca> eh, fair enough
[16:16] <pstolowski> Chipaca: thanks for staying vigiliant with serial-port interface regexp... completely overlooked what you spotted!
[16:17] <Chipaca> pstolowski: no
[16:17] <Chipaca> pstolowski: np*
[16:17] <Chipaca> :-)
[16:17] <Chipaca> kyrofa: i need to go for a bit, but i'll carry on looking when ig et back
[16:17]  * Chipaca afk
[16:18] <pstolowski> Chipaca: it looked very innocent :}
[16:18] <kyrofa> Chipaca, of course, I appreciate your time!
[16:42] <cachio> Pharaoh_Atem, there?
[16:53] <Chipaca> pstolowski: IKR, I wouldn't've noticed if the regexp hadn't been blatently wrong
[16:53] <Chipaca> kyrofa: *blush*
[17:10] <popey> When do we plan to have overlay support landed?
[17:11] <jjohansen> zyga-ubuntu: no, no indication that the bug has other side effects (well it will break LXD checkpoint/restore). The symlink isn't getting properly updated on profile replacement, to point to the new blob.
[17:22] <Chipaca> kyrofa: does this code need to run on non-linux?
[17:23] <kyrofa> Chipaca, I don't believe so, no
[17:29] <Chipaca> kyrofa: my suggestion about O_RDRW is non-portable, you see :-)
[17:29] <kyrofa> Chipaca, are FIFOs portable?
[17:30] <Chipaca> kyrofa: not to cp/m, dos, nor derivatives
[17:30] <Chipaca> :-)
[17:31] <Chipaca> kyrofa: but to unices yes
[17:48]  * kalikiana heading out o/
[18:01] <Chipaca> niemeyer: question about the approach to the cache
[18:03] <Chipaca> niemeyer: currrently asserts.SnapFileSHA3_384 calls osutil.FileDigest to get the digest and then asserts.EncodeDigest to format it (prepend sha3-384: etc)
[18:04] <niemeyer> Chipaca: Ok
[18:04] <Chipaca> niemeyer: writing osutil.GetPathInfo, I can either make it receive a hasher (the caller would then wrap and pass in SnapFileSHA3_384), or i could move SnapFileSHA3_384 and EncodeDigest to osutil, or I could move GetPathInfo to asserts (or elsewhere)
[18:05] <Chipaca> niemeyer: the disadvantage of the hasher is that it makes it awkward to add more 'expensive' stuff, if everything is passed in
[18:05] <Chipaca> but otherwise it seems fine
[18:07] <Chipaca> niemeyer: so the question is, which approach do you think is best?
[18:07] <niemeyer> Chipaca: Yeah, I think it should compute internally to make it convenient.. I'm just wondering if it's a bit of a weak design in that if we introduce further hashes, we'll probably want to read the file only once to do them all, instead of asking N hashing functions to each compute it again
[18:08] <niemeyer> Chipaca: So perhaps neither? Where is the real sha3 algo living?
[18:08] <Chipaca> niemeyer: which is the 'real sha3'
[18:08] <niemeyer> Chipaca: The thing that computes the sha3 digest given bytes
[18:08]  * niemeyer digs in
[18:09] <Chipaca> niemeyer: osutil.FileDigest takes a generic crypto.Hash
[18:09] <niemeyer> Chipaca: That's good.. we can cook a crypto.Hash which is actually multiple hashes easily, I suppose
[18:10] <niemeyer> Chipaca: So the answer to my question above is golang.org/x/crypto/sha3
[18:11] <Chipaca> fwiw I think I need a thing that takes an io.Reader, not bytes
[18:11] <Chipaca> but that's minor
[18:11] <Chipaca> (otoh it's easy to multiplex readers to do multiple hashes)
[18:12] <niemeyer> Chipaca: I suggest leaving asserts alone for now and just doing the low-level thing inside osutil, leveraging crypto/sha3 directly
[18:12] <niemeyer> Chipaca: The cache can keep bytes too
[18:13] <niemeyer> Chipaca: DeriveSideInfo can return the actual bytes too, unencoded
[18:14] <mup> PR snapd#4843 opened: interfaces/builtin: let MM change qmi device attributes <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/4843>
[18:14] <niemeyer> Chipaca: FWIW, if we find a need to reuse EncodeDigest later, it should probably live inside strutil
[18:14] <Chipaca> niemeyer: I _think_ i understood what you meant :-)
[18:15] <Chipaca> niemeyer: basically make SnapFileSHA3_384 call osutil.GetPathInfo instead of osutil.FileDigest to get the digest
[18:15] <Chipaca> i think that'll work, because i think everything uses that to get the hash
[18:16] <Chipaca> i'll double check and report back if it's otherwise
[18:16] <niemeyer> Chipaca: I don't think that will work
[18:16] <Chipaca> niemeyer: then i didn't understand what you meant
[18:16] <niemeyer> Chipaca: Well, or maybe it will, if we reuse the StateCache type there as well
[18:17] <Chipaca> ah, because it doesn't have the state :-/
[18:17] <niemeyer> Chipaca: The original suggestion was to *return* the digest, but I guess your solution is cleaner actually
[18:17] <Chipaca> heh
[18:17] <Chipaca> niemeyer: the problem is what is 'the digest'
[18:17] <Chipaca> all these functions return 'the digest'
[18:17] <niemeyer> Chipaca: Right.. but we can pass in the state as a StateCache interface as well
[18:17] <Chipaca> it's just … different digests
[18:17] <Chipaca> :-)
[18:18] <niemeyer> Chipaca: DeriveFooBar doesn't return any digests today
[18:18] <Chipaca> niemeyer: i never mentioned DeriveFooBar
[18:18] <Chipaca> ;-)
[18:18] <niemeyer> Chipaca: I did, both in the call and above
[18:18] <niemeyer> "Chipaca: DeriveSideInfo can return the actual bytes too, unencoded"
[18:19] <niemeyer> Chipaca: This is the actual function that performs the digest inside firstboot
[18:20] <Chipaca> niemeyer: yes, but i'm not sure what the bytes would be useful for
[18:20] <niemeyer> Chipaca: To cache them
[18:20] <niemeyer> Chipaca: But... you're right
[18:21] <Chipaca> i hate being right before understanding the thing
[18:21] <Chipaca> :-)
[18:21] <Chipaca> probably a bit late in the day for me
[18:21] <niemeyer> Chipaca: It's cleaner to pass the StateCache in as an interface, and call GetPathInfo inside it
[18:22] <niemeyer> Chipaca: Perhaps osutil.ComputePathInfo instead
[18:22] <niemeyer> Chipaca: So callers realize this is not a trivial op
[18:22] <Chipaca> niemeyer: HoldOnToYourTrowsersWereGoingToGetPathInfo
[18:22] <Chipaca> :-p
[18:22] <niemeyer> Even better :P
[18:23] <Chipaca> yeah the name was a this-thing-needs-a-name token one, not the actual thing
[18:23] <Chipaca> ComputePathInfo it is
[18:24] <Chipaca> and, eod for a while (probably be back later to play with help strings)
[18:25] <niemeyer> Chipaca: Enjoy
[20:04] <mup> PR snapd#4837 closed: many: go vet cleanups <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4837>
[20:15] <cachio> niemeyer, could you please take a look to this one? https://github.com/snapcore/spread/pull/52
[20:15] <mup> PR spread#52: Add storage option for google <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/52>
[20:17] <cachio> it is making fail the ubuntu-16.04-32 on google
[21:02] <Chipaca> niemeyer: ping
[21:21] <mup> Issue snapcraft#1659 closed: Implement support for supported bases <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1659>
[21:21] <mup> PR snapcraft#1993 closed: core: initial support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1993>
[21:23] <niemeyer> Chipaca: Hyea
[21:23] <Chipaca> niemeyer: noodling around with this stuff, it looks like I should give PathInfos a Rename
[21:23] <Chipaca> niemeyer: at which point I'm not sure PathInfo is the right name for the beast
[21:24]  * Chipaca goes back to noodlin' and lets niemeyer worry about names
[21:24] <niemeyer> Chipaca: I'm not sure about what other name might be appropriate though.. we're effectively associating a bag of knowledge with a particular path
[21:27] <Chipaca> niemeyer: HashedFile?
[21:27] <Chipaca> eh, probably not or it'll grow Open() and stuff
[21:28] <Chipaca> and I guess Rename is actually a method of the hash cache, not the path info
[21:28] <Chipaca> hrmph
[21:29] <Chipaca> (the rename thing is because in quite a few places (at least two so far :-) ) we hash just before moving the file_
[21:29] <Chipaca> the download with deltas path is really interesting
[21:29] <Chipaca> apply delta hashes the composed file to make sure it's ok
[21:30] <Chipaca> and if so it's treated like a complete partial
[21:30] <Chipaca> so it's hashed to make sure it's ok
[21:30] <mup> PR snapcraft#2003 opened: patches: make the ctypes patch more robust and add armhf arch triplet <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2003>
[21:31] <Chipaca> and that's in store, before hashing it to make sure it's ok
[21:31] <Chipaca> :-)
[21:40]  * cachio afk
[21:55] <niemeyer> Chipaca: Renaming the path info doesn't sound too bad
[21:55] <Chipaca> niemeyer: yeah, i was originally thinking of having it do the actual rename
[21:55] <Chipaca> but it'll just rename the cache and be happy
[21:55] <niemeyer> Chipaca: The association is still with the path, and it's not just a hash.. we want mtime, size, etc, as well
[21:55] <niemeyer> Chipaca: Ah, agreed.. it should act just on the cache
[21:57] <mup> PR snapcraft#2004 opened: errros: add a specific error when running commnds from plugins <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2004>
[23:23] <cachio> niemeyer, hey
[23:23] <niemeyer> cachio: Heya
[23:24] <cachio> niemeyer, when you have 5 minutes, could you please take a look to https://github.com/snapcore/spread/pull/52 ?
[23:24] <mup> PR spread#52: Add storage option for google <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/52>
[23:24] <cachio> niemeyer, I have 1 PR waiting for this change
[23:25] <niemeyer> ACk
[23:25] <cachio> niemeyer, tx
[23:28] <cachio> niemeyer, something else
[23:28] <cachio> niemeyer, I see https://paste.ubuntu.com/p/2Wd5dQX6WS/ after a reboot in debian 9 in google
[23:29] <cachio> it is like spread tries to connect and for some reason pam is closing the session for the root
[23:29] <cachio> the sshd config is the same we have in linode
[23:29] <cachio> did you see that before?
[23:44] <mwhudson> um
[23:44] <mwhudson> subiquity is failing to start in a live cd with "cannot create user data directory"
[23:44] <mwhudson> what can possibly have changed since this worked yesterday
[23:49]  * cachio eod


[06:32] <sakhi> moonin
[07:18] <inetpro> good morning
[07:22] <superfly> morning, inetpro and sakhi
[07:24] <bmg505> good morning, in another 2 hours my 5 day holiday starts
[08:56]  * Symmetria begins his crusade against rpki in the defense of internet freedom and autonomy
[08:57] <tumbleweed> superfly: disabling your ubuntu-za drupal cronjob fro now.
[08:57]  * nlsthzn watches in interest, having no clue what he sees but enjoying  it non the less
[09:02] <Symmetria> heh, nlsthzn there are proposals in the works in the global internet community that if implemented would hand governments a rather effective internet kill switch
[09:02] <Symmetria> and the ability to very easily shut off entire isps, countries or sections of the internet
[09:02] <Symmetria> they are *EXTREMELY* dangerous proposals backed by some extremely nasty agendas on the back end, agendas which have been fairly well hidden up till now
[09:03] <Symmetria> trust me, life is about to get very very very interesting going forward
[09:03] <nlsthzn> he who holds the switch, holds the power... sounds like America is up to no good again
[09:03] <Symmetria> heh, its worse than just the americans
[09:04] <Symmetria> this would create a situation where if two countries went to war, the one country could turn off the other country :P
[09:04] <Symmetria> it would create a situation where through some simple court orders, a government could decide that only its isp could actually function
[09:05] <Symmetria> its... nasty
[09:05] <Symmetria> and the implications and ramifications of the proposed policy are being very well hidden, the proponents of it with their agendas are playing up the positives rather effectively
[09:07] <nlsthzn> Well, good luck with your crusade!
[10:11] <bmg505> well actually those laws are in place for telephone calls and mail and packages and even humans, so its logical that it will also happen for the internet, it does not make it right though but it does put it in perspective
[12:08] <tumbleweed> nice job WA, http://ftp.wa.co.za/pub/debian/
[12:10] <cocooncrash> Hah
[12:11] <tumbleweed> that debian thing, nobody uses it, right? :)
[12:11] <superfly> nope, no one
[12:11] <superfly> :-P
[12:11] <linuxboy> ubuntu does
[12:11] <tumbleweed> nobody will miss it then
[12:11] <linuxboy> not often though
[12:12] <froztbyte> #glug.za/freenode.#glug.za.2011.02.log:1235:2011-02-09 16:19:47<+froztbyte> have WA figured out how to run a mirror yet?
[12:12] <froztbyte> tumbleweed: ^
[12:12] <tumbleweed> froztbyte: I've been trying to educate them...
[12:12] <tumbleweed> they seem to have worked out how to keep thier mirror in sync (although that could be luck)
[12:12] <superfly> tumbleweed: did you try lots of pretty pictures in a powerpoint presentation? :-P
[12:12] <tumbleweed> this is a new era of sillyness
[12:15]  * sakhi thinks wa DSL console should be https.
[12:18] <linuxboy> sakhi: did you see clug when someone bitched about them putting the username/password in the URL?
[12:18] <cocooncrash> sakhi: You can use HTTPS.
[12:21] <linuxboy> http://lists.clug.org.za/pipermail/clug-chat/2008-February/024451.html
[12:21] <sakhi> linuxboy: nope I didn't see that post.
[12:22] <linuxboy> sakhi: happened in 2008
[12:26] <sakhi> cocooncrash: I think that page should be forced to https if it is apache webserver (not sure how you do in IIS)
[12:27] <sakhi> its good that it is encryped though.
[12:32] <superfly> yeah, I think half their problem is probably IIS and ASP.NET :-P
[12:32] <linuxboy> and the other half are some of the people who manage them?
[13:10] <superfly> no doubt :-P
[14:22] <marcog> Symmetria: any eta on resolving uct's international issues?
[15:47] <Symmetria> marcog, uct is on drugs
[15:47] <Symmetria> there was no problem from tenet's side with international
[15:47] <Symmetria> if there is a problem, its internal
[15:47] <Symmetria> and I told them this, 4 times
[15:47] <froztbyte> it's always someone else if they don't know what the problem is
[15:48] <froztbyte> we've got the same thing from our clients when they're unable to resolve their internal network issues
[15:48] <froztbyte> "must be supplier!!"
[15:48] <marcog> Symmetria: you mean icts then, sigh
[15:50] <froztbyte> see the part where inability to solve problems was mentioned
[15:50] <Symmetria> marcog heh, if you look at the total seacom bandwidth today, there was never a drop off in traffic
[15:50] <marcog> Symmetria: uct's internet *is* fucked though, whatever the cause
[15:50] <Symmetria> there was a problem with international graphing because at one point we were running without the bandwidth control system (which actually means, all limits and restrictions were not in effect, which would have sped things up, not slowed them down)
[15:51] <Symmetria> yeah I see you're running at a peak of only around 150mbit
[15:51] <Symmetria> and a peak national at around 220
[15:51] <Symmetria> which is kinda low
[15:51] <Symmetria> chances are their proxies arent handling
[15:51] <marcog> it does indeed seem to be proxy issues
[15:51] <marcog> cause when i tunnel, there are no problems
[15:52] <Symmetria> heh students back today?
[15:52] <marcog> yes!
[15:52] <marcog> :(
[15:52] <Symmetria> proxies probably getting raped
[15:52] <Symmetria> because bandwidth isnt the issue
[15:52] <froztbyte> what hardware do their proxies run on?
[15:52] <Symmetria> I warned them about this
[15:52] <Symmetria> froztbyte you dont wanna know :)
[15:53] <froztbyte> why?
[15:53] <Symmetria> :P well, start by asking what operating system/proxy serverthey use
[15:53] <froztbyte> oh dear
[15:54] <froztbyte> I suppose we shouldn't go down this road
[15:54] <froztbyte> we've done a gigabit of live traffic across a cluster setup of our caches in testing before, so we know we can handle it
[15:54] <froztbyte> and we've got some updates coming over the next few weeks which push our capacities even further
[15:54] <froztbyte> but yeah...
[15:58] <froztbyte> what are they, bluecoat?
[16:02] <Symmetria> froztbyte microsoft isa
[16:03] <Symmetria> and apparently they are busy prepping 4 new boxes to add to the cluster
[16:05]  * froztbyte sadpandas
[16:27] <cocooncrash> froztbyte: When I first started at UCT, the caches were squids.
[16:28] <cocooncrash> Then they changed to Novel BorderManager, which was a complete cockup.
[16:28] <cocooncrash> And then IIS, which wasn't much better.
[16:28] <Symmetria> http://www.news24.com/SouthAfrica/News/DUT-classes-resume-after-protests-20110214
[16:28] <Symmetria> heh
[16:28] <Symmetria> now THERE is something that could disrupt our international bandwidth
[16:28] <Symmetria> :P since our international gateway node is there
[16:29] <froztbyte> cocooncrash: as far as things go, squid's not really all that fantastic either
[16:29] <froztbyte> it /really/ is not geared for high traffic loads in its stock form
[16:29] <Symmetria> heh lusca handles high traffic loads better than squid
[16:29] <froztbyte> ours is so patched up it looks like a totally different beast
[16:29] <froztbyte> yeah, lusca's already a helluva big step up on squid
[16:30] <Symmetria> lusca made some huge improvements and can comfortably serve a coupla gigs on a big enough box
[16:30] <froztbyte> we ported our patchbase over to lusca, and are continuing developments there
[16:30] <froztbyte> Symmetria: depending on configuration
[16:30] <froztbyte> and traffic type across it
[16:30] <Symmetria> we used to use lusca frontend as a load balancer for serving firefox downloads, peaked it out at around 6gigabit/second on a single box
[16:30] <Symmetria> the real trick to get that kinda through it.... stop caching anything :P
[16:31] <froztbyte> if you're running it as a gateway-style proxy for lots of people's connections, you need to do a loooooooooooot of tweaking
[16:31] <Symmetria> heh we tell everyone, turn off your disk caching
[16:31] <Symmetria> if you wanna use the stuff for logging/control fine
[16:31]  * froztbyte kicks ASDM in the nads
[16:32] <Symmetria> just dont try and cache anything
[16:32] <froztbyte> urgh *shudder*
[16:32] <Symmetria> because your disks arent fast enough to keep up
[16:32] <froztbyte> squid + disk logging == B.A.D.
[16:32] <froztbyte> so bad
[16:32] <froztbyte> it does it synchronous :(
[16:32] <froztbyte> (the normal codebase)
[16:32] <Symmetria> heh what they SHOULD do is just stick a damn SCE in line
[16:32] <Symmetria> that can do the logging for them
[16:33] <Symmetria> completely transparently
[16:33] <froztbyte> yes but that would require them to use their brains
[16:33] <Symmetria> and it logs far more than a proxy server ever would :P
[16:33] <froztbyte> not just their wallets
[16:33] <Symmetria> the sce logging facilities are... really really scary
[16:33] <Symmetria> (we disable them on the TENET sce, entirely)
[16:34] <Symmetria> but enabled, that thing can tell you the top transmitting email address and exactly how many bytes of email they sent for the last 2 weeks
[16:34] <Symmetria> which it picks up from layer 7 analysis of traffic at up to 30gigabit/second
[16:34] <Symmetria> which is kinda... mindblowing
[16:34] <froztbyte> we've got an SCE deployment in limbo in the one customer network at the moment
[16:34] <froztbyte> waiting on another project to finish before it can be done
[16:35] <froztbyte> can't wait to play with it :)
[16:35] <Symmetria> heh you're gonna have fun deploying sce
[16:35] <Symmetria> setting it up is... a bitch slut whore
[16:35] <Symmetria> once it works, its fine
[16:35] <froztbyte> hehe
[16:35] <Symmetria> oh and its management interface = WINDOWS ONLY
[16:35] <Symmetria> (and you *CANNOT* use an sce without that interface)
[16:35] <froztbyte> yeah, it's roughly like the ASAs
[16:36] <froztbyte> ASAs you can still kinda manage on the console....but you wouldn't want to
[16:38] <Symmetria> heh I've worked with cisco pix enough to know how to use an ASA through the console with relative ease
[16:38] <Symmetria> the sce is.... far far far more difficult than that
[16:39] <froztbyte> I've been getting to know the ASA console over the last while
[16:39] <froztbyte> usually mostly by poking at stuff in ASDM and then seeing what the underlying output is
[16:40] <Symmetria> heh thing is, the SCE relies on a bunch of backend components
[16:40] <froztbyte> pet peeve of mine is how crap the ASA testing/information commands are compared to the rest of the cisco line
[16:40] <Symmetria> whats known as a collection manager
[16:40] <Symmetria> a subscriber manager
[16:40] <Symmetria> and a management interface
[16:40] <Symmetria> all of which are seperate software components
[16:40] <Symmetria> the collection manager in turn talks to a mysql database
[16:40] <Symmetria> the sce transmits to the collection manager which decodes the shit and shoves it into mysql
[16:42] <Symmetria> but make no mistake, the sce is a very very powerful platform
[16:42] <Symmetria> capable of insane throughput :)
[16:43] <froztbyte> it'll be capable of doing what this network needs for a looooooong time


[00:04] <hqbui> ls
[00:04] <hqbui> dir
[00:04] <hqbui> top
[00:04] <hqbui> pwd
[00:04] <hqbui> exit
[06:29] <dholbach> good morning
[13:20] <Jung-Kyu> .
[14:01] <t1mp> hello
[14:01] <ahayzen> o/
[14:03] <nik90_> hello
[14:04] <nik90_> mhall119: u r live
[14:04] <sil2100> o/
[14:04] <ahayzen> mhall119, we can see you!
[14:04] <mrbrownstone> your are live
[14:04] <jcastro> hi everyone!
[14:05] <JDGwf> Hi JCastro & Nik90_ :)
[14:05] <nik90_> JDGwf: hello
[14:06] <mhall119> if you have questions you can ask them in here at any time, just start it with "QUESTION" so I get a highlight on it
[14:09] <ahayzen> mhall119, we're using it on the mediascanner2 models for the music-app :)
[14:11] <mhall119> ahayzen: like it?
[14:11] <ahayzen> mhall119, yeah it works well :) we use it for sorting
[14:12] <mhall119> cool, I'll have to find time to try it on my app
[14:30] <mhall119> http://mhall119.com/2014/05/calling-for-ubuntu-online-summit-sessions/
[14:32] <philoulafripouil> When will be released Ubuntu 14.10 ?
[14:32] <ahayzen> thanks guys :)
[14:51] <dart> Bluetooth seems to be an issue
[22:26] <nik90_> jose: ping
[22:29] <nik90_> jose: Can you book a session "Ubuntu Core Apps" for Thursday May 29th 12:00 UTC
[23:52] <jose> nik90_: hey, can you send me the full details to<EMAIL_ADDRESS>I'll have it done for sure


[01:09] <bdmurray> hello
[01:09] <bdmurray> it's that bug guy
[01:09] <bdmurray> coming to _bug_ somebody
[01:09] <bdmurray> :)
[01:11] <nixternal> brb
[01:12] <bdmurray> sure
[01:22] <ubotu> New bug: #121810 in ubuntu-docs (main) "Gutsy Install Disk Boots up with Feisty Id Info" [Undecided,Confirmed]  https://launchpad.net/bugs/121810
[01:23] <bdmurray> I was going to ask about that bug
[02:26] <nixternal> bdmurray: that won't get fixed until a Gutsy doc package gets uploaded
[02:27] <nixternal> no hurry to fix it really, but it will get fixed with the next doc upload
[02:30] <bdmurray> Did you read how it is confusing what version I am running?
[03:36] <nixternal> hah
[03:36] <nixternal> this bug report is funny
[03:37] <nixternal> bdmurray: that is a duplicate of 120509 and 120508
[03:38] <nixternal> and anyone who has a loss of labor/time/money whatever with a "development release", needs to lose it :)
[03:41] <bdmurray> While they are looking in the "wrong" spot for version information it is interesting.
[03:42] <bdmurray> Wouldn't it be somewhat trivial to increment the version?
[04:27] <nixternal> bdmurray: it has already been done in SVN, all we need to do is create a gutsy package for the docs
[04:28] <nixternal> but seeing as we haven't begun adding stuff yet, it won't be but a little bit yet until we do
[04:43] <bdmurray> haven't & won't & but a little bit means soon?
[04:44] <nixternal> month at the soonest I am guessing
[04:44] <nixternal> it isn't anything major, just the About Ubuntu still says feisty ;)
[04:45] <nixternal> it is fixed in SVN, just need a Gutsy package built for the docs, and it isn't worth building a new version just to change Feisty to Gutsy at this time, especially since that would be the only change right now
[04:46] <bdmurray> cool so around tribe 3 then? is the normal point in the release cycle?
[04:50] <nixternal> sounds about right
[04:50] <nixternal> I would count on after mdke_'s wedding :)
[02:59] <fijam> hello
[05:48] <jjesse> made changes to adept guide specifically to kubuntu
[05:48] <jjesse> and uploaded to bzr branch
[06:08] <nixternal> rock on with your bad self
[06:08] <nixternal> I need to start getting on some stuff
[06:08] <jjesse> i'm getting ready to have some review made on the changes i've made so i'll elt you know when i'm ready for that
[06:09] <nixternal> roger that...we have BarCamp Chicago today, so I am going to get in the shower here soon and make my way to a train
[06:09] <jjesse> have fun at barcamp chicago :)
[06:09] <nixternal> bah
[06:09] <nixternal> I wish I could just drive, but you can't park anywhere around the place
[06:10] <nixternal> I hate when people decide to hold a fairly decent sized event when the only way in and out is the L trains
[06:10] <jjesse> that does suck
[06:12] <nixternal> so I have to drive out by O'hare, on the other side, 30 minute drive, hop on a train, 30 minute ride, and walk another 15...when I could just drive straight there in 30-45
[06:12] <nixternal> you ever been up to Hart(heart?) Michigan?
[07:45] <ubotu> New bug: #42911 in postfix (main) "postfix cannot read saslauthd socket (dup-of: 105378)" [Medium,New]  https://launchpad.net/bugs/42911


[06:06] <lordievader> Good morning
[13:31] <geosmile> does anyone have a good pointer to a systemd service that spins up docker compose / down?
[15:40] <DammitJim> someone in the office was just telling me that Ubuntu 16.04 LTS is end of life 04.2021
[15:40] <DammitJim> but then I reviewed the Ubuntu page and it says it's EOL in 2024
[15:40] <DammitJim> what kinda support does one get between 2021 and 2024?
[15:46] <xnox> DammitJim: most likely one will either need a free Ubuntu Advantage personal (free) or one of the paid tiers to access ESM (Extended Security Maintenance). Like one currently needs for 12.04 LTS and 14.04 LTS both of which are end of basic support. You can ask questions about Ubuntu Advantage in the live chat at https://buy.ubuntu.com/
[15:46] <xnox> DammitJim:  but that will be announced next year, as xenial is still currently supported.
[15:46] <DammitJim> ty
[15:48] <xnox> DammitJim:  we try to not use "EOL" anymore, and we try to instead use "End of Basic support" and "End of Extended Security Maintenance" because it is ambigious, 2021 vs 2024.
[15:48] <xnox> or well 2026
[15:49] <xnox> who knows what ESM offering for 16.04 will be.
[15:49] <DammitJim> si
[16:30] <RoyK> DammitJim: it's probably not much of a problem to upgrade it, though, depending on what it runs
[18:11] <DammitJim> how can I figure out if a certain package came from main or something else?
[18:11] <DammitJim> for example openjdk-8-jdk on Ubuntu 16
[18:11] <quadrathoch2> DammitJim apt policy <package>
[18:11] <DammitJim> ty
[18:11] <DammitJim> I don't know why I was thinking there was a webpage with that info
[18:11] <DammitJim> querying
[18:11] <quadrathoch2> you could use packages.ubuntu.com DammitJim ;)
[18:12] <quadrathoch2> but only if it's within the ubuntu repos
[18:12] <DammitJim> man, things get very weird... when upgrading the OS
[18:12] <quadrathoch2> DammitJim oO what specifically?
[18:12] <DammitJim> because it almost forces you to update your applications to support the version that is in main for the OS you are going to
[18:13] <DammitJim> so, we have servers that run applications written in java and go on tomcat
[18:13] <DammitJim> so, for example, we have Ubuntu 16 servers with tomcat 7 and openjdk 8
[18:13] <DammitJim> if I upgrade to Ubuntu 18 because Ubuntu 16 is EOS 04.2020
[18:14] <DammitJim> then it sounds like I won't get support for installing/keeping openjdk 8 and tomcat 7 because those aren't coming from main
[18:14] <DammitJim> does that make sense?
[18:14] <quadrathoch2> yup :) DammitJim
[18:14] <DammitJim> gotta keep up with tech, I guess
[18:15] <quadrathoch2> DammitJim yeah, tech is really fast in comparison to anything else
[18:15] <quadrathoch2> advancing
[18:15] <DammitJim> I might just have to run the outdated OS...
[18:16] <DammitJim> actually, I wonder what is worse... I think I loose either way
[18:16] <DammitJim> or pay for support, I guess
[18:16] <quadrathoch2> support _should_ not be too expensive
[18:16] <DammitJim> it adds up, though
[18:17] <quadrathoch2> in comparison to what?
[18:17] <DammitJim> 100 VMs @ $100 a pop per year
[18:18] <DammitJim> I don't have $10k laying around
[18:18] <DammitJim> I better start cracking the whip and get the devs updating their applications
[18:20] <quadrathoch2> yes, but imho when having a 100 VMs you probably (as a company) already earn more/have more revenue, where it should be possible to pay it (I mean or you could get more devs who update the software)
[18:20] <DammitJim> yeah, you know how it is... it's not my money, it's the president's
[18:20] <DammitJim> maybe the problem I have is that I haven't been moving fast enough telling devs to get off java 8
[18:21] <quadrathoch2> probably, as it's already 6 years old
[18:22] <quadrathoch2> and already out of support (at least commercial from oracle)
[18:22] <DammitJim> well, Ubuntu support java 8 since it's in main for Ubuntu 16
[18:22] <DammitJim> there's a fine balance
[18:23] <quadrathoch2> yup :) I know, just saying that upstream support is eol.
[22:57] <dasjoe> I've done debootstrapped root-on-ZFS server installs for what, 7? years by now, although I have no experience with zsys either
[22:58] <sarnold> dasjoe: wow
[23:02] <dasjoe> sarnold, long time no see :-)
[23:03] <sarnold> dasjoe: indeed, it's been ages :) how are you doing?
[23:03] <dasjoe> I found some of my notes about how to get an installation similar to Ubuntu Server on ZFS, https://gist.github.com/dasjoe/09ecf8190c523bf7a7dc
[23:05] <dasjoe> sarnold, I'm fine! Just a bit busy all the time, so I "kind of forgot about" IRC for a while. I was cleaning up some stuff and stumbled upon my client again. How are you?
[23:06] <sarnold> dasjoe: I can relate to most of that, hehe :) too busy, too little time, but happy to be gainfully employed at home, you know? :)
[23:07] <sarnold> dasjoe: here's hoping you'll remember your client more often :)
[23:08] <sarnold> dasjoe: five years ago .. installing the wily hwe kernel. man.
[23:11] <dasjoe> sarnold, I've set it to autostart when I login, so there's that :-) Yeah, I'm enjoying my last week off. Past few months have been quite stressful with everybody working from home and my team having to fix not only our office stuff but home networks, too :-)
[23:12] <dasjoe> sarnold, yeah, the gist even contains some hacks for grub like enabling only some feature flags and symlinking ZFS partitions into /dev/ so grub can find them
[23:13] <dasjoe> sarnold, also, BIOS only, no UEFI grub. Times were simpler!
[23:14] <sarnold> dasjoe: hah, and at the moment I'm composing a knowledge base thing for folks booting ith legacy / bios etc and busted grub installs...
[23:14] <sarnold> dasjoe: .. at the moment, uefi is feeling simpler in many ways :)
[23:15] <sarnold> dasjoe: how long did you have off?
[23:15] <dasjoe> sarnold, well, I'm sadly no longer too involved with ZFS as of now. My laptop's root filesystem is NTFS ;-)
[23:16] <sarnold> a swedish pal is lamenting the end of his month off .. actuall I htink he returns tomorrow
[23:16] <sarnold> dasjoe: *gasp*
[23:16] <sarnold> dasjoe: actually, I'm thinking of buying a windows myself, MS flightsim is looking pretty good..
[23:19] <dasjoe> sarnold, I uninstalled Outlook and RocketChat on July 17th, so it's three and a half weeks in total. Originally we wanted to have a real vacation - as in travel somewhere for a week or so - oh well
[23:20] <sarnold> dasjoe: yeah :(
[23:20] <sarnold> I love the "uninstall" though :) hahaha
[23:22] <dasjoe> sarnold, yes! Uninstalled everything at around 23:50 on that friday, so I'm really out of the loop about what's happening in the office right now. We still have no on-call rotation, so I had to explain again and again how I'm not reachable for anybody in any case
[23:24] <sarnold> dasjoe: more than once I've heard of folks using 'vacation time' to get work done.. without being bothered by co-workers
[23:26] <dasjoe> sarnold, I found it easier to ignore bothering requests working from home, we could actually focus on some problems or do some research for once :-)
[23:29] <sarnold> dasjoe: yay :D I do imagine we're going to see more work-from-home..
[23:30] <dasjoe> sarnold, still, I'm thnking about looking for a job at a real remote company instead of "remote-first"-as-long-as-it-suits-us, especially now that my family and I established methods and rules for me working from home
[23:31] <sarnold> dasjoe: oooo good luck :D
[23:33] <dasjoe> So I'm browsing through SRE jobs every few weeks. As of now my short commute (a 5 minute walk) and okay-ish compensation is what's keeping me there. Better compensation with no commute would be nice to have, but I can't really complain


[00:00] <AKX> @xnox: Thank you for checking...
[00:01] <AKX> xnox: Thank you for checking....
[01:05] <Thedemon007> Hi if someone know were can get last kernel version ppa let me know here https://bugs.launchpad.net/ubuntu/+source/linux-hwe-6.2/+bug/2039334
[01:05] -ubottu:#ubuntu-kernel- Launchpad bug 2039334 in linux-meta (Ubuntu) "Intel usb problem with gamepad device descriptor read/64, error -32" [Undecided, New]
[01:05] <Thedemon007> i check https://wiki.ubuntu.com/Kernel/MainlineBuilds?action=show&redirect=KernelMainlineBuilds but url no work
[01:43] <Thedemon007> i think already found a way https://www.linuxcapable.com/how-to-install-latest-linux-kernel-on-debian-linux/ i am donwloading now
[02:29] <AKX> Thedemon007: Yes, that works, if you want the latest Kernel from the Zabbly PPA.  Unfortunately, I no longer have an "easy" way of getting the latest Kernel from the Kernel.org 6.1.x Series as a set of Ubuntu Deb Packages.
[02:31] <AKX> The "Mainline PPA" 6.1.x packages contained what is known as Kernel.org's current "Long Term Kernel."
[02:31] <Thedemon007> AKX some way for install matic kernel packages? or were can found .deb files in http://archive.ubuntu.com/ubuntu/ repo ?
[02:31] <AKX> I have been using the now-missing Mainline Kernel PPA to install the latest 6.1.x Long-Term Kernel.
[02:32] <AKX> Been using the PPA since 6.1.39 was published...  I currently have 6.1.55 installed, but Kernel.org says 6.1.57 should be available.
[02:32] <AKX> I went to check today for 6.1.57 at the Ubuntu Mainline Kernel PPA, but it had dissapeared.
[02:33] <Thedemon007> Amm ok so is a problem recent
[02:37] <AKX> Thedemon007: Yes, very...  I used the Mainline Kernel PPA to install 6.1.55 about 10 days ago, give-or-take a couple days.
[02:38] <AKX> Now today, I check again, and I get HTTP 404/Not Found error.
[02:38] <AKX> Looking in Ubuntu Repo, 6.1.x Long Term Kernel is not available.  Only 6.2.
[02:39] <AKX> I tried 6.2.  Did not like it.  Also tried 6.5.  Did not like that either.  So, went backwards to 6.1.  Things started working very well, no problems.
[02:39] <AKX> And much faster than 5.15 and 5.19...
[02:51] <AKX> --- ---
[02:51] <AKX> --- ---
[02:53] <AKX> The git source repo ( git clone git://kernel.ubuntu.com/ubuntu/linux.git ) is also missing...
[02:54] <AKX> The above link is referenced in Ubuntu Kernel GIT Guide ( https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide )
[02:59] <Thedemon007> :(
[03:03] <AKX> xnox: Any word?
[04:38] <stuffnthings> is the kernel ppa being terminated or is it just down?
[04:40] <AKX> stuffnthings: I do not know. Someone from Ubuntu pinged another Dev and requested info, but that has not come back yet.
[04:41] <stuffnthings> thanks for clarifying further AKX
[04:42] <AKX> stuffnthings: I have also reached out to some outside community forums, notified them of the outage, and requested info...
[04:42] <AKX> stuffnthings: (Maybe they have access to people/contacts, that I cannot reach at Canonical.)
[04:44] <stuffnthings> i just checked on it for the first time in a while yesterday, you know how long its been out?
[05:00] <Thedemon007> i try boot with mantic kernel but graphics no work
[05:01] <Thedemon007> idk if are a issue of compatibility because i use jammy or is the kernel maybe more later i try boot mantic iso..
[05:05] <Thedemon007> xorg.log: https://paste.ubuntu.com/p/nNC764SRwY/
[05:22] <tomreyn> Thedemon007: please head over to #ubuntu for support
[05:26] <Thedemon007> tomreyn ok thanks
[12:12] <k3dAR> Hi, i have question about Ubuntu Kernel MainlineBuilds, is temporary down or ended?
[12:13] <stuffnthings> it may be either, i asked around got got conflicting answers
[12:17] <k3dAR> Thanks, so not any official statement?
[12:20] <stuffnthings> nope
[12:22] <k3dAR> And any info if ended, if be reenabled hibernation with secure boot on stock kernels?
[12:23] <stuffnthings> i dont know anything about that ,sorry
[12:43] <k3dAR> and can you (or anyone) pls suggest a better place to ask?
[12:45] <jeremy31> You could try emailing the kernel-ppa team
[13:32] <tomreyn> (at least) one of the kernel team is now aware of the (potential) issue and plans to look into it later.
[13:49] <jeremy31> I wonder how many UKUU users will be crying
[14:04] <k3dAR> jeremy31: what is pls email addr for kernel-ppa team? Cannot find it... Btw: crying all who hibernate with secure boot as this disabled in stock kernels
[14:05] <jeremy31> Hibernate didn't work so well on many systems because of ACPI support, so it was disabled IIRC
[14:06] <jeremy31> https://launchpad.net/~kernel-ppa
[14:12] <k3dAR> Thanks. I understand default disabled in polkit rule, but not understand disabled in Kernel side only for secureboot, when user add polkit rule for enable hibernation item, then if have disable secureboot, hibernate work, but with enable secureboot is hibernation blocked by kernel... With UbuntuMainline kernel works hibernation with secureboot enabled, of course for secure reason to swap on luks
[21:17] <AKX> Does Kernel PPA being down have anything to do with the Malicious / Hate-Speech Language Translations discovered on the Ubuntu 23.10 Desktop ISOs, as reported here: ( https://www.omgubuntu.co.uk/2023/10/ubuntu-23-10-installer-translations-hijack ) ...?
[21:36] <AKX> It is reasonable to presume that if the Installation ISOs were compromised, then other parts of the Tool Chain may have been compromised.  Interestingly, the "Official" Updated Kernels ( including Source / GIT ) on LaunchPad are still available.
[21:36] <AKX> I would recommend Ubuntu revoke those as well ( for the time-being ), to ensure integrity...
[21:44] <jeremy31> AKX: Does kernel-ppa have anything to do with translations?
[21:49] <k3dAR> AKX: sure not, as not be compromised ISO, but "only" merge translation strings from 3rd translation web/service for and only installer
[21:52] <Eickmeyer> AKX: https://discourse.ubuntu.com/t/announcement-ubuntu-desktop-23-10-release-image-is-being-updated-to-resolve-a-malicious-translation-incident/39365 will answer all of your questions regarding the incident. Any more speculation beyond that will not be done here.
[21:52] <Eickmeyer> (and is entirely off-topic here as well)
[22:08] <JanC> I think it's best to wait until after the weekend when everybody is back; the mainline kernel PPA is not officially supported AFAIK, so they aren't going to call people into work on the weekend for it