[00:04] <slangasek> SpamapS: Reject Reasons:
[00:04] <slangasek> libmysqlclient18: lintian output: 'missing-pre-dependency-on-multiarch-support
[00:04] <slangasek> +', automatically rejected package.
[00:05] <slangasek> forgot that svn-buildpackage doesn't use debuild so doesn't call lintian :P
[00:08] <slangasek> SpamapS: so, bumping the debhelper build-dep and setting Pre-Depends: ${misc:Pre-Depends} per http://wiki.debian.org/Multiarch/Implementation is needed here
[00:39] <Daviey> infinity: Do you think you'll be able to look at bug 759545 before a1?
[00:42] <slangasek> given that infinity is still bootstrapping armhf, I wouldn't count on it
[00:44] <Daviey> slangasek: thanks.
[00:59] <SpamapS> slangasek: ACK, will fix and make sure to run lintian
[00:59] <slangasek> SpamapS: ta
[01:06]  * SpamapS slogs through missing/broken perl deps...
[01:24] <SpamapS> slangasek: so, can we re-use 5.5.17-3 or do we need to bump to 5.5.17-4 ?
[01:34] <poolie> does USC have an option to install stuff from tarballs or is this user just confused about tarballs vs debs?
[01:38] <SpamapS> slangasek: anyway, bumped to 5.5.17-4. I'll be in the mountains for the next 3 days, so hopefully this one works. :)
[01:50] <slangasek> SpamapS: thanks, building
[01:51] <slangasek> SpamapS: btw, Pre-Depends: ${misc:Pre-Depends} should have been sufficient here, the substition gets expanded to multiarch-support
[01:51] <slangasek> (so the explicit declaration is a redundant no-op)
[02:01] <SpamapS> slangasek: *ahhh*
[02:19] <slangasek> SpamapS: lintian doesn't think much of your debian/copyright. ;) uploading anyway
[04:14] <infinity> Daviey: What vorlon said.  I might find time, but armhf is everything right now.  And she'll hit me if I say otherwise.
[05:02] <pitti> Good morning
[05:03] <pitti> slangasek: no worries, it wasn't a bad breakage; but I thought it was a good candidate/exercise for reversion, as per Rick's new policy
[05:23] <ScottK> What policy is that?
[05:24] <pitti> ScottK: "never break precise"
[05:25] <pitti> ScottK: well, less of a policy, more a set of best practices
[05:25] <ScottK> So all those times when we broke the development release before were on purpose?
[05:25] <ScottK> Good thing we have the new policy to avoid it...'
[05:25] <pitti> if we introduce a regression that breaks daily images or upgrades, and reverting it doesn't make things worse, we sohuld revert
[05:25] <ScottK> ;-)
[05:25] <ScottK> Right.  I remember something about that now.
[05:26] <pitti> and for bigger transitions, we need to come up with a staging area solution (such as using -proposed and running automatic tests against that), but that hasn't been fleshed out fully yet
[05:26] <ScottK> We could all is "Unstable".
[05:26] <ScottK> all/call
[05:29] <pitti> ScottK: we'll never get this perfect anyway, but there have been several situations in the past where breakage has been sitting there for days and weeks, so a little more rigor there is certainly adequate
[05:29] <ScottK> I agree with that.
[07:46] <dholbach> good morning
[07:59] <freeflying> slangasek: procps (1:3.2.8-11ubuntu4) failed again
[08:25] <slangasek> freeflying: failed how?
[08:43] <freeflying> slangasek: Errors were encountered while processing: procps
[08:43] <freeflying> E: Sub-process /usr/bin/dpkg returned an error code (1)
[08:44] <slangasek> freeflying: not reproducible, need the full error message please
[08:45] <pitti> I ran my oneiric VM, switched apt to precise, apt-get install procps -> fine
[08:46] <pitti> freeflying: locally modified conffile perhaps? as a workaround to the previous failure?
[08:46] <pitti> precise(yesterday) -> precise(today) on my workstation also worked, FTR
[08:47] <freeflying> slangasek: http://paste.ubuntu.com/742035/
[08:48] <slangasek> freeflying: is this a chroot?
[08:48] <freeflying> slangasek: no
[08:48] <slangasek> hmm
[08:48] <freeflying> pitti: fresh installation with today's daily build iso, previous was 3.2.8-11ubuntu3
[08:49] <slangasek> well, that's a pretty generic upstart failure.  What happens if you try to manually run the command from /etc/init/procps.conf?  cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p -
[08:51] <freeflying> slangasek: manually run is fine
[08:51] <slangasek> freeflying: is it a locally modified conffile maybe, like pitti asks?
[08:51] <slangasek> oh, you said it's a fresh install
[08:51] <freeflying> slangasek: no
[08:51] <slangasek> so probably not
[08:51] <slangasek> :)
[08:52] <slangasek> freeflying: can you do 'initctl log-priority info', try to configure the package again, and then check /var/log/kern.log for any information from upstart?
[08:56] <freeflying> slangasek: nothing output to kern.log
[08:56] <broder> slangasek: ...kern.log? do we even still use that?
[08:56] <slangasek> don't we?
[08:56] <pitti> sure we do
[08:56] <broder> i thought we rolled everything into syslog
[08:57] <broder> huh. i stand corrected
[08:57] <slangasek> no, only the things that it's reasonable to merge :)
[08:57] <pitti> broder: we got rid of /var/log/messages
[08:57] <pitti> which was really redundant, given sys/auth/kern logs
[08:58] <slangasek> freeflying: please post a copy of whatever file you have as /etc/init/procps.conf currently; also, please show 'initctl list | grep procps'
[09:02] <freeflying> slangasek: http://paste.ubuntu.com/742046/
[09:02] <freeflying> slangasek: initctl list | grep procps
[09:02] <freeflying> procps stop/waiting
[09:02] <slangasek> freeflying: well, that looks correct
[09:04] <slangasek> freeflying: when you ran the command by hand, did it return 0?
[09:04] <freeflying> slangasek: which one
[09:05] <slangasek> freeflying: the 'cat ... | sysctl' one
[09:05] <freeflying> slangasek: yes, return 0
[09:05] <infinity> cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p - || echo Bollocks.
[09:14] <cjwatson> SpamapS: which missing/broken perl deps did you run into?  (I have a full report, I'm just interested in which of the 14 remaining problems bit you)
[09:23] <Mirv> does someone know the definitive list of needed kernel config options to have ureadahead working?
[09:24] <Mirv> google is not much of a friend this time, or the information is obsolete, or I'm having some unrelated problem. for example it seems CONFIG_ENABLE_DEFAULT_TRACERS is no more.
[09:53] <dbarth> rickspencer3: ping?
[09:54] <rickspencer3> hi dbarth
[09:54] <rickspencer3> s'up?
[09:54] <dbarth> hi
[10:07] <ev> @pilot in
[12:04] <highvoltage> dholbach: hey there, edubuntu.org is down and I filed a ticket on RT, do you know if there's anyone in particular I could (or should) poke about that?
[12:05] <dholbach> highvoltage, #canonical-sysadmin
[12:05] <dholbach> I'd simply ask in there
[12:05] <dholbach> highvoltage, and http://edubuntu.org/ works for me
[12:06] <highvoltage> ah, and so it does for me now. that was fast :)
[12:06] <zumbi_> ogra_: hi!
[12:06] <ogra_> hey :)
[12:07] <zumbi_> ogra_: re ubuntu core, I wonder how gcc cross fits, as it is multiarch, so it links to system libraries
[12:07] <zumbi_> ogra_: so imagine my product uses distro suite N and my host is suite N+2
[12:08] <zumbi_> ogra_: if I cross compile my app against multiarch system libraries, it will link to suite N+2
[12:08] <ogra_> oh, i think that might get you into probs
[12:08] <zumbi_> ogra_: thats why a sysroot enabled cross tool migh tbe useful
[12:08] <ogra_> not sure though, hrw is our cross toolchain specialist
[12:09] <ogra_> and riku 8as i said in the other channel) works on porting packages to cross buildability
[12:09] <zumbi_> yes, I have contact to these people, I follow what they do too
[12:09] <ogra_> we also have a spec for that for 12.04 to get a subset of packages cross functional
[12:09] <ogra_> but i fear you need to use the same release version for both atm
[12:10] <zumbi_> I just wanted to point out a possible pitfall, now that you seem to be going commercial with it
[12:10] <zumbi_> I have to say I am very please to see it happening
[12:10] <ogra_> yeah, it was overdue
[12:10] <zumbi_> *pleased
[12:11] <ogra_> we will still go on building the distro natively on the buildds though :)
[12:11] <zumbi_> sure, cross compiling the debian core from scratch is not easy task
[12:11] <ogra_> well, its a future target for linaro
[12:11] <ogra_> some day they will make it :)
[12:12] <zumbi_> ogra_: as a hobby project, which I have no time for, I wanted to create a mini-core based around busybox and uclibc
[12:13] <ogra_> well, that will surely get you a lot of trouble if you start using "normal" packages ... the busybox tools are to different in many earas
[12:13] <zumbi_> that might be interesting for a future milestone too
[12:13] <ogra_> *areas
[12:13] <ogra_> iirc that was discussed at UDS ...
[12:14] <zumbi_> ogra_: surely it would be incompatible with normal packages, but maybe we could find a way to upgrade from uclibc minimal core into eglibc core
[12:14] <ogra_> what i would do to get a minimal system would just be using update-initramfs turn it into a tarball ;)
[12:14] <hrw> zumbi_: if you want sysrooted cross toolchain then you can build it ;D
[12:14] <ogra_> +and
[12:14] <zumbi_> hrw: yep, thats for sure
[12:15] <zumbi_> hrw: but I dont think thats the binary based distro mindset
[12:15] <hrw> yep
[12:16] <zumbi_> ogra_: uhm.. initramfs rootfs tarball, might be kinda of curious
[12:16] <ogra_> the prob with these minimal fses is that at some point you want a package tool ...
[12:16] <ogra_> which in the end forces you to have perl (dpkg) and pathin (apt)
[12:16] <ogra_> *python
[12:17] <ogra_> which then bloats the rootfs, no matter how small it was initially
[12:17] <zumbi_> ogra_: yes, but busybox has dpkg replacement
[12:17] <ogra_> which doesnt help with maintainer scripts :)
[12:17] <zumbi_> I got mini python, kernel and uclibc minimal system in 2.5MB :)
[12:18] <zumbi_> ogra_: indeed, it would require another pool of packages, not compatible with main pool
[12:18] <ogra_> indeed, but at what compatibility level ?
[12:18] <hrw> I got x11, wifi, bt, pim, glibc, kernel in 16MB
[12:18] <hrw> with package management - but not debian/ubuntu
[12:18] <zumbi_> hrw: thats huge :P
[12:19] <hrw> zumbi_: ok, I got ~2MB free in this flash too ;d
[12:20] <zumbi_> hrw: hey.. you and your open embeddish hat :)
[12:21] <zumbi_> well, I'll have a look to ubuntu core stuff, its great to see it happening
[12:21] <ogra_> :)
[12:58] <dantti> cnd: ping
[13:50] <ogra_> pitti, poke
[13:50] <ogra_> pitti, looking at http://status.ubuntu.com/ubuntu-precise/ubuntu-arm.html i'm wondering why all WIs from foundation team members show up for https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-lts-upgrades in our chart
[13:51] <ogra_> doko__ and infinity are in ubuntu-arm, but why do mvo's items show up there ?
[14:17] <herton> pitti: hi, I noted some packages are on universe instead of main, if you can take a look: http://archive.ubuntu.com/ubuntu/pool/universe/l/{linux,linux-lts-backport-natty,linux-lts-backport-maverick} and http://ports.ubuntu.com/pool/universe/l/{linux-ti-omap4,linux-fsl-imx51,linux-ports-meta,linux-meta-ti-omap4,linux-lts-backport-natty,linux-lts-backport-maverick} and http://ports.ubuntu.com/pool/universe/l/linux/ (this last one only the hardy 3
[14:17] <herton> 0.96 pkgs)
[15:41] <cnd> dantti, pong
[16:03] <pitti> herton: meh, one of these days we need to fix this more permanently
[16:07] <pitti> herton: do you happen to have an automatically generated report for this somewhere, which includes the corresponding releases?
[16:07] <mterry> doko__, you around?  Curious whether you were going to grab the ocaml merge or whether you want to hand it off
[16:07] <herton> pitti: unfortunately no, I'm thinking about writing a tool to verify it and produce a report though
[16:08] <pitti> jdstrand: ^ for example, the security team has a script which yells "archive is broken" on ABI inconsistencies, but unfortunately it doesn't check components
[16:08] <cjwatson> pitti: there's pocket-mismatches in cocoplum:~lp_archive/dak/, although it has kind of noisy output and I haven't got round to putting it somewhere public yet
[16:08] <cjwatson> if that helps
[16:09] <jdstrand> mdeslaur has that script these days
[16:20] <pitti> herton: I think I caught them all, but might have missed some; need to check again later/after meeting/Monday
[16:20] <herton> pitti: ok, thanks
[16:21] <pitti> then pocket-mismatches should have a more useful output again, too
[16:22] <pitti> and in fact the very ones I just moved aren't even in there
[16:22] <dantti> cnd: hi, I'm trying to probe the battery status of my apple trackpad/keyboard, and I saw you were the one that added support for it, I see it has a feature 71 that seems to be battery stuff, do you have any hints on how to probe that?
[16:23] <pitti> ah, it's split by release, nevermind
[16:23] <dantti> cnd: do I have to code this on hid or is it possible to write some app that can talk to hid directly?
[16:24] <doko__> mterry, ok, I can do that, will look at it tomorrow
[16:24] <mterry> doko__, oh sweet, thanks
[16:24] <mterry> tomorrow is saturday!  I don't want it that bad  :)
[16:26] <doko__> yeah, have to take care about my mobile contract which was terminated without reason while I was in the US ...
[16:29] <cjwatson> doko__: bug 891720 needs to be fixed quickly; can you do it, or want me to?
[16:33] <cnd> dantti, I don't really know
[16:33] <cnd> that comment in the code was from the guy who wrote the magic mouse support
[16:34] <cnd> I just added magic trackpad support onto it
[16:34] <cnd> if you have a mac, you can sniff the hid packets and maybe figure it out
[16:34] <cnd> that's what I did to reverse engineer the input protocol for the trackpad
[16:35] <cnd> by "have a mac", I mean if you "have OS X"
[16:35] <dantti> cnd: hmm I don't :P
[16:35] <dantti> I tried to run it on VBox but didn't worked...
[16:35] <cnd> dantti, you could try poking at it with different feature report values, but I have no clue how successful you would be :)
[16:36] <dantti> cnd: right but how do I do that?
[16:36] <cnd> dantti, modify the hid-magicmouse module
[16:36] <dantti> as it really seems that if I ask the feature 71 it would report that but I have no clue on how to do that :P
[16:36] <cnd> or maybe use hidraw somehow
[16:37] <doko__> cjwatson, need to run to the shop. will do it within the next hour
[16:37] <dantti> hmm right there is no such nice hid lib.. :P
[16:37] <dantti> cnd hidraw can be used by an user space app?
[16:38] <cjwatson> doko__: thanks
[16:38] <cnd> dantti, I think so
[16:38] <cnd> I've never used it myself
[16:38] <dantti> cnd: hidraw or the mouse? :P
[16:39] <dantti> well probaly the former..
[16:39] <cnd> hidraw
[16:39] <cnd> I have both a mouse and a trackpad :)
[16:40] <dantti> cnd: I have a keyboard and a trackpad, the keyboard I received broken from my boss but it stopped working and I'm not sure if it was because of the batteries, that's why I want this to work...
[16:43] <hallyn> zul, oh hey, are you piloting this afternoon?
[16:44] <hallyn> zul,  today is my first turn.  can i co-pilot with you if you do this afternoon?  :)
[16:48] <pitti> ev: accepted https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-crash-signatures for precise, so that it'll appear in the WI tracker
[16:49] <hallyn> eh, maybe i'll just focus on virt patches
[16:50] <Daviey> hallyn: Have you seen, https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Patch_Pilots ?
[16:51] <hallyn> Daviey, yup
[16:51] <hallyn> its what i'm looking through this morning
[16:54] <SpamapS> cjwatson: I'm still not entirely sure, but one was libsvn-perl .. I did start my dist-upgrade right before the transition, so it was likely a transient problem
[16:54] <ev> pitti: cheers!
[16:54] <cjwatson> SpamapS: libsvn-perl is fixed
[16:54] <SpamapS> cjwatson: update/install forcibly fixd it
[16:55] <cjwatson> http://people.canonical.com/~ubuntu-archive/transitions/perl5.14.html <- remaining problems
[16:56] <cjwatson> there's a doc-base upgrade bug (awaiting perl sync) and possibly an update-inetd problem with samba which will be a replay of the previous one; fixes for both in progress
[16:56] <SpamapS> cjwatson: yeah it seems all of it is working now.
[16:57] <hallyn> wtf
[16:57] <hallyn> cjwatson, thanks
[16:57] <cjwatson> ~praise topic-diff.pl
[16:59] <SpamapS> cjwatson: I think the other one was libdbi-perl
[16:59] <cjwatson> that's fixed too
[16:59] <SpamapS> cjwatson: which I just now got back by re-installing mysql-client
[16:59] <cjwatson> you must have been fairly early in the transition
[17:03] <SpamapS> slangasek: About that copyright file and dep5 ... I think I want to raise a bug in the dep5 format that encourages hyper redundancy.
[17:04] <SpamapS> slangasek: the missing paragraphs are identical to all the other paragraphs of the same type... so I'm thinking we should be able to just say "Standard GPLv2 header md5sum affaed8daf7af7faf8..." or something like that.
[17:09] <slangasek> SpamapS: you're supposed to be able to have a stand-alone License: paragraph that other paragraphs can refer to?
[17:10] <slangasek> SpamapS: but the spec is currently not clear about this, which is one of the things that needs fixed before I'll personally bless the spec
[17:11] <SpamapS> slangasek: definitely not clear, I read it as License: is always attached to Files:
[17:14] <SpamapS> slangasek: its possible I could have put this Comment: as the paragraph I suppose..
[17:15] <SpamapS> Comment: These files fall under the blanket license specified in the file COPYING
[17:15] <SpamapS> License: GPL-2
[17:15] <slangasek> SpamapS: Standalone License Paragraph (Optional, Repeatable)
[17:16] <slangasek> SpamapS: please raise this issue on debian-project, this ambiguity is critical :)
[17:16] <SpamapS> slangasek: is that new?
[17:16] <SpamapS> I admit I have not tracked changes to it since I first read it over a year ago.
[17:17] <slangasek> it may have been rearranged, but it's not new in the past year
[17:18] <Daviey> dep-'s having ambiguity shocker.
[17:18] <SpamapS> slangasek: hrm.. ok, well I totally missed the standalone license bits. I think I could save 500 lines in the copyright file with that.
[17:18] <SpamapS> given that it is 762 lines.. thats significant. :)
[17:21]  * slangasek nods
[17:22] <SpamapS> actually I think I already made that optimization
[17:23] <SpamapS> I just forgot the bit about the standalone license paragraph
[17:23] <broder> slangasek: gah. vmware just released an update to vmplayer that still has the buggy insserv call
[17:24] <slangasek> \o/
[17:24] <slangasek> yes, I meant to buttonhole them at UDS about it and never got a chance
[17:24] <broder> no, no. it's still broken
[17:24] <slangasek> that was an ironic \o/, see how the hands list a little bit to the left
[17:24] <broder> ah, i see that now :)
[17:25] <broder> the worst part is that the shell script has a comment "# Ubuntu will spew unrelated warnings..  Hide these."
[17:26] <SpamapS> hrm is there a way to run a single lintian check outside of lintian?
[17:27] <broder> SpamapS: there's a --tags argument to lintian
[17:37] <SpamapS> broder: no I just want to run a single check standalone
[17:37] <SpamapS> broder: like not against a .dsc ..
[17:37]  * SpamapS curses svn-buildpackage for not being able to build w/ local changes
[17:38] <broder> SpamapS: i haven't dug into it enough to know for sure, but i don't think lintian is architected to allow that
[17:38] <broder> but not really sure
[17:38] <SpamapS> yeah
[17:38] <SpamapS> easier to just workaround svn-buildpackage's deficiencies
[17:39] <cjwatson> I'd tend to agree with broder; at the very least you'd have to somehow arrange to run the appropriate collection scripts as well and put their output somewhere
[17:43] <slangasek> broder: unrelated warnings! awesome
[17:44] <slangasek> SpamapS: svn-buildpackage --svn-ignore-new
[17:44] <broder> slangasek: do you remember off the top of your head the LP bug about this? i'm having a hard time finding it
[17:44] <slangasek> or, bzr branch svn+ssh:// [...] && bzr bd ;P
[17:45] <slangasek> broder: not off the top of my head, just off the middle of my mail; one sec
[17:45] <slangasek> broder: bug #858122
[17:45] <broder> thanks
[17:48] <SpamapS> slangasek: does that actually keep local changes?
[17:48] <slangasek> SpamapS: yes; you do have to 'svn add' any new files before calling it, I think
[17:49] <zul> hallyn: sure
[17:53] <dantti> cnd: I'm compiling the mouse module, I'm just not sure about what u8 features means, do you know why it has two values?
[17:55] <cnd> dantti, they are magical values that make the devices change modes
[17:55] <cnd> you'll have to figure out the magical values for getting battery information
[17:56] <dantti> cnd: right my guess is that the value is 71, so it would be __u8 features[] = { 71 };  ?
[17:56] <cnd> I don't know :(
[17:56] <cnd> well, yes, what you wrote is correct
[17:56] <cnd> I meant I don't know if 71 is the value
[17:57] <cnd> sorry if I sound confused, I'm juggling conversations :)
[17:57] <dantti> cnd: ok, the features the device returns seems to be so..  also from a report from hadess 71 is reported as Battery_Strength
[17:58] <cjwatson> jdstrand: we seem to be carrying a patch to iptables introduced by you which installs .la files when Debian doesn't.  this seems like the wrong direction and causes a build failure in collectd (after I fix the first thing it's failing on) - can you explain why it's needed?
[17:58] <dantti> cnd: the min and max goes from 0 to 100 ... :P hopefully this will work ..
[17:58] <cnd> cool
[17:59] <jdstrand> cjwatson: that didn't originate with me, but I merged it. I am assuming you are talking about 9001-build-libipq_pic.la.patch?
[17:59] <cjwatson> no, I'm talking about one that did originate with you, according to the changelog
[17:59] <cjwatson> +  [ Jamie Strandboge ]
[17:59] <cjwatson> [...]
[18:00] <cjwatson> +  * debian/iptables-dev.install: install lib/*.la in usr/lib
[18:00] <cjwatson> those files should in general not be installed unless there is a reverse-dependency that hasn't been weaned off them yet
[18:00] <cjwatson> in this case one of the dependency_libs entries is wrong
[18:01] <jdstrand> I actually that is from <IP_ADDRESS>-2ubuntu1 in karmic
[18:01] <jdstrand> from nxvl
[18:01] <cjwatson> really?  it's not changelogged there
[18:01] <cjwatson> 9001-build-libipq_pic.la.patch is not a problem
[18:02] <nxvl> that was a FTBFS IIRC, right?
[18:02] <nxvl> back around barcelona
[18:02] <jdstrand> let me put it this way. my intent was to just pull what came before along. If I messed up, please correct it :)
[18:03] <cjwatson> it's not in http://patches.ubuntu.com/by-release/atomic/ubuntu/i/iptables/iptables_<IP_ADDRESS>-2ubuntu1.patch.bz2 either
[18:03] <cjwatson> (well, there's a .la entry there but it's commented out
[18:03] <cjwatson> )
[18:06] <jdstrand> cjwatson: the bottom line is I'm happy to fix it. I can't really explain why it is there
[18:06] <cjwatson> jdstrand: ok, well, I can take it out and test collectd with the fixed version if you're cool with that
[18:06] <jdstrand> I should have looked at that more closely during the merge
[18:06] <cjwatson> just wanted to check it wasn't deliberate
[18:06] <jdstrand> cjwatson: I'm totally cool with that :)
[18:07] <cjwatson> ideally I'd like to scan to check it isn't used ...
[18:09] <jdstrand> cjwatson: ah I remember the history of that changelog entry (1.4.10-1ubuntu1). someone submitted a merge request, but didn't merge a bunch of stuff. I was attempting to give the submitter as much credit as possible, but the parts he missed I put under me
[18:09] <jdstrand> cjwatson: that doesn't mean that I didn't screw up or that I shouldn't have looked at that bit more closely of course :)
[18:11] <doko> mterry, ocaml uploaded
[18:12] <mterry> doko, cool, thanks
[18:13] <jdstrand> cjwatson: looking at a debdiff between lucid and natty, it looks like I did goof
[18:13] <jdstrand> cjwatson: and inverted the .a and the .la
[18:14] <cjwatson> ok - I'm just getting hold of aba's script to test whether it's safe to remove the .la entirely
[18:14] <cjwatson> or whether we need to just take out dependency_libs
[18:14] <jdstrand> cjwatson: k, sorry about that
[18:14] <cjwatson> so I can sort it out once I've done that
[18:14] <cjwatson> np
[18:20] <hallyn> @pilot in
[18:27] <hallyn> zul, all right, i guess i'll take another stab at this libvirt migration on lucid one
[18:27] <zul> sweet
[18:30] <dantti> cnd: do you know where hid_output_raw_report store the return data?
[18:31] <cnd> dantti, no, sorry
[18:31] <cnd> I really don't know much about hid
[18:31] <dantti> cnd: k, thanks
[18:31] <cnd> I only knew the very least amount to be able to sniff packets using OS X software and then take what was already in hid-magicmouse and rework it for the trackpad
[18:32] <cnd> dantti, you can ask on the linux-input mailing list
[18:32] <cnd> that is the best source for answers to questions about hid and input in general
[18:33] <dantti> cnd: right thanks, if I can't find anything in google or on any other hid driver I'll try that
[19:17] <dantti> cnd: ok, it's was not output_raw... I should use get_... now I have G�Dp as %s what do you think?
[19:56] <hallyn> jdstrand, for bug 869553, are you working on the patch for upstream (and precise), or should I push/test that?  Is regular qa-regresion-testing (with -m to test migration) sufficient, or were you planning to write some new test for it?
[19:57] <hallyn> i'd be nice if I could push the fixes for that and bug 869590 into lucid-proposed together :)
[20:24] <hallyn> maybe a silly question...  is verifying verification-needed bugs in SRU queue an ok thing to do on patch pilot time?  :)
[20:25] <hallyn> (it does hold up patches, so I assume so...)
[20:30] <jdstrand> hallyn: I am not actively working on it
[20:30] <hallyn> jdstrand, cool, thanks.
[20:30] <jdstrand> hallyn: feel free to push it upstream
[20:31] <jdstrand> (and into precise)
[20:31] <hallyn> ok, will do.
[20:31] <jdstrand> thanks! :)
[20:31] <hallyn> (want to finish up with the 0.9.7 merge first;  but that sort of conflicts with the patch piloting way;  so it feels weird :)
[20:33] <slangasek> hallyn: I don't think anyone's going to slap you for doing SRU verification, though it isn't actually in scope for patch piloting
[20:34] <hallyn> slangasek, ok, thanks.
[20:36]  * hallyn biab
[20:48] <ivacco> help
[20:49] <slangasek> ivacco: this is not a help channel; you probably want #ubuntu
[20:50] <ivacco> not, i like information about how contribute for development of ubuntu
[21:13] <ivacco> i like information about how contribute to development of ubuntu.
[21:14] <slangasek> ivacco: this is probably a good starting point: https://wiki.ubuntu.com/ContributeToUbuntu
[21:24] <slangasek> pitti: I think someone in the session for https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-power-consumption volunteered to look into the black/white screen question, do you recall who?
[21:28] <hallyn> so i gather once i'm done with a patch, i shoud unsubscribe ubuntu-sponsors?
[21:29] <infinity> hallyn: Doesn't really matter if the bug gets closed.
[21:30] <infinity> hallyn: (And, on the flipside, if the bug is reopened, only sponsors are in a position to do anything about it, since the original patch submitter obviously doesn't have access to)
[21:30] <hallyn> well its ending in sru, so closing could still take awhile
[21:30] <hallyn> ok
[21:30] <hallyn> won't do that then, thx :)
[21:30] <infinity> hallyn: See second point.  If the SRU team finds the fix defficient, a sponsor may still need to be involved.
[21:30] <infinity> ;)
[21:31] <broder> i'd prefer if sponsors were unsubscribed if a bug isn't blocking on sponsor action
[21:31] <broder> i think the SRU team generally resubs sponsors when necessary
[21:32] <infinity> broder: I'm not sure if that theory holds up in practice, but *shrug*... That workflow also sounds sane, if it happens.
[21:32] <broder> leaving them subscribed clutters the queue, which generally causes the sponsorship process to take longer
[21:32] <hallyn> right, i was thinking of reducing the clutter;  but OTOH we don't want bugs to get lost...
[21:32] <broder> when i'm worried about that, i usually subscribe to the bug myself
[21:32] <hallyn> that's what i was just thinking
[21:33] <broder> it might not be ideal, but it is generally effective
[21:33] <hallyn> so i think that's what i'll do.  thanks guys
[21:33] <hallyn> i can always re-subscribe sponsors if it turns out i failed :)
[21:33] <hallyn> oh i was worried aobut nothing - i can't do it anyway :)
[21:33] <broder> i may be unusually allergic to cruft in the queue, though
[21:42] <tumbleweed> whenever I unsubscribe sponsors, I add a comment saying "if you need us, please re-subscribe us"
[21:42] <tumbleweed> (well, a little more fleshed out...)
[21:43] <infinity> "Thank you for using our sponsorship services.  We hope you were satisfied with our product today, and should you need us again, please don't hesitate to re-subscribe us"?
[21:44] <tumbleweed> heh
[21:47] <dupondje> pitti: kenvandine: Uploaded fixes for papyon: https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349
[22:40] <SpamapS> slangasek: FYI, silenced the lintian warnings about the copyright file for the next upload...
[22:41] <SpamapS> slangasek: speaking of that.. should the next thing be to merge experimental into precise, and start the libmysqlclient transition?
[22:42] <SpamapS> slangasek: or do we need a DD to start all the binNMU rebuilds in experimental first?
[22:52] <slangasek> SpamapS: well, binNMU rebuilds in experimental aren't going to happen on their own, you'd need to talk somebody into doing such a rebuild test; maybe it's more straightforward to do your own rebuild testing, and then discuss with the +1maint team how and when it's best to add that to precise?
[22:58] <hallyn> @pilot out
[23:17] <SpamapS> slangasek: sorry, I don't really grok the debian release process yet. I'll gladly do a full rebuild test on my own.. but then who is this +1maint team and how would I contact them?
[23:17] <slangasek> SpamapS: https://wiki.ubuntu.com/PlusOneMaintenanceTeam
[23:18] <SpamapS> AHHH that
[23:18] <slangasek> SpamapS: the reason binNMUs don't happen automatically for experimental is that packages don't transition from experimental to unstable without an upload
[23:18] <slangasek> which means everything would be binNMUed again once the lib hits unstable
[23:18] <SpamapS> slangasek: right so I'd need to do my own tests, file bugs for things that need changing, and then give people time to fix them in experimental before moving 5.5 to unstable?
[23:19] <slangasek> that's considered best practice, yes
[23:19] <SpamapS> sounds reasonable. I'll start a mass rebuild tonight...
[23:19] <slangasek> because mysql-5.1 is a separate source package, it's technically possible to transition mysql-5.5 to testing before all the revdeps are converted, so I don't think you need to coordinate with the Debian release team on this one
[23:20]  * SpamapS wonders if Lucas Nussbaum's tools are available for reporting on the results
[23:20] <slangasek> but for precise, coordination with +1maint is a good idea
[23:20] <slangasek> SpamapS: I guess you should ask lucas :)
[23:21] <SpamapS> Yeah I'll do that all next week. Just getting the list of what FTBFS will be useful.
[23:21] <slangasek> cjwatson: libdbd-sybase-perl and unixodbc-gui-qt both uploaded to unstable
[23:26] <cjwatson> slangasek: thanks, I'll sync those once LP notices them
[23:26] <cjwatson> SpamapS: I think we will have space for another transition in precise early next week, if that works for you
[23:36] <SpamapS> cjwatson: Yes, I'll try to get an intial test rebuild done on my box over the weekend so we can skip obviously broken stuff.
[23:37] <SpamapS> assuming the wind stops blowing at 40mph tomorrow I won't need my box as I'll be sailing down mammoth mountain.. ;)
[23:38] <SpamapS> ok no more working ,time to enjoy holidaying
[23:38]  * slangasek waves


[02:45] -queuebot:#ubuntu-release- New binary: rustc [s390x] (hirsute-proposed/universe) [1.47.0+dfsg1+llvm-1ubuntu1] (i386-whitelist)
[03:02] -queuebot:#ubuntu-release- New binary: rustc [amd64] (hirsute-proposed/universe) [1.47.0+dfsg1+llvm-1ubuntu1] (i386-whitelist)
[03:14] -queuebot:#ubuntu-release- New binary: rustc [ppc64el] (hirsute-proposed/universe) [1.47.0+dfsg1+llvm-1ubuntu1] (i386-whitelist)
[03:54] -queuebot:#ubuntu-release- New binary: rustc [i386] (hirsute-proposed/universe) [1.47.0+dfsg1+llvm-1ubuntu1] (i386-whitelist)
[05:18] -queuebot:#ubuntu-release- New binary: golang-github-containers-dnsname [s390x] (hirsute-proposed/universe) [1.1.1+ds1-4] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: capstone [s390x] (hirsute-proposed/universe) [4.0.2-2] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: golang-github-containers-dnsname [ppc64el] (hirsute-proposed/universe) [1.1.1+ds1-4] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: age [ppc64el] (hirsute-proposed/none) [1.0.0~beta5-1] (no packageset)
[05:23] -queuebot:#ubuntu-release- New binary: age [s390x] (hirsute-proposed/none) [1.0.0~beta5-1] (no packageset)
[05:23] -queuebot:#ubuntu-release- New binary: libnewuoa [ppc64el] (hirsute-proposed/none) [0.1.1-1] (no packageset)
[05:23] -queuebot:#ubuntu-release- New binary: capstone [ppc64el] (hirsute-proposed/universe) [4.0.2-2] (no packageset)
[05:23] -queuebot:#ubuntu-release- New binary: libnewuoa [s390x] (hirsute-proposed/none) [0.1.1-1] (no packageset)
[05:23] -queuebot:#ubuntu-release- New binary: capstone [armhf] (hirsute-proposed/universe) [4.0.2-2] (no packageset)
[05:24] -queuebot:#ubuntu-release- New binary: capstone [arm64] (hirsute-proposed/universe) [4.0.2-2] (no packageset)
[05:24] -queuebot:#ubuntu-release- New binary: libnetconf2 [s390x] (hirsute-proposed/none) [1.1.16-1] (no packageset)
[05:24] -queuebot:#ubuntu-release- New binary: golang-github-containers-dnsname [arm64] (hirsute-proposed/universe) [1.1.1+ds1-4] (no packageset)
[05:24] -queuebot:#ubuntu-release- New binary: libnetconf2 [ppc64el] (hirsute-proposed/universe) [1.1.16-1] (no packageset)
[05:26] -queuebot:#ubuntu-release- New binary: golang-github-containers-dnsname [armhf] (hirsute-proposed/universe) [1.1.1+ds1-4] (no packageset)
[05:26] -queuebot:#ubuntu-release- New binary: meep-openmpi [amd64] (hirsute-proposed/universe) [1.16.1-1] (no packageset)
[05:27] -queuebot:#ubuntu-release- New binary: meep-mpi-default [amd64] (hirsute-proposed/universe) [1.16.1-1] (no packageset)
[05:28] -queuebot:#ubuntu-release- New binary: libnewuoa [armhf] (hirsute-proposed/universe) [0.1.1-1] (no packageset)
[05:29] -queuebot:#ubuntu-release- New binary: age [armhf] (hirsute-proposed/universe) [1.0.0~beta5-1] (no packageset)
[05:29] -queuebot:#ubuntu-release- New binary: meep-openmpi [s390x] (hirsute-proposed/universe) [1.16.1-1] (no packageset)
[05:29] -queuebot:#ubuntu-release- New binary: meep-mpi-default [s390x] (hirsute-proposed/universe) [1.16.1-1] (no packageset)
[05:29] -queuebot:#ubuntu-release- New binary: libnewuoa [arm64] (hirsute-proposed/universe) [0.1.1-1] (no packageset)
[05:34] -queuebot:#ubuntu-release- New binary: age [arm64] (hirsute-proposed/universe) [1.0.0~beta5-1] (no packageset)
[05:34] -queuebot:#ubuntu-release- New binary: libnewuoa [riscv64] (hirsute-proposed/universe) [0.1.1-1] (no packageset)
[05:34] -queuebot:#ubuntu-release- New binary: libnetconf2 [arm64] (hirsute-proposed/universe) [1.1.16-1] (no packageset)
[05:34] -queuebot:#ubuntu-release- New binary: meep-mpi-default [ppc64el] (hirsute-proposed/universe) [1.16.1-1] (no packageset)
[05:36] -queuebot:#ubuntu-release- New binary: golang-github-containers-dnsname [riscv64] (hirsute-proposed/universe) [1.1.1+ds1-4] (no packageset)
[05:36] -queuebot:#ubuntu-release- New binary: meep-openmpi [ppc64el] (hirsute-proposed/universe) [1.16.1-1] (no packageset)
[05:36] -queuebot:#ubuntu-release- New binary: libnetconf2 [armhf] (hirsute-proposed/universe) [1.1.16-1] (no packageset)
[05:38] -queuebot:#ubuntu-release- New binary: libnetconf2 [riscv64] (hirsute-proposed/universe) [1.1.16-1] (no packageset)
[05:40] -queuebot:#ubuntu-release- New binary: age [riscv64] (hirsute-proposed/universe) [1.0.0~beta5-1] (no packageset)
[05:40] -queuebot:#ubuntu-release- New binary: capstone [riscv64] (hirsute-proposed/universe) [4.0.2-2] (no packageset)
[05:55] -queuebot:#ubuntu-release- New binary: meep-mpi-default [arm64] (hirsute-proposed/universe) [1.16.1-1] (no packageset)
[06:00] -queuebot:#ubuntu-release- New binary: meep-mpi-default [armhf] (hirsute-proposed/universe) [1.16.1-1] (no packageset)
[06:00] -queuebot:#ubuntu-release- New binary: meep-openmpi [arm64] (hirsute-proposed/universe) [1.16.1-1] (no packageset)
[06:02] -queuebot:#ubuntu-release- New binary: meep-openmpi [armhf] (hirsute-proposed/universe) [1.16.1-1] (no packageset)
[06:32] -queuebot:#ubuntu-release- New binary: meep-openmpi [riscv64] (hirsute-proposed/universe) [1.16.1-1] (no packageset)
[06:41] -queuebot:#ubuntu-release- New binary: meep-mpi-default [riscv64] (hirsute-proposed/universe) [1.16.1-1] (no packageset)
[07:24] -queuebot:#ubuntu-release- New: accepted capstone [arm64] (hirsute-proposed) [4.0.2-2]
[07:24] -queuebot:#ubuntu-release- New: accepted capstone [ppc64el] (hirsute-proposed) [4.0.2-2]
[07:24] -queuebot:#ubuntu-release- New: accepted capstone [s390x] (hirsute-proposed) [4.0.2-2]
[07:24] -queuebot:#ubuntu-release- New: accepted libnetconf2 [armhf] (hirsute-proposed) [1.1.16-1]
[07:24] -queuebot:#ubuntu-release- New: accepted libnetconf2 [riscv64] (hirsute-proposed) [1.1.16-1]
[07:24] -queuebot:#ubuntu-release- New: accepted libnewuoa [armhf] (hirsute-proposed) [0.1.1-1]
[07:24] -queuebot:#ubuntu-release- New: accepted libnewuoa [riscv64] (hirsute-proposed) [0.1.1-1]
[07:24] -queuebot:#ubuntu-release- New: accepted rustc [amd64] (hirsute-proposed) [1.47.0+dfsg1+llvm-1ubuntu1]
[07:24] -queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (hirsute-proposed) [1.47.0+dfsg1+llvm-1ubuntu1]
[07:24] -queuebot:#ubuntu-release- New: accepted capstone [armhf] (hirsute-proposed) [4.0.2-2]
[07:24] -queuebot:#ubuntu-release- New: accepted libnetconf2 [arm64] (hirsute-proposed) [1.1.16-1]
[07:24] -queuebot:#ubuntu-release- New: accepted libnetconf2 [s390x] (hirsute-proposed) [1.1.16-1]
[07:24] -queuebot:#ubuntu-release- New: accepted libnewuoa [s390x] (hirsute-proposed) [0.1.1-1]
[07:24] -queuebot:#ubuntu-release- New: accepted capstone [riscv64] (hirsute-proposed) [4.0.2-2]
[07:24] -queuebot:#ubuntu-release- New: accepted libnewuoa [ppc64el] (hirsute-proposed) [0.1.1-1]
[07:24] -queuebot:#ubuntu-release- New: accepted libnetconf2 [ppc64el] (hirsute-proposed) [1.1.16-1]
[07:24] -queuebot:#ubuntu-release- New: accepted rustc [i386] (hirsute-proposed) [1.47.0+dfsg1+llvm-1ubuntu1]
[07:24] -queuebot:#ubuntu-release- New: accepted golang-github-containers-dnsname [arm64] (hirsute-proposed) [1.1.1+ds1-4]
[07:24] -queuebot:#ubuntu-release- New: accepted golang-github-containers-dnsname [ppc64el] (hirsute-proposed) [1.1.1+ds1-4]
[07:24] -queuebot:#ubuntu-release- New: accepted golang-github-containers-dnsname [s390x] (hirsute-proposed) [1.1.1+ds1-4]
[07:24] -queuebot:#ubuntu-release- New: accepted rustc [s390x] (hirsute-proposed) [1.47.0+dfsg1+llvm-1ubuntu1]
[07:24] -queuebot:#ubuntu-release- New: accepted golang-github-containers-dnsname [armhf] (hirsute-proposed) [1.1.1+ds1-4]
[07:24] -queuebot:#ubuntu-release- New: accepted libnewuoa [arm64] (hirsute-proposed) [0.1.1-1]
[07:24] -queuebot:#ubuntu-release- New: accepted golang-github-containers-dnsname [riscv64] (hirsute-proposed) [1.1.1+ds1-4]
[07:59] -queuebot:#ubuntu-release- New binary: netopeer2 [ppc64el] (hirsute-proposed/universe) [1.1.39-1] (no packageset)
[07:59] -queuebot:#ubuntu-release- New binary: netopeer2 [s390x] (hirsute-proposed/universe) [1.1.39-1] (no packageset)
[08:06] -queuebot:#ubuntu-release- New binary: netopeer2 [arm64] (hirsute-proposed/universe) [1.1.39-1] (no packageset)
[08:07] -queuebot:#ubuntu-release- New binary: netopeer2 [armhf] (hirsute-proposed/universe) [1.1.39-1] (no packageset)
[08:15] -queuebot:#ubuntu-release- New binary: netopeer2 [riscv64] (hirsute-proposed/universe) [1.1.39-1] (no packageset)
[08:20] <cpaelzer> Laney: there are tests triggered by an upload in the autopkgtest queue 'pgl-ddl-deploy {"submit-time": "2020-12-08 07:55:06", "triggers": ["pgl-ddl-deploy/2.0.0-1ubuntu1"]}'
[08:20] <cpaelzer> Laney: I know they will fail and already inserted the correct trigger (combined with pglogical)
[08:21] <cpaelzer> Laney: my request would be (given the current queue lengths) if you could cancel the "known-to-fail" runs for me?
[08:22] <cpaelzer> juliank: was so kind to add &delete=1, but with that I can only remove my own triggers :-/
[08:22] <cpaelzer> Laney: and to complete the morning pings - nobody beat you on bug 1907110 , so once you are around I'd appreciate if you could also look for that
[08:32] <juliank> cpaelzer: Hello!
[08:32] <cpaelzer> o/
[08:34] <juliank> cpaelzer: So only that specific test run?
[08:35] <juliank> for all archis, I suppose?
[08:36] <juliank> cpaelzer: OK, I checked all archs, and you triggered them all with new triggers so I deleted the automatic ones
[08:37] <juliank> Are we doing python3.9-only now or what happened yesterday?
[08:37] <juliank> * since yesterday
[08:38] <cpaelzer> juliank: perfect - thank you
[08:38] <juliank> I should add an IRC highlight on La ney
[08:45] <cpaelzer> xnox: FYI - about two weeks ago you fixed an FTFBS on open-isns, that never migrated as  that version had a bug that makes it uninstallable
[08:46] <cpaelzer> xnox: This blocks a few others (that is how I found it) - I already confirmed that the fix that appeared in Debian yesterday fixes our issue and will upload a merge after some testing
[08:46] <cpaelzer> xnox: your FTFBS fix is still needed in Ubuntu (due to glibc 2.32 being ahead of Debian)
[09:39] <Laney> cpaelzer: ok, will do
[09:47] -queuebot:#ubuntu-release- New binary: golang-github-nbio-st [amd64] (hirsute-proposed/universe) [0.0~git20140626.e9e8d98-1] (no packageset)
[09:47] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (hirsute-proposed/main) [5.8.0-1012.12+21.04.1] (core, kernel)
[09:48] -queuebot:#ubuntu-release- New binary: age [amd64] (hirsute-proposed/universe) [1.0.0~beta5-1] (no packageset)
[09:48] -queuebot:#ubuntu-release- New binary: scala-mode-el [amd64] (hirsute-proposed/universe) [1:1.1.0-1] (no packageset)
[09:50] -queuebot:#ubuntu-release- New: accepted age [amd64] (hirsute-proposed) [1.0.0~beta5-1]
[09:50] -queuebot:#ubuntu-release- New: accepted age [armhf] (hirsute-proposed) [1.0.0~beta5-1]
[09:50] -queuebot:#ubuntu-release- New: accepted age [riscv64] (hirsute-proposed) [1.0.0~beta5-1]
[09:50] -queuebot:#ubuntu-release- New: accepted golang-github-nbio-st [amd64] (hirsute-proposed) [0.0~git20140626.e9e8d98-1]
[09:50] -queuebot:#ubuntu-release- New: accepted age [arm64] (hirsute-proposed) [1.0.0~beta5-1]
[09:50] -queuebot:#ubuntu-release- New: accepted age [s390x] (hirsute-proposed) [1.0.0~beta5-1]
[09:50] -queuebot:#ubuntu-release- New: accepted age [ppc64el] (hirsute-proposed) [1.0.0~beta5-1]
[09:50] -queuebot:#ubuntu-release- New: accepted scala-mode-el [amd64] (hirsute-proposed) [1:1.1.0-1]
[09:51] -queuebot:#ubuntu-release- New binary: golang-gopkg-libgit2-git2go.v30 [amd64] (hirsute-proposed/universe) [30.3.2-1] (no packageset)
[09:51] -queuebot:#ubuntu-release- New binary: libnetconf2 [amd64] (hirsute-proposed/universe) [1.1.16-1] (no packageset)
[09:51] -queuebot:#ubuntu-release- New: accepted golang-gopkg-libgit2-git2go.v30 [amd64] (hirsute-proposed) [30.3.2-1]
[09:51] -queuebot:#ubuntu-release- New: accepted libnetconf2 [amd64] (hirsute-proposed) [1.1.16-1]
[10:13] <Laney> cpaelzer: I didn't understand what you were asking for about pgsphere - is it old binaries that the NBS report isn't picking up?
[10:24] <cpaelzer> Laney: no up to yesterday there were binaries in the NBS report
[10:24] <cpaelzer> rechecking the current state
[10:25] <cpaelzer> Laney: this binary is bad, old and needs to go
[10:25] <cpaelzer>  postgresql-pgsphere | 1.1.1+2018.10.13-2       | hirsute/universe | amd64, arm64, armhf, ppc64el, riscv64, s390x
[10:25] <cpaelzer> This is the new one (which also has a provides postgresql-pgsphere)
[10:25] <cpaelzer>  postgresql-13-pgsphere | 1.1.1+2020-10-20-1 | hirsute/universe | amd64, arm64, armhf, ppc64el, riscv64, s390x
[10:26] <cpaelzer> the case for postgresql-q3c is the same
[10:27] <cpaelzer> The others are "normal" NBS and listed in the current report https://people.canonical.com/~ubuntu-archive/nbs.html, those are postgresql-12-pgrouting postgresql-12-pgrouting-doc postgresql-12-pgrouting-scripts postgresql-12-postgis-3 postgresql-12-postgis-3-scripts
[10:27] <cpaelzer> I listed those in the bug as well
[10:27] <cpaelzer> Laney: does that explain what was formerly unclear?
[10:29] <xnox> cpaelzer:  ok.
[10:36] <Laney> cpaelzer: I did the ones the nbs report showed, but that wasn't one of them, so I guess it needs to be done manually
[10:38] <cpaelzer> yes the cases on q3c and pgsphere need to be done manually I guess
[10:38] <Laney> done for sphere
[10:38] <cpaelzer> due to the move package -> provides they are missed in the report
[10:38] <cpaelzer> thanks
[10:38] <Laney> q3c... looking... where's that one
[10:40] <Laney> done
[10:40] <cpaelzer> new
[10:40] <cpaelzer>  postgresql-13-q3c | 2.0.0-4 | hirsute/universe | amd64, arm64, armhf, ppc64el, riscv64, s390x
[10:40] <cpaelzer> ah ok, you already found it then
[10:40] <cpaelzer> thank you Laney
[10:40] <Laney> ok hopefully that is it
[10:40] <Laney> 👍
[10:40] <cpaelzer> I have a few more to resolve, one step at a time ... :-)
[11:04] -queuebot:#ubuntu-release- New binary: netopeer2 [amd64] (hirsute-proposed/universe) [1.1.39-1] (no packageset)
[11:19] -queuebot:#ubuntu-release- New binary: simdjson [s390x] (hirsute-proposed/universe) [0.7.0-1] (no packageset)
[11:20] -queuebot:#ubuntu-release- New binary: simdjson [ppc64el] (hirsute-proposed/universe) [0.7.0-1] (no packageset)
[11:20] <rbalint> RAOF, bdmurray could you please check the glibc SRU for Bionic? it takes quite some time to get all tests run and if it could be accepted today it may make it to the release pocket this year
[11:21] -queuebot:#ubuntu-release- New binary: simdjson [amd64] (hirsute-proposed/universe) [0.7.0-1] (no packageset)
[11:29] -queuebot:#ubuntu-release- New binary: simdjson [arm64] (hirsute-proposed/universe) [0.7.0-1] (no packageset)
[11:29] -queuebot:#ubuntu-release- New binary: simdjson [riscv64] (hirsute-proposed/universe) [0.7.0-1] (no packageset)
[11:29] -queuebot:#ubuntu-release- New binary: simdjson [armhf] (hirsute-proposed/universe) [0.7.0-1] (no packageset)
[11:30] -queuebot:#ubuntu-release- New: accepted simdjson [arm64] (hirsute-proposed) [0.7.0-1]
[11:30] -queuebot:#ubuntu-release- New: accepted simdjson [armhf] (hirsute-proposed) [0.7.0-1]
[11:31] -queuebot:#ubuntu-release- New: accepted meep-mpi-default [arm64] (hirsute-proposed) [1.16.1-1]
[11:31] -queuebot:#ubuntu-release- New: accepted meep-mpi-default [ppc64el] (hirsute-proposed) [1.16.1-1]
[11:31] -queuebot:#ubuntu-release- New: accepted meep-mpi-default [s390x] (hirsute-proposed) [1.16.1-1]
[11:31] -queuebot:#ubuntu-release- New: accepted meep-openmpi [armhf] (hirsute-proposed) [1.16.1-1]
[11:31] -queuebot:#ubuntu-release- New: accepted meep-openmpi [riscv64] (hirsute-proposed) [1.16.1-1]
[11:31] -queuebot:#ubuntu-release- New: accepted netopeer2 [amd64] (hirsute-proposed) [1.1.39-1]
[11:31] -queuebot:#ubuntu-release- New: accepted netopeer2 [armhf] (hirsute-proposed) [1.1.39-1]
[11:31] -queuebot:#ubuntu-release- New: accepted netopeer2 [riscv64] (hirsute-proposed) [1.1.39-1]
[11:31] -queuebot:#ubuntu-release- New: accepted simdjson [amd64] (hirsute-proposed) [0.7.0-1]
[11:31] -queuebot:#ubuntu-release- New: accepted simdjson [riscv64] (hirsute-proposed) [0.7.0-1]
[11:31] -queuebot:#ubuntu-release- New: accepted meep-mpi-default [armhf] (hirsute-proposed) [1.16.1-1]
[11:31] -queuebot:#ubuntu-release- New: accepted meep-openmpi [arm64] (hirsute-proposed) [1.16.1-1]
[11:31] -queuebot:#ubuntu-release- New: accepted meep-openmpi [s390x] (hirsute-proposed) [1.16.1-1]
[11:31] -queuebot:#ubuntu-release- New: accepted netopeer2 [ppc64el] (hirsute-proposed) [1.1.39-1]
[11:31] -queuebot:#ubuntu-release- New: accepted simdjson [ppc64el] (hirsute-proposed) [0.7.0-1]
[11:31] -queuebot:#ubuntu-release- New: accepted meep-mpi-default [riscv64] (hirsute-proposed) [1.16.1-1]
[11:31] -queuebot:#ubuntu-release- New: accepted netopeer2 [arm64] (hirsute-proposed) [1.1.39-1]
[11:31] -queuebot:#ubuntu-release- New: accepted simdjson [s390x] (hirsute-proposed) [0.7.0-1]
[11:31] -queuebot:#ubuntu-release- New: accepted meep-openmpi [ppc64el] (hirsute-proposed) [1.16.1-1]
[11:31] -queuebot:#ubuntu-release- New: accepted netopeer2 [s390x] (hirsute-proposed) [1.1.39-1]
[11:31] -queuebot:#ubuntu-release- New: accepted meep-mpi-default [amd64] (hirsute-proposed) [1.16.1-1]
[11:31] -queuebot:#ubuntu-release- New: accepted meep-openmpi [amd64] (hirsute-proposed) [1.16.1-1]
[11:51] <LocutusOfBorg> vorlon, https://launchpad.net/ubuntu/+source/gdk-pixbuf-xlib/2.40.2-2 on i386 too please?
[11:52] <LocutusOfBorg> otherwise we can't really gdk-pixbuf on i386 e.g. https://launchpad.net/ubuntu/+source/gst-plugins-bad1.0/1.18.2-1ubuntu1/+build/20379041
[12:10] <Laney> https://ubuntu-release.kpi.ubuntu.com/ a new thing is born
[12:11] <Laney> it's possible to write scrapers for new data sources, will mail some list about this soon
[12:11] <Laney> e.g. we should have one for autopkgtest queues
[12:11] <doko> what are release bugs?
[12:12] <Laney> rls-incoming or rls-tracking
[12:20] <Laney> LocutusOfBorg: I did that one
[12:20] <LocutusOfBorg> ta
[12:20] <Laney> https://launchpad.net/ubuntu/+source/gdk-pixbuf-xlib/2.40.2-2/+build/20380598
[12:20] <Laney> less good
[12:21] <LocutusOfBorg> Laney, no problem, I can fix it
[12:31] <LocutusOfBorg> bileto mostly ready to land :)
[12:43] -queuebot:#ubuntu-release- Packageset: Removed autoconf2.64 from i386-whitelist in hirsute
[12:43] -queuebot:#ubuntu-release- Packageset: Removed cifs-utils from i386-whitelist in hirsute
[12:43] -queuebot:#ubuntu-release- Packageset: Removed ding-libs from i386-whitelist in hirsute
[12:43] -queuebot:#ubuntu-release- Packageset: Removed libnfsidmap from i386-whitelist in hirsute
[12:43] -queuebot:#ubuntu-release- Packageset: Removed llvm-toolchain-10 from i386-whitelist in hirsute
[12:43] -queuebot:#ubuntu-release- Packageset: Removed postgresql-12 from i386-whitelist in hirsute
[12:43] -queuebot:#ubuntu-release- Packageset: Removed pycryptodome from i386-whitelist in hirsute
[12:43] -queuebot:#ubuntu-release- Packageset: Removed python-crypto from i386-whitelist in hirsute
[12:43] -queuebot:#ubuntu-release- Packageset: Removed sssd from i386-whitelist in hirsute
[12:43] -queuebot:#ubuntu-release- Packageset: Removed uid-wrapper from i386-whitelist in hirsute
[12:43] -queuebot:#ubuntu-release- Packageset: Added gdk-pixbuf-xlib to i386-whitelist in hirsute
[12:43] -queuebot:#ubuntu-release- Packageset: Added libpod-parser-perl to i386-whitelist in hirsute
[12:43] -queuebot:#ubuntu-release- Packageset: Added mailcap to i386-whitelist in hirsute
[12:43] -queuebot:#ubuntu-release- Packageset: Added media-types to i386-whitelist in hirsute
[12:43] -queuebot:#ubuntu-release- Packageset: Added nvidia-graphics-drivers-460 to i386-whitelist in hirsute
[13:00] <doko> I'm re-adding autoconf2.64, I still want to build gcc-9 on i386
[13:01] <doko> is there anything that can prevent that removal?
[13:02] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (groovy-proposed/partner) [1:20201110.1-0ubuntu<IP_ADDRESS> => 1:20201208.1-0ubuntu<IP_ADDRESS>] (no packageset)
[13:05] <doko> ahh, wait that was gcc-8, which isn't bult anymore on i386
[13:35] <cpaelzer> Laney: juliank: one more question on autopkgtests queues, my recent upload of open-isns seems to have inserted the test into the queue twice
[13:36] <cpaelzer> Like: open-iscsi {"triggers": ["open-isns/0.100-3ubuntu1"], "submit-time": "2020-12-08 12:23:34"}
[13:36] <cpaelzer> None are triggered by a person - neither me nor anyone else
[13:36] <cpaelzer> but they are listed twice on every architecture
[13:36] <cpaelzer> On one hand we could remove just one of the two duplicates
[13:37] <cpaelzer> but on the other I wonder if there might be mure dups
[14:32] <Laney> cpaelzer: I don't see it, did it go through already?
[14:32] <Laney> anyway you can probably find those requests in the logs
[14:32] <Laney> Requesting ... on ... to verify ...
[14:32] <Laney> if you want to look a bit
[14:33] <cpaelzer> Laney: you ask for open-isns duplicates I guess, in no way did they already complete
[14:33] <cpaelzer> rechecking ...
[14:34] <cpaelzer> Duplicates are still on https://autopkgtest.ubuntu.com/running
[14:34] <Laney> what should I look for?
[14:34] <cpaelzer> just search for "open-isns" there
[14:34] <cpaelzer> oh
[14:34]  * cpaelzer removes blinders
[14:35] <cpaelzer> the leading is open-isns vs open-iscsi
[14:35] <Laney> 🙈
[14:35]  * cpaelzer forbids too similar package names to trigger together ...
[14:35] <cpaelzer> sorry for the noise Laney
[14:35] <Laney> heh, np
[14:35] <Laney> they are similar now you mention it
[14:58] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (hirsute-proposed) [5.8.0-1012.12+21.04.1]
[15:25] <Laney> https://ubuntu-release.kpi.ubuntu.com/d/yIC34LpGk/testing?viewPanel=4&orgId=1
[15:25] <Laney> might be useful for people
[15:43] -queuebot:#ubuntu-release- Packageset: Added gcc-11 to i386-whitelist in hirsute
[15:45] <coreycb> bdmurray: for ceph 15.2.7 in groovy-proposed and focal-proposed, I've tagged that as verification-done. do you think we can get that out earlier than the typical 7 days considering it's critical?
[16:12] -queuebot:#ubuntu-release- Unapproved: gnome-flashback (focal-proposed/universe) [3.36.4-0ubuntu1.1 => 3.36.5-0ubuntu1] (edubuntu)
[16:14] <bdmurray> coreycb: It looks like the point release only contains the bug fix. Is that correct?
[16:19] <coreycb> bdmurray: yes the bug fix and a CVE Fix so it's a fairly small delta for a point release
[16:20] <bdmurray> coreycb: It seems reasonable to me, why is it not in hirsute yet though?
[16:23] <bdmurray> Oh it is the task is just wrong
[16:26] <coreycb> bdmurray: I just moved hirsute to fix released. I failed to put the bug reference in the changelog for hirsute.
[16:27] <coreycb> bdmurray: thanks
[16:30] <rbalint> RAOF, bdmurray could you please check the glibc SRU for Bionic? it takes quite some time to get all tests run and if it could be accepted today it may make it to the release pocket this year
[16:33] <bdmurray> rbalint: its on my list
[16:37] <rbalint> bdmurray, thanks!
[16:45] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (groovy-proposed) [1:20201208.1-0ubuntu<IP_ADDRESS>]
[16:47] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20201110.1-0ubuntu<IP_ADDRESS> => 1:20201208.1-0ubuntu<IP_ADDRESS>] (no packageset)
[16:47] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20201110.1-0ubuntu<IP_ADDRESS> => 1:20201208.1-0ubuntu<IP_ADDRESS>] (no packageset)
[16:47] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (focal-proposed/partner) [1:20201110.1-0ubuntu<IP_ADDRESS> => 1:20201208.1-0ubuntu<IP_ADDRESS>] (no packageset)
[17:50] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (hirsute-proposed/main) [5.8.0-1014.15+21.04.1] (core, kernel)
[18:40] <vorlon> LocutusOfBorg: looks like you got gdk-pixbuf-xlib/i386 sorted already?
[19:03] -queuebot:#ubuntu-release- Unapproved: accepted glibc [source] (bionic-proposed) [2.27-3ubuntu1.4]
[19:06] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20201208.1-0ubuntu<IP_ADDRESS>]
[19:06] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20201208.1-0ubuntu<IP_ADDRESS>]
[19:06] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (focal-proposed) [1:20201208.1-0ubuntu<IP_ADDRESS>]
[19:13] -queuebot:#ubuntu-release- Unapproved: accepted gnome-system-monitor [source] (focal-proposed) [3.36.1-0ubuntu<IP_ADDRESS>]
[19:17] -queuebot:#ubuntu-release- Unapproved: accepted gnome-flashback [source] (focal-proposed) [3.36.5-0ubuntu1]
[20:23] <LocutusOfBorg> sure vorlon thanks
[21:56] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (hirsute-proposed) [5.8.0-1014.15+21.04.1]
[23:25] -queuebot:#ubuntu-release- New binary: libosmocore [amd64] (hirsute-proposed/universe) [1.4.1-3] (no packageset)
[23:25] -queuebot:#ubuntu-release- Unapproved: fwupd (hirsute-proposed/main) [1.5.3-2 => 1.5.3-2] (core)
[23:27] -queuebot:#ubuntu-release- New binary: bpfcc [ppc64el] (hirsute-proposed/universe) [0.17.0-8] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: bpfcc [amd64] (hirsute-proposed/universe) [0.17.0-8] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: libosmocore [ppc64el] (hirsute-proposed/universe) [1.4.1-3] (no packageset)
[23:29] -queuebot:#ubuntu-release- Unapproved: fwupd (hirsute-proposed/main) [1.5.3-2 => 1.5.3-2] (core)
[23:37] -queuebot:#ubuntu-release- New binary: volk [ppc64el] (hirsute-proposed/universe) [2.4.0-3] (no packageset)
[23:37] -queuebot:#ubuntu-release- New binary: libosmocore [s390x] (hirsute-proposed/universe) [1.4.1-3] (no packageset)
[23:40] -queuebot:#ubuntu-release- Unapproved: fwupd (hirsute-proposed/main) [1.5.3-2 => 1.5.3-2] (core)
[23:40] -queuebot:#ubuntu-release- New binary: volk [amd64] (hirsute-proposed/universe) [2.4.0-3] (no packageset)
[23:44] -queuebot:#ubuntu-release- New binary: volk [riscv64] (hirsute-proposed/universe) [2.4.0-3] (no packageset)
[23:45] -queuebot:#ubuntu-release- New binary: volk [s390x] (hirsute-proposed/universe) [2.4.0-3] (no packageset)
[23:45] -queuebot:#ubuntu-release- New binary: bpfcc [arm64] (hirsute-proposed/universe) [0.17.0-8] (no packageset)
[23:48] -queuebot:#ubuntu-release- New binary: libosmocore [arm64] (hirsute-proposed/universe) [1.4.1-3] (no packageset)
[23:48] -queuebot:#ubuntu-release- New binary: libosmocore [armhf] (hirsute-proposed/universe) [1.4.1-3] (no packageset)
[23:51] -queuebot:#ubuntu-release- New binary: libosmocore [riscv64] (hirsute-proposed/universe) [1.4.1-3] (no packageset)
[23:55] -queuebot:#ubuntu-release- New binary: bornagain [amd64] (hirsute-proposed/universe) [1.18.0-1] (no packageset)


[07:00] <dkessel> takling about xscreensaver: i hope someday someone in debian will accept the original author's opinion about the old version in debian (and ubuntu) and no longer ship that version... see https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/
[07:03] <Unit193> dkessel: Did you read the bug report?  And so far, xsc in unstable was patched to disable that.
[07:03] <dkessel> i just read jwz's opinion about it, tbh
[07:05] <Unit193> Need to read both sides on this.
[08:52] <pavlushka> Hi, everyone!
[08:52] <pavlushka> lubuntu live session locks out in trusty 14.04.4
[08:54] <pavlushka> cant explore.
[09:12] <pavlushka> when not even afk.
[19:01] <phillw> wxl: you busy?
[19:02] <wxl> phillw: just at work as usual. what's up?
[19:04] <phillw> just need a quick check my an admin of a new wiki page.... only a fer sentences, so hopefully only a 2 minute job :D
[19:04] <phillw> s/fer/few/
[19:04] <wxl> phillw: sure sure
[19:05] <phillw> wxl: https://wiki.ubuntu.com/Lubuntu/ContactUs/ModsOnFacebook
[19:05] <phillw> We have some new spam spotters and they asked for some instructions.
[19:06] <phillw> the wolf allocated me to write them :P
[19:06] <wxl> should be like "Dealing with spammers" I guess
[19:07] <wxl> also
[19:07] <wxl> have on add session
[19:07] <wxl> s/on/an/
[19:07] <phillw> No, it is also approving new members, thus trying to liit the spammers :)
[19:07] <wxl> and you have hours hours
[19:07] <wxl> there's two sections:
[19:07] <wxl> Spammers
[19:07] <phillw> wxl: go edit it :P
[19:07] <wxl> aww jeez now i have to login
[19:09] <phillw> I was writing as I was thinking ...  But is a faster way than it go around email group for 2 weeks while some committee, some where, decides to agree :P
[19:09] <phillw> 2 new Mods, they asked for guidelines :)
[19:17] <wxl> phillw: done. fix your links #2 :)
[19:17] <phillw> wxl: it is a search on lubuntu-official, it is a chat - unless you know how to link it?
[19:18] <wxl> oh
[19:18] <wxl> um
[19:18] <wxl> maybe
[19:18] <wxl> now you're going to make me log into facebook too XD
[19:19] <phillw> wxl: you wanted the title!!!  Oh, did you get the mail for bank account, or was it shreaded this time?
[19:22] <phillw> wxl: also, with having been hunting down other bugs... Can you ask the boss where this one is up to? https://bugs.launchpad.net/ubuntu/+source/lubuntu-artwork/+bug/1551446
[19:22] <wxl> no i did
[19:22] <wxl> just need to reply to it
[19:22] <wxl> i guess i give up on the chat thing :)
[19:23] <wxl> there's a way to start a group chat but there's none available it seems
[19:23] <phillw> wxl: yeah, I know it is a pile of sh1t to sort out... but, we'd like it doing so that I can go nag the boss :D
[19:24] <phillw> wxl: group chat?
[19:24] <wxl> i assume that's what you mean
[19:24] <wxl> i don't know
[19:24] <wxl> you'll figure it out XD
[19:24] <wxl> regarding the black wallpaper i'll investigate a bit more
[19:25] <phillw> wxl: well, one is black wallpaper, the other is for donations to lubuntu.... not too sure where group chat came in.
[19:25] <wxl> phillw: facebook.
[19:27] <phillw> wxl: how many channels do we have on Fb? .... I track 5
[19:27] <wxl> phillw: do you mean chats?
[19:27] <phillw> no, channels and groups / pages
[19:27] <wxl> 3 groups
[19:27] <wxl> 1 page that i know of
[19:28] <wxl> bbl
[19:29] <phillw> okies.... I need to put 2nd part of evening meal in :)
[20:10] <phillw> wxl: now fed.... are you happy with page?
[20:21] <tsimonq2> wxl: I think I found a browser for Lubuntu/LXQt :P https://www.indiegogo.com/projects/qutebrowser-a-keyboard-focused-vim-like-browser#/
[20:21] <tsimonq2> your dream browser, "vim-like"
[20:21] <tsimonq2> and it's Qt
[20:21] <tsimonq2> hope it's FLOSS
[20:22] <tsimonq2> I see!
[20:22] <tsimonq2> this is WAY better than Qupzilla, I'll try it for the next week or two and report back
[20:24] <tsimonq2> wxl: there isn't a Debian package yet, but hopefully soon
[20:25] <ianorlyn> tsimonq2, but I like qupzilla
[20:26] <tsimonq2> ianorlyn: are you serious? simple simple functions don't work
[20:27] <ianorlyn> tsimonq2, like what?
[20:27] <tsimonq2> typing in the omnibox doesn't automatically search Google
[20:27] <ianorlyn> oh I don't like omnibox anyway
[20:27] <tsimonq2> OH
[20:27] <tsimonq2> what?
[20:27] <tsimonq2> *sigh*
[20:28] <tsimonq2> I just...don't like it
[20:46] <wxl> phillw: i think it's good now though i'm not sure i understand the ignore section.
[20:46] <wxl> tsimonq2: put it on the blueprint
[20:47] <tsimonq2> wxl: awesome k
[20:49] <phillw> wxl: we do not see any use of accepting people with 100 - 300+ other group "memberships". could you manage to be a contsructive member of a channel? Our opinion is that not in any way - there are not enough hours in the day. therefore we mark them as ignore.... We are not a flag collecting society as to who can join the most groups... Is it more clear now?
[20:51] <wxl> phillw: yep
[20:52] <phillw> tsimonq2: I have asked on #debian about the iso hosting, but have no answer. So, I will leave it with you to ask your contact to get in touch via the iso hosting area at http://phillw.net/isos.html Vm's are NOT set up to replicate the iso hosting area.
[20:52] <phillw> wxl: wiki page okay to release?
[20:53] <wxl> phillw: last edit got us there, yep
[20:54] <phillw> wxl: On occasions that you receive notification of the spam from a member, make sure to thank them publicly.
[20:54] <wxl> yup
[20:54] <phillw> you cannot, such reports are anonymous....
[20:55] <wxl> uh
[20:55] <phillw> hence the little topic
[20:55] <wxl> then remove publicly
[20:55] <phillw> which, goes back to the initial thing of having the topic :P
[20:55] <phillw> which has been there a long time!!!
[20:56] <tsimonq2> phillw: read my PM please
[20:56] <phillw> wxl: 25 November 2015
[20:57] <wxl> phillw: i don't really know what you're talking about with regards to the topic. feel free to edit, though :)
[21:01] <phillw> wxl: something like this ... http://pastebin.com/00gp03tX
[21:01] <wxl> phillw: tl;dr go edit :)
[21:02] <phillw> it thanks peope, and warns others :D


[01:02] <endo> so, there is some weird stuff with MAAS on 2.0
[01:03] <endo> the database got messed up, and the region controller wouldn't start
[01:04] <endo> it was detecting more than one database, and even after I tried to fix that, it wouldn't provide the /api/2.0 url, even after trying to remove and purge everything and the database.
[04:20] <mup> Bug #1567663 changed: Commision Failed because of IPMI power control problems <MAAS:Expired> <https://launchpad.net/bugs/1567663>
[04:43] <setuid> Does anyone know which repo/ppa contains maas-rack-controller? It's not in the standard nor maas/stable repos.
[04:43] <setuid> I'm following these instructions: https://maas.ubuntu.com/docs/rack-configuration.html
[04:44] <setuid> I'm finding that a good 90% of the docs out there are incorrect/broken/out of date by a version or two
[04:45] <setuid> That page, was linked from here: https://maas.ubuntu.com/docs/install.html