[10:34] <knome> shouldn't #ubuntu-wiki point here, since the channel itself seems dead
[10:36] <SaberX01> I would think so .. all *-doc  should do.
[10:38] <SaberX01> knome .. did you scribe all the PGP stuff? Was pretty nice .. read through it all again this evening.
[10:38] <knome> scribe... what?
[10:42] <SaberX01> the GnuPG stuff: https://help.ubuntu.com/community/GnuPrivacyGuardHowto
[10:44] <knome> no, i didn't touch that :)
[11:13] <knome> https://help.ubuntu.com/community/IRCTranslatorProject
[11:13] <knome> what's peoples take on that?
[11:14] <pleia2> if it were alive, it belongs on wiki.u.c, not the help wiki
[11:14] <knome> yes, but it seems to be dead
[11:14] <knome> and even that page has like 150 hits ever
[11:14] <pleia2> oh neat, the header says that
[11:14] <knome> yes, i tagged it
[11:14] <knome> but i was wondering whether we really want to move it
[11:14] <knome> or just delete it
[11:15] <pleia2> yeah, might be for deleting since it's pretty old now
[11:17] <pleia2> I think I might pass out now, see you
[11:18] <knome> good night! :)
[11:25] <SaberX01> knome, Well, I spend allot of Time in IRC ..and the main thing I see comming back from those we send to !es ot !ru  etc is the activity on those channels is often very low compare3d to the main support channel.
[11:28] <SaberX01> As for the doc itself, see how it's in EN .. not sure how much it's being used.
[17:42] <knome> seems its impossible to delete the page at https://help.ubuntu.com/community/https%3A/wiki.ubuntu.com/phillw/Lubuntu/Documentation/CheckCD
[17:42] <knome> anybody has ideas?
[17:43] <knome> https://help.ubuntu.com/community/https:/wiki.ubuntu.com/phillw/Lubuntu/Documentation/CheckCD?action=DeletePage gets you to the "really delete the page?" page, but clicking delete again redirects you to "not found"
[17:44] <knome> renaming doesn't work either
[17:45] <knome> ooh, i did it
[17:45] <knome> just created page https:, then deleted that with all subpages
[18:00] <SaberX01> knome, Where is the central knowledge base intended to be; help.ubuntu.com  wiki.ubuntu.com  askubuntu.com ?  Which is considered the master reference ?
[18:02] <knome> wiki.ubuntu.com is directed to developer coordination
[18:02] <knome> at least loosely
[18:04] <SaberX01> Ok, so the ubuntu-doc group focus is on help.ubuntu.com  ?
[18:04] <knome> the main focus should be on the official documentation.
[18:05] <knome> or at least that's how i see it
[18:05] <knome> but as with the community help wiki and askubuntu;
[18:05] <knome> they are different ways to achieve the same things
[18:05] <knome> some people prefer the other
[18:06] <knome> the rest something else
[18:06] <SaberX01> I do not disagree, I am just trying to get my heard around what the priorities are and where to spend calories
[18:06] <knome> do what scratches your itch
[18:08] <SaberX01> By official documentation, what are you referring to there?
[18:09] <SaberX01> Belay my last I found it.
[23:54] <knome> IdleOne, thanks, it works
[23:54] <IdleOne> welcome


[15:30] <jcw4> is karma down?
[15:49] <jcw4> is this the right channel to ask about karma?
[15:58] <lukestuts> Hello - is there anyone here who can tell me about private/commercial PPA hosting on launchpad?
[16:19] <rbasak> lukestuts: I hope somebody comes along to help you, but if not, https://launchpad.net/+tour/join-launchpad#commercial lists<EMAIL_ADDRESS>- HTH.
[16:32] <lukestuts> rbasak: Thanks, that is what I was looking for
[20:38] <tgm4883> Did someone forget to change the supported status of 12.10? The API is still reporting it as supported
[20:38] <dobey> it is still supported
[20:39] <tgm4883> It is? I thought it just ended like last week
[20:39] <tgm4883> May 16th
[20:39] <dobey> oh, so it did
[20:40] <tgm4883> We have a graphic that gets generated from that info, so it's currently wrong http://www.mythbuntu.org/repos
[20:40] <dobey> i was thinking 13.10
[20:42] <tgm4883> dobey: should I file a bug?
[20:43] <dobey> possibly. it seems i can still request recipe builds for it, and shouldn't be able to
[20:46] <tgm4883> dobey: where is the launchpad project on launchpad?
[20:46] <dobey> launchpad.net/launchpad
[20:47] <tgm4883> somehow I probably should have known that
[20:47] <dobey> yeah i was tempted to just reply "launchpad" to troll a bit :)
[20:50] <tgm4883> Ok, bug filed https://bugs.launchpad.net/launchpad/+bug/1322743
[20:50] <tgm4883> Depending on where LP is pulling the data, it might actually be a bug for the Ubuntu project since 12.10 is listed as supported there as well  https://launchpad.net/ubuntu/quantal
[20:54] <dobey> oh cool
[20:54] <dobey> i think i fixed it
[20:56] <dobey> tgm4883: can you verify if it's fixed via the API?
[20:56] <tgm4883> dobey: yep, looks obsolete now :)
[20:57] <tgm4883> Thanks dobey
[20:57] <dobey> sure
[21:30] <cjwatson> dobey: Did you consult with infinity before doing that?  He was deliberately not closing it out in LP yet because he was going to land a final kernel.
[21:31] <cjwatson> dobey: In general please don't update Ubuntu series statuses without checking with us ...
[22:33] <dobey> cjwatson: oh. didn't know, sorry. ok
[22:36] <dobey> cjwatson: i'll change it back


[00:00] <doko> slangasek, do you remember which one?
[00:00] <slangasek> doko: the flag?  not offhand
[00:01] <slangasek> doko: google suggests 'expect stderr' restriction
[00:01] <doko> hmm, it alreadys has: Restrictions: allow-stderr
[00:01] <bdmurray> Riddell: oh, its mostly arm64 except for perlkde
[00:02] <Riddell> bdmurray: so probably fine to release all except perlkde then
[00:02] <slangasek> doko: right, https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1197005 says that's the right syntax; I don't know then
[00:02] <ubot2`> Launchpad bug 1197005 in autopkgtest (Ubuntu) "Add "expect stderr" restriction" [Medium,Fix released]
[00:03] <doko> slangasek, ok, I'll check with piotr tomorrow. care to unblock it? the test did always fail
[00:04] <xnox> doko: there could be other things, e.g. crash files generated (at least i'm under the impression that causes adt tests to fail, i can be wrong)
[00:04] <doko> but then, who did overwrite it in the past?
[00:05] <xnox> doko: i don't think it ever migrated from trusty-proposed to trusty.
[00:05] <xnox> doko: the previous one was copied from saucy i think.
[00:05] <slangasek> no
[00:05] <slangasek> there's a previous 'force-badtest' hint from infinity
[00:06] <xnox> doko: and tests did not pass.
[00:06] <xnox> doko: if [ -x /usr/bin/python2.6 ]; then\
[00:06] <xnox> 		test -f debian/python-foo/usr/lib/python2.6/dist-packages/foo/__init__.p;\
[00:06] <xnox> 		test ! -f debian/python-foo/usr/lib/python2.6/dist-packages/foo/spam.py;\
[00:06] <xnox> 	fi
[00:06] <xnox> grep -qe "Depends: .*python\(:any\)\? (<<" debian/python-foo/DEBIAN/control
[00:06] <xnox> [ "`readlink debian/python-foo/usr/lib/python2.7/dist-packages/foo/absolute_link_to_tmp`" = "/tmp" ]
[00:06] <xnox> make[1]: *** [check] Error 1
[00:06] <xnox> make[1]: Leaving directory `/tmp/adt-run.Vm3DtR/dsc0t-dh-python-testtmp/adttmp/tests/t201'
[00:06] <xnox> make: *** [test201] Error 2
[00:06] <xnox> https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-dh-python/ARCH=amd64,label=adt/8/artifact/results/dsc0t-dh-python-stdout/*view*/
[00:07] <infinity> That's the same test that failed on the previous version and doko assured me it was fine and it would be fixed. :P
[00:07] <slangasek> doko: but I don't like kicking the can down the road indefinitely.  If there's not a pressing need for this fix in trusty, it should stay in -proposed and someone should fix the bug
[00:07] <xnox> that's for 1.20131021-1ubuntu3
[00:07] <xnox> hm. me tries to find actual results in jenkins
[00:08] <slangasek> ugh pbuilder
[00:08] <slangasek> this is why I don't have autopkgtest installed on my laptop. :P
[00:08] <xnox> doko: are you asking unblock for ubuntu3 or ubuntu4 ? cause britney hasn't asked to test ubuntu4 yet.
[00:09] <xnox> slangasek: i use scripts from lp:auto-package-testing which don't have side effects of installing garbage on my machines.
[00:10] <doko> xnox, 4
[00:10] <xnox> slangasek: those cleanly download ubuntu cloud image and do all the dirty work in a snapshot of thereof. and that's the same way adt tests are being executed in the lab.
[00:10] <doko> infinity, did I? can't remember
[00:10] <infinity> doko: Yeah. :)
[00:11] <doko> slangasek, I do want this for the test rebuild
[00:11] <infinity> doko: I think I let it in cause you said the version I unblocked was critical for some reason or other, but you also claimed the test would get fixed (perhaps by upstream).
[00:11] <infinity> Unless you're upstream.
[00:11] <infinity> Then, it was by you. :P
[00:11] <xnox> doko: then you don't get to claim all tests have passed, in the ADT environment, cause ADT has not run yet for ubuntu4 yet ;-)
[00:12] <doko> no, python helpers are a thing I'm staying away from. too many hostile people out there ...
[00:12] <slangasek> xnox: needing to grab a cloud image when I have perfectly good, pbuilder-free schroots here also seems onerous ;)
[00:12] <doko> hmm, I need to learn how to run autopkgtests locally ...
[00:13] <xnox> slangasek: adt tests are expected to be able to break test-beds =/ so, lxc or kvm, no chroots here when running those.
[00:13] <xnox> doko: an sbuild hook would be nice, to install and run the tests at the end of the build, wouldn't it?
[00:13] <xnox> or just use a schroot run to do them.
[00:13] <slangasek> doko: sudo adt-run /path/to/dh-python_1.20131021-1ubuntu4.dsc  --- adt-virt-schroot trusty
[00:13] <doko> infinity, looks like pitti did try to fix it, but didn't succeed. I don't think that I did ask you in the past ...
[00:14] <xnox> slangasek: oh, nice.
[00:14] <doko> will try to address this tomorrow
[00:14] <infinity> doko: Given my hint unblocking it, you must have asked me.
[00:14] <doko> anyway, have to wait for an eglibc upload for the test rebuild
[00:14] <slangasek> infinity: you only add hints when doko asks you?
[00:15] <doko_> infinity: can you please unblock cmake?
[00:15] <infinity> doko: eglibc being worked on right now.
[00:15] <infinity> xnox: By fixing libarchive?
[00:16] <xnox> infinity: yes please. I'm a bit clueless about it. extracted the actual test-suite output and the test case is sane. not sure if it's symptoms of the same eglibc issue or not =/
[00:17] <infinity> xnox: If it uses strstr, it could be.
[00:17] <infinity> And pretty much everything uses strstr.
[00:17] <infinity> So, we'll see.
[00:47] <xnox> infinity: but seriously, can you migrate cmake before/for the archive rebuild ? cause it's only invalidated by dependency....
[00:47] <infinity> xnox: Uhm, no.
[00:47] <xnox> Uhm, ok.
[00:47] <infinity> xnox: "invalidated by dependency" means it DEPENDS on that other package.
[00:48] <infinity> xnox: As in, it depends on that version of libarchive.
[00:50] <infinity> I'm not sure why that would be, in this case, mind you.
[00:50] <xnox> infinity: i don't see how though =/ hm, not a condition i've seen before from britney.
[00:50] <infinity> Happens all the time during ABI transitions, etc.
[00:51] <infinity> Oh, it might be because of ppc64el.  cmake on ppc64el depends on libarchive13, which only exists in -proposed.
[00:51] <infinity> We could temporarily break that, but I'd prefer not to.
[00:52] <infinity> Or I could cheat, by moving the ppc64el libarchive into the bootstrap repo.
[00:52] <xnox> yeah... cause there is cmake/ppc64el in trusty-release....
[00:53] <slangasek> doko: fwiw, on the failing test ([ "`readlink debian/python-foo/usr/lib/python2.7/dist-packages/foo/absolute_link_to_tmp`" = "/tmp" ]), I see the following:
[00:53] <slangasek> debian/python-foo/usr/lib/python2.7/dist-packages/foo:
[00:53] <slangasek> lrwxrwxrwx 1 root root 51 Dec 20 00:43 absolute_link_to_tmp -> ../../../../share/pyshared/foo/absolute_link_to_tmp
[00:53] <slangasek> that is obviously not an absolute symlink, and the test should be fixed
[00:53] <slangasek> (or dh-python itself fixed)
[00:54] <infinity> Oh, it's already in the bootstrap repo, not as easy to cheat as I was thinking.
[00:54] <infinity> xnox: Anyhow, let's see if my glibc magically fixes it shortly.
[00:54] <infinity> Well, "shortly"... Once I've built it.
[00:55] <xnox> infinity: ah britney doesn't consider bootstrap repo. makes sense.
[00:55] <slangasek> quite
[00:56] <xnox> and copying across libarchive13/pp64el binary without source, to trick britney into migrating cmake, is wrong on so many levels..... right, i'll go bother about something else, whist infinity cooks eglibc =)
[00:57] <slangasek> we could equally force-migrate libarchive before it's fixed on i386
[00:57] <slangasek> but if it's done soon... why bother
[00:58] <infinity> xnox: britney sort of does consider the bootstrap repo to avoid too much pain, actually.
[00:58] <infinity> But I may have missed a corner case.
[00:58] <infinity> And I don't much care in this case, we should just fix the bugs.
[01:20] <infinity> xnox: Huh.  So, I can't reproduce that libarchive test failure.
[01:21] <xnox> infinity: on i386?
[01:22] <xnox> infinity: i can, but then again i haven't rebooted my machine into fresh kernels in a while.
[01:22] <infinity> xnox: On i386, yes.  In the same chroot where I *can* reproduce the java vs strstr bug.  So, it's not that.
[01:22] <xnox> infinity: yeah, it did smell fishy, and not fully related to the eglibc bug.
[01:23] <xnox> infinity: went to try wacking it again, but i guess it's you who have retriggered a rebuild ;-)
[01:24] <infinity> Yeah.
[01:24] <infinity> If it fails on the buildd, I'll start comparing package versions.
[01:25] <infinity> This chroot is stale by a few days, since I haven't upgraded it since I started looking at the java thing.
[01:25] <infinity> Nope, it passed on the buildds now.
[01:25] <infinity> So, racy test, or problem solved elsewhere.
[01:57] <slangasek> doko_: this autopkgtest has been broken since the first commit in the dh-python branch, one wonders why Piotr has tests if he's not going to use them. :P  I can't tell if it's the test or dh_python that should be fixed; I'm filing a bug in Debian and unblocking
[02:00] <infinity> Grr.  I do love it when people sync -f over my changes and then DON'T FIX THE RESUTLING FTBFS.
[02:00] <infinity> resulting, too.
[02:05] <StevenK> "It built locally, must be a buildd issue!"
[02:05]  * StevenK hides.
[02:15] <slangasek> some kind of irony that I installed autopkgtest to verify a dh-python bug, and on removal it left behind .pyc files
[02:17] <infinity> StevenK: Given that the changelog specifically stated the fix was powerpc-specific, "it built locally" would be a pretty lousy excude for sync -f.
[02:17] <infinity> excuse, too.
[02:18] <infinity> And the old patches applied cleanly too, so "I think upstream might have fixed it" would also not work. :P
[09:05] <Laney> It's easy to miss sync FTBFSen given that they don't mail
[09:31] <infinity> Laney: It's easy to miss the FTBFS, it's a bit harder to miss the patches you overwrote. ;)
[09:31] <infinity> Laney: But we chastised him appropriately with "I can't test it" doesn't mean "drop the patches", it means "ask someone who can".
[09:33] <Laney> Oh yeah, it's still naughty to do that, but usually you'd get shouted at by soyuz before anyone else notices.
[09:34] <infinity> Agreed that people who copy packages should get FTBFS grump mail.
[09:34] <infinity> wgrant: Why don't they?  Bug, or actually hard to do for some reason?
[09:34] <wgrant> infinity: Both.
[09:35] <infinity> wgrant: Let me guess, we have no concept of creator on those, just the signer?
[09:35] <wgrant> infinity: It needs to guess at the publication to use.
[09:36] <infinity> wgrant: How so?  Isn't the build record a bit more specific in its lineage than the source?
[09:36] <wgrant> infinity: The build just lists an archive, suite, architecture and sourcepackagerelease.
[09:37] <infinity> wgrant: I mean, if you FTBFS in a PPA, it's the person who uploaded/copied to that PPA, if you FTBFS in primary, it's obviously a build record that was created after a copy to primary, which you can only do once.  You can only create a record for a source once in any archive.
[09:37] <wgrant> Notifications have historically gone to SPR.creator because derp.
[09:37] <wgrant> They need to go to SPPH.creator
[09:37] <infinity> wgrant: Okay, but do we know who copied the SPR into the archive?
[09:37] <wgrant> But for that we need to guess at which SPPH is relevant.
[09:37] <wgrant> Which apparently doesn't always work.
[09:38] <wgrant> There's a similar problem with attributing translations for copies, not quite sure what's going wrong.
[09:38] <infinity> Would it be mean for me to assign the bug to Celso and make him fix it the day he starts?
[09:40] <wgrant> Yes :)
[09:41] <infinity> You're no fun.
[09:44] <apw> that would be very [just do it] mean thing to [just] do [it]
[09:50] <Laney> Cruel to be kind
[13:46] <sergiusens> can someone please check on golang-gocheck and golang-go-flags please?
[13:46] <sergiusens> from the new queue
[13:55] <xnox> infinity: doko: demote python-pyste to universe (got denewed into main?!) & demote gccxml src+bin  to universe. Ready as per component-mismatches.
[14:01] <doko> xnox, done
[14:04] <xnox> cheers!


[00:29] <cjwatson> Laney: I don't think there are any significant ones in the long term; I'm somewhat interested in doing something expedient for now, but it wouldn't be hard to refactor later
[00:29] <Laney> ack
[00:31] <cjwatson> mainly because I've left it rather late to get this done and I'd like not to have to wait for April to test it ...
[00:40] <Laney> well, and the first autosync of a cycle might not be the best time to test a brand new tool :-)
[00:41] <Laney> anyway, getting it out the door fast is fine by me: we then have 4 monthsish to shuffle code around
[00:42] <cjwatson> depends how you look at it ... but at the very least it means there's a giant pile of output and it's hard to audit
[00:43]  * cjwatson decides to just not bother believing that "Blacklisted current version" knows what it's talking about, since it appears not to always do so
[00:43] <Laney> we came to that conclusion for syncpackage too
[00:44] <cjwatson> from what I can tell all it means is this_version > parent_version, and auto-sync can check that for itself ...
[00:45] <Laney> except when it's set incorrectly or LP forgets to clear it
[00:45] <cjwatson> exactly
[00:46] <cjwatson> it's poor naming anyway
[00:47] <Laney> https://bugs.launchpad.net/launchpad/+bug/841372
[00:47] <ubot4> Launchpad bug 841372 in launchpad "Incorrect auto-blacklisting in DSD? (affects: 1) (heat: 7)" [Low,Triaged]
[00:47] <cjwatson> yeah, just found that from the ref in syncpackage
[00:48] <cjwatson> I think I have less rabbit-holey bugs to use my LP hacking time on though :)
[00:48] <Laney> shame, as per-version blacklisting could be generally useful
[00:48] <cjwatson> mm, sounds no fun to maintain though
[00:48] <cjwatson> I suspect you'd often want a range of some kind
[00:48] <cjwatson> "upstream 1.4 sucked, but we hear 1.5 is better"
[00:50] <Laney> probably
[00:54] <cjwatson> ooh, I should use copyPackages, that doesn't send mail
[01:08] <cjwatson> (1) done
[01:10] <Laney> goodnight. tomorrow I try to get local LP reasonably functional.
[01:51]  * cjwatson posts a lengthy followup to bug 597041 on the binary->source lookup issue
[01:51] <ubot4> Launchpad bug 597041 in python-launchpadlib (Ubuntu) (and 1 other project) "No way to get from binary package to source package (affects: 1) (heat: 8)" [Undecided,Invalid] https://launchpad.net/bugs/597041
[12:37] <cjwatson> OK!  I think I'll be able to run an API auto-sync later today
[12:37] <cjwatson> Will check in the code a bit later; have to run now
[12:37] <cjwatson> The only significant thing that's not yet implemented is component checks on binaries, which isn't desperately important for the moment


[15:06] <Kilos> hi guys, is it my imagination or is the internet getting slower all the time
[16:12] <Kilos-> inetpro, ping
[16:15] <Kilos>  /msg NickServ identify %$*&Kilos
[18:46] <Kilos> hi pavlushka
[18:46] <pavlushka> Hello dear Kilos
[18:46] <Kilos> you well lad?
[18:47] <pavlushka> Kilos: Well, I am alive! the best part seems, he he
[18:47] <Kilos> lol
[18:49]  * pavlushka feeling a little more worthy making someone laugh
[18:50] <Kilos> thats good
[18:51] <pavlushka> you good Kilos? This channel is missing a lot of its folks.
[18:52] <Kilos> im good ty. yes and no one chats anymore
[18:53] <Kilos> and the bot is missing
[18:55] <pavlushka> Kilos: Oh, didn't noticed that!
[18:56]  * pavlushka feels like a coffee
[18:58] <pavlushka> Kilos: I think its a lot easier to run 'cat /etc/lsb-release' than 'lsb_release -rd' or...
[19:00] <pavlushka> Kilos: and hey, my beard smells like goat
[19:00]  * pavlushka feeling confused
[19:01] <Kilos> lol
[19:09] <pavlushka> Kilos: look I am actually not a technical guy, as you have seen since 16.04, oops 2016
[19:10] <pavlushka> Kilos: So I can only help people unwind by trash talking.
[19:10] <Kilos> you do well man, you have helped me a few times
[19:11] <pavlushka> Kilos: as I am still stuck in between the trasition from c++ to python.
[19:13] <pavlushka> and love you Kilos and love your glasses and your big Jar of binary coffee :p
[19:14] <Kilos> lol
[19:14] <pavlushka> and yes inetpro's toothpaste, I guess that is sweet most probably
[19:29] <Kilos> i go sleep now. night all. rest well