[00:20] another quick question - i'm using debhelper for packaging, and it's not quite calculating all the dependencies i'm expecting [00:21] in particular, i have liblame-dev as a build-depends, but it's not adding liblame or lame as a runtime dependency (which i think it does need) - is this a common gotcha? [00:21] obviously I can add it manually... [00:22] the_belgain: you don't have to. The -dev package will pull in the other ones [00:23] it does for most of the -dev libraries, but not for lame it seems [00:24] the_belgain: you probably want to look at the build log and at the ldd output of your program first, to confirm whether liblame is being pulled into the build the way you're expecting [00:24] Why do you need lame? [00:25] the program i'm packaging (fuppes) is upnp media server / renderer which does transcoding - it uses lame to transcode audio to mp3 [00:26] the_belgain: so it needs to check for lame during the build, I guess. [00:26] the_belgain: you have to specify lame in build-depends, then [00:26] mok0: he already said that he did [00:27] i've specified liblame-dev in the build depends, yes [00:28] but if configure (?) checks for the lame binary, then you need to put it in build-depends, and with a Recommends: in the binary package [00:28] is the problem that the packages are called "liblame-dev" and "liblame0", which is confusing debhelper? [00:29] the_belgain: there are two overall explanations for not getting the dependency on liblame that you expect: 1) the library isn't being linked in during your program build the way you expect, 2) liblame0 doesn't have a proper shlibs file and therefore the dependency isn't being autocalculated even though the library is used [00:29] liblame0 contains the shared libraries, if your binary is linked to that, dh_shlibs should find it [00:29] I've just verified that liblame0 does have a proper shlibs file, which leaves the other case to examine [00:30] ok, i'll check the compile output to see if it looks like it's being pulled in correctly. thanks [00:30] pbuilder builds take forever to run... :( [00:31] the_belgain: use cowbuilder [01:19] evening === pmf__ is now known as ember === cprov is now known as cprov-ZzZ [01:39] Heya gang [01:41] Heya bddebian [01:42] Heya ScottK === bigon is now known as bigon` [02:03] Got a question about my lintian results... How do I resolve the following: [02:04] gpg: Can't check signature: public key not found [02:04] That's not a lintian result [02:04] Don't worry about it. [02:04] ok, cool [02:05] is that due to pbuilder, that my public key isn't found?\ [02:05] hi wolfger [02:05] Fujitsu: ping [02:05] Hi Hobbsee [02:05] wolfger: my c-n-f bug really isn't on crack. you just didn't read it. [02:06] Hobbsee: right... I didn't read closely enough the first time to recognize the package assigned was c-n-f. [02:07] then when I looked c-n-f up, it said it was for bash, so I assumed it did not apply to zsh. Incorrectly assumed, as it turns out ;-) [02:07] live and learn [02:07] wolfger: readme says it does zsh too. [02:10] sʞɔoɹ nʇunqn nice === ember_ is now known as ember [02:31] ??? [02:31] * wolfger wonders how the heck leonel did that [02:32] <_MMA_> http://www.revfad.com/flip.html [02:33] I feel like I am missing something when it comes to building a package. I now have a .dsc that passes linitian with no errors, and I'm done with the guide.... how does this become a .deb? [02:34] pbuild it? :) [02:37] bddebian: as opposed to the "sudo pbuilder build ../*.dsc" I already ran? [02:38] Ah, that should have produced a .deb [02:38] DId you look in your results dir? [02:39] Or did it possibly fail to build? [02:39] maybe I'm just too tired to be doing this right now... It built okay (finally), but I am at a loss for where the "results dir" would be. [02:40] hm [02:40] dpkg-deb: building package `memaker' in `../memaker_0.1-r134-1_i386.deb' [02:40] wolfger: wherever you set it in your pbuilderrc [02:40] usually /var/cache/pbuilder/result/ [02:40] ah [02:40] Thanks, Hobbsee [02:45] * wolfger is getting nervous.... this is taking far too long to install [02:46] oh, never mind. It's done. Been done for who knows how long... :-P [02:46] siiiigh. [02:47] vmware won't do any sound at all [02:47] and there's nothing holding /dev/dsp [02:48] * bluefoxicy can rmmod the module but can't insmod it, hrm [02:49] er. Can't write to the device with it insmoded... [02:53] wolfger: http://www.en.fliptext.net/ [03:09] Hobbsee: Pong. [03:12] <_MMA_> Im trying to find the bug about GDM not using the background color set in gdmsetup. Any help? [03:15] <_MMA_> Got it. [03:23] Where can I find a plaintext version of CC-BY 2.5? [03:25] Hi all... is there a well-formatted feed (RSS?) of package updates which I can use to feed my "validate updates before they break production" RHN clone? [03:27] I'd prefer to parse a machine-friendly format like RSS, than to combine ``apt-get upgrade'' with a screenscrape of Launchpad. [04:09] if a bug is duplicated it's needed to be marked as invalid, didn't it? [04:11] If it's duplicated, mark it as a duplicate? [04:51] Fujitsu: nvm, i found out. === tritium_ is now known as tritium [06:52] hmm, can you tell an app to use a different path for a lib at runtime? [06:53] I've got devel libraries installed to /usr/local/ and normal apps are picking them up ... and crashing [07:10] good morning [07:11] hello dholbach [07:11] hey gpocentek [07:11] * dholbach hugs gpocentek [07:13] * gpocentek hugs dholbach back [07:15] LaserJock: Won't LD_LIBRARY_PATH work? [07:15] LaserJock: If not, maybe LD_PREPLOAD, but I've never used that. [07:16] LD_PRELOAD, of course. [07:25] hmm [07:26] i'm working on packages for the semifree game UrbanTerror, the game engine is GPL (with some components under other free licenses) and the data files are all free to distribute except for one file which is under the Quake3 SDK license. if i say excluded this file from the source package and had the binary package download it (its only 1.3mb) in the preinst, would this be acceptable? === asac_ is now known as asac [07:30] morning [07:36] * minghua likes persia's proposal of allowing (Debian's) Original-Maintainer and Uploads to do uploads for main packages. [07:41] anyone would like give any suggestion about Bug #181029 [07:41] Launchpad bug 181029 in scim-bridge "[FTBFS] scim-bridge (0.4.14-1) fails to build in hardy" [Medium,Confirmed] https://launchpad.net/bugs/181029 [07:42] minghua: I dont follow Ubuntu lists, can you give me a link to persia's proposal? [07:43] freeflying: I agree with minghua, removing it is the best way around the error. Or are you looking for something more? [07:47] man-di: Sure, https://lists.ubuntu.com/archives/ubuntu-devel/2007-December/024886.html [07:47] slangasek: actually, I don't want to maintain two version in Debian and Ubuntu :P [07:47] man-di: To be precise, it's (MOTU) and (Debian's maintainer and uploaders). [07:47] minghua: thanks [07:48] freeflying: so, why could you not simply remove the .pot file in an upload to Debian, and allow this to propagate to Ubuntu? [07:48] freeflying: if the .pot file is empty it doesn't benefit the Debian package either, so removing it at build time also won't hurt Debian [07:50] slangasek: I think missing POT file will cause FTBFS on Ubuntu buildd as well, though I'm not sure. [08:11] Hallo, my name is Herbert Straub and I ask about the re-sync of the REVU uploaders keyring. I followed the instructions MOTU/Packages/REVU. My launchpad account is herbert. [08:26] hstraub: I'll resync it. [08:31] Hi all, is there any way to identify java related packages in universe/multiverse that need fixing (apart from FTBFS)? [08:32] slytherin: What do you mean by 'fixing'? [08:33] Fujitsu: any sort of problems, bugs, watch files, unmet deps. I am looking for an easy way to locate java apps/libs with problems. Because I can only help in that area [08:34] slytherin: you should talk to doko (once he's back from Holidays again) and man-di - looks like a Java team is coming up :) [08:35] It'd be nice to have something like packages.qa.d.o at some point, collating all of the QA information per-package. [08:36] dholbach: as of now I have helped fix few FTBFS. But now I am looking for something different. I will still try to fix FTBFS though. [08:37] my next target is lucene2 [08:38] slytherin: when you want to fix something in java packages please send the report to Debian BTS, I will look into it, do an upload and then you can sync [08:38] man-di: ok [08:43] hstraub: It's done. [08:44] man-di: On 'batik' front, I think it should now compile with GCJ except JPEG and TIFF codecs part. But I think latest version has an additional dependency. Should I file a bug for this in debian? [08:45] morning everyone [08:46] oops, bug is there already [08:46] slytherin: problem is that we have software in the archive that depends on batik providing TIFF codec, and it does only when its compiled with SUN JDK [08:46] icedtea will probably work too, but I dont checked that yet [08:47] man-di: icedtea won't make a difference from gcj. It doesn't have those sun specific classes. [08:48] so no option to moving to another JVM for building for now [08:48] man-di: which software are you referring by the way which depend on codecs? I will take a look if they work with latest version [08:48] btw: batik is currently actively worked on it debian [08:48] slytherin: I think it was fop [08:49] problem was that GCJ built batik fine, but fop dont build with the new batik anymore [08:50] hmm. I hope batik developers move away from sun specific apis soon [08:50] slytherin: I think there is no other API providing that specific feature [08:50] * Fujitsu thinks there is - in languages other than Java. [08:51] Silly Java. [08:51] * man-di slaps Fujitsu [08:51] * Fujitsu preempted that. [08:52] ...we could integrate JRuby or Jython and use Ruby or Python to implement it... [08:52] there was also some PHP interpreter written in Java... [08:53] I wonder why Apache Commons' developer have not developed an alternative yet [08:53] That sounds worse than normal PHP, and that's pretty bad. [08:53] No buffer overruns, I guess. [08:53] Fujitsu, thank you... [08:54] slytherin: they dont saw the need, tiff is not so widely used. You need a critical mass of users who need a feature... [08:55] hmm [08:55] Fujitsu: its for cases when you want to run everything in a Java Application Server [08:55] that has its benefits, but also its troubles === DarkMageZ_ is now known as DarkMageZ [09:09] slangasek: its not a dfsg issue, so i don't think it is a best way to remove it directly from upstream tarball [09:17] talking about java ... what's news about openjdk ? [09:17] s/what's/what are the/g [09:18] rzr: news as in? icedtea is in Ubuntu. Hopefully it will make into Debian soon. [09:19] great [09:19] so tuxguitar will quit contrib to main [09:20] rzr: depends on it's dependencies. openjdk/icedtea can not fully replace Sun's JDK as of yet [09:21] that's what i am reading at http://icedtea.classpath.org/wiki/FrequentlyAskedQuestions#Functionality_and_Testing [09:21] no sound yet .. [09:24] rzr: we (Debian) are a bit reluctant to move pcakges from contrib to main just because of icedtea, it should better work with another free runtime too. [09:25] rzr: after all icedtea is i386, amd64 and powerpc only [09:25] * pochu waves [09:25] and powerpc is limited [09:25] I plan to make a nativebuild (in debian) of tuxguitar in next upstream release [09:26] rzr: for what? What do you gain by this? [09:27] good morning [09:28] then it will not requiere sun jvm [09:28] and can be in main [09:29] rzr: I really doubt that [09:29] rzr: that will only work when it works with GCJ as byteocode too [09:29] * minghua can't believe someone is proposing Ubuntu to adopt Gobolinux's filesystem layout because it "sounds like fun"... [09:30] man-di: The problem with lucene2 in Ubuntu is some unit tests for contrib libraries are failing, not the core. Can we bypass this failure? Or how about unit testing only core. [09:30] minghua: That's what people do... [09:30] minghua: ubuntuforums? [09:30] man-di: It will , if we wrap the sound layer to alsa [09:31] Fujitsu: No, some list, should be -devel-discuss. [09:32] Oh gawd, they've migrated to there now!? [09:32] * Fujitsu screams. [09:32] I thought we kept that kind of person in the forums. [09:33] Heh. [09:33] * Fujitsu is behind on -devel-discuss by several hundred messages, fortunately. [09:34] rzr: ah, you meant providind an additional JNI library to access also, I thought you meant compiling tha jars to native code with gcj [09:34] Fujitsu: Me too. I just browse my inbox through the web interface now and then before I download them via POP3, and such messages always intrigues me. [09:34] minghua: we do both [09:35] * minghua has been more and more happy about the -devel and -devel-discuss split. [09:35] Ah, so there is some sanity to it. [09:35] /Variable/tmp [09:36] DarkSun88: congrats! :) [09:37] DarkSun88: congratulations! :) [09:38] man-di: Can you please reply to my question. It is about lucene2. May be you missed it. [09:39] man-di: I think rzr meant to speak to you a few lines above. [09:40] slytherin: good question [09:40] minghua: I guessed that [09:41] slytherin: so it does FTBFS on Ubuntu? [09:41] man-di: Yes. [09:41] slytherin: do you have a link to a log? [09:42] man-di: just a minute [09:42] man-di: minghua is right [09:42] :) [09:42] man-di: Some problem with my network. Can you please check this page - http://qa.ubuntuwire.com/ftbfs/ [09:43] the host seems down [09:44] man-di: I will be back after a coffee break. We will discuss after that. [09:45] I need to do some customer work here too... === Amaranth_ is now known as Amaranth [10:00] man-di: http://launchpadlibrarian.net/11125011/buildlog_ubuntu-hardy-i386.lucene2_2.2.0-2_FAILEDTOBUILD.txt.gz [10:02] geser: thx [10:03] slytherin: I cant test currently if that fails in Debian too [10:03] slytherin: if not I would be for an ubuntu-only patch [10:03] slytherin: if yes we should patch debian and sync [10:19] man-di: I am ok with this approach. [10:23] slytherin: can you work on this? I'm currently on limited time [10:23] I'd like to request a REVU review for my package speed-game please: http://revu.tauware.de/details.py?package=speed-game [10:24] man-di: I don't have access to any Debian machine. And I am doing all this in my free time in office. No net connection at home presently. :-( [10:24] man-di: I can try setting up debian pbuolder chroot. But it will take time [10:27] are you all already running hardy on your machines? [10:27] slytherin: hmm, can test on Debian but not yet, tonite I can [10:27] man-di: No problem. I will wait. [10:28] amarillion: why are you asking that? :-) [10:28] I'm on gutsy, I have to keep remembering to adjust the target distribution to hardy before uploading my package [10:29] Which is a pain [10:29] also, I'd like to redirect some friends to my ppa to test some of the packages I'm working on [10:29] but they are running gutsy of course [10:30] so I'm feeling rather schizophrenic about gutsy/hardy [10:31] amarillion: You can use dch command to add an entry to changelog and use -r option to set release. You can set an alias as follows 'alias dch="dch -i -r hardy"' [10:31] ah that will help, thanks [10:32] so which release are you running then? Is hardy too unstable for day to day use? [10:34] ........ [10:34] * Fujitsu looks at KmosReport. [10:34] Why is #164166 marked as a positive? [10:35] amarillion: I am not using it on my office machine. But using it at home. [10:35] I wonder why people are making such a hard time to Kmos regarding cyphesis-cpp [10:36] I guess for everyone else it would be synced already [10:38] dholbach: Can you please clarify why you thought that was a positive? [10:38] * pochu enjoys his first requestsync bug :) [10:42] Fujitsu: ok... just read up on the irclogs [10:42] It could have probably been explained better on KmosReport, sorry. === cprov-ZzZ is now known as cprov === \sh_away is now known as \sh [11:11] dholbach: Speaking of KmosReport, I don't see any solution proposal in bug 181029. [11:11] Launchpad bug 181029 in scim-bridge "[FTBFS] scim-bridge (0.4.14-1) fails to build in hardy" [Medium,Confirmed] https://launchpad.net/bugs/181029 [11:12] <\sh> moins [11:13] hello [11:13] hello \sh. [11:14] * minghua grumbles at his new keyboard that has \ key in a different place. [11:14] minghua: the bug report is about a FTBFS - Marco says "It needs a cleanup of empty files in po/ directory." [11:15] minghua: if you want to re-word "solution proposal" to something else indicating that he analyzed the problem, that's fine with me [11:15] dholbach: But how? And I remember that a missing POT file will cause a similar FTBFS. [11:17] minghua: really? most apps ship without .pot files and build OK - we explicitly have to run cd po; intltool-update -p for some to get the .pot file for rosetta [11:20] * dholbach -> break [11:20] Okay, something is seriously wrong with pidgin here... [11:21] dholbach: I may well be wrong. I just remember seeing some building problem with missiong POT file before, around the dapper days. [11:21] minghua: yes I've seen that too... [11:22] dholbach: I'll change it to "correct analysis" on the wiki, regardless. I believe that's okay for you? [11:22] mok0: Pidgin crashing, or build problem with missing POT file? :-P [11:22] minghua: pidgin randomly crashing [11:24] minghua: On amd64/gutsy [11:25] mok0: I encountered that from about october 15th to around november 15th. Might be worth looking at the changelogs. [11:25] persia: you mean the problem was solved in a newer version? [11:26] * minghua cancels apport crash report sending, seeing there is no usable backtrace. [11:26] mok0: hardy i386 here. [11:27] mok0: pidgin was remarkably unstable for a while, especially when interacting with IRC. It seems to have settled now, but my system typically has the unstable and broken bit inverted, so it's not always a good indicator of real issues or real solutions. [11:27] minghua: what pidgin version? [11:28] mok0: 1:2.2.2-1ubuntu1 [11:28] persia: the problem we saw was in jabber [11:28] minghua: same version here [11:28] mok0: See. That's why I only report bugs when I can reproduce them in sterile environments :) [11:29] persia: good point :-) [11:29] mok0: Huh? But changelog says that's a hardy version. [11:29] Anyway, pidgin has been stable for the past few weeks until tonight's upgrade. [11:29] minghua: Ah, sorry, 1:2.2.1 here [11:29] So I doubt it's pidgin's fault. [11:31] (pidgin was not in tonight's upgrade) [11:31] minghua: could be coincedental === bigon` is now known as bigon [11:42] \o/ My first upload :-) [11:44] Hurrah! [11:45] <\sh> pochu: congrats :) [11:45] <\sh> btw...pidgin and jabber is aweful...just use gajim as jabber client and search for a jabber server with many transports available ;) [11:46] i use biltbee [11:47] * persia doesn't think pidgin or gajim integrate with biltbee very well... [11:52] dholbach: pochu Thanks a lot. [11:52] :) [11:52] <\sh> hmm...I'm searching for someone in germany who wants to have a new job as IT Projectmanager :) [11:53] <\sh> Karlsruhe Area ;) [11:57] \sh: naah. using lots of servers is more fun. [11:58] \sh: I use my own server in London for jabber, slomos brothers server (de) for yim, norweigan for icq, swedish and danish for msns :-) [11:58] <\sh> Nafallo: lol ;) [12:00] I use my own server for jabber as well. :-) [12:00] \sh: bring the job in france and we'll talk [12:02] <\sh> rzr: that's a problem :) [12:02] <\sh> rzr: come to germany...karlsruhe is next to strassbourgh (sp?) [12:04] minghua: sure, that'S ok [12:04] I wouldn't mind re-packaging gusty applications for hardy, I was wondering if someone out there could walk me though it once first though. I am totally new to packaging [12:04] I did read the documentation [12:05] Is there anyone willing to give me a hand? [12:05] sectech: In many cases, the gutsy packages were just reused for hardy entire, unless there had been an update in the meantime. At this point, we're mostly looking at bugfixes, although there are still a few candidates for consideration for an update. What sort of thing would you like to do? === \sh is now known as \sh_away [12:07] I'm trying to find a way to contribute... I have enough programming experience just get by... I figured there must be something that I could work on [12:07] believe me I have plenty of time (I lost my job a while back haha) [12:08] Note to self: I should check whether sync is enough or a merge is required to get ruby1.9 from sid to hardy. === \sh_away is now known as \sh [12:09] sectech: Well, there are basically three classes of work that might be a good introduction to the process. Finding and fixing bugs (many have patches that just need review & integration), working on some of the QA tasks, and addressing integration issues. Also, some people like to focus on a specific programming language or set of application functionality. [12:10] Okay.... How about bug fixes and patching...I could give that a shot [12:10] when we've 0ubuntu1 and it mention about the maintainer field spec in changelog, it still needed at 0ubuntu2 revision ? [12:10] i need to mention about the spec in 0ubuntu2 changelog [12:10] ? [12:10] Kmos: We only rephrase all the "Retained changes" during a merge. An update just needs new changes. [12:10] <\sh> grmpf...never test afterstep in a running gnome desktop session... [12:10] persia: ah ok =) thanks [12:11] Basically I would reproduce the bug, apply the patch and see if it's still there right? [12:11] sectech: https://launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_contact=&field.bug_commenter=&field.subscriber=&field.component [12:11] k [12:11] That horrid URL will provide a list of all the bugs that have a patch candidate. Where the patch isn't a debdiff, or the sponsors aren't subscribed, it frequently needs review & testing. [12:12] ok... I'll look through that and see if I can make sense of it [12:13] Also, you might try https://launchpad.net/ubuntu/+bugs?field.tag=bitesize or https://launchpad.net/ubuntu/+bugs?field.tag=packaging, or even https://launchpad.net/ubuntu/+bugs?field.tag=patch as additional sources of things that tend not to be too hard (and the sort of thing for which people here may be happy to help if you get stuck) [12:13] <\sh> persia: could you do me a favour and catch the debdiff for afterstep from bug #174252 and upload please? [12:13] Launchpad bug 174252 in libungif4 "transition to libgif" [Undecided,In progress] https://launchpad.net/bugs/174252 [12:14] \sh: I've promised myself no sponsoring tonight in the hopes of catching up on a couple other things :( [12:14] <\sh> persia: ok :) np... [12:14] <\sh> pochu: you can do it now ,-) [12:14] Could anyone else please help \sh with this? I'm guessing it's needed now to resolve some alpha 3 goal. [12:14] * \sh 's fixing emacs21 now [12:15] <\sh> but before that..I'll upload the patch to debiqan [12:16] \sh: looking [12:16] <\sh> pochu: thx.. [12:17] \sh: It would be nice if you can avoid those timestamp changes in the patch... [12:17] \sh: But since pochu is looking now, you can ignore my opinion. :-) [12:19] minghua: that'd mean more work since those are autogenerated by autofoo, aren't they? [12:19] What about installing hardy and searching for bugs? just to begin with so I can get used to the QA system? [12:19] <\sh> minghua: well, that comes from a simple thing...the afterstep package needs some magic before working with dbs-edit-patch [12:20] <\sh> minghua: to use dbs-edit-patch you need to run make -f debian/rules debian/vars and this will introduce those changes [12:20] sectech: if it's not a critical box and you aren't afraid of breaking it or killing your cat, go for it :) [12:20] <\sh> minghua: I talked to robert (the debian maintainer) and it's normal [12:20] sectech: but keep an stable install somewhere just in case ;) [12:20] I think I have another hard drive around here. [12:22] <\sh> minghua: and yes, you can remove those changes from the diff but it's so trivial we can live with it somehow... [12:23] hi all [12:23] \sh: Ah, I see it's not easily avoidable. [12:24] \sh: Then I say it's not worth the effort. I am not the sponsor anyway. :-) === LucidFox is now known as Sikon_Stargate [12:28] sectech: Just in case, it's worth reviewing https://wiki.ubuntu.com/MOTU/Contributing. I'm guessing you've already read it from your earlier statement about documentation, but it might help give some hints about processes. [12:28] persia Yeah I did read that... [12:33] \sh: uploading [12:45] <\sh> pochu: thx a lot [12:46] <\sh> pochu: I'm adding a debdiff for emacs21 just now [12:47] When I start with horde... what's the URL where I would post the bugs to? [12:48] <\sh> sectech: horde bugs or ubuntu bugs? [12:48] sectech: Likely https://bugs.launchpad.net/ubuntu/+source/horde/+fielbug, but I'm just guessing. [12:48] ubuntu horde [12:48] <\sh> sectech: launchpad === Sikon_Stargate is now known as LucidFox [13:04] Hey pochu. Whielding the super upload opwers I see. Congratulations! [13:04] powers [13:08] hahaha [13:09] DarkSun88: Congratulations! [13:09] Thanks a lot Luke :) [13:09] At all my sponsors and not naturally :D [13:10] <\sh> DarkSun88: yeah congrats from me too :) [13:10] :D [13:10] Thanks [13:11] <\sh> well, camlimages, emacs21 and just now driftnet will be fixed too :) [13:12] <\sh> good afternoon jono and jdstrand :) [13:13] hi \sh! [13:17] hey \sh [13:19] <\sh> grmpf../me should get ready for the gym... [13:38] Can anyone stop this "Daniel Moyne" person's reporting bugs? [13:39] * minghua points at #181475 (and -76, -77, -81, -82, -83, -84). [13:40] minghua: he must have done a break at -78, -79, -80... [13:40] minghua: most of the earlier bugs on https://bugs.launchpad.net/~dmoyne/+reportedbugs don't seem quite so egregious. Perhaps just a multiple submit issue? [13:41] persia: Yeah, I meant temprarily. Not a ban. I assume bona fide here. [13:42] Seems to have stopped, anyway. [13:44] * minghua wonders why persia is so fast at marking duplicates... [13:44] * persia has practice :) [13:45] Can somebody please review http://revu.tauware.de/details.py?package=alliance and give their valuable feedback? Thanks in Advance. [13:45] minghua: Simple recipe: go to the submitters +reportedbugs, open all the bugs in tabs, click "Mark as duplicate" in successive tabs, grab the bug number into the X buffer in the last tab, iterate back middle-clicking and submitting. Reload +reportedbugs to ensure that you caught them all. [13:46] Actually, this works for a package bug page too. [13:46] tuxmaniac: Is it lintian and linda clean, with maxiumum verbosity and hardy versions, for both source and binary? (these generate >60% of my comments on packages on REVU). [13:49] persia: did you upload theseus this morning? [13:49] mok0: I don't remember uploading anything this morning. Why? [13:50] I patched it last nigth and it is already built. Just wondering who to thank [13:50] persia: I'm doing similar things here. But LP is not really very responsive for me... [13:50] mok0: The bug didn't get an assignee when it was sponsored? You can check the signature on the .dsc or on the mail to -hardy-changes if you like. [13:52] TheMuso: heh, yeah, and thanks :) [13:52] <\sh> pochu: http://launchpadlibrarian.net/11229263/emacs21_21.4a%2B1-5ubuntu5.debdiff http://launchpadlibrarian.net/11229512/camlimages_2.2.0-2ubuntu1.debdiff http://launchpadlibrarian.net/11229790/driftnet_0.1.6-7ubuntu1.debdiff http://launchpadlibrarian.net/11229884/gdal_1.4.4-1ubuntu1.debdiff ready for review and upload :) (bug #174252) [13:52] Launchpad bug 174252 in libungif4 "transition to libgif" [Undecided,In progress] https://launchpad.net/bugs/174252 [13:53] minghua: Interesting. My packets are going trans-pacific, and then trans-atlantic to get there. I don't know why I'd have less latency. [13:53] Ah. dholbach, thanks! :-) [14:03] \sh: that will have to wait, 'cos I'm off to lunch :) [14:03] <\sh> pochu: np ... just not to forget...wmaker just fixed..simage needs more love then I expected [14:03] \sh: feel free to poke DarkSun88 who is newbie ;) [14:04] <\sh> but right now, I'm off to the gym...need to get rid of 10kg ;) === LifeHacker is now known as tuxmaniac [14:05] persia, did you get my message? [14:06] tuxmaniac: Not that I noticed. What did you message me about? [14:07] LaserJock: your behind MOTU post is titled " dholbach " [14:07] Heya gang [14:07] looks like that might be incorrect [14:07] heya bddebian [14:07] lintian and linda are complaining about newer standards version is that warning ok persia ? [14:07] bddebian: I'm about to be off, but you were looking for me earlier? [14:07] Hi imbrandon [14:07] bddebian, boo [14:08] heya persia :) [14:08] persia: Yeah but I forget why :( [14:08] Hi tuxmaniac [14:08] imbrandon: I posted it [14:08] Hi bddebian [14:08] Heya geser [14:08] hello there :P [14:08] tuxmaniac: If lintian is complaining, you're not using the latest lintian. You may ignore linda for now when she says that 3.7.3 is too new. Also check the binary packages by running against $arch.changes [14:08] tuxmaniac: It is fine [14:08] persia: Oh I remember. I'll hit you up "tonight" if you are around [14:08] dholbach: ahh ok, it showed up on planet with the wrong title :) [14:08] tuxmaniac: oops, follow persia [14:09] bddebian: Tell me quick, and maybe I'll have a quick answer :) [14:09] imbrandon: argl.... [14:10] persia: Nah it was more about helping my dumb arse with something again [14:10] Please give me an advice. I am going to patch source to fix an FTBFS. The problem is due to missing header files from sources. But the function calls that are giving problem are anyway deprecated in latest GTK+. So is it better to replace those call appropriately or should I just go ahead and add header files. [14:13] slytherin: I like updating to the newest API: it means you have longer before the next time the package needs a patch, and upstream is usually happier to receive the update patches (if you do a good job). [14:13] persia: Ok. :-) [14:15] The functions are deprecated in GTK 2.12. So I guess it will be long before they are actually removed. But I will anyway replace those calls. === freeflyi1g is now known as freeflying [14:39] What TZ is slangasek in? [14:39] bddebian: He's on the west coast of the US. [14:39] bddebian: I don't know what $TZ that translates into. [14:39] soren: Ah that's right, thanks [14:40] bddebian: np :) [14:40] A little early yet then :-) [14:40] bddebian: Slightly, yes :) === \sh is now known as \sh_away === jono is now known as jono-in-email-he === jono-in-email-he is now known as jono-in-emailhel === jono-in-emailhel is now known as jonoinemailhell [15:15] hi got a suggestion re a possible fix for the issue of ubuntu (tis not its fault) managing laptop hd in laptop mode [15:35] * rzr updated http://revu.tauware.de/details.py?package=jaaa [15:50] dholbach: mail for you [15:50] apachelogger: gracias [15:51] de nada [15:51] I think ;-) [15:52] ja [15:54] jpatrick: très bien [15:54] apachelogger: merci === jonoinemailhell is now known as jono [16:42] yay, one more FTBFS sent down the rabbit hole. :-) [17:07] bddebian: hi, so two things on the asc upload [17:07] Uh oh [17:07] bddebian: 1) omg, who prepared this upstream tarball, it's an embarrassment [17:08] Uhm, upstream. :) [17:08] jdong: could you change the maintainer to MOTU when you upload the next version of gtkpod-aac? thanks :) [17:08] bddebian: 2) I don't know what the procedure is within the Debian games team for adding new comaintainers. According to the changelog, you added yourself; was this acked by someone who was an existing uploader, or is there a standing debian-games policy I can refer to in this regard? [17:09] bddebian: yeah, I know it was upstream, I did compare the tarballs... :) [17:09] tjaalton: aww you don't want to be scapegoat anymore? :D [17:09] slangasek: Hmm, good question, I don't know that we have a set "policy". I have usually just been adding myself when uploading. [17:09] jdong: right, I don't use it anymore, so.. :) [17:10] banshee is a whole lot easier [17:10] slangasek: BTW, I built it with libparagui1.1 on my sid laptop this morning and everything works fine. [17:10] tjaalton: ok, will do. [17:10] bddebian: I'd appreciate a clarification on this, then; I don't assume that just because someone has commit access to a repo, they're empowered to mark themselves as an uploader [17:10] (and this would be a blocker for me sponsoring it to Debian) [17:10] slangasek: fair enough [17:11] jdong: great, thanks! [17:13] I'm thinking I really should have just stuck with porting Hurd packages.. [17:14] there's so many PATH_MAX waiting for you! [17:15] hah [17:16] Well let's see if I actually get a response from the Games Team ML this time... === davro is now known as davromaniak [17:17] k [17:51] bah, dholbach needs to get some real American hours ;-) [17:53] LaserJock: you could also adjust to european working hours :) [17:54] umm .... [17:54] ;-) [17:55] Hi, I'm still looking for a revu of http://revu.tauware.de/details.py?package=libserial (it's a small package to build) [17:56] LaserJock: Or you can just say screw it like I'm getting closer to doing.. :) [17:56] bddebian: lol [17:58] slangasek: what exactly is a release wizard? :D [17:58] I think I'm either going to have to apply for DD or stop trying to work with Debian [17:58] there's this DM thing now as well [17:59] joejaxx: a modal dialog that walks you through releasing an OS [17:59] slangasek: bah :P i mean the contributor position :) [17:59] slangasek: haha :P [17:59] slangasek: based on ncurse library? :) [18:00] azeem: where is the information on DM's? [18:00] joejaxx: python-glade [18:01] azeem: Aye, but I'm not sure that is enough [18:01] * joejaxx at the developer corner and does not see it [18:01] s/at/is\ at/g [18:01] slangasek: :P [18:02] bddebian: if you're talking about asc, I think it would be equally inappropriate for a DD to add themselves to uploaders without consulting the current uploaders (and I have dressed down DDs for this before) [18:02]