[00:35] New bug: #179983 in malone "SVGZ doesn't have the good encoding" [Undecided,New] https://launchpad.net/bugs/179983 === \sh is now known as \sh_away [01:51] 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 ? === bigon is now known as bigon` [01:52] 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] and change the "{gutsy, festy, ...}" in the debian/changelog ? [02:06] Larose: Yes, sorry. [02:08] Hello All. Could someone help me with a problem? [02:08] 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] Fujitsu: I don't understand the ~*** [02:09] Fujitsu: Is it documented ? [02:10] Larose: It's probably not documented anywhere, though it has been referred to on launchpad-users a couple of times lately. [02:10] In a Debian version, `~' is less than anything, even `' [02:10] well, ok [02:10] 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] It means users can upgrade properly. [02:10] Larose: it's documented somewhere... ~ is less than null [02:11] hrm.. like Fujitsu said [02:12] Larose: and multiple distro source uploads have historically been an interestingly not-quite-what-you-think situation. even in debian. [02:12] and it looks like launchpad doesn't believe in it [02:12] lamont: It's not possible to do with a pool. [02:13] 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] lamont: Multi-distro uploads need to build differently for each distro. [02:14] Er, DistroSeries, that is. [02:15] (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] Fujitsu: ah. point. [02:15] 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] 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] lamont: Yes, but Soyuz can't do that. [02:16] either way, you don't upload with mutliple distroseries in the source.changes [02:16] (for PPAs, that is) [02:16] Fujitsu: too true. it requires archive-god foo [02:16] I suspect it will reject horribly if you try. [02:17] Good old initialize-from-parent.py. [02:27] 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] How relevant to this channel. [02:31] And how devastatingly terrible. [02:37] (and that's why we have a web of trust... if no one trusted signs his key, then who cares...) [02:39] Precisely. [02:43] hum. what does this "delete link" button do? [02:44] Hobbsee: Other than being ugly, it deletes the packaging link. [02:44] I'm not sure everybody should have that privilege, but they do. [02:44] and where the heck is my mono now? [02:44] Fujitsu: ah right. [02:44] Fujitsu: yes, i was wondering about why i suddenly had that priveledge [02:45] Fujitsu: as it is, i can't see how that relates to anything else, so it's rather useless in my case [02:45] 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] 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] ah right [02:46] 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] It will prefill that. [02:46] ah right [02:47] So it is useful. [02:47] grrr [02:47] And when NMSP comes around, with HCT and all... well, I won't bother going into that, as it won't happen. [02:48] NMSP? [02:48] NoMoreSourcePackages. [02:48] n omroe source packages [02:48] HCT? [02:48] Hypothetical Changeset Tool, IIRC. [02:49] how the heck do you know all this? [02:49] right, just checking it was what I thought it was [02:49] hadn't seen the abbreviation NMSP :) [02:53] Hobbsee: I am God. [02:53] Or I read specs and bugs. One of them. [02:53] Fujitsu: right then. [02:53] Fujitsu: you read the intros of specs. [02:53] Fujitsu: and you appear to have far too much interest in soyuz ;P [02:54] lifeless: "Not My Stinking Problem"? [02:55] HCT is the most beautiful demo I ever saw. [02:56] Fujitsu: NMSP is very simple once the source is all committed to bzr (or whatever) [02:57] 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] jml: howdy [03:00] jdub: hi [03:00] what's up? [03:00] jdub!!! howdy! [03:00] hey lamont [03:01] good to see you - long time no chat, etc... and back to our regularly scheduled program. :-) [03:01] jml: just figuring out if the question i wanted to ask is built on too many assumptions [03:01] jml: i'll start from the beginning [03:02] jml: there's a branch of drupal that doesn't appear to be registered in launchpad [03:02] actually, none other than 'head' (called 'main') appear to be [03:02] That is all that is imported at this time. [03:02] should i register the branch, or does it need to be done via vcs-imports requests or something? [03:03] I'm not sure there is a facility to perform multiple imports. [03:03] Unless one was to create a new release series, perhaps. [03:04] jdub: At the moment, we only import trunk (or equiv) from svn and cvs, afaik [03:04] https://launchpad.net/drupal/5.x <- "do not import" [03:04] I've not seen a UI to do anything else. [03:04] jdub: I might be wrong. The real experts on our code import stuff are on European times [03:05] so at least it has the right info [03:05] but there are probably "cvs is state of the ass technology" issues in the way :) [03:05] almost certainly :) [03:06] I guess the other branches on https://code.launchpad.net/drupal/ aren't relevant to this discussion? [03:06] nup [03:08] ok, thanks :-) [03:08] so, there's this great distributed VCS that has good LP support that drupal might want to upgrade to :) [03:08] jdub: np. [03:09] bzr rocks, but few want to move :( [03:09] when it works reliably for me every time, and quickly... [03:09] It does for me. [03:09] Hobbsee: it doesn't already? [03:09] yeah, the whole 'branching-taking-15-minutes-or-more' thing is a bit of a blocker [03:10] Or the initial mplayer push to LP taking 4 hours, yeah. But bzr+ssh is making that better. [03:10] although i may have used the wrong frontend (i think i used the http stuff, not the newer pull) [03:10] Fujitsu: oh yeah, i think i uploaded that by accident, and didn't commit to bzr [03:10] gryc: tried branching with 1.0? [03:10] jml: need packs too :) [03:10] lifeless: ahh, of course [03:11] jml: yes, and it's better, but it's still really slow :/ === Ubulette_ is now known as Ubulette [07:34] Hi, I can't edit a bug I reported because I cannot get past the Logon page...? [07:34] maarten_: Have you blocked cookies, by any chance? [07:35] No, well, from some sites [07:35] maarten_: How many times have you tried to log in? [07:35] OK, thank you very much, for some reason launchpad was in the list of blocked sites.... sorry!@ [07:36] Aha. [07:36] That's bug #30679: Launchpad should say it needs cookies. [07:36] 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] Many thanks for this! [07:36] No problem. [07:54] morning === doko_ is now known as doko [08:12] 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? === bigon` is now known as bigon [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] Fujitsu: no, there are small differences here and there [08:22] Why is there lpia stuff in Debian's, then? [08:22] thegodfather: ^^ [08:23] Fujitsu: afaik they try to keep it as synced as possible [08:23] tho things might have changed in time [08:23] it's even possible that LP broke with the last upgrade... [08:24] Heh, wouldn't surprise me. [08:25] 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] Or drescher is out of date, perhaps. Maybe that broke. [08:27] thegodfather: Why are you so godfatherly of late? [08:28] Fujitsu: for a change [08:32] Goooooooooooooooooood morning Launchpadders! [08:32] Hey mpt. [08:33] I just had to check my clock. No changing timezones, kthxbye. [08:52] I'm only half an hour earlier than I was yesterday [08:52] I'm used to a `Go+d evening Launchpadders!' at this time, but I suppose I should get used to the opposite. === stu1 is now known as stub === cprov-out is now known as cprov [10:58] Evening cprov. [10:59] Fujitsu: hi, good morning. === \sh_away is now known as \sh [12:17] kiko: ping [12:17] ahoy [12:18] kiko: flouresde amazounica [12:18] :) [12:18] floresta === sivan is now known as sivang [13:31] New bug: #180075 in blueprint "duplicate email notifications on wiki page change" [Undecided,New] https://launchpad.net/bugs/180075 === bigon is now known as bigon` === bigon` is now known as bigon [13:47] 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] ardchoille: you got the right place [13:48] ardchoille: yes, that's fine. let me check if there's anyone around who can do that for you [13:48] Ah, great. === \sh is now known as \sh_away === keffie_jayx is now known as effie_jayx [14:26] New bug: #180083 in launchpad "Registering project with ID "favicon.ico" returns icon instead of project" [Undecided,New] https://launchpad.net/bugs/180083 === matsubara is now known as matsubara-lunch [14:33] heh [14:33] what a funny bug === cprov is now known as cprov-lunch [14:56] New bug: #180091 in blueprint "Blueprint notifications are sent by bounces@canonical.com" [Undecided,New] https://launchpad.net/bugs/180091 [15:04] kiko, I aim to please :-) [15:16] To those of you who helped me with my issue in LP, you are very much appreciated :) [15:19] as the great mpt says, we aim to please! === salgado is now known as salgado-lunch === salgado-lunch is now known as salgado === neversfelde_ is now known as neversfelde === \sh_away is now known as \sh [17:45] New bug: #180135 in malone "Boilerplate responses to duplicates waste time and hurt searching" [Undecided,New] https://launchpad.net/bugs/180135 [17:53] cprov, why do people need to sign the CoC to upload to a PPA? [17:54] In other words, why isn't the PPA ToS enough? [17:55] mpt: no especial reason, we just want to get CoC commitments from users. Why is that a problem ? [17:56] cprov, why do you want to get CoC commitments from users? [17:56] Are PPA users more likely to behave badly than users of other Launchpad features? :-) [17:57] mpt: yes, there is a higher chance to use launchpad to damage someone else's systems. [17:58] cprov, why don't the PPA Terms cover that? [18:03] 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] agreed [18:04] ok, I'll report a bug on reducing the duplication [18:07] mpt: thanks [18:16] New bug: #180143 in soyuz ""PPA uploads must be signed by an 'ubuntero'" isn't understandable" [Undecided,New] https://launchpad.net/bugs/180143 === neversfelde_ is now known as neversfelde [18:43] hiya, it seems to me that all launchpad-hosted bzr branches are down [18:43] or rather, launchpad gives links that result in 404 [18:43] for example, https://code.launchpad.net/~bzr/bzr-dbus/trunk [18:43] links to http://bazaar.launchpad.net/~bzr/bzr-dbus/trunk which is 404 [18:44] but browsing at http://codebrowse.launchpad.net/~bzr/bzr-dbus/trunk/files works just fine [18:46] 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] New bug: #180161 in malone "'Assign to' should include drop-down with team members" [Undecided,New] https://launchpad.net/bugs/180161 === meduxa is now known as toscalix [20:04] Hi all... When will the translations for hardy be available on lp? === \sh is now known as \sh_away [20:10] * mpt wonders if "In Progress" could be renamed to "Underway" === sivan is now known as sivang [21:20] mpt: Trying to finally get them all to one word, I suppose? [21:22] Fujitsu, thinking about it, yeah [21:22] I think it would be enormous changes, though [21:22] e.g. merging Fix Committed + Fix Released = Fixed :-) [21:25] unless we had just "Committed" and "Released", but that probably wouldn't be understandable enough [21:26] that sounds like terms in a mental institution [21:26] kiko! [21:26] hello [21:26] heya thumper [21:26] mpt: I think the Commited/Released distinction is necessary [21:26] *Committed [21:27] I think it's useful too fwiw [21:27] What for? [21:27] If they're merged, what would I see when I go to a milestone page? Everything Underway until the release? [21:28] Milestone pages show all targeted bugs regardless of status anyway, don't they? [21:29] They do. [21:29] But how do I tell if something has actually been fixed yet, and is just awaiting rollout? [21:30] Depends what you mean by "rollout" [21:30] Release of the version in which the fix will appear. [21:31] (or perhaps cherrypicking, as seems to be necessary a lot in LP... /me waves to all (de|pro)moted arch: all binaries) [21:31] You can't tell that in current Launchpad anyway! [21:31] Why not? [21:32] 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] Because Ubuntu bugs are marked Fix Released without an Ubuntu version containing the fix being released. [21:32] The version of the package is released, but you're right. [21:33] 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] 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] Fujitsu, right, that's what I thought when designing them originally [21:34] Ubuntu would be able to mass-change Fix Committed bugs to Fix Released on release day, and everything would be groovy [21:34] Exactly. [21:34] I didn't realize mass-changing wouldn't be implemented for another N years [21:34] but, but [21:34] Heh. [21:35] even when mass changing is implemented, I *still* don't think it will be practical. [21:35] Why not? [21:36] Partly because it would be too much bugmail at once [21:37] 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] Perhaps. [21:37] In which case we need version tracking. [21:37] right [21:37] Which is always good anyway. [21:38] So I propose replacing Fix Released with a field for which version(s?) the bug is fixed in. [21:38] That sounds very good. [21:40] Hm, that could get a bit messy, actually... [21:41] 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] But it does sound like a much better way to do it. [21:42] * mpt reads through bugmail [21:42] Fujitsu, you're getting good at marking duplicates :-) [21:42] (in bugs about Launchpad itself, I mean) [21:42] * Fujitsu knows whether most LP bugs exist. [21:43] What's an SPR? [21:43] oh, SourcePackageRelease [21:43] Sorry, yes. [21:48] * Fujitsu wonders how exactly the enormous architecture-independent binary domination regression managed to not fail any tests. [21:53] is it be possible to recover the lost packages or is a new upload necessary? [21:54] They're still in librarian, so I presume they should be revivable. cprov? ^^ [21:55] Fujitsu: I'm working on it ... [21:55] cprov: They won't require a new upload? [21:56] Fujitsu: now, if you provide a list of binaries that have vanished since 20th Dec I can republish them [21:57] 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] Fujitsu: ok, don't worry, I can do it myself. [22:00] 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] Fujitsu: no, all arch-indep override since 20th vanished the binary from the archive, arch-specific overrides works [22:03] I am aware. [22:05] Fujitsu: shouldn't be difficult to trace, till tomorrow better postpone such actions. [22:06] I have to go away for a bit, brb [22:06] OK, thanks. === cprov is now known as cprov-away [22:06] cprov: libcommons-httpclient-java survived it but not libcommons-httpclient-java-doc [22:06] and libcommons-httpclient-java is arch:all [22:07] That's not encouraging. [22:09] 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] Launchpad bug 176139 in libtoolbar-java "Please move package to universe" [Wishlist,Fix released] https://launchpad.net/bugs/176139 [22:09] See y'all in 10 hours or so [22:12] geser: libcommons-httpclient-java looks to have already been in universe. [22:16] ah, that explains it [22:19] So it was saved by someone NEWing it incorrectly. [22:20] New bug: #180210 in malone "Launchpad doesn't parse RT URLs correctly for cpan.org" [High,New] https://launchpad.net/bugs/180210 === gryc is now known as grycAFK === grycAFK is now known as gryc === bigon is now known as bigon` === bigon` is now known as bigon [23:08] any admins here? [23:09] is there any need for any reverse proxies in the LP solution? [23:10] i recently started to work for Blue Coat Systems [23:10] maybe I can pulls some strings to borrow you guys a box or two [23:31] New bug: #180218 in soyuz "override mismatch race needs to be fixed" [Undecided,New] https://launchpad.net/bugs/180218