| lfaraone | If the *only* change in a New Upstream Version is to fix a single bug that I want to SRU, can I just upload the NUV to the SRU queue as "0.2.1-0ubuntu0.10.04.1" or something? | 02:40 |
|---|---|---|
| neeraj | Hi, I was about to file an FFe for updating ubuntu-sugar-remix-meta package and was going through https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze%20for%20new%20upstream%20versions | 03:09 |
| neeraj | I didn't understand the Upstream Changelog diff. I hope attaching the debdiff file will do. | 03:10 |
| lfaraone | neeraj: if it's an ubuntu-native package, it's not needed. | 03:11 |
| lfaraone | neeraj: since the usr metapackage is not developed separately, it's not a "new upstream version" per se. | 03:11 |
| neeraj | lfaraone: Ok. A new version | 03:12 |
| neeraj | *? | 03:12 |
| lfaraone | eeraj: if you're just re-running the "update package" script I don't even think you'll need a FFe, but ScottK would know better than I would. | 03:13 |
| lfaraone | * neeraj | 03:13 |
| neeraj | lfaraone: yes. I only ran update package script. | 03:14 |
| ScottK | lfaraone and neeraj: I approved it. | 03:39 |
| neeraj | ScottK: Thanks :) | 03:39 |
| ScottK | lfaraone: Technically adding new packages is a new feature, but not a major one. I'd like to see about getting release delegation for you for u-s-r so you can just decide it. | 03:40 |
| lfaraone | ScottK: oh, that'd be cool. I guess I just need to get in front of the techboard? | 03:40 |
| ScottK | lfaraone: No, it's a delegation from the release team. | 03:41 |
| lfaraone | ScottK: ah, exciting. so I don't have to make another meeting :) | 03:41 |
| lfaraone | ScottK: where to I sign? | 03:45 |
| ScottK | I just sent a mail to the release team list. As long as there is consensus around the idea, it won't be a problem. Now we wait. | 03:46 |
| lfaraone | ScottK: saw it, thanks! | 04:05 |
| ScottK | You're welcome. | 04:05 |
| lfaraone | ScottK: so this wouldn't cover everything in the packageset, I gather. | 04:06 |
| ScottK | lfaraone: No, but I assume that you're either fixing bugs or wanting new packages sync'ed so that's not a big deal. | 04:07 |
| ScottK | It's late in the game, so I figure to start small. | 04:07 |
| lfaraone | ScottK: fair enough. | 04:07 |
| lfaraone | ScottK: btw, a new package that should show up in the next week, a "sugar-abrowser-activity". (won't be synced from Debian, I'll probably be the one packaging it) Should I work to get it ready by FinalFreeze, or is that not realisticlly acceptable? (really small wrapper script, which we can't call Firefox because it's themed differently) | 04:08 |
| ScottK | If it's super simple and you promise it won't hurt my head to review it, go ahead. | 04:09 |
| lfaraone | ScottK: yessir. | 04:09 |
| bilalakhtar | good morning | 07:13 |
| Laney | anyone got a squeeze system that they fancy testing something on for me? | 11:32 |
| soren | Laney: Is it fun? | 11:43 |
| Laney | err... yeah | 11:43 |
| Laney | sure! really fun! | 11:43 |
| soren | Laney: It has to be fun. I have to go get the laptop on a shelf, find a power supply and wait for it to boot. | 11:44 |
| soren | Laney: So if it's not fun, I'll hate you forever and ever. | 11:44 |
| Laney | Maybe not that fun. | 11:44 |
| soren | :( | 11:44 |
| Laney | Run the test case on http://trac.informatik.uni-bremen.de:8080/hets/ticket/794 against ghc6 & libghc6-gtk-dev from squeeze | 11:44 |
| * soren was in the mood for fun | 11:44 | |
| soren | Oh, gui? No can do. | 11:44 |
| Laney | :'( | 11:44 |
| * tumbleweed has a squeeze box here, one sec | 11:45 | |
| soren | It's my Xen test box. No GUI. | 11:45 |
| Laney | yay for tumbleweed! | 11:45 |
| Laney | if it's broken then it'll hang when you click one of the buttons | 11:45 |
| tumbleweed | Laney: it hangs | 11:49 |
| Laney | tumbleweed: hmm, thnks | 11:50 |
| Laney | not sure whether to be happy at that or not | 11:50 |
| Laney | at least we can make the change in Debian | 11:50 |
| === giskard_ is now known as giskard | ||
| === ivoks-afk is now known as ivoks | ||
| === ivoks is now known as ivoks-afk | ||
| === ara_ is now known as ara | ||
| === shadeslayer_ is now known as shadeslayer | ||
| === ivoks-afk is now known as ivoks | ||
| === ivoks is now known as ivoks-itc | ||
| porthose | is GPL3 and CC-non-commercial compatible? I'm working on an app that is released under GPL3 but has a component that is released under CC-non-commerical | 18:29 |
| jetienne | q. where the prerm scripts of the installed packages are storred ? | 18:40 |
| jpds | jetienne: /var/lib/dpkg/info | 18:41 |
| jetienne | jpds: thx | 18:41 |
| jpds | jetienne: You are welcome. | 18:41 |
| lucidfox | Huh | 19:02 |
| lucidfox | I just noticed that one of my shirts has the word UPSTREAM written along it | 19:02 |
| ScottK | porthose: No. | 19:16 |
| ScottK | porthose: Anything non-commercial is not GPL compatible. | 19:16 |
| porthose | ScottK, thx that is what I thought just making sure :) | 19:16 |
| ari-tczew | bdrung_: I'm thinking about create a new step for main-sponsoring procedure. | 20:15 |
| bdrung_ | ari-tczew: some bugs could through the reviewers-team step | 20:16 |
| ari-tczew | when universe-sponsor has reviewed a patch and when it looks good, then should add a tag, e.g. 'upload-ready' | 20:16 |
| ari-tczew | then main sponsor like you bdrung_ will look for bugs with tag 'upload-ready' | 20:16 |
| bdrung_ | ari-tczew: the upload-ready tag sounds good to me | 20:17 |
| ari-tczew | nice! | 20:17 |
| Laney | but he'd still have to review it anyway. | 20:17 |
| ari-tczew | Laney: that's normal... We are talking about situations, when universe-sponsor is looking on bugs subscribed e.g. 2 years ago | 20:18 |
| bdrung_ | Laney: yes, but then the throughput will be increased | 20:18 |
| Laney | How? | 20:18 |
| Laney | You still have to review just as dilligently, there's just a different queue to review from | 20:18 |
| bdrung_ | Laney: it's like cherry picking bugs | 20:19 |
| ari-tczew | bdrung_: could you explain what we plan? : | 20:19 |
| ari-tczew | :) | 20:19 |
| bdrung_ | Laney: universe sponsors can still reject a patch, request an improvement, forward it to upstream, etc. | 20:19 |
| Laney | At the very least the upload-ready name is a misnomer. | 20:19 |
| Laney | please-prioritise-this-main-sponsors | 20:20 |
| ari-tczew | sigh... well, what about tag | 20:21 |
| Laney | :) | 20:21 |
| ari-tczew | 'main-sponsorship-ready' ? | 20:21 |
| bdrung_ | or reviewed-by-motu | 20:21 |
| directhex | i-like-muffins | 20:22 |
| ari-tczew | Laney: example: we have in sponsors queue an old bug, patch is targeted to jaunty and package is present @main. please look what I'm doing: bug 312384 | 20:22 |
| ubottu | Launchpad bug 312384 in Package Descriptions for Ubuntu "a typo in description of "Cluster Management"" [Low,Triaged] https://launchpad.net/bugs/312384 | 20:22 |
| ari-tczew | the same thing motu can do for bug 375890 | 20:25 |
| ubottu | Launchpad bug 375890 in pidgin-libnotify (Ubuntu) "Typo in patch to configure.ac" [Low,Confirmed] https://launchpad.net/bugs/375890 | 20:25 |
| iulian | I think there's a difference between a core developer and a motu. Let's keep it that way, at least for now. | 20:26 |
| ari-tczew | I don't agree with iulian. | 20:27 |
| ari-tczew | I propose to start discuss through list-mail. | 20:28 |
| Laney | ari-tczew: I don't understand why you unsubscribed the sponsors there. The change was (presumably) good; we shouldn't necessarily expect contributors to follow our release cycle closely. | 20:28 |
| Laney | It would have been easy for a sponsor to adjust the changelog... | 20:28 |
| Laney | In previous cycles I have just added [natty] to the subject | 20:28 |
| bdrung_ | iulian: what's the difference between a core dev and motu? | 20:28 |
| ari-tczew | upload rights | 20:29 |
| Laney | bdrung_: Everyone can triage bugs, that's fine and encouraged. | 20:29 |
| bdrung_ | beside upload rights? | 20:29 |
| Laney | I don't think creating a double-review expectation is helpful though | 20:29 |
| bdrung_ | Laney: it's just for getting processed the backlog of main bugs. there are sponsor request that are older than two years. | 20:30 |
| ari-tczew | Laney: ok mastermind, let's give a better idea for clean up sponsors queue. go ahead! | 20:30 |
| Laney | ... | 20:30 |
| ari-tczew | I thought so. | 20:31 |
| Laney | I can't interact with someone with that tone | 20:31 |
| * ari-tczew is sad :( | 20:32 | |
| bdrung_ | ari-tczew: i am not satisfied how you processed bug #312384. if i would process the bug, i would have checked if it still valid and check if it can be forwarded to upstream or Debian. in this case Debian could be affected. | 20:33 |
| ubottu | Launchpad bug 312384 in Package Descriptions for Ubuntu "a typo in description of "Cluster Management"" [Low,Triaged] https://launchpad.net/bugs/312384 | 20:33 |
| Laney | and I don't think there's any problem with anyone reviewing the main queue, but there's no need for a tag or any kind of double review expectation | 20:34 |
| Laney | just use your unsubscription and status altering abilities | 20:34 |
| bdrung_ | Laney: i like the idea of prepending [natty] to the bug. | 20:34 |
| * Laney is out for a few hours, ttyl | 20:34 | |
| Laney | bdrung_: yeah, it's worked well in the past | 20:34 |
| Laney | for deferring fixes post-freeze | 20:34 |
| * Laney waves | 20:34 | |
| bdrung_ | Laney: let's talk later about it | 20:35 |
| ari-tczew | bdrung_: so, I suggest to write about it on wiki | 20:35 |
| bdrung_ | ari-tczew: which one? the [natty] title or the reviewed-by-motu tag? | 20:35 |
| bdrung_ | ari-tczew: the first yes and let's discuss the second first. | 20:36 |
| bdrung_ | ari-tczew: maybe a status may be sufficient. let's wait until Laney is back. | 20:36 |
| ari-tczew | bdrung_: all things in one page. Maybe we should create a new wiki page about reviewing bugs for main by universe sponsors. | 20:37 |
| iulian | bdrung_: I'm not going to explain to you the difference between a core developer and a motu. I believe you should know that already. The main reason I said that is because I don't see the point in having two developers review the same patch. | 20:38 |
| bdrung_ | ari-tczew: i don't think that we should document it yet. i hope this can be a one-time thing. getting the queue empty and keep it small. | 20:38 |
| iulian | In this case, two developers with different upload privileges. | 20:40 |
| bdrung_ | iulian: the point is that the main queue lacks sponsors and that there are many old one in there. (1) some bugs may not be valid any more, (2) some needs work, (3) some should be fixed upstream first, and (4) some are still valid. i would prefer to review the bugs falling under point (4) first. point (1) till (3) can be processed by motu too. | 20:41 |
| ari-tczew | bdrung_: ok sorry for my bad step. this is a new idea and everyone can do mistakes on start. | 20:43 |
| ari-tczew | Laney: sorry for my behaviour | 20:43 |
| bdrung_ | ari-tczew: did you read https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews -> "Not suitable for the current release period". maybe we should discuss a different way. | 20:44 |
| ScottK | ari-tczew: Better than writing a wiki page I think would be to write mail to the ubuntu-devel mailing list so it can be discussed among developers. | 20:52 |
| ari-tczew | bdrung_: could you do this? ^^ | 20:53 |
| bdrung_ | ari-tczew: ok, will do that on my todo list | 20:55 |
| iulian | ScottL: Hi. As an ubuntu-release delegate for Ubuntu Studio, could you please look at bug #606533? | 20:58 |
| ubottu | Launchpad bug 606533 in lmms (Ubuntu) "Please merge lmms 0.4.7-2 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/606533 | 20:58 |
| === Lutin is now known as Guest42642 | ||
| === ivoks-itc is now known as ivoks | ||
| kklimonda | james_w: with bzr-builder, is it possible to use svn revision for bzr branch that is imported from svn as a rev no in package version? | 21:06 |
| james_w | no | 21:06 |
| bdrung_ | kklimonda: there is a bug report for that | 21:08 |
| bdrung_ | kklimonda: bug #412722 | 21:09 |
| ubottu | Launchpad bug 412722 in bzr-builder "Provide deb-version substitute {svn}" [Low,Confirmed] https://launchpad.net/bugs/412722 | 21:09 |
| kklimonda | bdrung_: thanks | 21:09 |
| === Guest42642 is now known as Luti | ||
| === Luti is now known as Lutin | ||
| === ivoks is now known as ivoks-afk | ||
| lfaraone | Is it okay to convert a package (which previously had no patch system) to 3.0 (quilt) in a SRU? ? that's what's used in the maverick version, and it'd just be cleaner than patching the source directly. | 22:59 |
| bdrung_ | lfaraone: in my opinion it's ok, because adding a patch system would require more changes. | 23:04 |
| directhex | in my opinion you should average it out, and port the package to wig & pen format | 23:05 |
| lfaraone | directhex: +1 | 23:05 |
| directhex | the funny thing about 3.0 (quilt) is that we're moving to using it in pkg-mono, for our pure git packaging work. 3.0 (git) would be much more sensible, if it hadn't been axed | 23:06 |
| ScottK | lfaraone: For an SRU, just apply the changes inline if there is no patch system. | 23:25 |
| ScottK | ajmitch: Since you're representing REVU requirements in the UDD discussions, I wanted to mention that from my POV REVU's killer feature is the ability to have multiple orig.tar.gz's that are different, but have identical version numbers and produce diffs from them. AFAIK we don't have any other tools that currently deal with that. | 23:41 |
| ajmitch | alright, do you have an example of that? | 23:42 |
| * ajmitch wasn't really expecting the representation to be so formal, just happened to be watching IRC at the right time when there were questions about REVU | 23:43 | |
| ScottK | ajmitch: Basically a contributor uploads a package, the orig.tar.gz is screwed up, so they fix it and upload again. We don't want them to have to change the upstream version number during the REVU process. | 23:45 |
| ajmitch | ah right | 23:46 |
| sladen | if you're working with somebody trying to get them to eg. +dfsg-ise something it's useful | 23:46 |
| ajmitch | I was thinking more along the lines of multiple tarball support in a single package | 23:46 |
| ScottK | ajmitch: That's going to hurt no matter how you do it. | 23:46 |
| ajmitch | no doubt | 23:46 |
| directhex | it already does. that means you, git-buildpackage! | 23:47 |
| ajmitch | ScottK: what does REVu currently do with such packages where the orig.tar.gz has changed? From what I understand, it should at least handle unpackaging them already & the diff should still be generated | 23:49 |
| ajmitch | though I'll probably need to test it out locally | 23:49 |
| ScottK | ajmitch: That's correct. | 23:49 |
| ScottK | I didn't look at the implementation, but I suspect it puts each one in a separate dir, unpacks, and diffs. | 23:49 |
| ajmitch | that's right | 23:49 |
| ajmitch | I just re-read your initial statement, I thought you were asking for an improvement to REVU there :) | 23:50 |
| ScottK | ajmitch: No, I want to make sure we don't regress if we switch to some UDD way of doing things. | 23:50 |
| ajmitch | Alright | 23:50 |
| ajmitch | from what I've seen, sladen's example of having binary files in the upstream tarball is the most common | 23:51 |
| ScottL | iulian, i will look at that bug tonight | 23:51 |
| ajmitch | especially with directhex's friendly mono packages | 23:51 |
| ScottK | ajmitch: That or they mistakenly rerolled the tarball with their /debian in it instead of having that in the diff.gz | 23:51 |
| * ajmitch sees a lot of native packages, many with non-native versions | 23:52 | |
| ScottK | Yep. | 23:52 |
| ajmitch | we're going to have to sort out what we're doing with the old (6+ months) packages on REVU soon | 23:52 |
| ajmitch | just archiving them is one option, but we don't want to drive people away more than we have | 23:53 |
| directhex | upload them all, to avoid alienation | 23:53 |
| ajmitch | I've also seen a few cases of REVU being used as a place to dump packages which are being reviewed for debian | 23:53 |
| lfaraone | ajmitch: I think REVU is mentioned on some Debian page. | 23:54 |
| ajmitch | possibly | 23:54 |
| directhex | doesn't mentors.debian.net suck? i can see the appeal of revu | 23:54 |
| ajmitch | the case that I saw was someone mailing the DPMT list with the url pointing to REVU | 23:54 |
| lfaraone | ajmitch: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519752#10 | 23:54 |
| ubottu | Debian bug 519752 in wnpp "RFP: pysolfc -- A Python solitaire game collection" [Wishlist,Open] | 23:54 |
| sladen | ajmitch: repoint them all at ARB ;-) | 23:55 |
| ajmitch | yeah, same thing | 23:55 |
| ajmitch | sladen: that's another point I have to raise :P | 23:55 |
| sladen | ajmitch: given how awesome ARB is, it should have no problem coping | 23:55 |
| ajmitch | sladen: your confidence is overwhelming | 23:56 |
| lfaraone | personally, I'm still on the "why are we adding more processes?" side of the fence on the ARB. | 23:57 |
| ajmitch | lfaraone: that was just one of the packages that I saw there, along with a few others by the same person | 23:57 |
| lfaraone | ajmitch: well, there's nothing inherently wrong with that, right? | 23:57 |
| ScottK | directhex: m.d.n serves a slightly different use case than REVU. I agree it sucks for doing what REVU does. | 23:58 |
| sladen | the /intent/ of ARB is excellent | 23:58 |
| ajmitch | lfaraone: when they're uploaded with a debian version & various things which we'd need changed for uploading to ubuntu? | 23:58 |
| sladen | the implementation will I'm sure need massaging | 23:58 |
| lfaraone | ajmitch: I mean, there's nothing wrong with uploading a package targeted to Ubuntu on REVU. | 23:58 |
| ScottK | sladen: It's defective by design at this point. | 23:58 |
| * ajmitch is of the opinion that REVU should still eb the primary way of getting stuff in | 23:58 | |
| ajmitch | lfaraone: right, most of these are targetting debian, and sponsorship has been requested in debian - it's doubling up on work if it's checked & uploaded in 2 places | 23:59 |
| ScottK | ajmitch: ARB will be great for the class of packages that are so great it's essential users get them right away, but still suck so bad we don't want to support them in Ubuntu. | 23:59 |
| lfaraone | well, with m.d.n, the goal is not to publicly discuss and criteque packages, but rather to offer a simple way to get packages out there, with the real discussion happening via mail on the mentors list and privately. | 23:59 |
| ScottK | lfaraone: Exactly. That's the difference. | 23:59 |
| lfaraone | ajmitch: are all REVU packages automatically marked for review? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!