[00:00] RainCT, i guess you can nuke that fake team then alltogether [00:01] it's not gonna serve any purpose ever [00:01] Yeah [00:02] superm1: uhm, the confirmation page has no "OK" button, only "Cancel" :P [00:02] yay launchpad [00:03] superm1: Also, I'm not sure whether that will send a mail to everyone. Maybe I should just leave it. [00:03] i found the same problem trying to delete ~ubuntu-mythtv yesterday when i was doing other team cleanup [00:51] Can I request for syncing a package that is still in Debian new queue? [01:01] anything that's dgetable. [01:01] probably best if you wait til it's accepted, though. [01:03] oh, thanks [01:03] one of may package is in the new queue from Jan 2nd till now, don't know when will it be accept to archive [01:06] \sh: libjs-dojo made it into unstable :) [01:22] * StevenK bugs wgrant [01:33] StevenK: Hi. [01:33] wgrant: Isn't there a timeout to kill builds that sit there and spin? [01:34] (See https://edge.launchpad.net/builders/sejong ) [01:40] StevenK: Yes, but it's slave-side. [01:40] So if the slave dies, no timeout. [01:41] Ah, so sejong might have just rolled over and died [01:41] Not completely. [01:41] It's still responding to XML-RPC. [01:41] But maybe sbuild has hung. [01:41] Mmmm [01:50] RAOF: file a bug if you need dh_xulrunner updated :) [01:50] micahg: I was going to, with a patch attached. [01:50] cool :) [02:00] Hello everyone! Anyone up to advocate/review qt-shutdown-p? - I think there are no more Bugs, Errors and no lintian warnings. qt-shutdown-p is a small program to shutdown the computer. http://revu.ubuntuwire.com/p/qt-shutdown-p === jdong- is now known as jdong [05:26] Yes! I (finally) win! [05:26] gnome-shell (and anything else that depends on gjs, which is nothing at the moment) now builds! [05:29] i can sense the relief :) [05:31] RAOF: BTW, xulrunner is moving to universe... [05:31] menesis: There is a Debian/Ubuntu Zope team that works mostly by getting stuff into Debian first. I would recommend you contaxt them. [05:33] micahg: You mean the current xulrunner package, which is 1.8, right? Not xulrunner-1.9.1, which is needed for Firefox? [05:33] RAOF: xulrunner-1.8 shoudl have been dropped already [05:33] And xulrunner-dev is still going to point to xulrunner-1.9.1-dev, right? [05:33] xulrunner-1.9.2 for lucid will be in universe [05:33] once the ff migration is done [05:34] What's FF migrating to? [05:34] RAOF: all in one package [05:34] No longer pretending you can use it as a lib, eh? :) [05:34] Wait. Does that mean we'll have two copies of the xulrunner code? [05:35] RAOF: no, it's so we can jump major upgrades for FF without breaking all the rdepends on xulrunner [05:35] RAOF: yes [05:35] Sounds like xulrunner needs to be removed then. [05:35] No way we can maintain it. [05:35] Eeep. [05:35] that's why it's going to universe [05:35] apps still build against it [05:35] micahg: What do you think we do here? [05:35] ScottK: I know [05:35] sorry [05:35] "Going to Universe" doesn't mean doesn't need maintaining. [05:36] We should, instead, have libs building against the firefox package? [05:36] If it's too hard for mozillateam to maintain in Main, what hope do we have? [05:36] RAOF: no -dev packages [05:36] Sounds like time for a pile of removal bugs then [05:36] Man, this would be so much easier if gecko was an actual library. [05:37] RAOF: I already showed you the bug for that :) [05:37] ScottK: you'll have to talk to asac about that [05:37] micahg: No, that was the bug to make SquirrelMonkeyFish an actual library :) [05:37] it seems like most upstreams are moving away from xulrunner anyways [05:38] On the basis that it's a huge pain in the arse, I'd guess. [05:38] No. I'll take it up with the release team. [05:38] Apart, of course, for gnome-shell. This could make MM... interesting. [05:39] I presume we'll want gnome-shell in main for MM, which means gjs in main, which means some form of libmozjs in main available for it to link to. [05:39] ScottK: here's the blueprint: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model [05:39] I'm familiar with the Firefox part, not the dumping unsupportable crap on the community part. [05:42] sorry ScottK, I never thought of it like that [05:42] micahg: That's the effect. [05:43] Presumably something's been done about couchdb, too, which I presume we still want in main for Lucid? [05:43] Seems like an odd thing for a database to depend on. [05:44] Javascript! [05:44] RAOF: idk, we might help them port to webkit if they're willing [05:44] Chromium has an actual javascript library, doesn't it. [05:44] libv8 IIRC. [05:45] RAOF: they're worse than mozilla about versioning [05:46] ScottK: can I ask you about the zend framework backport? [05:46] Does *anyone* have a javascript library that has an actual stable ABI? [05:46] Greetings, folks! We're hard at work on a new version of Tahoe-LAFS. Our plan for releasing a new version in time to get uploaded into Lucid has slipped twice now: http://allmydata.org/pipermail/tahoe-dev/2010-January/003621.html [05:46] RAOF: I think webkit does [05:46] Dear lord! [05:47] micahg: What bug? [05:47] bug 488633 [05:47] Launchpad bug 488633 in karmic-backports "Please backport zend-framework 1.9.6-0ubuntu1 from Lucid" [Wishlist,Fix released] https://launchpad.net/bugs/488633 [05:47] And by the way, check out this praise of Tahoe-LAFS from a blue-ribbon panel of USA national cyber defense experts: http://tinyarro.ws/zooko [05:48] ScottK: there was a security alert for that version and we pushed 1.9.7 already [05:48] can I change the bug to that version? [05:48] micahg: Yes. [05:48] can you reack afterwards? [05:48] Let me know when you're done and I'll ack the change. [05:49] Does it makes sense to drop .la files from a -dev package ? I'm looking after a merge, and the main difference is that .la files are not installed anymore [05:50] ScottK: done [05:50] oops, I should confirm too [05:51] fabrice_sp: .la files aren't useful at best and are annoying at worst. If the new debian revision doesn't install the .la files, that's perfectly fine. [05:51] ScottK: really done this time :) [05:51] RAOF: thanks! That means that one can be a sync ;-) [05:52] is it the same with .a files? [05:52] aren't they used for static linking? [05:52] Yes, they are. [05:52] That't exactly what they are. [05:53] ok. Thanks again :-) [05:53] fabrice_sp: libtool requires them. they are not strictly needed by ld(1) [05:53] .la are quite different, though. They do a similar job to pkg-config, but in a more convoluted way that everyone seems to hate. [05:53] they are plain text files with various meta information [05:54] oh, I'm talking about .la files. .a files are ar(1) archives of object files (.o) [05:55] ok. Just in case, I'll check that rdepends still builds then [06:01] micahg: Ack'ed. [06:01] ScottK: thanks [07:04] good morning [07:24] YokoZar: wine isn't installable. [07:24] YokoZar: wine (1.1.36-0ubuntu2) Depends: wine1.2, but wine1.2 (1.1.36-0ubuntu2) Conflicts: wine (<< 1.2) === Quintasan1 is now known as Quintasan [08:03] how do i tell pbuilder to add my ppa from launchpad to its sources.list? [08:17] andruk: othermirror in .pbuilderrc [08:27] so i put the line 'OTHERMIRROR="deb http://ppa.launchpad.net/csm-ticc/tablettray/ubuntu karmic main"' in my ~/pbuilderrc, but how do i add my gpg key? [08:32] andruk, you don't need your gpg key, apt in pbuilder runs unauthenticated [08:34] tell that to: http://pastebin.ubuntu.com/360524/ [08:35] on second look though, thats only a warning... [09:47] thanks Hobbsee and directhex [09:47] :-) [10:12] I have this error when I run "debuild -S": http://paste.ubuntu.com/360560/ [10:12] and I can't sign the public key [10:13] BlackZ: debuild -S -us -uc will create an unsigned package [10:14] randomaction, yes, but I should sign it, or not? === virtuald_ is now known as virtuald [10:15] signing is only important when you want to upload it [10:16] geser, yes, I should upload it [10:16] signing is necessary when you are uploading to archive or PPA [10:16] so I must sign it [10:16] you need a key, then [10:16] I have created, but I can't sign it [10:17] try "debsign -k0x22C75AE3 autotrash_0.1.1-0ubuntu1_source.changes" [10:19] geser, http://paste.ubuntu.com/360563/ [10:19] your key ID must match your name/address in changelog [10:19] he did specify the key id in the last attempt [10:21] it may be a problem with your gpg setup, as it can't find the key [10:22] BlackZ: does "gpg --list-secret-keys" list your key? [10:24] geser, yes [10:26] hmm [10:32] have you tried if you can sign a file (doesn't matter what kind of file) with gnupg? [10:33] geser, Successfully signed dsc and changes files [10:33] solved [10:33] thank you [10:34] I have re-created the key [10:34] without "BlackZ" as comment in the key === arand_ is now known as arand === dholbach_ is now known as dholbach [12:22] <^arky^> Hi, any compiz packing team member help me patch bug 507964 [12:22] Launchpad bug 507964 in compiz "Application Switcher keybinds conflicts with gnome default" [Undecided,New] https://launchpad.net/bugs/507964 [12:26] ^arky^: try #ubuntu-dekstop [12:26] ^arky^: try #ubuntu-desktop [12:26] sorry :) [12:27] <^arky^> thanks dholbach will do that [13:10] kees: yeah I meant to do it the other way (and have wine >> wine1.2) [13:58] Hello everyone! Anyone up to advocate/review qt-shutdown-p? - I think I've done everything that fabricesp said. http://revu.ubuntuwire.com/p/qt-shutdown-p [14:02] hakaishi: I don't really have time to review it but another point would be the changelog. Use -0ubuntu1 instead of -0ubuntu2 [14:03] hakaishi: maybe make rules files more readable too (some newlines wouldn't be bad) [14:04] sebner: I thought that it should be -0ubuntu2 if it is a second upload with the same source... [14:04] sebner: okay, thanks [14:04] hakaishi: oh, I didn't know it's already in the archive [14:06] sebner: ah^^ ... seems I mistook something right now [14:06] hakaishi: nah it's not in the archive. New stuff enters the archive generally with -0ubuntu1, then you increment the versionsnumber for further uploads [14:21] sebner: Is it okay now? [14:26] hakaishi: looks better now but wondering about your rules file anyways. Normally, http://pastebin.com/m4b8274cf should be enough but it fails. What's with this permissioned deniend stuff? [14:30] hakaishi: found the issue [14:30] hakaishi: proper solution: http://pastebin.com/m5e497858 [14:30] hakaishi: that's all you need in your rules file [14:36] wb hakaishi , got my messages? [14:39] hakaishi: sebner: Why call dh_auto_build in override_dh_auto_build if the right thing to do is "qmake" ? [14:39] Just don't bother including that line :) [14:40] persia: ah right, was confused with his $(MAKE) so I replaced it the sane command :) [14:40] sebner: Ah, if was previously qmake; ${MAKE}, then it's correct to call dh_auto_build [14:41] (or at least this does no harm) [14:41] persia: haha, right. DON'T confuse me! [14:41] persia: yeah, just testbuild. auto_build is necessary [14:42] But dh_auto_install oughtn't drop out of a build if it can't do anything. That seems like a bug. [14:43] persia: well, dh_auto_install normally calls make install and there is no such thing, he installs the stuff manually with dh_install (.install file), so you have to skip it or it fails imho [14:44] sebner: Right, I understand the application here. I just think it's a workaround for a bug. [14:44] persia: sure, bug of debhelper. shouldn't fail but skip automatically [14:44] I think dh_auto_install ought fail gracefully if there isn't an install rule. [14:44] Right. [14:45] persia: poor people like us have to use workarounds :) [14:45] sebner: Why? Surely your perl is sufficient to fix it :) [14:45] persia: no perl et al :P [14:46] Oh well. [14:46] persia: C#, java and after some dirty haXX0ring and copying python. nahh, .. the youth of today. such useless languages :P [14:46] date [14:46] hi Laney [14:47] excuse me [14:47] Fri Jan 22 14:46:58 UTC 2010 [14:47] hi sebner [14:47] Laney: haha, we now have persia bot :P [14:47] persia: just a moment please. I'm a little confused. I just have to override_auto_build: with qmake? But pbuilder will fail with permission denied... so I'll have to add a override_auto install: dh_install. Is that right? [14:47] hakaishi: proper solution: http://pastebin.com/m5e497858 [14:48] * persia agrees with sebner [14:48] okay, thank you [14:48] hakaishi: auto_install only fails because there is nothing to install [14:48] dh_install is for the .install file [14:48] Well, at least it's as proper as we're going to get without hacking debhelper. [14:48] which would be override_dh_install what you don't need [14:48] Or creating an install: rule and overriding the entire sequence. [14:48] (which you also don't need) [14:48] persia: I'll check if there is already an open dh bug about it [14:49] sebner: The workaround is mentioned in the manpage :) [14:49] hakaishi: the easiest for now is really my proposed solution [14:49] persia: haha, fail by design then [14:49] ^^ [14:49] sebner: Well, it still works for 90% of packages, which was the point. [14:50] persia: you are right but speaking about sanity ... [14:51] heh. [14:51] perhaps this ist because I have a install rule in the Makefile [14:51] hakaishi: you should make sane makefiles then :P [14:53] hakaishi: If you put an install rule in your makefile that respects DESTDIR, you should be able to drop your install file and let dh_auto_install do it's magic. [14:53] persia: wah wah wah, the manpage speaks about 90% working packages and "Skip it and ***run make install manually***", and the manpage says: if there's a Makefile and it contains a "install" target. The word here is ***if*** so it's a real bug imho as it seems that it should work/skip automatically [14:53] sebner: Interesting point. I can see that argument. File the bug :) [14:54] ahm, the Makefile is generated like that, because I want the possibilty to install from Source to [14:54] why does it fail here? [14:55] * Laney has projects where the makefile doesn't have an install target which dh7 copes with fine [14:55] persia: Laney : Oh, it might be another bug. It fails with "permissioned" deniend for some files so the makefile might be b0rken and not dh_auto_install itself [14:55] hakaishi: have your upstream Makefile install to ${DESTDIR}/${PATH} rather than /${PATH}. If DESTDIR is unset, it will install to system locations. If it is set, it will install for packaging. [14:55] Indeed. It sounds like an issue with the Makefile. [14:55] I would guess that is the case [14:56] it's probably trying to install into the system [14:56] * sebner says sorry to his beloved dh7 and gives it a cookie :) [14:56] persia: why do I need to upstream the Makefile, if it is generated by qmake? [14:57] hakaishi: You don't. In that case, you want to draft a qmake source file that generates an install rule that installs to ${DESTDIR}/${PATH} [15:00] persia: Sorry, I don't get it... [15:00] OK. Let's set qmake aside for the purposes of discussion. We'll get back to it once the desired behaviour is clear. [15:01] So, you have a Makefile with an install rule. You want this to be able to be used by people who don't use the package, so they can run make; make install [15:01] But when you run that install rule inside a package build, it fails, because it doesn't have permission to write to system locations. [15:01] persia: but this is what it already does, isn't it? [15:01] Yes. [15:02] The Makefile probably has lots of lines like `install -m 755 /usr/bin/foo` [15:02] can someone explain me what the deploy.tar.gz here is for ? I thought in source format 3 there is only a orig.tar.gz and debian.tar.gz file: http://packages.debian.org/source/sid/jxplorer [15:02] If the Makefile instead had lines like `install -m 755 ${DESTDIR}/usr/bin/foo`, then if DESTDIR is unset, the behaviour would be unchanged. [15:03] This is good for the `make; sudo make install` case. [15:03] Within the packaging, DESTDIR will be set, so it ends up installing in /foo/bar/baz/quux/debian/tmp/usr/bin/foo [15:03] aha, I get it. thanks [15:04] Which means that the *same* rule in the Makefile can work for both the non-packaged case and the packaged case. [15:04] So you just need to change the qmake source to do that. [15:05] c_korn: See the .dsc. As I understand it, one can have an arbitrary number of objects defined, and the dsc ties them together. [15:05] persia: isn't it about multiple tarballs? [15:06] c_korn: In this specific case, it appears that upstream has a separate source release and installer release, and these have been packaged together. [15:06] <^arky^> Modifying site packages variable, need help with bug 499990 [15:06] Launchpad bug 499990 in labyrinth "fails to start due to missing package import" [Undecided,New] https://launchpad.net/bugs/499990 [15:06] sebner: "objects" can be "tarballs", if one likes :) I believe one can also use zip archives, flat files, etc. [15:06] c_korn: http://wiki.debian.org/Projects/DebSrc3.0 ... samples: # sample1: 3.0 (quilt) with orig.tar.gz / debian.tar.gz and additional tarballs with all compressions schemes <-- this might be [15:07] persia: ohh, I didn't know zip and that stuff is allowed too [15:07] persia: ah, *all* compressions schemes [15:08] sebner: I'm not 100% sure that other stuff works now, but I believe that was the long-term intent. [15:08] sebner, persia: thank you [15:08] persia: nvm. I'm just happy that now .gz and .bz2 is allowed as upstream tarball :) [15:08] c_korn: yw [15:14] <^arky^> dholbach: a quick question about labyrinth package [15:16] ^arky^: shoot [15:18] <^arky^> dholbach: bug 499990 'site-package' is hardcoded [15:18] Launchpad bug 499990 in labyrinth "fails to start due to missing package import" [Undecided,New] https://launchpad.net/bugs/499990 [15:19] <^arky^> in bin/labyrinth and labyrinth/defs.py [15:19] ^arky^: if you want to fix it, please go ahead, I'm happy to sponsor it or take a look at it [15:22] persia: I don't know how do this in the .pro file, can you tell me? [15:22] hakaishi: Sorry, I've never used qmake. [15:22] <^arky^> dholbach: Thanks, doing just that. My question is should I patch all the files under debian/ directory ? [15:23] persia: okay, then I'll just try another time. cu === arand_ is now known as arand [15:27] ^arky^: https://wiki.ubuntu.com/PackagingGuide/PatchSystems#CDBS with Simple Patchsys [15:31] <^arky^> dholbach: thank you [15:31] no worries :) [15:31] thank YOU [15:37] Upload to revu via ftp from network behind the proxy does not work for me ? Is there any way to upload via http ? [15:40] jariq: There isn't. === yofel_ is now known as yofel === solarion is now known as Solarion [16:40] hi, i'm a newbie with a rather trivial question: what do i have to specify in debian/rules if the actual sources (including autotools files and everything) are in a subdirectory of a package? [16:44] <^arky^> dholbach: you still around man [16:45] ^arky^: yep [16:46] anyone? i tried dh $@ --sourcedirectory=src, but that doesn't seem to do the trick [16:46] <^arky^> dholbach: source uses '@PYTHONDIR@' variables where does this get site in debian package? [16:46] there's a line: AUTOMAKE=automake-1.9 autoreconf -ivf [16:46] that causes a choke: autoreconf: `configure.ac' or `configure.in' is required [16:47] (in override_dh_auto_clean) [16:47] <^arky^> dholbach: Is it the 'configure' file that gives '@PYTHONDIR@' values ? [16:48] ^arky^: I don't know - might be worth forwarding that bug to upstream [16:49] <^arky^> dholbach: ok [17:01] AAAH stupid PPA! === mathiaz_ is now known as mathiaz === fta_ is now known as fta === cyphermo1 is now known as cyphermox [19:51] hi folks [19:51] Hi sistpoty [19:51] hi geser [19:52] haha, I'm so lazy, I don't even upload anything myself anymore: bug 495772 :) [19:52] Launchpad bug 495772 in pearpc "Unable to compile package acquired through apt-get source" [Undecided,Fix released] https://launchpad.net/bugs/495772 [19:53] hello geser ;) [19:53] hi [19:53] Hi BlackZ, ajmitch [19:53] hi ajmitch [19:54] (so ctrl-w closes a kvirc window, as I just figured *g*) [19:56] heh [19:56] * ajmitch wonders when wgrant will be around this morning [19:58] * sistpoty grumbles a little bit about ScottK for sagemath... downloading a 57MiB tarball doesn't suggest getting it in shape again will be a simple task [19:59] sistpoty: I think we're going to have to remove it. [19:59] ScottK: oh? so I should focus my work elsewhere? [19:59] Debian maintainer said it needs a new upstream release to work with Python 2.6. [19:59] Yes. [19:59] Unless you really want to package it (it's a beast I understand) [20:00] ScottK: not really [20:00] Boost transition is done. [20:00] My suggestion is work on FTBFS or NBS. [20:00] I don't have a hard one handy. [20:00] ok, will do, thanks ScottK! [20:05] sistpoty: I noticed a bunch of ftbfs packages while rebuilding ffmpeg's reverse depends [20:05] hi siretart [20:05] sistpoty: I didn't check all logs, but none of those I've seen were because of ffmpeg, all were because of other problems [20:05] hi sistpoty :-) [20:05] huhu sistpoty siretart :D [20:05] hi sebner [20:06] hi sebner! [20:06] * sebner reads the backlog in case somebody already asked siretart about gstreamer-plugins-bad [20:07] siretart: got a package you want me to look at in particular? [20:08] sistpoty: http://paste.ubuntu.com/360846/ [20:08] is a copy of my ftbfs folder [20:09] thanks siretart, I'll start with k9copy [20:10] hm, where is k9copy from? marillat? [20:11] oh, looks like ubuntu native one :) [20:13] siretart: you can strike out smilutils from that list, this one is already fixed [20:16] sebner: I'm not sure what's the deal with gstreamer-plugins-bad, but we have a ftbfs fix for gst-plugins-bad0.10 waiting to be sponsored [20:16] randomaction: sounds interesting :D [20:16] geser: excellent. thanks [20:16] hola hola geser :) [20:17] Hi sebner [20:21] hello [20:23] ajmitch: Hi. [20:25] wgrant: morning, going to head out & enjoy the sunshine today? :) [20:25] ajmitch: Ahem. [20:27] * ajmitch has had breakfast but probably needs some caffeine to function for the day [20:31] hm.... /var/lib/dpkg/info/tex-common.postinst: 1011: kpsewhich: not found (dependency problem? worked fine after a dpkg --configure -a) [20:48] could it be somehow related to texlive-base binaries sitting in the NEW queue? [20:54] bah :( no new TeX before next week [21:03] oh, tl2009 is in lucid NEW? \o/ [21:06] siretart: actually texlive-base 2009-7 is already through NEW [21:06] thanks to out-of-order processing done by jdstrand :) [21:07] jeez, give me a second to get through it! ;P [21:08] geser: what else is needed besides that? [21:09] jdstrand: I don't see anything TeX related in the NEW queue left [21:10] k [21:10] fyi, texlive was the only thing I deNEWed related to that [21:45] hello [21:46] !ops [21:46] Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpds! [21:46] Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution. [21:46] Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution. [21:46] Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution. [21:46] Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution. [21:46] !ops +R this channel [21:46] Error: I am only a bot, please don't think I'm intelligent :) [21:46] Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution. [21:46] Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution. [21:46] Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution. [21:46] Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution. [21:46] Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution. [21:46] Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution. [21:46] thanks tsimpson [21:46] just a note, do not click that link [21:47] okay, now i understood what those attacks were [21:48] lol [21:48] tsimpson: no worries, you got it under control [21:48] ahh, SECURE is set [23:01] hi all, I filed this bug a little while ago: https://bugs.launchpad.net/ubuntu/+source/acpid/+bug/507778 so can anyone sponsor it, it been on the queue for a while [23:01] Ubuntu bug 507778 in acpid "Please merge acpid (1:2.0.0-1) from Debian testing" [Undecided,New] [23:04] you need a core-dev for that as it's in main [23:05] dhillon-v10: slangasek and mathiaz discussed that request yesterday. [23:05] geser: alright [23:05] jpds: so what happens now, I should wait for some time right [23:07] I'd talk to thme firsyt. [23:07] mathiaz: ping regarding a merge :) [23:07] jpds: alright :) [23:08] dhillon-v10: well - the question is whether the new version of acpid (2.0.0) should be pulled in lucid - considering that it's new code (?) for a an LTS [23:09] dhillon-v10: as I'm not familiar enough with acpid, I defer to slangasek on wether 2.0.0 should be pulled in [23:09] mathiaz: alright that makes sense, well the good thing is that I am getting better at merges (slowly) [23:10] dhillon-v10: right - the issue here is not wether your work is should be improved, but rather if we should *actually* merge the new version [23:10] mathiaz: understood :) thanks for the info. [23:10] dhillon-v10: some packages are more touchy - it may well turn out that 2.0.0 should be included in Lucid [23:11] dhillon-v10: in which case your merge proposal will be reviewed again [23:11] mathiaz: true, this one goes to main so its understandable [23:12] mathiaz: oh wait, while you are around, can you tell me why one of my patches isn't applying, let me get you the link [23:13] mathiaz: alright this one: https://bugs.launchpad.net/ubuntu/+source/cln/+bug/508995 [23:13] Ubuntu bug 508995 in cln "Please merge cln (1.3.1-2) from Debian Testing" [Undecided,New] [23:14] dhillon-v10: which package did you merge from? [23:14] dhillon-v10: the changelog entry in the diff shows an entry for unstable [23:14] dhillon-v10: so you haven't probably merged from the *latest* version of debian [23:15] mathiaz: the testing one, here: http://packages.debian.org/changelogs/pool/main/c/cln/current/changelog [23:16] dhillon-v10: the base debian package you've used is 1.3.1-1 [23:16] dhillon-v10: in the diff, you can see entry for 1.3.1-2 - that shouldn't be there [23:17] dhillon-v10: you wanna attach the debdiff between the debian version and the merged ubuntu version [23:17] dhillon-v10: the *latest* debian version - which in this case is 1.3.1-2 [23:18] mathiaz: alright I see what I did wrong, but the merge was mostly done by bzr so I don't understand what went wrong there [23:18] dhillon-v10: probably that the bzr branch for the Debian package wasn't up-to-date [23:19] mathiaz: alright I guess I am better off merging by hand :) [23:19] mathiaz: would you be around in like 5 mins. so i can show you my diff [23:20] dhillon-v10: I should be [23:28] * persia idly notes that #ubuntu-devel may be a more appropriate place to discuss issues with seeded packages. [23:29] (or some more specific channel) [23:34] persia: alright so there's a different package and when I merge that, it turns out that the only change is in changelog and control file, that's it, I double checked and nothing is there, is that possible [23:35] Yep. I just fixed FTBFS for plymouth on four architectures with a change like that to libdrm recently. [23:35] sure, if Debian merged our changes, then only our changelog entries and the updated Maintainer field are left after a merge (which should be a sync then) [23:36] The important thing to check is *which* changes to debian/control [23:37] Another example would be the outstanding tiemu merge, which just has some dependency changes because we don't have iceweasel. [23:38] persia: yeah I checked that like 4 times, and the last upload fixed got about everything so :) [23:40] As geser said, if all the fixes have been applied upstream, you can just sync and drop the changelog and maintainer changes. [23:41] Just make sure there's nothing missing. === vorian is now known as v