[00:04] I guess most debian-edu* packages should be removed as the debian-edu source package has already been removed from jaunty [00:05] ScottK: re bug 527978, should I just upload it as a 0ubuntu1? (will waiting for it to land in Debian miss the freeze?) [00:05] Launchpad bug 527978 in groundcontrol "Please sync groundcontrol 1.6-1 (universe) from Debian unstable (main). [Launchpad now using openid breaks login]" [Critical,Fix released] https://launchpad.net/bugs/527978 [00:11] lfaraone: At this point I'd get it uploaded to Ubuntu. [00:12] debfx and ajmitch: It's not too late for removals, but we need bugs filed/subscribed to ubuntu-archive [00:12] ScottK: yep, that's what I was saying [00:13] OK [00:13] * ajmitch is *still* patiently waiting for build-dependecies to download before testinbuilding this package [00:13] ScottK: done, https://code.edge.launchpad.net/~lfaraone/ubuntu/lucid/groundcontrol/gc1.6.5, attached to bug, will propose for merging shortly. [00:13] OK. [00:14] * ScottK won't sponsor it so he can review it for the release team. [00:24] ScottK: I think nhandler offered to review it. [00:26] OK. Good. [00:28] ajmitch: could you ack bug #569959 ? [00:28] Launchpad bug 569959 in debian-edu-install "Please remove debian-edu-config and debian-edu-install from lucid" [Undecided,New] https://launchpad.net/bugs/569959 [00:28] persia: thanks for sponsoring the ftbfs fixes [00:29] debfx: Thanks for creating them. Nice to have working software. [00:30] does anyone have objections to removing/blacklisting debian-edu-*? I can't really see how they're useful, but I could be wrong [00:31] stgraber: Any thoughts on that? [00:31] * persia is of the "toss it: it's not helping" mindset, personally [00:33] I finally figured out why reverse-build-depends doesn't work for me: I thought it uses lucid by default, the help says the default is karmic but in fact it's maverick ^^ [00:33] debfx: Accepted your fixes. Thanks. [00:34] * ScottK leans in favor of removals like debian-edu stuff [00:35] debfx: It was lucid up until *very* recently, when it was switched to maverick for the next release. Extra points for submitting a patch that changes the help to indicate "the current development release" or has the help dynamically be correct based on the source. [00:35] current development release can be fetched from LP with a few lines of python, if you're prepared to depend on launchpadlib [00:36] persia: already checked out the ubuntu-dev-tools branch :) [00:36] launchpad.distributions['ubuntu'].current_series.name is what you want [00:37] ScottK: what time does this have to be in the queue by? [00:37] ajmitch: that [00:37] lfaraone: Sooner the better, but we have a day or two if needed. [00:37] ajmitch: that would make r-b-d require an internet connection [00:38] debfx: yes [00:38] and it's written in perl [00:38] or to store this somewhere [00:38] ajmitch: I thought I had them blacklisted last release... [00:38] ajmitch: (re edu) [00:38] lfaraone: debian-edu-* ? [00:39] ajmitch: yes. [00:39] I think u-d-t already depends on launchpadlib for some other stuff, but be nice if it used anonymous credentials to avoid needing to register credentials for yet another tool. [00:39] such as doing launchpad = Launchpad.login("ubuntuwire rcbugs", "", "", EDGE_SERVICE_ROOT) [00:40] Should it use edge though? [00:40] easy way to login anonymouly, though that code is written for karmic [00:40] probably not, but it's what I was used to using [00:45] I'm working on a utility to automate the updating of packaging to bzr/hg/git heads, and am planning on including it in u-d-t. I'm also intending to write a full testsuite for it, including sample repositories of each. (less than a couple KB, gzipped). Would this be accepted? (as if I didn't gzip the repos bzr would interpret them as nested git trees) [00:48] lfaraone: I think there exist several utilities that do that: check foo-buildpackage as a start. [00:49] The mr package may be even more interesting, as it's intended to work with arbitrary VCS. [00:50] persia: my goal is that you can do this regardless of what VCS you use yourself for your packaging, or even if you use none at all. [00:50] lfaraone, ajmitch: should I update the debian-edu bug to request the removal of debian-edu-*? [00:50] lfaraone: So, add a "null" module to mr :) [00:51] debfx: A new bug will be less confusing, but reference the old bug in the new bug. [00:51] persia: right now it pulls the upstream changelog from the upstream commits between now and the last release and formats it as a debian changelog. [00:51] persia: that's fine. [00:51] lfaraone: Please *don't* do that. There's a reason we ship the upsteam changelog separately from the debian changelog. [00:52] You should ship both (as indicated by the various packaging guides, and supported by lintian), and you should put "New Upstream Version" when you upload a new upstream version, and only note critical changes that are especially interesting. [00:52] * ScottK has some binary New to do thanks to debfx. [00:52] persia: we're asssuming upstream lacks a changelog. [00:52] lfaraone: That's either a bad assumption, or supports poor practices on the part of upstream. Please don7t. [00:52] persia: so you're saying http://packages.debian.org/changelogs/pool/main/p/pianobar/pianobar_0+git20100420.3072c5a-1/changelog is terrible practice? (for an upstream which only has snapshots) [00:52] Yes. [00:54] 1) bad of upstream to only have snapshots, 2) bad of upstream to rely only on VCS logs for changelog, rather than describing things for end-users, 3) annoying verbosity in debian/changelog that is also available in an upstream changelog (even if the package source build requires scraping it out of the upstream VCS with git shortlog) [00:55] persia: According to DPM § 4.4, debian/changelog "includes modifications made in the Debian package compared to the upstream one as well as other changes and updates to the package." [00:55] persia: that excludes upstream changes? [00:56] Generally it does. [00:56] It's sometimes considered good to mention major changes in the package. [00:57] lfaraone: The key bit is "compared to the upstream one" [00:57] That's since apt-listchanges just shows the Debian changelog. [00:57] lfaraone: But that comparison only makes sense when the upstream changelog is also made available. [00:57] But it's just key bits, not the whole thing. [00:58] The other thing about the pianobar changelog is that it has lots of frequent uploads, which indicates either that you're spending a lot of time pushing every patch, or that upstream is highly unstable and buggy. [00:59] persia: former, I've only had it crash on rare occasions. Which is why I wrote said script to automate this. [00:59] But it really deoesn't help most users to get a new downoad every day or two. [00:59] I test the new upstream release for about a day, then put it up. [00:59] Most users want to have things just work, and don't want updates. [01:00] persia: then they should track testing. [01:00] (no?) [01:00] No. [01:00] A maintainer should make the package as close to perfect as possible, and release it. Then focus on someting else (maybe working to make upstream perfect, maybe another package, etc.) [01:01] persia: a good number of these uploads are either fixes, or new features. [01:01] When there's a new upstream release that's well tested and offers significant advantages to users, that should again be prepared with effort to make it as perfect as possible. [01:01] persia: where should I file a package blacklist bug? [01:02] debfx: In launchpad, against the package. Typically it's just added as a note in the package remove request. [01:02] In the rare case where we want to blacklist-but-not-remove, it gets it's own bug. [01:03] lfaraone: The other thing with frequent uploads is that the Debian buildd network is overloaded and behind, so by uploading very frequently you delay the transition of other packages to Testing. [01:03] lfaraone: Check with someone else, but it's very much not my style. The complete lack of closing any bugs reported in Debian indicates that the selection of fixes and features appears more interseting to someone closely watching upstream than someone who7s just using it. [01:03] persia: it would be a request to blacklist and remove debian-edu-* [01:03] Then again, I make a practice of packaging stuff where upstream is so stable as to appear dead to most folks, so perhaps I'm biased :) [01:04] debfx: Right. Generally if you request removal of stuff still in debian, the archive-admins will blacklist at the same time. It doesn't especially hurt to note it in the bug, but it may not help. Having an extra bug just makes the archive-admins have to process more bugs. [01:04] * micahg seems to gravitate to stuff that moves fast upstream [01:05] Speaking of which, where's seamonkey? [01:05] in progress :-/ [01:05] people found a few issues [01:06] debfx: You hit a few gcc 4.4 bugs today: any idea why http://launchpadlibrarian.net/44677571/buildlog_ubuntu-lucid-armel.musescore_0.9.6~beta1+dfsg-0ubuntu1_FAILEDTOBUILD.txt.gz would be an arch-specific build failure? [01:06] (I'm not asking for a fix, just curious if it is obvious to someone else) [01:10] persia: Typedef for double on all platforms except for those using CPUs with ARM architectures. On ARM-based platforms, qreal is a typedef for float for performance reasons. [01:10] instead of double it should return qreal [01:10] Aha! That directly contradicts the bit someone told me about not using floats in armel for performance reasons, but certainly explains the oddities :) [01:14] persia: not sure why it doesn't automatically typecast float to double [01:14] Doesn't matter. Not going to be fixed for lucid. [01:15] ScottK: shooting for morning [01:15] When we find out what new toolchain features will be enabled on armel for maverick, we can ask about that sort of thing, although it may have to wait for a new ABI from Qt. [01:15] micahg: What timezone? [01:15] ScottK: CDT [01:15] UTC-5? [01:15] yes [01:16] micahg: OK. Make it early then. I'm flying from -0400 to -0700 tomorrow and probably need to get it done before I'm in the air. [01:16] ScottK: what time is that? [01:16] micahg: Around lunch time. [01:17] I don't want to depend on airport wireless to get it done. [01:17] k, well,I might end up staying up to finish then [01:17] in which case morning in Europe [01:18] OK. [01:18] ScottK: also what to do with bug [01:18] oops [01:18] bug 532232 [01:18] Launchpad bug 532232 in lightning-sunbird "Please update lightning extension to version 1.0 for use with Thunderbird 3" [Wishlist,Triaged] https://launchpad.net/bugs/532232 [01:19] * micahg seems to have a broken keypad [01:25] * ScottK looks [01:27] micahg: Is it totally broken as is? [01:27] ScottK: lightning is, sunbird isn't AFAIK [01:28] ScottK: Thunderbird 3 requires lighning 1.0 beta 1 [01:28] But we're just talking about updating lightning, right? [01:29] ajmitch: Still about? bug #528957 would benefit from gilir's patch (I've tested it a fair bit, and so have some others). [01:29] ScottK: well, it's built out of the same source, and there's more to the story [01:29] Launchpad bug 528957 in wesnoth "mouse button clicks not detected in windowed mode" [Undecided,Confirmed] https://launchpad.net/bugs/528957 [01:29] micahg: OK. [01:29] ScottK: upstream has discontinued development on sunbird and is only developing lightning, we were thinking to only build a new lightning and a stub sunbird [01:30] OK. [01:30] persia: still about, just been having some ssh issues :) [01:30] micahg: So does sunbird get removed? [01:30] ScottK: it's too late for the ideal thing which would be to rename the source, but yes, I think sunbird would get removed [01:31] ajmitch: Sorry to hear that. May you be blessed with high entropy input. [01:31] persia: just curious why you're pinging me about it? [01:31] ah, patch is against a main package [01:33] I'm guessing that libsdl1.2 isn't on the CDs & it's not too late to push an upload fir it [01:34] The trick is to have it all compiled-like before the image rebuilds happen Monday UTC-7 :) [01:34] OK. Maybe SRU then. Alas. [01:34] could someone please have a look and possibly ack bug #569959 ? [01:34] Launchpad bug 569959 in debian-edu-install "Please remove all debian-edu-* packages from lucid" [Undecided,New] https://launchpad.net/bugs/569959 [01:35] persia: it's the release team's call, I'll set it building here [01:35] * ajmitch would really like an SSD for the laptop about now [01:36] debfx: ACked [01:36] I checked & debian-edu is on the blacklist, just not the other packages [01:37] ajmitch: ok, thanks [01:40] persia: to be honest, it looks like something that'll probably be SRU material, given that it's just affecting something in universe at this stage [01:40] ScottK: does that plan sound ok for lightning? I think we also need to update the locales or we lose all the translations [01:40] * persia wonders why debootstrap --variant=buildd is installing exim4 in Debian [01:40] ajmitch: Fair enough. [01:40] * persia was just reviewing "unseeded bugs" opportunities to sponsor, and that appeared, except it needs a "core" sponsor. [01:41] micahg: I'd like asac or someone to ack the sunbird removal, but generally, yes. [01:41] ScottK: able to comment on http://launchpadlibrarian.net/44484053/libsdl1.2_1.2.14-4ubuntu2.debdiff being SRU or fixing it now? [01:41] ScottK: k, he or chriscccoulson would be doing the uploads [01:42] ajmitch: SRU. It doesn't fit the RM's criteria for post-RC Main uploads. You can upload to -proposed now. [01:42] ScottK: thanks [01:42] No need to wait. [01:43] It just won't get accepted until Thursday, modulo release team mistakes about accidentally accepting stuff in proposed (I did that once already) [01:43] * ajmitch will change version & target release for it [01:43] Thanks. [01:50] Anyone want to review the (large) changes in bug #565206? I don't know enough about the software in question to have any idea if this would be a good thing. [01:50] Launchpad bug 565206 in scidavis "Please update to 0.2.4 as it fixes compatibility issues with qt 4.6" [Undecided,Confirmed] https://launchpad.net/bugs/565206 [01:50] * persia thinks it needs review *before* getting an FFe reevire [01:51] s/reevire/review/ [01:55] persia: From reading the changelog, the deprecation warnings concern me. It does sound like the package is pretty broken at the moment and so I think a bias towards accepting is generally appropriate. [01:56] I can confirm that scidavis is not alone in having gotten bitten by some changes on Qt 4.6. [02:14] ScottK: Thanks. [02:15] Anyone up for testing it? I'll enqueue it, but I'm not sure I'll hit it soon enough to do it justice and get it uploaded. [02:20] how testable is it? [02:22] You'd want a dataset, and some ideas how to plot it nicely, at least. === nobawk is now known as nobawk|away === nobawk|away is now known as nobawk [03:45] geser: If you get a chance, it looks like libepc is in need of one of your GTK deprecation fixes. [06:11] ScottK: got a wine1.0 package ready to upload, will followup with wine1.0-gecko, new wine1.2 and wine1.2-gecko that conflict properly, and then finally a new vst [06:12] OK. [06:48] persia: That's on intention not in the series file - see the difference between the .in file and the one without - and the debian/branchcheck script. :) [06:53] ScottK: ok, all uploads except -vst done [06:54] right. YokoZar you know what time it is here, right? [06:54] ScottK: Feel free to do it in the morning ;) [06:54] Which one needs to build before you can do vst? [06:54] wine1.0 [06:55] OK. Let's see if I can manage to stay awake for that one. [06:56] It's best if they come in a group methinks, so feel free to go to bed and do it when you're fresh ;) (IIRC, it's about 2am there?) [07:02] It is. [07:02] I have to be up in ~4 hours, so I'll only be so fresh .... [07:09] ScottK: progress on SM, I think the package works now, having one more person test, then working on integrating fixes back into branch [07:16] Great. [07:17] YokoZar: I let the two wine1.0 packages in. They'll hit binary New after they build, it I'll get that in the morning. [07:21] good morning [07:41] morning dholbach [07:41] hey ajmitch [07:44] heya dholbach [07:45] hey imbrandon :) [07:50] hi [07:55] my package IOK(Indic Onscreen Keyboard) is already in ubuntu repository, now i have to bring this to debian repository how to do that? [07:55] i follow this link https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers?action=show&redirect=ContributingToDebian and made changes in "how do i do" then what should i do? again should i send that package to revu.ubuntuwire.com? [07:59] lfaraone: done [08:03] suji11, the equivalent would be mentors.debian.net [08:04] imbrandon: Thank you:) [08:09] can i remove a package from revu.ubuntuwire.com which is unknowingly sent by me ? [08:16] suji11, just archive it === nobawk is now known as nobawk|away [08:21] suji11: at the first sight your package looks quite good, but there are still a few things that could be improved: 1. lintian -I complains about hyphen-used-as-minus-sign and already did when you created the package 2. people maintaining packages in debian generally have a given name and a family name and use both in their packages 3. the description should be improved, I think the debian developers reference has something about how to ... [08:21] ... write good descriptions === nobawk|away is now known as nobawk [08:25] suji11: http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis [08:46] ScottK: libepc done === nobawk is now known as nobawk|away === nobawk|away is now known as nobawk [10:20] imbrandon: my package IOK is now in the version of 1.3.9 but i have to update it to 1.3.10 , how to do that? === yofel_ is now known as yofel === nobawk is now known as nobawk|away [11:08] er... [11:14] any archive admins here? [11:25] ivoks: What's up. [11:26] ScottK: bug 570096 [11:26] Launchpad bug 570096 in cluster-glue "[FFE] Please sync cluster-glue (universe) from Debian unstable (1.0.5-1)" [High,Confirmed] https://launchpad.net/bugs/570096 [11:26] ScottK: abi is broken, hell is freezing :) [11:26] Ah. I can't do the actual sync for that. [11:26] * ScottK loooks [11:27] we already have confirmations of problems it is causing :/ [11:29] OK. [11:31] ivoks: See #ubuntu-devel. That should take care of it. [11:31] ScottK: good night :* [11:43] nigelbabu: ping? [11:45] Just looking through https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved is it worth linking Workflow para 2 - " forward the bug and patch upstream" to https://wiki.ubuntu.com/Bugs/HowToTriage#Forwarding upstream ? [11:45] I had to search for it.. say yes and I'll make the change. [11:47] Be bold and do it! [11:48] :) [11:48] He can always rollit back I guess [11:48] erm [11:49] "If the change is significant enough to be fixed in Ubuntu, get the patch uploaded." [11:49] what of forwarding to Debian in that case? [11:50] hmm === nobawk|away is now known as nobawk [12:57] Ciemon: yes, make the change, was likely an oversight [12:57] Is it possible to cowbuilder --create ubuntu chroots on a Debian system? What --mirror should one use for that? [12:58] Rhonda: yes, and the normal ones you would use for ubuntu updates [12:58] eg .archive.ubuntu.com [12:58] Thanks. Hmm, now cdebootstrap tells me E: Unknown suite $everything [12:59] So I think I would need to create some additional files. :) [12:59] debootstrap ... [12:59] Hmm, but there is /usr/share/cdebootstrap/generic-ubuntu in the cdebootstrap package, makes me wonder … [12:59] dpkg -L debootstrap | grep whatyouwant | wc -l sould print 1 [12:59] Rhonda: yea, the debian wiki on it looks to cover the adding of suites [13:00] ubuntu suites, that is [13:00] Ah, /usr/share/cdebootstrap/suites :) [13:00] Oh, it only goes up to intrepid. [13:02] should be trivial to "backport" the needed packages from ubuntu lucid OR ( what i would recomend ) just add the needed suites manualy to the scripts [13:02] just make sure if you manualy do it you record your changes etc for updates [13:03] Ah, seems I need to have ubuntu-archive-keyring.gpg installed, too. [13:03] yes if you dont want the gpg errors ;) [13:03] Rhonda: are you doing this on unstable ? [13:04] imbrandon: lenny [13:04] Rhonda: ahh , you might look at the sid packages, they are likely to have newer scripts [13:04] but honestly thats all they are, scripts that are basicly copy/pasted from release to release with minimal to no changes [13:05] I am currently switching from cdebootstrap (lenny) to debootstrap (lenny-backports). That might be also pretty helpful. :) [13:05] ;) [13:06] if you run into a snag holler, its been a while since i have run debian proper but there are plenty of us arround that have and should be able to get ya threw it [13:06] both, debootstrap and cdebootstrap-static from sid work on lenny [13:06] mostly on my dev machines i run ubuntu lts's with other ubuntu and debian chroots, so i do the opsite ;) [13:07] carstenh: Sure, but I like to keep my system as clean as possible. You know that I'm a perfectionist in my approaches. :) [13:07] heh, dev machine and clean ? hahahaha , i mean good luck .... just teasin [13:07] ScottK: DktrKranz uploaded gc 1.6.5 to unstable 5 hours ago. Should I convert that back to a sync request? [13:08] imbrandon: That's why one uses tools like cowbuilder in the first place - remember? :) [13:09] Rhonda: you just need to redefine "clean", I use a private partial sid mirror as excuse to install such packages on stable [13:09] * Rhonda jumped at the sight of "1.6.5" and thought wesnoth. %-/ [13:09] Rhonda: if the needed suites arent in lenny-backports you can also use ~/.* files too to "amend" the scripts [13:09] its just a bit more involved in the setup [13:09] not much though [13:09] imbrandon: Sure, but with debootstrap from lenny-backports it at least started something, which is more than before. :) [13:09] :) [13:10] And I usually do a "cp -a squeeze sid" anyway because sid has issues with bootstrapping anyway, so that part isn't troubles here. [13:10] persia: i uploaded topgit to debian today, including the patch that you uploaded to ubuntu. if you want to tag this in ubuntu somehow ... [13:11] Rhonda: yup, basicly the same concept [13:12] * imbrandon needs to read a couple of chapters in his shiney new git book today [13:14] i should probably have a debian proper vm , hum, maybe something else to put on my todo for this week [13:15] anyone else excited about pbuilder-cross :) hehe [13:18] imbrandon: I've always been able to get away with pbuilder-sid login, unless something requires dbus or anything odd like that. [13:19] lfaraone: yea mostly it does, but for X and corner cases it good to have one arround [13:19] dosnt take nothing but hdd space and thats easy to come by [13:25] what's pbuilder-cross? [13:29] hyperair: new crossbuilder in expirimental with multistrap vs debootstrap [13:30] imbrandon: er. in english, please? [13:30] exactly how "cross" are we going? [13:30] eg pbuilder-cross arm some.dsc , on a x86 machine [13:30] cross-arch? [13:30] is it something like qemubuilder? [13:30] sorta [13:30] interesting [13:31] what does it use? [13:31] gcc's native cross compiling ability and multistrap [13:36] ScottK: now that gc1.6.5 is in debian, there's no reason to upload the 0ubuntu1 version, right? [13:38] lfaraone: At this point a straight upload is easier. [13:40] ScottK: Huh. Are the archive admins busy handling last-minute removals, or am I missing something? [13:40] imbrandon: what's multistrap? [13:41] lfaraone: Generally they are all busy people. Archive admin is not a full time job. So I wouldn't assume there will be any availability to do it. [13:41] hyperair: like debootstrap but for bootstraping other arches easier than traditionaly with debootstrap + apt-cross [13:41] lfaraone: If someone uploads -1 using requestsync, we get to ~ the same place. [13:41] requestsync/syncpackage [13:42] imbrandon: that's cool stuff. (and this is the first time i've heard of apt-cross) [13:43] Does that mean essentially sponsoring an upload, from Debian? [13:43] iirc archive admin duties are only done like 4 out of 7 days a week and of those 4 days its "rotated" between the admins for whos "day" it is, that was the case last i looked into it more than a year ago [13:43] it's just directly uploading a sync instead of waiting for an AA to push the button [13:43] ah [13:43] Daviey: Yes. Essentially you take the Debian package, run syncpackage over it to get a .changes that ~ looks like it came from Debian, and upload. [13:44] ScottK: okay. but you can't upload it, since you have to review it. [13:44] This is true. [13:44] ScottK: do I need ubuntu-release approval before a motu would touch it? [13:44] i got waiting for approval :) [13:44] I suspect imbrandon will upload it. [13:44] i can upload [13:44] lfaraone: No. People should upload and wait for reviews in the queue. [13:45] imbrandon: thanks, that'd be awesome. [13:45] could we prioritize this? [13:45] for example, i'm waiting to get approval for cluster-agents [13:45] cause i can not upload two other packages untill this one is built [13:45] ScottK / lfaraone : is the package in question ready for upload or are we talking here in a little bit ? [13:46] imbrandon: it is already in Debian. [13:46] ivoks: Can you not build depend on a $VERSION? [13:46] imbrandon: http://ftp.de.debian.org/debian/pool/main/g/groundcontrol/groundcontrol_1.6.5-1.dsc [13:46] ivoks: i'm sorry i'm not familiar with what you have going [13:46] lfaraone: k, i'll grab it here in justa few moments and ping ya when its uploaded ( should be less than 30 min ) [13:48] Daviey: i could [13:48] ivoks: If you do that, then you should be able to fire off your two uploads; and they should just get a Dep Wait. [13:48] Ciemon: pong. but I guess you're question is already answered :) [13:48] ScottK: what was the reason syncpackage was removed from u-d-t, by the way? [13:49] lfaraone: Because historically we have discouraged use of things like this and adding it right before release without a lot of discussion didn't seem like a great idea. [13:49] BTW, it wasn't removed, it's in the source, it just doesn't get included in the binary. [13:50] ScottK: ah. I'm confused: what's the harm in this if Archive Admins would just take the action based on the MOTU's request anyway? [13:50] Daviey: but that's not correct [13:50] (I don't see why it's discouraged, that is) [13:50] ivoks: How so? [13:51] Daviey: cause new version of lucid's package B could work with karmic's package A [13:51] lfaraone: There's more risk of error if the package is touched manually than done via the archive. [13:51] Daviey: it's just that current lucid package A is broken [13:51] ivoks: It's accepted, FYI. [13:51] Daviey: so, making a hard dep on new version is wrong [13:52] ScottK: thank you! :) [13:52] ScottK: i'll have one more :/ [13:52] YokoZar: Don't forget to file a bug for removal of the wine source package (if you didn't already). [13:52] OK [13:52] ScottK: okay. I just think that if we had a method for MOTUs to take the action directly, it would save the AAs a lot of work. Especially since from what I can tell the AAs aren't reviewing the request. [13:53] lfaraone: The desired solution is a button in LP. [13:53] ScottK: yes, that would be ideal. [13:53] ScottK: so what we have now isn't for some oversight reason, just because we don't have the technical measures to work around this? [13:53] ivoks: Hmm, i've done that multiple times.. Do you have a quote from Debian policy, or similar that states it shouldn't be done? [13:54] Daviey: i said it isn't correct, not that there's a policy :) [13:54] lfaraone: Someone needs to implement the button in LP is the only reason we don't have it. [13:55] ivoks: Ahh! It's a trick i've done a couple of times to ensure multiple packages get built in the correct order; therefore linking against the version i want it to. [13:55] ScottK: okay. is there a bug report for that? (I might want to look into implementing it in the copious free time I'll have after Lucid and Finals) [13:55] Daviey: Artificially bumping version requirements is not a good idea. I do it sometimes myself, but am careful to docment the fact that it's artificial and when it can go away. [13:55] lfaraone: I'm sure there is. It'll be against soyuz. [13:56] ScottK: it's all in the changelog :) [13:57] ScottK: is syncpackage broken atm ? [13:58] imbrandon: Not that I know of. [13:58] ScottK: hum ok [13:59] E: No credentials found for 'ubuntu-dev-tools', please see the manage-credentials manpage for help on how to create one for this consumer. [14:00] ScottK: not afaict, but bug 529933 seems similar. (and one that would need unblocking before we can add the button [14:00] Launchpad bug 529933 in soyuz "people with upload privileges are not allowed to use syncSource" [Low,Triaged] https://launchpad.net/bugs/529933 [14:00] I'm almost certainly not the one to be discussing LP development with. [14:00] ScottK: ~/.bin/syncpackage groundcontrol_1.6.5-1.dsc lucid [14:00] * ScottK has no idea about it. [14:00] then i get that [14:00] hum hum [14:01] Weird. [14:01] and a big fat traceback [14:01] imbrandon: do you have your credentials stored? [14:01] imbrandon: does "requestsync --lp hello" work? [14:01] imbrandon: I gather someone has "improved" the original version. [14:02] lfaraone: Why on earth would someone make a script require authenticated access to LP to read information? [14:02] Now I'm really glad I didn't include it. [14:02] lfaraone: no i dont , but why should i need it [14:02] ScottK: I've got no idea, but that's a problem for later :) [14:02] ScottK: It was probably written before LP API had anon access. [14:02] imbrandon: try the original at http://people.canonical.com/~pitti/scripts/syncpackage I guess :) [14:03] Daviey: We've had a script that worked for years. [14:03] (which does not seem to use the API) [14:03] ScottK: But that answers why it requires authenticated access to purely read public info. [14:03] imbrandon: Use this one http://people.canonical.com/~pitti/scripts/syncpackage [14:03] Daviey: No. That's how. The why is someone is an idiot. [14:04] That's the unimproved one [14:05] seems somewhat harsh. ho hum. [14:06] Right, the LP API stuff in udt could be improved to use anon access as appropriate [14:06] ScottK: http://paste.ubuntu.com/422767/ [14:07] from "unimproved" [14:07] . o O ( and maybe syncpackage could be made to fallback to the old apt-cache madison way ) [14:08] Ah. [14:08] where is it getting the '2.5' ? [14:08] That's the a python thing [14:09] ugh ok so i need to force it to use 2.5 ? or ... [14:09] This is the exact class of package that pitti's version didn't work with. [14:09] I think mine will. [14:09] heh [14:09] k [14:12] Checking and then I'll get you the fix [14:14] imbrandon: http://paste.debian.net/70708/ [14:15] With that it works. [14:15] Daviey: Actually I think it's not harsh at all. [14:15] Daviey: If you consider that my LP ID is allowed to put new code into -updates for all Ubuntu users, you might then get an idea why I think it's lunacy to give any more code rights to use it than absolutely necessary. [14:16] ScottK: The authors of the tools should have written in anon API access before it existed? [14:16] Daviey: No. They should have kept using rmadison until it did. [14:16] or worse, screenscrape? [14:16] ScottK: ok. [14:16] As I said, we've had a script that worked reasonably well since before the LP API even existed. [14:18] ScottK: Oh aye. [14:21] ScottK / lfaraone : uploaded [14:22] Thanks. [14:22] BTW, it took a long time to figure out changing only those two lines .... [14:22] ScottK: heh [14:23] hum manage-credentials seems a bit broken too atm [14:23] * imbrandon looks more [14:26] ugh, better things to do, but yea manage-credentials is complaining about not reading something from /tmp/ [14:29] Ah! Wait! … erm. … how can I hand cowdancer the components that it should look at? It seems to only look at "main". [14:30] pbuilder uses --components "main contrib non-free" [14:30] lfaraone: " - Fixes to fixes" hahahah seriously ? [14:30] Right, /me tries --components 'main universe' now. [14:31] pbuilder update --overrite-config --components ... [14:32] imbrandon: I know, right? :) [14:32] carstenh: I can only update if there is something. the create failed. :) [14:32] And if that would be the case I'd just do sudo vim hardy/etc/apt/sources.list [14:37] lfaraone and imbrandon: Accepted. [14:37] Thanks. [14:41] ScottK: thanks again. [14:48] * Rhonda thinks she needs to set a few also affects for wesnoth-1.8 in the wesnoth bugs … [14:52] hi all, packaging newbie here have hit a problem when running debuild -S hopeing someone can help me :) [14:56] the error I am seeing can be seen here: http://ubuntu.pastebin.com/HJW3C2PM [14:57] ScottK / lfaraone : ty ty [14:58] * Rhonda hides behind persia, I fumbled with bug #109434 [14:58] Launchpad bug 109434 in wesnoth "Installing a server for a game automatically auto-inits and runs every boot." [Wishlist,Incomplete] https://launchpad.net/bugs/109434 [15:00] let me guess, someone dosent think it should [15:01]