[00:49] anyone around for a quick mplayer upload to fix bug 482408? [00:49] Launchpad bug 482408 in mplayer "mplayer overrides pulseaudio's "saved volume" value" [Low,Fix committed] https://launchpad.net/bugs/482408 [00:49] afterward should be SRU-able to 9.10, too [00:50] * jdong will bite :) [00:50] jdong: thanks! [00:51] err... [00:51] siretart: how would you like to handle the pkg-multimedia-ness of mplayer? [01:01] if i request a sync for a package in main on LP is there anything else I need to do to get someone to look at it? [01:04] mannyv: might be easier to use the requestsync tool [01:06] mannyv: would be nice if you'll do build test [01:07] micahg, I did use requestsync [01:07] ari-tczew, I did test build and test install [01:07] yhym ok [01:08] i was wondering if afterwards i just wait for someone to come along and sync it or if i have to do something else to get someone to notice it [01:09] i havent been around long but i used to be serialorder then i decided to follow suit and just use my real name =) [01:10] dtchen_: let's hope you get your core-dev upload rights back soon :) [01:10] I applied; I'm awaiting development membership board's say [01:10] I don't think there should be too many objections [01:11] well, status quo won't change anything. It's unlikely that bugs will stop flowing in or that I'll stop fixing them regardless whether I can upload. :-) [01:11] no, it just makes things smoother for you [01:11] you've done an impressive amount of work :) [01:12] I wish I didn't have to blog every time someone writes something daft. :/ [01:13] there seems to be a lot of annoyed & confused people around [01:13] I didn't know that MOTUs had so much power :) [01:17] I know seb128 replied to the first post the first time this whole crack came about (https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-October/009541.html), but I guess that was lost on many people, too :/ [01:30] whats the command to look at a dsc and show what gets installed and what it contains etc... [01:35] mannyv: nope, I believe that's it === testing is now known as Guest63960 === micahg1 is now known as micahg [01:46] is this still correct: https://wiki.ubuntu.com/UbuntuDevelopment/FAQ#I%20need%20to%20fix%20a%20bug%20in%20the%20upstream%20provided%20source,%20modify%20the%20source%20or%20add%20a%20patch? [01:48] micahg: Yeah, it looks correct. Although, it could be expanded on a little more [01:48] ok, I should have specified, I was wondering about the part about modifying the source [02:01] #join ubuntu [02:02] sorry about that === micahg1 is now known as micahg [03:34] http://brainstorm.ubuntu.com/idea/2073/ [03:35] ^ I bet most people who downvoted this did it just because it's Mono. [03:50] LucidFox: that one's been talked about a bit [03:50] I know. :) [05:18] porthose_, there? About bug #484678 [05:19] Launchpad bug 484678 in ampache-themes "Sync ampache-themes 3.4.3-1 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/484678 [06:58] Hello, could someone help me with this wierd build failure: https://launchpad.net/~aelmahmoudy/+archive/ppa/+sourcepub/871610/+listing-archive-extra [06:58] it builds for i386 only [07:39] AnAnt> The i386 build does binary while the amd64 build does binary-arch [07:39] LucidFox: huh ? [07:40] LucidFox: so ? [07:40] The amd64 build doesn't build the binary-indep package, and the builder tries to access a file resulting from building the pcb-common package. [07:40] why is that different behaviour ? [07:41] Binary-indep packages are built only once, since there is no need to build them on every architecture [07:41] so, does the package needs fix or what ? [07:41] http://paste.ubuntu.com/322218/ [07:42] Yes, you need to fix the binary-arch phase so that it doesn't need files from debian/pcb-common in the arch-dependent package. [07:43] Let me look at debian/rules [07:43] ok, please do [07:45] Oh, nice, I wasn't aware of these override_dh_* makefile rules. [07:47] LucidFox: dh 7 ! [07:47] You need to ensure that what's written in override_dh_fixperms only executes for dh binary-arch, not dh binary-indep. [07:47] I know :) [07:48] dh_fixperms -i would do the trick ? [07:49] hmm, nope [07:50] how to do that ? [07:50] The problem is not with dh_fixperms [07:51] We could eschew override_dh_fixperms and modify the binary-arch rule explicitly, but I'm hoping for a cleaner solution [07:52] Apparently there's no way. Hmm... [07:53] Well [07:56] thanks for help [07:57] LucidFox: could it be by checking wether debian/pcb-common exists or not before doing the chmod ? [07:57] You could do that, too! [07:59] [ ! -d debian/$(package)-common ] || chmod <....> [08:19] btw, anyone interested in testing texlive 2009 ? [08:22] AnAnt> I am [08:22] I want it for an updated xetex. [08:23] ppa:aelmahmoudy/tl2009 [08:24] it's sync'ed from Debian's experimental [08:26] AnAnt: cool! thanks! [08:27] I hope it will be in lucid ! [08:28] AnAnt: I would support syncing it early in lucid to get maximum testing done. and we really do not want to have a tex from 2007 in a LTS release [08:31] YES [08:31] siretart`: you mean file sync request from experimental ? [08:31] * LucidFox adds the PPA [08:32] My "other software" tab in Software Sources now contains 11 external sources, all PPAs. [08:32] AnAnt: perhaps in parallel with a discussion on the mailing list [08:32] At this rate, it will be Karmic in name only. [08:33] oh, the ppa has no packages for lucid. :-( - well, I guess the karmic package should do fine as well [08:35] siretart`: I'm still using karmic [08:36] LucidFox: i've got 19 ;-) [08:37] AnAnt> http://paste.ubuntu.com/322240/ [08:37] oh ! [08:37] because I appended ~ to versions [08:38] ok, I think there is no need to append this ~, right ? [08:39] You can relax the dependencies [08:39] >= 2009-0? [08:41] or just >= 2009 [08:42] aptitude is having troubles to install any of those packages, it seems.. [08:42] How do I make dh_auto_clean use make clean rather than make distclean? [08:42] LucidFox: override_dh_auto_clean [08:42] Yes, I know, but does it execute anything other than make distclean? [08:43] I don't think I understand the question [08:43] override_dh_auto_clean: [08:43] have you looked at the source? It's perl, but the scriptless are rather short... [08:43] make clean [08:43] siretart`: source of texlive ? [08:44] no, that was for LucidFox [08:47] if I got dsc,orig & diff.gz files already, can't I just generate a source.changes file for them ? [08:48] you can, unpack the source and run dpkg-genchanges inside the package dir [08:50] Actually, the problem was elsewhere, as it turned out. [08:50] dh_auto_clean does invoke make clean if make distclean isn't possible. [08:51] But apparently CDBS's makefile.mk just ignores errors, while dh_auto_clean doesn't ignore them if the makefile exists. [08:51] yes, that's true [08:51] oh, CDBS [08:51] dunno about that [08:51] This is why the clean rule broke in the transition from CDBS to dh 7. [08:51] Basically, there's an upstream custom-written makefile that invokes an autogenerated makefile in src, unconditionally. [08:52] Need to file an upstream bug about that, but for now, [ ! -f src/Makefile ] || dh_auto_clean [08:54] I really like the override commands, they allow to transition from CDBS seamlessly in many cases. [09:06] LucidFox: the fix worked, thanks ! [09:15] AnAnt> By the way [09:15] you can also use >= 2009~ [09:15] er [09:15] >= 2009-1~ [09:16] LucidFox: why not just upload the correct version ? [09:17] Well, using the same version number in PPAs as in official archives is a Bad Thing(tm) [09:17] I thought it is a bad thing to do so BEFORE release [09:17] but after ? [09:18] you should make sure that users get automatically upgraded to the primary archive package if one is forthcoming [09:20] hmmm [09:20] well, I started uploading already [09:20] delete & repeat again ? [09:28] hi there, i was wondering if someone could have a quick look at something ifupdown-scripts-zg2 0.3-4 in karmic for me? All i'm trying to do is rm debian/ifupdown-scripts-zg2.dirs but dpkg-source is ignoring deletion of it so it doesnt show up in the debdiff. does someone know the reason? i could leave the file empty instead but i was curious [09:29] http://paste.ubuntu.com/322269/ [10:04] is the .dirs file perhaps in the orig.tar.gz and not in the .diff.gz? [10:06] thanks geser, its obvious now! the orig tarball has the debian directory, i thought that was not supposed to be in there? [10:07] it's preferable if it's not there but sometimes it is [10:09] is the best method here just to remove the entries from the .dirs and leave the empty file in place? [10:18] in this case yes (or you could rm it in the clean target [10:20] I think it's best to repack the upstream tarball to remove the debian directory from there. [10:20] And file an upstream bug report about it. [10:24] with format 3.0 (quilt), this is no longer necessary [10:25] Ubuntu doesn't support it yet, though. [10:25] Or rather, LP doesn't. [10:25] AnAnt> I see you uploaded pcb to m.d.n too, great! [10:25] it's WIP, and I read it will be available in two/three weeks [10:25] LucidFox: yeah [10:26] DktrKranz> Excellent news, I'll migrate my packages to the new format when support lands. [10:26] * DktrKranz too, at least some of them [10:27] with new format, packages which requires some patching hacks will benefit a lot [10:27] would removing the entry in .dirs to fix for now and filing a debian bug for repackaging be ok? since lucid will be syncing for a while [10:28] LucidFox: I don't think it makes sense to repack an .orig.tar.gz which is already in Debian (and Ubuntu) just to get rid of the debian dir within [10:28] :) [10:31] i noticed 3.0 allowed --include-removal option to dpkg-source, that would have made me happy [10:46] When I have multiple language versions of a document in subdirectories, should I only register en with doc-base, or all of them? === asac_ is now known as asac [12:07] Is there any way to get sponsorship requests in feed form? [12:12] LucidFox: IIRC launchpad offers the bug lists as rss feed, doesn't it? [12:14] Well, I'd like to receive a notification via RSS/Atom when someone subscribes ubuntu-universe-sponsors. [12:19] siretart`> So what's our stance on debian-multimedia.org? Historically some of our packages have been merged from it, are we going to move away from it? [12:23] LucidFox: well, I can only suggest to very very carefully inspect before touching anything from marillat [12:23] LucidFox: that site is a one-man show, who doesn't give a sh*t about licensing, compatibility with anything but his own systems, debian/rules or debian/copyright cleaness, etc [12:24] the only plus: he has an impressive amount of interesting packages [12:24] I know about all that. :) [12:25] LucidFox: if you ask me directly, I'd suggest maintain the packages independently [12:26] And to be fair, for some packages, merging them is 95% applying existing Ubuntu changes for cleanliness from version to version. [12:26] He refuses to repack the qdvdauthor upstream tarball to remove binaries, for example. [12:27] so it seems to me that merging from him doesn't seem to help much [12:28] Except for new packages. [12:28] And I'm considering joining the debian-multimedia team, although I have no experience with package development using a VCS. [12:29] oh, sending in debdiffs is great as well, you don't really have to learn git if you don't want to :-) [12:30] I've worked with git before, just not in conjunction with Debian packages. [12:32] git-buildpackage is really helpful here. it feels like debuild with a few extra options [13:02] Any reason mjpegtools is in multiverse? [13:03] I wondered about that as well, but didn't investigat the sources yet deeply. given that we promoted x264, we can maybe promote it. [13:04] And it's not in Debian because of patent issues? [13:06] LucidFox: since debian's ftpmaster currently seem to want to remove all of ffmpeg, I didn't really feel like finding out what they might or might not do with mjpegtools [13:07] Remove ffmpeg? Why? [13:07] Patent issues? [13:07] yes [13:16] What's the purpose of packages in git that aren't in Debian itself? [13:45] either for ubuntu, or debimedia. [13:45] debimedia is (at least its supposed to be) an repository with the 'missing bits' === fta_ is now known as fta === apachelogger_ is now known as apachelogger [15:34] Heya gang [15:34] hey bddebian! [15:35] Heya siretart [15:37] Hi bddebian. [15:39] Hi iulian [15:46] <\sh> emgent, ping... your exploit thingy where do I find more informations? === chuck_ is now known as zul [15:57] \sh: ola, i reply to you on FB:) [16:12] \sh: check again :) [16:14] <\sh> emgent, somehow like mod_security? === ubott2 is now known as ubottu [16:19] no really [16:19] it`s a service-product [16:19] we send via webapps all updates, user can delegate all to us [16:19] also, we are more aggressive to mod_security [16:19] and we can manage rules per domain [16:20] also in 2010 you will see the jesys appliance ;) [16:22] \sh: [16:23] I've already got my program packaged in a PPA, so I just submit a [needs packaging] bug for it? [16:23] <\sh> emgent, I hope those appliances can be scaled horizontally ;) [16:33] I want to get my package into ubuntu, but I don't know if it's good enough [16:34] sproaty, you should file a [needs-packaging] bug, assign it to yourself, and upload it to revu [16:35] but how about measuring the quality of the app? It's pretty functional, even at a 0.39 release, but I've been working on it for over a year [16:35] sproaty, is this an app you wrote yourself? [16:35] yes [16:35] I have it in the ppa [16:37] sproaty, REVU will allow MOTU to look at your *package*, and see if it's in order, it's less about the overall functionality of the software in it (as long as it's not completely broken) [16:37] well the package should be good, it's just some source python - real simple [16:37] the quality of the software itself is your responsibility, wrt being the package maintainer (the one to get the bugs from Ubuntu), and the upstream maintainer :) [16:38] ah right [16:38] so if you have users for your program, and it's something that can reasonably be added to the archives, there shouldn't be too much of an issue [16:38] I just thought they may have some policy against pretty active development, like I've released 4, 5 versions over the past month [16:39] cool, I've got around 5000 downloads so far, with a few people talking to me about the program, so I guess it's functional enough :D [16:39] what I mean by reasonably added is that it serves a real purpose, and if something similar already exist, maybe it does something more, or different, that is really good [16:41] it's nothing special, sort of an image editor, but not -exactly- pixel-based, since you can draw shapes, and move/edit these shapes (rather than pixels) [16:41] but I'll file it, and see what happens :) [16:41] i've not been brave enough to attempt to package my app yet [16:42] seems somewhat complicated :$ [16:43] I found it really simple [16:43] only problem is I keep re-creating my package from scratch and not .diff from the previous release [16:43] i've got to interact with dbs and stuff, that's the bit which seems complex [16:44] sproaty, perhaps then you should consider using bzr or something similar to keep your packaging [16:44] will probably copy the cacti package at some point, that seems to do pretty much the same [16:44] I use bzr, but for my code -- in what context do you use it for a package? [16:45] sproaty, you could keep a different branch that holds just the debian/ directory, then make your changes in there, each change in its revision, so you have history [16:46] ah right [16:46] but say I've build ppa-1 with debuild -S, as I do [16:46] that always asks me about "something something no diff.gz file found" [16:46] so surely there's a way for me to build the new package, ppa-2 against what's already in ppa-1? [16:47] sproaty, do you keep a debian/ directory in your source? [16:47] no, since it's cross-platform [16:50] ugh, I have to run. Shame, I want to get this done [16:50] sorry to leave it half-done [17:12] How does synaptic manage pinning? I just ran into a bug with it and I can't unforce a package version. [17:13] vadi2, better ask mvo :P [17:13] mk [17:13] he's not on [17:41] Hi [17:41] How would I do an upstream merge with debian? [17:42] I seem to remember reading something about it in the wiki, but I can't find it now [17:42] how should I file a bug about a debian library package not including the pkg-config file for itself? [17:43] upstream includes it, it was not packaged to install though [17:43] fahadsadah> Start with the Debian version, examine the Ubuntu changes and apply them. [17:43] Attach the diff.gz for the merged version to LP when ready. [17:43] NO! [17:43] not for a merge, attach the debdiff(s) [17:44] Oh, right! [17:44] * LucidFox facepalms [17:44] Attach the debdiff against the debian version. [17:45] is that to me? [17:45] diff.gz is for upstream updates within Ubuntu. [17:45] Arc> No, towards fahadsadah and Laney. [17:45] ah [17:46] Thanks [17:47] If the Ubuntu delta can be dropped, do I just get the package from Debian? [17:47] yes, that's called a sync [17:48] fahadsadah: you don't do a fresh upload, but order it via the bug-tracker [17:50] nevermind. the debian package is messed up beyond our ability to use it anyway [17:51] when our app gets packaged it'll have to be bundled with a static copy to avoid getting broke by debian-games team next time they decide to mess with upstream's defaults [17:52] what? [17:52] why don't you take your issues up with the games team? [17:52] oh this has been going around and around [17:52] libode gets built quite often for debian with double precision, which makes it too slow for games [17:52] but whoever at debian "owns" the package doesn't care [17:52] why is it ok for debian but not ubuntu? [17:53] so all the packages that use ODE as a dep end up having to package their own version of ODE [17:53] Arc: wuhhhhh woah! [17:53] I hold Ubuntu members to higher standards ;-) debian I gave up on years ago. [17:54] Arc: if there's an issue in the Debian package, fix it---and static copies *are not allowed* [17:54] I hope you don't find much support for that here [17:54] you should fix it in Debian [17:54] then we won't be able to package [17:54] *blink* [17:54] until they stop building it with non-default upstream flags it's unusable [17:54] packaging a new upstream release, some patches are still applicable but the line numbers of the changes have changed; do i need to recreate those patches or is quilt smart enough to locate the correct section of code in the file? [17:55] ode-config --cflags [17:55] -I/usr/include -DdDOUBLE [17:55] double precision is non-default and too slow for games, it's only recommended for scientific applications [17:55] Arc: you mean the software you're using is badly written and relies on hard-coded floating point lengths--and is probably going to fail with endian issues too? [17:56] sladen: no I mean that double precision is too slow so we don't support it. [17:56] fcuk112_: fix the patches so that they reliably apply cleanly [17:57] Arc: so it's got *nothing* to do with packing, merely a (likely misguided) belief and 32-bit floats are going to be faster [17:57] packaging [17:57] s/and/that/ [17:57] sladen: ok, thanks. [17:57] you believe that double is as fast as float? [17:58] Arc: ever heard of the phrase "premature optimization" [17:58] sladen: you're a debian packager aren't you? [17:59] * adama looks at sladen [18:00] Arc: Ubuntu *is* Debian; I think you'll find quite an overlap, and a strive to fix issues at the source [18:00] the hubris has exposed you :-P [18:00] what's the piece of software in question? [18:00] no, Ubuntu is not Debian. Ubuntu is a separate and distinct project which builds up from Debian [18:01] libode1 and libode-dev are in question [18:01] Arc: in much the same way that a steak *IS* beef? :> [18:02] we are universe and universe is debian [18:02] that's a disappointing viewpoint. [18:04] standing on the shoulders of giants is how technological advances are made is realistic amounts of time [18:04] everyone is free to re-invent the wheel, but clever people try not to [18:04] Ubuntu standing on Debian's shoulders != (Ubuntu == Debian) [18:04] Arc: so what's the broken piece of software that you're trying to link against libode? [18:05] anyways, back to real work [18:05] this issue will obviously have to wait until MOTU is disbanded [18:05] Arc: if I invent something, and then invent an improved version, who's shoulders am I standing on? [18:14] anyone know who "Arc" was---seems an interesting bit of outreach to follow-up on, even if we scared them away [18:16] he seems to still be connected [18:16] seems like a disappointing viewpoint [18:25] \sh: So, do we want fai back in the archive? It was removed from Karmic, but it wasn't blacklisted [18:42] emgent, what happened with bug 279755 ? [18:42] Launchpad bug 279755 in ubuntu "[needs-packaging] remastersys" [Undecided,In progress] https://launchpad.net/bugs/279755 === fenris__ is now known as ejat [18:53] http://www.pastie.org/706305 when i do a test install of the deb, it fails because of the depencies, but the dependencies are specified in the debian/control file - what is wrong here? [18:54] fcuk112_: dpkg doesn't install dependencies [18:54] do apt-get -f install [18:56] Laney: ok, thanks. [18:57] or use gdebi [19:04] porthose_ ? [19:19] fabrice_sp: is it true, that new packages in Debian will sync automatically into lucid until end of DebianImportFreeze? [19:19] no new versions, but new packages [19:39] yes [19:40] *gone [20:43] ScottK: Here? [20:43] StevenK: Yes. [20:44] ScottK: Is it worthwhile autosyncing boost1.39 from Debian? [20:44] no [20:44] StevenK: We can't sync boost due to Python differences and we'd drop it anyway. I'd say no. [20:45] Okay, I'll kick it from the current run. Shall I blacklist it too? [20:45] boost1.40 is being fixed in debian to sort similar python issues so might be syncable in the near future [20:46] Well, when I say blacklist I mean boost1.39 [20:46] I think 1.39 will disappear soon enough, but I think there are apps that may still need fixed to work with a newer version, sadly [20:47] Meh, blacklisting is cheap [20:47] there's a removal request for boost1.39 in debian, so probably blacklist for now [20:53] Heh, right [20:53] * ajmitch wishes the BTS would hurry up & show me the bug [20:53] No bug for you [20:53] :( [20:53] and there it goes [20:54] just looking up http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556924 for your viewing pleasure [20:54] Debian bug 556924 in boost1.40 "boost1.40: FTBFS without Python 2.4" [Important,Open] === Zhenech_ is now known as Zhenech [20:59] fabrice_sp, I left a comment on bug #484678. Please have a look when you have time. ty :) [20:59] Launchpad bug 484678 in ampache-themes "Sync ampache-themes 3.4.3-1 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/484678 [21:16] porthose_, I saw.. But isn't it worth syncing now, to get autosync after? [21:16] thanks for your comment, by the way [21:17] some archive admin: what about bug 483813? [21:17] Launchpad bug 483813 in schroot "Sync schroot 1.3.1-1 (universe) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/483813 [21:18] experimental is allowed? [21:18] allowed, but some explanation is usually appreciated I think [21:18] I don't know where the current schroot is from (and I'm not an archive admin) :) [21:18] testing, IIRC [21:19] !info schroot | karmic [21:19] karmic: schroot (source: schroot): Execute commands in a chroot environment. In component universe, is optional. Version 1.2.3-1 (karmic), package size 685 kB, installed size 1948 kB === davroman1ak is now known as davromaniak [21:25] fabrice_sp: Syncing from experimental particularly needs justification for Lucid since we are by default taking from Testing and not Unstable. [21:25] ScottK, ok. I'll request justifications in the sync request then. Thanks! [21:28] Hi all, I'm trying to make a package, but I'm having trouble with the debuild stage - it's failing with "secret key not available". I've set my key in devscripts.conf so I'm rather lost.... [21:29] etaliverto, this error does not prevent your pacakge to be built [21:29] Any pointers for troubleshooting would be much appreciated. I'm new to this, been following the wiki but I've ended up with four keys in my secring.gpg so I'm not sure I did everything right. [21:31] •fabrice_sp• Thanks - can I upload it to REVU unsigned though? I was trying to update an existing package for a bug report. [21:31] etaliverto, use -k flag [21:31] ohh. For REVU, it has to be signed [21:32] •av`• OK, thanks, I'll try with the flag.... [21:32] etaliverto, use -kKEYID [21:33] etaliverto, also, what is your changelog entry? [21:35] I made the changelog with dch -i, it gives my name and email address on the last line - they're the same ones as used when I made the GPG key === hggdh_ is now known as hggdh [21:36] •av`• It works with the -k flag, thanks! [21:36] etaliverto, np ;) [21:36] Any idea why it doesn't work through debuild though? [22:32] jdong: motu sru? Bug #369818 [22:32] Launchpad bug 369818 in gnome-commander "Incorrect sorting by size in panel" [Undecided,Fix released] https://launchpad.net/bugs/369818 [23:06] hi, I've created a needs-packaging bug, assigned it myself, but how do I "upload it to revu" [23:12] if the only ubuntu diff is "add lpia to supported archs", is it worth doing the merge, or can I sync? [23:12] lpia is going away for lucid, right? [23:13] lucas: Sync! [23:13] thanks [23:17] ah boo, gotta upload to revu from my linux box === yofel_ is now known as yofel