[00:35] <ubotu> New bug: #179983 in malone "SVGZ doesn't have the good encoding" [Undecided,New] https://launchpad.net/bugs/179983
[01:51] <Larose> My small package works on 6.06, 6.10, 7.04, 7.10 and 8.04, is there a way, when uploading it to my-ppa, that the binaries are build for every version ?
[01:52] <Fujitsu> Larose: You need to upload multiple versions of the package. Say 1.0-1~ppa1, 1.0-1~ppa1~7.10, 1.0-1~ppa1~7.04...
[01:53] <Larose> and change the "{gutsy, festy, ...}" in the debian/changelog ?
[02:06] <Fujitsu> Larose: Yes, sorry.
[02:08] <ScottAS> Hello All. Could someone help me with a problem?
[02:08] <Larose> In http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog, it is written that I can put multiples distribution (separated by space), but it doesn't work with my-ppa : "Rejected: Unable to find distroseries: dapper edgy feisty gutsy hardy"
[02:09] <Larose> Fujitsu: I don't understand the ~***
[02:09] <Larose> Fujitsu: Is it documented ?
[02:10] <Fujitsu> Larose: It's probably not documented anywhere, though it has been referred to on launchpad-users a couple of times lately.
[02:10] <Fujitsu> In a Debian version, `~' is less than anything, even `'
[02:10] <Larose> well, ok
[02:10] <Fujitsu> So 1.0-1~ppa1 is less than 1.0-1, 1.0-1~ppa1~7.10 is less than 1.0-1~ppa1, etc.
[02:10] <Fujitsu> It means users can upgrade properly.
[02:10] <lamont> Larose: it's documented somewhere... ~ is less than null
[02:11] <lamont> hrm.. like Fujitsu said
[02:12] <lamont> Larose: and multiple distro source uploads have historically been an interestingly not-quite-what-you-think situation. even in debian.
[02:12] <lamont> and it looks like launchpad doesn't believe in it
[02:12] <Fujitsu> lamont: It's not possible to do with a pool.
[02:13] <lamont> Fujitsu: I don't buy that.  OTOH, it's almost certainly impossible to meet the version requirements with multiple distros (must land between the previous and the next)
[02:14] <Fujitsu> lamont: Multi-distro uploads need to build differently for each distro.
[02:14] <Fujitsu> Er, DistroSeries, that is.
[02:15] <lamont> (from the smash-it-into-multiple camp, all that has to happen is that the files in pool/$mumble have to be added to multiple Sources/Packages files, by way of being inserted into the database and propagated forward
[02:15] <lamont> Fujitsu: ah.  point.
[02:15] <Larose> Sorry if it's a little bit off-topic, but I have one more question, I did a kernel module package, I would like to distribute it (the .deb) to every debian-based distro, I mean, what should I write in the changelog for the distribution ? Anything I want, because I won't upload it to any package archive ?
[02:16] <lamont> the other way to do it is upload the source to the earliest, and then propagate it forward as though it were in the archive when the new distroseries opened.
[02:16]  * lamont has had this discussion before.
[02:16] <Fujitsu> lamont: Yes, but Soyuz can't do that.
[02:16] <lamont> either way, you don't upload with mutliple distroseries in the source.changes
[02:16] <Fujitsu> (for PPAs, that is)
[02:16] <lamont> Fujitsu: too true.  it requires archive-god foo
[02:16] <Fujitsu> I suspect it will reject horribly if you try.
[02:17] <Fujitsu> Good old initialize-from-parent.py.
[02:27] <ScottAS> Someone has creation an OpenPGP key using my Domain Name, I didn't create and I don't know what to do otherwise. I fear that there's nothing I can do because I can't revoke it myself.
[02:31] <Fujitsu> How relevant to this channel.
[02:31] <Fujitsu> And how devastatingly terrible.
[02:37] <lamont> (and that's why we have a web of trust... if no one trusted signs his key, then who cares...)
[02:39] <Fujitsu> Precisely.
[02:43] <Hobbsee> hum.  what does this "delete link" button do?
[02:44] <Fujitsu> Hobbsee: Other than being ugly, it deletes the packaging link.
[02:44] <Fujitsu> I'm not sure everybody should have that privilege, but they do.
[02:44] <Hobbsee> and where the heck is my mono now?
[02:44] <Hobbsee> Fujitsu: ah right.
[02:44] <Hobbsee> Fujitsu: yes, i was wondering about why i suddenly had that priveledge
[02:45] <Hobbsee> Fujitsu: as it is, i can't see how that relates to anything else, so it's rather useless in my case
[02:45] <Fujitsu> I suspect that ubuntu-dev should have that privilege, but not the whole world.
[02:45]  * Hobbsee presumes it makes sense where the upstream is also monitored in LP, or something
[02:46] <Fujitsu> It is used for when people try to file a bug on a project that doesn't use LP (it will ask them if they meant package X in Ubuntu, where X is any package with a link to that project).
[02:46] <Hobbsee> ah right
[02:46] <Fujitsu> Oh, and also when you hit `Also Affects: Project....'
[02:46]  * Hobbsee wonders why hte queue has now grown wider than her browser
[02:46] <Fujitsu> It will prefill that.
[02:46] <Hobbsee> ah right
[02:47] <Fujitsu> So it is useful.
[02:47] <Hobbsee> grrr
[02:47] <Fujitsu> And when NMSP comes around, with HCT and all... well, I won't bother going into that, as it won't happen.
[02:48] <lifeless> NMSP?
[02:48] <Fujitsu> NoMoreSourcePackages.
[02:48] <Hobbsee> n omroe source packages
[02:48] <Hobbsee> HCT?
[02:48] <Fujitsu> Hypothetical Changeset Tool, IIRC.
[02:49] <Hobbsee> how the heck do you know all this?
[02:49] <lifeless> right, just checking it was what I thought it was
[02:49] <lifeless> hadn't seen the abbreviation NMSP :)
[02:53] <Fujitsu> Hobbsee: I am God.
[02:53] <Fujitsu> Or I read specs and bugs. One of them.
[02:53] <Hobbsee> Fujitsu: right then.
[02:53] <Hobbsee> Fujitsu: you read the intros of specs.
[02:53] <Hobbsee> Fujitsu: and you appear to have far too much interest in soyuz ;P
[02:54] <lamont> lifeless: "Not My Stinking Problem"?
[02:55] <lamont> HCT is the most beautiful demo I ever saw.
[02:56] <lamont> Fujitsu: NMSP is very simple once the source is all committed to bzr (or whatever)
[02:57] <Fujitsu> lamont: As far as I can tell it's no longer on the immediate plans, but then again most things don't seem to be on the immediate plans.
[02:59] <jdub> jml: howdy
[03:00] <jml> jdub: hi
[03:00] <jml> what's up?
[03:00] <lamont> jdub!!! howdy!
[03:00] <jdub> hey lamont 
[03:01] <lamont> good to see you - long time no chat, etc... and back to our regularly scheduled program. :-)
[03:01] <jdub> jml: just figuring out if the question i wanted to ask is built on too many assumptions
[03:01] <jdub> jml: i'll start from the beginning
[03:02] <jdub> jml: there's a branch of drupal that doesn't appear to be registered in launchpad
[03:02] <jdub> actually, none other than 'head' (called 'main') appear to be
[03:02] <Fujitsu> That is all that is imported at this time.
[03:02] <jdub> should i register the branch, or does it need to be done via vcs-imports requests or something?
[03:03] <Fujitsu> I'm not sure there is a facility to perform multiple imports.
[03:03] <Fujitsu> Unless one was to create a new release series, perhaps.
[03:04] <jml> jdub: At the moment, we only import trunk (or equiv) from svn and cvs, afaik
[03:04] <jdub> https://launchpad.net/drupal/5.x <- "do not import"
[03:04] <Fujitsu> I've not seen a UI to do anything else.
[03:04] <jml> jdub: I might be wrong. The real experts on our code import stuff are on European times
[03:05] <jdub> so at least it has the right info
[03:05] <jdub> but there are probably "cvs is state of the ass technology" issues in the way :)
[03:05] <jml> almost certainly :)
[03:06] <jml> I guess the other branches on https://code.launchpad.net/drupal/ aren't relevant to this discussion?
[03:06] <jdub> nup
[03:08] <jdub> ok, thanks :-)
[03:08] <jml> so, there's this great distributed VCS that has good LP support that drupal might want to upgrade to :)
[03:08] <jml> jdub: np.
[03:09] <Fujitsu> bzr rocks, but few want to move :(
[03:09] <Hobbsee> when it works reliably for me every time, and quickly...
[03:09] <Fujitsu> It does for me.
[03:09] <jml> Hobbsee: it doesn't already?
[03:09] <gryc> yeah, the whole 'branching-taking-15-minutes-or-more' thing is a bit of a blocker
[03:10] <Fujitsu> Or the initial mplayer push to LP taking 4 hours, yeah. But bzr+ssh is making that better.
[03:10] <Hobbsee> although i may have used the wrong frontend (i think i used the http stuff, not the newer pull)
[03:10] <Hobbsee> Fujitsu: oh yeah, i think i uploaded that by accident, and didn't commit to bzr
[03:10] <jml> gryc: tried branching with 1.0?
[03:10] <lifeless> jml: need packs too :)
[03:10] <jml> lifeless: ahh, of course
[03:11] <gryc> jml: yes, and it's better, but it's still really slow :/
[07:34] <maarten_> Hi, I can't edit a bug I reported because I cannot get past the Logon page...?
[07:34] <Fujitsu> maarten_: Have you blocked cookies, by any chance?
[07:35] <maarten_> No, well, from some sites
[07:35] <Fujitsu> maarten_: How many times have you tried to log in?
[07:35] <maarten_> OK, thank you very much, for some reason launchpad was in the list of blocked sites.... sorry!@
[07:36] <Fujitsu> Aha.
[07:36] <Fujitsu> That's bug #30679: Launchpad should say it needs cookies.
[07:36] <ubotu> Launchpad bug 30679 in launchpad "Login requires cookies, but does not say so" [Medium,Confirmed] https://launchpad.net/bugs/30679 - Assigned to Matthew Paul Thomas (mpt)
[07:36] <maarten_> Many thanks for this!
[07:36] <Fujitsu> No problem.
[07:54] <carlos> morning
[08:12] <soren> Over the last few days, I've gotten e-mails about failed builds of open-vm-tools on powerpc, ia64, and lpia. However, p-a-s says only to build them on i386 and amd64.. What gives?
[08:20]  * Fujitsu thought we used Debian's P-a-s, and can't see any mention of open-vm-tools in his CVS emails going back many months.
[08:21] <thegodfather> Fujitsu: no, there are small differences here and there
[08:22] <Fujitsu> Why is there lpia stuff in Debian's, then?
[08:22] <Fujitsu> thegodfather: ^^
[08:23] <thegodfather> Fujitsu: afaik they try to keep it as synced as possible
[08:23] <thegodfather> tho things might have changed in time
[08:23] <thegodfather> it's even possible that LP broke with the last upgrade...
[08:24] <Fujitsu> Heh, wouldn't surprise me.
[08:25] <Fujitsu> Well, it's definitely still respecting P-a-s, so I guess we can safely assume that open-vm-tools isn't in it.
[08:25] <Fujitsu> Or drescher is out of date, perhaps. Maybe that broke.
[08:27] <Fujitsu> thegodfather: Why are you so godfatherly of late?
[08:28] <thegodfather> Fujitsu: for a change
[08:32] <mpt> Goooooooooooooooooood morning Launchpadders!
[08:32] <Fujitsu> Hey mpt.
[08:33] <Fujitsu> I just had to check my clock. No changing timezones, kthxbye.
[08:52] <mpt> I'm only half an hour earlier than I was yesterday
[08:52] <Fujitsu> I'm used to a `Go+d evening Launchpadders!' at this time, but I suppose I should get used to the opposite.
[10:58] <Fujitsu> Evening cprov.
[10:59] <cprov> Fujitsu: hi, good morning.
[12:17] <sivan> kiko: ping
[12:17] <kiko> ahoy
[12:18] <sivan> kiko: flouresde amazounica
[12:18] <sivan> :)
[12:18] <kiko> floresta
[13:31] <ubotu> New bug: #180075 in blueprint "duplicate email notifications on wiki page change" [Undecided,New] https://launchpad.net/bugs/180075
[13:47] <ardchoille> I asked a question here: https://answers.launchpad.net/launchpad/+question/20913  Was that the correct place to ask that type of question in order to have it seen by the proper person(s)?
[13:48] <Hobbsee> ardchoille: you got the right place
[13:48] <intellectronica> ardchoille: yes, that's fine. let me check if there's anyone around who can do that for you
[13:48] <ardchoille> Ah, great.
[14:26] <ubotu> New bug: #180083 in launchpad "Registering project with ID "favicon.ico" returns icon instead of project" [Undecided,New] https://launchpad.net/bugs/180083
[14:33] <kiko> heh
[14:33] <kiko> what a funny bug
[14:56] <ubotu> New bug: #180091 in blueprint "Blueprint notifications are sent by bounces@canonical.com" [Undecided,New] https://launchpad.net/bugs/180091
[15:04] <mpt> kiko, I aim to please :-)
[15:16] <ardchoille> To those of you who helped me with my issue in LP, you are very much appreciated :)
[15:19] <kiko> as the great mpt says, we aim to please!
[17:45] <ubotu> New bug: #180135 in malone "Boilerplate responses to duplicates waste time and hurt searching" [Undecided,New] https://launchpad.net/bugs/180135
[17:53] <mpt> cprov, why do people need to sign the CoC to upload to a PPA?
[17:54] <mpt> In other words, why isn't the PPA ToS enough?
[17:55] <cprov> mpt: no especial reason, we just want to get CoC  commitments from users. Why is that a problem ?
[17:56] <mpt> cprov, why do you want to get CoC commitments from users?
[17:56] <mpt> Are PPA users more likely to behave badly than users of other Launchpad features? :-)
[17:57] <cprov> mpt: yes, there is a higher chance to use launchpad to damage someone else's systems.
[17:58] <mpt> cprov, why don't the PPA Terms cover that?
[18:03] <cprov> mpt: well, I don't have a precise answer to this question, but why it should be covered by specified terms if it already covered in ubuntu CoC.  However I see it becoming a problem when we support PPA for other distributions.
[18:04] <mpt> agreed
[18:04] <mpt> ok, I'll report a bug on reducing the duplication
[18:07] <cprov> mpt: thanks
[18:16] <ubotu> New bug: #180143 in soyuz ""PPA uploads must be signed by an 'ubuntero'" isn't understandable" [Undecided,New] https://launchpad.net/bugs/180143
[18:43] <mathrick> hiya, it seems to me that all launchpad-hosted bzr branches are down
[18:43] <mathrick> or rather, launchpad gives links that result in 404
[18:43] <mathrick> for example, https://code.launchpad.net/~bzr/bzr-dbus/trunk
[18:43] <mathrick> links to http://bazaar.launchpad.net/~bzr/bzr-dbus/trunk which is 404
[18:44] <mathrick> but browsing at http://codebrowse.launchpad.net/~bzr/bzr-dbus/trunk/files works just fine
[18:46] <ubotu> New bug: #180151 in launchpad "team add member should include a link to the invited member" [Undecided,New] https://launchpad.net/bugs/180151
[19:25] <ubotu> New bug: #180161 in malone "'Assign to' should include drop-down with team members" [Undecided,New] https://launchpad.net/bugs/180161
[20:04] <Hattory> Hi all... When will the translations for hardy be available on lp?
[20:10]  * mpt wonders if "In Progress" could be renamed to "Underway"
[21:20] <Fujitsu> mpt: Trying to finally get them all to one word, I suppose?
[21:22] <mpt> Fujitsu, thinking about it, yeah
[21:22] <mpt> I think it would be enormous changes, though
[21:22] <mpt> e.g. merging Fix Committed + Fix Released = Fixed :-)
[21:25] <mpt> unless we had just "Committed" and "Released", but that probably wouldn't be understandable enough
[21:26] <kiko> that sounds like terms in a mental institution
[21:26] <thumper> kiko!
[21:26] <thumper> hello
[21:26] <kiko> heya thumper 
[21:26] <Fujitsu> mpt: I think the Commited/Released distinction is necessary
[21:26] <Fujitsu> *Committed
[21:27] <kiko> I think it's useful too fwiw
[21:27] <mpt> What for?
[21:27] <Fujitsu> If they're merged, what would I see when I go to a milestone page? Everything Underway until the release?
[21:28] <mpt> Milestone pages show all targeted bugs regardless of status anyway, don't they?
[21:29] <Fujitsu> They do.
[21:29] <Fujitsu> But how do I tell if something has actually been fixed yet, and is just awaiting rollout?
[21:30] <mpt> Depends what you mean by "rollout"
[21:30] <Fujitsu> Release of the version in which the fix will appear.
[21:31] <Fujitsu> (or perhaps cherrypicking, as seems to be necessary a lot in LP... /me waves to all (de|pro)moted arch: all binaries)
[21:31] <mpt> You can't tell that in current Launchpad anyway!
[21:31] <Fujitsu> Why not?
[21:32] <Fujitsu> If it's Fix Committed, I can be fairly sure the fix will be in the release to which it is targetted. Or their usage of LP is broken.
[21:32] <mpt> Because Ubuntu bugs are marked Fix Released without an Ubuntu version containing the fix being released.
[21:32] <Fujitsu> The version of the package is released, but you're right.
[21:33] <Fujitsu> It would be a useful distinction to make, but until we get mass-editing (which seems to keep getting hit with the deferring stick), version tracking, or something else, it's not practical.
[21:33] <mpt> It's not "released" in any sense meaningful to the people running Ubuntu 7.10 and reporting bugs about what they encounter in it. (Unless the fix is backported, but most fixes aren't.)
[21:34] <mpt> Fujitsu, right, that's what I thought when designing them originally
[21:34] <mpt> Ubuntu would be able to mass-change Fix Committed bugs to Fix Released on release day, and everything would be groovy
[21:34] <Fujitsu> Exactly.
[21:34] <mpt> I didn't realize mass-changing wouldn't be implemented for another N years
[21:34] <mpt> but, but
[21:34] <Fujitsu> Heh.
[21:35] <mpt> even when mass changing is implemented, I *still* don't think it will be practical.
[21:35] <Fujitsu> Why not?
[21:36] <mpt> Partly because it would be too much bugmail at once
[21:37] <mpt> And partly because it would work only as long as we're developing one version at a time, which may be true now, but may not be a few years hence
[21:37] <Fujitsu> Perhaps.
[21:37] <Fujitsu> In which case we need version tracking.
[21:37] <mpt> right
[21:37] <Fujitsu> Which is always good anyway.
[21:38] <mpt> So I propose replacing Fix Released with a field for which version(s?) the bug is fixed in.
[21:38] <Fujitsu> That sounds very good.
[21:40] <Fujitsu> Hm, that could get a bit messy, actually...
[21:41] <Fujitsu> Well, for SPRS you'd probably have to also show the DistroSeries in which the SPR first appeared, as the package version alone isn't a whole lot of use, as it's not released independently.
[21:42] <Fujitsu> But it does sound like a much better way to do it.
[21:42]  * mpt reads through bugmail
[21:42] <mpt> Fujitsu, you're getting good at marking duplicates :-)
[21:42] <mpt> (in bugs about Launchpad itself, I mean)
[21:42]  * Fujitsu knows whether most LP bugs exist.
[21:43] <mpt> What's an SPR?
[21:43] <mpt> oh, SourcePackageRelease
[21:43] <Fujitsu> Sorry, yes.
[21:48]  * Fujitsu wonders how exactly the enormous architecture-independent binary domination regression managed to not fail any tests.
[21:53] <geser> is it be possible to recover the lost packages or is a new upload necessary?
[21:54] <Fujitsu> They're still in librarian, so I presume they should be revivable. cprov? ^^
[21:55] <cprov> Fujitsu: I'm working on it ...
[21:55] <Fujitsu> cprov: They won't require a new upload?
[21:56] <cprov> Fujitsu: now, if you provide a list of binaries that have vanished since 20th Dec I can republish them
[21:57] <Fujitsu> Can't you fairly easily perform a query for superseded SPRs that are for published sources? Or look in the logs? Having someone else create a list manually sounds like it's going to miss things.
[21:59] <cprov> Fujitsu: ok, don't worry, I can do it myself.
[22:00] <Fujitsu> I guess this is one situation where the bug trail that we're meant to leave would be useful, but at least some of the component changes were performed without bugs.
[22:02] <cprov> Fujitsu: no, all arch-indep override since 20th vanished the binary from the archive, arch-specific overrides works
[22:03] <Fujitsu> I am aware.
[22:05] <cprov> Fujitsu: shouldn't be difficult to trace, till tomorrow better postpone such actions.
[22:06] <cprov> I have to go away for a bit, brb
[22:06] <Fujitsu> OK, thanks.
[22:06] <geser> cprov: libcommons-httpclient-java survived it but not libcommons-httpclient-java-doc
[22:06] <geser> and libcommons-httpclient-java is arch:all
[22:07] <Fujitsu> That's not encouraging.
[22:09] <geser> cprov: here is a list of packages which are missing after bug #176139 got fixed: libavalon-framework-java libavalon-framework-java-doc libcommons-httpclient-java-doc libjunitperf-java libjunitperf-java-doc libi18n-java libjazzy-java libjcalendar-java libjcalendar-java-doc libnsuml-java libsaxon-java libsaxon-java-doc libtoolbar-java
[22:09] <ubotu> Launchpad bug 176139 in libtoolbar-java "Please move package to universe" [Wishlist,Fix released] https://launchpad.net/bugs/176139
[22:09] <mpt> See y'all in 10 hours or so
[22:12] <Fujitsu> geser: libcommons-httpclient-java looks to have already been in universe.
[22:16] <geser> ah, that explains it
[22:19] <Fujitsu> So it was saved by someone NEWing it incorrectly.
[22:20] <ubotu> New bug: #180210 in malone "Launchpad doesn't parse RT URLs correctly for cpan.org" [High,New] https://launchpad.net/bugs/180210
[23:08] <yeager> any admins here?
[23:09] <yeager> is there any need for any reverse proxies in the LP solution?
[23:10] <yeager> i recently started to work for Blue Coat Systems
[23:10] <yeager> maybe I can pulls some strings to borrow you guys a box or two
[23:31] <ubotu> New bug: #180218 in soyuz "override mismatch race needs to be fixed" [Undecided,New] https://launchpad.net/bugs/180218