[00:52] <bigjools> roaksoax: I approved your packaging change
[00:53] <bigjools> can I land it as-is?
[01:10] <roaksoax> bigjools: cool thanks
[01:10] <bigjools> roaksoax: actually
[01:10] <bigjools> roaksoax: wait
[01:11] <bigjools> I have got so many branches I am getting them mixed up
[01:11] <roaksoax> bigjools: so I created a packaging.precise.sru which is what was in quantal at the time, plus your merges
[01:11] <roaksoax> bigjools: or your change to the upstart job
[01:11] <roaksoax> bigjools: i'll get that updated :)
[01:11] <bigjools> we have not backported the celery import-pxe-files
[01:12] <roaksoax> bigjools: ok, no harm since it was only a 1 line addition
[01:12] <roaksoax> to the sudoers file for maas
[01:12] <bigjools> roaksoax: no I mean your https://code.launchpad.net/~andreserl/maas/quantal_packaging_updates/+merge/135264
[01:12] <bigjools> it was more than that, 167 lines of diff :)
[01:12] <roaksoax> bigjools: the change for that is: debian/extras/99-maas-sudoers
[01:13] <roaksoax> bigjools: the rest, is for maas-cluster-controller shipping maas-import-pxe-files and storing the images
[01:14] <bigjools> roaksoax: none of it is needed
[01:14] <bigjools> I think
[01:15] <bigjools> grar, let me check again
[01:15] <roaksoax> bigjools: hold on, isn't bug #1068843 the one one which the cluster controller has to have the images?
[01:16] <roaksoax> bigjools: so that bug,which i see was backported to the stabilkization branch is where the images are no longer on the region controller and are on the cluster controller
[01:16] <bigjools> roaksoax: right right
[01:16] <bigjools> I am getting two changes mixed up
[01:16] <roaksoax> bigjools: the thing for celery to work, was simply adding permission for the maas user to run maas-import-pxe-files
[01:16] <roaksoax> bigjools: which is a 1 line change
[01:17] <bigjools> roaksoax: yup :)
[01:18] <roaksoax> bigjools: ok, so now
[01:18] <roaksoax> bigjools: i have updated it
[01:18] <roaksoax> :)
[01:18] <roaksoax> bigjools: now, I had to rebase the python-django package because a securoity fix landed in archives
[01:18] <roaksoax> bigjools: and your changes needed to be applied on top of that package
[01:19] <roaksoax> bigjools: now, It would be great if you could open a bug report for each of those patches
[01:19] <bigjools> roaksoax: you already did it? I was about to do it
[01:19] <bigjools> :)
[01:19] <roaksoax> so i can reference the changelog and SRU the package
[01:19] <bigjools> I will file
[01:20] <bigjools> where is your precise packaging branch?  I made a bunch of changes just in the PPA
[01:20] <bigjools> (for maas)
[01:20] <roaksoax> bigjools: awesome, assign them to me and I'll take care of the rest
[01:20] <bigjools> coolio
[01:21] <roaksoax> bigjools: lp:~maas-maintainers/maas/packaging.precise.sru
[01:22] <roaksoax> bigjools: this is the only change i made of top for the packaging: http://bazaar.launchpad.net/~maas-maintainers/maas/packaging.precise.sru/revision/146
[01:22] <roaksoax> in comparison to the quantal one
[01:23] <roaksoax> bigjools: in terms on packaging I didn't see any other change
[01:24] <bigjools> roaksoax: ok I have a *bunch* of changes, it might be best if I just blow your branch away and replace it with mine
[01:24]  * bigjools diffs
[01:24] <roaksoax> bigjools: sure, branch the quantal with the recent changes you just approved and put them on top
[01:24] <roaksoax> bigjools: that way I can make sure what differs from quantal
[01:25] <bigjools> I branched the old precise packaging and changed on top of that
[01:25] <bigjools> since that is the branch that we really want to use, right?
[01:25] <roaksoax> bigjools: uhmmm nope
[01:25] <bigjools> whut?
[01:26] <roaksoax> bigjools:  the quantal branch updates precise -> quantal right?
[01:26] <roaksoax> bigjools: the quantal version is going to be the same as precise
[01:26] <bigjools> the code is the same, the packaging is a fair bit different now
[01:26] <roaksoax> bigjools: it shouldn't be
[01:26] <bigjools> but I see why you're approaching it this way
[01:27] <bigjools> let me diff them, hang on
[01:28] <roaksoax> bigjools: note that when you backport, you use the same package as ubuntu+1, + any singularities that you need to do in that particula release
[01:28] <roaksoax> bigjools: in our case, we are SRU'ing a whole release
[01:28] <bigjools> ok
[01:28] <roaksoax> so the packaging should be the same + changes for precise
[01:28] <roaksoax> bigjools: cause the upgrade path is going to be the same
[01:29] <bigjools> well for reference, here's the diff from my your sru packaging to my sru packaging http://pastebin.ubuntu.com/1373861/
[01:30] <roaksoax> bigjools: yeah, too much complication :)
[01:30] <roaksoax> s/too much complication/too complicated/
[01:30] <bigjools> I have an equally big diff to the quantal branch
[01:30] <bigjools> let's see what I can do
[01:31] <roaksoax> bigjools: the one iuploaded in the PPA, only seemed to have the upstart changes as packaging changes
[01:32] <bigjools> I have changelog and upstart
[01:32] <roaksoax> bigjools: right, I merged your changelog entry for the upstart change
[01:32] <roaksoax> bigjools: and i added all the biuglist we are closing
[01:32] <roaksoax> bigjools: which you partially had
[01:32] <roaksoax> bigjools: there should not be any more changes AFAIK
[01:32] <bigjools> indeed
[01:33] <roaksoax> bigjools: ok so I will rebase packaging.precise.sru with latest fixes
[01:33] <bigjools> roaksoax: looks like your branch is up to date then
[01:35] <bigjools> excellenbt
[01:35] <bigjools> roaksoax: did you rebase the django package already?
[01:35] <roaksoax> bigjools: yes
[01:35] <bigjools> roaksoax: awesome
[01:36] <roaksoax> :)
[01:36] <roaksoax> bigjools: alright, I hope that tomorrow i can at least upload yui3, python-tx-tftp, and django
[01:36] <bigjools> \o/
[01:36] <bigjools> to quantal and precise?
[01:36] <roaksoax> yui3, django to precise
[01:37] <roaksoax> and python-tx-tftp to quantal, and once accepted to precise
[01:37] <bigjools> nice!
[01:37]  * bigjools files bugs
[01:42] <bigjools> roaksoax: 1st one https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/1081388
[01:43] <roaksoax> bigjools: could you also please explain what it does, or "fixes" maas problem
[01:47] <bigjools> roaksoax: any better?
[01:49] <bigjools> roaksoax: 2nd https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/1081391
[01:49] <bigjools> one more to go
[01:52] <bigjools> roaksoax: https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/1081392
[01:52] <bigjools> I can attach patches for reference if you need
[01:52] <roaksoax> bigjools: cool thanks
[01:52] <roaksoax> bigjools: no not really
[01:52] <bigjools> ok
[01:53] <roaksoax> i'll take care of them tomorrow
[01:53] <roaksoax> now, I'm off
[01:53] <roaksoax> have a good day :)
[01:55] <bigjools> roaksoax: excellent, thank you.  Have a good evening!
[04:49] <AskUbuntu> Adding nodes to MAAS server | http://askubuntu.com/q/220049
[09:43] <Nafallo> hi
[09:43] <Nafallo> where in maas can I define my own preseeds? :-)
[09:43] <Nafallo> I need to specify an http proxy for apt in my environment.
[09:52] <bigjools> Nafallo: yes, /etc/maas/
[09:52] <bigjools> edit existing one
[09:56] <Nafallo> can't see one in there?
[09:56] <Nafallo> I'm using Ubuntu 12.10 btw.
[09:56] <Nafallo> so maas=0.1+bzr1269+dfsg-0ubuntu1
[09:57] <bigjools> Nafallo: I have to dash, rvba should be able to point you to the right place
[09:57] <bigjools> but 12.10 already points a proxy at the squid-deb-proxy on the region controller
[09:58]  * bigjools outta here
[09:58] <rvba> Nafallo: the preseeds are in /usr/share/maas/preseeds/
[09:59] <rvba> Nafallo: like bigjools said, you'll see that /usr/share/maas/preseeds/generic already sets the proxy to be the squid-deb-proxy on the region controller
[09:59] <Nafallo> hmm. I guess the alternative is to point squid-deb-proxy to use a proxy then? :-P
[09:59] <Nafallo> cause my maas is on rfc1918 space, and I'm not planning to NAT it.
[10:00] <rvba> Yeah, you can configure that proxy to use a parent proxy.
[10:01] <Nafallo> I think that will be the best option then, cause currently the machines just time out :-)
[10:01] <Nafallo> thanks. I'll test that :-)
[16:23] <rvba> roaksoax: Hi Andres.  Quick question for you, what is the format of the generated /etc/maas/maas_cluster.conf file?  Right now we have only one value in there (MAAS_URL=http://<IP_ADDRESS>/MAAS).  Is that guaranteed that it will be key=value\nkey2=value2?
[16:25] <roaksoax> rvba: if you make it so yes
[16:26] <rvba> roaksoax: ok, apparently we simply populate this file manually in the packaging so I've got my answer.
[16:26] <roaksoax> rvba: yep, so you'd need to add a new /sed/ in order to replace the second key=value
[16:26] <rvba> roaksoax: ok, got it,ta
[16:26] <roaksoax> rvba: but that file already comes with one key value, and the value for that key is being replaced
[17:01] <rvba> roaksoax: can you please triage this (pretty critical if you ask me)?  https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1081212 allenap or I will work on a fix for it.
[17:03] <roaksoax> rvba: is this bug present in the archives?
[17:03] <rvba> roaksoax: yes
[17:04] <roaksoax> done
[17:04] <rvba> ta
[17:16] <allenap> roaksoax: Could you do the same for bug 1081660 please?
[17:16] <roaksoax> allenap: sure thing
[17:16] <allenap> Ta.
[17:17] <roaksoax> allenap: weird, that bug didn't happen before
[22:36] <roaksoax> bigjools: howdy! is bug #1081392 not fixed in 1.4/quantal?
[22:45] <bigjools> roaksoax: hi
[22:45] <bigjools> roaksoax: it's already in quantal
[22:45] <bigjools> I only noticed the bug on precise
[22:49] <roaksoax> bigjools: ok cool
[22:53] <bigjools> roaksoax: note that this particular fix is already in upstream 1.3, but I did a patch as that saves worrying about bringing in many changes if upstream is refreshed
[22:54] <roaksoax> bigjools: ok cool
[22:54] <roaksoax> bigjools: yeah we shouldn't have issues for this
[23:18] <bigjools> roaksoax: did you see https://bugs.launchpad.net/bugs/1081660
[23:19] <bigjools> ah you did, you triaged it :)
[23:28] <roaksoax> bigjools: yeah, which i found pretty werid
[23:29] <roaksoax> cause that error never appeared before
[23:29] <roaksoax> so unless someone changed something
[23:30] <roaksoax> bigjools: this is how it handles it: ip=$(ifconfig eth0 | awk '$1 == "inet" { sub("addr:","",$2); print $2; }') && [ -n "${ip}" ] && host=$(dig +short -x $ip)  && host=${host%.}
[23:31]  * bigjools blinks
[23:32] <bigjools> roaksoax: I expect it's a genuine timeout and dig is returning that string
[23:32]  * bigjools reconnecting
[23:35] <roaksoax> bigjools: yeah that might indeed be the issue, though I've never seen it before :/
[23:36] <roaksoax> i can't reproduce it
[23:42] <bigjools> roaksoax: sigstop the dns server?
[23:44] <bigjools> btw I copied all the packages from experimental to testing


[10:02] <jamespage> xnox: hello - I'm trying to figure out why ceph on armhf has suddenly decided it wants to link against libboost-random1.67.0 - all other archs don't which I find odd
[10:03] <jamespage> any ideas?
[10:15] <gpiccoli> Hi sil2100, vorlon - recently (~a month ago) mdadm was pushed to -proposed but it contains code that depends on kernel counter-part, from dannf. Kernel team is still figuring the proper solution to this raid0 layout stuff, so mdadm is block-proposed. Well...I need to release a mdadm version with a small patch, so discussed with dannf and kernel team, and we decided, if possible, to drop the current proposed and do my release first
[10:16] <gpiccoli> So, can I ask you to drop the current mdadm from proposed? ddstreet uploaded my mdadm version, it's all explained in LP #1847924
[10:16] <gpiccoli> Tnx in advance sil2100 and vorlon
[10:20] <LocutusOfBorg> jamespage, https://launchpadlibrarian.net/460565614/buildlog_ubuntu-focal-armhf.ceph_14.2.5-3ubuntu2_BUILDING.txt.gz
[10:20] <LocutusOfBorg> "libboost_random" is used in some places
[10:21] <LocutusOfBorg> e.g. ceph-mon
[10:21] <LocutusOfBorg> ceph-dencoder
[10:23] <jamespage> LocutusOfBorg: yeah that's what's puzzling me - because all of the other arch builds do the same thing but don't end up with that as a depends
[10:25] <LocutusOfBorg> ldd /usr/bin/ceph-dencoder |grep random -> returns stuff on armhf
[10:28] <sil2100> gpiccoli: hey! The mdadm upload that you have prepared, just to confirm - it's based on what was in updates rather than what was in -proposed, correct?
[10:30] <gpiccoli> Hi sil2100 o/
[10:30] <gpiccoli> Exactly, it's based on -updates
[10:31] <gpiccoli> I've added an entry (as per ddstreet suggestion) related to dannf proposed stuff, and mentioned in my changelog that it was removed
[10:31] <gpiccoli> This is in order to have users better clarified on what's happened
[10:31]  * gpiccoli bbiab (~2h)
[10:47] <jamespage> LocutusOfBorg: linking is wonky on that architecture - "lots of package could avoid a useless dependency"
[10:50] <LocutusOfBorg> yes I came to the same conclusion
[10:50] <LocutusOfBorg> linker is not stripping it
[10:50] <LocutusOfBorg> because objdump on armhf and amd64 shows the same symbols used on both archs, and none related to random
[10:53] <LocutusOfBorg> doko, ^^ this looks like more a binutils regression TBH
[10:54] <jamespage> I checked the previous armhf build and it does not appear to have the same issue
[10:54] <jamespage> looking into the logs now
[10:55] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/10936746/+listing-archive-extra
[10:55] <LocutusOfBorg> jamespage, ^^
[10:57] <jamespage> ack
[10:58] <jamespage> only ref I can find in the source tree is to a test class so it might be needed for the build, but not for the binaries
[10:58] <infinity> boost_random is being explicitly placed on the linker line, I'm not sure you can blame binutils for doing as asked.
[10:59] <LocutusOfBorg> infinity, I blame binutils for not correctly stripping it with as-needed provided
[10:59] <LocutusOfBorg> and I blame it for correctly removing it on everywhere except armhf...
[11:01] <LocutusOfBorg> moreover, the last run on 22/12/2019 https://launchpad.net/ubuntu/+source/ceph/14.2.4-0ubuntu3/+build/18461332 had the same boost_random link, but no random library linked
[11:01] <infinity> So, further WTF, why is armhf built with clang and arm64 with g++?
[11:03] <infinity>   * [6eddb32] Build with clang(++) on armhf mipsel armel.
[11:03] <LocutusOfBorg> #849657
[11:03] <infinity> That's likely the cause of the behaviour difference.
[11:03] <infinity> And it's not needed for Ubuntu, I imagine, where our armhf buildds are beefy.
[11:03] <LocutusOfBorg> so clang is dumb?
[11:05] <infinity> clang might indeed be dumb.  Even if it's not, it's really poor form to use different compilers on different arches, and a nightmare to debug the subtle binary differences.
[11:05] <infinity> jamespage: I'd recommend backing out that g++ -> clang++ change and see if it magically loves you.
[11:06] <infinity> (make it dependent on a dpkg-vendor is Debian check, if you want to upstream it and let Debian keep their braindead nonsense here)
[11:06] <jamespage> infinity: good spot
[11:06] <jamespage> thanks
[11:07] <LocutusOfBorg> infinity, maybe if you want to upstream the change in Debian, you can ask them to keep gcc and reduce parallelism on arm?
[11:10] <infinity> No idea if it was an OOM they were working around or hitting the 2G hard limit (but we don't build on 32-bit kernels, so our hard limit's a bit higher for individual userspace processes, or should be)
[11:10] <infinity> Either way, if it works with g++ on Ubuntu, my carefactor for what Debian does it low.
[11:10] <jamespage> I'll do the dpkg-vendor trick to exclude ubuntu
[11:10] <infinity> s/it/is/
[11:11] <jamespage> happy to push that back to Debian - I'm working with the new maintainer to get things back in sync and still have git commit permissions
[11:11] <LocutusOfBorg> looks like they are already using max-parallel=2 on armhf
[11:11] <infinity> Also unnecessary for us.
[11:12] <infinity> Probably.
[11:12] <jamespage> you'd be surprised - ceph can hit the ceiling
[11:12] <infinity> Well, if it works with parallel=4 on other arches, it should on armhf too. :P
[11:12] <jamespage> of the builder memory size easily with any level of parallel
[11:12] <infinity> (note that armhf and arm64 buildds are literally identical VMs on identical hardware, and I refuse to believe the 64-bit builds use less RAM)
[11:13] <jamespage> infinity: whats the memory size?
[11:13] <jamespage> looking at notes I left myself in the past
[11:13] <infinity> I believe they're all 4 vCPU, 8G.  I think.
[11:13] <jamespage> https://www.irccloud.com/pastebin/MmppuWX8/
[11:13] <LocutusOfBorg> https://salsa.debian.org/ceph-team/ceph/commit/6eddb32731f4edda764eb5f4cd634599a8487ca7
[11:13] <LocutusOfBorg> I think this commit needs to be relegated to just armel and mipsel
[11:14] <LocutusOfBorg> or probably only mipsel, I can't find any failure related to OOM in debian buildd logs
[11:14] <LocutusOfBorg> btw why not package the new release?
[11:15] <LocutusOfBorg> (funnily enough, all the mipsel hacks didn't work so far, the package still FTBFS there)
[11:17] <infinity> mipsel probably just needs to die in a fire.
[11:18] <infinity> Oh, but they're building it on shiny mips64 hardware/kernels now.  So, WTF.
[11:20] <Laney> Drop it and see what happens. Worst case you have to revert, but yay for unstable being unstable. :)
[11:20] <LocutusOfBorg> what is the situation for htslib on s390x? debian removed it...
[11:20] <infinity> I am genuinely curious what horrifying things the ceph people are doing to OOM compilers like this.
[11:32] <infinity> LocutusOfBorg: It's fascinating to me that the upstream "we think there are endian issues" bug has been open for years, but the massive regression only happened, like, last month.
[11:32] <infinity> LocutusOfBorg: I'd suggest that bisecting where that went wrong would probably be trivial, but we can tear out the rdep stack too, whatever.
[13:03] <tarzeau> will 20.04 have python2 or not?
[13:16] <tarzeau> https://wiki.ubuntu.com/Python/3 not really up to date or?
[13:17] <ogra> tarzeau, there is a removal discussion on the ubuntu-dvel ML IIRC
[13:17] <ogra> *-devel
[13:19]  * tarzeau looks for the ml archive
[13:20] <gpiccoli> sil2100, I'm back if you have anything to discuss about mdadm =)
[13:20] <tarzeau> https://lists.ubuntu.com/archives/ubuntu-devel/2020-January/thread.html
[13:20] <JackFrost> Given the timeframe, there's not enough time for https://people.canonical.com/~ubuntu-archive/transitions/html/python2-rm.html
[13:22] <JackFrost> https://ubottu.com/y/ff  is the release schedule, if you wondered.
[13:23] <tarzeau> JackFrost: i'm aware of that still 40 days to get pkgs into 20.04 :)
[13:23] <tarzeau> i just don't know if 20.04 will have this or not: https://tracker.debian.org/pkg/gmic
[13:26] <JackFrost> It was already removed, so not if it isn't fixed.
[13:26] <JackFrost> !info gmic focal
[13:26] <tarzeau> i have a fix, but i don't like making nmus
[13:27] <tarzeau> you'll miss flowblade, sure you could make a snap of it
[13:27] <JackFrost> The maintainer is lowNMU, fwiw.
[13:27] <JackFrost> Did you see plugwash's work?
[13:28] <tarzeau> i know i even asked if he'd mind, and he doesn't, still i hate NMU (personal preference)
[13:28] <tarzeau> nope, where?
[13:28] <JackFrost> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922582#18
[13:28] <JackFrost> No I understand the distaste for NMUs.
[13:29] <tarzeau> yeah that's what i applied and given credit to bug reporter (hah, must fix): http://phd-sid.ethz.ch/debian/gmic/
[13:29] <tarzeau> but then i'm not a fan of just fixing gmic, which is one year old, i'd rather have the latest 2.8.2 (for the next five years)
[13:29] <tarzeau> but oh well i run unreleased or sid anyways
[13:29] <JackFrost> I mean, Ubuntu *could* jump ahead I'd imagine.
[13:30] <tarzeau> i have never figured how to get something into ubuntu/or updated, still doing pkg into debian, waiting archive sync
[13:31] <tarzeau> and new queue/ debian/copyright is worse than finding dd-who-sponsors-dsc-links
[13:31] <JackFrost> If at all possible, Ubuntu hates to maintain deltas needlessly.
[13:31] <tarzeau> yeah i figured, and that's also great!
[13:31] <tarzeau> but now debian has fasttrack!
[13:31] <tarzeau> ok ubuntu has frankenPPA
[13:31] <JackFrost> Which...Isn't complete and doesn't precisely relate? :)
[13:32] <tarzeau> true, /me will stick to his reprepro (well not me, but user friends)
[13:33] <tarzeau> instead of deltas, what about allowing packages to circumvent debian new queue pkgs?
[13:33] <JackFrost> Some have done that, I don't know how frowned upon that is.
[13:33] <tarzeau> who is that some, and how did they do so?
[13:33] <JackFrost> (Also, some DDs don't like a dsc?)
[13:34] <tarzeau> because they prefer salsa git?
[13:34] <JackFrost> Basically by being the maintainer in Debian too.  But they cheated with a 0build1 trick.
[13:34] <JackFrost> Ah.  I like things being maintained in git, but dsc for sponsorship is nice.
[13:35] <tarzeau> is canonical doing HPC stuff?
[13:35] <tarzeau> (wrong channel to ask that?)
[13:35] <JackFrost> I'm not a Canonicalite.
[13:41] <JackFrost> tarzeau: https://salsa.debian.org/fasttrack-team/support/issues/10#note_123991 still isn't the most reassuring.
[14:01] <rafaeldtinoco> quick question on migrations
[14:01] <rafaeldtinoco> builddeps:/tmp/autopkgtest.9ZDytk/2-autopkgtest-satdep.dsc:i386 : Depends: wmnd-snmp:i386 but it is not installable
[14:01] <rafaeldtinoco> is i386 avoiding migrations currently ?
[15:04] <dannf> gpiccoli: thx!
[15:05] <gpiccoli> Thank you dannf, for letting me slip my upload first hehe =)
[15:29] <xnox> jamespage:  fun! build log? Most likely something somehwere is missing, and normally the boost from inside ceph is used, instead of system one. Note that cmake&boost have weird integration now, such that "findboost" might be defaulting to system stuff now.
[15:56] <infinity> xnox: Check later context, his problem was almost certainy Debian switching armhf to clang, while other arches use gcc.
[15:59] <xnox> infinity:  oh, ok.
[16:19] <tdaitx> so, is there a service I can trust to tell me if a given TZ table is actually wrong? in bug 1859217 the user complains that openjdk-8 has regressed on Istanbul TZ, but in fact openjdk-11 was only "working" (as per user description) because upstream didn't update it from tzdata2019b to tzdata2019c (while openjdk-8 did)
[16:22] <tdaitx> the latest security update for openjdk-11 now includes tzdata2019c and thus both openjdk-8 and openjdk-11 are now reporting the same values - which the user says that they are the wrong ones
[16:22] <tdaitx> so I need to check if the alleged "right" values are in fact the right ones
[16:22] <tdaitx> and yeah, I belive tzdata2019c is actually correct and the user is mistaken, but it would be good to check that somehow
[16:22] <tdaitx> sbeattie: fiy ^
[16:22] <infinity> tdaitx: I mean, tzdata is the only authority on the topic, other than local governments and mystic divination.
[16:25] <infinity> tdaitx: On the other hand, 2019c didn't have changes to Istanbul AFAICT...
[16:26] <tdaitx> infinity: it did: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/8560bc534080 (that's the openjdk commit for it, it's the same as openjdk-11 and I suppose the same for upstream)
[16:27] <Laney> The announcement says it changed some historical data for Turkey
[16:28] <infinity> tdaitx: Oh, yeah, deep in the past.
[16:28] <tdaitx> yeah
[16:29] <infinity> If you want to check if they're right, Paul gives references in the comments.
[16:30] <infinity> But your user's bug is likely a non-bug.
[16:31] <tdaitx> infinity: sorry, which bug are you referring to?
[16:32] <infinity> tdaitx: The one you linked?
[16:33] <tdaitx> infinity: I don't see any comments from Paul
[16:33] <Laney> Paul is upstream of tzdata
[16:33] <infinity> tdaitx: Your user's complaint of regression is more just business as usual for tzdata.  It's unfortunate that different Java versions will all disagree until they're all updated, but that's their own fault for bundling tzdata instead of using system zone files. :P
[16:34] <infinity> tdaitx: Oh, "the comments" being the comments in the zone files.  Paul Eggert being Paul.  When he changes things, he leaves comments referencing why (usually URLs to papers on the topic, etc)
[16:35] <infinity> tdaitx: But generally, I trust him to be right, as he's the de facto authority on timezones anyway.  The world all uses tzdata as their authoritative set, so even if it's wrong, it's right.  Until the next version, which is more right.
[16:35] <tdaitx> right, found it (it was the link for the commit, not a bug report, that's why I got confused)
[16:35] <tdaitx> ok, good to know
[16:36] <tdaitx> Laney: infinity: thanks
[16:40] <jamespage> xnox: figured it out - have an upload in testing atm
[17:14] <tdaitx> infinity: as for 'checking' the results, I used a simply "date --date='TZ="Europe/Istanbul" 1943-01-01 12:01:01' '+%s'" which confirms the openjdk output
[18:35] <rafaeldtinoco> ahasenack: ping
[18:35] <ahasenack> rafaeldtinoco: hola
[18:35] <rafaeldtinoco> ahasenack: if you have ~5 min, could u check if it makes sense to add wmnd i386 test to britney hints file ?
[18:36] <rafaeldtinoco> both autopkgtests from it are mutual exclusive (wmnd and wmnd-snmp)... somehow autopkgtest can't handle test dependencies for i386
[18:36] <rafaeldtinoco> not quite sure why
[18:36] <rafaeldtinoco> but everything is ok for i386 as well, Im afraid it will block its migration, and that is the last for net-snmp I believe
[18:37] <ahasenack>  builddeps:/tmp/autopkgtest.WFivWM/1-autopkgtest-satdep.dsc:i386 : Depends: wmnd:i386 but it is not installable
[18:37] <ahasenack> have you tried installing that to see why it's uninstallable?
[18:37] <rafaeldtinoco> Broken builddeps:/tmp/autopkgtest.WFivWM/2-autopkgtest-satdep.dsc:i386 Depends on wmnd-snmp:i386:any < none @un H >
[18:37] <rafaeldtinoco> yep.. if I install locally generated .deb .. it passes test1
[18:37] <ahasenack> well
[18:37] <ahasenack> no
[18:37] <ahasenack> I mean, on a amd64 host, add the i386 arch
[18:37] <ahasenack> and then try to install wmnd-snmp:i386
[18:38] <ahasenack> you have wmnd in a ppa somewhere?
[18:38]  * rafaeldtinoco checks
[18:38] <rafaeldtinoco> nope, will provide
[18:57] <rafaeldtinoco> ahasenack: https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1855943
[19:01]  * ahasenack checks
[19:03] <rafaeldtinoco> it does not work with add-architecture
[19:03] <rafaeldtinoco> it depends on having a full i386 env
[19:03] <rafaeldtinoco> it can't even find :i386 package
[19:04] <ahasenack> well, that ppa didn't build i386
[19:05] <rafaeldtinoco> oh, yep
[19:05] <rafaeldtinoco>  Intel x86 (i386)
[19:05] <ahasenack> https://launchpad.net/ubuntu/+source/wmnd/0.4.17-3ubuntu1 also didn't
[19:05] <rafaeldtinoco> it had default
[19:05] <rafaeldtinoco> yep
[19:05] <rafaeldtinoco> i guess its "deactivated
[19:05] <ahasenack> yes, not in the whitelist
[19:05] <rafaeldtinoco> that explains
[19:05] <ahasenack> vorlon: ping ^
[19:05] <ahasenack> just a case for a badtest hint for wmnd/i386?
[19:06] <rafaeldtinoco> i believe so
[19:06] <rafaeldtinoco> its blocking net-snmp
[19:06] <rafaeldtinoco> which is blocking pcs
[19:06] <ahasenack> relax :)
[19:06] <ahasenack> many things are blocking many things in the archive at any given time :)
[19:07] <ahasenack> vor-lon might be mid-travel (sprint)
[19:07] <rafaeldtinoco> oh, true
[19:08] <rafaeldtinoco> https://media.giphy.com/media/5qoRdabXeT4GY/giphy.gif
[19:08] <rafaeldtinoco> =)
[19:08] <rafaeldtinoco> alright Ill shift context then
[19:08] <rafaeldtinoco> this one is almost there
[19:10] <ahasenack> you can propose an MP for the badtest, assuming that is the right thing
[19:16] <rafaeldtinoco> ahasenack: yep, will do it
[19:16] <rafaeldtinoco> tks
[19:35] <vorlon> ahasenack: hinted
[19:35] <ahasenack> rafaeldtinoco: ^
[19:35] <ahasenack> vorlon: thanks!
[19:36] <vorlon> ahasenack: and yes, this is the correct course of action for any source packages not in the list I posted to ubuntu-devel
[19:36] <rafaeldtinoco> nice.. good to know
[19:36] <ahasenack> seconded
[19:51] <seb128> vorlon, https://launchpad.net/ubuntu/+source/glib2.0/2.63.3-2 added a depends from the libglib2.0-tests to xdg-desktop-portal which is blocking migration since xdg-desktop-portal isn't available on i386. What's the recommended solution there? changing glib to not build the -tests package on i386?
[19:56] <ahasenack> vorlon: from https://pastebin.ubuntu.com/p/HmSd9xd7NN/, on an amd64 lxd with i386 added, I was able to install krb5-multidev:i386 libkrb5-dev:i386 and libkrad-dev:i386 just fine, but not build-essential. I don't even know why it's trying to install build-essential, the dep8 tests only require @ for the kinit test, and @, slapd, ldap-utils, libsasl2-modules-gssapi-mit for the slapd-gssapi test
[19:56] <ahasenack> and this passed before, lemme get the link
[19:56] <ahasenack> http://autopkgtest.ubuntu.com/packages/krb5/focal/i386
[19:57] <ahasenack> build-essential amd64 was used the last time this i386 test passed
[19:58] <ahasenack> hmm, same this time
[19:59] <ahasenack> ah, if I enable proposed, then build-essential (amd64) becomes uninstallable
[19:59] <ahasenack>  build-essential : Depends: libc6-dev but it is not going to be installed or
[19:59] <ahasenack>                             libc-dev
[19:59] <ahasenack>                    Depends: g++ (>= 4:9.2) but it is not going to be installed
[20:06] <ahasenack> linux-libc-dev (src:linux) 5.4.0-11.14 is in focal-proposed according to rmadison, but  don't see it listed in https://launchpad.net/ubuntu/+source/linux (yet?)
[20:07] <ahasenack> https://launchpad.net/ubuntu/+source/linux/5.4.0-11.14 is a 404
[20:07] <ahasenack> oh, there is a linux-5.4 source
[20:08] <ahasenack> https://launchpad.net/ubuntu/+source/linux-5.4 it tricks us
[20:08] <ahasenack> focal-specific
[20:08] <sarnold> ahasenack: I've found this helpful to try to keep track of the various kernel source packages https://kernel.ubuntu.com/sru/dashboards/web/kernel-stable-board.html
[20:10] <ahasenack> thanks
[20:12] <ahasenack> I'll wait for the kernel builds to settle a bit in proposed/migration
[21:00] <LocutusOfBorg> infinity, https://github.com/samtools/htslib/commit/418a183ef842a966afb00e783c09ac7fd7eaeb62
[21:00] <LocutusOfBorg> does this ring a bell?
[21:00] <LocutusOfBorg> I git bisected it
[21:01] <LocutusOfBorg> and that is the first commit with s390x failing
[21:17] <vorlon> seb128: yes, I would say omit the glib-tests package
[21:17] <seb128> vorlon, k, thanks
[21:18] <vorlon> ahasenack: build-essential:amd64 is installed because the way we're installing cross test deps leverages apt-get build-dep; so build-essential:native is always required by apt
[21:19] <ahasenack> I see


[15:06] <realtime-neil> Is it possible to run autopkgtest units as part of a package build on launchpad?
[15:14] <cjwatson> realtime-neil: No
[15:15] <realtime-neil> cjwatson: shucks. What do people do instead? I'm ready to follow prior art.
[15:25] <cjwatson> realtime-neil: Stuff that ends up in Ubuntu has autopkgtests run by the Ubuntu infrastructure (which is not part of Launchpad).  I'm not aware of what people do for random PPAs