| LaserJock | anybody know how to change branch details in the new LP? | 07:06 |
|---|---|---|
| wgrant | LaserJock: Pencil next to the branch title? | 07:09 |
| LaserJock | I don't see one | 07:10 |
| wgrant | LaserJock: Hm, I can see one on my branches. https://code.edge.launchpad.net/~ubuntu-qa/debcheck/ubuntuwire is one you should be able to see too. | 07:11 |
| LaserJock | ok, right, I see it there | 07:11 |
| LaserJock | then why can't I see it on a vcsimport I registered | 07:11 |
| wgrant | Because you're aren't a member of ~vcs-imports | 07:12 |
| LaserJock | well that's stupid | 07:12 |
| wgrant | Quite possibly. | 07:12 |
| LaserJock | I was gonna fix an import that's been down since 2007-10-07 but I guess not | 07:12 |
| wgrant | How do you propose to fix it? | 07:13 |
| LaserJock | the project moved to svn | 07:13 |
| LaserJock | all I need to do is update the url and it should work | 07:13 |
| wgrant | File an answer, I propose. | 07:13 |
| LaserJock | wgrant: yeah, I suppose that'll have to do | 07:20 |
| wgrant | Hm. That's a few buildds. | 08:21 |
| === RainCT is now known as RainCT_ | ||
| === fta_ is now known as fta | ||
| psycose | I run a Launchpad PPA builder session using Ubuntu Intrepid, can i tell the system to create a symlink (sudo ln -s /usr/lib/gcc/i486-linux-gnu/4.3 /usr/lib/gcc/i486-linux-gnu/4.3.1) because the compiler tool chain crash without it ? | 13:42 |
| psycose | or should i wait that ubuntu packager solve that problem ? | 13:43 |
| persia | psycose: You should probably file a bug against gcc in Ubuntu describing the issue. I suspect we'd have *many* more FTBFS reports if it affected every package. | 13:52 |
| fta | too bad it's not possible to re-upload a deleted package with a different src tarball in ppa :( | 14:45 |
| fta | as the tarball is gone from the pool, it should be possible.. | 14:45 |
| persia | fta: Yeah, but it violates the archive model. | 15:15 |
| fta | it's a ppa | 15:16 |
| persia | Once an orig.tar.gz has been published, it ought not be changed. REVU makes a special exception to this because so many orig.tar.gz files there are initially broken, but even REVU probably oughtn't. | 15:16 |
| persia | Yes, but it violates the very idea that an orig.tar.gz is actually the original tarball. | 15:16 |
| persia | Where it isn't the original tarball, it ought have an appropriate indicator indicating modification, which indicator ought be bumped when it is changed. | 15:17 |
| fta | most ppa are probably not better than REVU.. | 15:18 |
| fta | in my case, it was a buggy vcs tag but as i want this package to enter the repo, i don't want to publish a higher version in my ppa | 15:19 |
| persia | Yeah, sadly most PPA probably aren't better. | 15:20 |
| persia | And I understand your use case: it's an unforunate side effect when orig.tar.gz's don't match upstream. | 15:21 |
| cprov | persia: agree | 15:22 |
| cprov | fta: wouldn't it be clearer to add a patch (using dpatch) modifying the orig ? | 15:23 |
| persia | cprov: Not in the case of a buggy tag. | 15:23 |
| cprov | fta: just and idea, I don't know exactly if it would be legitimate. | 15:23 |
| fta | cprov, not in this case, that would be a several megs patch | 15:23 |
| persia | Essentially, sometimes there isn't an original tarball that upstream releases. In these cases, we construct one with a get-orig-source rule. | 15:24 |
| persia | If the wrong rev is pulled, the orig.tar.gz is mislabelled, so a packaging mistake ends up costing the appropriate version number. | 15:24 |
| persia | This is especially annoying for VCS-centric upstrems that are good about tagging releases appropriately. | 15:25 |
| cprov | yes, I see, very annoying from the maintenance PoV. | 15:26 |
| persia | fta: Don't let a several meg patch frighten you: you don't want to adjust because it would be wrong, not because of the patch size. | 15:26 |
| persia | cprov: Part of why some maintainers don't like VCS. Mind you, when it works, it can vastly simplify the work, it just doesn't always work. | 15:26 |
| persia | (especially when the maintainer makes a mistake) | 15:27 |
| cprov | persia: right. Do you think a bug should be filled to discuss this issue ? Do you see anything we could do on the infrastructure side to make it work better ? | 15:28 |
| fta | i created bug 263301 already | 15:29 |
| ubottu | Launchpad bug 263301 in soyuz "Can't re-upload a package with a different src tarball after deletion in PPA" [Undecided,New] https://launchpad.net/bugs/263301 | 15:29 |
| cprov | fta: thank you. | 15:29 |
| persia | cprov: I would have said no :) But it depends on the purpose of a PPA. | 15:29 |
| persia | If a PPA is supposed to be a scratch space for people to fiddle and learn, then deletion ought actually delete. | 15:29 |
| persia | While this might violate all sorts of conventions, and permit people to do things like upload lower versions, etc., it makes it a better scratch space. | 15:30 |
| cprov | persia: it does delete, however the package version and the orig version|content remains blacklisted | 15:30 |
| persia | If PPAs are supposed to be little release archives for stuff not in other distributions or with patches not in other distributions, then fixing the bug is a bad idea, as it fails to encourage adherence to the conventions. | 15:31 |
| persia | cprov: The content is deleted. The existence of the upload is not deleted. My apologies for confusion. | 15:31 |
| fta | cprov, i also opened bug 263296 just before.. a ui problem with delete | 15:31 |
| ubottu | Launchpad bug 263296 in soyuz "Can't easily delete packages when PPA contains more than 50 pkgs" [Undecided,New] https://launchpad.net/bugs/263296 | 15:31 |
| persia | I already opened that bug, so that's a dup. I'll see if I can find mine. | 15:32 |
| persia | And you can delete the packages, it's just very awkward. | 15:32 |
| fta | i looked but couldn't find it | 15:32 |
| jpds | Does anyone know how I can use the "inTeam" method described in http://people.ubuntu.com/~flacoste/launchpad-api-doc.html ? | 15:33 |
| cprov | fta: persia: nice, two new bugs on ppa, I will investigate solutions for them Monday. Thank you, guys. | 15:35 |
| jpds | I do: me.inTeam("ubuntu-dev") and I get this error: http://paste.ubuntu.com/42171/ | 15:35 |
| fta | thank *you* | 15:35 |
| persia | fta: I can't find it either. Odd. Thanks for filing then :) | 15:36 |
| fta | persia, i usually search 1st :) | 15:36 |
| persia | cprov: which is the intended model for the PPAs? I'll comment on 263301 appropriately. | 15:36 |
| persia | fta: Certainly :) I was just *sure* I filed that bug, as it was causing me lots of issues in June. | 15:37 |
| cprov | persia: well, the intended model is the current one, package and orig versions always grow coherently. However this model has issues. Better describe the broken workflows and decided to change the system to fit all of them. | 15:39 |
| persia | cprov: At a much higher level, are PPAs scratch spots for people to play, or intended for release purposes for teams? | 15:40 |
| cprov | persia: both. | 15:40 |
| cprov | persia: since we assume they are compatible. | 15:40 |
| persia | Ah. That assumes that anyone uploading always does it right :) With that assumption, we don't need PPAs, as we could just take it in Ubuntu. | 15:41 |
| cprov | persia: the current situation suggests they are *not* (as I see it) | 15:41 |
| persia | No. I'll comment both ways to underscore this in the bug. Thanks for describing the confusion. | 15:41 |
| cprov | persia: ehe, thanks | 15:41 |
| fta | funny, go to +delete-packages, enter something bogus in the search field but don't search, select a package to be deleted and click delete, you get the bogus search error. | 15:44 |
| fta | is it the same form ? | 15:44 |
| fta | my bogus search was to search for something in the version, not in the package name | 15:45 |
| cprov | fta: they are part of the same form, indeed. | 15:55 |
| fta | cprov, ok, so the question is, should search prevail over delete ? | 15:57 |
| cprov | fta: IMHO, it does because of the way the page is implemented "search/select/act", but that can be changed. | 15:58 |
| === cprov is now known as cprov-lunch | ||
| fta | cprov-lunch, it should look for field.actions.update vs field.actions.delete to do the right thing | 16:00 |
| fta | need a another bug ? | 16:00 |
| fta | -a | 16:00 |
| cprov-lunch | fta: yes, file that too. | 16:00 |
| fta | bug 263314 | 16:07 |
| ubottu | Launchpad bug 263314 in soyuz "delete vs search in +delete-packages (ppa)" [Undecided,New] https://launchpad.net/bugs/263314 | 16:07 |
| === warp10_ is now known as warp10 | ||
| persia | fta: Please update 263301 if my description of the general case in support of your need is insufficiently general to cover your specific situation. | 16:16 |
| fta | persia, it's indeed what happened to me: i fixed it earlier today http://bazaar.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts/revision/171 | 16:19 |
| persia | fta: Great. Let's see how it gets interpreted tomorrow. I'm still not sure which is the right answer (for all the reasons I describe), but it's better that the implementation be based on an informed decision, rather than just what happens to be right for Ubuntu. | 16:20 |
| fta | i would not say i'm new to packaging, but my get-orig-source rule is far from trivial and then probably not bugfree. Got the proof today with mercurial and firefox 3.1 | 16:27 |
| persia | fta: No, you're not new to packaging, and your get-orig-source rules tend to make people cry, but I think that a novice packager is more likely to end up in this situation than yourself, and would rather avoid the bug being rejected because you are special: better to have the decision be based on a general case. | 16:56 |
| fta | persia, sure. that's why i didn't use mozilla anywhere in the bug, or my vcs specificities. btw, who's crying about my get-orig-source rules and about which package(s) ? i'd be interested to know the arguments. | 17:35 |
| persia | fta: At least me for prism. That was probably the least easy get-orig-source I ever reviewed. | 17:36 |
| persia | Note that this isn't necessarily a bad thing: sometimes things must be done that way. | 17:36 |
| persia | Also note that the final result produced correct data, so the fact that it was hard for me to understand isn't very important. | 17:37 |
| fta | persia, ok. for prism, that's history now. my last version of debian/rules looks like this: http://paste.ubuntu.com/42200/ but that whole WEBAPPS thing will probably disappear too. | 17:41 |
| persia | fta: You include /usr/shre/mozilla-devscripts/prism.mk and you still need 99 lines for a CDBS rules file? I like CDBS with 1 line. | 17:43 |
| persia | This isn't the forum really, but complication is relative :) | 17:43 |
| fta | persia, 2 reasons, 1st: /usr/share vs /usr/lib (preferred upstream path) to please lintian, 2nd: as i said, WEBAPPS mess that will disappear. I tried to simply xulapp packaging as much as possible, see my (temptative of) tutorial here https://wiki.ubuntu.com/MozillaTeam/XulApps/Packaging but it's still not easy business. yet the rules files in there is small | 17:49 |
| fta | indeed, not the right forum | 17:49 |
| === trmanco_ is now known as trmanco | ||
| === cjwatson_ is now known as cjwatson | ||
| komputes | I always seem to run into an issue when I want to report a bug against 2 packages, can someone tell me how that's done again (without removing the first package or relating it to a URL to an upstream project) | 23:08 |
| wgrant | komputes: You want to have the same bug against two packages? | 23:08 |
| komputes | wgrant: yes | 23:09 |
| wgrant | komputes: "Also affects distribution..." | 23:09 |
| komputes | wgrant: great, thanks. I guess I always get confused since the field is filled with the previous package name, making it seem that I am replacing it with this new package, thanks for reminding me... | 23:11 |
| wgrant | komputes: That's useful when you want to add a task against Debian, which uses the same package names. | 23:12 |
| komputes | wgrant: gotcha, guess i'll have to learn to live with it. | 23:12 |
| === ursula__ is now known as Ursinha | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!