[00:17] one question, in build-depends, is it ok to put like this: mono-gmcs (>= 1.9.1+dfsg-1ubuntu1) or could it just be like this: mono-gmcs (>= 1.9) [00:24] asac, is this ok for debian/changelog??: - debian/rules: Added configure flag to pass libxul-embedding-unstable as default [00:24] RoAkSoAx: does it work? [00:24] asac, yep [00:25] it builds [00:25] good [00:25] RoAkSoAx: yes, document remaining changes [00:25] and add that youa dd ed the configur flag to fix build-bustage :) [00:28] asac, is it ok like this: http://pastebin.ubuntu.com/22463/ ??? [00:32] RoAkSoAx: why not. maybe make one sentence out of the last changelog entry [00:33] asac, ok thank you very much for your help. i really appreciate it :D [00:35] RoAkSoAx: welcome [00:35] RoAkSoAx: are you here regularly? [00:35] RoAkSoAx: The LP syntax should be (LP: #xxxxxx) [00:35] i am about to update gecko-sharp ... once that is done blam might need a respin or something [00:35] cannot tell for sure right now ;) [00:36] just wanted to let you know [00:36] asac, yeah i'm usually around... just ping me when you update gecko-sharp to check it then.. i'll wait before i suscribe it to u-u-s [00:37] RoAkSoAx: no, go ahead and get your merge in now [00:37] we can fix it once the gecko-sharp update gets in [00:38] ok cool then ;) [00:38] Laney, ok ;) [00:38] asac, oh btw.. would it be better to have mono-gmcs (>= 1.9.1+dfsg-1ubuntu1) or mono-gmcs (>= 1.9) in Build-Depends? [00:39] RoAkSoAx: depends on what the requirements are. if you need at least the 1.9.1+dfsg-1ubuntu1 package then you need to specify that [00:39] if you just need any package build from >= 1.9 upstream release [00:39] use the latter form [00:43] asac, the build-depends in hardy was mono-mcs (>= 1.1.17) and in debian is mono-gmcs (>= 1.2.6), so i guess i just can leave it like the newer debian... without raising it right? or it would be better to change it to >= 1.9.1 [00:45] Unless you know that it'll fail with < 1.9, you should leave it at >= 1.2.6 [00:45] RoAkSoAx: depends on whether it would build with 1.2.67 ;) [00:45] err 1.2.6 [00:45] most likely thats a theoretical question [00:46] yeah, so i'll leave it with 1.9.1 [00:46] why 1.9.1? [00:46] i'd say if you are unsure, just leave it at whatever debian maintainer says [00:46] asac, ok, will do, thanks :) [00:47] The pkg-cli-apps team is generally pretty good about that :) [00:55] hi RAOF [00:56] emgent: Howdie. [00:57] RAOF: have you time for one fast upload ? [00:57] emgent: Not right now, but I may later? [00:58] ok np [00:58] Bug #242517 [00:58] Launchpad bug 242517 in tmsnc "Stack-based buffer overflow in tmsnc CVE-2008-2828" [Undecided,New] https://launchpad.net/bugs/242517 [00:58] for intrepid it`s ready. [00:59] i go to work for other ubuntu version [00:59] hi persia [01:25] ok, I've got this software I want in Ubuntu... I've registered a packaging-request (bug#242481) and created an amateurish package that seems to include the most important stuff (I.E SHOULD be basically ok to include as-is)... is there anything else I should do to ensure MOTU doesn't miss it before Intrepid? [01:27] rawler: Upload it to REVU for comments and corrections. [01:27] !revu [01:27] REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU [01:29] persia: ok, thanks.. will look into it.. [01:32] ok, the REVU-page tells me to ask here for keyring-sync.. someone awake with a quick-button? :) [01:38] hey all, I was taking a look at the ldapscripts package and had a question about the debian/patches/help-options.patch file [01:39] the file references several bin/*.patch files that aren't in the original source... should those be there? [01:44] nm, they're in the bebian package as well... so I guess they belong :) [01:53] oh, well.. no REVU-admin awake.. I guess I should go to sleep anyways.. see you all in the morning.. :) [01:53] rawler: I'll do a sync: sorry for being distracted [01:54] *ahh* no probs at all.. :) [02:04] rawler: sync complete. Try an upload... [02:04] great! thanks.. :) [02:05] but, ehm.. I already did an upload before, and that "worked" (as in, I was allowed to upload).. will that create problems? [02:07] rawler: Which package? [02:12] well, it seemed to have worked anyways.. I'm in.. thanks a LOT.. :) [02:13] btw, is REVU the same system that MOTU uses for uploads? [02:18] rawler: No. MOTU upload direct to the archive. REVU is for package review. dput is generally what we use to upload to the archive though. [02:18] nevermind.. i MUST go to bed.. I'll move my apartment in two days, so quite some things to do the next days.. [02:18] ok, thanks for the help.. see you! [02:25] hi [02:26] I find this annoying, yet useful [02:26] bzr tag $(head -n 1 debian/changelog | sed -e 's/[^(]*($[^)]*$.*/\1/') [02:27] SpookyET: You might also find the parsechangelog script useful. [02:34] persia: link? [02:40] dont we have skype in repos? [02:41] gnomefreak: medibuntu does [02:41] I didn't think it was distributable? [02:41] pwnguin: thanks [02:41] cannonical might [02:42] persia: dpkg-parsechangelog | grep Version | sed 's/Version: //' [02:42] A little more readable, I suppose [02:43] .. [02:43] cut -d\ -f2 [02:43] :-P [02:45] ? [02:46] SpookyET: You can use 'cut -d\ -f2' instead of sed 's/Version: //' [02:47] true [02:47] pssht, awk '/^Version/ {print $2}' [02:47] I had a fail push to launchpad. Now, I got a lock until 2:31 [02:48] always wanted to learn awk [02:49] I suppose you can use perl and python as well [02:49] I was suggesting cut since it's a little more light weight than sed [02:59] SpookyET: You can't just bzr break-lock? [03:00] RAOF: the lock is on the server [03:03] SpookyET: That's what break lock does [03:03] did nothing [03:04] bzr break-lock;bzr push [03:04] No, you need to provide the remote repo [03:04] bzr break-lock [03:04] should not it use the default [03:04] bzr push --remember [03:06] fixed. thanks [04:52] hi motus. i tried to dput a package to a ppa on LP, but forgot to specifiy a target. dput uploaded and (amidst other messages) told me: "Uploading to ubuntu (via ftp to upload.ubuntu.com)". does this mean i've accidentally attempted to upload to ubuntu? [04:54] trying again with correct config loads to ppa.launchpad.net, so i'im guessing i did. :( is there some action i need to take to de-clutter the build cue before itgets around to rejecting the upload, or just leave it be? [04:55] It means you tried to upload to Ubuntu. It'll get rejected. [04:55] It's not a problem. Everyone has done it. [04:55] I would think that if your key wasn't in one of the keyrings, it would reject it outright, before anyone saw it in any queue. [04:57] thanks both. do i wait for a rejection email, or it'll throw it out silently? [04:57] oh, emails here [04:58] " Signer has no upload rights at all to this distribution.: \o/ thank you! [05:03] I'm trying to get debian/rules to use my setup.py to prepare the package, but the resulting .deb will not install the python files [05:03] does anyone have experience rolling .deb's of python applications? [05:05] my setup.py: http://paste.ubuntu.com/22513/ [05:06] and debian/rules: http://paste.ubuntu.com/22514/ [05:07] superm1: Around? [05:07] yeah. wgrant [05:07] glanced over vlc and nothing stood out, but i was holding off a response until i could more throroughly look [05:07] RIght, thanks. [05:07] It seems to work fine. [05:07] i say push it, and if we catch something we'll fix it [05:08] Sounds good. [05:08] I'll mangle the version, as our upstream tarballs are named oddly. [05:08] how are you going to handle that? [05:08] Hopefully we can fix that once they finally get around to releasing 0.9.0 [05:08] i was wondering about htat [05:09] I just need to throw a 'release.' before the 'e' in the Debian version. [05:09] And take not to merge it manually. [05:09] *note [05:09] ah didn't realize you'll have rights to fix it in debian [05:10] No, I don't. [05:10] I'll just rename the tarball in Ubuntu. [05:10] kostmo: You should, at least, be using one of dh_pysupport or dh_pycentral [05:10] Until 0.9.0. [05:10] oh okay [05:10] Argh. The tarballs differ, of course. [05:10] Damn. [05:10] Because of the embedded x264 and co. [05:11] Why is it so hard for AV guys to release and use _libraries_? [05:11] maybe can you get siretart to change the name in debian? [05:11] or add an epoch possibly [05:11] No point. [05:11] It'll be for a few months at most. [05:11] RAOF, everyone goes around and adds support for their own set of patches [05:12] it sucks [05:12] but everyone's come to live with it [05:12] I'll just make the tarball 0.8.6.release.e+debian or something. [05:12] And hope they upload 0.8.6h at some point soon. [05:17] Oh blergh. [05:17] Ours has a +x264... at the moment, so it'll have to be +xdebian or so. [05:18] this is getting worse and worse [05:18] i am really starting to think epoch's sound more attractive [05:18] Upstream has 0.8.6h though, so this shouldn't be for long. [05:18] But the .release will be here for a while. [05:18] I am also getting a lintian error: file-in-etc-not-marked-as-conffile [05:18] An epoch is overkill if we just have to wait for a new minor upstream version... [05:19] the details of that error message don't tell you how to fix it [05:19] kostmo: You probably want to use CDBS' distutils support which makes debian/rules trivial. [05:20] I don't know much about CDBS. Thanks, I'll look into it. [05:20] wgrant, have you asked siretart when he is getting 0.8.6h in debian? [05:21] superm1: I hadn't. As it has had a number of NMUs lately, I don't think it likely it will be soon. [05:22] wgrant, okay well just make sure you document what to do in the cases of merges/updates until 0.8.6h then i suppose in a README.Ubuntu or something [05:22] I've got it in the changelog. [05:22] As it fits in two lines, and the changelog is fairly long otherwise. [05:23] k :) === Zic_ is now known as Zic [06:50] Hi Masters. I am currently building a package for the new Subversion 1.5 for Hardy. When I'm done is there a repo where someone would be interested in having this put, considering it's not going to be an official upgrade path? [06:51] you can use ppa [06:51] or try to upload it to intrepid [06:51] moosepants: Which version of subversion? [06:51] 1.5.0 [06:54] moosepants: Looks like there were still some issues with perl, Java, and ruby on Friday. I'd probably recommend a PPA for now. [06:54] moosepants: Debian has subversion 1.5.0 already. What dont you just sync it? [06:54] The official upgrade path is likely to be a merge with Debian 1.5.0dfsg1-1, and then a possible backport to Hardy. [06:54] persia: When is that likely to occur? [06:54] man-di: Are the issues that keep it in experimental resolved? I thought the candidate was a work in progress. [06:55] I dont know, I'm not involved in that. I just thought that its ridicolous to start another packaging of subversion [06:55] moosepants: I'm not sure of dates, but I'd suspect that the remaining issues with 1.5.0 will be resolved in the next few weeks. That will push past DIF, but it's a sufficiently high-profile pplication as to when it gets merged. [06:56] Err. It's a sufficiently high profile application it will likely be merged in a few weeks. [06:56] Were I you, I'd start playing with the Debian revision, and see how well it works for you, rather than duplicating the work. [06:57] man-di: That I'd agree with [06:57] persia: I hoped so. :-) [06:57] Hrm. Well, we need it nowish (I have been holding off some big merges awaiting merge-tracking), so I'll have a go with the Debian version, although I'm 95% done making my own package, provided it tests OK [06:58] moosepants: You might look at the changelog for 1.4.6dfsg1-2ubuntu1: it likely has fairly clear hints about what ubuntu modifications are useful. [06:59] The merge is likely to be fairly awkward; I looked at merging a not-1.5 version to fix the libsvn-perl-rebuild-against-5.10 problem, and there was all sorts of fun awaiting. [07:00] But if you're just interested in a working svn 1.5, simply building the debian package against hardy should be reasonable. [07:01] RAOF: Cool, thats what I'm in the middle of now. [07:05] good morning [07:09] persia: Where did you look to see that there were issues on Friday? [07:10] dholbach: good $TIME_IN_YOUR_TZ [07:11] nxvl: and the same to you :) [07:12] moosepants: I was reading the changelog on the version uploaded to Debian experimental on Friday: indicated some issue with Java, and a couple extra patches for perl and ruby. There is often benefit to looking at the code referenced by the changelog entry if one plans to extend it. [07:13] <\sh> moins [07:14] persia: Cheers, I will have a look myself. I am pretty new to the debian/ubuntu packaging world, so have little idea. Thanks anyway [07:51] wgrant: superm1? [07:51] morning folks! [07:51] helloooooooooo [07:53] wgrant: if you want to work on vlc, I very much welcome you to prepare the latest upstream release as maintainer upload to debian, which I'll happily sponsor for you. xtophe, the vlc guy caring for the debian package seems to be pretty MIA and we badly need a fixed vlc in debian rather soon [07:53] siretart: Evening. [07:53] siretart: Sure, I'll see what I can do about preparing 0.8.6h tonight. [07:53] It has had 3 NMUs since the last MU :( [07:55] wgrant: yeah, that's really unfortunate [07:57] Oh dear. It has a few bugs open. [07:58] but it seems xtophe touched the team's svn last week [07:59] hmmm [07:59] vlc (0.8.6.f-1) UNRELEASED; urgency=medium [08:01] That's still rather prehistoric. [08:02] hm. I see [08:03] Will update manager install a (new) recommends to a package? [08:04] YokoZar: Yes, unless the user has configured it otherwise. === polo is now known as Polo [08:05] persia: umm, how does one configure update-manager? [08:06] siretart: Well, it looks like he's onto it, so I won't interfere. [08:07] he's onto it since quite some time. feel free to poke him as well ;) [08:08] YokoZar: Either fiddle with apt.conf, or use arguments to apt-get to set policy. [08:08] update-manager uses either python-apt or synaptic internally, depending on the type of upgrade. In either case, it accepts base apt configurations, and in the synaptic case, it also follows synaptic configuration. === Polo is now known as poloo === poloo is now known as polooo === polooo is now known as poloooo === poloooo is now known as Polo === Polo is now known as PoloO === PoloO is now known as PoloOo === stdin_ is now known as stdin === asac_ is now known as asac [09:59] let's do some sponsoring - who's in for it? :) [09:59] * dholbach looks at wmifs [09:59] I did some earlier, about ten bugs [10:00] * dholbach high-fives DktrKranz :) [10:00] * DktrKranz hugs dholbach [10:00] * wgrant is a bit busy trying not to strangle vlc developers. [10:01] wgrant: sponsoring will make you think of something else - voilà! :) [10:01] Heh. [10:01] They don't bother to release security patches, and they've recently moved to git, so the SVN revision references in the tickets on their bugtracker aren't useful to find patches :( [10:01] elegant way to say: "stop what you're doing and go processing u-u-s queue" :) [10:02] * dholbach looks at windowlab [10:02] I was going to do some yesterday, but then realised I was no longer in u-u-s, so couldn't unsubscribe them. [10:02] wgrant: adding you [10:03] dholbach: Thanks. [10:03] * dholbach hugs wgrant [10:03] done [10:03] i wonder if i have anything awaiting sponsorship in universe [10:03] just main, i think [10:04] at least the sync requests should be easy to ACK [10:05] i'm awaiting a couple of packages to go into debian before sync requesting, too [10:05] Why are sync requests easier to ack than other diffs? Oughtn't one be reviewing past Ubuntu variation? [10:05] * persia encourages sponsoring, just doesn't understand that point. [10:06] right, syncs merges and standard debdiffs need the same attention. I'm focusing on merges/syncs right now, just to be sure to get rid of them before DIF [10:07] persia: It's easier to trust Debian than a Contributor. It's pretty easy to check if the diff is incorporated in Debian, not so easy to check that a Contributor diff is correct. [10:07] persia: I wasn't trying to say that one thing deserves more attention than another. [10:07] wgrant: I guess. I'm more worried about useful Ubuntu variation going missing, but maybe my experience isn't typical. [10:07] also the description in sync requests is often more explicit [10:08] * dholbach looks at lasso [10:13] * dholbach looks at giftrans [10:24] * dholbach looks at memaker [10:26] hm, nope, i got nothin' in universe currently [10:26] or nothing waiting, anyway [10:28] xsp i want to see updated in debian first, but i could put out a 0ubuntu1 package if pushed [10:29] directhex: Better to wait for Debian to ensure the same orig.tar.gz, If you want to prep a debian update candidate, ask the maintainer if help would be welcome. [10:30] persia, done and done. he's just busy. [10:31] i'll take a peek at monodevelop, that would be useful [10:33] ehm, looks like it's unbuildable on intrepid right now [10:34] ~ [10:37] * dholbach looks at planner [10:37] hm, uninstallable, not unbuildable. automatic versioned dependencies are old. just needs a rebuild [10:44] bleh! someone already did it, as a 1ubuntu2 package. stupid merge-o-matic [10:44] that was a waste of time [11:10] wgrant: oh, I see you uploaded a new vlc 3 hours ago. I've refreshed the patches for version 0.8.6h in the debian svn [11:10] siretart: I did, so we can easily merge from Debian now. [11:11] wgrant: moreover, I think we agreed on dropping the x264 and faad copies so vlc can be promoted to universe again [11:12] siretart: x264 is in multiverse, and we now depend on it. [11:12] So unless we can promote it, vlc can't go back. [11:13] DktrKranz: ping [11:13] sebner: 150 euros... ehm... pong [11:13] DktrKranz: rofl [11:14] DktrKranz: my libnxml merge. What sense does it make to keep the versioning on cdbs? I introduced it to fix gutsy backport but how big is the change that this version gets backported intrepid->hardy->gutsy? [11:14] Hi [11:14] * sebner winks mok0 [11:14] Long time no see [11:15] mok0: you or me? ^^ [11:15] me [11:15] Long time no see me [11:15] sebner: bug number? [11:15] DktrKranz: bug #225626 [11:15] Launchpad bug 225626 in libnxml "Merge libnxml 0.18.2-3 from Debian(Unstable)" [Wishlist,In progress] https://launchpad.net/bugs/225626 [11:15] mok0: then welcome back ^^ [11:16] sebner: thx. Not quite back though [11:16] sebner: working on a manuscript [11:16] sebner: current cdbs version is higher than the one you mention, but if you try to backport it in the future, you'll get FTBFS [11:17] since we keep merging clean-la.mk [11:18] DktrKranz: for gutsy but not for hardy [11:19] what if someone wants it for dapper? [11:19] (or any supported series <= gutsy) [11:20] DktrKranz: then we reintroduce the fix. But the chance isn't that high since no one requested a backport of the hardy version to gutsy [11:21] I agree, usually backports requests are for current stable release [11:21] DktrKranz: so go and upload it and stop complaining :P [11:21] but I'm not a backporter, maybe you can ask them advices :) [11:21] bah [11:22] siretart: Is x264 in multiverse purely due to patent concerns? [11:23] * sebner --> lunch [11:23] * directhex patents frivolous software patents === Arby__ is now known as Arby [11:24] dholbach: re: giftrans. Does depending on a non-existant package as part of an alternative matter? [11:24] soren: network-manager-{vpnc,openvpn} are out-of-date looking at GNOME SVN, mind if I have a look at them? [11:27] Hmm, how do you configure terminator? [11:27] DktrKranz: Not at all. In fact, I'd be thrilled if you did. I been neglecting them big time. [11:28] soren: sure. I'll have a look (since I had some crashes with vpnc), not sure when, though. [11:28] hey guys [11:28] can someone tell me why [11:29] beacuse [11:29] gah.. [11:29] Definitely. [11:29] because, I mean. [11:29] ocsinventory-server appears on http://gb.archive.ubuntu.com/ubuntu/pool/universe/o/ocsinventory-server/ [11:29] and on pacakges.ubuntu.com [11:29] ahhhh [11:29] hmmm [11:29] no [11:29] No? [11:29] Aw... Too bad. :) [11:29] but apt-get can't find it [11:30] cbx33: Because you haven't got your sources.list setup properly, I would suggest. But that can't be right. [11:30] cbx33: How exactly can't apt-get find it? [11:32] There's an arch-indep binary published in both Hardy and Intrepid. All looks good to me [11:32] wgrant: it is an mpeg4 encoder, so yes [11:33] siretart: Lovely. [11:34] wgrant: I think it even was in debian at some point but got removed [11:35] nevermind [11:35] * cbx33 found the problm [11:35] this box is a gutsy box [11:36] cbx33: Heh, that would do it. [11:36] damn box [11:36] siretart: Yep. [11:36] How I love software patents. [11:36] I guess we'll have to carry that Debian diff forever. [11:52] wgrant: however we can and should work on minimizing it [11:52] (the diff) [11:53] siretart: It's pretty small now. [11:54] oh, cool [11:54] There's pulse, and x264. [11:54] And xulrunner 1.9. [11:54] wgrant: would you mind uploading backports of vlc to the motumedia ppa, at least for hardy? [11:54] And no iceape. [11:55] siretart: If you add me to motumedia, sure (I probably should join anyway). I left a while ago due to bugmail, but I can route that elsewhere now. [11:56] wgrant: done [11:56] siretart: Danke. [12:01] siretart: Apart from the pulseaudio plugin diff itself: [12:01] 9 files changed, 64 insertions(+), 9 deletions(-) === sebner_ is now known as sebner [12:01] So it's pretty small. [12:03] wgrant: oh, nice [12:03] is the pulseaudio plugin diff something that would be applicable to debian as well? [12:03] Possibly. [12:04] It's in the 0.9 branch upstream. [12:04] then please file a bug with the patch attached [12:04] Will do. [12:04] thanks [12:06] siretart: Ah, it's already there. Debian bug #471069. [12:06] Debian bug 471069 in vlc "[patch] pulseaudio support" [Wishlist,Open] http://bugs.debian.org/471069 [12:15] wgrant: excellent. thanks [12:15] now we "only" need some hands to actually integrate them in the debian branch [12:16] * siretart really should focus more on ffmpeg [12:16] siretart: The Debian vlc maintainer doesn't seem tooo inactive. [12:17] no he isn't. I see xtophe from time to time in #videolan === _stink__ is now known as _stink_ [12:18] hi sistpoty|work [12:18] hi siretart [12:18] siretart: I'm currently rolling an update to fix all vlc CVEs open in Hardy... [12:18] I think it builds now. [12:19] wgrant: cool. thanks [12:19] Indeed it does. [12:19] huhu sistpoty|work [12:19] hi sebner [12:19] woohoo, maybe we'll do a FAUmachine release soon, thanks to your ideas siretart :) [12:20] sistpoty|work: cool! :) [12:22] hey.. REVU complains about my tetzle-package, says that lintian thinks the Standards-Version is to high.. (3.8.0).. my local lintian on Hardy does not complain, should I still downgrade Standards-Version? [12:23] rawler: no [12:23] rawler: No. I'll throw a newer lintian on there some time tonight. [12:24] okies.. great.. :) [12:25] btw, how long is it usually before someone has time to review a submitted package? hours, days or weeks? [12:26] rawler: depending on how much you pay and how annoying you are [12:26] siretart: Any objections to me installing a backported 3.8.0-compatible lintian on spooky? [12:27] sebner: I don't pay, and I'm mildly annoying? :) [12:28] weeks then :P [12:28] It is recommended to ask in here no more than once a day. [12:28] Somebody will likely take notice of one of your requests. [12:30] heh.. allright.. I'm just asking since I'm in the process of moving my apartment, so got lots of other stuff to do as well, and wants to know roughly what to expect, for planning.. :) [12:31] I generally just put stuff in the queue and wait, normally takes a few days [12:36] Laney: great.. thanks.. :) [12:44] btw, how important is the manpage of a single-binary game? (a QT4-puzzle-game) [12:44] or rather, how important is the missing-manpage lintian complaint? [12:49] siretart: It looks like vlc 0.9.0 will be out in a month, so the Pulse addition in Debian may not be necessary. [12:49] rawler: I, personally, wouldn't sponsor a package at this stage without a manpage. They're easy enough to write. [13:10] morning [13:40] dholbach: Did you manage to fix that mouse problem you were having on Intrepid? [13:41] Laney: no - do you have it too? [13:41] dholbach: Yeah, I just booted it up and it's stuck to a tiny area on the top left [13:41] Laney: regarding the "| xf86-common" - having it shouldn't matter [13:41] Laney: did you find anything out about it already? any bug report or anything? [13:42] dholbach: No, doing a bit of poking now [13:42] and I'll get you a new debdiff in a sec [13:42] Laney: take your time - I have a bunch of other things to finish first - but I'll get to it [13:42] Laney: keep up the good work! :) [13:42] Thanks :D [13:54] for backport packages how is archive admins related to the process? [13:56] gnomefreak: they do the backporting with their sscripts [13:56] persia: \o/ for the uqm-content sync but what about the merge :P [13:56] jpds: so i would have one of them spin it and push? [13:57] sebner: As soon as I can figure out git packaging properly, Debian will have a new revision with those changes. [13:57] persia: ah true you told me. YEAH sync :D [14:00] ember: ah gratulation!!! [14:01] gnoeif you're in the ~ubuntu-backporters team, yes [14:02] gnomefreak: ^ [14:03] jpds: thanks [14:03] gnomefreak: otherwise, file a bug and wait for a backporters to approve it. [14:04] jpds: its been there for over a month and they were subscribed [14:04] noone touched it and i would really like to get my plate cleaned up a bit [14:04] gnomefreak: Filed against -backports? [14:04] wgrant: no i tried but it wouldnt allow me [14:05] i tried caps and no caps [14:05] gnomefreak: There is no restriction on filing bugs against projects... [14:06] wgrant: Launchpad doesn't know of any source package named 'hardy-backports' in Ubuntu. [14:06] persia: when is the new u-u-c emblem introduced? or isn't that possible since the election escalated ^^ [14:06] gnomefreak: launchpad.net/hardy-backports/+source/foo [14:06] gnomefreak: lp.net/hardy-backports [14:06] sebner: Err. Right. I'll go look at doing that now. [14:06] gnomefreak: Project, not sourcepackage. [14:07] Hi * [14:07] persia: *thanks*. wuhu. new icon for me \o/ xD [14:08] wgrant: thanks so i can mark gutsy and hardy as invalid once *-backports is set? [14:09] mok0: I'm looking at the wrench: it's 16x16, and I need 14x14. Shall I trim one pixel from each edge, or do you want to resize in a more complicated way? [14:10] persia: the other emblems I have looked at are also 16x16, but displayed as 14x14 in the html [14:10]