[00:10] * TheMuso grumbles at there being no Contents-$arch.gz for hardy [00:10] on any mirror. [00:17] TheMuso: afaik the Contents file isn't generated yet for hardy but I don't remember why [00:18] geser: I can see its not being generated... I guess another soyuz bug. [00:19] seems like that always happens for the devel release === yamal_ is now known as yamal [00:57] * persia notes that Contents.gz is intentionally not provided at the beginning of a release cycle due to the expected massive changes, but that post-DIF it likely ought be enabled, and someone may have forgotten. [00:58] ah, that makes sense [01:03] Fujitsu: wow, there's now an octave3.0 package [01:03] LaserJock: There is. [01:03] And we didn't sync it because it broke the upgrade path, IIRC. [01:03] oh? how so? [01:03] * Hobbsee waves [01:03] LaserJock: Bug #178424 [01:04] Launchpad bug 178424 in octave2.9 "Please sync octave3.0 3.0.0-1 (universe) from Debian unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/178424 [01:05] hmm, I don't see how that's a problem [01:06] users not being able to upgrade? [01:06] why would they not be is my question [01:06] octave3.0 conflicts/replaces 2.9 [01:06] but there's nothing that says that an upgrade would give you 3.0 [01:06] I believe the problem was that there is no octave metapackage any more. [01:07] LaserJock: No "octave" virtual package. Just needs a small change for a merge, in my opinion. [01:07] but why not use the package from 2.9? [01:07] (but someone should probably check with the Debian Octave maintainers to make sure we don't interfere with some cunning plan) [01:07] I was just thinking that current 2.9 users would get 2.9 [01:08] and if people want to install 3.0 they can do that themselves [01:08] LaserJock: octave2.9 is scheduled for removal from Debian (and we'd probably want to follow if we import octave3.0) [01:08] yeah, that would be the problem [01:09] wait [01:09] the changelog says: "Dropped the empty octave package. This will allow [01:09] releasing octave3.0 without an epoch in its version number. We will [01:09] reintroduce this package later, if necessary (anyway, octave3.0 [01:09] provides octave)." [01:09] does the provides make it upgradable? [01:09] LaserJock: Give it a test. [01:10] (create gutsy chroot, install octave, upgrade to hardy with an extra repo including octave3.0, see if it breaks) [01:13] Ah. Wait. I understand now. 1:2.9.18-1ubuntu1 >> 3.0.0-1. That's frustrating. [01:19] Heya gang [01:19] hey bddebian [01:19] Hi persia [01:22] LaserJock: I've got another one for you if you have a moment. [01:22] k [01:23] I need a couple of minutes to fix it. I missed that a package had moved from Universe to Main and so it needs a few adjustments [01:26] LaserJock: The updated package can be dgetted (dgotten) from http://www.kitterman.com/test/libnet-server-perl_0.97-0ubuntu1.dsc [01:27] It's signed. [01:27] dgotten? English is annoying flexible and irregular :) [01:27] hey [01:28] LaserJock: There is also http://www.kitterman.com/test/libnet-server-perl_0.97-0ubuntu1_source.changes if you want it. [01:29] Is a watch file really worth a delta with Debian? [01:29] bddebian: Only for orphaned packages. [01:30] ScottK: hmm, you upload the diff.gz with it? I get 404 [01:32] Urgh checking [01:33] LaserJock: It's there now. Sorry about that [01:36] Does Malone support virtual packages? I'm thinking it might be nice to havea virtual package against which needs-packaging bugs are filed, so as to create the ability to subscribe to the package as an ad-hoc mailing list for packaging work that needs doing. [01:37] ScottK: Donald? [01:37] persia: It does not. [01:37] persia: yeah ... well I tried that [01:37] Fujitsu: Thanks. I shan't propose such a thing to a wider forum then. [01:37] You can only file bugs on SourcePackageNames that are published in a distribution. [01:38] I went from "virtual package just like wnpp" -> "project for wnpp" -> "tag it" [01:38] Ah. So the discussion has been had before. The annoying bit being that one cannot subscribe to a tag. [01:39] persia: not unless you actually upload a virtual package of nothing [01:39] make a package called needs-packaging or something. put it in the archive. *shrug* [01:39] Bug #151129 [01:39] Launchpad bug 151129 in malone "Can't subscribe to a tag" [Undecided,New] https://launchpad.net/bugs/151129 [01:39] is it correct to assign a new needs-packaging bug to MOTU (it covers the thing I'm working on) [01:39] Hobbsee: That's just wrong. Uploading the needs-packaging package which only provides changelog, copyright, and README.gz is not the right solution. [01:39] Ng: No. Correct to assign to yourself, as you're working on it. [01:39] persia: i didn't say it was right. i just said it would do what you were asking :P [01:40] persia: Well, one could upload, and then remove it again immediately. [01:40] persia: okidoki, thanks [01:40] Once there is any kind of SourcePackagePublishing, it will be filable, but that's a bug. [01:40] Fujitsu: Hmm. Then it would be there, but not distributed. Hobbsee: would you collude in such a dance? [01:40] * Fujitsu prefers being able to subscribe to tags. [01:41] persia: define distribubted in this case? [01:41] persia: it woudl be yet another universe package [01:41] Hobbsee: That would be distributed. [01:42] I think being able to subscribe to tags is a sane idea [01:42] Fujitsu: Yes, that's a more general solution. Too bad it's still New. [01:42] persia: yes, but how many packages are in universe again? [01:42] LaserJock: So does mpt, apparently. [01:42] LaserJock: far too sane to be implemented. [01:42] * Hobbsee ducks [01:42] Hobbsee: About 15,000. Which we support. [01:43] fsvo support, anyway [01:43] but yes [01:43] * persia considers confiscating Hobbsee's MOTU badge [01:43] heh [01:43] LaserJock: Yes. Scott is my middle name. [01:43] * Hobbsee waves her core-dev badge around [01:43] core-dev trumps MOTU, i'm afraid [01:44] * Fujitsu looks with dismay at http://qa.ubuntuwire.com/multidistrotools/universe.html#removedfromA [01:44] Hobbsee: Right. Core-dev gets you upload to anywhere, so losing MOTU wouldn't affect much, except that it would indicate you don't have the appropriate positive attitude about supporting all of universe :) [01:44] *grin* [01:45] Fujitsu: I'm likely to start hitting that next week, but would be more than happy if you want to start sooner :) [01:45] * Hobbsee has reservations with how some of MOTU works. Therefore, she's less likely to feel an active part of it. [01:46] still, i don't see how a metapackage would actulaly need supporting, per se. [01:46] * persia has reservations with how some of core works, and doesn't intend to start participating soon. [01:46] or what the problem is of addign one more, when there's 15K already. [01:46] ScottK: does libnet-server-perl have any current core dev owner? I won't be stepping on any toes? [01:47] Hobbsee: It's a non-package. It oughtn't really be there. Publishing and removing would allow one to file bugs, but publishing and letting die only makes more work for those of us who try to trim the edges. [01:47] LaserJock: There isn't currently an Ubuntu diff. We get it from Debian and the Debian maintainer isn't an Ubuntu person, so I'd think not. [01:47] k [01:49] Do we know when ajmitch returns, so we might be able to have rcbugs going again? [01:49] Hobbsee, transmission 1.0 is out if you're interested in bumping it (but it's not in Debian yet) [01:49] He indicated about three weeks around 22nd December, so I'm guessing "soon". [01:50] Thanks persia. [01:50] * persia is anxiously awaiting the return of RCbugs :) [01:51] nenolod: i don't see the point in duplicating work like that [01:51] ScottK: did you comment that it was uploaded to hardy in bug #69895 because I'm doing it? [01:51] Launchpad bug 69895 in postgrey "crashes when syslog is not available" [Medium,Fix released] https://launchpad.net/bugs/69895 [01:51] Hobbsee, right. i'll tell the debian maintainer that 1.0 is out. ;) [01:51] LaserJock: I commented that it was uploaded because I didn't notice it had moved to main and uploaded it. [01:51] ah, k [01:51] oh. [01:52] Hobbsee, 1.0 is incoming [01:52] w00t, on build 200 of newpki-client... [01:52] ScottK: Isn't that more easily done with a changelog entry? [01:52] LaserJock: After it bounced, I came looking for you... [01:52] persia: What? [01:52] so, i'll just update bug 180534 to a sync bug [01:52] Launchpad bug 180534 in transmission "Please update transmission to latest version (1.0)" [Undecided,New] https://launchpad.net/bugs/180534 [01:52] ;) [01:52] ScottK: Closing bugs for uploads. [01:52] I didn't mark 69895 fixed [01:53] my changelog marks bug #177408 fixed [01:53] Launchpad bug 177408 in libnet-server-perl "Please upgrade to 0.97" [Wishlist,Triaged] https://launchpad.net/bugs/177408 [01:53] ScottK: My mistake. Sorry. [01:53] No trouble. [01:54] I was messing with libnet-server-perl because I'm working on getting amavisd-new into Main for Hardy and I'm making sure all the depends are in good shape and in Main also. [01:56] ScottK: done [01:58] LaserJock: Thanks. [01:58] Hobbsee, https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/180534 -- if you want to bump it again. it builds fine in my pbuilder. [01:58] Launchpad bug 180534 in transmission "Please sync transmission_1.00-1 from Debian unstable (main)" [Undecided,New] [01:59] nenolod: I thought you said it wasn't in Debian yet? [01:59] ScottK2, it's in incoming [01:59] Ah. [01:59] actually it just moved out of incoming a while ago into unstable [02:00] OK. [02:04] man, I've done a lot of dput'ing today [02:04] (so it can be pulled from merkel, but not from the main pool) [02:04] (which is where i picked it up) [02:08] ScottK: \o/ 3 Main upload is just over 3 hrs ;-) [02:08] LaserJock: If you're going for volume, you may find that dput *source.changes can be surprisingly helpful. [02:09] haha === bigon is now known as bigon` [02:12] Thanks for all the help LaserJock. [02:12] no problem, glad i could be of some service [02:17] hmm, we have iceape but not iceweasel? [02:24] anybody have an opinion on "s/iceweasel/firefox/" vs "add firefox|" for dependent packages? [02:25] LaserJock: I like "add firefox |" to support future gobuntu plans if they choose iceweasel over epiphany (currently under debate, I believe) [02:27] hmm, does epiphany use firefox plugins? [02:27] LaserJock: In some limited ways, but not really. [02:27] LaserJock: it has it's own plugin package basically. [02:28] LaserJock: it can use flash and stuff though. [02:28] hmm [02:28] I've got a package that creates a mozilla plugin [02:28] and in debian it uses iceweasel | iceape | xulrunner [02:29] and it build-deps on libxul-dev [02:30] For Hardy, I think the idea is to use xulrunner [02:30] Be careful there. F3 is xulrunner1.9, which is not xulrunner. [02:30] ScottK: Yes. [02:30] I'm assuming that the build-dep on libxul-dev will work for everything [02:31] * persia thinks the API may be different, and suggests checking in -mozillateam [02:31] some I was just gonna do firefox | iceweasel | iceape | xulrunner [02:31] xulrunner-1.9-dev is the 1.9 dev package. [02:32] but I wondered about epiphany [02:32] sorry for the ignorance, but should I care about F3 and xulrunner1.9? are they default in Hardy? [02:33] Fx3 isn't default yet. [02:33] They are planned to be, though. [02:33] (Fx3 uses xulrunner-1.9, rather than an embedded Gecko) [02:33] hmmpf [02:33] I hate mozilla stuff [02:34] and I can never get anything from mozilla team [02:49] Shite, I think my pbuilder is screwed up, I don't know if I can help with UUS persia :( [02:49] bddebian: what'd you do now? [02:50] Dunno :-( [02:51] It act like it's having issues resolving archive.ubuntu.com [02:51] acts.. [02:53] but your machine is fine? [02:53] Yeah. In fact in pbuilder-login it acts fine. I'm not getting it.. :-( [02:56] weird [02:57] bddebian: paste the output? [02:57] Yeah and pbuilder update works but not build.. wtf [03:03] bddebian: Maybe pbuilder finally died for you. You might try https://help.ubuntu.com/community/SbuildLVMHowto (there's a handy script in ubuntu-dev-tools to make this pointlessly easy) [03:07] This is craziness: http://paste.debian.net/46256 [03:07] man, I *still* have a hard time remembering changelog-closes-bug [03:07] bddebian: Maybe some irregularity between arch: i386 and arch: all ? (Yes, this should never happen) [03:10] * persia requests people check other bugs on a package when preparing a new revision. While it's also nice to fix other outstanding issues, there is really no point to requesting an update to a package that is scheduled for removal. [03:15] persia: one last chance to get a changelog entry? ;-) [03:15] LaserJock: Cause for rejection of the candidate, in my book. [03:20] Vorian: Please check your changes files. This will be the last set of packages for which I manually add the extra characters to close the LP bugs. [03:23] persia: I can do that. [03:48] Does anyone use transmission? Bug #180534 is likely good, but might do well with some testing. [03:48] Launchpad bug 180534 in transmission "Please sync transmission_1.00-1 from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/180534 [03:56] Good morning all. I have been struggling with this error message since yesterday night and unable to resolve the issue. http://paste.ubuntu-nl.org/50934/ [03:57] when I try to remove the Desktop folder inside the debian directory it builds fine but fails at the creating icons stage due to the rules present. [03:58] When I add this directory back it fails even before building giving the above pastebinned error [03:58] any pointers? [03:58] I see that this occurs while building the diff.gz [03:59] dpkg-source: unrepresentable changes to source is what is killing you [03:59] You are doing something that pdkg-source thinks is changing a binary file. [04:00] That'd be dpkg-source, of course [04:01] Gah, I finally get my pbuilder fixed and the freakin' power runs out :( [04:01] tuxmaniac: Could you paste debian/rules? [04:02] bddebian: bummer man [04:03] persia, http://paste.ubuntu-nl.org/50935/ [04:03] bddebian, hahah [04:03] LaserJock, hi. Long time no see. :-) Hope you "break" was fun [04:03] heh ... something like that [04:07] wow, a long description that includes 23 lines of help/usage instructions [04:08] tuxmaniac: From where are the .png files originating? I don't see them. [04:09] persia, I dont understnad what you are asking :-( They are in a desktop folder inside debian directory [04:09] if thats what you want [04:09] tuxmaniac: Does your orig.tar.gz differ from http://revu.ubuntuwire.com/revu1-incoming/alliance-0709221900/alliance_5.0.orig.tar.gz ? [04:10] If so, does your orig.tar.gz contain a debian/ directory? [04:11] persia, yes [04:11] persia, orig does not contain debian/ [04:11] persia, i removed it. is that wrong? [04:12] tuxmaniac: You removed it? Did you have to repack for other reasons (licensing, zip file, etc.)? If not, it is wrong. [04:12] persia, changed some stuff and now its building fine on Hardy before I started "cleaning" up stuff :-D [04:13] Since this is the first package, I thought the orig should be "ditto" to src tarball and should not contain any contaminations? [04:13] orig should be exactly the file distributed by upstream, whenever possible. If upstream has a debian/, someone should tell them to remove it. [04:16] persia, my patch worked for you as well? [04:16] persia, i'm glad to hear that :) [04:16] nenolod: Yes. Crashes gone. Thank you very much. Please also forward the patch to Debian, GNOME, and the gtk maintainers. [04:17] persia, yeah. i'm going to send the patch on to bugzilla.gnome.org now. thanks for testing. :) [04:23] dang it, forgot my orig.tar.gz [04:23] some days I hate packaging [04:26] persia, http://bugzilla.gnome.org/show_bug.cgi?id=507605 [04:26] Gnome bug 507605 in recent-files "[patch] gtk_recent_files_menu_populate() does not guard properly against recursion" [Critical,Unconfirmed] [04:26] nenolod: Be sure to register that in Malone :) [04:27] persia, done === dmb_ is now known as dmb [04:28] Excellent. I don't know if it will make hardy, but expect it soon enough. [04:28] well, that patch needs to go into the gtk+ we ship in hardy, as it fixes a fairly nasty bug [04:29] (not that the bug affects me anymore, mind.) [04:30] * nenolod sends to debian too [04:30] nenolod: You might subscribe the main sponsors then, to request upload. [04:30] persia, yep [04:31] you probably want to just ping lool or slomo, then [04:32] they already have an upload pending for a gdkpixbuf issue [04:32] (on the Debian side) [04:32] now, how do i get a program into the add/remove list? [04:33] Hobbsee: gnome-app-install? [04:33] does that just require mvo rerunning his script, or? [04:33] That works by .desktops. [04:33] Unlike Ubuntu Restricted Extras and Kubuntu Restricted Extras, in Gutsy Xubuntu does not have an entry in Add/Remove... for its restricted extras. [04:33] Give you app a .desktop, and wait for mvo to rerun his script. [04:33] none of them have desktop files! [04:33] Hobbsee: Then you've a few packages to update :) [04:34] persia: but..but...the other 2 are already there, and don't have .desktop files in their sources at all [04:34] Perhaps there are some that have their .desktop's in the app-install-data source. [04:35] Hobbsee: You might try http://people.ubuntuwire.com/~persia/generate-desktop.bash. It's old and crufty, but leverages the debian/menu files to get some templates prepared. [04:35] ah, yes [04:35] Fujitsu: Quite a large number, actually :( [04:35] persia: Urrgh. Why? [04:36] Fujitsu: you're correct. do i have to put x-r-e in there manually, or mvo's script picks it up? [04:36] * Hobbsee thought mvo had a script for that [04:36] Fujitsu: Base pragmatism, really. On the other hand, for things like apache, I agree with that approach, as a menu file isn't appropriate. [04:36] weird, requestsync just got totally the wrong version to sync [04:36] Ah, perhaps. [04:37] LaserJock: you were expecting an experimental version? [04:37] no [04:38] I was expecting 0.8.5-1 and I got 0.6.6-3 [04:38] which is really ancient [04:40] hmm, do I have to have sid deb-src lines for requestsync to work right? [04:41] As far as I know it uses rmadison. [04:41] LaserJock: Yes. [04:41] which is it? [04:41] :-) [04:41] I thought it used rmadison for versions, and sid deb-src for changelog. Does it use changelogs.debian.org now? [04:42] It has always used changelogs.d.n, AFAIK. [04:42] * persia uses requestsync once per release, and has yet to be satisfied [04:42] well, ok here's the thing [04:42] the changelogs it picks up are right [04:42] but in the subject text and first paragraph it get's it wrong [04:43] right. u-r-e finally updated [04:43] no more bugs in it, either [04:43] LaserJock: What does rmadison -u debian $package tell you? I remember someone complaining about an issue where it wasn't in sync in all architectures in Debian. [04:44] ohhh [04:44] gchempaint | 0.6.6-3 | unstable | m68k [04:44] gchempaint | 0.8.4-2 | unstable | mips, mipsel, s390 [04:44] gchempaint | 0.8.5-1 | unstable | source, alpha, amd64, arm, hppa, i386, ia64, powerpc, sparc [04:44] is it picking up the m68k line? [04:45] Ah, probably. [04:45] Shouldn't it be using `-a source' or something [04:45] *? [04:46] * persia continues to deprecate requestsync as relying too much on the delicate Debian infrastructure, encouraging laziness (if you're testing and building, you have the source and changelog locally), and failing to hint about requirements for syncs as each freeze passes. [04:46] Fujitsu: Doesn't matter. Not supported by p.qa.d.o at this time. Kmos reported a bug, but I don't know where. [04:46] persia: I just use it to get the format right since people seem to be more picky these days [04:48] LaserJock: Format is simple. "Please sync $package $version ($component) from $source_dist ($component)". Rationale section describing any dropped ubuntu variation, reason for any freeze exception, and confirming testing. Changelog since last version imported into Ubuntu. [04:49] yeah, well I don't do syncs that often and people get irritated if you accidentally miss $component or something [04:50] Ah. Yes. $component for Ubuntu is important to help determine who needs to ACK (less important for you). $component in sync_source is important to get the right thing. [04:51] On the other hand, the vast majority of my non-sponsored uploads are sync requests, so maybe I have a different viewpoint than others. [04:51] right but at least 99.9% of the time $source_dist ($component) is Debian unstable [04:51] s/sponsored/sponsoring/ [04:51] LaserJock: "Debian unstable (main)", yes. [04:52] ah see ;-) [04:54] nixternal: yo homey, I finally joined your Vista army when I got my new laptop ;-) [04:54] haha [04:54] new lappy ey? [04:54] ... "Vista army"? [04:54] !nixternal [04:54] !nixternal [04:54] Oh no! The pointy-clicky Vista lover has arrived! He's rumoured to be giving out free money, too! [04:54] hahahahahaha [04:55] nixternal: yeah [04:55] the "Cancel or Allow" thing is driving me nuts [04:56] how many dialog boxes do i have to go through just to open up a .exe [04:56] no less than 2 [04:56] Plop. A “Cancel or Allow” dialog box is about to pop up. Cancel or Allow? [04:56] lol [04:56] LaserJock: You do know that if you hadn't actually run it, you'd be eligible for a refund, right? [04:57] I don't particularly care tbh [04:57] I'll use it for some games maybe [04:58] oh, so this means LaserJock is actually /running/ Vista, how odd [04:59] not at this moment [04:59] * nixternal boots into vista to play some call of duty 4 [04:59] persia: are people actually able to collect that refund these days? [04:59] but until I put Ubuntu on it I gave it a spin, haven't not seen it [04:59] I did last year slangasek [04:59] I have two thinkpads I wouldn't mind a refund on :) [04:59] with XP [04:59] slangasek: I've heard of people doing it recently. [04:59] but in what countries? [04:59] US for me [04:59] slangasek: In some places, and from some resellers, yes. More people pressing legal cases when the reseller ignores them would help. [04:59] ok [05:00] right, these are direct from Lenovo, probably not worth my effort then [05:00] slangasek: Why not? If you've never installed, give them a call. [05:00] how much do you get? [05:01] LaserJock: You ran it: you're no longer eligible :( You have to have never used the software. [05:01] persia: I know, I just wondered how much it's worth [05:01] how are you supposed to prove never having run it? [05:01] LaserJock: I think about half the cost of a retail copy. [05:02] nixternal: Didn't you blog about it? Do you have the archive URL handy? [05:02] Isn't the key accepting the EULA in the OEM post-installation bit? [05:02] persia: that's not bad. [05:02] don't know if I blogged about it [05:02] I got $97 back [05:04] nixternal: What evidence did you need to supply? [05:05] that you said no and removed anything from the hard drive...I took it to best buy and let them verify it for me [05:05] they will cancel your registration number for vista anyways, and you will know when that happens, as Vista becomes useless at that point supposedly [05:06] I think they turned that `feature' off a while back. [05:06] Because there were too many false-positives. [05:06] well, I never said no because I never booted it into Windows before wiping it [05:07] so I don't know what evidence I'd be expected to supply [05:08] slangasek: Did wiping it include the recovery partition, if any? [05:08] sure [05:08] I don't want Windows to ever recover [05:08] heh [05:08] Fair enough. [05:09] So you obviously don't care about what you offer to someone who you may resell it to after its lived its useful live for you? [05:09] i.e no OS to offer besides linux [05:09] I've never resold a computer [05:09] LaserJock: You forgot the Rationale section. Why grant the freeze exception? Does it work in hardy? [05:09] slangasek: Ah ok then. [05:09] and I wouldn't do business with Windows users anyway. :) [05:10] persia: :( I just did what request sync told me [05:10] TheMuso: I don't see how "no OS to offer besides linux" is a bad thing :p [05:10] I've never sold a computer either [05:10] Any MOTUs out there willing to review package photoml (http://revu.tauware.de/details.py?package=photoml)? It's already been advocated once, and the remaining (hopefully) few issues pointed out by persia have been addressed in the most recent upload. [05:10] I use them 'til they die [05:10] LaserJock: Yes. I know. That's part of why I don't like requestsync. [05:10] persia: I would agree, but the sale may not be possible if people don't agree. [05:10] persia: What freeze are we in? [05:10] ScottK: DIF [05:10] ScottK: Debian import freeze [05:11] anyway, if I were to resell a computer I'd market it as "own an Ubuntu laptop, as run by the release manager!" [05:11] I don't think I need a rationale for DIF, but I should say that it worked in Hardy [05:11] >:) [05:11] As I understand it, all syncs are fine as long as we don't break lots of things (like if we synced octave3.0 without deeper investigation). [05:11] sladen: heck yeah ;-) [05:11] slangasek rather [05:11] slangasek: haha [05:12] slangasek: Heheh. [05:14] persia: Doesn't that just mean it's not automatic. [05:14] There's no rule that says manual actions have to be justified. [05:15] ScottK: Not quite. It needs an ACK from a member of ~ubuntu-dev. I believe even members of ~ubuntu-dev should provide rationales for freeze exceptions (even if it's just "I think it's a good idea" or "I want latest upstream") just for documentation purposes. [05:15] Non-members of ~ubuntu-dev are generally required to provide a rationale to convince a member of ~ubuntu-dev to ACK. [05:16] persia: I understand you think that, but we don't have any actual process requirements to that effect do we? [05:16] * nenolod subscribes ubuntu-main-sponsors to bug 180463 [05:16] Launchpad bug 180463 in gtk+2.0 "gnome-panel crashed with SIGSEGV in idle_populate_func()" [Low,Triaged] https://launchpad.net/bugs/180463 [05:16] it's basically the lowest Freeze barrier possible [05:16] ScottK: Process requirements? No. There's not even a requirement for a sync request bug at this point. [05:16] Personally, I think DIF is poorly named [05:17] It's really just the end of autosync [05:17] Especially for an LTS, I think we should really be considering updated applications to make sure they don't break things. sid is rough sometimes. [05:19] Maybe. Our release manager noted that any further syncs would be "Freeze Exceptions" when announcing DIF. [05:20] that's quite odd, IMO [05:21] * persia points at https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-December/000359.html [05:21] Fortunately for me, I haven't been warned by the MC not to do anything, so I can do whatever I want as we've established that one must be warned before being kicked out now. [05:22] ScottK: ;p [05:22] LucidFox: Can you please avoid touching sync bugs that are filed by MOTU? It creates unnecessary spam, and isn't particularly useful. [05:22] ScottK: You're a member of ~ubuntu-dev. By my proposed freeze exception process (ACK'd by a release manager), you can sync whatever you want. [05:22] persia: yes, that was, IMO, a bit unfortunate [05:23] persia: The MOTU process for deciding process isn't go ask an RM. [05:23] LaserJock: Why? Would you prefer a more restrictive freeze exception process? [05:23] ScottK: Right, which is why my proposed freeze exception process isn't policy. [05:23] persia: which should have read "merging packages that haven't yet been merged for hardy is a freeze exception", mumble 3am mails [05:23] persia: we've *never* had such a freeze [05:23] Fujitsu> How do I know if it's filed by a MOTU? [05:24] LaserJock: Right. Blame email sent at 3am :) [05:24] persia: Please let's stop inventing more freezes and reviews [05:24] DIF has always been "no more autosyncs" [05:24] ScottK: I didn't. I don't seek to do so. Even aside from all that, I still think Rationale is good practice. [05:24] wasn't there a follow-up mail in there somewhere that said "yes, it's an exception to the freeze; anyone with the corresponding upload rights is still allowed to use their own judgement"? [05:24] we've never had to file exceptions before UVF [05:24] LucidFox: If they've confirmed it themselves, they're probably a MOTU. If in doubt, click on their name and check, or get the Greasemonkey script that displays karma and related emblems. [05:25] All right. [05:25] LaserJock: it was never intended that the exceptions should need to get filed anywhere special [05:25] slangasek: Yes. That was my proposed freeze exception process. [05:25] DIF is poorly named, as it isn't a freeze really [05:29] persia: Could you please take a look over the new upload of photoml to make sure all of your concerns have been addressed? While you mentioned that you preferred not to officially review it again, it would be good to know whether one of the pickier MOTUs considers it acceptable so that I can address any remaining issues ASAP. [05:30] guest22: My memory is that you fixed a couple niggles, and were planning to fix the rest upstream for the next release. I'm likely happy. [05:30] slangasek: well, a 0 barrier freeze is what's confusing about the DIF stuff, IMO [05:31] we're saying "We are now in a Freeze and require exceptions, but exceptions are doing what you already do" [05:31] * persia agrees with Laserjock, despite having a preference for stability and rationale [05:32] persia: I would tend to think that that should be a general requirement .. [05:32] * ScottK will forgo the usual rant on increased bureacracy in Ubuntu as it's just to painful. [05:32] ScottK: What rant? Do you not agree with LaserJock? [05:33] ScottK: well, tbh, it's only perceived increased bureaucracy. DIF has no practical consequences [05:33] persia: Yes, that seems like a reasonable summary. When I uploaded the package addressing the issues you raised, the single advocacy was zeroed out, and the package dropped out of the lost of those close to being ready for acceptance. Any advice on how to request someone else to take a look at it for another review? [05:33] persia: I absolutely agree with laserjock. I think your proposals are entirely off base and unnecessary. [05:34]