[00:04] jdong: in what way, less painful? [00:04] I suspect the base tarball isn't one any more [00:05] mok0: the base.tgz is much faster to build [00:05] mok0: I find myself doing pbuilder updates quite frequently so that's greatly appreciated [00:05] jdong: hmm, ok [00:05] and the base.tgz size increased abt from 88->110MB [00:05] jdong: I use cowbuilder, so no tarring or compression [00:05] which is noticeable.. .but not too bad [00:06] mok0: if I had LVM set up on this machine.... [00:06] * StevenK uses sbuild and LVM snapshots [00:06] * mok0 plans to set up sbuild & LVM snapshots at some point === neversfelde_ is now known as neversfelde [00:07] hi mok0 [00:07] LaserJock: Hi [00:08] I haven't quite been convinced yet that sbuild/LVM is much better than pbuilder [00:08] seems like you need an aweful lot of disk space for them [00:09] LaserJock: true, but my machine has so many gigabytes of diskspace I don't really need [00:10] so what do you gain though? [00:11] LaserJock: As I understand it, with sbuild you can create your own buildd system, that compiles several archs [00:11] and you can't do that with pbuilder? [00:11] just wondering [00:12] LaserJock: you can use deb-o-matic [00:13] deb-o-matic apparently work with pbuilder as well [00:13] LaserJock: It's a bit faster than pbuilder, and it's an environment closer to what the buildds use. [00:13] yes that's right [00:13] RAOF: right [00:14] but they seem fairly comparable [00:16] when I reinstalled my system I LVM'd it all so I could try it out, but I haven't had a chance to try yet [00:16] I don't have a lotta hard drive space so that was my biggest concern [00:16] You seemed more content to complain about 64 bit issues instead. [00:17] heh [00:17] I haven't reinstalled it though, I'm still sticking to 64 bit [00:18] I've been learning how to work around the issues [00:20] I need to figure out how to get a 64 bit skype 2 [00:20] that's my latest challenge [00:23] * RAOF laughs derisively. [00:26] Actually, that's unfair. Skype _would_ be easy for me to set up if ALSA wasn't broken. [00:28] * LaserJock cringes at reading people trying to deploy Hardy production school servers [00:29] LaserJock: http://www.skype.com/go/getskype-linux-beta-dynamic seems to work (modulo ALSA problems) for me. [00:29] I've deployed Hardy to a server. [00:29] Though it isn't doing much at the moment other than rebuilding universe. [00:29] As have I. But that's because I'm _insane_. [00:29] LaserJock: I've been shocked by how stable hardy has been throughout development... [00:29] jdong: Indeed. [00:29] well [00:29] the hiccups have only been minor so far [00:30] there's that pycentral day :) [00:30] Apart from composite on -intel, it hasn't broken. [00:30] And that, yeah. [00:30] and yeah, intel xv from day to day [00:30] I'm not afraid of the desktop stuff in general [00:30] And g-p-m a bit lately, but nothing important. [00:30] my biggest trouble area right now is the newest HAL [00:30] i.e proc->sys batteries [00:30] but deploying unfinished software to workaround Gutsy bugs seems doomed [00:30] Yes. [00:30] sysfs batteries do not update properly for me, so I've personally locked my own patched hal to my macbook right now [00:31] jdong: I have 59 hours until my battery is charged. [00:31] My battery is discharging on AC :) [00:32] eya people [00:32] 59 O_O [00:32] lol Fujitsu [00:33] I had 63 hours of runtime this morning, too. [00:33] my battery only updates when I /etc/init.d/hal restart [00:33] so I love how I have 98% battery for 4 hours [00:33] then my PMU puts the laptop to sleep. [00:33] Same. [00:33] jdong: Just tested lzop, it's about 2x faster than gzip [00:33] hence why I inverted the patch we chose to apply [00:34] I see the flashing red battery light, and note that I have 100% full... [00:34] mok0: it turns the process from CPU bound to IO bound. [00:34] But then the power history graph shows correct discharge... [00:34] jdong: ok [00:34] Fujitsu: and even worse, g-p-m and laptop mode both apply the wrong power saving settings [00:34] mok0: so the more underpowered your CPU is, the more you'll likely save [00:35] jdong: I have a q6600, not exactly underpowered :-) [00:37] mok0: oh PFFT [00:37] mok0: then you'd almost not benefit from the switch [00:37] jdong: 2x [00:37] mok0: you'd probably want to use p7zip's bzip2 backend [00:37] mok0: which can quad-thread bzip2 from stdin [00:37] that might end up faster on your muscle CPU [00:37] jdong: cool [00:37] lzop doesn't delete the original? [00:38] mok0: lzop is identical in behavior to gzip [00:38] jdong: no [00:39] jdong: not for me [00:39] jdong: it leaves the original as well as the compressed file [00:39] mok0: you're right [00:40] * mok0 tries p7zip [00:40] definitely slower [00:41] mok0: are you sure you're multithreading bzip2 [00:41] jdong: no :-) [00:41] lemme TRY to recall the cmdline [00:41] | 7z a -tbzip2 -mx=1 -mmt=on -si test.bz2 [00:42] that should be the "business end" of your pipe [00:42] it's definitely gonna be 3-4x faster than standard bzip2, and compress better than it. [00:42] jdong: I am testing on an .iso, it doesn't really compress well [00:42] the question is, is it gonna be faster than lzop..... [00:43] mok0: you should probably test on a gunzipped base.tgz [00:43] jdong: you mean gunzipped base.tgz? [00:44] what did I say? [00:44] jdong: kkk [00:46] 7z: 7.77 secs :-) [00:46] lzop: 2.26 sec [00:47] ok, that's what I expected [00:47] though of course the former would be a lot smaller if it were compressible [00:47] Both compress the image to 81M [00:48] bzip2: 19.9 sec [00:49] 81 Mb [00:49] How long does pbuilder usually take overall? sbuild+LVM gives me <25 second builds on lots of things. [00:50] Fujitsu: it take me 3.9 secs to decompress base.tgz [00:50] man, pbuilder used to take slightly over 1 min. on my older laptop [00:51] Not bad. [00:52] I use cowbuilder, which does no unpacking/packing [00:52] We seem to have a lot of failures in universe because of the dh_iconcache/dh_icons migration. [00:53] Fujitsu: what's the problem? [00:53] dh_iconcache doesn't exist any more, so the builds fail. [00:53] Fujitsu: unpacking the base.tgz usually takes me 3-4 secs, cleaning takes another 5 secs or so [00:53] Ah. [00:53] so I'd guess at top 15s overhead [00:53] Fujitsu: I thought it was transitioning [00:54] LaserJock: My build results say otherwise. [00:54] hmm :/ [00:56] Fujitsu: do you have any idea how many FTBFS we're looking at? [00:57] LaserJock: Total, or just from that? [00:57] just from that [00:58] Still grepping for that. [00:58] I guess total would be good to know as well ;-) [00:58] ~500 out of the ~8300 that I've built so far have failed. Some of those won't be legit failures (because I forgot to use P-a-s this time), but most will be. [00:59] hmm [00:59] that's fairly significant [00:59] Yes. [01:00] About 3000 builds still to go, which should take about 36 hours more. [01:00] I wonder if they're biased towards Ubuntu packages or if they're a general problem [01:01] Fujitsu: I'm guessing this is related to performing universe rebuilds? [01:01] TheMuso: Correct. [01:01] Lovely. [01:01] LaserJock: defining "Ubuntu packages" how? === jelmer_ is now known as jelmer [01:02] slangasek: Ubuntu versioned [01:02] dh_iconcache was never in Debian, so they'll all be Ubuntu-local bits [01:02] pkgname =~ ubuntu? [01:02] slangasek: I was speaking about all FTBFS for that part [01:02] ah, yes [01:02] is there any way of grabbing the changelog between two vers of packages from launchpad? [01:02] or is hitting up changelogs.ubuntu.com the only way? [01:02] in that case, I'm sure there are plenty of FTBFS that can be blamed on the Debian maintainers ;) [01:03] yeah [01:03] we often sync at precisely the wrong time ;-) [01:04] nah, there's no right time to sync that will avoid the fact that a significant number of packages in Debian unstable are poorly maintained [01:04] Hm, pycentral breakage in a build just a few minutes ago. [01:05] During bzr installation. Is that known? [01:05] what actually happened that initiated this pycentral breakage in so many things? [01:06] slangasek: I don't mean sync repo wide, just on a per-package basis [01:07] anyway, yeah [01:08] LaserJock: yes, and some packages sit FTBFS in unstable for longer than an Ubuntu release cycle :) [01:09] yeah [01:09] Is there some method other than grep-dctrl that I can use to resolve an arbitrary binary package name to its source package? [01:09] it's difficult sometimes because Debian seems to have quite variable levels of maintenance [01:19] Should a package remove obsolete config files when it gets upgraded? They seem to stay in /etc and get listed as "obsolete" in "dpkg -s". [01:20] Erasing modified configs is a Bad Idea. [01:20] Fujitsu: sure. But they should get removed when they are unmodified, shouldn't they? [01:22] jdong: rmadison? apt-cache madison? [01:22] crimsun_: really? *checks his sanity* [01:23] crimsun_: rmadison on a binary package name doesn't seem to tell me its source package? [01:23] or am I being retardd? [01:25] jdong: ah, it's not reliable, true [01:25] jdong: it only shows source if the binary pkg name is also the source pkg name [01:25] right [01:25] jdong: ("apt-cache madison" should suffice, though) [01:25] I guess I'll just grab the Source.bz2's [01:26] crimsun_: well that makes assumptions about what's in sources.list [01:26] true [01:26] if only launchpad were magical... [01:32] jdong: PTS has something of that sort [01:32] heya crimsun_ :) [01:32] hey emgent === greeneggsnospam is now known as jsgotangco [02:40] \sh_away: If it's bugfix only, no FFe is needed. Just file a bug to document what you are doing. === kitterma is now known as ScottK2 [03:43] hmm [03:44] * LaserJock wonders why git-core in fiesty-backports has a ~dapper1 version and is newer than in gutsy [03:53] hm? [03:53] heh [04:02] LaserJock: Because it was backported from Hardy to Dapper and then Hardy got a newer one that wouldn't backport cleanly past Gutsy so the Dapper one was forward ported to Edgy/Feisty. Gutsy backport from Hardy is pending. [04:02] Clear? [04:02] ScottK: kinda [04:03] It'll all work out right in the end. [04:03] jdong had it all figured out. [04:03] I figured [04:03] just made me smile as I was backporting [04:04] lol [04:04] yeah lamont uploaded to dapper initially, then I realized we needed to care for everyone else [04:04] I got a FTBFS of the latest hardy to gutsy which I am investigating [04:04] somehow the test for cvs fails in pbuiler [04:06] hmm, I'm currrently trying it [04:06] it takes an insane amount of time doing tests [04:06] LaserJock: one of the final test cases failed with can't cd into cwd, IIRC [04:07] hmmpf [04:07] jdong: Lucky you to have an interested core-dev that might upload a source backport for you. [04:07] ScottK2: yeah, just have to know what to upload ;-) === boomer` is now known as boomer [04:12] hrmf. Since when did pycentral start using /usr/share/pyshared? [04:12] * TheMuso had to find that one out by building a damn package by hand. [04:18] hello world [04:24] * jscinoz is away: I'm busy [04:25] jscinoz: Thank you for that useful titdit of information :P [04:25] * jscinoz is back (gone 00:00:52) [04:25] what happened [04:25] didnt know that would go out in every channel [04:25] >_< [04:27] jdong: well, git-core just finished building for me [04:27] LaserJock: no way [04:27] LaserJock: well why did it fail for me :( [04:27] oh well I'll assume it works [04:27] jdong: You don't have that special core-dev touch. [04:28] and get a backport going [04:28] heh [04:28] ScottK2: lol [06:09] hmm, so the icecast of the local police scanner proved useful tonight [06:10] "Powered by Ubuntu" ;-) [06:26] LaserJock: Could you elaborate, please? Sounds fascinating. :) [06:27] well, somebody in my LUG emailed to say they set up an icecast server on an Ubuntu box to stream from his police scanner [06:27] tonight "something" happened in our neighborhood [06:28] a helicopter kept circling around [06:28] so I thought I'd make use of the stream and see what was up [06:28] Oh alright. Nice. :) [06:28] I'm still a bit shaky on the details, but something definately when down a couple streets away [06:29] Right. [06:29] I thought it was an interesting use of Ubuntu :-) [06:33] Most definitely. :) [06:49] ugh this is maddening [06:49] package builds fine with dpkg-buildpackage, but if i debuild -S -sa then use pbuilder it fails [06:51] jscinoz: Missing build-deps? [06:52] none afaik [06:52] jscinoz: Also, logs make for more useful answers :) [06:52] sec il lpatebin [06:52] good evening slomo, you around? [06:53] superm1: yes [06:53] RAOF, http://pastebin.com/m28dfdc95 [06:54] as we had discussed the other day about that patch related to V4L/V4L2, I scrapped it and made one against gst-plugins-good0.10 that just changes the default [06:54] superm1: sounds better [06:54] I talked to an upstream dev about making the change show up upstream as well, and they're going to consider making it a change there too [06:54] Good morning [06:54] jscinoz: Your /tmp is out of space? [06:55] jscinoz: That's likely to be a fair sized package, yes? [06:55] superm1: sounds sane anyway... who did you talk to? :) [06:55] yes 750mb [06:55] RAOF, shouldnt be, i have 1.4gb free [06:55] slomo, er i'd have to look at my logs at my PC in the office. gentleman in #gstreamer [06:56] he said they'd decide later though, so just to document it on a bug for now [06:56] superm1: ok, so things are taken care of ;) feel free to patch the ubuntu package for now [06:56] slomo, well it's in main [06:56] so i'd need to get sponsorship on it [06:56] oh [06:56] give me a patch then ;) [06:57] the debdiff on the bug is against debian [06:57] bug 195914 [06:57] Launchpad bug 195914 in ekiga "Ekiga & gstreamer inputs default to outdated V4L, and require to be changed to V4L2" [Undecided,In progress] https://launchpad.net/bugs/195914 [06:57] superm1: thanks [06:57] RAOF, wait i guess you're right, it is running out of space >_< [06:57] superm1: will care for that later, don't worry :) [06:58] slomo, thanks [06:58] is it possible to tell pbuilder to use a different temp dir? i have plenty of room on my home partition [07:03] jscinoz: Change the APTCACHE and BUILDRESULT config option in your pbuilderrc, I would think. [07:04] thanks [07:04] jscinoz: Also BASETGZ and BUILDPLACE config options in the same file come to play. [07:10] If i get my package in to debian, will it likely be in ubuntu 8.10? [07:29] jscinoz: Most probably, yes, unless you manage to sneak it in within the next few days, and then file a FF exception bug, get it reviewed and accepted within the next two weeks or so. I'm not sure about the dates, but it's getting pretty late for 8.04 cycle anyway. [07:29] yeah, i was told it'd be better to go for debian unstable and it would get into intrepid anyway [07:30] Yeah, during the Intrepid cycle, it's only a matter of a simple sync request. [07:34] arent the debian folk rather tight-arsed about what gets included though? [07:35] jscinoz: Heheh. :) I guess one could find a more delicate description. :) To answer your question, I don't really know, I haven't tried to upload anything there, but I've been told they have a good tight QA process, which really is a good thing, mind you. :) [07:35] yeah [07:36] i have one small licensing issue with my package [07:36] a single file is under a non-free license [07:36] They're strict about licenses, yes. [07:36] the Quake 3 SDK EULA, which permits distribution. [07:36] >_< [07:37] at the moment i have it display the license preinst, then upon acceptance i have it download this one file which is only 1.2mb [07:37] Hmm... I have no experience when it comes to such issues. [07:37] Right, well unless the upstream agrees to change the policy and license, I'm afraid that's the only approach possible. [07:40] well i'll submit it to mentors and see what feedback i get. [07:40] although i'd imagine every quake3 based game has this same issues, and they're still in the repos [07:41] this data package takes so darn long to build >_< [07:47] finally built now to upload the 800mb package >_< [07:57] Ouch. :) [08:00] 108kbyte upload speed >_< [08:00] dput cant do a diff upload can it? [08:00] because i have a feeling the first one is gonna be rejectect and i get to uploda the whole thing again >_< === \sh_away is now known as \sh [08:08] superm1: uploaded [08:08] superm1: will take the patch to debian too and upload after the previous version went to testing [08:13] Hi everyone. Is updating a package to a new upstream version a feature freeze exception? and if so how can new upstream versions be included into hardy at all? Or do they only go into intrepid and have to be backported? [08:14] HighNo: yes. if it fixes bugs, doesn't include new api/abi changes, then filing a feature freeze exception should be easy [08:15] if it is major changes, then it may be a bit more difficult for it to get included [08:17] ok, it would be a major update... [08:19] morning dholbach [08:19] good morning [08:19] hey nixternal [08:25] <\sh> moins [08:25] morning [08:25] <\sh> who can I bug about UbuntuWeeklyNews? [08:25] <\sh> Message from Zend: http://andigutmans.blogspot.com/2008/02/zend-framework-to-be-part-of-ubuntu.html [08:26] \sh: just edit the wiki page :) [08:28] <\sh> dholbach: this one? https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Ideas <--- looks a bit outdated ;) [08:28] nixternal: so what about if I want to integrate the new version with hardy and most likely without a ffe? [08:28] <\sh> oh no...there is something else [08:28] The next Ubuntu Weekly Newsletter, Issue #80 is due to be released on March 1st 2008. [08:29] https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue80 [08:29] \sh: ^ [08:29] <\sh> dholbach: yeah found it :) [09:20] anybody - what is the exact process of releasing a new version of a package already included in hardy - if that new version only has functionality, not bugfixes? Am I getting this right - it is typically not wanted unless using the backport project? [09:24] HighNo, Are you looking to get the new version into Hardy or into an already released version of Ubuntu? [09:29] cody-somerville: Hardy at this time - though the new version will be released next week [09:29] HighNo, The feature freeze has already passed for Hardy. If you want to upload a new version to Hardy, you'll need to file for an exception. [09:30] HighNo, See https://wiki.ubuntu.com/FreezeExceptionProcess [09:31] HighNo, What package are you thinking of? [09:32] neat. someone finally wrote some colorblind simulations for colorfilter [09:35] cody-somerville: blueproximity [09:37] HighNo, interesting package. [09:38] HighNo, What is the upstream URL? [09:39] cody-somerville: I am the upstream author and doing some major feature enhancements these days. The version that made it into hardy is very stable and works great but has limited functionality. I was mainly asking to know what to do after I completed those changes and did the testing. If there are ways to get the package with the new funcionality in hardy. (which also implies feisty and gutsy as backporting takes place) [09:39] cody-somerville: http://blueproximity.sf.net [09:39] HighNo, Is there a risk of regression? How big is the update? [09:40] anyone: It is ok for MOTUs to accept a package with very low build deps (like debhelper 5). It would make backporting of my package very easy (that is no change at all) [09:41] cody-somerville: could you explain regression? [09:42] HighNo, Is there a big risk that the package will stop working where it would work before? ie. The risk of regression would be greater if the amount of changes you've made since the last upload is larger than what some might consider "minor"/. [09:43] HighNo, Once you've made the next release, you can make yourself (or ask someone else) to file a Ubuntu Freeze Exception to see if you can get approval to upload your new version. As I already pointed out, the procedure is detailed at https://wiki.ubuntu.com/FreezeExceptionProcess [09:44] cody-somerville: ahh, ok, no danger of regression then [09:45] HighNo, Okay. Well, once you've made the release, feel free to e-mail me if you need help filing for a freeze exception. [09:47] cody-somerville: that sounds great [09:47] HighNo, Do you need my e-mail address or will you be able to find it? [09:47] cody-somerville: until when can new versions be introduced? [09:48] HighNo, Technically, new versions may not be introduced with an exception approved by the motu release team. The closer we get to the release date, the harder it will be to get approval. [09:48] HighNo, If with the exception request, you could prove that you've tested it for regressions, I'm sure you'll have an easier time getting approval. [09:50] HighNo, OooOoo... I'm just looking at the release schedule now. I dunno how easy it will be able for you to get an exception. The UserIterface freeze passed on the 28th. [09:51] HighNo, If we can't get your new version into the official hardy repository, we can always put it in a PPA :) [09:51] HighNo, And that'll mean it'll be all ready for a quick upload once the repository for the next version (intrepid) opens in a few months. [09:53] HighNo, Do you know what a PPA is? [09:56] cody-somerville: sorry, have been afk [09:57] cody-somerville: I've hear of PPA but have not used it until now [09:58] HighNo, It is a personal package archive. It allows you to host debian packages on launchpad easily :) [09:59] cody-somerville: I'd like to involve launchpad a bit more into development but don't know how. Are You used to that? [09:59] I am. [09:59] whoohoo [09:59] I'll continue this conversation with you in a private query. [10:00] ok === geser_ is now known as geser === dholbach_ is now known as dholbach [11:11] oy === thekorn_ is now known as thekorn [11:43] soren, geser, nixternal, persia: I won't be able to make it to the MOTU Meeting today (just as a heads-up) - need to prepare some stuff for next week :/ === cprov-out is now known as cprov [11:45] oh, there's a meeting? [11:45] goody [11:57] Hi [12:09] motu meeting in #ubuntu-meeting now [12:44] Heya [13:15] moo === allee_ is now known as allee === Pricey is now known as PriceChild [13:28] persia, about the logo, you can see it in https://help.ubuntu.com/community/UbuntuScience [13:28] mok0: Ah. I'm in agreement with you then :) [13:28] I've created a bug, assigned a debdiff for a package thats been included in hardy, and assigned USU to it. What else do I need to do to get it built and released? [13:30] DaveMorris: you've created a bug? ;-) [13:30] technically I did, I left off some dependencies in the package I created :) [13:31] DaveMorris: The procedure seems correct [13:31] so just a matter of time till it's build, or do I need to change teh status as well? [13:31] DaveMorris: Status = confirmed [13:31] * RainCT supposes that DaveMorris means u-u-s and not u-s-u [13:32] Ubuntu sponsors for universe is who I subscribed [13:32] ok then :) [13:32] * mok0 's head just exploded [13:32] rofl [13:33] * RainCT puts mok0 head back together with some glue ;) [13:33] * mok0 hugs RainCT [13:34] * RainCT hugs mok0 back :) [13:34] DaveMorris: If you click on the Ubuntu Sponsors for Universe string in LP, you can see that your package now appears on their list [13:35] heya [13:35] yeah, I noticed I had only subscribed them, not assigned it to them [13:35] Hi emgent [13:35] DaveMorris: I don't think you should assign it to them, [13:35] but to yourself, showing that you take responsibility for it [13:36] * DaveMorris needs to sort out some backports of the package yet [13:36] actually, I think it shouldn't be assigned to anybody (so that the reviewer can assing it to himself) :P [13:36] which bug is it, btw? [13:36] #195433 [13:36] RainCT: Ah, is that how it works? [13:37] bug 195433 [13:37] Launchpad bug 195433 in opensg "libopensg-core-dev is missing dependices which are called on in the pkg-config file" [Undecided,Confirmed] https://launchpad.net/bugs/195433 [13:37] hi [13:37] can someone help me? [13:37] i worked on bug https://bugs.launchpad.net/ubuntu/+source/blogtk/+bug/196813 [13:37] Launchpad bug 196813 in blogtk "BloGTK doesn't work with Python 2.5 (IOError: unsupported XML-RPC protocol)" [Undecided,New] [13:37] and found the fix [13:38] i contacted the upstream developer and asked him to include it in a new upstream version [13:38] hope that was right? [13:38] RainCT: I am constantly confused by what you are supposed to and not supposed to in LP. [13:38] when a new version gets released how can i sync it in ubuntu? [13:38] RainCT: ... and the rules tend to change ever so often [13:39] soc: yes, contacting upstream is always right :) [13:40] soc: now what would be good to do (unless the next upstream version is a bugfix only release) is to include the fix in the version that is currently in Ubuntu [13:40] (s/Ubuntu/Hardy) [13:40] mok0: heh [13:40] RainCT: how can i do that? [13:41] mok0: I also find them somewhat confusing :). [13:41] imo the fix would be very useful because it fixes a) a crasher b) makes BloGTK run with Python 2.5, so the dependency on Python 2.4 can be dropped ... [13:42] soc: do you have the hardy source repository enabled? [13:42] yes [13:43] mok0: and the answer to your question is yes (well, at least there are some sponsors doing so) [13:43] i downloaded the orig.tar.gz and the diff.gz now [13:43] mok0: it's allways good to subscribe yourself when reviewing something so that other sponsors don't duplicate the work [13:43] in my opinion in the diff all the lines with "-#!/usr/bin/env python [13:43] +#!/usr/bin/env python2.4" [13:43] have to be changed back ... [13:44] soc: okay. you'll need also the .dsc, and then run: dpkg-source -x *.dsc to get an uncompressed directory [13:44] but just deleting deleting is not the right to do i gess :-) [13:44] ok [13:44] RainCT: Ok, I understand === Ubulette_ is now known as Ubulette [13:45] RainCT: But subscribing is different than "assigned to" [13:45] What should be the version number for a fakesync? [13:45] ok, did it ... [13:46] mok0: Yes. Subscriber's get bug mail (and in the case of u-u-s, the bug is listed in their "bugs the group is subscribed to" list..) [13:46] do i have to manually change #!/usr/bin/env python2.4 to #!/usr/bin/env python or is there a way to revert that change? [13:46] mok0: the Assigner field is to say who is working on the bug, and usualy a field with someone assigned shouldn't be touched (unless he is asking for information on his last message or something, then you should answer if you can :)) [13:47] soc: let me have a look at the source.. :) [13:47] * jdong half-loses temper at bug reporters [13:48] soc: I believe that there should be #!/usr/bin/python and no env anymore [13:48] ok [13:48] "Why don't you just upload the package without the launcher and break all the launcher icons? I need this bugfix on hardy NOW" [13:48] *grumble* [13:48] haha [13:48]