[00:28] <kokoye2007> Hello
[01:06] <slangasek> bdmurray: that's still https://code.launchpad.net/~vorlon/ubuntu/utopic/apport/lp.1354318, which is tied up in a question between ev and pitti about whether we're getting premature inotify regardless of umask settings
[01:08] <bdmurray> slangasek: I didn't see that question and started a new branch based on yours but not using a .new report file per pitti's concerns.
[01:10] <slangasek> bdmurray: yes, I'm not sure ev has actually raised the point with pitti, though I asked him to do so... maybe a highlight will help :)
[04:38] <pitti> Good morning
[05:03] <pitti> slangasek, bdmurray: yeah, I'm still not convinced that a full rewrite instead of appending is better in any way; it's a lot more expensive and just changes the failure mode instead of improving them
[05:42] <slangasek> pitti: so ev claimed to me that the current approach was giving problems with inotify behavior
[05:54] <pitti> slangasek: i. e. the final close() and/or chown() doesn't trigger an inotify event any more?
[05:55] <slangasek> pitti: I believe ev's assertion was that the inotify happens too early.  But we shouldn't play telephone
[05:56] <pitti> yeah, let's wait until he comes online
[06:10] <pitti> apw: thanks for tracking down bug 1375805
[07:18] <dholbach> good morning
[07:47] <mlankhorst> morning!
[07:49] <mardy> pitti: hi! Is it a good idea to add -dbg packages to the projects I maintain, or do we have a different policy?
[07:50] <pitti> mardy: they are redundant in Ubuntu as we autuomatically build -dbgsym packages for everything
[07:50] <pitti> mardy: so don't bother
[07:50] <mardy> pitti: OK, thanks
[07:54] <apw> pitti, i was lucky to have a persistant tester :)
[08:11] <pitti> dpm, wgrant: an hour ago or so I approved/cleaned up  the POTs on https://translations.launchpad.net/ubuntu-rtm/14.09/+source/oxide-qt/+imports -- I don't need to do anything with the POs, right? they'll be auto-imported eventually?
[08:12] <dpm> pitti, exactly. Once the .pots are approved and imported, the .pos will be too
[08:14] <pitti> thanks
[08:15] <seb128> pitti, do you plan a langpack update in rtm?
[08:16] <pitti> seb128: it's cron'ed; https://translations.launchpad.net/ubuntu-rtm/14.09/+language-packs will get another update tomorrow
[08:16] <seb128> pitti, ok, great, thanks :-)
[08:16] <pitti> seb128: if weekly isn't enough, we can certainly ask wgrant to produce two every week?
[08:17] <seb128> pitti, weekly is enough, I saw none on https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-September/date.html but I guess for some reason they don't appear on -changes?
[08:17] <pitti> seb128: correct; language-pack-* is filtered out for ACCEPTED mails, changes@ etc
[08:18] <seb128> k, makes sense
[08:18] <pitti> seb128: https://launchpad.net/ubuntu-rtm/+source/language-pack-touch-de/+changelog
[08:18] <seb128> pitti, thanks
[08:18] <seb128> weekly seems fine to me
[08:20] <seb128> is jenkins.qa.ubuntu.com down?
[08:25] <pitti> seb128: apparently, yes; d-jenkins works fine
[08:25] <seb128> where is the right place to let people know in they case they don't? #is?
[08:26] <pitti> seb128: yes, in particular retoaded
[08:27] <Laney> it did load for me, but it was s-u-p-e-r-s-l-o-w
[08:28] <seb128> Laney, it's spinning for over 5 minutes for me
[08:28] <seb128> that's not usable, I'm still going to let #is know
[08:28] <Laney> needs attention either way
[08:29] <seb128> yeah
[08:29] <mlankhorst> doko_: ping?
[08:47] <seb128> Laney, pitti, #is restarted it, back to normal
[08:47] <pitti> seb128: cool, thanks
[08:47] <seb128> yw!
[08:48] <Laney> great
[09:03] <flexiondotorg> Laney, Thanks for uploading the update xzoom to Debian and Ubuntu.
[09:52] <Laney> flexiondotorg: no worries
[10:07] <wwlzhuzhu> Hi everyone, I am trying to add a net samba printer, I try to see the windows computer from Places net,I can. But from printer manager i can  not accesss trough  examine. I am on ubuntuMATE beta2
[11:03] <doko> mlankhorst, pong
[11:04] <mlankhorst> so it seems llvm detects qemu32 as pentium2, which disables the sse extensions, causing the llvmpipe breakage
[13:01] <doko> mlankhorst, but why are these needed by llvmpipe?
[13:19] <doko> mlankhorst, how comes qemu into the game?
[13:23] <mlankhorst> doko: things were already broken before it seems, but with the change to 3.5 to no longer autodetect features it started to show..
[13:25] <doko> mlankhorst, lp_screen.c explicitly checks for sse2
[13:25] <doko> so why did that work before?
[13:25] <mlankhorst> because we passed an empty string to cpu/feature flags
[13:25] <mlankhorst> which meant 'autodetect all capabilities please'
[13:26] <mlankhorst> this is no longer supported in 3.5
[13:26] <mlankhorst> and llvm::sys::gethostcpuname() returns 'pentium2'
[13:27] <nrbrtx> Dear all! I can't understand why Ubuntu does not have an init script for saving and restoring display backlight level. I have prepared one (see bug 1270579 ), it works on my laptops as expected.
[13:28] <doko> mlankhorst, that would be correct, as we build for i686. but where is qemu32 called? can't you specify a target cpu?
[13:28] <mlankhorst> you can specify a target cpu, but llvm detects it as a generic pentium2, without sse support or anything..
[13:29] <mlankhorst> it can be overridden partially, but setting all the feature flags manually will be a bit of a pain
[13:29] <mlankhorst> still, i probably should :/
[13:36] <ted> bdmurray, Do you know what tool generates this list: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-s-incoming-bug-tasks.html
[13:42] <pitti> apw: oh right, you forgot the debian/rules bit
[13:42] <pitti> apw: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=0c114f9497ca8771c96229e6ccc59544f7cd6c0b
[13:42] <pitti> apw: that was my original commit until I saw your upload
[13:43] <nrbrtx> Am I understand correctly, that Ubuntu Utopic has screen backlight save/restore on via systemd?
[13:51] <apw> pitti, yeah ... just fixed it ... stupid test box has that file as a "conf" file from the old days ... and if you had gotten their first it would have been fixed first time ... grr
[13:52] <pitti> apw: urgh, conffile? oh blergh, this is an upstart job, not an udev rule, right
[13:52] <pitti> apw: no worries :)
[13:52] <apw> pitti, i know, but somehow apt has it down as one of those ...
[13:52] <apw> pitti, anyhow this time the builders are working so i was able to get a reliable test before upload, though it matches yours exactly
[13:53] <pitti> and yeah, init scripts/jobs really should not be conffiles, but be treated as code; they are the #1 offender in /etc for cleaning it up
[14:05] <mlankhorst> doko: http://paste.debian.net/123989/ untested, but would something like this work?
[14:19] <mlankhorst> hm seems to! D
[14:19] <mlankhorst> *:D
[14:21] <mdeslaur> doko: can I expect a twisted sync?
[14:28] <mlankhorst> doko: the paste I linked above fixes the crash in the test for me. Would this be a sane way to deal to have some form of autodetection?
[14:36] <mlankhorst> it should at least match llvmpipe's idea of the cpu caps to llvm
[14:38] <bdmurray> pitti, slangasek: I wonder if ev's concern stemmed from incomplete reports appearing in the error tracker due to bug 1360417.
[14:39] <bdmurray> ted: yes, I know what tool generates that list
[14:40] <ted> bdmurray, Will you tell me? :-)
[14:42] <bdmurray> ted: https://code.launchpad.net/~arsenal-devel/arsenal/2.x see the rls-mgr folder
[14:56] <doko> mdeslaur, no, but there is an upload in the unapproved queue
[15:01] <doko> mlankhorst, maybe guard this for ix86?
[15:03] <slangasek> ev: ^^ can you provide some more detail on your whoopsie_upload_all / inotify concern?
[15:09] <mdeslaur> doko: cool, thanks
[16:13] <ev> slangasek: sure, looking now
[16:15] <ev> I believe my concern was that the report would appear to whoopsie via inotify before it had the correct permissions. Whoopsie would try to read this, fail, and put it in a queue for two hours later.
[16:15] <ev> This doesn't appear to be the case, looking at Martin's MP
[16:16] <ev> whoopsie isn't looking for .new files, so it will only act on the report after the rename, after it has the right permissions
[16:16] <ev> slangasek: err your MP :)
[16:16] <ev> ohhh
[16:16] <ev> your MP introduces the .new behaviour
[16:16] <ev> so this makes more sense now
[16:17] <slangasek> ev: ok, I thought you had expressed a concern that things were /already/ appearing to whoopsie before they had the correct permissions
[16:17] <ev> I was looking at a bug that asac was encountering at the time. I believe your MP will fix it.
[16:17] <slangasek> ev: pitti has claimed that the inotify only happens once the file is readable
[16:17] <slangasek> ev: right, and pitti wants me to not use the .new
[16:17] <ev> oh boo
[16:17] <slangasek> so what was the bug, specifically?
[16:17] <ev> well, we could have a unit test for this sort of thing
[16:18] <pitti> ev, slangasek: no, I'm fairly sure the inotify happens already on creation; I wondered if there's another inotify event on close() or chmod(), so that we can wait until teh file becomes readable
[16:18] <slangasek> ok
[16:19] <slangasek> pitti: so it's speculation on your side that this works in a non-racy manner? ;-)
[16:19] <mitya57> Is it normal when a package in universe depends on a package in multiverse?
[16:19] <slangasek> mitya57: no, it's disallowed by policy
[16:19] <pitti> slangasek: well, it's a question :)
[16:19] <slangasek> ok
[16:20]  * mitya57 files a bug then (the package in question is ubuntu-emulator)
[16:20] <slangasek> so, notwithstanding the increase in disk writes, I'm sure that my MP is non-racy wrt inotify
[16:20] <pitti> slangasek: but according to the manpage, inotify can do this (subscribe to IN_CLOSE_WRITE)
[16:21] <pitti> or even better, IN_ATTRIB (and then checking if it's readable)
[16:21] <pitti> that's the thing which we are actually looking out for
[16:21] <pitti> as it has permissions 000 during writing
[16:21] <slangasek> pitti: ok, well I gather that this isn't what's being done today
[16:22] <pitti> hmm, grepping whoopsie for "inotify" gives no results
[16:23] <slangasek> ev: where does the inotify watching happen for this?  no references to 'inotify' in the whoopsie source
[16:23] <pitti> oh, glib -- GFileMonitor?
[16:23] <pitti> bingo
[16:23] <slangasek> ok
[16:24] <pitti> so I suppose we want G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED
[16:24] <pitti>         if ((event_type == G_FILE_MONITOR_EVENT_CREATED) ||
[16:24] <pitti>             (event_type == G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED))
[16:25] <pitti> and the first one should be dropped (or there shoudl be at least an additional check that the file is readable)
[16:26] <pitti> oh wait
[16:26] <slangasek> pitti: the first one is necessary for offline notifications of files already created when whoopsie starts
[16:26] <pitti> this is the monitor for the .upload stamp
[16:26] <pitti> that looks fine
[16:26] <pitti> in fact, whoopsie isn't concerned about the completeness of .crash files at all; apport writes the stamps, and whoopsie is only looking for .upload
[16:26] <pitti> sorry, so this was a red herring, whoopsie looks fine
[16:27] <ev> yeah, damn
[16:27] <pitti> we only need to ensure to write the .stamp file after the .crash file is completely written and readable
[16:27] <slangasek> ev: so is there not actually a bug here?
[16:27] <pitti> which again is contained in whoopsie-upload-all
[16:27] <ev> I don't believe so, no
[16:27] <slangasek> ok
[16:27] <slangasek> bdmurray: ^^ so I think this should unblock you regarding your fix to my branch to not do the .new handling
[16:27] <pitti> and AFAICS the current version already does that
[16:31] <bdmurray> slangasek: okay, thanks
[16:41] <bdmurray> pitti: the fix for bug 1354571 will prevent uploading of incomplete core dumps right?
[16:44] <pitti> bdmurray: yes, this was specifically adjusted in w-u-a as well
[16:44] <pitti> i. e. not just with UnreportableReason
[16:46] <bdmurray> pitti: okay, I think I'll SRU this to Trusty to reduce the work load for the error tracker then
[19:32] <brainwash_> xnox: hey, have you already been pinged by the xubuntu team re bug 1375893 ?
[19:38] <brainwash_> you've fixed the ubiquity wallpaper problem some months ago, back then it showed the debian background
[20:47] <Noskcaj> mitya57, Anything i still need to do for bug 1372224
[21:36] <AMDCeleron> !ops
[21:41] <AMDCeleron> !ops
[21:50] <doko> Logan_, are you this logan? http://bugs.python.org/issue18096
[22:43] <doko> slangasek, infinity: did you make progress with the cross-toolchain-base packages?
[22:47] <slangasek> doko: I've gotten a successful build of the arm64 one, but I understand that there's still some more work needed for any of the biarch cross-compilers; also the packaging has drifted between the various targets and badly needs to be resynced... that's currently backburnered for me
[22:51] <doko> slangasek, ok, once you have the arm64 case, I can have a look at the biarch stuff
[22:51] <slangasek> well, I think infinity wanted to look at it from the glibc side
[22:51] <doko> ahh, nice
[22:51] <infinity> I'm looking at it, yes.
[22:52] <infinity> Have some patches from helmut to toss in, and then some test building to see the state of things and where it now breaks.


[13:13] <obounaim> Hi everybody
[13:14] <obounaim> What is a "fakesync"
[13:29] <jtaylor> obounaim: it is done when the checksum of the orig tarbal is different
[13:29] <jtaylor> most commonly the case when we update to new upstream before debian
[13:30] <jtaylor> then the checksums could mismatch due to different compression
[16:02] <obounaim> Does Ubuntu packages conform 100% with Debian policy?
[16:25] <tumbleweed> obounaim: almost
[16:26] <obounaim> what are the differences?
[16:30] <tumbleweed> obounaim: the obvious things. you can look at the (untouched for years) ubuntu-policy package, but I'd say just apply common sense
[18:05] <obounaim> fa


[00:27] <daftykins> https://youtu.be/aMZ4QL0orw0
[00:27] <daftykins> nice tune
[00:27] <daftykins> did pretty good on my first pool team night, 2 out of 3 won - last of 'em was down to the black
[11:45] <zxmpi_> thursday, could never get the hang of thursdays
[12:33] <m0nkey_> know what you mean, not quite the end of the working week and not quite the weekend.
[12:34] <zxmpi_> still mid week but too close to weekend to be not be distracted by weekend


[01:53] <ubptgbot> PauloAndrePMP was added by: PauloAndrePMP
 Hey is the Axolotl admen here? :)
 [Edit] Hey is the Axolotl admin here? :) … Axolotl doesn't seem to be able to read my contacts. Try to start a chat and no one comes up. I've even tried manually adding the contact and still doesn't show.
 [Edit] Hey is the Axolotl admin here? :)
 @liamolua [Hey is the Axolotl admin here? :)], I think you are wanting @flaburgan.  There is a beta with fixes for current 8.8 version regressions up at https://t.me/ubports_qa_team/38332
 @liamolua [Hey is the Axolotl admin here? :)], [Edit] I think you are wanting @flaburgan.  There is a beta available for testing, with fixes for current 8.8 version regressions up at https://t.me/ubports_qa_team/38332
 Awesome, it seems to not be able to see my contacts. I'll check out the beta :)
[04:53] <cc> when i try to use "ubports-installer.0.5.2-beta",it always told me that
[04:53] <cc> https://img.vim-cn.com/d4/3828d3fc4ae688f46d8af0491f7a4735ace886.png
[04:54] <cc> i have tried other network,use vpn,but it still cant connect
[04:54] <cc> https://img.vim-cn.com/d4/3828d3fc4ae688f46d8af0491f7a4735ace886.png
[04:55] <cc> https://img.vim-cn.com/e2/f03f97040cd58d7333ab1b59ea90a388185d7c.png
 @flaburgan @totalsonic Tried installing the.click but it gave me this failed output.
 (Photo, 1080x1920) https://irc.ubports.com/QSK7teCe.png
 @liamolua [@flaburgan @totalsonic Tried installing the.click but it gave me this failed out …], are you on an arm64 device?  The link I gave you was for armhf.  Let me see if I can find the link to arm64
 I'm on Nexus 5 which I think is arm hf. Ill double check
 @liamolua [I'm on Nexus 5 which I think is arm hf. Ill double check], yes, that is armhf
 Nexus 5 is armhf
 Strange...
 @liamolua [Strange...], the 0.8.9 beta installed and is working on my Meizu Pro 5 on RC channel.  Maybe try redownloading the click and reinstalling?
 Will do, I did send it over ssh so that could be it
 Installed this time round, cheers :)
 It still can't see my contacts @flaburgan. Can't create a convo with anyone cause no one shows up.
 Okay, I'm having a few issues with my Nexus 5 on UT 16.04 Stable. … 1) When I try to install Anbox, I loose Wifi access. … 2) GPG does not work, tried multiple map apps and all of them just keep trying to load the GPS location (I have checked permissions too).
 [Edit] Okay, I'm having a few issues with my Nexus 5 on UT 16.04 Stable. … 1) When I try to install Anbox, I loose Wifi access. … 2) GPG does not work, tried multiple map apps and all of them just keep trying to load the GPS location (I have checked permissions too). … Sorry to be spamming the chats atm.
 [Edit] Okay, I'm having a few issues with my Nexus 5 on UT 16.04 Stable. … 1) When I try to install Anbox, I loose Wifi access. … 2) GPG does not work, tried multiple map apps and all of them just keep trying to load the GPS location (I have checked permissions too). … Anyone know what is going on? … Sorry to be spamming the chats atm.
[05:42] <cc> anyone knew what happen on my ubports?
[05:43] <cc> failed to connect to the ubports servers
 @cc [failed to connect to the ubports servers], Try uninstalling the app and download again from ubports.com
 try  the .deb file instead of apparmour
 [Edit] try  the .deb file instead of appimage
[05:45] <cc> what i donwload is .exe
[05:45] <cc> i use win10
[05:46] <cc> does .deb can run on windows10?
 Oh, well. Try redownloading the exe
 No dude, .deb is for ubuntu
[05:47] <cc> as so far,i've tried 3 computers,download many times,and also try many net by vpn
 Maybe try installing it froma linux computer. Put Ubuntu on a USB and use the live enviroment if you dont want to install ubuntu on your computer
[05:50] <cc> okey,i've try,but it maybe cause more questions.
 Maybe askin the Welcome and Install group cc. They probably know more and is why it exists.
 https://t.me/WelcomePlus
 [Edit] Maybe askin the Welcome and Install group cc. They probably know more.
[05:56] <cc> okey
[05:58] <cc> thanks
[06:14] <ubptgbot> Marc Williams was added by: Marc Williams
[06:20] <cc> excuse me ,where can i download  ubports recovery ?
 (Photo, 956x1276) https://irc.ubports.com/quE5yNXw.png
 @ProfessorDark007 [<reply to media>], my oneplus one bacon won’t boot without usb cable connected.
 (Photo, 590x1280) https://irc.ubports.com/3KoGElHu.png AND-WIN Classified
 (Photo, 590x1280) https://irc.ubports.com/sPm22Txc.png
 (Photo, 590x1280) https://irc.ubports.com/GtD6Kuod.png
 (Photo, 590x1280) https://irc.ubports.com/XKy9bdqh.png
 (Photo, 590x1280) https://irc.ubports.com/K0rVmVL1.png
 (Photo, 590x1280) https://irc.ubports.com/FvF0KX6l.png
 @RAJVMEHTA [<reply to media>], I uses to like this launcher when I used android, but its not greatly related to Ubuntu touch unless you wanted to mention design cues you like that we coils use in Ubuntu touch
 @liamolua [It still can't see my contacts @flaburgan.  Totally didn't see the the dot menu on the top right. That worked, cheers!!! … I was trying to manually add numbers with the plus button. That isn't doing anything when I save the number.
[08:35] <lejocelyn> hi everyone
[08:35] <lejocelyn> when we use OSM Scout server combined with PureMaps, shouldn't it display the names of the street?
[08:35] <lejocelyn> I downloaded Berlin's map, but when I zoom in, I don't have the streets' names
[08:38] <cc> finally i solve the problem
[08:38] <cc> i use "fastboot flash recovery recovery.img"
[08:39] <cc> and then put my phone into recovery mode,and then i can clearn the wrong word
[08:39] <cc> the piont is ,which recovery.img can be used on meizu pro5 ubuntu-touch ?
[08:39] <cc> i try so much,finally,i found the correct one
 Good stuff cc.
[08:41] <cc> thanks for all your help!
[08:41] <cc> but this bug is so...
[08:42] <cc> i dont know how to say that,er.,...mybe other one will met this bug one day
[09:03] <ubptgbot> <Achim ES> @lejocelyn [I downloaded Berlin's map, but when I zoom in, I don't have the streets' names], Can't confirm this. Maybe it depends on the maps/service. HERE does show street numbers
[09:03] <ubptgbot> <Achim ES> (Photo, 1080x1920) https://irc.ubports.com/8MpQkcOL.png
[09:17] <lejocelyn> Achim ES, I'm talking about OSM Scout server
[09:17] <lejocelyn> are you using Scout server ?
[09:18] <lejocelyn> (as far as I know, it provides only one map)
[09:18] <lejocelyn> contrary to when you're online
[09:19] <lejocelyn> weird bug too on the PinePhone, when I try to paste a copied file with the graphical file manager, it makes Ubports restarts
[09:20] <lejocelyn> someone has the same issue?
[09:20] <lejocelyn> (it's systematic here)
 Hi everybody. Can anybody suggest me a device to install Ubuntu Touch? Do you know if any device (except for pinephone) supports dual boot, maybe with something like LineageOS? Thank you!
[09:21] <lejocelyn> Achim ES, if you're using OSM Scout server too, maybe then it has to do with language configuration
[09:22] <lejocelyn> ah yes, you're using it actually, and you don't have the streets' names displayed as well
[09:23] <lejocelyn> ah si
[09:23] <lejocelyn> ah yes you do
 @Alexi [Hi everybody. Can anybody suggest me a device to install Ubuntu Touch? Do you kn …], Sorry, dual boot is not really supported atm
 @Flohack Thank you for your reply. And speaking about devices which is the best one so far?
 @Alexi [@Flohack Thank you for your reply. And speaking about devices which is the best …], Depends on your needs. Most devices have a few things that are not working fully, you would need to telk us what you need for you daily life
 I am already using a BQ Aquaris E4.5
 but I would like to have a bigger screen
 I would go for Oneplus One then, or one of the Sony Xperias. Also my Nexus 6P port is quite okaish, and the N6P is monstersize :)
 I have noticed several problems with the music reader in particular with the BQ
 Music Reader? Whats that
 Music Player, sorry
 Well most of that problems might be on all devices, there is not much device-specific stuff around audio playback
 I see
 I have seen that on the UT site there is an indicator of "Maturity" for each device, what is that referring to in particular?
 @Alexi [I have seen that on the UT site there is an indicator of "Maturity" for each dev …], I'm pretty sure it's a rough guide to how complete the port is.
 I see, thanks!
 Hi, if I have TWRP on my mobile phone and I install UT via the installation program, will TWRP still be installed?
 @Petr [Hi, if I have TWRP on my mobile phone and I install UT via the installation prog …], No UBPorts Recovery
 Which is the only way Ubuntu touch can update anywau
 [Edit] Which is the only way Ubuntu touch can update anyway
 no. Ubuntu Touch is not a single zip file you can flash from TWRP. … you can join the telegram group @WelcomePlus to get help about the installer if you haven't done it yet...
 @amyosx [No UBPorts Recovery], Is there any way to replace UBPorts recorvery with TWRP again?
 Well you have TWRP installed so you clearly know how to install it so just do that again if you ever want to go back to Android?
 TWRP isn't something that just appears on a phone :P
 @Lorxu [TWRP isn't something that just appears on a phone :P], So UT supports adb?
 Uhm... don't you normally use fastboot to flash a recovery?
 @Lorxu [Uhm... don't you normally use fastboot to flash a recovery?], Yes..
 Fastboot is not ADB
 What is your actual question? "Can I go back to Android if I don't like Ubuntu Touch?" Or is it something else? Asking about the recovery sounds like you're asking about a detail that's part of another question
 @Lorxu [What is your actual question? "Can I go back to Android if I don't like Ubuntu T …], I'm still a beginner, now I'm wondering if the bootloader will be reinstalled somehow ..
 @Petr [I'm still a beginner, now I'm wondering if the bootloader will be reinstalled so …], Bootloader not touched
 Ubuntu touch only modifies boot, recovery, system, and data
 All replaced by a ROM anyway
 If you want to go back to android just enter fastboot and install twrp again
 Then flash ur rom
 @amyosx [If you want to go back to android just enter fastboot and install twrp again], So uploading a new rom, recorvery goes through the bootloader?
 @Petr [So uploading a new rom, recorvery goes through the bootloader?], Yes
 Enter Bootloader, install twrp
 In twrp flash rom
 @amyosx [In twrp flash rom], Dobrá už to chápu, díky moc!
 @Petr [Dobrá už to chápu, díky moc!], English please
 @Petr [Dobrá už to chápu, díky moc!], Sorry :)
 Hey man, we speak English in this chat. There might be a chat for your language however. :)
 @amyosx [English please], Well I get it, thanks a lot!
 Yes, sorry :)
 @Petr [Yes, sorry :)], Its ok
 @amyosx [Its ok], Otherwise does it have to be rooted to upload a new rom, UT?
 @Petr [Otherwise does it have to be rooted to upload a new rom, UT?], ?
 If I'm not mistaken, then Android must root and then upload rom ...
 @Petr [If I'm not mistaken, then Android must root and then upload rom ...], No
 Just install twrp
[12:26] <ubptgbot> ADBac was added by: ADBac
 You only need unlocked bootloader and enable usb debugging in Android before
 @liamolua [Okay, I'm having a few issues with my Nexus 5 on UT 16.04 Stable. … 1) When I try …], I've had GPS working fine on my Nexus 5 for a long time now but funnily enough had a bunch of issues today.  One thing worth trying is running `sudo test_gps` from the terminal, putting your device as close to the outside as possible (i.e.
[14:16] <ubptgbot> near a window) and waiting for the GPS fix.  It's probably better to run this over SSH, if you can.  If not, perhaps use the ActiveScreen app to keep your screen on while you wait for the fix.
 Is it possible to compile UBPorts for a device that launched with android 10
 @prudev [Is it possible to compile UBPorts for a device that launched with android 10], Not yet sadly
 @amyosx [Not yet sadly], 😔 rip
 @prudev [Is it possible to compile UBPorts for a device that launched with android 10], Pinephone is entirely new. Interesting if you don't know about it… See also Volla phone
 @Stereofont [Pinephone is entirely new. Interesting if you don't know about it… See also Voll …], She probably wants to do for her phone
 She pro android dev
 At the moment, even 8 and 9 are work in progres
 @amyosx [She pro android dev], 👍
 @imraniqbal [I've had GPS working fine on my Nexus 5 for a long time now but funnily enough h …], I will give it a try in the morning, cheers :)
 @Stereofont [At the moment, even 8 and 9 are work in progres], Ahh thanks
[15:23] <ubptgbot> Sven H was added by: Sven H
[18:07] <ubptgbot> Heng Ye was added by: Heng Ye
[18:09] <ubptgbot> <Heng Ye> I'm trying to port Xperia 10 with GSI, but there's some weird problem with the LXC containers and the cgroups. Logs are here:https://forums.ubports.com/topic/5029/sony-xperia-10-kirin-porting
[18:10] <ubptgbot> <Heng Ye> Somehow the GUI's not launching...it seems that the cgroups aren't getting mounted, and after they are...it seems that the LXC android is running and stopped at the same time.
[18:10] <ubptgbot> <Heng Ye> Anyone else have an Xperia 10 (kirin)?
[18:20] <ubptgbot> <Achim ES> @lejocelyn [ah yes, you're using it actually, and you don't have the streets' names displaye …], Indeed. Have you tried HERE, former Nokia maps?
[18:25] <ubptgbot> <Achim ES> Is there a German UBports group?
 https://t.me/UBports_Deutsch
 @Heng Ye [I'm trying to port Xperia 10 with GSI, but there's some weird problem with the L …], https://t.me/xperia_x_ut
[18:38] <ubptgbot> DonClementi was added by: DonClementi
 Hi! 😃
 @DonClementi [Hi! 😃], hello,
[18:40] <ubptgbot> <Achim ES> @FJW_Schnettler [https://t.me/UBports_Deutsch], Danke :-)
 Almost time for the live stream I think
 @mateosalta [Almost time for the live stream I think], Yes we hear you ^^
 Already wrming up
 [Edit] Already warming up
 :)
 I really like these, it really gives the community a view of what is happening
[19:02] <ubptgbot> <Achim ES> @mateosalta [Almost time for the live stream I think], Which live stream?
 https://www.youtube.com/watch?v=H4ef2HWVmQs
[19:15] <ubptgbot> <Heng Ye> @FJW_Schnettler It's a different device, Xperia X and 10. I'll see tho
 @Heng Ye [@FJW_Schnettler It's a different device, Xperia X and 10. I'll see tho], you'll probably want to ask in https://t.me/halium instead
[19:17] <ubptgbot> <Heng Ye> 👍'
[19:17] <ubptgbot> <Heng Ye> is it possible to boot ubuntu touch with hybris-boot?
 @neothethird what about the Pinebook?
[19:27] <ubptgbot> NoDataMusic was added by: NoDataMusic
[19:32] <ubptgbot> wxlNyF was added by: wxlNyF
 @DiogoConstantino [@neothethird what about the Pinebook?], just that the installer can now build for arm64 and armhf
 ah okj
 [Edit] ah ok
 @UniversalSuperBox that's a nice problem to have, lets raise the value
 @UniversalSuperBox both types of Q&A are useful to the community
[19:53] <topoi> Hello folks. I am trying to cross compile "mg" (and maybe thereafter some other tools); I barely (cross-)compile, so what is the prefered way to do so?
[19:58] <topoi> There is no problem with compiling simple things with "arm-linux-gnueabi-gcc -static", but where do I have to configure it in larger projects? There surely is some standard I'm not aware of.
 @topoi [There is no problem with compiling simple things with "arm-linux-gnueabi-gcc -st …], are you trying to build a click package for UT?
[20:00] <topoi> I just want to compile some (recent) commandline utilities like mg, openvpn, tmux, etc. when accessing the phone via ssh.
 @topoi [I just want to compile some (recent) commandline utilities like mg, openvpn, tmu …], if you're starting from debian package sources, you can maybe use https://github.com/ubports/crossbuilder to create deb packages and then unpack the built packages to get the binaries
[20:01] <topoi> To replace all "gcc" with "arm-linux-gnueabi-gcc" inside "./configure" might not be the usual way to do I assumed?
 @topoi [To replace all "gcc" with "arm-linux-gnueabi-gcc" inside "./configure" might not …], `CC=<whatever_abi ./configure` should work i guess
 or you can use `--target` and `--host` options for `configure` i think
[20:06] <topoi> Ohh well.. of course. That sounds sane, thanks!! =) I'll look into all your suggestions, dohbee. I'm new to UT, so haven't yet looked into clickables.
 (Photo, 620x941) https://irc.ubports.com/bqOgubPV.png
[20:07] <ubptgbot> big_based_bot was added by: big_based_bot
 @UniversalSuperBox (for the Q and A) my friend made a port for the Xiaomi A2 and said that you refused to merge it to CI, is there a reason behind this?
 I haven't refused, I just haven't had time
 @UniversalSuperBox [I haven't refused, I just haven't had time], Ah okay, fair enough
 O actually hand wave you guys when you say bie
 [Edit] O actually hand wave you guys when you say bye
 [Edit] I actually hand wave you guys when you say bye
 :D
 @DiogoConstantino [I actually hand wave you guys when you say bye], that's so adorable
[20:17] <ubptgbot> Pat was added by: Pat
 We're over at https://whereby.com/ubports-chat if you want to chat with us!
[21:17] <topoi> Ohh nice, "CFLAGS=-static ./configure  --host=arm-linux-gnueabi --build=x86_64-linux-gnu" did the trick for me compiling mg; well except the "shared libraries from the glibc version used for linking". ;)
[21:55] <ubptgbot> رز کریت was added by: رز کریت
[23:37] <ubptgbot> McMarius11 was added by: McMarius11


[03:17] <lotuspsychje> good morning
[17:54] <sem> good morning lotuspsychje
[21:46] <Bashing-om> UWN: Issue821 now available to our reading public: https://discourse.ubuntu.com/t/ubuntu-weekly-newsletter-issue-821/41330 :D


[00:00] <ehashman> re: https://irclogs.ubuntu.com/2018/07/25/%23ubuntu-release.html#t13:56 the issue is that node vendors upstream openssl (and since it's 1.0 and upstream, it doesn't have symbol versions), and then node exports those symbols as part of *its* ABI (cc apw)
[00:01] <ehashman> and I agree that this is bonkers and I am trying to help them figure out a better strategy...
[00:03] <ehashman> because the symbols are unversioned, that makes this bug particularly sticky. my goals are to get this fixed in node upstream by helping them figure out a better ABI strategy (that will probably take a stable release cycle), to get this fixed in Debian by upgrading to node 10.x (since we want to drop openssl 1.0 support in buster and that kills two birds with one stone), and
[00:05] <ehashman> to hopefully fix this in Ubuntu by patching node 8.x there to use the right major version of openssl, because right now we have a massive ABI mismatch in which we have unversioned symbols in upstream from 1.0 vs versioned, incompatible symbols in 1.1... in its current state, you can't compile or run native extensions against ubuntu's nodejs
[00:06] <ehashman> infinity: this also may be of interest to you as you were commenting in said backscroll
[00:08] <ehashman> for the average nodejs user I'd say this renders nodejs in Ubuntu totally broken (since they will want to be able to use stuff they npm install against system node, similar to python users downloading stuff with pip and expecting it to work)
[04:29] <tjaalton> any archive admin: xorg-lts-transitional needs to move out of NEW
[05:12] -queuebot:#ubuntu-release- New binary: nsync [s390x] (cosmic-proposed/none) [1.20.1-1] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: poezio [s390x] (cosmic-proposed/universe) [0.11+git20180805-1] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: poezio [ppc64el] (cosmic-proposed/universe) [0.11+git20180805-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: nsync [amd64] (cosmic-proposed/universe) [1.20.1-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: nsync [ppc64el] (cosmic-proposed/universe) [1.20.1-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: poezio [i386] (cosmic-proposed/universe) [0.11+git20180805-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: nsync [arm64] (cosmic-proposed/universe) [1.20.1-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: poezio [amd64] (cosmic-proposed/universe) [0.11+git20180805-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: poezio [arm64] (cosmic-proposed/universe) [0.11+git20180805-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: poezio [armhf] (cosmic-proposed/universe) [0.11+git20180805-1] (no packageset)
[05:19] -queuebot:#ubuntu-release- Unapproved: samba (trusty-proposed/main) [2:4.3.11+dfsg-0ubuntu<IP_ADDRESS> => 2:4.3.11+dfsg-0ubuntu<IP_ADDRESS>] (core)
[05:20] -queuebot:#ubuntu-release- Unapproved: samba (xenial-proposed/main) [2:4.3.11+dfsg-0ubuntu<IP_ADDRESS> => 2:4.3.11+dfsg-0ubuntu<IP_ADDRESS>] (core)
[05:30] -queuebot:#ubuntu-release- Unapproved: open-vm-tools (bionic-proposed/main) [2:10.2.0-3ubuntu3 => 2:10.3.0-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[05:41] -queuebot:#ubuntu-release- New binary: dovecot [s390x] (cosmic-proposed/main) [1:<IP_ADDRESS>-1ubuntu1] (ubuntu-server)
[05:44] -queuebot:#ubuntu-release- New binary: dovecot [ppc64el] (cosmic-proposed/main) [1:<IP_ADDRESS>-1ubuntu1] (ubuntu-server)
[05:45] -queuebot:#ubuntu-release- New binary: dovecot [amd64] (cosmic-proposed/main) [1:<IP_ADDRESS>-1ubuntu1] (ubuntu-server)
[05:45] -queuebot:#ubuntu-release- New binary: dovecot [i386] (cosmic-proposed/main) [1:<IP_ADDRESS>-1ubuntu1] (ubuntu-server)
[05:49] -queuebot:#ubuntu-release- New binary: dovecot [arm64] (cosmic-proposed/main) [1:<IP_ADDRESS>-1ubuntu1] (ubuntu-server)
[05:50] -queuebot:#ubuntu-release- New binary: dovecot [armhf] (cosmic-proposed/main) [1:<IP_ADDRESS>-1ubuntu1] (ubuntu-server)
[06:28] <tsimonq2> So, it seems Qt is blocked on ffmpeg, which needs its ppc64el test sorted out...
[06:30] <tsimonq2> I can't seem to make heads or tails of this failure... harumph.
[06:31] <acheronuk> and the remaining FTBFS stuff against ffmpeg 4 fixed or kicked to the kerb
[06:33] <tsimonq2> Right, I was just sorting through these... hmmm
[06:38] <acheronuk> some have fixes in debian bugs, some have a fix bus doesn't apply well to the current patched source, some could maybe just be booted to -proposed.....
[06:39] <acheronuk> lovely!
[06:40] <tsimonq2> I've reached my time limit for today... I'm going to bed; maybe later I'll go through and fix some of these RC bugs in Debian, and try to get a list of things that need booting to -proposed.
[06:40] <tsimonq2> Help fixing that ppc64el test failure would be appreciated, though.
[06:41] <tsimonq2> Ciao o/
[06:41] <acheronuk> strigi can be removed from archive when amarok in -proposed can go to -release
[06:41] <acheronuk> tsimonq2: thanks
[07:43] <apw> ehashman, that is a tricky problem, as anyone already installing nodejs and using it has the oposite problem; slangasek ^^
[08:11] -queuebot:#ubuntu-release- Unapproved: accepted rax-nova-agent [source] (bionic-proposed) [2.1.15-0ubuntu1~18.04.0]
[08:19] <tjaalton> apw: can you push xorg-lts-transitional through NEW?
[08:20] <tjaalton> would be one less step in getting xserver update to cosmic..
[08:21] <apw> tjaalton, if they are transitionals for something, how come they are New ?
[08:22] <tjaalton> apw: new package names
[08:22] <apw> right, but if they are transitionals they should be old names by definition
[08:23] <tjaalton> bionic has the old names, -hwe-16.04 -> stock
[08:23] <tjaalton> this is for the next stack which doesn't even exist yet
[08:24] <apw> so we are making transitionals for something which doesn't even exist ?
[08:24] <tjaalton> traditionally it would be removed from the devel series at this point, and reintroduced to the next lts
[08:24] <apw> so i am confused how this will un
[08:24] <apw> unblock anything
[08:25] <apw> tjaalton, but i assume you are saying you are about to introduce these into bionic ?
[08:25] <tjaalton> in a few months
[08:26] <tjaalton> once there's something to backport
[08:26] <apw> so this upload is about actually removing the 16.04 ones really
[08:26] <tjaalton> there are drivers that haven't been rebuilt for the new abi, because I want the gone, but that bug hasn't seen any action since may
[08:27] <apw> it is the removal of the 16.04 ones in this upload that lets us migrate ?
[08:27] -queuebot:#ubuntu-release- Unapproved: rejected catfish [source] (bionic-proposed) [1.4.6-0ubuntu<IP_ADDRESS>]
[08:28] <tjaalton> aiui if the dep can't be installed, then the transitional isn't installalbe
[08:28] <tjaalton> or would become uninstallable with the xserver from proposed
[08:28] <tjaalton> that's why
[08:28] <apw> tjaalton, right, so i think we are saying we have 16.04 transitionals pointing to things which go away if xorg migrates, and
[08:29] <apw> this new transitionals doesn't reference them at all ?
[08:29] <tjaalton> so this new pkg actually removes all the drivers that haven't been rebuilt
[08:29] <tjaalton> so actually, to unblock I could just readd the -hwe-16.04 names
[08:29] <tjaalton> apw: right
[08:30] <apw> i am wondering if removing this thing from -release makes as much sense
[08:30] <tjaalton> the idea was to allow upgrades from lts with hwe stack to an interim release
[08:31] <apw> but i guess it is safe to do that as much with this one if we decide the dangling is embaressing
[08:31] <tjaalton> avoids an sru
[08:31] <apw> right and they should exist for sure once this all exists in bionic ... just feels a bit odd to have it before they exist
[08:31] <tjaalton> sure
[08:31] <apw> but, we can argue about that as much as we can about the -hwe-16.04 ones existing poinlessly now
[08:32] <apw> and as safely in either pocket
[08:32] <tjaalton> well, for the unblock I can just go back to old names and only drop the drivers
[08:32] <tjaalton> either way
[08:34] -queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [amd64] (cosmic-proposed) [3:14.2]
[08:34] -queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [armhf] (cosmic-proposed) [3:14.2]
[08:34] -queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [ppc64el] (cosmic-proposed) [3:14.2]
[08:34] -queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [arm64] (cosmic-proposed) [3:14.2]
[08:34] -queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [i386] (cosmic-proposed) [3:14.2]
[08:34] <apw> tjaalton, ^
[08:35] <tjaalton> apw: thanks
[08:35] <tjaalton> if you have more cycles to spare, there's always bug 1772588 ;)
[08:46] -queuebot:#ubuntu-release- New: accepted barclay [amd64] (cosmic-proposed) [2.1.0-2]
[08:46] -queuebot:#ubuntu-release- New: accepted boohu [arm64] (cosmic-proposed) [0.9.0-1]
[08:46] -queuebot:#ubuntu-release- New: accepted boohu [i386] (cosmic-proposed) [0.9.0-1]
[08:46] -queuebot:#ubuntu-release- New: accepted boohu [s390x] (cosmic-proposed) [0.9.0-1]
[08:46] -queuebot:#ubuntu-release- New: accepted boohu [amd64] (cosmic-proposed) [0.9.0-1]
[08:46] -queuebot:#ubuntu-release- New: accepted boohu [ppc64el] (cosmic-proposed) [0.9.0-1]
[08:46] -queuebot:#ubuntu-release- New: accepted boohu [armhf] (cosmic-proposed) [0.9.0-1]
[08:46] -queuebot:#ubuntu-release- New: accepted dbus-glib [amd64] (cosmic-proposed) [0.110-3]
[08:46] -queuebot:#ubuntu-release- New: accepted dbus-glib [armhf] (cosmic-proposed) [0.110-3]
[08:46] -queuebot:#ubuntu-release- New: accepted dbus-glib [ppc64el] (cosmic-proposed) [0.110-3]
[08:46] -queuebot:#ubuntu-release- New: accepted gamemode [amd64] (cosmic-proposed) [1.2-3]
[08:47] -queuebot:#ubuntu-release- New: accepted jaxrpc-api [amd64] (cosmic-proposed) [1.1.2-1]
[08:47] -queuebot:#ubuntu-release- New: accepted moksha.common [amd64] (cosmic-proposed) [1.2.5-1]
[08:47] -queuebot:#ubuntu-release- New: accepted poezio [arm64] (cosmic-proposed) [0.11+git20180331-1]
[08:47] -queuebot:#ubuntu-release- New: accepted poezio [ppc64el] (cosmic-proposed) [0.11+git20180331-1]
[08:47] -queuebot:#ubuntu-release- New: accepted dbus-glib [arm64] (cosmic-proposed) [0.110-3]
[08:47] -queuebot:#ubuntu-release- New: accepted dbus-glib [s390x] (cosmic-proposed) [0.110-3]
[08:47] -queuebot:#ubuntu-release- New: accepted libpgobject-util-pseudocsv-perl [amd64] (cosmic-proposed) [2-1]
[08:47] -queuebot:#ubuntu-release- New: accepted poezio [armhf] (cosmic-proposed) [0.11+git20180331-1]
[08:47] -queuebot:#ubuntu-release- New: accepted dbus-glib [i386] (cosmic-proposed) [0.110-3]
[08:47] -queuebot:#ubuntu-release- New: accepted poezio [amd64] (cosmic-proposed) [0.11+git20180331-1]
[08:47] -queuebot:#ubuntu-release- New: accepted gatk-native-bindings [amd64] (cosmic-proposed) [1.0.0-2]
[08:47] -queuebot:#ubuntu-release- New: accepted poezio [i386] (cosmic-proposed) [0.11+git20180331-1]
[08:47] -queuebot:#ubuntu-release- New: accepted poezio [amd64] (cosmic-proposed) [0.11+git20180805-1]
[08:47] -queuebot:#ubuntu-release- New: accepted poezio [armhf] (cosmic-proposed) [0.11+git20180805-1]
[08:47] -queuebot:#ubuntu-release- New: accepted poezio [ppc64el] (cosmic-proposed) [0.11+git20180805-1]
[08:47] -queuebot:#ubuntu-release- New: accepted s-tui [amd64] (cosmic-proposed) [0.7.5-1]
[08:47] -queuebot:#ubuntu-release- New: accepted unibetacode [amd64] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted unibetacode [armhf] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted unibetacode [ppc64el] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted utf8gen [amd64] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted utf8gen [armhf] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted poezio [s390x] (cosmic-proposed) [0.11+git20180331-1]
[08:47] -queuebot:#ubuntu-release- New: accepted poezio [i386] (cosmic-proposed) [0.11+git20180805-1]
[08:47] -queuebot:#ubuntu-release- New: accepted trace2dbest [amd64] (cosmic-proposed) [3.0.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted unibetacode [i386] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted utf8gen [arm64] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted utf8gen [ppc64el] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted utfcheck [amd64] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted utfcheck [armhf] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted poezio [arm64] (cosmic-proposed) [0.11+git20180805-1]
[08:47] -queuebot:#ubuntu-release- New: accepted unibetacode [arm64] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted utf8gen [i386] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted utfcheck [arm64] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted poezio [s390x] (cosmic-proposed) [0.11+git20180805-1]
[08:47] -queuebot:#ubuntu-release- New: accepted utf8gen [s390x] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted unibetacode [s390x] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted utfcheck [i386] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted utfcheck [ppc64el] (cosmic-proposed) [1.1-1]
[08:47] -queuebot:#ubuntu-release- New: accepted wsclean [amd64] (cosmic-proposed) [2.6-1]
[08:47] -queuebot:#ubuntu-release- New: accepted wsclean [armhf] (cosmic-proposed) [2.6-1]
[08:48] -queuebot:#ubuntu-release- New: accepted wsclean [ppc64el] (cosmic-proposed) [2.6-1]
[08:48] -queuebot:#ubuntu-release- New: accepted yubikey-manager [amd64] (cosmic-proposed) [0.7.1-1]
[08:48] -queuebot:#ubuntu-release- New: accepted utfcheck [s390x] (cosmic-proposed) [1.1-1]
[08:48] -queuebot:#ubuntu-release- New: accepted wsclean [i386] (cosmic-proposed) [2.6-1]
[08:48] -queuebot:#ubuntu-release- New: accepted wsclean [arm64] (cosmic-proposed) [2.6-1]
[08:48] -queuebot:#ubuntu-release- New: accepted wsclean [s390x] (cosmic-proposed) [2.6-1]
[08:48] -queuebot:#ubuntu-release- Unapproved: accepted vala [source] (bionic-proposed) [0.40.8-0ubuntu1]
[09:18] <bluesabre> Unapproved: rejected catfish [source] (bionic-proposed) [1.4.6-0ubuntu<IP_ADDRESS>] ? Why was the catfish SRU rejected?
[09:36] <rbasak> ehashman: o/
[09:37] <rbasak> ehashman: yeah that was going to be roughly my suggestion. It's quite OK to suggest that the ABI be versioned to differentiate these cases. But how ABI versioning works is dictated by upstream. Ideally these would be accomodated for in the best possible way, automatically, by upstream code.
[09:46] -queuebot:#ubuntu-release- New binary: gkl [amd64] (cosmic-proposed/universe) [0.8.5+dfsg-1] (no packageset)
[09:58] <apw> bluesabre, normally you get an email, and if it was done via the tooling (which it should) i believe it puts it in your SRU bug too
[10:00] <acheronuk> apw: would you have time to look at: https://code.launchpad.net/~rikmills/britney/hints-ubuntu/+merge/347451
[10:02] <apw> acheronuk, hmmm, that is a bit brutal
[10:03] <bluesabre> apw: hm, says "Rejected by Łukasz Zemczak: Deprecated by a newer upload." I don't think there has been another bionic upload for it, so guess I need to have it sponsored again?
[10:04] <acheronuk> apw: either that or I have to keep a delta with debian to skip it as we did. it would be better for me if I could just let it sync in future, but I'll put the delta back if you don't like the hint
[10:04] <apw> acheronuk, i am mulling, it is more the lack of a way to express what i want
[10:36] -queuebot:#ubuntu-release- Unapproved: nvidia-settings (bionic-proposed/main) [390.42-0ubuntu1 => 390.77-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[11:12] -queuebot:#ubuntu-release- New binary: python-uinput [s390x] (cosmic-proposed/none) [0.11.2-1] (no packageset)
[11:14] -queuebot:#ubuntu-release- New binary: python-uinput [ppc64el] (cosmic-proposed/universe) [0.11.2-1] (no packageset)
[11:14] -queuebot:#ubuntu-release- New binary: python-uinput [amd64] (cosmic-proposed/universe) [0.11.2-1] (no packageset)
[11:14] -queuebot:#ubuntu-release- New binary: python-uinput [i386] (cosmic-proposed/universe) [0.11.2-1] (no packageset)
[11:19] -queuebot:#ubuntu-release- New binary: python-uinput [arm64] (cosmic-proposed/universe) [0.11.2-1] (no packageset)
[11:19] -queuebot:#ubuntu-release- New binary: python-uinput [armhf] (cosmic-proposed/universe) [0.11.2-1] (no packageset)
[11:19] <acheronuk> apw: ok. mull at your leisure
[11:21]  * acheronuk retries test in case it behaves better with Qt 5.11
[11:22] <acheronuk> not very hopeful, but you never know
[11:49] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-31.33] (core, kernel)
[11:50] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-31.33] (core, kernel)
[12:01] <acheronuk> still fails
[12:07] <ehashman> apw: what is the opposite problem in this context
[12:18] <apw> ehashman: that people already on the releae maybhave things using the ubuntu abi
[12:26] -queuebot:#ubuntu-release- Unapproved: amd64-microcode (trusty-proposed/main) [3.20180524.1~ubuntu<IP_ADDRESS>+really20130710.1 => 3.20180524.1~ubuntu<IP_ADDRESS>+really20130710.1ubuntu1] (no packageset)
[13:12] <ehashman> apw: no, it's not possible. as reported on the bug, the ABI incompat also broke the ability to compile native extensions
[13:12] <ehashman> that is what the release team seemed worried about
[13:13] <apw> ehashman, ahh ok, then that piece of information needs to get to slangasek as he was reviewing this change
[13:13] <ehashman> it is on the bug report
[13:14] <ehashman> no less than three times
[13:14] <ehashman> but perhaps I should file a summary comment
[13:27] <apw> yeah do that, and steve should see this here as well
[13:49] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-31.33~16.04.1] (kernel)
[13:49] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1020.20] (kernel)
[13:50] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1020.20~16.04.1] (no packageset)
[13:52] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-31.33~16.04.1] (kernel)
[13:55] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1020.20~16.04.1]
[13:55] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-31.33~16.04.1]
[13:55] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-31.33~16.04.1]
[13:55] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1020.20]
[13:55] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-31.33]
[13:55] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-31.33]
[14:10] -queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1014.17] (kernel)
[14:20] -queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1014.17]
[15:02] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/none) [4.15.0-1016.17] (no packageset)
[15:12] <stgraber> can someone look at squashfs-tools in xenial-proposed queue? relevant to that whole fscaps discussion on ubuntu-devel (fixing unsquashfs on xenial to not strip them)
[15:20] <blackboxsw> RAOF:  any chance we can publish cloud-init 18.3-9-g2e62cb8a-0ubuntu1~16.04.2  from -proposed into -updates the previous SRU  (18.3-9...16.04.1) had aged about 3 weeks before we found a trivial bug that needed fixing. https://bugs.launchpad.net/cloud-init/+bug/1784685
[15:20] <blackboxsw> he only change between cloud-init 18.3-9-g2e62cb8a-0ubuntu1~16.04.1 and .16.04.2 is the cherry picked bug fix for the above bug. Same thing with 18.04.1 and 18.04.2, just a cherry pick.
[15:20] <blackboxsw> all verification logs are attached to SRU process bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1777912
[15:27] <slangasek> ehashman, apw: yes, I've seen the follow-up comments on the bug, I appreciate having that clarified.  I do intend to re-review with an eye towards accepting, in the light of this clarification.  If someone were to fix up the SRU template in the bug description to be accurate, that would save me a step
[16:03] <ehashman> huzzah
[16:03] <ehashman> I don't know if I have access
[16:06] <sil2100> ugh, please ignore the bionic subiquity upload
[16:06] <sil2100> Miss-dput
[16:07] -queuebot:#ubuntu-release- Unapproved: subiquity (bionic-proposed/universe) [0.0.29 => 0.0.29+18.04.1] (no packageset)
[16:08] -queuebot:#ubuntu-release- Unapproved: rejected subiquity [source] (bionic-proposed) [0.0.29+18.04.1]
[17:17] -queuebot:#ubuntu-release- New binary: golang-github-gogo-googleapis [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: gotest.tools [amd64] (cosmic-proposed/universe) [2.1.0-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: r-cran-flexmix [amd64] (cosmic-proposed/universe) [2.3-14-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: python-ulmo [amd64] (cosmic-proposed/universe) [0.8.4-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: r-cran-prabclus [amd64] (cosmic-proposed/universe) [2.2-6-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: r-cran-gclus [amd64] (cosmic-proposed/universe) [1.3.1-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: r-cran-trimcluster [amd64] (cosmic-proposed/universe) [0.1-2.1-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: photutils [ppc64el] (cosmic-proposed/universe) [0.5-1] (no packageset)
[17:21] -queuebot:#ubuntu-release- New binary: photutils [amd64] (cosmic-proposed/universe) [0.5-1] (no packageset)
[17:24] -queuebot:#ubuntu-release- New binary: photutils [i386] (cosmic-proposed/universe) [0.5-1] (no packageset)
[17:38] -queuebot:#ubuntu-release- New binary: photutils [arm64] (cosmic-proposed/universe) [0.5-1] (no packageset)
[17:40] -queuebot:#ubuntu-release- New binary: photutils [armhf] (cosmic-proposed/universe) [0.5-1] (no packageset)
[19:28] -queuebot:#ubuntu-release- New binary: designate [amd64] (cosmic-proposed/main) [1:7.0.0~b3-0ubuntu1] (openstack, ubuntu-server)
[19:58] <teward> is there a known reason why do-release-upgrade doesn't work for 16.04 -> 18.04 without defining -d in the process?
[19:58] <teward> (which then properly finds 18.04.1)
[19:59] <acheronuk> teward: because upgrades have not been enabled yet
[19:59] <teward> acheronuk: ah, that'd explain it, know what the timeline is for that?
[19:59] <teward> because I have at least 80 people whining on Ask Ubuntu about it, and I'd like to give people an answer they can live with
[19:59] <acheronuk> there are some gnome upgrade bugs to be fixed, so when they are sorted
[19:59] <teward> so "Once they fix GNOME" problems then.
[20:00] <teward> acheronuk: got a specific list of the bugs so I can watch them?
[20:00] <teward> or a task list somewhere would work too
[20:01] <acheronuk> LP #1766890
[20:01] <acheronuk> that is the main issue I saw mentioned in #ubuntu-meeting at end of last week
[20:02] <teward> acheronuk: thanks, i'll keep this on my radar.
[20:03] <slangasek> NB we didn't find any bugs in GNOME there, and the fix is to early-upgrade libc6 to remove any trigger loops
[20:04] <slangasek> so it's not provably "just a desktop issue" either
[20:05] <acheronuk> slangasek: right. thanks for clarifying. I'd only given it a cursory look the other day
[20:07] <teward> slangasek: wouldn't any type of early upgrade necessitate changes in Xenial as well then?  Or would that early-upgrade be done during the d-r-u process?  Just for my curiosity
[20:07] <teward> (I always clean-install and then transfer data, I never do in-place upgrades, but i"m tired of fifty dupe questions heh)
[20:07] <slangasek> teward: the upgrader code always runs from the upgrader tarball associated with the target release; that's what's being changed for that bug, the bionic release-upgrader tarball
[20:07] <teward> ahh, I see.
[20:08] <teward> makes sense.
[20:08] <slangasek> this design also makes it possible to fix bugs affecting upgrades from EOL releases we can no longer SRU to, which is handy in general ;)
[20:09] <slangasek> anyway, juliank was working on that u-r-u change today and I've just re-reviewed his MP and approved it, so that should move forward some tomorrow
[20:09] <teward> indeed that does, slangasek, hopefully everything works :)
[20:10] <teward> sorry to prod and ask for details, thanks for sharing the info.
[20:16] <teward> slangasek: glad to hear that things're moving forward, I assume that there'll be an announcement when the upgrade path is open or something?
[20:18] <slangasek> I don't believe we do a separate announcement for that
[20:18] <slangasek> because everybody gets an announcement in their motd and on their desktop
[20:18] <teward> ah, good point.  I'll look forward to when the upgrade path is available so I don't have to keep watching the same 20 people keep asking the same question over and over again about when the upgrade paths will be available
[22:31] <stgraber> slangasek: I don't suppose I can have you review that squashfs-tools upload for xenial? :)
[22:31] <stgraber> you know, since you started that whole fscaps thing :)
[22:33] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1016.17]
[22:35] <slangasek> stgraber: my SRU review day is Friday, can it wait until then?
[22:35] <stgraber> slangasek: yeah, should be fine, maybe someone else will feel like review it before then, will nag you on Friday if nobody does by then
[22:36] <rbasak> I'm hoping to have time during my SRU day tomorrow.
[22:36] <stgraber> rbasak: thanks!
[22:36] <rbasak> But my time is being a little disrupted for personal reasons. I will make it up, but that's why I'm not sure it'll be tomorrow.
[22:37] <stgraber> should be a pretty quick one, both patches are simple and look obviously true, they both have testcases and have both been in Ubuntu and Debian for a while. The hardest part is making sense of the diff since things get re-ordered to match bionic/cosmic.
[22:39] <rbasak> ack. I'd do it now but I'm trying to get something else finished right now before I finish for the day.


[01:37] <beisner> thedac, wolsen, gnuoy, coreycb, dosaboy - fix for bug 1485722 proposed and tested.  i view this as critical as it is a deployment blocker for Vivid and later when nrpe is related to rmq.  please & thanks :-)
[01:37] <mup> Bug #1485722: rmq + nrpe on >= Vivid No PID file found <amulet> <openstack> <uosci> <nrpe (Juju Charms Collection):Invalid> <rabbitmq-server (Juju Charms Collection):New> <https://launchpad.net/bugs/1485722>
[01:38] <wolsen> beisner, well sir let me go look
[01:42] <wolsen> beisner - added a comment
[01:43] <wolsen> beisner, please take a look - if I don't hear back I can fix it in the merge as the rest of the change looks fine
[01:45] <beisner> wolsen, removed a cat :-)
[01:46] <wolsen> beisner, awesome, those pesky felines getting in the way :)
[01:46] <wolsen> cats, rabbits, meh
[01:48] <wolsen> beisner, this is backport-potential yes?
[01:48] <beisner> wolsen, definitely
[01:48] <beisner> wolsen, affects next and stable rmq + nrpe
[01:48] <beisner> well just the rmq charm but nrpe users will hurt
[01:48] <wolsen> beisner, yuppers - though its slightly mitigated by not affecting an lts version - but ya
[01:49] <beisner> wolsen, it'll be a MP blocker once those tests land ;-)   then it'll get heat if it doesn't already have any.
[01:49] <wolsen> beisner, +1 on that
[01:49] <wolsen> beisner, I was noticing earlier with a proposal that jillr put up - there's not a lot of test around some of the nrpe stuff - which is something we should mark for improvement somewhere
[01:50] <beisner> wolsen, i added a comment on that fyi
[01:50] <beisner> basically to hang tight while we iron out these crits
[01:50] <beisner> then resubmit
[01:51] <wolsen> beisner, ah ok - hadn't looked at it too closely, but was trying to help jillr take a look at it
[01:51] <wolsen> beisner, did she retarget? I had asked her to retarget /next (honestly haven't looked at that)
[01:51] <beisner> wolsen, yep.  but it's running the old tests, which as we know now, lead to releasing broken-ass charms.
[01:51] <wolsen> beisner, ack
[01:52] <beisner> wolsen, hence the hang-tight, then rebase & resubmit review.  no sense in not-testing any additional features.
[01:53] <beisner> biab, thanks for the check-in wolsen
[01:55] <wolsen> beisner, landed
[02:01] <beisner> wolsen, thanks sir
[02:03] <wolsen> beisner, np
[13:17] <Walex> Hi I am trying to login to the Juju MongoDB instance and I am getting "not authorized" errors. I am using '-u admin' and '-p ....' from the '/var/lib/juju/agents/machine-0/agent.conf' file (API and state password are the same). The 'mongod' instance with started with '--keyFile ....' but there does not seem to be an equivalent option for the 'mongo' client. Suggestions welcome.
[13:23] <Walex> also curiously all three members of the replica set have different passwords. How does one member log into the other members?
[13:27] <lazyPower> Walex: MongoDB replicaset passwords are cluster specific, so typically you log in through a mongos gateway to reach your cluster nodes
[13:27] <lazyPower> however i'm not certain how you would log in and poke around in the Juju DB - thats a good question. The core devs probably would have some insight here
[13:28] <Walex> lazyPower: http://www.metaklass.org/how-to-recover-juju-from-a-lost-juju-openstack-provider/ has a suggestion which I tried...
[13:28] <lazyPower> natefinch:  wwitzel3 - Any insight for Walex on how they can cannect to the jujudb?
[13:30] <Walex> lazyPower: maybe I am using the wrong terms here, I don't see any 'mongos' daemons running on the nodes. I meant perhaps the state servers.
[13:31] <Walex> the 3 nodes can log into each other obviously (I see the port 37017 traffic)...
[13:32] <Walex> but that's obviously done with the replica set keyfile.
[13:32] <lazyPower> right. I'm not so familiar with how our juju stateserver is setup to be honest. i just know it exists and what function it serves
[13:32] <lazyPower> the experience i speak of is from running a distributed monogdb cluster
[13:33] <Walex> will wait or perhaps later send a mailing list message.
[13:33] <wwitzel3> let me see if I can remember
[13:34] <natefinch> you use the oldpassword field from the agent config on machine 0....
[13:35] <natefinch> I forget the exact incantation
[13:35] <Walex> natefinch: I'll try again
[13:35] <Walex> natefinch: in http://www.metaklass.org/how-to-recover-juju-from-a-lost -juju-openstack-provider/
[13:35] <Walex> there is a plausible looking line
[13:36] <lazyPower> Thanks natefinch and good morning o/
[13:36] <Walex> but I use the 'oldpassword' and "auth fails" not sure if 'admin' is the right user
[13:36] <natefinch> Walex: that looks good to me. I usually just get the password the old fashioned way (copy and paste) but assuming the grep does the right thing, then yes
[13:38] <Walex> ahhhhhhhhh I have just noticed my mistake: I was trying to log into the 'juju' database, not 'admin'. oops
[13:40] <Walex> indeed with "/admin" that works, sorry...
[13:44] <lazyPower> Walex: glad we could get you sorted!
[13:46] <Walex> lazyPower: and I can connect directly to 'localhost:37017/juju' if I add '--authenticationDatabase admin' as an option to 'mongo'
[13:46] <Walex> sorted!
[13:51] <lazyPower> cory_fu: so, if you've got a moment - we got this far yesterday - http://paste.ubuntu.com/12205843/
[13:52] <lazyPower> thats our reactive/nginx.py, down to implementing a relationship stub and the super simple intro to reactive and layers is basically complete. we've mirrored what we use in charm schools to teach charming w/ docker
[13:53] <cory_fu> lazyPower: Would it have killed you to select Python as the language to get syntax highlighting?  ;)
[13:53] <lazyPower> cory_fu: i used pastebinit?
[13:53] <cory_fu> Ah.  Fair enough
[13:55] <cory_fu> I'm surprised pastebinit doesn't guess the format based on the file name
[13:56] <lazyPower> papercutz
[13:56] <cory_fu> :)
[13:59] <lazyPower> cory_fu: thanks for the sync yesterday. that really got mbruzek and I moving. We're going to have this particluar charm wrapped today and ready to move on to extending the base layer(s) and writing docs before the week is up
[14:00] <cory_fu> lazyPower: You have a bit of a bug in your config-changed handler.  It could potentially call stop_container and attempt to issue docker commands before docker is installed
[14:00] <lazyPower> that was critical to resolving things we were doing exploratory dev for
[14:00] <lazyPower> cory_fu: in our testing it was from install =>    and the entire chain ran before it hit a possible stop hook.
[14:00] <lazyPower> what scenario would be exposed that leaves us vulnerable to calling stop before its present
[14:02] <cory_fu> Oh, yeah, I suppose you're right.  docker.available will be set during the install hook, so it's a bit moot.  Though, if your docker base layer ever changes (say to require a repo URL config or something) that could potentially delay docker install until config, it could open you up.  *shrug*
[14:02] <cory_fu> lazyPower: I was going to suggest creating an nginx.restart state that you could set
[14:02] <cory_fu> Would be another potentially useful entrypoint for layers using this
[14:03] <cory_fu> And would future-proof the code against the admittedly non-issue
[14:03] <lazyPower> we thought about that, and i forget why exactly we refactored down to just dropping in a config-changed hook context vs using the state
[14:03] <lazyPower> but it makes sense
[14:11]  * mbruzek starts reading the scrollback
[15:06] <kwmonroe> hey lazyPower, i just deployed cs:trusty/etcd and was met with: http://paste.ubuntu.com/12206396/  have you seen that before?
[15:06] <kwmonroe> ^^ no relations or anything, just "juju deploy cs:trusty/etcd" got me there
[15:16] <mbruzek> hey Kevin that looks aweful
[15:18] <mbruzek> kwmonroe: that looks like our overuse of path.py has come to bite us.
[15:18] <mbruzek> kwmonroe: Can you paste the entire unit log?  Did the pip install path.py not work?
[15:19] <mbruzek> in the install hook
[15:19]  * marcoceppi wears a smug face
[15:19]  * mbruzek waves and nods at marco
[15:21] <kwmonroe> momento mbruzek, i tore that env down, but I'll fetch the logs again shortly
[15:21] <mbruzek> kwmonroe: it looks to me that the install hook does not install pip
[15:32] <Walex> I see that the Juju "command" node(s) don't run (necessarily) any daemon, and that the "state" nodes run 'mongod' from the 'juju-mongodb' package. Also I see that all nodes run 'jujud' from the unit 'tools' directories. I am about to update to 1.24.5. How do the 'jujud' binaries in each unit get updated? When? Are there ordering dependencies among the 'juju-*' packages for upgrade, and among the state servers? ...
[15:32]  * Walex worries about details...
[15:38] <kwmonroe> mbruzek: i betcha you gotta do "from path import Path" (cap P on the 2nd path): http://paste.ubuntu.com/12206611/
[15:38] <mbruzek> kwmonroe: It looks like path.py was updated today!  It is possible that is not working.
[15:39] <mbruzek> kwmonroe: we use lowercase path all over the place.  whit can you help with this problem?
[15:39] <kwmonroe> mbruzek: we use cap P in our big data charms... now fight.
[15:40] <lazyPower> kwmonroe: hmm interesting, let me check the charm code 1 sec kwmonroe
[15:40] <kwmonroe> mbruzek: lazyPower.. i'm just gonna leave this here: https://pypi.python.org/pypi/path.py
[15:49] <lazyPower> kwmonroe: i follow that with the bug hat spawned this issue
[15:49] <lazyPower> https://github.com/jaraco/path.py/issues/102
[15:51] <lazyPower> kwmonroe: but thanks for the heads up on the issue. We'll cut a hotfix patch and get it cueued up - as we are apparently broken in the store now
[15:53] <kwmonroe> gracias lazyPower!
[15:53] <lazyPower> kwmonroe: once we have a fix in place do you mind being the on-call reviewer for that MP? i'll stack it on what you're already reviewing so its applicable :D
[15:54] <kwmonroe> sure lazyPower, i'll be your huckleberry
[15:54] <lazyPower> aww yeee
[16:14] <lazyPower> kwmonroe: broken rel of path.py was just pulled from pypi
[16:14] <lazyPower> ready for you to re-test at your leisure
[16:18] <lazyPower> whoa juju gui just removed its crosshatched background - https://github.com/juju/juju-gui/pull/799
[16:21] <kwmonroe> confirmed lazyPower, latest deploy pulls path.py-7.7.1 and all is right with the world.  would you like a tracking bug requesting s/path/Path for the inevitable time when path does finally go away?
[16:22] <rick_h_> lazyPower: quit watching us :P
[16:22] <lazyPower> kwmonroe: we're going to pin package deps now, and prepare for the inevitable breakage when we have the bandwidth
[16:22] <lazyPower> thats used in a lot of places
[16:22] <lazyPower> and we have a lot of auditing to do
[16:23] <kwmonroe> ack lazyPower.  thanks to you and whit for the nudge to get path-8 out of pypi :)
[16:42] <Walex> I updates packages on master node, now 'juju upgrade-juju' tells me that "no more recent supported versions available"  how do I make a more recent version of the tools available to the nodes?
[16:46] <lazyPower> Walex: when you juju upgrade-juju it should have published a newer version of the tools to your state server
[16:47] <lazyPower> the nodes will slowly start to upgrade once your environment is upgraded if memory serves me correctly
[16:49] <Walex> lazyPower: ahhhhhhh so in theory I just wait. I noticed somewhere a mention of a queue
[16:50] <Walex> ah but just looked at my state servers and I don't see the 1.24.5 directories I'll investigate
[16:58] <Walex> what's peculiar is that when I upgrade 'juju-core' it took many minutes and it is a fairly small package.
[17:00] <wolsen> ackk, regarding our discussion for the keystone pause/resume
[17:00] <ackk> wolsen, yes
[17:01] <wolsen> ackk, so for the clustering support - if we had the support in hacluster charm to move the vip off a node (e.g. get a node in maintenance mode or paused), then I think what is in the keystone charm would be fine actually
[17:01] <wolsen> ackk, the pause and such that is
[17:02] <wolsen> ackk, I still have a concern that if a user were to simply issue the pause against keystone but they hadn't done the appropriate action on the hacluster charm that they could end up with a service disruption
[17:02] <wolsen> which might not be great
[17:02] <ackk> wolsen, right. there are other similar cases where there's more to do than "service foo start/stop". for instance ceph OSDs need to be set to "noout"
[17:03] <wolsen> ackk, right - maybe we can address it with docs around the pause/resume action?
[17:04] <ackk> wolsen, I see your point. I'm a bit worried about putting a lot of logic in a single action and having an action with the same name doing different things across charms
[17:05] <ackk> wolsen, there are other cases where you'd definitely want separate steps, like for nova-compute
[17:05] <wolsen> ackk, that's a fair point, but to me the action defines the semantics of what you want to happen and its up to the charm to define what needs to happen for that action to take place - which can add some complications
[17:05] <wolsen> ackk, that being said lets try to keep it simple until we have to
[17:05] <wolsen> do more
[17:05] <wolsen> ackk, but if we do keep it simple, we still need to be able to inform the user what other actions need to take place
[17:06] <ackk> wolsen, you mean documenting that you should do other stuff before stopping services/
[17:06] <ackk> ?
[17:11] <wolsen> ackk, yep
[17:12] <wolsen> ackk, I'm thinking the action docs would say something about requirements in a clustered scenario, e.g. running the pause action there first
[17:13] <ackk> wolsen, btw what's needed on the hacluster side to move the VIP?
[17:14] <wolsen> ackk, if we could enforce that the action were running first, that'd be great, but that's kind of above and beyond...
[17:14] <wolsen> ackk, for the hacluster - theres the option to move a resource - but the cluster may need to be in maintenance mode as well or the node marked as offline
[17:15] <wolsen> ackk, i'd have to go through the specific details of how to do that (to refresh my memory)
[17:16] <ackk> wolsen, I see. so basically we could add a pair of actions there so that you'd "juju action do pause hacluster-keystone/X; juju action do pause keystone/Y"
[17:16] <ackk> (roughly)
[17:16] <wolsen> ackk, yep
[17:16] <ackk> wolsen, cool
[17:16] <wolsen> ackk, so it'd still keep the building blocks you're looking to add (we can fancy it up in the future if needed)
[17:16] <ackk> wolsen, +1
[17:17] <wolsen> ackk, but the user needs to know that they have to do the multi-step process
[17:17] <ackk> wolsen, agreed
[17:17] <ackk> wolsen, could you sum that up in a comment on the MP?
[17:17] <wolsen> ackk, doing so now
[17:17] <ackk> wolsen, thanks
[17:18] <ackk> wolsen, totally unrelated (but since we're on openstack charms topic), do you know any downside of not using the embedded webserver for ceph-radosgw?
[17:19] <wolsen> ackk, and I think the other proposals which are similar (e.g. glance and percona-cluster) will likely fall into the same - though percona-cluster I think we should carefully think through that in some more depth (I'll try to give some more thought to it)
[17:20] <wolsen> ackk, when not using the embedded server, it doesn't have the 100 continue support built-in to the apache service. Ceph devs used to provide an apache package which had it but they yanked it in favor of the embedded web server
[17:20] <wolsen> ackk, the 100 continue support is necessary for some of the use cases (e.g. using it from the horizon dashboard)
[17:20] <ackk> wolsen, I see
[17:21] <wolsen> ackk, so the preferred way forward is the embedded server
[17:21] <wolsen> ackk, but is there another use case that you have for not using it?
[17:22] <ackk> wolsen, well, we've seen failures in autopilot deploys recently. I'm not sure it's related, but it might have happened since we switched to the embedded server
[17:23] <wolsen> ackk, oh :(
[17:24] <ackk> wolsen, as said it's just a guess, maybe it's an unlucky coincidence
[17:26] <wolsen> ackk, logs and a bug would be great (if you haven't gotten one already)
[17:27] <ackk> wolsen, https://bugs.launchpad.net/charms/+source/ceph-radosgw/+bug/1477225
[17:27] <mup> Bug #1477225: ceph-radosgw died during deployment <cloud-install-failure> <cpec> <ceph-radosgw (Juju Charms Collection):New> <https://launchpad.net/bugs/1477225>
[17:27] <wolsen> ackk, also wanted to say the MP looked really good in general and thanks for that contribution!
[17:27] <ackk> wolsen, np! :)
[17:29] <ackk> wolsen, wrt maintenance, we're also not sure yet of what needs to be done on neutron-gateway nodes (see notes in the doc)
[17:30] <wolsen> ackk, bleh yeah that's tricky as it will almost certainly cause service disruption unless dvr is enabled I believe
[17:30] <ackk> wolsen, specifically if removing/readding the l3router in neutron is needed, and how properly cause a failover if
[17:30] <ackk> wolsen, we deploy with l3ha
[17:30] <wolsen> ackk, ok
[17:30] <ackk> router-ha, that is
[17:31] <ackk> wolsen, still, stopping services on the node is not enough to cause a failover
[17:32] <wolsen> ackk, I'll have to dig into it (I don't have enough background on neutron gateway and ha to be honest)
[17:33] <ackk> wolsen, ok, thanks for the info
[17:33] <ackk> wolsen, and for the review :)
[17:35] <wolsen> ackk, np :-) it was fun!
[17:36] <ackk> heh
[17:52] <kwmonroe> lazyPower: fwiw, i saw pypi went to path.py-8.1 and re-checked etcd.  you're still good.
[17:52] <lazyPower> kwmonroe: above and beyond, thats awesome. Thanks!
[17:52] <kwmonroe> np lazyPower, gives you time to work out which version you want to pin.
[18:00] <whit> lazyPower: this path.py hiccup makes me think we should have an official juju python index
[18:00] <marcoceppi> whit: that sounds like the opposite of what we need, why not just version lock your deps?
[18:01] <whit> marcoceppi: accomplishes the same thing without having to edit all the places the dep is defined everytime you need to update
[18:01] <whit> marcoceppi: think of it as a hierarchy of control
[18:02] <whit> the index is centralized, but under our control (unlike pypi)
[18:02] <whit> then reqfiles and setup.pys become the more granular control
[18:02] <marcoceppi> sounds like a lot of work for little pay off
[18:02] <lazyPower> whit: that sounds like an extra maintenance burden and infrastructure for the sake of running infrastructure. It would yield some benefit, but i'm not certain thats enough to not just version lock deps.
[18:03] <lazyPower> if we had packages constantly getting yanked from pypi, then yes, that sounds like the way to move forward
[18:03] <lazyPower> so we can maintain the versions we depend on that are otherwise disappering
[18:03] <whit> the issue is the "default" version
[18:03] <whit> which is always the most current in the index
[18:03] <lazyPower> well, thats fair, but we also didnt define any of that in our requirements. in 2 places we had blind install path.py on the CLI
[18:04] <whit> if you pin, you no longer will pull newer
[18:04] <lazyPower> and in others we had no version data in the requirements.txt file
[18:04] <marcoceppi> sure, so you should develop a charm, pip freeze, deliver, iterate, pip update, freeze again, release
[18:04] <whit> I don't think you all are grokking how these things scale or the tooling available
[18:05]  * marcoceppi shrugs
[18:05] <whit> just take it as my advice until it makes sense ;)
[18:05] <lazyPower> whit: thats possible
[18:05] <lazyPower> whit: but do we adopt the same thing with companion technologies for other languages? Run our own gem host, npm index, et-al?
[18:05] <whit> think of it as every deploy of any charm as your "product website"
[18:06] <whit> you wouldn't deploy packages straight from pypi to prod
[18:06] <whit> quality control folks
[18:06] <lazyPower> i did :3
[18:06] <whit> ur.. production
[18:06] <lazyPower> and i hated the pain that introduced like today, but we pinned deps then too. we didn't spin up a gem host.
[18:06] <marcoceppi> so, how does pip freeze not solve this?
[18:06] <marcoceppi> I don't want us to be responsible for someone's charm not working because an index is down
[18:07] <marcoceppi> or they're using a newer version than our index or vice versa
[18:07] <whit> marcoceppi: vs. pypi or github being down which you can do nothing about?
[18:08] <marcoceppi> yeah, but we're not responsible and they're all well estabilished services that have a team dedicated to keeping those things running
[18:08] <marcoceppi> no ones perfect but I don't want to run pager duty because we're running our own index
[18:08] <whit> marcoceppi: yeah, but those being down == a crap experience for charm deployment
[18:09] <marcoceppi> and our index being down?
[18:09] <whit> this is an academic example in reliability and control
[18:09] <whit> we can fix that
[18:09] <whit> we can't fix externalities
[18:09] <whit> that's the point of the example
[18:09] <marcoceppi> this is the exact reason SAAS exists
[18:10] <whit> marcoceppi: when your shit break because some elses saas break, you still look like an ass
[18:10] <marcoceppi> if you want to run this for a set of charm syou maintain, sure, that sounds great, I don't think it sets us up for success anymore than what exists with pypi or other services
[18:10] <whit> saas exists so you don't have to build it
[18:10] <whit> but when aws goes down, netflix loses money
[18:11] <marcoceppi> and when yoru shit breaks because you can't run a web service 24/7 due to stafing you look like a bigger ass
[18:11] <whit> marcoceppi: that we can fix ;)
[18:12] <whit> marcoceppi: my general point is that python libraries working are part of charms working and therefore part of a good charming experience
[18:12] <whit> which is important to the success of juju
[18:12] <lazyPower> whit: this sounds more like deps should be bundled with charms.
[18:12] <lazyPower> not that we should run an indexer
[18:12] <marcoceppi> running a proxy isn't a project concern
[18:12] <marcoceppi> it's an operations concern
[18:12] <marcoceppi> we run pypi proxies in our private environments
[18:12] <whit> resources would help, but an index fixes the problem now without the developer issue of pin maintenance
[18:13] <marcoceppi> that just work, leave this for ops people to run themselves, not us
[18:13] <whit> https://pypi.python.org/pypi/devpi
[18:13] <marcoceppi> lunch is here
[18:14] <whit> marcoceppi: yes it is an operations concern.  that we agree on.
[18:14] <whit> who's operation concern and why, we don't
[18:17] <lazyPower> whit: actually the fact we were pulling from pypi and not some mirror helped us today... had we still had the 8.0 copy cached we would still be broken in the charm store right now
[18:17] <rick_h_> whit: marcoceppi fyi from another team's perspective. We've recently discussed talking with IS on running a pypi index in prodstack for our services there and gating/curating. However, we currently have a matching "xxx-download-cache" project for each codebase and build it into the project's build steps.
[18:17] <rick_h_> this allows for complete offline building of code/projects
[18:17] <rick_h_> and completely verison locked w/o internet access (since prodstack has egress firewall locks)
[18:18] <rick_h_> whit: marcoceppi so I guess some additional feedback, I can't not redeploy my produciton because pypi or GH are having DDOS issues atm.
[18:18]  * rick_h_ goes back to lurking
[18:23] <jrwren> Every organization and project has different tollerances for acceptable risk. Some projects may be willing to accept the risk that goes with depending on github or pypi being up, others cannot.
[18:45] <whit> lazyPower: we would have tested the new copy before updating the index
[18:45] <whit> therefore no breakage?
[18:45] <lazyPower> i guess
[18:45]  * lazyPower shrugs
[18:46] <lazyPower> i'm not interested in running a pypi mirror
[18:46] <lazyPower> but if someone else is,i'm thumbs up to them doing it
[18:47] <whit> rick_h_: that sounds good
[18:47] <whit> ideally grabbing and freezing all necessary resources for a charm has lots of benefits
[18:47] <whit> this is the general idea behind IBWFs mas o menos
[18:49] <whit> whether you are building on the fly or building resource blobs or some sort of image, controlling the source material has lots of benefits
[18:50] <whit> image workflows do have the advantage of breaking before deploy (in the build stage) rather than during deploy
[18:53] <jrwren> whit: how far do you take this? what makes archive.ubuntu and PPA different from pypi?
[19:01] <beisner> Fwiw I use devpi caching mirror in uosci
[19:02] <beisner> As doing A lot of iterations revealed pypi weaknesses and false test failures
[20:30] <whit> jrwren: archive.ubuntu is better curated than pypi
[20:30] <whit> ppa is effectively == to a self hosted index if you control the ppa
[20:30] <whit> if you don't, you trust the maintainer, so it depends on the nature of the relationship
[20:31] <jrwren> whit: ah, I thought you were refering to uptime. I used to deal with pypi being down often enough.
[20:31] <whit> so if you run the index, you have a bit more control of the uptime
[20:31] <whit> rather than depending on the packaging vols of pypi
[20:32] <jrwren> yes, my point is, that to a 3rd party, there isn't much difference between pypi and a ppa.
[20:33] <jrwren> Both are out of control systems which present risk.
[20:33] <whit> jrwren: risk is contextual
[20:33] <jrwren> what do you mean?
[20:33] <whit> if i am trying out juju, and my charm fails due to pypi being down, I still will say juju sucks
[20:34] <jrwren> definitely true.
[20:34] <whit> if I'm using juju for a situation I'm invested in, it behooves me to run a debian index and a python index
[20:34] <whit> and my own charm server
[20:34] <jrwren> exactly.
[20:35] <jrwren> or accept the risk of not doing so.
[20:35] <whit> so from the context of eco (and anyone who care bout adoption), controlling the central vectors of potential failure is valuable
[20:35] <whit> yep
[20:36] <whit> a good first time experience is one that works
[20:37] <whit> from our perspective, it's a tradeoff between investing in running, curating and monitoring our own index, vs. the less known cost of random failure
[20:38] <jrwren> its a very good point.
[20:39] <jrwren> it makes me wonder if charms shouldn't declare their external dependencies.
[20:41] <jrwren> certainly with unit status external deps could be handled in the charm an a status-set blocked used to clearly tell end user that an external dep failed.
[20:59] <beisner> +1 to charms declaring external dependencies, at minimum in the form of a README blip.
[21:00] <beisner> That is so much better than having to figure it out via install hook failures when you're sitting behind firewalls and proxies.


[15:30] <jugglerbry> hi all.  i'm in the process of creating a website for complete newbies to ubuntu, and wondered if i could get some constructive feedback ? either through here, or via contact us form on the site ? would anyone mind if I posted the url here ?


[00:24] <mhall119> daker: where did you find ?autoplay=1&autohide=1 for the youtube videos?
[00:24] <daker> youtube api :)
[00:25] <daker> mhall119: ex http://youtube.com/embed/IDXILsX7_QI   this will not play automaticaly
[00:25] <daker> but this will http://www.youtube.com/embed/IDXILsX7_QI?autoplay=1
[00:26] <daker> autohide=1 will hide the tile of the video & the controls buttons
[00:26] <daker> when you hover the video they will show up
[00:27] <cjohnston> nigelb: ping
[00:33] <mhall119> daker: ah, cool, looks good then
[00:33] <daker> it happened to me many times
[00:33] <mhall119> daker: is https://code.launchpad.net/~daker/summit/fix.1147863/+merge/152572 still being worked on?
[00:34] <daker> mhall119: ya
[00:35] <mhall119> daker: so we're still going to allow importing Attendee data from Launchpad, at least that was my understanding
[00:35] <mhall119> cjohnston: ^^ can you confirm or deny?
[00:35] <cjohnston> Yes.
[00:35] <cjohnston> the correct spec is in the description of bug #1147863
[01:19] <JoseeAntonioR> mhall119: hey, I had to run, mind taking a look at it now?
[01:20] <JoseeAntonioR> http://paste.ubuntu.com/5615349/
[01:21] <JoseeAntonioR> it's from lines 112 to 116 and then from 136 to 141
[01:22] <cjohnston> s/S/s JoseeAntonioR
[01:25] <JoseeAntonioR> I'll change and try
[01:26] <JoseeAntonioR> cjohnston: now works for the pad, but the bottom lines don't appear
[01:26] <cjohnston> JoseeAntonioR: https://bazaar.launchpad.net/~summit-hackers/summit/trunk/view/head:/summit/schedule/templates/schedule/actions.html
[01:26] <JoseeAntonioR> yeah, I was taking a look on that and thought on it
[01:27] <cjohnston> I disagree with the changes to the links at the bottom
[01:28] <JoseeAntonioR> ok, so I should keep them as they are now
[01:29] <cjohnston> yes
[01:29] <JoseeAntonioR> cjohnston: see http://joseeantonior.com:8000/uds-r/meeting/149/foundations-r-wubi-redesign/ (does it resolve?)
[01:30] <JoseeAntonioR> the bottom lines are not appearing
[01:30] <JoseeAntonioR> oh, I think I found the error
[01:31] <JoseeAntonioR> and got it working now
[01:31] <JoseeAntonioR> cjohnston: would only meeting.html need the changes?
[01:32] <cjohnston> virt_meeting
[01:32] <cjohnston> and on daily and by_ the irc link should point to the logs
[01:32] <cjohnston> the irc log
[01:32] <cjohnston> everything else i thnk would be ok
[01:34] <JoseeAntonioR> yeah, that's another bug
[01:36] <cjohnston> nah.. same thing
[01:40] <JoseeAntonioR> I still need to figure out how to get the dates :P
[01:41] <JoseeAntonioR> cjohnston: should I also link the branch to the blueprint, or only to the bug?
[01:41] <cjohnston> bug
[02:06] <JoseeAntonioR> cjohnston: how should we link the irc logs instead of the webchat embed? iframe?
[02:08] <cjohnston> yes
[02:10] <JoseeAntonioR> ok, working on the bug now
[02:38] <JoseeAntonioR> cjohnston: problem, I'm working with uds-r and logs aren't in irclogs.ubuntu.com, do you know where are they?
[02:40] <cjohnston> http://ubottu.com/uds-logs/archives/uds-r/
[02:43] <JoseeAntonioR> cjohnston: and how should I link to the specific time? in irclogs.u.c I use #t10 for example
[02:49] <cjohnston> ask whoever maintains the logs to fix them
[02:53] <JoseeAntonioR> then, bug is blocked until tsimpson (I think) fixes this
[02:53] <JoseeAntonioR> I'll just push the etherpad changes to merge
[02:56] <cjohnston> providing the whole log is better than nothing
[02:58] <JoseeAntonioR> ok, let's have this and I'll file another bug to fix that once I reach tsimpson
[03:00] <JoseeAntonioR> mp for etherpad thingy submitted
[03:05] <cjohnston> bug #1155416
[03:06] <cjohnston> bug #1155417
[03:08] <cjohnston> bug #1155420
[03:08] <cjohnston> I feel better.
[03:08] <cjohnston> good night
[03:14] <JoseeAntonioR> cjohnston: night, and thanks!
[03:40] <JoseeAntonioR> mhall119: ping
[05:08] <nigelb> cjohnston: pong
[05:17] <JoseeAntonioR> nigelb: ping
[05:43] <nigelb> JoseeAntonioR: hi
[05:44] <JoseeAntonioR> nigelb: hey, I'd like to know if bug 898590 is still relevant, so I can work on it
[05:47] <nigelb> JoseeAntonioR: I'm pretty sure it is. I'll look at the codebase to see where.
[05:47] <nigelb> Ugh, need to install bzr
[05:47]  * nigelb dislikes bzr
[05:47] <JoseeAntonioR> :P
[05:52] <nigelb> JoseeAntonioR: Here's the essential idea, you can change the bug accordingly.
[05:52] <nigelb> Do not call the lp api directly.
[05:52] <nigelb> Call it through this module.
[05:52] <nigelb> every lp api call will be a function in this module.
[05:52] <nigelb> The idea is, it's easier to mock this module out of the way when you're testing.
[05:53] <JoseeAntonioR> nigelb: but what is this going to be used for?
[05:56] <nigelb> Testing.
[05:56] <nigelb> You don't want to make actual api calls when you test.
[05:56] <nigelb> You mock the call.
[05:57] <JoseeAntonioR> I still quite don't get it
[05:57] <JoseeAntonioR> mind working on that tomorrow? I need to go to bed for school
[05:58] <nigelb> You need to look at the mock module.
[05:58] <nigelb> That'll help
[05:58] <nigelb> see if we're using it anywhere.
[05:59] <JoseeAntonioR> I'll check, then
[05:59] <JoseeAntonioR> I'm out for today, night!
[10:21] <cjohnston> nigelb: can you please setup tarmac to run tests on 'common' and 'schedule'
[21:00] <cjohnston> daker: mhall119 ?
[21:01] <daker> o/
[21:02] <cjohnston> daker: the link is in the invite
[23:02] <mhall119> daker: cjohnston: sorry I missed it, doctor's appointment schedule changes (and delays)
[23:03] <daker> np
[23:03] <daker> the doctor first


[08:55] <KBar> xfce4-windowck-plugin crashes on "Show the plugin on desktop": https://forum.xfce.org/viewtopic.php?id=15393
[08:56] <KBar> apport caught it today and produced an interesting crash report available by its ID 58e56bc6-4782-11ec-baab-fa163ee63de6
[09:10] <Unit193> !info xfce4-windowck-plugin
[12:27] <xu-irc29w> Have xubuntu 20.04 installed. Installed gcc to compile C programs. I keep getting error when I try to compile: "stdio.h not found"
[12:28] <xu-irc29w> Has anyone else had this?
[12:35] <Unit193> Install libc6-dev
[12:35] <tomreyn> or build-essential even
[12:40] <xu-irc29w> Hmm...won't let me install libc6-dev, says : libc6-dev : Depends: libc6 (= 2.31-0ubuntu9.2) but 2.31-0ubuntu9.3 is to be installed
[12:40] <xu-irc29w> E: Unable to correct problems, you have held broken packages
[12:41] <xu-irc29w> How to fix?
[12:50] <KBar> Are you sure you're on 20.04? In the repositories, there is no version 2.31-0ubuntu9.3
[12:51] <KBar> Did you add PPAs?
[12:54] <xu-irc29w> Linux version 5.4.0-90-generic (buildd@lgw01-amd64-054) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021
[12:55] <xu-irc29w> Sorry, what do you mean by PPAs?
[12:56] <KBar> Personal Package Archives, i.e. personal repositories: https://help.ubuntu.com/stable/ubuntu-help/addremove-ppa.html.en
[12:57] <KBar> xu-irc29w, do you, by any chance, have focal-proposed enabled?
[12:58] <KBar> xu-irc29w, check in "Software & Updates" > "Developer Options" tab.
[12:58] <KBar> If it checked, uncheck it, run `sudo apt update` and try installing the libc6-dev package again.
[12:59] <KBar> *it is
[13:03] <KBar> Well, I guess `sudo apt update` is redundant since "Software & Updates" will ask you to reload anyway.
[13:06] <xu-irc29w> focal-proposed not enabled
[13:07] <Unit193> sudo apt full-upgrade;sudo apt install libc6-dev
[13:08] <xu-irc29w> No luck yet. Guess it might be faster to try reinstalling whole system.
[13:08] <xu-irc29w> Using XFCE desktop
[17:26] <tomreyn> ^^ https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1926918
[17:26] <tomreyn> broken repository *since may*
[23:06] <Unit193> Haha. ;D


[12:28] <gary_poster> In a fit of excitement, I will announce our call approximately at the time I intend to do so:
[12:28] <gary_poster> bac benji gmb, call in 2!
[12:28] <gmb> k
[12:36] <bac> from stub: Todays rollout was a success. The update process went smoothly.
[14:38] <gary_poster> cool bac.  emacs question: I think I am using standard emacs Python mode rather than Python(/barry?)-provided emacs mode.  Do you have an opinion as to whether I should switch to the one on LP?
[14:39] <gary_poster> (barry's?)
[14:39] <bac> gary_poster: i'm using standard.  you have a link to barry's?
[14:40] <gary_poster> bac https://launchpad.net/python-mode
[14:42] <bac> gary_poster: by standard, i meant the one installed on ubuntu by default-ish
[14:42] <bac> ii  python-mode                               1:5.1.0-1                                         Python mode for GNU Emacs and XEmacs
[14:43] <bac> this is the one maintained by barry afaict
[14:43]  * gary_poster looks
[14:44] <gary_poster> bac, cool, yeah, didn't have.  trying, thanks
[14:59] <gary_poster> Gimme a C!
[14:59] <gary_poster> ...c...
[14:59] <gary_poster> Gimme an H!
[14:59] <gary_poster> ...h...
[14:59] <gary_poster> Gimme an R!
[14:59] <gary_poster> ...r...
[14:59] <gary_poster> What's that spell?
[14:59] <gary_poster> ...mumble...
[15:00] <gary_poster> I said, what's that spell?
[15:00] <gary_poster> ...churr?
[15:00] <gary_poster> YES!
[15:03] <gary_poster> The rotation schedule page has an ominous change: "Build Farm"
[15:03]  * gary_poster wonders if he can pretend he doesn't see this.
[15:18] <gary_poster> bac, we have this request.  Do you happen to know if (1) we can do this and (2) if this is something I ask LOSAs to do?
[15:18] <gary_poster> "Project https://launchpad.net/percona-benchmark is commercial.
[15:18] <gary_poster> Please make all branches private by default"
[15:28] <bac> gary_poster: we can do it
[15:28] <bac> at least i can
[15:29] <bac> we need to know the team they'd like to give access
[15:29] <gary_poster> ah, great, cool bac.  I'll ask that information, and hopefully you can see the anwer when you get to CHR
[15:30] <bac> gary_poster: ok.  fwiw this is the guy who had the problem i worked on yesterday
[15:30] <gary_poster> oh ok bac.  thanks
[15:58] <gary_poster> Project https://launchpad.net/percona-benchmark should default to percona-dev team for access.  If you set that up now, I'll close the ticket
[16:08] <gary_poster> oof, CHR was more involved than usual
[16:15] <bac> gary_poster: i'm just curious, if you go to https://code.launchpad.net/percona-benchmark do you see "Define branch visibility"?
[16:16]  * gary_poster looks
[16:17] <gary_poster> no, bac
[16:17] <bac> gary_poster: ok, just checking.  i'll take care of it now
[16:17] <gary_poster> thanks bac
[16:19] <bac> gary_poster: done.  i note they already have a branch up which was not retroactively made private
[16:19] <bac> branch visibility only applies to new branches
[16:19] <gary_poster> ok thanks bac.
[16:19] <gary_poster> can he make that one private himself, bac?
[16:20] <bac> gary_poster: i'm unsure
[16:20] <bac> gary_poster: i cannot do it for him
[16:20] <gary_poster> ok thanks bac
[17:27] <gary_poster> CHR ended up taking 2 hours
[19:19] <bac> gary_poster: POTUS announces visit to RTP on wednesday.
[19:19] <bac> hope that doesn't mess up my flight out.  :(
[19:20] <gary_poster> bac, eek, was driving out that day too
[19:21] <bac> gary_poster: which direction?  W on 40?
[19:21] <gary_poster> bac, north, and because of this, probably will go E and then N on 95
[19:22] <gary_poster> might have gone that way anyway, but def will now
[19:23] <bac> i'd like to think AF1 landing wouldn't be too disruptive.  i'm sure they park it somewhere remote, unload the motorcade, and scurry off.  </overlyoptimistic>
[19:47] <gary_poster> lol
[19:48] <gary_poster> maybe so
[19:48] <bac> word is, it shouldn't be too disruptive.  but, as long as he's on the ground nothing takes off, lands, or taxis
[19:59] <bac> chr -- should be easy
[20:16] <bac> chr done.  gary_poster you must've done all the heavy lifting
[20:16] <gary_poster> cool, bac
[20:16] <gary_poster> you did it on Monday
[20:16]  * bac -> cycling.  bb later