[00:01] <Riddell> maybe or maybe not, depends on the thoroughness of the other archive admins
[00:01] <ajmitch> or depending on how annoying our nagging is :)
[00:19] <porthose> Riddell, not sure what you mean?
[00:21] <Riddell> porthose: all sorted, please ignore :)
[00:21] <Riddell> siretart: can you ack bug 590219 ?
[00:21] <ubottu> Launchpad bug 590219 in ffmpeg-extra (Ubuntu) "Remove libavutil-extra-49 from maverick (multiverse)" [Undecided,New] https://launchpad.net/bugs/590219
[00:21] <porthose> Riddell, k :)
[00:24] <lfaraone> If I'm writing a guide for people new to Debian/Ubuntu packaging to teach them how to package a specific type of software that has well-defined ways for operating and being distrubited, would it be acceptable to provide a skeleton akin to what dh_make produces but customized for this class of software?
[00:25] <james_w> could you teach dh_make how to do the right thing for that class?
[00:26] <lfaraone> james_w: Possibly. Ideally, I'm trying to make a solution that is akin to "just add water!" (source, description, copyright)
[00:26] <lfaraone> james_w: it's using CDBS, so it might be rejected as duplication of the existing cdbs option, no?
[00:27] <james_w> possibly, I don't know
[00:27] <james_w> depends whether it's something like python, or like "sugar app" I guess?
[00:27] <james_w> python module I mean
[00:27] <lfaraone> james_w: sugar app.
[00:27] <james_w> I don't know if there is a useful distinction, but there may be one to the dh_make maintainer
[00:27] <james_w> you could ask
[00:28] <james_w> always better to just have the tool do the right thing IMO
[00:30] <ajmitch> there are a few separate tools around that do that
[00:30] <lfaraone> hmmm. dh_make supports templates. this may be the way to go.
[00:30] <lfaraone> *user supplied.
[00:30] <lfaraone> ajmitch: like waht?
[00:31] <ajmitch> like dh-make-php, or similar stuff for CPAN modules
[00:32] <ajmitch> (which is dh-make-perl)
[00:32] <ajmitch> I'm not sure if you want to go down that path
[00:32] <lfaraone> ajmitch: I'd like to implement the simplist solution possible, but nothing simpler.
[01:29] <Ddorda> hey, i'm looking for an unpackaged program so i can gain experience. is there a list or something?
[01:30] <ScottK> Ddorda: If you want to gain experience with packaging, fixing bugs and packaging patches is a much better way to do it.
[01:32] <Ddorda> ScottK: i want to learn how to package a program from zero, i guess that method won't fit for now, but after i'll know more i believe that this is what i'll do
[01:33] <ScottK> Ddorda: Look for bugs tagged 'needs-packaging' in Launchpad.
[01:33] <Ddorda> ScottK: oh! thanks! that's i was looking for :)
[02:54] <artfwo> Hi! Would anyone care to sponsor bug 591528 (main)?
[02:54] <ubottu> Launchpad bug 591528 in libraw1394 (Ubuntu) "FTBFS on all architectures (Maverick)" [Undecided,Confirmed] https://launchpad.net/bugs/591528
[02:55] <micahg> artfwo: you might have better luck in #ubuntu-devel
[02:55] <micahg> artfwo: since it's in main
[02:55] <artfwo> okay, will try there
[03:11] <ajmitch> artfwo: so it doesn't try & connect to www.oasis-open.org anymore with your patch?
[03:11] <artfwo> nope
[03:11] <artfwo> ajmitch, when docbook-xml is installed in the system, docbook-utils no longer try to look for it online
[03:13] <ajmitch> useful
[03:13] <ajmitch> I'll upload it once I've built it then
[03:14] <artfwo> ajmitch, okay, thanks
=== nhandler_ is now known as nhandler
=== nobawk|away is now known as nobawk
=== nobawk is now known as nobawk|away
[04:52] <siretart> Riddell: AFAIUI, it is a standard NBS job. so in short: yes
=== lifeless_ is now known as lifeless
[06:27] <raywang> TheMuso, hi
[06:29] <raywang> TheMuso, hi, let's talk about it here.
[06:29] <TheMuso> raywang: ok sure.]
[06:30] <raywang> TheMuso, ok, thank you for taking your time to review packages. 0.3.2 seems have some bugs, and I plan to have you sponsor 0.3.1 instead, what do you think?
[06:31] <TheMuso> raywang: Sure, these pacakges won't be going into the Ubuntu archive proper. They will go into the accessibility-dev PPA, and possibly into vinux if the vinux devs want them.
[06:31] <TheMuso> raywang: At-spi2 will only be considered if its stable enough for every day use, which it seems it is not, so for maverick, we are sticking with at-spi v1.
[06:31] <raywang> TheMuso, that's good
[06:32] <raywang> TheMuso, alright, that makes sense, but at least there is somewhere that holds new at-spi2 for the people who wants them. :)
[06:32] <TheMuso> raywang: Agreed.
[06:33] <raywang> TheMuso, and do you have some time to write me an Testimonials, I'm applying ubuntu member, and I need your help if you would like to do it. :)
[06:33] <raywang> TheMuso, https://wiki.ubuntu.com/RayWang
[06:33] <TheMuso> raywang: Unfortunately I haven't see much of what you have been doing in the community, so I am not sure I am in a position to comment.
[06:34] <raywang> TheMuso, yeah, I see, anyway, thanks all the same. :)
[06:34] <TheMuso> raywang: np
[06:38] <lifeless> TheMuso: you can comment on the contributions you're seeing, and development is a contribution
[06:39] <lifeless> TheMuso: there is the contributing developer concept now :)
[06:39] <TheMuso> lifeless: I haven't seen anything yet, thats my point.
[06:40] <lifeless> ah kk
[07:56] <dholbach> good morning
[08:04] <abogani2> to you
=== Amto`Off is now known as Amto_res
[10:48] <ari-tczew> dholbach: I wrote: Ubuntu package has forwarded -> as all package was uploaded in Debian and Debian has released a more revisions than Ubuntu
[10:48] <dholbach> ari-tczew: I'm not sure I understand
[10:49] <ari-tczew> dholbach: it's visible in Debian's changelog
[10:49] <dholbach> ari-tczew: Ubuntu introduced changes that were already upstream
[10:49] <dholbach> ari-tczew: like in upstream upstream
[10:50] <dholbach> ari-tczew: debian packaged new upstream tarballs separately (and only one of the security issues in mentioned in the debian changelog)
[10:50] <dholbach> ari-tczew: as you can see from the debian bug tracker, nothing was ever forwarded from ubuntu to debian
[10:51] <ari-tczew> dholbach: you don't understand me. I mean _package has forwarded_ so Debian earlier doesn't got this package, but Ubuntu yes. Then later maintainer drag package from Ubuntu, adjust for Debian and pack in Debian newer upstream releases, but not in Ubuntu
[10:52] <dholbach> ari-tczew: I don't think that's what happened
[10:53] <dholbach> in Ubuntu: chef (0.7.10-0ubuntu1.1) karmic-security; urgency=low Mon, 28 Dec 2009 18:21:07 -0800
[10:53] <dholbach> in Debian: chef (0.7.14-3) unstable; urgency=low Wed, 04 Nov 2009 16:33:44 -0700
[10:53] <dholbach> (so even before the fix landed in Ubuntu, there were a couple of new upstream releases in Debian already)
[10:54] <dholbach> in general it was OK to sync the package, but the analysis wasn't quite right
[10:59] <ari-tczew> dholbach: and what next?
[10:59] <dholbach> ari-tczew: I ACKed the sync
[11:00] <dholbach> ari-tczew: as I said: it was OK to sync, I just had a question about the explanation in the bug
[11:03] <ari-tczew> dholbach: as you see, my syncs almost always are good :P
=== raywang is now known as rawang
[11:33] <directhex> isn't chef tollef's?
[11:34] <directhex> hm, no.
[11:35] <directhex> oh, he's hacking upstream
=== zMoo is now known as zMoo_lol
=== zMoo_lol is now known as muiriel
[13:23] <sim> Hi
[13:24] <ari-tczew> hi sim
[13:24] <sim> How to restrict kernel package (ppa) build to a single architecture ?
[13:25] <sim> Actually I am only interested in building the amd64 kernel package
[13:25] <sim> Moreover I'd like avoiding Makefile mutilations :)
[13:26] <ari-tczew> sim: why do you neeed to disable build on other architectures ?
[13:26] <sim> ari-tczew: I want build a kernel package which provide support for a x86_64 board
[13:27] <sim> ari-tczew: so a x86 build will not be different from the generic version
[13:27] <sim> ari-tczew: just it will use some extra space...
[13:27] <abogani2> sim: debian.master/rules.d/* debian.master/control.d/*
[13:28] <ari-tczew> sim:  I dunno
[13:29] <sim> I am really sad to have to do that :(
[13:30] <sim> I will have to merge some specific ppa modifications with the next kernel package releases
[13:31] <sim> A way to select the build target from the launchpad platform would be a real improvement
=== muiriel is now known as zMoo
[13:55]  * abogani2 waves
[13:55] <abogani2> Anyone could procede with sync for this package: https://bugs.launchpad.net/ubuntu/+source/rxtx/+bug/591682
[13:55] <ubottu> Ubuntu bug 591682 in rxtx (Ubuntu) "Sync rxtx 2.2pre2-1 (universe) from Debian sid (main)" [Wishlist,New]
[14:03] <BlackZ> abogani2: if you have subscribed ubuntu-sponsors it's OK
[14:04] <ari-tczew> cody-somerville: you can take merge xchat. I'm busy until 18th June
[14:06] <ari-tczew> abogani2: why you ask about this sync? you are not a requester
[14:07] <ari-tczew> cody-somerville: bug for xchat is bug 591714
[14:07] <ubottu> Launchpad bug 591714 in xchat (Ubuntu) "Merge xchat 2.8.6-6 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/591714
[14:08] <abogani2> ari-tczew: Because last change (-ubuntu1) is mine.
[14:08] <ari-tczew> aha ok
[14:08] <BlackZ> cody-somerville, ari-tczew: I can proceed with the merge if for you is OK
[14:09] <ari-tczew> BlackZ: so let's go. cody-somerville give me a free hand to take this one so you can take this merge instead me
[14:10] <ari-tczew> I'm going to gym, see you later
=== txwikinger2 is now known as txwikinger
[14:37] <gnomefreak> tseliot: is X safe to upgrade now? it has held back packages and it wants to remove some key X packages, at least i think they are key packages
[14:38] <tseliot> gnomefreak: upgrade to what? Lucid?
[14:39] <gnomefreak> tseliot: no in Maverick but its not a Lucid->Maverick it is a full Maverick and it just started yesterday i think
[14:39] <gnomefreak> well it was a Lucid tot Maverick upgrade was a few weeks ago
[14:40] <gnomefreak> s/tot/not
[14:40] <tseliot> "not" or "to"?
[14:41] <gnomefreak> to sorry
[14:41] <tseliot> you might want to ask RAOF if the xserver ABI was bumped. If so, maybe we need to rebuild the nvidia driver
[14:44] <gnomefreak> tseliot: the nvidia drivers dont work for me at all. I installed the drivers from Nvidia. jockey only offered me the 96,173,nvidia-current but i should be offered 185. but either way none of the 3 offered work
[14:45] <tseliot> gnomefreak: "don't work"? No logs?
[14:45] <gnomefreak> i guess he is afk
[14:45] <gnomefreak> tseliot: dropped to low graphics
[14:45] <tseliot> gnomefreak: you can collect the logs from low graphics mode
[14:46] <tseliot> please, do that, then we'll speak again
[14:46] <gnomefreak> tseliot: ok im lookgin atm
=== alessio is now known as `Alessio`
=== `Alessio` is now known as quadrispro
[15:02] <gnomefreak> this is taking forever to upload to bug report
[15:02]  * gnomefreak goes for smoke while it does its thing
[15:11] <gnomefreak> tseliot: i updated the bug i filed (sorry forgot the bug) here it is. bug 590571
[15:11] <ubottu> Launchpad bug 590571 in xserver-xorg-video-nouveau (Ubuntu) "The monitor turns off after kernel selection in Maverick" [Undecided,Incomplete] https://launchpad.net/bugs/590571
=== jtechidna is now known as JontheEchidna
[15:50] <sim> Finally, I have proceded like this: http://pastebin.org/321552
[15:51] <sim> That's quite dirty... but enough good for me
=== jtechidna is now known as JontheEchidna
[16:16] <micahg> if a binary pkg is removed from one source and moved to another w/out a binary, should a bug for a transitional package be in the binary remove request for archive or a separate bug?>
[16:56] <micahg> if a binary pkg is removed from one source and moved to another w/out a binary, should a bug for a transitional package be in the binary remove request for archive or a separate bug?>
[16:56] <ScottK> micahg: I'm not sure I understand the question.
[16:57] <micahg> ScottK: bug 591758
[16:57] <ubottu> Launchpad bug 591758 in tct (Ubuntu) "please remove 'timeout' from Maverick" [Undecided,New] https://launchpad.net/bugs/591758
[16:57] <micahg> ScottK: it seems like we need a transitional package as well
[16:57] <ScottK> Looking
[16:59] <geser> for builds the transitional package is not needed and for upgrades in this case neither (who doesn't have coreutils installed)
[17:00] <micahg> geser: he's concerned about FTBFS due to the transition
[17:02] <ScottK> micahg: Is timeout still a separate binary or is it now embedded in an already existing binary package?
[17:04] <geser> timeout is part of "coreutils" now
[17:05] <geser> micahg: it looks like only chromium-browser build-depends on timeout, so it shouldn't be an problem to fix this one package (drop the build-dependency)
[17:05] <micahg> geser: k, he's working on that, ok, good to know there's no other issue
[17:06] <ScottK> micahg: I agree with what geser said.  If it had been a lot of packages, then it might have been useful to have coreutils "Provide: timeout" as a transitional measure, although since versioned provides are supported, that kind of approach is not always completely satisfactory.
[17:07] <micahg> ScottK: k, thanks
[17:09] <geser> micahg: a versioned build-dependency on "coreutils >= 8.0 | timeout" might be in order to make sure a timeout binary is available (or fix the coreutils FTBFS)
[17:09] <micahg> geser: for chromium?
[17:09] <geser> yes
[17:11] <geser> coreutils FTBFS on e.g. armel, and the currently available version doesn't have timeout yet, so on armel the timeout package is still needed until the coreutils FTBFS is fixed
=== yofel_ is now known as yofel
[17:43] <BlackZ> cody-somerville: the xchat merge from the latest debian unstable version is ready, please see bug #591714
[17:43] <ubottu> Launchpad bug 591714 in xchat (Ubuntu) "Merge xchat 2.8.6-6 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/591714
[17:51] <xteejx> Hey guys, bug 588301 in lincity-ng/libphysfs...had a look thru the source and version 2.0.0-2 had a symlink added as a patch I think, but it has since been removed
[17:51] <ubottu> Launchpad bug 588301 in libphysfs (Ubuntu) "Can't start lincity-ng because libphysfs-1.0.so.0 doesn't exist" [Medium,Triaged] https://launchpad.net/bugs/588301
=== bulldog is now known as bulldog98
[18:53] <xteejx> Can someone check my debdiff on bug 591847, I think it's ok, also is there any chance this can be done, and am I right in subscribing the Review team?
[18:53] <ubottu> Launchpad bug 591847 in a7xpg (Ubuntu) "push button to start message in a7xpg is ambiguous" [Wishlist,New] https://launchpad.net/bugs/591847
[18:58] <BlackZ> xteejx: have you did a patch?
[18:59] <xteejx> BlackZ: A debdiff you mean? Yes. Unless you mean a patch to fix the 'problem', then yes I did that too with quilt
[18:59] <xteejx> Took a bit of messing around to learn it, but done :)
[19:00] <BlackZ> xteejx: so if you did a patch attach it too
[19:01] <xteejx> BlackZ: Ok, is that the case even though it's in the debdiff?
[19:01] <BlackZ> and in the changelog entry, start_game_string.patch (LP: #591847) would be enough
[19:01] <BlackZ> (with the description)
[19:01] <BlackZ> xteejx: I'd attach debdiff + patch
[19:01] <xteejx> That is what I have in the changelog... the patch name, close LP bug and description
[19:02] <BlackZ> xteejx: but if you have did the patch you have to include it in the bg
[19:02] <BlackZ> s/bg/bug
[19:02] <xteejx> huh?
[19:02] <xteejx> I re-read it :) Yeah I made the patch, so I'll attach it then :)
[19:03] <BlackZ> xteejx: and fix the changelog
[19:03] <BlackZ> xteejx: * debian/patches/start_game_string.patch: Changes ambiguous "push button to start" to "push CTRL to start" (LP: #591847) would be enough
[19:04] <xteejx> BlackZ: Oh you mean the LP description put it into the changelog?>
[19:04] <BlackZ> xteejx: the debian/changelog file, it should be as I suggested you
[19:04] <xteejx> BlackZ: Ok, I think I understand :) thanks BlackZ
[19:09] <BlackZ> xteejx: also, you have to include the patches in a file tipically called 00list or series in the debian/patches directory
[19:09] <BlackZ> (if it doesn't exist, create it)
[19:09] <xteejx> BlackZ: I updated the series file to include my patch so that it would be applied during build
[19:10] <BlackZ> xteejx: but without the .patch extension
[19:10] <BlackZ> you have to add them without the extension
[19:11] <xteejx> All the rest have extensions in the series file
[19:11] <xteejx> .patch, .diff
[19:12] <xteejx> hence the reason I did the same :S
[19:13] <BlackZ> xteejx: hmmm, so let it
[19:13] <BlackZ> BTW it's not an error!
[19:13] <xteejx> so generally drop the extensions?
[19:14] <BlackZ> xteejx: I'd drop it but that's not required, the patch will work BTW
[19:14] <xteejx> BlackZ: Ok, I'll leave it then to make it look more uniform with the rest, makes sense I suppose :)
[19:15] <BlackZ> xteejx: if they have, let it
[19:15] <xteejx> Ok :)
[19:15] <xteejx> Thanks BlackZ
=== asac_ is now known as asac
=== Philip6 is now known as Philip5
[20:06] <tonyyarusso> All right, I could use a bit of packaging help if there's anyone around.
[20:07] <geser> what kind of problem do you have?
[20:07] <tonyyarusso> First item of business:  I thought I'd try making a get-orig-source rule.  Upstream doesn't currently version the tarball, nor use a clear name, so it comes as linux-nrpe-agent.tar.gz.  I need that to be something more along the lines of nagios-xi-agent-0.1.orig.tar.gz.
[20:08] <tonyyarusso> Obviously just a mv would change the name of the tarball, but what about the folder it would unpack?  Wouldn't changing the name of that mess up the MD5?
[20:09] <geser> the folder name doesn't matter to which in unpacks as long as it's one folder
[20:11] <tonyyarusso> oh, all righty then
[20:12] <tonyyarusso> Next up:  I'm attempting to do this with debhelper (although I'm not sure if I really need to...), but I don't really understand what all of the different parts do and which ones I actually need.
[20:13] <tonyyarusso> My package is platform independent.  All it does is a) pull in some dependencies, b) copy some perl & shell scripts to a directory created by one of those dependencies, and c) add some config options in /etc and restart a service.
[20:15] <tonyyarusso> geser: Do I need anything at all other than dh_install?
[20:23] <geser> only the common ones
[20:25] <tonyyarusso> such as?  testdir, testroot, clean ?
[21:16] <dupondje> Where can I see packages that arent accepted yet ?
[21:17] <dupondje> xserver-xorg-input-mouse shows newer version then there is in the archive :s
[21:21] <micahg> dupondje: which version?
[21:21] <micahg> (ubuntu)
[21:22] <dupondje> maverick ..
[21:23] <micahg> dupondje: https://edge.launchpad.net/ubuntu/maverick/+queue
[21:23] <dupondje> its not there :P
[21:24] <micahg> dupondje: maybe your mirror?
[21:24] <dupondje> archive.ubuntu.com ... guess its up-to-date :P
[21:24] <micahg> dupondje: amd64 not built yet?
[21:25] <dupondje> https://launchpad.net/ubuntu/+source/xserver-xorg-input-mouse
[21:26] <dupondje> xserver-xorg-input-mouse (1:1.5.0-2)
[21:26] <dupondje> aptitude show gives me: Versie: 1:1.5.0-1
[21:27] <micahg> dupondje: are you on amd64?
[21:27] <dupondje> ye
[21:28] <micahg> hmmm
[21:28] <micahg> should be published now
[21:28] <dupondje> tought also :) its weird
=== giskard_ is now known as giskard
[21:53] <tonyyarusso> What does the .PHONY rules target do?
[21:54] <dutchie> tonyyarusso: it tells make that those rules don't correspond to making an actual file
[21:54] <dutchie> tonyyarusso: i'd recommend reading the documentation for make :)
[22:01] <tonyyarusso> joy
[22:49] <ajmitch> funkyHat: uploaded your mpd merge, sorry for the delay :)
[22:50] <funkyHat> ajmitch: no worries ⢁). Thanks ⡈)
[22:53] <imbrandon> afternoon all
[22:53] <ajmitch> hi imbrandon
[22:54] <imbrandon> heya ajmitch
[23:13] <imbrandon> so if i bind mount /usr in /etc/fstab will it mount early enough not to cause normal boot issues ?
[23:15] <tonyyarusso> Can I use a get-orig-source rule in such a way as to not even have a source in my directory to begin with?  (ie I have debian/ and nothing else, and the rule should download the rest)
[23:16] <tonyyarusso> If yes I must be confused about how to reference it, because debuild succeeds but pbuilder fails, with a "can not stat file" error later in rules.
[23:21] <ari-tczew> why developers write in debian/changelog only "Resync on Debian" without any informations?
[23:22] <ari-tczew> I saw it in packages uploaded by doko and seb128
[23:23] <sebner> ari-tczew: because they are lazy
[23:24] <ari-tczew> maybe I'll request syncs without explanation?
[23:24] <ajmitch> sure, they'll probably get closed without explanation then
[23:25] <kklimonda> ari-tczew: some packages are too big, too important and maintained only by the handful of developers who are in touch with each other so it's not a problem in these cases and it's much faster to just write * Resync with Debian then to point every delta we still carry over.
[23:26] <ari-tczew> if anyone require abidance, let's require from himself
[23:26] <ari-tczew> s/abidance/rules=policy
[23:27] <ari-tczew> kklimonda: I see that you're not a developer (only PPU for 1 package) and you have answers for all question. congratulations!
[23:28] <ajmitch> ari-tczew: check again, he is in ~ubuntu-dev
[23:28] <ari-tczew> ajmitch: ^^ only PPU for 1 package
[23:29] <ajmitch> so please hold back on the sarcastic responses as well
[23:29] <tonyyarusso> Could someone show me a good example of get-orig-source usage?
[23:30] <ajmitch> tonyyarusso: I don't believe it's meant to be used at build-time, if that's what you're trying to do
[23:30] <ari-tczew> please don't be too much sensitive, I love these such discussions
[23:31] <tonyyarusso> ajmitch: oh.  It's just to save you the trouble of fetching it?
[23:31] <ajmitch> tonyyarusso: yes, from what I've seen of how's it's generally used
[23:32] <tonyyarusso> hrm, ok
[23:33]  * tonyyarusso still has no idea what he's doing, but is getting closer, kinda
[23:39] <kklimonda> ari-tczew: the number of packages I have upload rights too doesn't have much to do with my observation skills nor with my knowledge about the project or policies. If you have asked your question in hope that there is a written policy "canonicaly employees/ubuntu-cure-dev members are allowed not to write as detailed changelog entries as everybody else" then you should rephrase your question and I
[23:39] <kklimonda> would not answer it like that. But your question is an open one so I've decided to answer it to the best of my knowledge.
[23:46] <ari-tczew> kklimonda: in the start I'd like to say that I'm not happy in answer by other language instead our native. I don't attack nobody, but only I said: if anyone require rules, he should require starting from himself.
[23:48] <ari-tczew> I've observed that only from me developers are require some special things and they don't respect me and my work.