[01:21] <zul> arges:  no because they were uploaded before the feature freeze
[03:38] <jdstrand> fyi, the squid3 in utopic-proposed is for a security update. wouldn't mind if it went through, but it's ok to wait if it would cause more work for people
[03:42] <infinity> jdstrand: There is no squid3 in proposed...
[03:42] <infinity> Oh, you JUST copied it.
[03:43] <jdstrand> yeah, I pre-advised
[03:43] <infinity> jdstrand: It should migrate unhindered, I imagine.
[03:43] <jdstrand> s/in utopic-proposed/on its way to utopic-proposed/
[03:43] <jdstrand> ok cool
[03:43] <jdstrand> thanks
[07:54] <dbarth> hi, so following the discussion with stgraber later yesterday, how can i get oxide-qt-1.2 to pass in utopic?
[10:35] <tseliot> hi, can an admin please approve ubuntu-drivers-common in utopic-proposed (it says "Not touching package due to block request by freeze") ?
[10:43] <infinity> tseliot: The block message should be pretty clear, I'd think.
[10:43] <infinity> tseliot: stgraber will remove the block when the current milestone is out.
[10:44] <tseliot> infinity: oops I misread the release schedule
[10:55] <Sweetshark> hi there. When will the utopic freeze lift? We have a libreoffice package in there that upstream just released talking about CVEs: http://blog.documentfoundation.org/2014/08/28/libreoffice-4-3-1-fresh-announced/ -- unfreezing could prevent a launchpad bug filing galore ...
[10:56] <Sweetshark> (FWIW, it seems both CVEs are Windows-only anyway)
[11:25] <Sweetshark> correct that: the CVEs are not windows-only, so an update would be appreciated.
[12:28] <zul> arges: #1362579 - python-osprofiler, #1362586 - openstack-granite, and #1362588 - python-lxc
[12:37] <Riddell> new ubiquity up to revert change I made yesterday which tried to add sddm support but didn't work
[12:38] <Riddell> Sweetshark: should be this evening
[12:44] <arges> zul: so i'm not on the ~ubuntu-release team so you'll need to get their ack on those new packages.
[12:45] <zul> arges:  k
[13:36] <Riddell> stgraber: kubuntu-plasma5 images will appear at http://cdimage.ubuntu.com/kubuntu-plasma5/releases/utopic ?
[13:38] <stgraber> Riddell: that looks right
[13:44] <elfy> stgraber: our release notes will be at https://wiki.ubuntu.com/UtopicUnicorn/Beta1/Xubuntu
[13:50] <stgraber> elfy: thanks.
[14:23] <elfy> is there a utopic one of these https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/
[14:23] <elfy> I can't find one
[14:29] <ogra_> stgraber, just a FYI ... you forgot to re-enable the s-i cronjob :)
[14:29] <ogra_> i switched it on again so we could get images from the nightly builds ...
[14:29] <ogra_> (i.e. dont rely on that it is off)
[14:31] <stgraber> elfy: not at this point. We usually don't set that up for the opt-in milestones and instead let the flavours organize things on their end.
[14:31] <stgraber> ogra_: oops, sorry about that
[14:32] <ogra_> stgraber, yeah, no prob, i just want that you are aware it  is on again
[14:38] <elfy> stgraber: okey doke, thanks
[15:13] <dbarth> stgraber: hi; can you confirm if phone updates can get a freeze exception? i'm pinging again about the oxide-qt 1.2 held in proposed
[15:15] <stgraber> dbarth: if you're calling about the beta-1 freeze, then the answer is no. We only block the source packages which DO affect the products participating in the beta. So if your package is held, it's because one of its binary packages is somehow part of the images we'll be releasing in a few hours.
[15:16] <stgraber> dbarth: according to seeded-in-ubuntu, binary packages coming from oxide-qt are included in ubuntukylin which does participate in this beta
[15:18] <dbarth> so we're stuck, ok
[15:18] <dbarth> lifted around when? monday? tuesday?
[15:18] <stgraber> in the next 2-3 hours
[15:19] <dbarth> oh, even better; then i'll come back in a bit ;)
[15:19] <dbarth> cool
[15:19] <dbarth> thanks for your patience
[15:24] <stgraber> Riddell, wxl, elfy, rcj: http://pad.ubuntu.com/14-10-beta1-announcement
[15:26] <Riddell> stgraber: you don't need a quote for the betas :)
[15:32] <rcj> stgraber, Added a suggestion in the pad to call out cloud daily builds separate from those on cdimage.u.c
[15:33] <rcj> stgraber, I'm just waiting on utlemming to review the text as well.  I'm not sure if we have updates for our example clouds.
[15:34] <stgraber> rcj: ok, I'm still waiting for kubuntu and lubuntu to mark their images ready so it'll likely be another 2 to 3 hours before I send out the announcement
[15:59] <jdstrand> arges: hey, would you be able to verify 1294861?
[15:59] <jdstrand> bug 1294861
[15:59] <ubot2`> Launchpad bug 1294861 in eglibc "time zone files are not set up correctly" [Medium,Fix committed] https://launchpad.net/bugs/1294861
[15:59] <jdstrand> arges: there is a security update that infinity prepared built on top of that and he said we could publish if you verified it
[16:06] <wxl> stgraber: any idea why all of a sudden i can't edit any more?
[16:11] <wxl> stgraber: nevermind. ibus/chrome :(
[16:13] <arges> jdstrand: yes i'll verify it
[16:13] <jdstrand> thanks!
[16:13] <jdstrand> no, if only the sparc build would finish
[16:13] <jdstrand> now*
[16:17] <arges> jdstrand: ok its verifeid
[16:17] <arges> verified
[16:18] <jdstrand> arges: thanks!
[16:21] <rcj> stgraber, Cloud text is good in the announcement notes.  Images are available @ EC2 and Azure now.
[16:40] <wxl> stgraber: lubuntu is ready with i386, amd64, amd64+mac and if i can play my cards right, maybe ppc
[16:40] <stgraber> wxl: cool, can you update the tracker to reflect that?
[16:41] <wxl> stgraber: oh yeah sure duh
[16:41] <stgraber> Riddell: how about you?
[16:41] <stgraber> I'm about to head out for lunch, so my plan is to start publishing when I'm back, that is in about an hour if that works for you guys?
[16:42] <wxl> stgraber: sorry still getting used to being a release manager :)
[16:42] <Riddell> stgraber: yeah should do, just starting testing new plasma5 imagse
[16:42] <Riddell> welcome along wxl
[16:42] <wxl> thanks Riddell :) you're kubuntu?
[16:42] <elfy> hi wxl :)
[16:43] <wxl> hi elfy :)
[16:44] <Riddell> wxl: yep, the original and best linux desktop :)
[16:45] <Riddell> I might be biased on the second point there
[16:45] <wxl> Riddell: probably a bit. how's plasma 5 coming along?
[16:45] <Riddell> wxl: ask me in half an hour when this install is done :)
[16:45] <wxl> Riddell: heheh ok
[16:46] <wxl> man, ibus is weird sometimes :/
[16:46] <Riddell> input methods are always weird
[16:47] <wxl> well it wasn't playing nice with chrome and then i restarted it and it works fine. i dont' know. i work here from the neck down.
[16:47] <Riddell> nobody has ever understood them who lives west of china
[16:47] <wxl> hahahah
[16:47] <Riddell> yes we had chrome not taking any input recently when ibus was installed
[16:48] <wxl> Riddell: here's my big question for kubuntu: does unicode input work like one would expect??
[16:49] <Riddell> wxl: what do you mean, lots of characters are unicode
[16:50] <wxl> Riddell: like in konsole. can't ctrl-shift-u <some control code>
[16:50] <Riddell> you mean CKJ characters?
[16:50] <Riddell> I don't think we have a feature like ctrl-shift-u <some control code>
[16:51] <Riddell> I can change keymapping fine and then I get ¡spanish characters!
[16:51] <wxl> even my compose key doesn't work right in konsole
[16:51] <wxl> ibus fixes things up
[16:51] <wxl> i've just never had this issue in any other flavor i've dealt with
[16:52] <Riddell> how do you mean compose key?
[16:53] <Riddell> é ë et al work fine in konsole if I have a spanish keyboard set, they need two keypresses
[16:54] <wxl> like i can do <compose key (which i ahve set to alt)> .. and i get …
[16:54] <Riddell> how do you set compose key?
[16:54] <wxl> i don't need to use different languages, per se, i need to use different characters that are ultimately universal (like math characters)
[16:55] <wxl> in keyboard settings i think
[16:55] <wxl> but the unicode is the weirdest part
[16:55] <wxl> ctrl-shift-u has worked in every distro i've ever dealt with except kubuntu
[16:55] <wxl> sorry everyone i don't mean to make this #kubuntu :)
[16:56] <tgm4883> If I wanted to add a media file (mp4) to the mythbuntu ISO, would we need to package that mp4 up, or is there another way for adding media files?
[16:56] <Riddell> tgm4883: best just package it up like ubuntu unity does
[16:57] <tgm4883> Riddell: good to know. Thanks
[16:57] <Riddell> see example-content
[16:57] <Riddell> wxl: if I set compose key in settings I can now compose stuff like é with my english uk keyboard
[16:57] <Riddell> using compose-'-e
[16:58] <Riddell> compose-.-. gives me ˙
[16:58] <Riddell> which is handy to know for speaking Catalan
[16:58] <wxl> Riddell: that's what i mean! it acts differently than elsewhere
[16:59] <wxl> Riddell: and still compose key doesn't help with things like ∃
[16:59] <wxl> i mean i could make it as such, but this should be native stuff that "just works"
[17:00] <wxl> Riddell: and from what i can tell scanning bug reports complaints about it gets responses like "we do input differently"
[17:01] <Riddell> hmm well I'm afraid I've no idea but I'm going to akademy next week so I could try asking the locale dude, he knows all
[17:03] <wxl> Riddell: that'd be super cool. let me know! and to be clear, MY issue is not about language or locale, but about wanting to use things like mathematical symbols or the occassional emoji ☺
[17:04] <wxl> wow i wish akademy was in the US. i'd go.
[17:04] <wxl> btw, to be clear, my loyalties lie with lubuntu but we use kubuntu at work :)
[17:05] <Riddell> we'll take you willing or not :)
[17:07] <wxl> well i tried to get lubuntu going for our standard desktop but our main it guy insisted on having something a bit more user friendly. i hadn't used kde since, well, a long time. i was rather pleased with the change :)
[17:11] <Riddell> wxl: what does lubuntu recommend these days for making usb drives with the images on?
[17:15] <wxl> Riddell: well i still recommend dd :) but i've also had good luck with unetbootin. we have also had a lot of suggestions to use mkusb but i've never done it.
[17:38] <Riddell> makes me sad that we don't have a good answer for the very important issue of installing our product :(
[17:39] <wxl> Riddell: dd never fails my friend
[17:40] <Riddell> wxl: until you mistype and it wipes your hard disk!
[17:41] <wxl> Riddell: so don't mistype. i've used it for years and never had a problem.
[17:41] <wxl> Riddell: but really unetbootin hasn't ever failed me either
[17:43]  * wxl is STILL trying to get ppc testing done. with first time testers.
[17:43]  * wxl chews his fingernails.
[17:43] <Riddell> you still have ppc?  my old mac died years ago
[17:52] <wxl> i have a couple ppcs but didn't have time to do the actual testing myself Riddell
[17:53] <Riddell> wxl: I'm stating to feel the pain of not having automated install tests like ubuntu does with Utah
[17:53] <Riddell> I wish I knew how to make them
[17:53] <wxl> Riddell: yeah that would be so nice
[17:55] <infinity> Riddell: Talk nicely to jibel, I'm sure he can help point you in the right direction (and I think, but am not sure, that we might even do some automated smoketesting for flavours already).
[17:56] <infinity> Riddell: Not that one shouldn't also manually test, which always finds a different class of bugs (ie: the bugs you don't already know about and test for), but it's a good start to know if things are complete crap.
[17:57] <elfy> is that the stuff reported at jenkins?
[17:57] <infinity> Maybe?
[17:57] <infinity> I'm actually remarkably ignorant to how much automation we do or don't have for flavours, and where it is.
[17:58] <elfy> https://jenkins.qa.ubuntu.com/view/Ubiquity/view/Lubuntu/ <-wxl
[17:58] <infinity> Ahh, I see no matching Kubuntu URL here.
[17:58] <elfy> yea
[17:58] <infinity> I guess it might just be a matter of asking?
[17:59] <wxl> elfy: wuzzat?
[17:59] <elfy> infinity: well a question asked generally gets an answer - I'd not know it though :)
[18:00] <elfy> wxl: auto tests
[18:00] <infinity> jibel would know, if he's around.
[18:00] <wxl> elfy: huh. interesting.
[18:00] <elfy> yea
[18:01] <elfy> wxl: very useful - it would be have been a whole lot more if I'd noticed ours were failing 2 or days prior to beta - we might have not had to run about at the last minute :)
[18:01] <elfy> and now I've seen the rss feed for that ...
[18:02] <wxl> elfy: if we have an issue there, should we just file a bug against ubiquity? also, what about the alternates?
[18:02] <elfy> wxl I can't answer those questions
[18:03] <wxl> elfy: hehehe ok :)
[18:16] <Riddell> stgraber: kubuntu-plasma5 is broken on i386 but works on amd64, can we publish 1 arch only?
[18:17] <stgraber> Riddell: sure
[18:18] <stgraber> Riddell: simply mark the one that works as ready, anything that's not ready doesn't get published
[18:19]  * Riddell makes it sew
[18:22] <stgraber> wxl: so what's going on with powerpc?
[18:23] <wxl> stgraber: i got a tester working on it, or at least he said he was
[18:23] <stgraber> wxl: ok, so I'm ready to push out beta-1 here and all the other flavours are ready, do you have any kind of ETA on that?
[18:24] <wxl> stgraber: well i said we'd probably release around 2100 utc so ig you're ready you should probably just push it out and we'll call it a learning experience
[18:24] <wxl> …unless you want to wait
[18:26] <stgraber> Riddell, rcj, elfy: are you guys fine with waiting another 2 hours?
[18:26] <wxl> even if i can just have the alternate done it will make a darn big difference
[18:27] <elfy> stgraber: yea I'm fine with that - all we need to do is publish something external
[18:27] <stgraber> wxl: I'm around for the next 4 hours so I don't really mind on my end, but it depends on the other folks, so if they're all fine with it, we can do that
[18:27] <wxl> stgraber: sounds good, thanks.
[18:28] <Riddell> should be fine
[18:28] <stgraber> ok and rcj is US based so that should be easy for him too, let's plan on releasing at 20:30 UTC then
[18:28]  * stgraber goes to work on other stuff till then :)
[18:28] <Riddell> 1 hour to go!
[18:29] <rcj> stgraber, that's fine.  our beta-2 image are available for cloud use now actually
[18:29] <wxl> thanks folks!!!
[18:29] <elfy> wxl: that's ok, one day the boot'll be on the other foot :p
[18:29] <stgraber> I'm going to drop the beta 1 migration freeze now though since none of you are going to be respinning anyway
[18:30] <wxl> elfy: i just hope the guy gets done in time yikes
[18:30] <stgraber> Riddell: 1 hour? are you confusing UTC and BST?
[18:34] <wxl> ok i sent a message to the tester in mind to tell him he's got two hours and told him to make sure he at least gets the alternate done
[18:34] <wxl> we may have to release the alternate only. he's kind of new to testing, so…
[18:34] <Riddell> #
[18:35] <elfy> sounds like awesome fun ;)
[18:40] <jibel> Riddell, we have most of the flavours on https://jenkins.qa.ubuntu.com/view/Ubiquity/view/All/? as infinity pointed out, just not Kubuntu. If someone wants to write autopilot tests for UI driven installations, I'm happy to add them
[18:41] <wxl> jibel: docs on writing tests are where?
[18:41] <Riddell> jibel: yes, what would that involve?
[18:43] <jibel> wxl, Riddell this is the tool we use to execute the tests http://unity.ubuntu.com/autopilot/, current ubiquity test are written for gtk but autopilot supports a qt backend as well
[18:43] <jibel> the code of current tests is in ubiquity trunk http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/files/head:/autopilot/
[18:43] <jibel> you can use it as example
[18:44] <wxl> jibel: and this is only for UI software?
[18:44] <Riddell> jibel: how does this relate to utah?
[18:44] <jibel> wxl, yes
[18:44] <jibel> Riddell, it's different from utah. Utah is doing preseeded installations and doesn't exercise the UI.
[18:45] <wxl> jibel: so one could use utah for the alternate installer?
[18:45] <jibel> wxl, yes
[18:45] <wxl> jibel: cool thanks for the heads up!
[18:45] <Riddell> jibel: what's the use of testing preseeded installations?
[18:46] <jibel> plars, ^ where is the code of iso smoke test we run with utah?
[18:46] <wxl> jibel: are you also one of the parties responsible for managing utah tests?
[18:46] <jibel> Riddell, you find all sort of issues with the base components of the installer
[18:51] <plars> jibel: iirc that's all in lp:ubuntu-test-cases and lp:ubuntu-test-runlists
[18:52] <wxl> jibel: where are the results of utah tests? on jenkins as well?
[18:53] <plars> wxl: http://ci.ubuntu.com/smokeng/utopic/desktop/ for desktop
[18:53] <wxl> plars: thanks!
[18:56] <wxl> plars: there used to be alternates for precise but now there are not?
[18:57] <plars> wxl: iirc, the alternative image was dropped in 12.10 or so
[18:57] <wxl> plars: well not for lubuntu :)
[18:58] <plars> wxl: none of the flavors are covered by these tests though
[18:58] <wxl> plars: well time to get writing :)
[19:03] <mapreri> umh... why anjuta is not migrating?
[19:14] <Riddell> mapreri: probably blocked by beta freeze?
[19:16] <mapreri> Riddell: since 07-21? umh... today is beta1, let's see tomorrow...
[19:26] <cjwatson> mapreri: it makes anjuta-extras uninstallable, as noted in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[19:27] <cjwatson> Depends: libanjuta-3-0 (>= 2:3.2.0), libc6 (>= 2.4), libcairo2 (>= 1.6.0), libgcc1 (>= 1:4.1.1), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.31.8), libgtk-3-0 (>= 3.3.16), libpango-1.0-0 (>= 1.18.0), libpangocairo-1.0-0 (>= 1.14.0), libstdc++6 (>= 4.1.1), dconf-gsettings-backend | gsettings-backend, anjuta (>= 2:3.10), anjuta (<< 2:3.11)
[19:28] <mapreri> cjwatson: do you know that http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says "Valid candidate", do you?
[19:28] <cjwatson> mapreri: update_excuses is only the first stage; update_output is the second
[19:28] <cjwatson> mapreri: https://wiki.ubuntu.com/ProposedMigration
[19:29] <cjwatson> "Valid candidate" is necessary but not sufficient for migration
[19:31] <mapreri> cjwatson: what a complex migration machinery... is some of a WIP to a more complete infrastructure?
[19:32] <cjwatson> mapreri: making it more "complete" would not make it less complex :P
[19:32] <cjwatson> it's a computationally difficult problem
[19:33] <cjwatson> no plans to significantly change it
[19:34] <cjwatson> although I would like to set up a clone of the Debian package tracking system at some point to make it easier to see what's going on with any given package
[19:34] <mapreri> cjwatson: seriously? do we have a so difficult dependency chain to cause a computational issue?
[19:34] <cjwatson> hell yes
[19:34] <mapreri> cjwatson: do you mean the new one? that would be nice
[19:35] <cjwatson> the general problem is NP-complete; the two-stage system makes a *big* difference to its practical feasibility
[19:35] <cjwatson> even today we have some cases where a run takes on the order of an hour if a big enough transition is in progress
[19:36] <cjwatson> though usually it's significantly less than that
[19:36] <cjwatson> I mean the new one yes
[19:36] <wxl> cjwatson: correct me if i'm wrong, but you aren't the mastermind behind the original amd64+mac release?
[19:37] <cjwatson> more o rless
[19:37] <mapreri> and why not integrating the output of the two-stage script in a single page?
[19:37] <cjwatson> well that's more or less what the PTS does
[19:37] <cjwatson> I don't have the necessary weeks to go and reorganise the output
[19:37] <mapreri> indeed
[19:38] <cjwatson> and reorganising the output would make it harder to plug in the PTS unless carefully coordinated with Debian
[19:38] <mapreri> ah, now all is explained :) so the usual reason
[19:38] <wxl> cjwatson: cuz i'm trying to figure out whether or not it's even relevant any more, at least for intel macs. it seems apple pushed out a bunch of firmware releases to bump up the efi version on those early macs and i'm thinking it is unnecessary for them. any recent experience? i'm having trouble finding testers with the hardware.
[19:39] <cjwatson> no idea
[19:40] <cjwatson> I'm reluctant to drop it without quite strong proof
[19:40] <wxl> cjwatson: well as you said, it's still relevant to other machines from that time period, at least as long as the firmware hasn't been upgraded. i'd just been inclined to call it something like amd64-old_efi
[19:41] <cjwatson> obviously it would be nice not to have to build it, but it would be annoying to drop it and then have to put it back later
[19:41] <cjwatson> and indeed it turned out not to be just Macs
[19:41] <cjwatson> (IIRC)
[19:41] <cjwatson> but it's been a long time
[19:41] <wxl> i know…
[19:42] <wxl> well, i'm going to continue to investigate the situation and try to find targets. i'll let you know if i find anything concrete out. still, i agree we keep it jic.
[19:43] <wxl> i feel like i do need to find some machines that it's relevant to, though.
[19:43] <cjwatson> it was 2008/2009 kind of era I believe
[19:48] <wxl> fyi cjwatson i've been working on trying to figure this all out and here's what i've come up with so far https://wiki.ubuntu.com/Lubuntu/Testing/PPC%26Mac64#amd64.2B-mac
[20:17] <wxl> stgraber: my tester ran out of time. release away.
[20:21] <stgraber> wxl: ok
[20:22] <stgraber> starting publishing of the images now, then will wait a few minutes for them to sync and then push out the announcement
[20:24] <wxl> stgraber: i await your word
[20:25] <stgraber> hmm, looks like it's the first time we release a plasma 5 image, the tool needs updating
[20:30] <wxl> Riddell: ↑
[20:31] <Riddell> yes it's the first time
[20:31] <stgraber> I just made the tool not crash for now and will publish manually, the image name for kubuntu plasma 5 doesn't quite work with what the tool expects...
[20:32] <stgraber> as in, the image type isn't part of the name. We may want to rename the tracker entry to Kubuntu Plasma 5 Desktop instead, then update publish-image-set to consider "Kubuntu Plasma 5" as a project, that should do the trick
[20:36] <Riddell> it's always felt inconsistent to me what is a name and what is a type
[20:56] <stgraber> things are slowly syncing...
[20:57] <elfy> good good - I see our's
[20:57] <wxl> np
[20:58] <elfy> stgraber: you got an issue with us publishing our blog page now? I've been up for 17 hours and want to press the button on it ;)
[21:00] <stgraber> elfy: if you can wait until the frontends are done syncing (xubuntu is only on 2 out of 5 apparently), then I'll push the main announcement out too
[21:01] <elfy> okey doke
[21:07] <stgraber> elfy: go ahead
[21:09] <wxl> we're a go stgraber ?
[21:09] <stgraber> wxl: yep
[21:10] <wxl> thx stgraber
[21:10] <Riddell> awooga!
[21:11]  * Riddell publishes http://www.kubuntu.org/news/14.10-beta-1
[21:15]  * Riddell hugs elfy, stgraber, wxl and wanders off to sleep
[21:15] <stgraber> good night!
[21:15] <wxl> bi Riddell :) thanks
[21:15] <shadeslayer> Riddell: remind me to get you a beer tomorrow
[21:16] <Riddell> um, not sure what for but ok sure :)
[21:16] <shadeslayer> for taking over the release :p
[21:16] <shadeslayer> we should do a release parteh at my awesome terrace
[21:17] <Riddell> you have a terrace?
[21:17] <Riddell> you're ill anyway, go back to resting
[21:17] <elfy> stgraber: thanks - wandering off now
[21:17] <elfy> cya Riddell :)
[21:18] <shadeslayer> Riddell: yes
[21:18] <shadeslayer> a kickass one
[21:18] <shadeslayer> Riddell: I'm fine now
[21:18] <shadeslayer> or well
[21:18] <shadeslayer> for now
[21:18] <shadeslayer> :p
[21:19] <shadeslayer> You can drink beer, I'll drink the water :D


[18:12] <ochosi> micahg: ping
[18:18] <ochosi> micahg: are you in touch with debian's maintainer of gmusicbrowser?
[18:18] <ochosi> micahg: the gmb-dev just told me he wants to drop/change some dependencies
[18:18] <ochosi> bbl


[06:15] <guiverc> Maybe we need to re-do Lubuntu plymouth?  (I could have misunderstood; comment 9 of https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1872669)
 Hi all, I've been developing Krob Linux for the Raspberry Pi
 based on KDE
 t.me/kroblinux
 Anyone interested?
 probably the wrong place to advertise your own distribution
 not advertising, really :)
 Its just asking if anyone is interested :)
 which you should do in the offtopic channel not the Lubuntu Devel channel.
 Ah
 Reposting there
[18:29] <kc2bez> Fresh bug today: bug 1873008
[18:29] <kc2bez> @The_LoudSpeaker might be of interest to you ^
 @kc2bez [<kc2bez> @The_LoudSpeaker might be of interest to you ^], I will take a look. Thanks!
 The symbolic link to the logo is failing. Idk why. It didn't the last time I tried.
 I also have some other changes regarding the same package. Will fix along with them.
[19:11] <kc2bez> wxl: We haven't had an iso build in a couple of days. Wondering if you know/noticed anything about that.
[19:12] <wxl> oh?
[19:12] <kc2bez> 20200413 is the "latest"
[19:12] <wxl> looks like everyone is behind
[19:13] <wxl> might be good to ask release if they didn't forget to turn the dailies back on
[19:13] <kc2bez> Tomorrow is freeze.
[19:13] <kc2bez> Do they normally turn them off?
[19:14] <wxl> perhaps they did for the beta?
[19:15] <kc2bez> Strange, here is today's log https://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/focal/daily-live-20200415.log
[19:16] <wxl> yeah totes a release question
 The livefs is still building though.
[19:19] <kc2bez> I'll let it perk for a bit.


[11:49] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: catfish 4.18.0 released<EMAIL_ADDRESS>[19:58] <Unit193> libxfce4windowing (NEW) 4.19.2-1 uploaded to experimental by Unit 193 (unit193) https://tracker.debian.org/libxfce4windowing


[01:36] <philn_> This is phil, is cody online. I'm wanting to demo free node.
[08:47] <_shaun_> hi guys i get the error message ive run out of space when i try pip install, is my /usr/local taking up space and what can i free up?


[04:01] <Lord-Kamina> Is there any way to get access to the config.log of a failed ppa build?
[06:19] <ePierre> Lord-Kamina, yes
[06:19] <Lord-Kamina> How?
[06:19] <ePierre> Lord-Kamina, in your PPA launchpad page, click on "View package details"
[06:19] <ePierre> Lord-Kamina, then click "View all builds"
[06:20] <ePierre> then you can filter to find your build and you should be able to click "see the log"
[06:20] <Lord-Kamina> But that shows the build log.
[06:20] <Lord-Kamina> Not the config.log.
[06:21] <Lord-Kamina> I'm trying to do a backport, and I guess something in the dependencies broke gcc, but I can't figure out what.
[06:21] <Lord-Kamina> I thought it might have been perl 5.24, but on another machine (same OS) I tried gcc4
[06:22] <Lord-Kamina> gcc-4.9 instead of 4.8 with perl 5.24 and it appeared to work.
[06:22] <Lord-Kamina> And I cannot get any more info from launchpad it seems, other than "checking whether the C compiler works... no"
[06:24] <ePierre_> Lord-Kamina, oh sorry... in that case I don't know!
[06:24] <Lord-Kamina> :( thanks anyway.
[08:32] <cjwatson> Lord-Kamina: The only way to do that is for your build to arrange to cat the config.log when it fails.  dh_auto_configure does this automatically, but perhaps you're bypassing or not using it.
[08:33] <cjwatson> Lord-Kamina: But if all else fails, something like ./configure ... || { code=$?; cat config.log; exit $?; } should work
[10:11] <kjackal> Hi! I am facing a problem with building snaps from launchpad (LP) builders. I have a single snap, named microk8s, and I would like to release to edge from the code's master branch and to track 1.10/edge  from the code's  1.10 branch. I first created a snap for the master->edge path, but then when I select the 1.10 code branch and click "Create a new snap package" in the snap "Name: " I have to use the name "microk8s" again and
[10:11] <kjackal> this errors with "There is already a snap package owned by microk8s developers with this name."
[10:12] <kjackal> Am I missing something? Same snap release to different tracks from different branches. Is this possible with LP builders?
[10:15] <cjwatson> The name there is just the name for the object (the snap recipe, if you like) in Launchpad, not the name of the underlying snap.  You must use a different name for the object in Launchpad.
[10:15] <cjwatson> But that doesn't mean the actual snap will end up with a different name.
[10:16] <cjwatson> If you put something different in the Name: field then it should work fine.
[10:16] <cjwatson> microk8s-1.10 or whatever
[10:18] <kjackal> awesome, thanks cjwatson we might want to update step 6 in https://docs.snapcraft.io/build-snaps/ci-integration
[10:19] <cjwatson> Yeah, I'll see about writing something better there.
[10:19] <cjwatson> Though as ever we want to avoid putting too much detail in and being confusing.
[10:19] <cjwatson> (I didn't write that document originally.)
[10:20] <kjackal> so in launchpad.snaps.getByName I should be looking for microk8s-1.10, right?
[10:21] <cjwatson> Yes
[10:21] <kjackal> awesome, thanks
[11:45] <rbasak> Could somebody take a look at https://answers.launchpad.net/launchpad/+question/670853 please? I think Lars is looking to start testing a mysql-8.0 transition soon.
[11:46] <rbasak> ("Please increase repository size in ppa:mysql-ubuntu/mysql-8.0")
[12:05] <moon127> rbasak: I've bumped it the same as 5.7 as suggested
[12:05] <rbasak> moon127: thank you!
[12:27] <Skuggen> Thanks!
[13:26] <cjwatson> kjackal: https://github.com/canonical-docs/snappy-docs/pull/418 FYI
[13:26] <gitlab-bot> canonical-docs issue (Pull request) 418 in snappy-docs "Improve directions for "Name" field of LP snaps" (comments: 0) [Open]
[13:28] <kjackal> cjwatson: +1 , Thank you
[17:55] <Lord-Kamina> cjwatson I was using whatever the original package had (which was a manual configure), I replaced that with dh_auto_configure and I got the output I needed, thanks.
[17:55] <Lord-Kamina> Now I gotta figure out how to fix it.
[17:56] <cjwatson> Good luck
[18:01] <Lord-Kamina> It's not finding gcc. Shouldn't gcc/g++-4.9 work on trusty?
[18:10] <cjwatson> Lord-Kamina: Can you post a link to the build log?
[18:10] <cjwatson> I don't really feel like guessing.
[18:11] <cjwatson> (Also, trusty has GCC 4.8, not 4.9.)
[19:03] <Lord-Kamina> cjwatson, that's apparently not the problem anymore. Either way, you are right, trusty normally has gcc-4.8 but I was under the impression gcc-4.9 was also _easily_ installable.
[19:04] <Lord-Kamina> Currently I'm getting burned on something else. I need aclocal-1.15, was trying to backport automake and am getting this: https://launchpadlibrarian.net/379414545/buildlog_ubuntu-trusty-i386.automake-1.15_1%3A1.15-4ubuntu1ppa-trusty1_BUILDING.txt.gz
[19:56] <Lord-Kamina> Why does launchpad refuse to install texinfo?
[19:59] <nacc> Lord-Kamina: have you tried buildling it locally?
[20:00] <Lord-Kamina> No, I don't have a machine running trusty at hand; but this at least should be pretty straightforward.
[20:01] <Lord-Kamina> However... The following packages have unmet dependencies:
[20:01] <Lord-Kamina>  sbuild-build-depends-automake-1.15-dummy : Depends: texinfo but it is not going to be installed
[20:01] <nacc> Lord-Kamina: ... schroot, lxd, etc.
[20:01] <Lord-Kamina> Literally failing because it doesn't want to install texinfo.
[20:01] <nacc> Lord-Kamina: but you need to find out why
[20:06] <Lord-Kamina> Yeah, but I don't really know how.
[20:10] <nacc> Lord-Kamina: right, that's why i said build it locally :)
[20:44] <Lord-Kamina> Making a trusty vm now. ugh.
[20:46] <nacc> Lord-Kamina: you don't need a VM
[20:47] <nacc> Lord-Kamina: that's overkill for just building a srcpkg, at least
[20:47] <nacc> Lord-Kamina: sbuild with a chroot or lxd is sufficient
[20:55] <Lord-Kamina> nacc, a VM is easier for me because I have little experience with Linux.
[20:55] <Lord-Kamina> I'm a mac user.
[20:56] <nacc> Lord-Kamina: i see
[20:58] <Lord-Kamina> Fairly advanced and more than somewhat familiar with the bsd innards but things as simple as apt can sometimes still be largely black magic to me. :P
[21:04] <nacc> Lord-Kamina: if i had to guess, it's because you're using a ppa for perl?
[21:04] <nacc> Lord-Kamina: one that's not been updated since january of last year...
[21:04] <Lord-Kamina> Could be.
[21:12] <Lord-Kamina> Is there a command to find a package that depends on another package?
[21:12] <nacc> Lord-Kamina: reverse-depends and apt-cache rdepends
[21:13] <Lord-Kamina> Don't know if it's actually related to the issue on the ppa, since this is a fresh install.
[21:13] <Lord-Kamina> But perl was complaining about libenchant having unmet dependencies.
[21:13] <Lord-Kamina> Even though I don't think perl directly depends on enchant.
[23:21] <cjwatson> Lord-Kamina: "is not going to be installed" invariably means that there's something deeper in the stack of dependencies that can't be resolved into a consistent set of packages to install.  Unfortunately apt notoriously doesn't tell you about the details up-front and it usually takes a little digging to figure it out.
[23:21] <cjwatson> chdist(1) is my usual tool for this; looking
[23:25] <cjwatson> Lord-Kamina: Right, that perl PPA provides perl 5.24 itself, but it doesn't provide rebuilt versions of all the libraries that would need to be rebuilt against it in order to actually be able to use it in practice
[23:25] <cjwatson> Lord-Kamina: If you dig deep enough, the actual unmet dependency is:  libxml-libxml-perl : Depends: perlapi-5.18.2
[23:25] <cjwatson> Lord-Kamina: I would recommend dropping that perl-5.24 PPA
[23:26] <cjwatson> Lord-Kamina: You're not going to have a good time trying to use perl 5.24 on trusty without an awful lot more work
[23:26] <cjwatson> Lord-Kamina: If you drop that then automake-1.15's build-dependencies are satisfiable
[23:58] <Lord-Kamina> cjwatson, I see. Thank you very much. I was using that ppa in the first place because something else that I needed to build requires perl 5.20 I think.


[01:38] <Unit193> Heads-up: I won't pick up catfish, not in the right team for that.
[03:30] <bluesabre> I always forget that catfish is in the python team
[07:52] <Unit193> bluesabre: Think I'm dead?  https://packages.qa.debian.org/x/xfce4-session/news/20220719T070535Z.html
[07:52] <Unit193> Can you review that for syncability?  Provided it stays the way it is, I think that's now syncable.
[07:58] <Unit193> https://salsa.debian.org/xfce-team/desktop/xfce4-session/-/commit/5c2031af3ba542e2a12dc8f41440eda4623ce97a should mean we don't have to use dbus-x11 anymore, https://salsa.debian.org/xfce-team/desktop/xfce4-session/-/commit/abbbaf832bb9f3a0abce29363aecc573ae574038 is useful to us (IMO, it's useful in general)
[07:59] <Unit193> https://salsa.debian.org/xfce-team/desktop/xfce4-session/-/commit/81235668b55771615179cf40100cfef4daff58f9
[10:44] <bluesabre> Unit193: will do
[12:46] <Unit193> Just uploaded -batt and -netload, time-out and -dev-tools will be the only things out of date. \o/
[21:15] <bluesabre> Niiiiice!
[23:42] <Unit193> bluesabre: Oh, looks like you've done the recent xfce4-settings merges, want that too?
[23:42] <Unit193> https://freya.unit193.net/~unit193/xfce416.html other than wanting a mailwatch release, we're in good shape.
[23:45] <Unit193> I don't think I can make that syncable either, we're patching XML files...


[08:54] <eythian> Hi, this bug https://bugs.launchpad.net/ubuntu/+source/consolekit/+bug/269651 is starting to collect spam. I'm not sure if there's a real reporting process, so I'll mention it here. Thanks.
[08:54] <ubot5`> Ubuntu bug 269651 in consolekit (Ubuntu Intrepid) "console-kit-daemon crashed with SIGSEGV in g_str_hash()" [High,Fix released]
[10:22] <cjwatson> eythian: removed, thanks
[10:23] <eythian> cjwatson: ta :)
[23:43] <mwhudson> yeech getBuildRecords is incredibly slow


[09:05] <vinilios> i created the following upstart conf file http://pastebin.com/2KCd7tNq , run.sh actually runs a java application, while the job starts fine, stop freezes, any idea how to fix it ?
[18:35] <notting> Keybuk: https://bugzilla.redhat.com/show_bug.cgi?id=577709#c5 <- opinions?
[18:36] <Keybuk> notting: that sounds like the old init it still running?
[18:36] <notting> Keybuk: right, it was the equivalent of apt-get dist-upgrade (or whatever) from a 0.3.x system to one that contains 0.6.x
[18:37] <Keybuk> in that dist-upgrade, we restart init
[18:37] <notting> Keybuk: which promptly loses track of all its jobs?
[18:37] <Keybuk> when we were using 0.3, that was just gettys and stuff, which wasn't an issue
[18:40] <notting> hm, would have to run some tests to see how practical that is
[19:02] <sadmac2_> notting: it could work. we might not kill some things like X on shutdown but nothing major.
[19:14] <halfline> gdm is what handles killing X
[19:15] <halfline> of course upstart is what handles killing gdm
[19:15] <sadmac2_> halfline: precisely
[19:15] <halfline> but there's that kill -TERM -1 or whatever anyway
[19:17] <caolanm> I'm trying out ubuntu lucid beta 1, and upstart doesn't seem to be firing scripts with "start on startup" ...has anyone had success with this?
[19:18] <Keybuk> caolanm: it probably is, but whatever those scripts need isn't ready yet
[19:18] <caolanm> Keybuk: how are those dependencies defined? all the script says is start on startup
[19:19] <caolanm> (I'm working from this guide: http://howtonode.org/deploying-node-upstart-monit)
[19:19] <caolanm> I tried changing it to "start on (local-filesystems and net-device-up IFACE=eth0)"
[19:20] <caolanm> which seems to fire, but I get strange errors regarding missing files
[19:31] <Keybuk> caolanm: you should talk to the maintainers of the software you're trying to update
[19:46] <sadmac> Keybuk: RE: Is this a mountpoint?, why not iterate mtab/proc/wherever and get a list of em?
[19:46] <Keybuk> do you realise how many corner cases that has? :)
[19:47] <sadmac> Keybuk: that + realpath should be == profit
[19:47] <Keybuk> what about if you've got a full filesystem
[19:47] <Keybuk> then you recursively bind mount the /real directory onto /
[19:49] <sadmac> not sure, but that's enough to make me want to not think about it anymore. Your way is fine. :)
[19:49] <sadmac> Keybuk: also did you see my last upstart blogging?
[19:49] <Keybuk> no?
[19:49] <sadmac> Keybuk: http://screwyouenterpriseedition.blogspot.com/2010/04/upstart-service-mangement-modeled-as-bi.html
[19:53] <Keybuk> sadmac: the funny thing is, that blog post makes about as much sense to me as most of your first draft proposals :p
[19:53] <sadmac> Keybuk: I impersonate myself well.
[19:55] <sadmac> Keybuk: also, I would assert that that blog post contains a lifetime supply of release codenames.
[20:37] <notting> sadmac: 577709 updated with brief testing
[21:06] <dvrcoder> question: can i make a upstart script dependent on the start of an oldschool init.d script? say, with "start on SYSVINITNAME"?
[21:14] <sadmac> dvrcoder: you can put an "initctl emit somefunkything" at the end of your sysvinit script, then do start on somefunkything. You could also instrument /etc/rc in a similar way to get such events for everything (which I believe fedora is doing now)
[21:17] <dvrcoder> sadmac: thanks. i'll try and pray it gets my job done :D
[21:38] <sadmac> notting: comitted and tagged. seem to be having some trouble with koji and/or ssl. wanna kick em off?
[21:38] <notting> sadmac: well, i was trolling for comments on the idea
[21:39] <sadmac> notting: among the horrible solutions thats the one that will cause the least screaming.
[21:40] <sadmac> notting: and the good solution might be ready for F-14
[21:40] <sadmac> actually it won't be applicable for F-14
[22:21] <dvrcoder> to create my own upstart script, is it enough to write a blabla.conf and put it in /etc/init, or do i have to register it somewhere additionally?
[23:16] <Keybuk> dvrcoder: ys


[05:47] <Bashing-om> !info automake yakkety
[05:53] <Bashing-om> That's all Folks - for me; G nite
[07:11] <ducasse> morning
[13:08] <BluesKaj> Hey folks
[18:23] <Bashing-om> A rained out Tuesday; and thanks - I have IRC to keep me company :)
[18:26] <OerHeks> fiber-love -D
[18:26] <OerHeks> cat6-friends
[18:40] <Bashing-om> Never ever going back to non internet - nor to a Dial up connection !
[18:41] <OerHeks> i would drop TV over internet too
[18:48] <Bashing-om> I "might" watch a movie - IF the commercials are not too heavy - maybe ; OR if the other half request that quality time to share a movie event . Otherwise. NO !
[18:53] <Bashing-om> OerHeks: Can I get into your smart bucket ? lm-sensors -> w83627ehf driver -> id=0x8860 (??) . How can I confirm this chip ID in release 16.04 ? Old docs are driving me nuts .
[19:00] <OerHeks> as of lm-sensors 3.4.0  there are fixes https://github.com/groeck/lm-sensors/blob/master/CHANGES#L12
[19:00] <OerHeks> so i guess the driver is included?
[19:03] <Bashing-om> OerHeks: Thanks , back to homework :) - ii  lm-sensors     1:3.4.0-2 - .
[19:03] <OerHeks> that was 2015
[19:03] <OerHeks> modprobe w83627ehf ?
[19:07] <Bashing-om> that is the source of my inquiry -> " modprobe: ERROR: could not insert 'w83627ehf': Device or resource busy " .
[20:42] <Bashing-om> Smoke break - smokers draw one .
[20:46] <daftykins> device must be claimed by another module already?
[20:48] <Bashing-om> daftykins: OH for sure is claimed . now I want to tell the system to share it ... Telling the system to ignore the error scares me !
[20:49] <daftykins> share? you can't have two active drivers :D you gotta unload the other / blacklist it
[20:52] <Bashing-om> Uh HUh . Agreed . but Bios has the claim , I do not want that I defeat what bios has set up But I want my cake too and run lm-sensors :)
[20:54] <Bashing-om> daftykins: I looking at ACPI issues here so I am some kind of careful .
[20:55] <daftykins> BIOS locking it o0 that doesn't make much sense
[21:12] <Bashing-om> daftykins: Well, Lots I have to learn yet with this can of worms . but looking at voltage and clocking control from bios that the driver w83627ehf also wants to access . I am aware of a couple of possible things I can do . one of which I am not comforable with, and the other; I want to know the ID of the chip that w83627ehf is accessing .
[21:28] <daftykins> device ID?
[21:32] <Bashing-om> daftykins: Old docs " modprobe w83627ehf force_id=0x8860 " . And old docs do not relate now to verifying " 8860 " in systemd .
[21:33] <daftykins> hrmm
[21:36] <Bashing-om> daftykins: Old docs - prior to the fan control split from lm-sensors .. file locations and addressing no longer apply .


[08:09] <dupondje> ahasenack: If you would have some additional questions on https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1806421 , you can poke me here also :D
[10:38] <brainwash> can bug 1801629 be fixed somewhere central, or does every flavour need to add those packages to their dependency list?
[10:39] <brainwash> there was some change in 18.10 apparently
[14:20] <cpaelzer> juliank: can apt_pkg.TagFile directly read a buildlog (as it includes RFC822 headers for the built packages) or does one need to pre-process the buildlog
[14:21] <cpaelzer> and if one needs to strip it, maybe there is some example I could shamelessly steal from?
[14:22] <juliank> cpaelzer: you probably want to grep for :?
[14:22] <cpaelzer> yeah, I can create my own strip function for sure - just wanted to know if it is needed or soem prior art
[14:22] <juliank> they are also indented a bit
[14:23] <juliank> and it might not recognize the blocks because they don't start with rfc822 data
[14:25] <juliank> cpaelzer: So I guess the answer is I don't know for existing stuff; but you probably want to get all lines starting at a Package: line until you hit an empty line
[14:26] <juliank> I think it's easy to write that in awk
[14:28] <cpaelzer> I actually have almost that in awk from an older script
[14:28] <cpaelzer> I can modify it to my needs, thanks
[15:46] <ernstp> I'm trying to build a kernel debian package (for ppa), but it's failing on headers_install
[15:46] <ernstp> Some mandatory headers (poll.h) are missing in arch/x86/include/uapi/asm.
[15:47] <ernstp> I'm using debian and debian.master directories from the mainline kernel repository
[15:47] <nacc> ernstp: building locally or in a ppa? If in a ppa, link to the build log. But it's not really relevant to this channel.
[15:48] <nacc> ernstp: this is for development of ubuntu itself, not for arbitrary upstream packages
[15:49] <ernstp> nacc: both with local buildpackage and in the ppa, but not if just running make header_install
[15:49] <ernstp> https://launchpadlibrarian.net/400403424/buildlog_ubuntu-bionic-amd64.linux_4.20.0-994.20181206.2c486cc~drmnext421_BUILDING.txt.gz
[15:52] <nacc> ernstp: not sure, i guess compare to the ubuntu one, see if it also happens there, and then diff.