[14:01] <doko> o/
[14:02] <didrocks> he
[14:03] <doko> cpaelzer, jamespage, joining?
[14:03] <jamespage> o/
[14:03] <jamespage> yep
[14:05] <doko> let's start with component mismatches
[14:05] <doko> https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:05] <doko> didrocks: can you do/forward alsa-lib?
[14:06] <didrocks> doko: I will forward it
[14:06] <cpaelzer> here
[14:06] <doko> and I didn't look at the status of ghostscript/fonts, although cpaelzer did
[14:06] <didrocks> doko: actually, it’s the kernel team who maintains alsa
[14:07] <didrocks> so I guess it should be them filing the MIR
[14:07] <doko> jamespage: cinder/python-tabulate ?
[14:07] <didrocks> (looking at alsa-lib subscriber)
[14:07] <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/fonts-urw-base35/+bug/1862048 was waiting for a subscriber
[14:07] <cpaelzer> didrocks: you  said you can't do so and pinged others
[14:07] <cpaelzer> has this happened?
[14:07] <didrocks> yes
[14:07] <didrocks> desktop-packages is sub
[14:07] <joeubuntu> sorry all, late to the meeting.
[14:08] <cpaelzer> Then this is ready for promotion @didrocks
[14:08] <didrocks> will do after this meeting
[14:08] <cpaelzer> I updated the bug accordingly
[14:09] <doko> I'll forward apport/terminator to foundations
[14:09] <cpaelzer> there are two more in te new MIR queue
[14:09] <doko> and doing the licensecheck ones
[14:09] <cpaelzer> https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir
[14:09] <cpaelzer> telp / amtk - has anyone context on those?
[14:10] <didrocks> I don’t but I’ll handle it
[14:10] <doko> gedit
[14:10] <didrocks> them*
[14:11] <cpaelzer> thanks didrocks, IÄll assign you ont he bugs then
[14:11] <didrocks> thx
[14:11] <cpaelzer> Lets also look at the recently modified incomplete
[14:11] <doko> so the open one is cinder/python-tabulate
[14:11] <cpaelzer> whiel I fetch the Link I think Laney wanted to talk about something
[14:11] <cpaelzer> Laney: around?
[14:12] <cpaelzer> incomplete MIRs
[14:12] <cpaelzer> https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir
[14:12] <cpaelzer> jeepeney was done alst week and needs no further action for now
[14:12] <doko> this list is long
[14:13] <cpaelzer> they don't auto-expire
[14:13] <cpaelzer> doko: therefore - we only look at the last touched
[14:13] <cpaelzer> although when in Frankfurt on the sprint we could clear out the past if all us want to do so
[14:13] <cpaelzer> should be a quick everyone-nods-and-set-invalid pass
[14:13] <cpaelzer> ec2-instance-connect still is disliked by me and security
[14:14] <cpaelzer> but I know rbalint is working on it
[14:14] <cpaelzer> anyone haveing any other MIRish topic to discuss ?
[14:15] <didrocks> nothing here
[14:15] <doko> jamespage: still here?
[14:15] <jamespage> yep
[14:16] <jamespage> sorry - multi-tasking never helps == multi-failing
[14:16] <jamespage> I think there was one new security MIR added to the queue for joeubuntu's team
[14:16] <jamespage> in the last week - masakari
[14:17] <doko> filed https://bugs.launchpad.net/ubuntu/+source/python-tabulate/+bug/1862773
[14:17] <doko> joeubuntu: ^^^
[14:18] <jamespage> masakari is in the backlog on the security team trello so its in the queue
[14:18] <jamespage> thanks
[14:19] <jamespage> doko: coreycb or I will pickup completion of that MIR for tabulate
[14:19] <joeubuntu> IT's on the list, thanks doko
[14:19] <doko> ta
[14:19] <doko> anything else?
[14:19] <cpaelzer> I think we are good
[14:19] <cpaelzer> as I said Laney had some question
[14:20] <cpaelzer> but I don't know which one, only that didrocks and I said plese get to the IRC meeting to talk about it
[14:20] <cpaelzer> didrocks: do you know what it was about?
[14:21] <didrocks> I don't at all
[14:21] <didrocks> we have our desktop meeting in 10 min, so he should soon be around
[14:21] <cpaelzer> hmm later/next time then
[14:21] <cpaelzer> oh that is good
[14:22] <cpaelzer> Oh FYI I won't be here next week (PTO)
[14:22] <doko> see you, bye
[14:22] <cpaelzer> cu
[14:22] <didrocks> enjoy cpaelzer :)
[14:25] <didrocks> doko: just to be clear: I’ll let you handle alsa-lib dep with the kernel team if you don’t mind
[14:29] <doko> didrocks: to be clear, doing adminstrative work on a MIR doesn't have to be done just be me
[14:29] <doko> now https://bugs.launchpad.net/ubuntu/+source/alsa-ucm-conf/+bug/1862776
[14:31] <didrocks> I don’t think filing an empty MIR really helps in moving the discussion forward with the people who need to deal with it, but probably material for discussing in Frankfurt
[14:32] <Laney> back here
[14:32] <Laney> is the meeting still going obn?
[14:32] <didrocks> it's done
[14:33] <Laney> meh
[14:33] <didrocks> but I guess you can write here, people seem still being around
[14:33] <cpaelzer> yep
[14:33] <Laney> it's not on the fridge calendar btw
[14:34] <Laney> yeah ok, so there's a project going on at the minute with some of us @ canonical
[14:34] <Laney> basically the goal is to make the oem enablement tweaks that some hardware requires, and comes with when you buy it with ubuntu pre-loaded, also available if you buy with another OS and install Ubuntu yourself
[14:35] <Laney> essentially requires defining extra packages to install for different hardware
[14:35] <cpaelzer> doko: jamespage: joeubuntu: ^^ highlight to make you come back to the meeting :-)
[14:35] <Laney> we're going to do this by including metapackages on the iso that declare what they're compatibile with, and dynamically installing them
[14:35] <Laney> now "on the iso" implies "in main"
[14:35] <Laney> and "package*s*" implies many
[14:36] <Laney> so I'm coming to you to try to work out an exception for this
[14:36] <cpaelzer> This sounds familiar, did you bring that up on the last engineering sprint already?
[14:36] <Laney> I did write up a draft here: https://wiki.ubuntu.com/MIRTeam/Exceptions/OEM
[14:36] <Laney> yes
[14:36] <Laney> the idea is that packages which fit that draft can go in without MIR
[14:36] <cpaelzer> great, the exception is what I'd have asked for
[14:36]  * cpaelzer reading ...
[14:38] <cpaelzer> so the real content is in an extra apt archive
[14:38] <cpaelzer> and this is really just abotu the meta-packages to go onto the iso
[14:38] <cpaelzer> that was unclear last time we talked, thanks for adding the link on the wiki page
[14:39] <Laney> more or less, and that part is being considered by the TB
[14:39] <Laney> the meta pkgs themselves are super trivial
[14:39] <didrocks> how many of those packages per release do you expect to see during a release life?
[14:40] <Laney> no idea
[14:40] <Laney> that all depends on how many laptops are enabled which is a bit beyond my field of view
[14:40] <Laney> but you could say several
[14:41] <didrocks> wondering as well about the burden on the SRU team, but that’s another topic (to see if the mechanism is realistic)
[14:41] <cpaelzer> Laney: I know it was only an idea back then when we talked - but is there any chance to get a linter-script for these rules ont that wiki page?
[14:41] <didrocks> anyway, if we expect several, I think we should have an automated checker for them
[14:41] <cpaelzer> the AAs could use that to verify that the package follows the rules before promotions
[14:41] <didrocks> exactly :)
[14:41] <cpaelzer> hehe, same thoughts it seems
[14:41] <Laney> explain more
[14:41] <Laney> please
[14:41] <cpaelzer> Laney: I think the definitions on the page are good
[14:42] <cpaelzer> Laney: the next step would be writing and attaching a script of some sort
[14:42] <Laney> I don't really have weeks to spend writing a script
[14:42] <Laney> or days even
[14:42] <Laney> so if that blocks this, it might do so for some time
[14:42] <cpaelzer> well, if we don't have such a thing the AAs will ahve to manually check against the defnitions ont his page
[14:43] <cpaelzer> which can work, but is error prone as we all know
[14:43] <cpaelzer> and it scales wit hthe number of packages that will go this path
[14:43] <didrocks> and can consume even more time depending on how many packages we are talking about (which we should know before starting this)
[14:43] <didrocks> I guess the OEM team can give some estimation
[14:44] <cpaelzer> Laney: IMHO it will not stall the approval of this approach to not (yet) have this script
[14:44] <cpaelzer> But once the actual "please promote on the base of this" happens
[14:44] <cpaelzer> then having one will make it fast
[14:44] <cpaelzer> and lacking that checker will make it slow and the AAs grumpy
[14:45] <Laney> ok I can put it on the list, but I have to deliver the project itself as a higher priority, hope you understand
[14:45] <cpaelzer> absolutely
[14:46] <didrocks> I think it can be seem as a broken record, but I would really like to have at least have a guess estimate of the number of packages we are talking about
[14:46] <Laney> didrocks: can you explain the background behind your request?
[14:46] <Laney> if it's 10, you prefer to review them all manually?
[14:46] <Laney> but 15 not?
[14:47] <didrocks> I guess 10 is indeed ok, but if it’s 30, the script should be mandatory before we start such a process
[14:47] <Laney> it's an interesting one
[14:47] <didrocks> as AA will likely spend more time and it will be more error-prone
[14:48] <Laney> if you decline this exception then it is the *MIR* team that gets more work
[14:48] <juliank> It's not that hard to have one package as a reference, and then run debdiff against any new ones, though
[14:48] <Laney> I'm interested because it saves me paperwork, but you should be because it saves you MIRs to review
[14:48] <juliank> And that provides a reasonable review base, I'd guess
[14:48] <cpaelzer> that is a simple approach to such a helper script
[14:48] <cpaelzer> good hint juliank
[14:48] <didrocks> I’m more thinking about MIR/AA/SRU in general, and not not caring just to deliver but giving the load to others
[14:49] <Laney> I'm saying the difference between declining until I write a script and approving without the script isn't that great
[14:49] <Laney> it's the addition of some paperwork
[14:49] <Laney> but if debdiffing some template is OK, ...
[14:49] <didrocks> which will back-pressure all parties to have a script
[14:50] <didrocks> or it will never happen because life and next projects…
[14:50] <juliank> "debdiff <first .dsc> <new .dsc> | filterdiff -p1 -x debian/changelog -x debian/modaliases" should be enough of a script
[14:50] <didrocks> yep
[14:50] <Laney> seriously?
[14:50] <joeubuntu> This sounds like a method to just get around MIRs,  will the packages that get installed be supported for 10 years?
[14:51] <Laney> it is a method to get around MIRs
[14:51] <Laney> they'll be supported for the life of the release yes
[14:51] <Laney> get around in the sense that doing MIRs will be extremely repetitive
[14:52] <joeubuntu> But the burden of support isn't any lower, shouldn't we do some validation of the packages supportability?
[14:52] <cpaelzer> joeubuntu: the packages will have no "active" content
[14:53] <cpaelzer> joeubuntu: we essentially do the validation on the template
[14:53] <cpaelzer> and then based on that provide a fast path as long as that pattern is matched
[14:53] <joeubuntu> OK, that makes sense.
[14:53] <joeubuntu> Thanks
[14:53] <cpaelzer> Laney: please correct me if your plan changed from what I barely remember from half a year ago :-)
[14:54] <cpaelzer> Laney: maybe the words in the last few messages here could be added to the wiki
[14:54] <Laney> no that's it
[14:54] <cpaelzer> it seems they help to calrify
[14:54] <Laney> so that debdiff thing, that is ok for a script for you?
[14:54] <Laney> I can upload a 'good' template somewhere and then just add that to the page ...
[14:54] <cpaelzer> yeah, if you attach the files needed and how to invoke to the wiki that should be ok
[14:55] <didrocks> I think so, just wrap it in an helper for the AA and that’s fine
[14:55] <cpaelzer> a repo somewhere and a link to it from the wiki might be even better than an attachment
[14:55] <didrocks> I would really put that in lp:ubuntu-archive-tools
[14:55] <cpaelzer> didrocks: weren't there a aa-helper repository somewhere?
[14:55] <cpaelzer> yes that is what i was looking for
[14:55] <cpaelzer> Laney: would that work for you (not stalling you too much) but giving you what you need?
[14:56] <Laney> I thought you wanted an actual static verifier, but this should be ok if you don't mind
[14:57] <cpaelzer> we are all reasonable people, in a perfect world there would be a super-duper-verifier - but this seems to work
[14:57] <cpaelzer> if it turns out it does not it will slow down the AAs and thereby your packages from promotion
[14:57] <didrocks> and all packages will have a very strong testsuite in them :p and and and… :)
[14:57] <cpaelzer> but I think this will be good
[14:57] <juliank> Oh, test suite
[14:57] <didrocks> ahah
[14:57] <cpaelzer> Laney: would you ping me once you updated the wiki/repo please?
[14:58] <juliank> It would be nice to have autopkgtest that installs it and run apt update I guess to ensure there's no typos in the .list entry
[14:58] <cpaelzer> we lack the people to "sign-off" on this atm, but I can send a mail to the MIR team then
[14:58] <Laney> cpaelzer: ok, I will do, thanks
[14:58]  * Laney ignores juliank trying to load more work onto this
[14:58] <cpaelzer> juliank: good suggestion
[14:58] <cpaelzer> lets add it only as a bonus-objective to avoid the anger of Laney
[14:59] <didrocks> heh
[14:59] <Laney> if you're being cool you'd do it with autodep8
[14:59] <Laney> and *that* would be the static verifier
[14:59]  * Laney runs
[14:59] <juliank> Oh yeah, I should write an autodep8 module for verifying packages which install sources.list entries
[14:59] <didrocks> yeah, but nothing ensures you that in the long run, the repo is still valid
[15:00] <didrocks> and have needed packages
[15:00] <didrocks> but anyway, let’s move on :)
[15:00] <didrocks> (or you need regularly running autodep8, which in the end is a jenkins-like solution with reporting and so on…)
[15:06] <Laney> funny thing but juliank is at some point in our lives going to work on something similar to that


[06:54] <rayfun> Hi, why does apt not install the latest version here and how can I change this behaviour?
[06:54] <rayfun> axel@lyra:/var/www/html/vhosts$ apt-cache policy phpmyadmin
[06:54] <rayfun> phpmyadmin:
[06:54] <rayfun>   Installed: (none)
[06:54] <rayfun>   Candidate: 4:4.9.5+dfsg1-2ubuntu0.1~esm1
[06:54] <rayfun>   Version table:
[18:13] <ice9> which diagram type is the most suitable for documenting server's services and architecture?
[18:18] <oerheks> dia, the software itself is created for such task
[18:21] <tomreyn> (cross posted to at least #linux and #debian, as usual)
[18:23] <oerheks> sorry for my brainfart
[20:05] <znf> Has anyone tried to patch an Ubuntu kernel with Google's BBRv3 ?
[20:10] <ice9> sorry tomreyn for cross posting, because I usually wait for hours to get a response if posted in a single channel, sometimes when I need a quick response (for a reason) I do that; but yeah, that's not good!
[20:22] <JanC> at the very least it's better if you mention that you posted it elsewhere before; people can check to see if they aren't going to do useless work then...
[21:22] <znf> so, nobody ever tried to BBRv3 on top of an ubuntu kernel? :(
[22:18] <patdk-lap> dunno about bbrv3, just using whatever bbr is in linux 6.5
[22:19] <JanC> Google promised to upstream BBRv3 "ASAP", so it will be in Ubuntu once they do that   :)
[22:23] <patdk-lap> make a dkms package :)
[22:31] <Odd_Bloke> I'm not really sure where to report this, but I'm seeing archive.ubuntu.com blocked in India with a link to http://www.airtel.in/court-orders/
[22:31] <sarnold> "Hon’ble Court."
[22:31] <sarnold> well that's one way to not look up how to spell "honorable"
[22:32] <patdk-lap> Odd_Bloke, your isp?
[22:36] <Odd_Bloke> Google suggests that's an official form of address for the Indian Supreme Court (but their website didn't load, somewhat ironically).
[22:37] <patdk-lap> just dont use your isp's dns server
[22:37] <patdk-lap> I just run my own pulling from the roots
[22:37] <patdk-lap> not sure if googles dns would follow .in stuff or not
[22:37] <patdk-lap> I doublt <IP_ADDRESS> would
[22:39] <Odd_Bloke> `curl -H "Host: archive.ubuntu.com" <IP_ADDRESS>` hits the issue, so I don't think it's DNS hijacking.
[22:40] <patdk-lap> oh, they are doing route blackholing
[22:40] <patdk-lap> effective, but I rarely see it done
[22:41] <patdk-lap> any other ips? outside of uk?
[22:41] <patdk-lap> <IP_ADDRESS> maybe?
[22:41] <Odd_Bloke> Same result.
[22:41] <patdk-lap> still in uk, heh
[22:42] <patdk-lap> you could point to my apt-cache-ng server if you wanted?
[22:42] <sarnold> Odd_Bloke: what dns recursors or forwarders are you hitting? what IP addresses does it reply?
[22:42] <patdk-lap> he did a stright http connect to the right ip, still no go
[22:42] <sarnold> ohhhhh
[22:43] <tomreyn> https could help there, if available
[22:43] <patdk-lap> cache.patrickdk.com:3142
[22:44] <patdk-lap> https wouldn't help
[22:44] <patdk-lap> http/https/... depends on tcp working
[22:44] <sarnold> Odd_Bloke: maybe traceroutes?
[22:45] <patdk-lap> question is, local isp blackhole, or a higher country level blackhole
[22:45] <tomreyn> oh, i was thinking they replaced the website by something else.
[22:45] <patdk-lap> they did, by redirecting the ip address :)
[22:48] <tomreyn> i'll hold back on the discussion, this is not the time + place.
[22:51] <patdk-lap> must be a local isp thing, most if the in looking glasses find it ok
[22:55] <tomreyn> http://www.site24x7.com/tools/public/t/results-1713912834141.html hyderabad + new delhi (unknown isps) report response size 262 bytes (but not others in IN)
[23:33] <oerheks> http://in.archive.ubuntu.com/
[23:41] <tomreyn> someone just suggested adding http://archive.ubuntu.com/ to the global test list of citizenlab's ooni probe https://github.com/citizenlab/test-lists/pull/1710/files
[23:41] -ubottu:#ubuntu-server- Pull 1710 in citizenlab/test-lists "Contribution from test-lists.ooni.org" [Open]
[23:43] <tomreyn> http://start.ubuntu.com/connectivity-check.html and https://ubuntu.com/ are already on their list according to https://github.com/citizenlab/test-lists/blob/master/lists/global.csv
[23:47] <JanC> Odd_Bloke: can you use other (local or non-local) mirrors?
[23:51] <JanC> I wonder what they objected to in the archives...
[23:52] <sarnold> tor or vpn would be my guess
[23:52] <JanC> huh
[23:54] <sarnold> they've been restricting internet access in the jammu and kashmir region (or whatever they're calling it these days), they might be trying to block censorship evasion tools
[23:55] <tomreyn> oh they have elections going, i almost forgot.
[23:57] <JanC> from what I can tell, the Indian justice system runs on...  Ubuntu
[23:57] <sarnold> if it runs at all?
[23:57] <sarnold> what I hear about it is mostly about how slow it is
[23:57] <JanC> """eCommittee, Supreme Court of India
[23:57] <JanC> Guidelines for Roll-out and Installation of Ubuntu Linux for Indian Judiciary"""
[23:58] <JanC> there are documents about them using Ubuntu in several places  :)
[23:59] <JanC> block security updates for your own systems... excellent plan  :P
[23:59] <oerheks> sarnold, this is normal in gov https://imgur.com/gallery/yZzobvd


[00:03] <cyphermox> slangasek: so I think it should still work even if it allocates the free space
[00:04] <cyphermox> it certainly does run grub-installer properly on x86 :)
[00:04] <slangasek> who here is familiar with how partman-md is /supposed/ to work?
[00:05] <slangasek> cyphermox: the fundamental issue here is that we are *not* wanting to create a RAID over two partitions, we're wanting to create a RAID over two disks and then create partitions on the RAID
[00:05] <cyphermox> sure
[00:05] <cyphermox> but why is that an issue?
[00:05] <cyphermox> if it seems to work properly...
[00:06] <slangasek> cyphermox: how are you figuring that it works properly?  we're having this conversation precisely because a bug has been reported
[00:06] <cyphermox> slangasek: a bug specifically on ppc64el, which uses very different code paths than x86
[00:07] <cyphermox> and I seem to be able to reduce the difference there too (pending testing)
[00:07] <cyphermox> part of the problem on ppc64el is that we also depend on PReP partitions which are not the typical grub /boot partitions and get detected via prep-bootdev, an "external" program grub-installer also ships
[00:08] <slangasek> cyphermox: the firmware needs to see a PReP partition.  You can accomplish that one of two ways.  1) Combine two disks into a RAID1 array, partition it, make one of those partitions a PReP partition; or 2) create partitions on the underlying disks, combine those individual pairs of partitions into RAID1 arrays, and mark one of those as a PReP partition
[00:08] <cyphermox> so my analysis as to "it seems to work" is based on the fact that on amd64, it seems to work, I don't deny we still need to figure out how well that scales to ppc64el/opal booting
[00:08] <slangasek> cyphermox: from what you've told me, you've tried to do exactly what I also expected to work - that you could select two disks for RAIDing and create partitions on top of them and have it work
[00:09] <slangasek> but that is *wrong* and doesn't work *anywhere* except MBR
[00:09] <cyphermox> slangasek: it's also why it's explicitly marked as not supported in anything but x86 :/
[00:09] <slangasek> that is wrong> the implementation is wrong and does not match the intent
[00:09] <slangasek> cyphermox: it's not even supported on x86 with UEFI, it only works for MBR
[00:10] <slangasek> do we automatically add the PReP partition to fstab?
[00:10] <cyphermox> no
[00:10] <slangasek> ok, so it's a magical thing that's handled via grub directly
[00:10] <slangasek> do you have the bug number for this handy? :)
[00:10] <cyphermox> yeah
[00:12] <cyphermox> so I'm already working on a fix, but there's multiple moving parts and I'm new at the whole thing, so trying to understand things as I change them :)
[00:12] <cyphermox> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1487365
[00:13] <cyphermox> it clearly currently doesn't work on ppc64el; we've established that
[00:13] <slangasek> cyphermox: how are you intending to solve this?  The install method presented in the bug, that of /dev/md0p1 being used as the PReP partition, will never work with the current state of partman-md
[00:15] <cyphermox> there's two pieces; teach grub-installer to correctly pick the members of the array when installing grub; and fix partman-md to use the underlying disk when we can somehow detect that it's otherwise unpartitioned
[00:15] <slangasek> ok, so you are planning to change partman-md to use whole disk instead of creating a partition
[00:15] <cyphermox> so presumably in the case where either it's just free space, or there is no partition table
[00:15] <slangasek> sorry, I didn't understand that was your aim
[00:15] <cyphermox> it wasn't until we discussed this
[00:15] <slangasek> if you do that, then yes, this all works
[00:15] <slangasek> ah ;)
[00:16] <cyphermox> I don't pretend to know all the intricacies of RAID or booting, so we refine as we go ;)
[00:16] <cyphermox> I'm starting to think I'll have to discuss this with KiBi too before I get too deep in the code
[00:19] <cyphermox> my question for you though would be, should this really be a priority for 15.10, or should we focus on more broken things since there is a workaround and people need to write their own partitioning recipe anyway?
[00:19] <slangasek> cyphermox: basically, it's like this.  software RAID is invisible to the firmware (whichever firmware it is).  The only RAID that's compatible with being booted from is RAID1, because it's a straight mirror, so the firmware just sees it as two disks with matching content.  Any other RAID scheme requires that the boot logic sit *outside* the software RAID array
[00:20] <slangasek> on MBR you dodge this because MBR doesn't boot from a partition
[00:20] <cyphermox> yeah
[00:20] <slangasek> on UEFI or opal, you need a partition to boot from; which means either full-disk software RAID + partitions inside it, or selective RAID of individual partitions
[00:22] <cyphermox> yup, got that
[00:25] <slangasek> cyphermox: so instead of committing to redesign partman-md, I think we should instead look at better enforcement of partitioning policies
[00:25] <slangasek> because you shouldn't have to wait for grub to try to install before you find out there's no prep partition
[00:25] <slangasek> historically there have been architecture-specific partman modules to enforce this
[00:26] <cyphermox> there alreday is a partman-prep IIRC, I could enforce things there
[00:26] <slangasek> IOW I think option 1) is what people generally *want* to have working, but until that works we can get by with directing people to option 2)
[00:29] <cyphermox> enforcing PReP not to be on RAID for now should be simple
[00:30] <slangasek> it doesn't require that it not be on RAID, it just requires that it not be a /dev/mdNpM partition
[00:30] <slangasek> well
[00:31] <slangasek> the use case here is that you want both disks to be equally bootable
[00:31] <slangasek> if grub can handle that without having to be pointed at /dev/md0 == (/dev/sda1+/dev/sdb1), that's fine
[00:32] <slangasek> but having a RAID1 over the individual PReP partitions may be preferable
[00:33] <cyphermox> well, that would get complicated to do without an early_script, but I'll give it a test too
[00:40] <slangasek> cyphermox: so I was mistaken, the partitioning enforcement is apparently usually done by the bootloader installer packages rather than partman modules per se.  e.g. silo-installer (available in Debian only)
[00:41] <slangasek> aboot-installer had one, but good luck finding that in any Debian release...
[00:41] <cyphermox> there is still some level of enforcement in partman- packages, for instance in the size/location for the ESP
[00:41] <slangasek> ok
[00:41] <cyphermox> and partman-prep already checks for location
[00:42] <cyphermox> so it should be fine to check there that PReP isn't over /dev/md0p[0-9]+
[00:42] <cyphermox> that's the easy part though, I still need to get grub-installer right for when it's partitioned right :)
[00:43]  * slangasek nods
[00:43]  * cyphermox uploads a new grub-installer revision to his installer-dev PPA
[00:45] <cyphermox> this is going to be pretty much all for today I think, I'll start an install with it Monday so I get the results on Tuesday morning.
[00:45] <slangasek> alright
[00:46] <slangasek> I'm going to braindump to the bug
[00:46] <cyphermox> cool.
[01:23] <cyphermox> slangasek: you mentioned dvorak too?
[01:24] <slangasek> I did
[01:24] <slangasek> let me double-check it
[01:26] <slangasek> cyphermox: possibly specific to UEFI boot
[01:31] <cyphermox> wat
[01:31] <cyphermox> I don't see how it would change anything
[01:31] <slangasek> cyphermox: well when you're using syslinux you get the option to select the keyboard layout from the bootloader
[01:31] <slangasek> so that's what most people use?
[01:31] <cyphermox> sure
[01:31] <slangasek> if you're using booting under UEFI you don't have that
[01:32] <cyphermox> well, perhaps, and that will change bits in the command-line
[01:32] <cyphermox> but when you detect the keyboard and select dvorak it should still get you the right thing
[01:32] <slangasek> so it's possible the keyboard selector within d-i is broken for everything, but not usually noticed on !UEFI
[01:32] <slangasek> well yes, it should ;)
[01:32] <cyphermox> it's possible, but I thought I had fixed it when you last reported this months ago
[01:32] <cyphermox> it was missing kbd.
[01:33] <cyphermox> I'll try the server image with and without EFI in a bit, when I'm done with laundry
[01:33] <slangasek> was my last report before or after 15.04 release?
[01:34] <cyphermox> after
[01:34] <slangasek> ah
[01:34] <cyphermox> wasn't it this summer?
[01:34] <slangasek> quite possibly
[01:34] <slangasek> but as I said, I was booting a 15.04 image
[01:34] <cyphermox> oh
[01:34] <cyphermox> well, then maybe I should SRU this fix ;)
[01:34] <slangasek> SRUing it won't get it into the already-produced image
[01:34] <cyphermox> no
[01:35] <cyphermox> ugh, and console-setup and kbd need to be on the d-i image itself
[01:35] <cyphermox> try a 15.10 image, so at least I'm reassured it works?
[01:36] <cyphermox> I could sprint with a dvorak keyboard, too :)
[01:37] <slangasek> yeah just finished downloading that
[01:39] <slangasek> cyphermox: bad news; same problem on 15.10 beta
[01:43] <slangasek> Oct 10 01:38:13 main-menu[235]: (process:1141): /etc/console-setup is not writable. No files will be saved there.
[01:43] <slangasek> Oct 10 01:38:13 main-menu[235]: (process:1141): gzip is not accessible. Will not save cached keyboard map.
[02:02] <cyphermox> looks like the same kbd issue :(
[02:04] <cyphermox> so, first, bios boot and I pick dvorak at the keymap panel in gfxboot.
[02:05] <cyphermox> I do get dvorak
[02:05] <cyphermox> now, uefi
[02:06] <cyphermox> so, English (US), then English (US) - Dvorak
[02:06] <cyphermox> still got dvorak?
[02:08] <cyphermox> that was with ubuntu-server from 20151009
[02:08] <cyphermox> what image did you use?
[02:08] <cyphermox> slangasek: ^
[02:09] <cyphermox> or are you using the keyboard-detection?
[02:11] <cyphermox> hum, if you go back and re-do the keyboard selection it looks like maybe it won't update the keymap properly
[02:12] <cyphermox> neh, the keyboard-detection is broken altogether
[02:14] <cyphermox> yup, the detection algo is broken, but the selection from lists appears to work, at least as far as picking between us and us:dvorak and having the right setting applied following that is concerned
[02:16] <cyphermox> I bet it's broken in Debian too
[02:19] <slangasek> cyphermox: ah; I didn't yet test a manual keyboard selection with 15.10, only the keyboard detection method, and that failed
[02:20] <cyphermox> yeah I confirm it's really broken
[02:20] <slangasek> ok, but manual selection works
[02:20] <slangasek> on 15.10
[02:20] <cyphermox> ah, no detection in debian?
[02:20] <slangasek> it didn't work for me in 15.04
[02:20] <slangasek> correct, the detection is an Ubuntuism
[02:20] <cyphermox> slangasek: yeah, the manual selection works
[02:22] <cyphermox> how would you go about picking dvorak on Debian?
[02:22] <cyphermox> doesn't look like I have the choice at all after American English
[02:24] <cyphermox> oh, so that's the 'plugin-detect-keyboard'
[02:24] <cyphermox> shiny.
[02:27] <cyphermox> slangasek: so where does this plugin come from?
[02:34] <cyphermox> so after detection it looks like you got setupcon to run, as it should, but still not setup the keymap properly
[02:38] <cyphermox> ah, oops. looks like we mangle XKBVARIANT along the way
[02:41]  * cyphermox adds that to the list for Tuesday
[03:45] <slangasek> cyphermox: ok; so did you file a bug to track this?
[08:48] <infinity> slangasek: FWIW, OPAL doesn't require a PReP partition, since it doesn't actually use grub.  OpenFirmware does, however, and we install the same way under OF/SLOF/OPAL to preserve sanity (and let disk images migrate).
[08:49] <infinity> slangasek: And, not, it's not added to fstab, because it's a raw partition with bootloader of choice (yaboot or grub, generally) blatted directly to it, is contains no filesystem.
[08:50] <infinity> s/is contains/it contains/


[00:09] <tsimonq2> doko: Looks like acheronuk got it, yep I was at work.
[00:11]  * valorie knows all, sees all
[00:16] <tsimonq2> Creepy!
[00:19] -queuebot:#ubuntu-release- New binary: insighttoolkit4 [ppc64el] (artful-proposed/universe) [4.12.0-dfsg1-1ubuntu2] (no packageset)
[00:50] <slangasek> jbicha: a binary reject of gjs?
[00:56] <jbicha> slangasek: yes please
[00:56] <slangasek> jbicha: that's not usual; what's the status of fixing the source?
[00:57] <jbicha> the unusual version number is because that upload was intended for a ppa
[00:57] <slangasek> jbicha: so should I also remove the source from artful-proposed?
[00:57] <jbicha> we're discussing the mozjs52 transition at tomorrow's Desktop meeting so I accidentally jumped the gun
[00:58] -queuebot:#ubuntu-release- New: rejected gjs [amd64] (artful-proposed) [1.49.90-0ubuntu0~artful1]
[00:58] -queuebot:#ubuntu-release- New: rejected gjs [armhf] (artful-proposed) [1.49.90-0ubuntu0~artful1]
[00:58] <jbicha> I think it's fine to leave the source there for now
[00:58] -queuebot:#ubuntu-release- New: rejected gjs [ppc64el] (artful-proposed) [1.49.90-0ubuntu0~artful1]
[00:58] -queuebot:#ubuntu-release- New: rejected gjs [arm64] (artful-proposed) [1.49.90-0ubuntu0~artful1]
[00:58] -queuebot:#ubuntu-release- New: rejected gjs [i386] (artful-proposed) [1.49.90-0ubuntu0~artful1]
[00:59] <slangasek> jbicha: but you don't need it there and you're not getting the binaries back - so I've gone ahead and removed it anyway
[00:59] <slangasek> package in -proposed that is expected to never migrate> zot
[01:01] <jbicha> if we didn't care about s390x, the binaries might have been fine, but thanks!
[01:03] <slangasek> it might technically be possible to resuscitate both source and binaries later without a rebuild, but tbf who cares, it's cheaper for you to reupload and let the NEW process work than to get someone to fish things out of the librarian
[01:03] <tsimonq2> slangasek: Could you please badtest libreoffice/s390x in artful triggered by debhelper/10.7.2ubuntu2 so debhelper can migrate? From what I remember it's a kernel regression that's unrelated to debhelper. I asked acheronuk to retrigger libreoffice/s390x with itself as a trigger at the beginning of the day today and it fails.
[01:05] <slangasek> tsimonq2: there are a mix of passes and failures for libreoffice/s390x recently; I'm going to need some more evidence that it's a testbed problem
[01:06] <slangasek> tsimonq2: n/m, I found my previous hint for i386+s390x about this issue
[01:06] <slangasek> tsimonq2: providing a reference to an existing hint in lp:~ubuntu-release/britney/hints-ubuntu is usually the most efficient way to get me to ack a badtest :)
[01:07] <slangasek> (done)
[01:21] -queuebot:#ubuntu-release- New binary: insighttoolkit4 [s390x] (artful-proposed/universe) [4.12.0-dfsg1-1ubuntu2] (no packageset)
[01:30] <tsimonq2> slangasek: Thanks!
[02:28] <ahoneybun> cyphermox: working on your idea
[02:43] <ahoneybun> that does not look better lol
[03:51] -queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [2.15-0ubuntu6~ubuntu16.04.1 => 2.16-0ubuntu2~ubuntu16.04.1] (edubuntu, ubuntu-server)
[03:51] -queuebot:#ubuntu-release- Unapproved: lxd (zesty-backports/main) [2.15-0ubuntu6~ubuntu17.04.1 => 2.16-0ubuntu2~ubuntu17.04.1] (edubuntu, ubuntu-server)
[03:57] -queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-backports) [2.16-0ubuntu2~ubuntu16.04.1]
[03:58] -queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (zesty-backports) [2.16-0ubuntu2~ubuntu17.04.1]
[05:10] -queuebot:#ubuntu-release- New binary: courier-unicode [amd64] (artful-proposed/universe) [2.0-1] (no packageset)
[05:10] -queuebot:#ubuntu-release- New binary: courier-unicode [ppc64el] (artful-proposed/universe) [2.0-1] (no packageset)
[05:11] -queuebot:#ubuntu-release- New binary: courier-unicode [s390x] (artful-proposed/universe) [2.0-1] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: courier-unicode [arm64] (artful-proposed/universe) [2.0-1] (no packageset)
[05:12] -queuebot:#ubuntu-release- New binary: courier-unicode [i386] (artful-proposed/universe) [2.0-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: courier-unicode [armhf] (artful-proposed/universe) [2.0-1] (no packageset)
[07:24] <ginggs> would someone please update the winff hint? maybe 'force-badtest winff/all/armhf' is best, since it hasn't passed since trusty
[08:48] <LocutusOfBorg> hello slangasek what about doing the qt5.9 dance instead of trying to patch 5.7 against the new gcc?
[08:48] <LocutusOfBorg> it is ready to land, just needing an AA
[08:55] -queuebot:#ubuntu-release- Unapproved: magnum (zesty-proposed/universe) [4.1.0-0ubuntu1 => 4.1.3-0ubuntu<IP_ADDRESS>] (no packageset)
[09:02] <acheronuk> LocutusOfBorg: I would guess he's asleep now. I'm test building 5.7.1 in a ppa with opensuse/gentoo's patch, but I agree that getting 5.9 transition landed with be far preferable
[09:08] -queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/universe) [1.1+16.04ubuntu3 => 1.1+16.04ubuntu4] (no packageset)
[09:44] <mitya57> tsimonq2, I am personally fine with having it stuck in proposed for a week or two, but others may get not very happy about it.
[09:45] <mitya57> So far I think that if someone still needs ubuntu-ui-toolkit for their packages, *they* should take care of updating it to 5.9.
[09:46] <mitya57> And I do not know which packages we are talking about. If it is just checkbox, then we can revert to the pre-Qt version of it.
[11:08] -queuebot:#ubuntu-release- New binary: xml-rpc-el [amd64] (artful-proposed/none) [1.6.12-2] (no packageset)
[11:11] -queuebot:#ubuntu-release- New binary: debpaste-el [amd64] (artful-proposed/none) [0.1.5-2] (no packageset)
[12:25] -queuebot:#ubuntu-release- Unapproved: landscape-client (trusty-proposed/main) [14.12-0ubuntu5.14.04 => 14.12-0ubuntu6.14.04] (ubuntu-desktop, ubuntu-server)
[13:27] -queuebot:#ubuntu-release- Unapproved: packagekit (xenial-proposed/main) [0.8.17-4ubuntu6~gcc5.4ubuntu1.1 => 0.8.17-4ubuntu6~gcc5.4ubuntu1.2] (kubuntu, ubuntu-desktop)
[13:36] <tsimonq2> mitya57: I remember Qt being in -proposed for a month and a half when Unity 8 was still actively developed... one or two weeks is nothing right now ;)
[13:37] <tsimonq2> mitya57: But yeah, this transition will be unusual because we're working out the Unity 8 stuff. The next Qt transition *should* be easier.
[15:23] -queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (trusty-proposed) [14.12-0ubuntu6.14.04]
[15:41] <cpaelzer> ping on bug 1540323 for an aa to remove packages
[15:50] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [1.1+16.04ubuntu4]
[16:27] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20170711.1-0ubuntu<IP_ADDRESS> => 1:20170808.1-0ubuntu<IP_ADDRESS>] (no packageset)
[16:27] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (zesty-proposed/partner) [1:20170711.1-0ubuntu<IP_ADDRESS> => 1:20170808.1-0ubuntu<IP_ADDRESS>] (no packageset)
[16:27] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20170711.1-0ubuntu<IP_ADDRESS> => 1:20170808.1-0ubuntu<IP_ADDRESS>] (no packageset)
[16:28] <xnox> Laney, slangasek - please hint util-linux s390-tools to go in together.
[16:33] <slangasek> xnox: what kind of hint are you looking for?  AIUI s390-tools is tied to net-snmp transition
[16:33] <slangasek> which means it's tied to the big transition
[16:35] <xnox> slangasek, it is tied, I do not see it tried together with the rest. E.g. util-linux and s390-tools are not tried together, despite both being valid candidates.
[16:36] <xnox> slangasek, as far as i can tell the two are installable in both -proposed and -release and thus those two leaf packages can migrate irrespective of the big transition.
[16:36]  * xnox is possibly wrong, but the only uninstallable currently listed in output is due to not trying the two together.
[16:36] -queuebot:#ubuntu-release- Unapproved: accepted pollinate [source] (xenial-proposed) [4.25-0ubuntu1~16.04.1]
[16:36] <slangasek> xnox: it's not tried together with the rest because util-linux doesn't need to go in together, it only needs to go in after (because of the one-way breaks)
[16:37] <slangasek> xnox: so no manual hinting needed, we just need to get p-m to pass the stone
[16:37] <xnox> hm.
[16:39] <xnox> ok.
[16:40] <xnox> slangasek, any idea why http://people.canonical.com/~ubuntu-archive/transitions/ocaml.html ocaml is no longer installable? is that also in the big transition of doom now?
[16:41] <slangasek> xnox: according to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt output, ocaml is not tied in
[16:45] -queuebot:#ubuntu-release- New binary: libgtop2 [amd64] (artful-proposed/main) [2.37.90-0ubuntu1] (ubuntu-desktop)
[16:45] -queuebot:#ubuntu-release- New binary: libgtop2 [ppc64el] (artful-proposed/main) [2.37.90-0ubuntu1] (ubuntu-desktop)
[16:45] <coreycb> hi release team, i synced sphinx from experimental and it's causing problems. can we reject it from artful-proposed and stick with 1.5.6-2 for now?
[16:46] -queuebot:#ubuntu-release- New binary: libgtop2 [i386] (artful-proposed/main) [2.37.90-0ubuntu1] (ubuntu-desktop)
[16:46] -queuebot:#ubuntu-release- New binary: libgtop2 [s390x] (artful-proposed/main) [2.37.90-0ubuntu1] (ubuntu-desktop)
[16:48] <slangasek> addressed coreycb's request
[16:51] -queuebot:#ubuntu-release- New binary: libgtop2 [arm64] (artful-proposed/main) [2.37.90-0ubuntu1] (ubuntu-desktop)
[16:54] -queuebot:#ubuntu-release- Unapproved: accepted pollinate [source] (trusty-proposed) [4.25-0ubuntu1~14.04.1]
[16:56] -queuebot:#ubuntu-release- New binary: libgtop2 [armhf] (artful-proposed/main) [2.37.90-0ubuntu1] (ubuntu-desktop)
[17:00] <ginggs> would someone please update the winff hint? maybe 'force-badtest winff/all/armhf' is best, since it hasn't passed since trusty
[17:00] <ginggs> slangasek: ^ seeing you are around :)
[17:02] <slangasek> ginggs: /all/ hinting means that if and when the test is fixed we don't pick it up. the solution with least collateral damage is LP: #1700668, if you can convince Laney of the design ;)
[17:04] <slangasek> we need a tool added to ubuntu-archive-tools that scans update_excuses for all regressions and matches them to existing badtest hints for a different version
[17:04] <slangasek> anyone want to write that? :)
[17:05] <ginggs> slangasek: elbrus cares about autopkgtests, so if it does start to pass on armhf i think he'll let us know
[17:05] <ginggs> but yeah, we do need a general solution
[17:06] <slangasek> I don't assume elbrus would notify us to remove a hint that's letting us ignore failures
[17:12] <slangasek> doko: ah, thanks for the pillow delete - let me also resurrect the no-change rebuild, then
[17:13] <xnox> slangasek, somehow i'm not sure how i can help with migrations. I think i will work on making ocaml stack installable and migratable again the bits that got synced/updated. but that is about it.
[17:13] <xnox> and the systemd adt regresions.
[17:14] <slangasek> xnox: well, for example, anything that's listed on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt as broken by the big migration, but not listed on http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_output_notest.txt , needs sorting out what tests are failing
[17:16] <doko> xnox: you could look at lp: #1709396
[17:18] <slangasek> xnox: (but ignore all the kde stuff there, because that's just waiting on tests to finish for qtwebengine-opensource-src)
[17:21] <slangasek> doko: I now have a "clean" autopkgtest of linux on armhf against new binutils/gcc showing a build failure; can you confirm this is a kernel bug, not a toolchain bug?
[17:21] <xnox> doko, or shall i fix linux/zfs s390x given that i ported that?
[17:21] <slangasek> hinting that will re-unblock binutils
[17:21] <slangasek> xnox: also valuable :)
[17:22] <slangasek> xnox: we've overridden that test for now, but obviously we need kernels to be uploadable
[17:23] <slangasek> xnox: mysql-5.7 also needs sorting (i386 test failure)
[17:24] <slangasek> tdaitx: you want to take a corner of this puzzle?
[17:24] <doko> slangasek: afaics this is the first build of one of the user space tools built using GCC 7, triggered by a warning turned into an error by the build process
[17:25] <slangasek> doko: so the message is correct / has precedent, and the kernel needs fixing. thanks, hinting
[17:31] <tdaitx> slangasek, which one you are referring to?
[17:31] <slangasek> tdaitx: the mega-transition clogging up proposed-migration; see above for a list of possible +1 maintenance tasks to work on
[17:31] <tdaitx> sure
[17:32] <slangasek> tdaitx: if you take one, please let us know which it is :)
[17:32] <tdaitx> will start on that after lunch
[17:35] <xnox> slangasek, please clean http://people.canonical.com/~ubuntu-archive/nbs.html
[17:35] <doko> xnox: done
[17:41] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20170808.1-0ubuntu<IP_ADDRESS>]
[17:41] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (zesty-proposed) [1:20170808.1-0ubuntu<IP_ADDRESS>]
[17:41] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20170808.1-0ubuntu<IP_ADDRESS>]
[18:03] <xnox> http://people.canonical.com/~ubuntu-archive/architecture-mismatches.html is odd no?
[18:07] -queuebot:#ubuntu-release- Unapproved: accepted postfix [source] (xenial-proposed) [3.1.0-3ubuntu0.1]
[18:24] <slangasek> a small tool that may help people deciphering the transition: https://code.launchpad.net/~vorlon/ubuntu-archive-tools/migration-blocked-by-tests
[18:25] <tsimonq2> slangasek: awesome! :D
[18:27] <slangasek> further enhancement would be to make that script track down which source package's failing test is at issue
[18:43] <slangasek> skiptest'ing pillow (it was a candidate once before, we don't need to wait for re-testing).  that should clear a lot of the underbrush
[19:08] <cyphermox> anyone already looking at libgtk2-perl?
[19:09] <cyphermox> (failing test there)
[19:11] <cyphermox> ahoneybun: what do you mean does not look better? maybe we should communicate by screenshot... I mean, if you're happy with the current state of the slideshow as it is in your original merge, I'll just upload that, but it really does look really bad to me here when running test-slideshow.
[19:14] <cyphermox> nevermind about libgtk2-perl, the test was not run with the same version
[19:16] <slangasek> anyone know offhand what's eating the buildd queue?
[19:17] <slangasek> oh hey look, pillow et al. migrated
[19:18] <tsimonq2> Lots of private jobs... :|
[19:19] <slangasek> rbalint1: hi, what can we say about grok? (libevent transition)
[19:19] <infinity> slangasek: iz livepatch.
[19:19] <slangasek> infinity: k
[19:20] <slangasek> rbalint1: looks like a wrong version comparison for gperf, is there a fix in flight anywhere?
[19:22] <slangasek> xnox: so you just uploaded hhvm? wasn't the version in -proposed already ready to migrate?
[19:25] <slangasek> claiming watchcatd
[19:42] <cyphermox> looking at picviz
[19:42] <cyphermox> or has that already been taken?
[19:53] <xnox> slangasek, the one in proposed was not good enough, and not if ftbfs with gcc-7
[19:53] <slangasek> xnox: 'not good enough' how?  was it not a candidate for migration with perl etc?
[20:19] <tsimonq2> Could someone on the SRU team please look at bug 1133477 and bug 1708619? The former of which is important to have because without it, there's potential data loss in Nautilus and Caja, and the latter is a regression in the audio applet in Lubuntu from 16.10 to 17.04 which should get fixed soon...
[20:20] <tsimonq2> Both of which have been uploaded to the queues already, I just think the former is extremely important and worth poking about (the latter is less important but still annoying). :)
[20:22] <rbasak> tsimonq2: I'm EOD now, but please poke me tomorrow (it's my SRU day tomorrow) if you don't get a review before then.
[20:22] <tsimonq2> rbasak: Ok, thank you.
[20:22] <slangasek> rbalint: where would I find API docs for libevent explaining the changes from 2.0 to 2.1?  ev_arg and ev_flags seem to have disappeared without a trace
[20:22] <rbasak> I say that, but I'm still working, unwinding my stack :-/
[20:23] -queuebot:#ubuntu-release- New source: python-certbot-apache (xenial-proposed/primary) [0.14.2-0ubuntu<IP_ADDRESS>]
[20:23] -queuebot:#ubuntu-release- Unapproved: python-acme (xenial-proposed/universe) [0.4.1-1 => 0.14.2-0ubuntu<IP_ADDRESS>] (no packageset)
[20:24] -queuebot:#ubuntu-release- Unapproved: python-letsencrypt (xenial-proposed/universe) [0.4.1-1 => 0.4.1-1ubuntu<IP_ADDRESS>] (no packageset)
[20:24] -queuebot:#ubuntu-release- Unapproved: python-certbot-apache (zesty-proposed/universe) [0.10.2-1 => 0.14.2-0ubuntu<IP_ADDRESS>] (no packageset)
[20:24] -queuebot:#ubuntu-release- Unapproved: python-certbot (zesty-proposed/universe) [0.10.2-1 => 0.14.2-0ubuntu<IP_ADDRESS>] (no packageset)
[20:24] -queuebot:#ubuntu-release- Unapproved: python-letsencrypt-apache (xenial-proposed/universe) [0.4.1-1 => 0.4.1-1ubuntu<IP_ADDRESS>] (no packageset)
[20:24] -queuebot:#ubuntu-release- Unapproved: python-certbot-nginx (zesty-proposed/universe) [0.10.2-1 => 0.14.2-0ubuntu<IP_ADDRESS>] (no packageset)
[20:24] -queuebot:#ubuntu-release- Unapproved: python-acme (zesty-proposed/universe) [0.10.2-1 => 0.14.2-0ubuntu<IP_ADDRESS>] (no packageset)
[20:24] -queuebot:#ubuntu-release- New source: python-certbot-nginx (xenial-proposed/primary) [0.14.2-0ubuntu<IP_ADDRESS>]
[20:24] -queuebot:#ubuntu-release- New source: python-certbot (xenial-proposed/primary) [0.14.2-0ubuntu<IP_ADDRESS>]
[20:33] <xnox> i wish gtk2 and qt4 were dead =)
[20:33] <acheronuk> +1
[20:34] <tsimonq2> +1
[20:35] <tsimonq2> xnox: I'd like to eventually see if we could get Qt 4 off of all the images (well, Kubuntu and Lubuntu Next) and see if we could get it out of the archive after that.
[20:35] <tsimonq2> But I think I'll do a better analysis when 18.10 opens for development.
[20:36] <tsimonq2> Meanwhile, Lubuntu will kill GTK 2 shortly, I don't think it would be off to suggest that 18.10 will be that cycle.
[20:36] <tsimonq2> s/off/far off/
[20:36] <tsimonq2> xnox: But Qt 4 will be quicker than GTK 2 from what I can tell :P
[20:37] <acheronuk> libreoffice-kde is still Qt4 :(
[20:38] <tsimonq2> acheronuk: Maybe in the next year, something can be done to fix that...
[20:39] <acheronuk> yep. could get quite close to no KDE4 on our iso if not for that
[20:40] <tsimonq2> For sure
[20:48] <Ukikie> -1
[20:49] <tsimonq2> Ukikie: oh?
[21:20] <rbalint> slangasek: there is whatsnew-2.1.txt.gz but this change is not covered, i rely on git history to understand the change
[21:22] <rbalint> slangasek: if you haven't started fixing the affected package i will do it and don't wait for Debian maintainers
[21:26] <slangasek> rbalint: I hadn't made any progress, feel free to take it (watchdogd)
[21:29] <rbalint> slangasek: ok, i take it then
[21:31] <slangasek> rbalint: sorry, watchcatd not watchdogd :)
[21:33] <rbalint> slangasek: yes, i got it :-)
[21:55] <slangasek> grok upload fixed
[21:57] <cyphermox> picviz done
[21:57] <cyphermox> I'd do lldpd now
[22:01] <slangasek> mdeslaur, rbasak: any insights into the mysql-5.7/i386 autopkgtest failure?
[22:04] <rbasak> slangasek: I was going to ask someone upstream but he's on vacation until Monday.
[22:04] <slangasek> rbasak: k. do you have any more info beyond what's currently in the log?
[22:06] <rbasak> "Failing test(s): main.mysql_upgrade"
[22:06] <rbasak> I think that test has been unstable in the past.
[22:06] <slangasek> retrying it
[22:07] <slangasek> and yes, it does seem to be the same error seen previously with 5.7.18-0ubuntu1
[22:07] <rbasak> https://anonscm.debian.org/cgit/pkg-mysql/mysql.git/commit/?id=b89cf68d7517c4400a4bd76b6d2a49d24518a8ed may be relevant. It'll be in the next merge.
[22:07] <slangasek> rbasak: hinted for now, thanks
[22:08] <rbasak> (which was actually blocked on my review, and I'd +1 but we got trumped by security because I was slow :-
[22:08] <rbasak> (
[22:08] <cyphermox> slangasek: has update-output-helper never been merged into ubuntu-archive-tools yet?
[22:09] <slangasek> cyphermox: no, I was never able to wrap my head around its usage to the point where I found it consistently helpful, so I haven't ever merged it
[22:15] <cyphermox> ok
[22:15] <cyphermox> well it was broken now anyway due to authenticating package sources
[23:16] <slangasek> acheronuk: thanks for cleaning up the qtwebengine-opensource-src mess.  There is a failing autopkgtest now, http://autopkgtest.ubuntu.com/packages/k/kdepim-addons/artful/armhf - is there any chance this is introduced by qtwebengine, or is it a false positive?  (And if it is a real regression, should we care or should we just hint it in knowing that 5.9 is around the corner?)
[23:21] <slangasek> qtwebengine is possibly the only package currently blocking wrt tests.  we also need gcc-7 ready to go again, webauth (available in the next run), watchcatd, hhvm (which could be removed), and then we might actually be done?
[23:22] <slangasek> that, and a kernel unblocked (apw?)
[23:26] -queuebot:#ubuntu-release- New binary: insighttoolkit4 [armhf] (artful-proposed/universe) [4.12.0-dfsg1-1ubuntu2] (no packageset)
[23:46] <mwhudson> so why the heck is python-urllib3 not migrating
[23:47] <mwhudson> ah it needs to migrate with requests i think
[23:48] <mwhudson> which is blocked by python-pydap tests failing
[23:49] <slangasek> mwhudson: because of some sort of s390x-specific breakage, AFAICS from update_output
[23:50] <mwhudson> slangasek: how do you get that?
[23:50] <slangasek> mwhudson: the uninstallables count is only increased for s390x
[23:50] <mwhudson> skipped: python-urllib3 (0, 23, 9)
[23:50] <mwhudson>     got: 92+0: a-7:a-7:a-7:i-59:p-6:s-6
[23:51] <mwhudson> ?
[23:51] <slangasek> mwhudson: ah, I refresh and I get a different list. so this is actually the funny business of reporting arch: all packages against a random arch
[23:52] <mwhudson> yeah i think so
[23:52] <mwhudson> i still don't understand update_output but it's definitely not going to migrate without requests also migrating
[23:53] <slangasek> right


[05:58] <darkxst> jbicha, gnome3-team/staging basically supercedes ricotz/testing? correct?
[05:59] <darkxst> well apart from testing being git snapshots vs releases?


[06:22] <shawn> hey hey
[06:25] <JohnDoe_71Rus> hi
[08:12] <cerebrate> hi
[16:13] <artrei> so i was using ubuntu and install lxde before i move to lubuntu entirely, i still have the lxde profile, can i delete this profile? or make lubuntu profile my default?
[16:14] <holstein> artrei: i just select it at login, and the next time, it is what is suggested.. is that enough?
[16:15] <artrei> holstein, can i delete that lxde profile? or it is also exist in lubunt package
[16:19] <holstein> artrei: you can do literally anything, since its all open.. what i do is, i choose the lubuntu session, then i get that , as "default" for the next logins.. is that enough?
[16:20] <holstein> otherwise.. what sessions do you have? what are you wanting to remove?
[16:21] <Scouse> looking to install lubuntu on old pc for kids, does it support Google Chrome?
[16:21] <artrei> Scouse, chromium is default browser but you can also install chrome
[16:21] <holstein> Scouse: lubuntu is ubuntu.. so anything in ubuntu is suppported.. the question is, doesn chrome support lubuntu, and yes it does
[16:22] <Scouse> pc spec is Intel celeron 1.7ghz proessor and 400mb ram
[16:22] <holstein> Scouse: just download the iso, and try it live on your hardware
[16:23] <artrei> according to task manager, i only use 250mb ram right now
[16:24] <Scouse> once downloaded can i run it live on windows to see if i like it and it runs ok before fully installing
[16:25] <artrei> Scouse, boot from CD
[16:25] <holstein> Scouse: you run it live from the cd.. you could literally have no hard drive in the machine
[16:29] <Scouse> downloading lubuntu 12.10 now and unetbootin
[16:29] <holstein> Scouse: i, and others have suggested 12.04.. use what you want though
[16:56] <Scouse> After being advised to look into Lubuntu as opposed to ubuntu I had a quick look on Youtube and heard about a nicer lighter alternative called Bohdi. Which is better to use for a windows user and linux newbie?
[16:58] <Scouse> I do like how Lubuntu look like a old windows system though
[16:59] <Scouse> but i do prefer how ubuntu looks
[17:00] <wxl> Scouse: it's hard to say what's "better." i have found bodhi sometimes difficult to deal with. lubuntu has great support, but it's not 100% user-friendly, although it is imho the best blend of lightweight and easy to use. you might try mint.
[17:00] <wxl>  Scouse: or better yet, just get a live cd of lubuntu and try it out.
[17:01] <Scouse> was going to download lubuntu and put it onto a live usb had to switch from old pc to laptop though
[17:04] <Scouse> can you have a apple style application bar or ubuntu application bar in lubuntu?
[17:04] <wxl> well really you can add whatever you want but the general rule is the more you add, the less lightweight it gets
[17:05] <wxl> i find there is a direct correlation with how pretty you want things and how heavy the operating system is
[17:09] <holstein> Scouse: you can try most any of the distros live.. try them and decide for yourself
[17:09] <Scouse> that is true, the system is old and being used by the kids so want it to run and be simple for them to use but having never used linux before I obviously have a few reservations but windows is just such a heavy OS and makes the system lag
[17:10] <holstein> "simple" is also a matter of opinion, to some degree.. most folks want what they are accustomed to, and i dont know that that is for you or your family
[17:12] <wxl> as i said, part of that is all the prettiness and/or convenience features
[17:12] <Scouse> is lubuntu that different from windows in terms of opertion
[17:12] <wxl> if you don't need a gui, you end up with a REALLY LIGHT operating system :)
[17:12] <Scouse> *operation
[17:13] <wxl> ultimately, no, all operating systems are basically the same. but it's like bicycles. you could have a single speed and a road bike and a mountain bike. they do the same thing, just differently.
[17:13] <Scouse> gui doesn't really make much difference as long as possible to add shortcuts to desktop as 99% of time everything is done ONLINE
[17:14] <holstein> if you want windows, i would use windows.. i dont, so i use linux
[17:15] <holstein> is lubuntu capable? sure.. will it work for you and your family? its is absolutely 100% free/easy for you to find that out for yourself
[17:17] <Scouse> @holstein - you are not really providing much help or information just trying to get me to go off and install operating systems. As I have already said the main reason for looking to install a version of linux is because windows is too heavy to run on the old pc
[17:17] <wxl> Scouse: as i said before it's hard to definitively answer the question of what's better. there's no one answer to a subjective question. i think that's why holstein appears to be elusive.
[17:17] <holstein> Scouse: you dont have to install it, at all
[17:18] <holstein> Scouse: you can literally remove your windows hard drive to keep it "safe" if you like
[17:18] <wxl> assuming we're not talking about particular windows-only applications, you can do everything in linux you can in windows and then some.
[17:18] <Scouse> no but you are just basically saying go try this and this and this
[17:18] <holstein> Scouse: i can not tell you if you will "like" it.. i can say it is capable.. and it works for me.. and i can share for you examples of how it works for me, if you like
[17:18] <wxl> the only this anyone has said to try is the live cd, which is a temporary version that runs in memory and is not installed at all
[17:19] <holstein> Scouse: i am just saying, you *can* try it for yourself.. and see.. i have no idea what your needs are, and i cant say it will meet them all in a casual chat on IRC
[17:19] <Scouse> thanks then for no real help and just arragance
[17:19] <holstein> Scouse: i migrate users to linux all the time, and there is a process of evaluating applications used. you have mentioned chrome.. and chrome workks grat
[17:19] <holstein> ?
[18:25] <ntzrmtthihu777> question about the lubuntu desktop in relation to the gnome-desktop
[18:26] <ntzrmtthihu777> in gnome the menu items are sorted by their *.desktop files "Categories" line, is it such in lubuntu?
[21:37] <ojkolsrud> HELLOOOOO.....hellooo....hello..