[02:55] <poolie> hi
[02:55] <jjesse> hello
[02:55] <poolie> i need to take over maintainership of a project whose owner is sick/uncontactable
[02:55] <poolie> is there a way to do this?
[02:55] <poolie> hi jjesse
[02:55] <poolie> i guess open a ticket?
[03:01] <mwhudson> poolie: yes
[03:01] <poolie> hm
[03:02] <poolie> "help improve launchpad" is not so great
[03:02] <poolie> s//such a great label/
[03:02] <poolie> what if i want help myself?
[03:02] <poolie> :)
[03:02] <lifeless> poolie: what project
[03:03] <poolie> bzr-usertest
[03:03] <lifeless> you need to take it over? its in the bazaar group already, you should be able to do most things to it as-is
[03:04] <poolie> hm
[03:05] <poolie> it is in the bazaar project group
[03:05] <poolie> that does not seem to give me any access though
[03:05] <poolie> like to change bug priority
[03:05] <lifeless> hmm,
[03:05] <lifeless> no bug supervisor set
[03:05] <lifeless> I thought that that inherited
[03:05] <lifeless> I've set the bug supervisor to bzr
[03:06] <poolie> !
[03:06] <poolie> i will later want to change the trunk too
[03:07] <poolie> did you use superpowers to change that?
[03:08] <lifeless> yes
[03:09] <poolie> out of curiousity through the db or the ui?
[03:09] <lifeless> ui
[03:10] <lifeless> doing stuff in the db -> not recommended
[03:10] <lifeless> if you do need to take over the project, I can do that, but prefer not to - its better if you can get in contact with the current owner
[03:10] <lifeless> I figure the bug supervisor thing isn't contentious
[03:11] <lifeless> isn't likely to be, that is
[03:46] <IntuitiveNipple> Anyone know how to prevent a PPA build on lpia when the package architecture only specifies i386 amd64 ?
[03:48] <persia> IntuitiveNipple: Why would you want to specifically block a build on lpia?
[03:48] <persia> (and yes, it fails if the architecture only specifies i386 and amd64)
[03:49] <IntuitiveNipple> persia: kvm and libsmbios always fail on lpia but they're only for i386 amd64 ia64
[03:49] <persia> Right.  Have you tried adding lpia to the list of architectures?
[03:50] <persia> (admittedly most lpia HW doesn't support VMX, but I have seen at least one chip that did)
[03:50] <IntuitiveNipple> Hmmm... no... the idea is not to build for lpia at all :)
[03:50] <persia> Right, that's the idea I don't understand.  Why shouldn't libsmbios work on lpia?
[03:50]  * persia knows about kvm, and suspects that while it's mostly useless on most real lpia HW, it should build and install)
[03:51] <IntuitiveNipple> well, the original authors have specified just the three architectures I mentioned... I didn't want to mess with it :)
[03:52] <persia> I bet it works.  The differences between lpia and i386 are less than the differences between i386 and amd64.
[03:52] <IntuitiveNipple> I guess I could *try* it ... at least those horrible red crosses will disappear :)
[03:53] <IntuitiveNipple> Well yes... I just didn't want to alter the packages more than necessary. I'm mainly building up-to-the-minute package for hardy from upstream or intrepid.
[03:53] <persia> IntuitiveNipple: Ah.  Nice to fix that in intrepid then.  I don't know what depends upon those, but they really ought to work for lpia.
[03:54] <IntuitiveNipple> I'll upload another version with lpia added and see what happens
[03:55] <lifeless> lpia is less an architecture than a profile for i386
[03:56] <IntuitiveNipple> There was a nasty bug in kvm-72 that I blamed on virt-manager :) It caused all grub installer actions to fail, and stopped XP rebooting
[03:56] <IntuitiveNipple> So I've put the fix up and wanted the builds to look all good with green ticks :p
[04:01] <IntuitiveNipple> The lpia build failure for kvm-72 is weird, anyone seen this before...
[04:01] <IntuitiveNipple> mv: cannot move `/build/buildd/kvm-72+dfsg/debian/tmp/usr/bin/' to a subdirectory of itself, `/build/buildd/kvm-72+dfsg/debian/tmp/usr/bin/kvm'
[04:04] <IntuitiveNipple> Looks like some serious work needed to make lpia builds of kvm work... the embedded qemu source creates build architecture-specific directories and code based on shell vars... in the case of lpia no shell var exists therefore the 'mv' source is the base-path with no extension
[04:05] <persia> Strange.  I just built qemu for lpia yesterday.
[04:06] <persia> https://launchpad.net/ubuntu/intrepid/+source/qemu/0.9.1-5ubuntu2
[04:06] <IntuitiveNipple> It looks to be because it doesn't create a qemu-system-lpia binary
[04:07]  * persia suspects another forum is more appropriate: perhaps #ubuntu-virt ?
[04:07] <IntuitiveNipple> indeed :p
[07:08] <\sh> anyone who is able to enlighten me of the new license of the new LP logo?
[07:14] <thumper> \sh: it is specified in https://help.launchpad.net/Legal
[07:14] <thumper> \sh: which is linked from the LP footer
[07:14] <\sh> kiko-zzz: when you are awake...I'm at my desk (somehow)from 06:00 UTC to 15:00 UTC (+/- one hour)
[07:14] <spiv> \sh: what do you want to know?  There was an email to the launchpad-users list saying it that is licensed as CC-BY-ND, IIRC.
[07:14] <spiv> As thumper says, the legal page should have all the info.
[07:15] <\sh> spiv: yes..that's why...the leonov logo was created with the new logo before it was licensed with CC-BY-ND...I need to know if we need a new one, or at least the info where can I ask for an exception so that leonov can use the base
[07:16] <spiv> \sh: I'd talk to kiko
[07:16] <spiv> \sh: (although if there is a problem, then it was already a problem when the logo wasn't licensed at all...)
[07:17] <\sh> spiv: well, I want to be sure, that everything is correct...not to run into legal problems :) I'll try to catch kiko when he's awake ...
[07:18] <\sh> now for some daily morning meetings and some coffee...laters
[09:35] <wgrant> bigjools: I take it you found a reasonably easy fix for #159304, then?
[09:36] <bigjools> wgrant: not easy but done nonethless
[11:08] <viciouslime> hi, does anyone know how I can delete milestones from a branch?
[11:11] <kiko-zzz> viciouslime, do you mean from a series? you need to request that through answers.launchpad.net/launchpad
[11:12] <viciouslime> kiko-zzz: thanks :) I'll do that
[11:17] <kiko-zzz> you're welcome
[11:31] <persia> bigjools: How is "Maintained" packages calculated on dogfood?  The number seems high.
[11:33] <bigjools> persia: it's where the user appears in the Mainainter tag on the source package
[11:35] <persia> bigjools: Interesting.  One of your examples seems to do things differently than many of us.
[11:35] <persia> Also, since we're tracking uploads (which I like), maybe s/packages/uploads/ in the explanatory text?
[11:35] <bigjools> persia: how do you mean?
[11:36] <persia> bigjools: Most of use will use Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com> or Ubuntu MOTU Developers <ubuntu-motu@lsits.ubuntu.com> for ubuntu-specific uploads.  Your first example doesn't do that.
[11:37] <bigjools> that's how it's always been on that page (even before it was broken)
[11:37] <wgrant> So PPA packages aren't uploaded nor maintained?
[11:38] <bigjools> in Ubuntu, no
[11:38] <wgrant> Right, but it doesn't exactly say that.
[11:38] <wgrant> But looking much better in general.
[11:39] <bigjools> great
[11:39] <bigjools> this is pretty much what I will release for now, barring any serious issues
[11:40] <persia> I miss pre-Dapper package history, but that's not typically relevant for any of my non-vanity use cases.
[11:40] <bigjools> if there are any more things you would like to see differently, please file bugs and we can do that separately
[11:40] <wgrant> So it still doesn't show superseded SPRs?
[11:40] <persia> Right.  Nvaigation needs work, but mpt was already on about that.
[11:40] <persia> wgrant: It shows Edgy, but not Breezy (at least for ~persia)
[11:40] <wgrant> 'Displaying first 30 packages out of 726 total
[11:41] <wgrant> That sounds a little strange.
[11:41] <wgrant> Is there no text in a similar position elsewhere in Launchpad?
[11:41] <persia> Because of the work "packages" or because of something else?
[11:41] <wgrant> I'm not sure.
[11:41] <wgrant> 'out of', maybe.
[11:41] <bigjools> the lists only show items that are actually published
[11:42] <wgrant> Right, that's probably a bad idea.
[11:42] <bigjools> it's something that we could add extra filtering for on the batched listings
[11:43] <wgrant> Why make the distinction about published/unpublished?
[11:43] <bigjools> I am just wary of changing something that's clearly been that way for a long time
[11:43] <wgrant> I don't think anybody actually likes it that way.
[11:44] <persia> bigjools: Is it harder to get the data for the now obsolete releases?
[11:45] <bigjools> no, the distroseries state does not enter the (current) query, it's purely done on whether the package is published
[11:45] <wgrant> Doesn't that implicitly unpublish the SPPs, though?
[11:46] <bigjools> no, the same package could be published in another series
[11:46] <bigjools> if it's not, then the package is obsoleted, yes
[11:46] <wgrant> Well, once all SPPs for a SPR are unpublished, the SPR will vanish from that page. That's what I meant.
[11:46] <bigjools> correct
[11:47] <bigjools> so would it be more useful to show *all* packages, regardless of state?
[11:47] <wgrant> I think so.
[11:47] <wgrant> Now it's batched there shouldn't be a problem.
[11:47] <bigjools> I can tweak it on dogfood right now, just a sec
[11:47] <wgrant> persia: What do you think?
[11:47] <bigjools> let's see what happens
[11:48] <persia> I'd be personally happy with *all* packages, regardless of state, but as I said, it's only for vanity use cases.
[11:49] <wgrant> At the moment, if somebody only cares about N packages, but cares about them a lot, they only get N uploads shown.
[11:50] <bigjools> ok, it's showing a lot more packages now
[11:51] <wgrant> Indeed it is.
[11:51] <wgrant> I must have uploaded an awful lot in Edgy.
[11:52] <wgrant> Or multiple times in one series, I guess.
[11:52] <persia> I had Edgy showing in my results before
[11:52] <wgrant> Maintained packages is still broken, but that might make more sense like that.
[11:52] <wgrant> persia: Probably because it has SPPs in other distroseries.
[11:53] <wgrant> persia: It will show the series in which it was originally uploaded, not where it is currently published.
[11:53] <persia> wgrant: Ah, quite possibly: it may have shipped also in Feisty.
[11:56] <persia> Hmm.  I'm still only seeing one entry per source per release.  Am I missing something?
[11:56] <emgent> Rinchen: around ?
[11:56] <wgrant> Ooh.
[11:56] <wgrant> You import Lenny on dogfood?
[11:57] <wgrant> I was looking for sid instead.
[11:57] <persia> Hmm.  Finally found 1 Breezy package.
[11:57] <wgrant> persia: Must be published in Dapper.
[11:58] <persia> I'm also certain that the numbers are off: e.g. dholbach had > 140 packages uploaded in Feisty, but it only shows 155 across all releases for him.
[11:59] <wgrant> persia: 'Displaying first 30 packages out of 779 total
[11:59] <wgrant> That's for dholbach.
[12:01] <wgrant> Is it deliberate that I'm not shown as both uploading and maintaining a package?
[12:02] <persia> wgrant: Hmm.  I wonder how I got my result, but refreshing shows me yours.
[12:03] <wgrant> Interesting indeed.
[12:05] <bigjools> wgrant: yes that's deliberate
[12:08] <wgrant> bigjools: Seems a but strange, but OK.
[12:08] <wgrant> *bit
[12:08] <bigjools> I don't know why that's done like that, I just looked at the code
[12:09] <wgrant> Heh.
[12:12] <bigjools> wgrant: ah it might be to filter syncs
[12:14] <wgrant> Manual syncs should show up as an upload, and autosyncs are owned by katie. What do you mean?
[12:14] <bigjools> where the maintainer is not the uploader
[12:15] <bigjools> and we're interested in who uploaded it
[12:15] <wgrant> Right.
[12:16] <wgrant> But you filter things that I have uploaded but where I am the maintainer too.
[12:16] <bigjools> really?  got an example?
[12:18] <wgrant> https://dogfood.launchpad.net/~wgrant/+uploaded-packages lacks soundconverter 1.2.0-0ubuntu1
[12:18] <wgrant> https://dogfood.launchpad.net/~wgrant/+maintained-packages has it.
[12:18] <wgrant> And I'm in the Changed-By.
[12:22] <wgrant> There are also inconsistencies in the text when somebody has uploaded nothing.
[12:22] <wgrant> For the package pages, the username is used. +related-projects and everywhere else in the UI uses display name.
[12:23] <wgrant> 'has no maintained packages' -> 'maintains no packages'
[12:23] <bigjools> wgrant: right that's deliberate - the uploaded packages section only contains those where you're *only* the uploader
[12:23] <wgrant> 'has no uploaded packages' -> 'has uploaded no packages'
[12:23] <wgrant> bigjools: Seems a bit odd...
[12:23] <wgrant> It would make sense in Debian.
[12:24] <bigjools> maybe it should be renamed to "Sponsored uploads"
[12:24] <wgrant> Except that's not it at all.
[12:25] <wgrant> That's another section that we need, though.
[12:25] <wgrant> Well, s/we need/would be nice/
[12:25] <wgrant> The intersection between that and anything else on the page would be {}, though.
[12:26] <persia> Not necessarily: one could sponsor an upload to a package one maintains.
[12:26] <wgrant> persia: GOod point.
[12:27] <persia> Note that for the hypothetical "Sponsored Uploads", we're not interested in cases where Changed-By: and .changes signer are the same.
[12:28] <persia> Actually, is there already a bug for "Sponsored Uploads"?  I've a use case that might make it interesting (although not essential).
[12:31] <bigjools> wgrant: thanks for pointing out those other inconsistencies
[12:32] <wgrant> persia: I think there might be.
[12:33]  * persia will search later.
[12:33] <wgrant> But it might be in a comment in one of the other bugs.
[12:33] <wgrant> bigjools: It's one of the things I do best.
[12:33] <bigjools> wgrant: I'll bear that in mind :)
[12:34] <wgrant> Is there a timeframe for Soyuz to grow full rebuild support?
[12:35] <bigjools> wgrant: define "full"
[12:35] <bigjools> we do plan on doing rebuilds this year
[12:35] <wgrant> Able to rebuild universe.
[12:35] <bigjools> but not the "scorched earth" type
[12:35] <wgrant> And give us results.
[12:35] <persia> bigjools: Does that mean complete archive rebuild on import from the previous release series, or just button-push rebuild?
[12:36] <wgrant> bigjools: Right, we've never expected more than that, I don't think.
[12:36] <bigjools> the latter for now
[12:36] <bigjools> but
[12:37] <persia> ...
[12:37] <bigjools> we're working on a spec that introduces derivative archive support so you can clone an archive (in part or full) and rebuild a selection of packages
[12:37] <wgrant> Isn't that what a rebuild archive basically is, anyway?
[12:37] <bigjools> yes - we've just made it generic
[12:37] <bigjools> so the same code can be used for other purposes
[12:37] <wgrant> Good to know.
[12:37] <persia> bigjools: Any chance that it could be organised in such a way to allow something like a "test-rebuild-everything" feature?
[12:38] <wgrant> Easy enough to do with appropriate ogreing.
[12:38] <persia> My fear is that it would be abused to do archive-test-rebuilds on Ubuntu, and presumably you'd only want that once in a while.
[12:39] <persia> Having an official "test-rebuilds" feature probably avoids that, although it may not be signfiicantly different in implementation.
[12:39] <bigjools> persia: I guess if all packages are selected we'll be able to rebuild everything, but obviously there's issues around bootstrapping
[12:40] <persia> bigjools: Understood.  I'm just thinking that you'll want to have an official "Ubuntu rebuild test" section so you don't end up with twelve.
[12:41] <bigjools> yeah this sort of thing is under discussion.  The spec is here although it's a bit bare to non-Canonical people: https://blueprints.edge.launchpad.net/soyuz/+spec/archive-derivatives
[12:42]  * bigjools -> food
[12:45] <wgrant> bigjools: I think we're used to that by now.
[12:48] <persia> bigjools: Just out of curiosity, why would you want to disallow direct uploads?
[12:48] <persia> I know at least the Ubuntu Desktop Japanese Remix and BlankOn would like to support that, rather than uploading to a PPA and copying the packages.
[12:51] <persia> (or running DAK externally as both do now)
[12:52] <kiko-zzz> persia, direct meaning binary?
[12:54] <persia> kiko-zzz: No, that would be bad.  Source.
[12:54] <\sh> Ah..kiko is awake ;)
[12:54] <persia> From the blueprints page "The copy archive will never have direct uploads but will instead have packages copied to it from another archive (its parent)."
[12:55] <kiko-zzz> ah, ok
[12:55] <persia> I just don't understand why if archives are generalised, it wouldn't be appropriate to allow uploads there (presumably with configurable permissions, etc.)
[12:56] <persia> Also, for the rebuild-test archive-consistency use-case, would a new copy of the same source trigger a rebuild?
[12:57] <persia> Alternately, if these copies include binary also, what happens when they are build with e.g. different C++ ABIs, and the resulting packages don't work together (because of, say, an experimental g++ in one of the PPAs from which it is sourced)
[13:00] <wgrant> The world burns.
[13:03] <kiko-zzz> persia, I think there's some desire to maintain a level of simplicity and there's also a lot of corner-cases we avoid by not allowing direct uploads, but I'll talk it over a bit with julian
[13:05] <bigjools> basically correct
[13:06] <kiko-zzz> bigjools, right. but how do you address persia's use case (or his concern)? :)
[13:06] <persia> Understood, and I can imagine some of the corner cases.  Is it at least a source-only copy?
[13:06]  * bigjools reads more scrollback
[13:07] <bigjools> copies are only ever source only
[13:08] <wgrant> Good.
[13:08] <wgrant> But hmm.
[13:08] <persia> Good.  And does a fresh copy of the same source trigger a new rebuild?
[13:08] <wgrant> Post-initialisation, you mean?
[13:08] <bigjools> wgrant: yes
[13:08] <wgrant> Copying only sources at initialisation seems strange unless you are rebuilding.
[13:09] <bigjools> right, we intend that sources are copied and then you hit the Big Red Button
[13:09] <wgrant> Right.
[13:09] <wgrant> (it would be a bit easier if these specs were public, of course)
[13:09] <bigjools> persia: it could do, we've not discussed that in complete depth.  The original intention is to make copy archives cheap as chips so you can just make a new one
[13:10] <persia> There's enough information on the blueprints page to point at things, but yes, it would be.
[13:10] <persia> More interestingly, if one subscribes to a spec early enough, one can get all the wiki edits by email, even though one cannot actually see the spec.
[13:10] <wgrant> I can't imagine that creating a derivative archive could be cheap unless you publish in the same place. Which is bad unless it's a snapshot archive.
[13:11] <bigjools> wgrant: who said they need to be published? :)
[13:11] <wgrant> bigjools: Why do I want an unpublished non-rebuild archive?
[13:12] <persia> bigjools: These aren't being published?
[13:12] <bigjools> there will be an option to publish them or not
[13:12] <wgrant> (except to confuse people who are looking at dogfood and see that lenny says it has no packages. That was confusing)(
[13:12] <bigjools> dogfood is, erm, in a state of flux shall we say
[13:13] <wgrant> I note that there is a nice unpublished Lenny copy, though.
[13:13] <bigjools> yes, we're doing that to make syncs easier
[13:13] <wgrant> Yep.
[13:13] <wgrant> I thought gina might be dead for a while once s-i-s came along.
[13:14] <bigjools> gina just won't die, I think kiko put some immortality code in there
[13:15] <wgrant> Heh.
[13:15] <bigjools> we don't currently use her for anything btw, but she's going to get a new frock for Debian importing
[13:16] <wgrant> I thought she was used for importing from security dak.
[13:17] <elmo> wgrant: no, security uploads are re-uploaded to lp after going through dak (sic)
[13:18] <wgrant> Ah. Hm.
[13:57] <persia> re: sponsoring earlier: bug #155956 (for any wishing to subscribe)
[15:41] <raphink> hello
[15:42] <raphink> the Ubuntu wiki is broken for me
[15:42] <raphink> it seems to be linked to the kubuntu2 theme
[15:42] <raphink> http://pastebin.ca/1168083
[15:42] <raphink> thi sis the trac
[15:42] <raphink> trace
[15:49]  * emgent need one launchpad devel
[16:24] <intellectronica> emgent: still need one?
[16:25] <emgent> intellectronica: sure.
[16:25] <intellectronica> emgent: at your service, sir
[16:25] <emgent> intellectronica: nice :)
[16:25] <emgent> i need to know all people with Africa/Kigali timezone
[16:25] <emgent> (in launchpad)
[16:25] <emgent> I need it for Human project in Rwanda
[16:26] <emgent> intellectronica: can you grep this?
[16:27] <emgent> now some italian ubuntu people are in rwanda for tech ubuntu stuff (openoffice, firefox etc.)
[16:27] <emgent> but we should know if there is some ubuntu people in kigali for talk about possible collaboration
[16:27] <emgent> intellectronica: can you help me ?
[16:28] <intellectronica> emgent: i'm not sure what's our policy on doing something like that. the information is there (and you can google for it) but given that we don't provide a direct search function, i'm not sure it would be ok for me to run a search like that for a user
[16:28] <emgent> intellectronica: ....
[16:29] <intellectronica> emgent: i'll ask around and see what people think. in the meanwhile, would you mind filing a question?
[16:29] <emgent> i need to know only pubblic information..
[16:29] <emgent> timezone is pubblic in launchpad, but i cant check this value in launchpad search filter.
[16:30] <intellectronica> emgent: yeah, that's my point. the information is there, so you're welcome to search for it, but since there isn't a way to search for it directly, i'm not sure if it's ok to run such a search for you
[16:30] <intellectronica> emgent: however, this discussion is quite theoretical, as https://edge.launchpad.net/+search?field.text=Africa%2FKigali should give you what you want
[16:31] <emgent> uhm i go to check
[16:31] <emgent> thanks
[16:32] <intellectronica> emgent: looks like it's only two users, and one of them writes in his profile that he's studying in england, so maybe the tz information for him is wrong :)
[16:32] <emgent> yeah saw that :(
[16:33] <emgent> ok, thanks
[16:53] <TheEric> any lp admins around?
[16:56] <mtaylor> rosetta question... if I've added more strings to my .pot file, do I just upload the .pot and launchpad iwll run the msgmerge on the .po files it has?
[16:58] <bdmurray> I'm getting OOPS trying to moderate the ubuntu-bugcontrol mailing list
[17:09] <Rinchen> barry, ^^
[17:09] <Rinchen> bdmurray, do you have an oops number for Ursinha-lunch to look up?
[17:09] <barry> bdmurray: that's not good
[17:10] <bdmurray> OOPS-955G2074
[17:11]  * barry waits 10 minutes
[17:11] <bdmurray> I just generated that one though
[17:12] <kiko-phone> TheEric, there always are, it's best to just ask your question and get the cool satisfaction of having it fixed!
[17:28] <barry> Rinchen, bdmurray wow.  i've got the oops now.  i'll submit a bug report on that
[17:33] <kiko-phone> barry, is it a wow oops then? :)
[17:34] <barry> kiko-phone: wow in the sense that it's triggering an assertion, so clearly unexpected
[17:34]  * barry guesses all bugs are unexpected tho ;)
[17:34] <kiko-phone> heh
[18:29] <Ursinha> barry-away, thanks for reporting that bug
[19:54] <popey> uhm, how odd, i just got mails from bug 155947 and bug 51315 with the subject "Georgia: Ceasefire and Withdrawal Now"
[20:53] <mtaylor> anybody on translations?
[20:53] <mtaylor> I just tried to upload a .pot and now status shows "failed"
[20:54] <mtaylor> can't entirely say I understand how I'm supposed to update my .pot
[21:26] <Syntux> Hi, I deleted a package from PPA and now I'm uploading a fixed version but getting that it was already accepted and I cannot upload it again although the delete was executed hours ago.
[21:27] <\sh> Syntux: first, why are you deleting it, when you uploading a new one anyways...
[21:28] <Syntux> \sh, I forgot to add 0ubuntu to the version so I had to reupload and when I tried that it said that I cannot upload older version
[21:29] <\sh> kiko: is the archive package delete cron job still running so few times ? I thought you (the admins) thought about increasing the interval
[21:30] <Syntux> \sh, it has already been deleted, in my PPA I have 0 packages, 0 MB binary and source.
[21:32] <kiko> \sh, I actually don't know the answer to that question! I need to check with the soyuz guys
[21:34] <\sh> Syntux: ask the soyuz people :)
[21:34] <Syntux> Who are they?
[21:34] <Syntux> Are they from the dark side?
[21:34]  * Syntux hides
[21:57] <Romario99> hey folks, is it possible to rename a project completely?
[22:05] <kiko> sure it is
[22:06] <kiko> what project, Romario99?
[22:10] <Romario99> gscrot
[22:10] <Romario99> it is not needed immediately
[22:11] <kiko> Romario99, and what would it be renamed to, if it was?
[22:11] <Romario99> gnapshot
[22:11] <kiko> what a better name indeed
[22:11] <kiko> should I do it now?
[22:11] <Romario99> hehe, i know
[22:11] <Romario99> but its a frontend for scrot
[22:12] <kiko> I know, but scrot is a really bad name!
[22:12] <Romario99> yes, am refactoring the whole app to be a standalone application
[22:12] <Romario99> and gscrot is obsolete ;-)
[22:13] <Romario99> i will let you know when it should be done
[22:13] <Romario99> thank you, kiko
[22:13] <kiko> Romario99, cool, no worries
[22:26] <wgrant> Syntux: You can't ever upload an older version.
[22:27] <Syntux> wgrant, yeah that should make sense but now I have deleted the package and want to upload it to fix that mistake
[22:27] <wgrant> That is beside the point.
[22:27] <wgrant> Uploading older versions can confuse things horribly.
[22:27] <wgrant> It simply should not be done.
[22:28] <wgrant> (and Soyuz enforces this)
[22:29] <Syntux> wgrant, what do you recommend doing now? changing the package name?
[22:29] <Syntux> :-)
[22:29] <Syntux> increasing the version?
[22:30] <wgrant> The version.
[22:30] <wgrant> You would never change the name for something small like this...
[22:30] <wgrant> As that does the same thing as reducing the version.
[22:30] <wgrant> No upgrades.
[22:30] <wgrant> And it's generally bad.
[22:32] <Syntux> Ok
[22:32] <Syntux> I admit it was a horrible mistake.
[22:32] <Syntux> :-)
[22:32] <Syntux> will increase the version now, thankfully I marked it as experimental
[22:35] <lifeless> barry: hey, are mailman 'topics' case insensitive?
[22:35] <Syntux> what is Soyuz ?
[22:36] <barry> lifeless: the topic patterns are just regular expressions, and i believe they are case insensitive.
[22:36] <wgrant> Soyuz is the part of Launchpad which manages the packages in distributions and PPAs.
[22:36] <lifeless> we have a user saying they aren't working for her
[22:36] <lifeless> this is the regex:
[22:36] <lifeless> \[merge\]
[22:36] <lifeless> \[codereview\]
[22:36] <lifeless> note that that is two lines
[22:36] <lifeless> does it need a | and branches ?
[22:37] <lifeless> a mail got through with subject [MERGE] wordlist refactoring
[22:38] <lifeless> so 'what are we doing wrong'
[22:39] <kiko> Syntux, the part of launchpad that knows how to manage packages.
[22:39] <Syntux> oh I see.
[22:39] <Syntux> Thank you
[22:40] <lifeless> kiko: is it still the official name, or is it launchpad packages or something ?
[22:40] <kiko> lifeless, it's still the official name.
[22:40] <lifeless> cool