[00:00] <persia> sebner: Well, main sponsors are always hard to find.
[00:00] <persia> You just need to make sure to give enough slack.
[00:00] <directhex> persia, (or warning)
[00:00] <highvoltage> *bong*
[00:01] <sebner> persia: I really have high hopes on the archive-reorg. or at least thinking about becoming generalist developer
[00:01]  * persia grumbles about permissions irregularities.
[00:01] <sebner> Aye
[00:02] <highvoltage> I think archive reorg is definitely making things easier for kubuntu, xubuntu and edubuntu and similar teams
[00:02] <persia> Could someone who isn't stuck in an approval queue please change the topic to reflect FeatureFreeze?
[00:02] <sebner> persia: nahh!" As long as the topic isn't changed we are free to upload :P
[00:02] <directhex> could someone with power over nature turn back time a few hours plz?
[00:02] <sebner> *pssssssssst*
[00:02] <persia> highvoltage: Yeah, but I'm complaining about suddenly discovering that I'm not an op in here.
[00:03] <geser> this seems to have changed with the move of freenode to an other ircd
[00:04] <ajmitch> sebner: sorry I can't sponsor, I killed my lucid box :)
[00:04] <RAOF> directhex: Just move London a few thousand miles west!
[00:04] <geser> ajmitch: perfect timing
[00:04] <sebner> grrrrrrrrr
[00:04] <ajmitch> geser: isn't it?
[00:04]  * sebner waves at geser (my core-dev friend)
[00:04]  * ajmitch managed to crack the screen on the laptop
[00:04] <RAOF> Owch.
[00:04] <sebner> geser: mind sponsoring? /me sees no FF in effect
[00:05] <ajmitch> RAOF: an expensive ouch, too
[00:05] <geser> sebner: like persia I'm only an indirect core-dev through DMB
[00:05] <sebner> * persia grumbles about permissions irregularities.
[00:05]  * sebner too
[00:05] <sebner> geser: + apply!
[00:06] <persia> sebner: You've done developer applications : it takes a while to get it ready.
[00:06] <ajmitch> I don't think he can become core-dev within the next few minutes
[00:06] <sebner> persia: not for geser ;-P
[00:07] <persia> ajmitch: Requires past time, actually.  0:00 UTC was the theoretical cut-off.
[00:07] <ajmitch> persia: theory & practice don't always coincide
[00:07]  * sebner doesn't see the topic changed
[00:08] <ajmitch> especially around release milestones :)
[00:08] <persia> true :)
[00:09]  * sebner proposes to make the FF on the last time period of 18th
[00:09] <sebner> Means in 23 hours and 50 minutes
[00:11] <persia> sebner: Erm, no.
[00:11]  * sebner calls it a day and says gn8
[00:11] <sebner> persia: you are killing the fun :P
[00:11] <persia> sebner: end of 18th worldwide isn't for about 38 hours.
[00:11] <ajmitch> 38 hours till FF? excellent
[00:12] <persia> Um, someone ought run that past slangasek :)
[00:12] <ajmitch> I'll take your word for it :)
[00:12] <persia> I really do remember a statement that freezes applied at 0:00 UTC
[00:12] <persia> (but I'd be delighted to be wrong about that)
[00:12] <ajmitch> it's usually been the case
[00:12] <persia> Well, at least since slangasek has been around.  Way back when we used to push it :)
[00:12] <slangasek> in practice I don't expect to get the mail out until AM Europe time
[00:13] <slangasek> so you have a grace period :P
[00:13] <persia> slangasek: But is that grace period a result of policy, or your workload?
[00:13] <slangasek> the latter
[00:13] <persia> so, we probably shouldn't press on with a REVU sprint, syncfest, and merging madness?
[00:13]  * lifeless queues up a bunch of upstream releases for post FF, to test the FFe pocess.
[00:14] <slangasek> heh
[00:14] <slangasek> persia: I leave it to the deveolpers' discretion ;)
[00:14] <persia> Actually, testing the new FFe process will be interesting.  This will be the first time we have an integrated release team.
[00:14] <ajmitch> I'm guessing the 4 people in ~ubuntu-release will be getting a lot of mail in the next few days then
[00:15] <persia> There's supposed to be some more members added to help with that.
[00:15] <ajmitch> will it still be approval from any 2?
[00:15] <persia> I wouldn't expect a policy change, but I could be mistaken
[00:16]  * persia tends to avoid release coordination stuff
[00:17] <ScottK> persia: While new day UTC may be a goal, I don't think FF happens until the release manager says it does.
[00:17]  * ScottK thinks you are free to press on.
[00:19] <highvoltage> well, release manager did say it's at the discretion of the developer. I guess that's a nice way to say "please don't *totally* abuse it"
[00:24] <slangasek> ajmitch: well, the freeze policy for main has always had a quorum of 1
[00:24] <ajmitch> universe has tended to be 2 for some reason
[00:25] <persia> Mostly because we don't really trust anyone.
[00:25] <persia> Moving to 1 makes sense.
[00:25] <crimsun> wasn't that from the first MC?
[00:25] <crimsun> seems kinda outdated given main's practice
[00:25] <persia> Was it even an MC thing?  I thought we decided at a MOTU meeting.
[00:26] <ajmitch> doesn't really matter, nor should it take much to change
[00:26] <persia> Doesn't take more than an email from the release team to change.
[00:26] <persia> We've delegated to a release team, and they get to make decisions.
[01:13] <PATX> can somebody help me decipher this: http://revu.ubuntuwire.com/revu1-incoming/fastpatx-1002180206/lintian
[01:13] <lifeless> looks like a url to me
[01:13] <PATX> debian-watch-file-in-native-package << its says no watch filed needed which, really is correct but i put one w/ comments in anyway
[01:14] <lifeless> why are you doing a native package
[01:14] <PATX> idk
[01:14] <lifeless> if its /possible/ to write a watch file, it shouldn't be a native package.
[01:14] <PATX> how do i not do one
[01:14] <lifeless> make sure you have the tarball it looks for present, and ensure there is at aleast one - in the version number
[01:15] <PATX> lifeless, fastpatx_6.0.1-1ubuntu1.tar.gz << thats in ../
[01:15] <lifeless> thats because its a native package
[01:16] <lifeless> do you know what I'm talking about, or are you guessing?
[01:16] <PATX> what are you talking about?
[01:17] <lifeless> https://wiki.ubuntu.com/PackagingGuide/Complete
[01:17] <PATX> dpkg-buildpackage -S -sa -rfakeroot -k<my key>
[01:17] <PATX> i did that to build i thought that did NOT make a native pkg
[01:17] <lifeless> https://wiki.ubuntu.com/PackagingGuide/Complete#Changing%20the%20Original%20Tarball
[01:17] <PATX> ok......
[01:17] <lifeless> the command you ran has nothing to do with native/non-native
[01:21] <PATX> lifeless, does it need to be a non-native to get into ubuntu
[01:21] <persia> If there is a separate upstream
[01:22] <PATX> ok
[01:23] <lifeless> PATX: generally nothing should be native.
[01:23] <lifeless> except things that are only developed in-ubuntu-for-ubuntu
[01:24] <PATX> ok
[01:24] <lifeless> arguably our dpkg etc packages should be non-native :)
[01:24] <PATX> ok
[01:24] <PATX> but now i am kinda confused...
[01:24] <PATX> fastpatx_6.0.1-1ubuntu1.orig.tar.gz
[01:24] <PATX> do i just need that?
[01:26] <persia> PATX: My best recommendation to get the right file is to create a working watch file, and add the correct changelog entry and call `uscan --force-download`.  This will automatically set the correct filename.
[01:26] <RAOF> It shouw be fastpatx_6.0.1.orig.tar.gz; the upstream code won't change with each package revision, so you just use the upstream version.
[01:26] <RAOF> Or, what persia said, which solves two problems in one.
[01:27] <PATX> ok
[01:28] <PATX> persia, my watch file does not get new version though... its just http://patx.me/paste/77751.html
[01:28] <PATX> is that bad (what it says is true)
[01:29] <Laibsch> RAOF: would you be willing to take another look at http://revu.ubuntuwire.com/p/ffgtk ?
[01:29] <Laibsch> porthose: Can you do the same? ^
[01:30] <persia> PATX: That's fine, but it means you can't have a working watch file.
[01:30] <PATX> yea i know
[01:30] <Laibsch> anybody other MOTU awake and willing to give to give me an endorsement for http://revu.ubuntuwire.com/p/ffgtk ?
[01:30] <persia> PATX: Now, write a get-orig-source rule for debian/rules that does the necessary screen-scraping to get the right upstream, etc, but then you have to name the file in the format RAOF suggested.
[01:30] <PATX> ok
[01:30] <persia> Laibsch: We're kinda sorta in feature freeze.  Why is this package so cool it needs to be in lucid?
[01:31] <Laibsch> persia: I know
[01:31] <Laibsch> and that's exactly the problem
[01:31] <Laibsch> Please take a look and see that I've been trying to get this package into Ubuntu since karmic
[01:31] <Laibsch> It's quite frustrating
[01:31] <Laibsch> I've put a lot of work into this package
[01:32] <Laibsch> and isdnutils which is a prerequisite
[01:32] <Laibsch> only to see things linger
[01:32] <Laibsch> Same thing I experienced with gjots2
[01:32] <Laibsch> it lingered so long that eventually my work went to waste
[01:32] <Laibsch> :-(
[01:32] <Laibsch> not a cool feeling
[01:33] <Laibsch> Ubuntu is supposed to be more agile than Debian, but my experience is the complete opposite
[01:33] <persia> I'm not at all certain we're more agile.
[01:33] <Laibsch> I usually have no problem getting stuff pushed into Debian, but Ubuntu is always a pain
[01:33] <persia> We generally recommend everyone put stuff in Debian (although we accept it)
[01:33] <Laibsch> people make you run around "you open a ticket in LP, people there tell you to upload to REVU, where the entry is closed and you're sent back to LP"
[01:34] <persia> Hrm?
[01:34] <Laibsch> persia: I make it a point to usually push to Debian although I don't use it
[01:34] <Laibsch> Shortly before the window closes for a new Ubuntu release, I ask for syncs, etc.
[01:34] <persia> If you're using Ubuntu, you're using Debian, plus a thin veneer of patches, and some plumbing changes.
[01:35] <Laibsch> During the last couple of days, of course, I try to push to Ubuntu directly
[01:35] <Laibsch> and my experience with the responses there is abyssmal and frustrating
[01:35] <Laibsch> persia: you know what I mean, I'm really frustrated and not in a mood to nitpick
[01:35] <persia> The last couple of days is precisely the worst time to try to push to Ubuntu.
[01:36] <Laibsch> I maintain 6-7 packages in Debian, I know the background
[01:36] <persia> Because that's when developers have the least time.
[01:36] <Laibsch> persia: Look at the references I gave you, please
[01:36] <Laibsch> I start about two weeks before
[01:36] <Laibsch> persia: let me give you the number of a bug ticket
[01:36] <persia> I just reviewed your package history on REVU.  The latest upload was 2 days before FF, fixing a heap of stuff you knew about since August.
[01:37] <Laibsch> persia: or better, instead of arguing, would you be so kind and do a review?
[01:37] <persia> But I'll look at it if you tell me why it's cool )
[01:37] <Laibsch> I can tell you about my frustrations in the meantime
[01:37] <Laibsch> ;-)
[01:37] <Laibsch> persia: do you live in .de?
[01:37] <Laibsch> Have you heard about FritzBoxes?
[01:37] <Laibsch> AVM?
[01:38] <maco2> he's in .jp
[01:38] <Laibsch> They have a large market share as all-in-one boxes
[01:38] <Laibsch> persia: You're in .jp?
[01:38] <Laibsch> We need to meet next time ;-)
[01:38] <Laibsch> You're not ??? Plessy, are you?
[01:38] <lifeless> no
[01:38] <Laibsch> was ist Charles?
[01:39] <Laibsch> I see
[01:39] <lifeless> check /whois
[01:39] <Laibsch> E.H.
[01:39] <Laibsch> ^^
[01:39] <Laibsch> done
[01:39] <Laibsch> ffgtk allows to control Fritz Boxes
[01:39] <Laibsch> and fax through them over the network
[01:39] <Laibsch> that is pretty cool
[01:40] <Laibsch> and currently not possible with any other solution
[01:40] <Laibsch> persia: convinced?
[01:40] <persia> Sure.
[01:40] <Laibsch> I'm sorry, it may not be anythning you may be able to use
[01:40]  * persia will look, but it needs two
[01:40] <Laibsch> I know
[01:40] <persia> Nope.  I can't use it, and I can't test it.
[01:40] <Laibsch> But it always needs a first
[01:40] <Laibsch> It's not completely functional yet
[01:41] <Laibsch> We also need the changes to isdnutils
[01:41] <Laibsch> the program itself is done
[01:41] <Laibsch> but it needs some changes in isdnutils to talk to the Fritzbox
[01:42] <Laibsch> persia: bug 420918 to see some of the run-around one can be given with 0 progress
[01:42] <PATX> I am just not quite getting the non-native
[01:43] <persia> PATX: You're packaging a shell script, right?  Have you read the wiki page about packaging without compilation?
[01:43] <Laibsch> persia: bug 406578 isn't much prettier
[01:43] <Laibsch> sorry, wrong bug number
[01:43] <Laibsch> bug 406574
[01:43] <persia> Laibsch: Complaining to me about these won't help much.
[01:43] <PATX> persia, i am packaging just one .py
[01:44] <Laibsch> I need to vent ;-)
[01:44] <persia> PATX: OK.  Did you read that wiki page?
[01:44] <PATX> the... https://wiki.ubuntu.com/PackagingGuide ?
[01:44] <PATX> if so yea
[01:45] <lifeless> Laibsch: please don't vent here; we try to have a productive channel, and venting is distruptive, even though I can understand the urge.
[01:45] <lifeless> persia: speaking of productive, do your randr needing packages in main build now?
[01:45] <lifeless> persia: can I chalk that up to 'done'
[01:46] <persia> PATX: No, https://wiki.ubuntu.com/MOTU/School/PackagingWithoutCompiling : that's a shortcut guide to accomplish what you are trying to do quickly.
[01:46] <PATX> ah OK thanks :)
[01:46] <persia> lifeless: I don't have packages in main :)
[01:46] <lifeless> persia: well, wherever they were failing
[01:46] <persia> lifeless: But I'll try to find the package that needed it, and rebuild.
[01:47] <persia> lifeless: But I'm 99% sure that you can call it  'done".
[01:47] <lifeless> persia: I'm a skeptic
[01:47] <Laibsch> lifeless: I think it may be important for MOTU to understand the frustrations of non-MOTU from time to time look at the links I gave and see I am being productive while I'm being given very unproductive runarounds
[01:48] <lifeless> its important to understand the problems and issues. Thats very different to venting.
[01:57] <PATX> persia, ok i think i am getting it... :) thanks... just one question do i need a debian/install (just never used one before when makeing .deb s for my lp ppa)
[01:57] <persia> PATX: Depends on whether you have a setup.py / Makefile / etc.
[01:58] <persia> I think it's easier to understand a debian/install file than hacking around in debian/rules
[02:01] <PATX> persia, i have a setup.py
[02:01] <persia> PATX: Then you don't need debian/install unless your setup.py is buggy :)
[02:02] <PATX> persia, ok :) and debian/compat (and pycompat) i have used before. but i do not see them on your page... do i not need these?
[02:04] <PATX> oh wait nvm
[02:04] <persia> PATX: debian/compat should appear on that page (somewhere - I should rewrite that page, or do another session in exchange for someone else rewriting it).  pycompat is important for python packages in some way I don't precisely understand: I have no idea if you need it for a single script.
[02:05] <PATX> ah
[02:05] <PATX> i see it (its burried)
[02:09] <ScottK> persia: pycompat is obsolete and not needed.  Thanks to a cdbs bug it's unfortunately common.
[02:11] <persia> ScottK: Thanks for the clarification.  Is the debian/control field still required, or only for modules?
[02:11] <PATX> ah ok :)
[02:14] <ScottK> persia: You mean XS/XB-Python-Version?
[02:14] <ScottK> Yes.
[02:15] <persia> For all packages, even just scripts?
[02:19] <RAOF> That's just for dh_pycentral, right?  My understanding of the Python policy was that you only needed to specify anything about python versions if there are versions of python that won't work (ie: it's an extension, or uses features from 2.4+, or ...)
[02:19] <PATX> persia, if i wanted to not use setup.py (ill use debian/install) it would still in install in usr/bin correct? not some python location?
[02:21] <persia> PATX: Depends what you put in debian/install :)  But it could.
[02:21] <PATX> i was just going to do "fastpatx usr/bin"
[02:22] <PATX> fastpatx being my package
[02:28] <paissad> guys, after running apt-get remove, i have some files i did not expected to be conffiles http://pastebin.com/f3d69c901
[02:28] <paissad>  ... actually i only expected /etc/PMS.conf & /etc/WEB.conf no to be removed
[02:28] <paissad> is it a new rule for Debian/Ubuntu policy not to remove files in /etc/default  & /etc/init.d & /etc/logroated/ ???
[02:30] <PATX> persia, http://revu.ubuntuwire.com/p/fastpatx
[02:31] <PATX> can u look at that? i think i got it?
[02:31] <PATX> but maybe you could tell me to do anything that might hold me up getting it passed...
[02:32] <persia> paissad: Everything in /etc/ gets marked as a conffile by default
[02:32] <persia> PATX: Maybe in a bit: I've been reviewing for the past 12 hours, and would prefer not to look at yet more right now :)
[02:33] <PATX> ok thanks a million if you get to it :)
[02:33] <paissad> persia, do i have to respect that policy ... or may i override the rule & remove some files in /etc/* ?
[02:34] <persia> paissad: I believe there's a way to mark a preferred subset of files as conffiles, so the rest automatically go away.  I don't know how to do it.
[02:35] <paissad> persia, if i create a debian/conffiles as said in Maintainer's Guide, i hope that only that files will be considered so
[02:35] <paissad> ^^
[02:35] <persia> paissad: Quite possibly.  Test it :
[02:35] <paissad> files mentionned in debian/conffiles i mean
[02:36] <paissad> persia, ok i will, thx
[02:38] <james_w> man dh_installdeb
[02:39] <persia> james_w: Thanks :)
[02:39]  * persia reads
[02:41] <persia> Ah, so it can't be overridden
[02:44] <james_w> it's not clear
[02:46] <ScottK> persia: Anything shipped in /etc is a conffile.  If you don't want something in /etc to be a conffile, then generate it in postinst.
[02:46] <persia> ScottK: Right.
[02:47] <persia> james_w: It's much more clear in the dh_installdeb source, which works as ScottK just described
[02:47]  * persia having read it due to the brevity of the manpage
[03:01] <SoftwareExplorer> I added a ppa in launchpad. I used the correct url/path on the command line but forgot to update ~/.dput.cf. I don't see the package in the ppa, but if I try it again (with an updated ~/.dput.cf) it says that it is already uploaded to launchpad. Am I just being to impatient?
[03:01] <lifeless> SoftwareExplorer: you're not understanding what dput does.
[03:01] <lifeless> SoftwareExplorer: dput writes a file when it uploads something.
[03:02] <lifeless> delete said file.
[03:02] <SoftwareExplorer> lifeless: Ok, thanks.
[03:03] <SoftwareExplorer> lifeless: It worked. :)
[03:03] <lifeless> feel free to file a bug saying 'the already uploaded message should print the file that it checked' or something - to make it more discoverable
[03:34] <paissad> persia, i have this warning " duplicate-conffile "if i create debian/conffiles
[03:35] <ScottK> paissad: Don't list anything shipped in /etc in debian/conffiles.  They are conffiles automatically (and unavoidably)
[03:35] <paissad> though,i guess i have to create a prerm script which removes /etc/logrotate/foo , /etc/default/foo /etc/init.d/foo !
[03:36] <paissad> ScottK, ok , i understand that now ... but i don't need all files in /etc to be conffiles  ^^
[03:36] <ScottK> But they are by policy
[03:37] <paissad> ScottK, By default, they are, but do you agree with that all files in /etc need to be conf files
[03:38] <ScottK> No.  They don't, but then don't ship them in the binary
[03:38] <paissad> ScottK, i will remove some of them from prerm script (remove or purge)
[03:39] <paissad> btw, what must i use ( prerm or postrm ?)
[03:46] <ScottK> postrm, IIRC
[03:49] <suji11> what is going on in my package http://revu.ubuntuwire.com/p/iok ?
[04:16] <rmunn> So now that feature freeze is over, what's the best thing a not-yet-MOTU can do to help improve Lucid?
[04:17] <fabrice_sp> rmunn, fix non installable pacakge and non buildable ones
[05:15] <suji11> what is going on in my package http://revu.ubuntuwire.com/p/iok ? whether it will come on lucid or not?
[05:19] <ajmitch> suji11: it was uploaded, it's in the queue for archive admins to check
[05:19] <suji11> ajmitch: ok
[05:28] <StevenK> suji11: Accepted.
[05:30] <suji11> StevenK: where could i check that?
[05:31] <StevenK> suji11: The queue where new stuff lands is https://edge.launchpad.net/ubuntu/lucid/+queue ; and iok is now at https://edge.launchpad.net/ubuntu/+source/iok
[05:33] <suji11> StevenK: Ok, Thank you:)
[05:40] <LLStarks> guys. shouldn't apt-get install deluge install deluged?
[05:40] <LLStarks> deluge 1.2 requires the daemon.
[05:41] <LLStarks> by default.
[05:45] <crimsun> StevenK: would you promote libffado (MIR bug #416778) and jack-audio-connection-kit (MIR bug #510481), please?
[05:57] <StevenK> crimsun: Done.
[05:58] <crimsun> StevenK: thanks!
[06:01] <SoftwareExplorer> So, I'm working on a package with a quilt patching system.  I added a patch, told quilt what files I would change, changed them, ran quilt refresh. Do I pop the patches before I run debuild?
[06:02] <LLStarks> bug #523622
[06:03] <nigelb> SoftwareExplorer: I believe yes.
[06:04] <SoftwareExplorer> nigelb: Hmm, Maybe I'm doing something wrong. When I pop the patches, debuild fails because it's trying to sign with someone else's key.
[06:05] <nigelb> SoftwareExplorer: did you "dch -i"?
[06:05] <nigelb> updated change log with your email yet?
[06:05] <SoftwareExplorer> nigelb: Yes.
[06:05] <SoftwareExplorer> nigelb: but of course, that's part of the new patch.
[06:06] <nigelb> okay, so the last entry in debian/changelog has your email ID and your key is set up?
[06:06] <nigelb> the signing with someone else's key failure happens when one of them is not done
[06:07] <SoftwareExplorer> nigelb: yes, as long as the latest patch is applied, but I thought debuild automatically work around that
[06:07] <fabrice_sp> arghhh: I ack'd a sync 2 hours ago, but we are in Feature Freeze now, right? (Topic is not up-to-date, it seems)
[06:08] <SoftwareExplorer> nigelb: (I got the impression I should pop the patches from the wiki, maybe that was wrong)
[06:08] <StevenK> It isn't Thursday where the release manager lives ....
[06:10] <fabrice_sp> oooh: cool
[06:16] <nigelb> SoftwareExplorer: appologies, lost power.  You still have issues?
[06:16] <fabrice_sp> a question about Bug 514292 .If it's a sync, how can I upload it? Adding a fake ubuntu entry?
[06:17] <SoftwareExplorer> nigelb: Um, well unless someone says I shouldn't, I'm leaning toward leaving the patches applied to run debuild
[06:17] <SoftwareExplorer> nigelb: otherwise debian/control will not have the correct email address
[06:17] <SoftwareExplorer> nigelb: *changelog
[06:18] <nigelb> SoftwareExplorer: wait, what does the patch do?
[06:18] <StevenK> SoftwareExplorer: They shouldn't be applied, the build should do that first
[06:18]  * fabrice_sp will upload it as build1
[06:19] <SoftwareExplorer> StevenK: Modifies 2 .c files, changelog, and I just realized it should modify control file to
[06:19] <nigelb> the patch shouldn
[06:19] <nigelb> the patch shouldn't be modifying changelog
[06:20] <StevenK> SoftwareExplorer: Exactly as nigelb says, you should not be modifying files under debian/ with quilt, you should just edit them straight
[06:20] <SoftwareExplorer> StevenK: Ahh, ok.
[06:21] <SoftwareExplorer> That's why it wasn't working
[06:21] <nigelb> quilt is only for the actual source code of the app.
[06:22] <SoftwareExplorer> nigelb: Ok, Thanks.
[06:22] <SoftwareExplorer> StevenK: Thanks.
[07:13] <suji11> StevenK: whats needed now so that I can see iok appearing in search at http://packages.ubuntu.com/
[07:14] <StevenK> I have no idea, I use Launchpad directly
[07:35] <eeexception> Hi, guys. I'm trying to make deb package of my qt project and have some troubles. I use this script to make deb http://code.google.com/p/yourownnewsmaker/source/browse/trunk/make-linux-release.sh,
[07:35] <eeexception> and this rules file http://code.google.com/p/yourownnewsmaker/source/browse/trunk/rules
[07:35] <eeexception> So during running it I have no errors except warning that I do not have pgp key, but as a result I get an empty deb packages with only these empty roots:
[07:35] <eeexception> /usr/bin; usr/sbin; /usr/share.
[07:35] <eeexception> By the way if I manually go to the builddir and run make install, Makefile script creates all needed files in right place.
[07:35] <eeexception> So I suppose that I have an error in section install: of rules file, but do not understand it at all. Could you help me to fix this problem?
[07:41] <SoftwareExplorer> I dput a source.changes to a ppa, but nothing seems to happen. I've given it a couple of hours and it doesn't even list anything a building. What could I be doing wrong?
[07:42] <eeexception> By the way I used this manual to create rules file http://wiki.maemo.org/Packaging_a_Qt_application
[07:45] <kklimonda> can I somehow build package that is using new source format on/for karmic?
[07:49] <SoftwareExplorer> Also, launchpad says "               Package counters and estimated archive size temporarily               unavailable.
[07:54] <SoftwareExplorer> I also tried disabling the ppa and reinabling it, but nothing happend
[08:03] <dholbach> good morning
[08:04] <eeexception> morning
[08:51] <suji11> dholbach:  good morning..
[08:56] <suji11> dholbach: My package iok was accepted, it is here https://edge.launchpad.net/ubuntu/+source/iok/1.3.9-0ubuntu1 in lauchpad , how could i get this from packages.ubuntu.com
[08:56] <dholbach> suji11: it might take some time
[08:56] <suji11> *packages.ubuntu.com
[08:56] <suji11> dholbach: ok
[08:57] <dholbach> ah
[08:57] <dholbach> it hasn't built on all architectures yet
[08:57] <dholbach> and while the source is in the archive already, the binary (.deb files) are still in a separate queue
[08:58] <suji11> dholbach: when i search iok here https://edge.launchpad.net/ubuntu/lucid it shows No packages matching 'iok' are published in Lucid.
[08:58] <dholbach> yes because of what I said above
[08:58] <dholbach> and I can't fix it
[08:58] <dholbach> Lucid:   amd64 (New)   armel   i386 (New)   ia64   powerpc (New)   sparc
[08:59] <dholbach> that's what (New) means there
[08:59] <suji11>  dholbach: ok, should i do anything for that?
[08:59] <dholbach> binary new = binary packages (=.deb files) are in a queue for the archive admins
[08:59] <dholbach> no
[08:59] <dholbach> the archive admins will get around to it
[09:00] <suji11> dholbach: ok, then i don't have to do anything now. am right?
[09:00] <dholbach> yes
[09:02] <suji11> dholbach: ok
[09:42] <stochastic> Can anyone with upload powers look at the patch for building xine against jack on Bug #152487 before feature freeze becomes solid?
[10:07] <hypera1r> you mean it's not solid yet?
[10:08] <directhex> hypera1r, it's still a little squishy, as long as people don't take the piss
[10:08] <hypera1r> heh
[10:08] <hypera1r> squishy eh
[10:08] <directhex> squishy!
[10:09] <hypera1r> stochastic: i think that patch is reversed.
[10:09] <oojah> I guess there are a lot of features to freeze, so it takes some time for them all to cool down.
[10:09] <sebner> hypera1r: do you got your cowpowers already?
[10:09] <stochastic> hypera1r, oops, I'll fix that up right now
[10:10] <hypera1r> sebner: er no.
[10:10] <hypera1r> sebner: not yet. =(
[10:10] <sebner> hypera1r: urgh!
[10:10] <hypera1r> sebner: bad time to become motu huh =p
[10:11] <hypera1r> stochastic: also, it seems like you chopped off the trailing \n in libxine1-misc-plugins.install
[10:11] <stochastic> I really didn't mean to.
[10:11] <stochastic> i.e. I don't know how that happened
[10:11] <hypera1r> stochastic: nevermind, just put it back =)
[10:12] <sebner> hypera1r: heh, I can remember .. some years ago the best time was after a release
[10:12] <hypera1r> sebner: why?
[10:13] <sebner> hypera1r: Before release is more dangerous, after release you can break anything you want
[10:13] <hypera1r> sebner: aah i see. heheh
[10:16] <stochastic> hypera1r, changes made.
[10:18] <hyperair> well, reading the patch, it looks good to me.
[10:19] <stochastic> can you upload it or do you not have the powers?
[10:20] <Laney> nobody pressed the buttons from the DMB yet?
[10:21] <sebner> hi Laney :)
[10:25] <Laney> hi hi
[10:35] <slytherin> do we have any special policy in regards with (against) FFE?
[10:38] <stochastic> Both Bug #360590  and Bug #152487 were awaiting a MIR approval that went through just 4hours ago.  They both have patches ready to be uploaded and if anyone is willing the entire Ubuntu Studio team would love for them to be uploaded.
[11:49] <paissad> hi all, i would like to add an interactive mode during the installation of my package to allow  choose a specific directory ( it's for a configuration file ) .... an example is ddclient configuration during installation for those who know it
[11:50] <slytherin> paissad: you need to use debconf
[11:51] <paissad> slytherin, ok thanks
[11:53] <Laney> is there a benefit to allowing this?
[12:04] <slytherin> Can any oython packaging experts take a look at python-scriptutil package from lucid and tell me why it would cause installation failure?
[12:14] <james_w> slytherin: is this a test?
[12:25] <PATX> can somebody review http://revu.ubuntuwire.com/p/fastpatx ?
[12:28] <slytherin> james_w: No. libmx4j-java is FTBFS because its build-dep javahelper fails to install because python-scriptutil fails to install.
[12:28] <james_w> slytherin: do you have a log or anything?
[12:29] <slytherin> just a sec
[12:29] <slytherin> james_w: https://launchpad.net/ubuntu/+source/libmx4j-java/3.0.2-8/+build/1484191/+files/buildlog_ubuntu-lucid-i386.libmx4j-java_3.0.2-8_FAILEDTOBUILD.txt.gz
[12:31] <hakaishi> Hi everyone! Anyone up to advocate/review qt-shutdown-p? - I've replaced the multiple start prevention and did some code cleanups. http://revu.ubuntuwire.com/p/qt-shutdown-p
[12:32] <james_w> slytherin: it's uninstallable rather than failing to install due to a postinst error or similar
[12:33] <james_w> so it's probably not python-specific knowledge that is needed
[12:33] <slytherin> james_w: It has only two dependencies both are satisfiable in lucid. So I am really wondering if this has something to do with python transition. The package has not changed for last 3 releases.
[12:34] <james_w> it needs a retry since scriptutil was promoted to main
[12:35] <slytherin> james_w: Can you give it a retry? I don't have permissions.
[12:37] <james_w> done
[12:39] <slytherin> james_w: thanks
[12:51] <hakaishi> Anyone up to review/advocate qt-shutdown-p? http://revu.ubuntuwire.com/p/qt-shutdown-p
[12:55] <highvoltage> dholbach: does core-dev imply motu as well?
[12:56] <highvoltage> dholbach: I generally thought that people become motu first before core-dev, is there a reason why mako wouldn't be able to get revu rights? http://revu.ubuntuwire.com/details.py?upid=7876
[12:57] <Laney> core-dev is a member of motu
[12:58] <Laney> you need to be made a reviewer by a REVU admin manually
[13:05] <highvoltage> nhandler: do you perhaps have some time to add mako as a reviewer on revu?
[13:06] <sistpoty|work> highvoltage: just done it
[13:06] <sebner> huhu sistpoty|work
[13:06] <nhandler> highvoltage: One second
[13:06] <sistpoty|work> hi sebner
[13:06] <highvoltage> sistpoty|work, nhandler: thanks!
[13:07] <sistpoty|work> yw
[13:07] <nhandler> Ah, beat me to it ;)
[13:37] <wrapster> if i try apt-get install on any pkg i see this error...
[13:38] <wrapster>  E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable)
[13:38] <wrapster> E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
[13:38] <akheron> wrapster: as it says, another process is using it
[13:38] <wrapster> but that is the only process using it
[13:38] <wrapster> i checked for it.. im the only one on that machine as of now.
[13:39] <wrapster> and it ws working fine all the while...
[13:39] <akheron> is there an apt-get or dpkg process stopped in the background?
[13:39] <akheron> did you check ps aux output that there's no other process?
[13:40] <wrapster> yes...
[13:40] <wrapster> but i did a ^c on apt-get and after that , Im seeing such issues.
[13:40] <wrapster> was it wrong?
[13:40] <akheron> no
[13:44] <slytherin> james_w: FYI ... libmx4j-java built fine on all arch.
[13:45] <james_w> score
[13:50] <highvoltage> "scratch (1.4.0.debian.20)" - that's a valid version number for an Ubuntu native package right?
[13:53] <sebner> sistpoty|work: it seems this will be the first FF Cycle where we can't do deep QA *hohohohoh*
[13:53] <hyperair> highvoltage: yes, but i think that package shouldn't be made a native package.
[13:54] <sistpoty|work> sebner: hm?
[13:54] <sebner> sistpoty|work: lack of games :\
[13:55] <sistpoty|work> sebner: ah
[13:57] <highvoltage> hyperair: what do you suggest?
[13:57] <hyperair> highvoltage: a non-native package.
[13:58] <hyperair> highvoltage: svn export it out and tarball it
[14:29] <bmhm> hi there, can packages for lucid still be changed?
[14:30] <sebner> bmhm: depending on what you understand under "changed"
[14:30] <bmhm> just a tiny bug report, bug #200204
[14:30] <bmhm> would be a big improvement for few effort, I think
[14:33] <sebner> bmhm: hmm, pretty late for something new
[14:34] <bmhm> I guessed so, the bad thing is that I found this bug too late :-(
[14:34] <bmhm> then better remove the nomination if it's too late
[14:36] <sebner> bmhm: I'm sorry, I don't really know who is the right person for font stuff
[14:43] <shadeslayer> bmhm: what i would suggest is to leave it like that
[14:43] <bmhm> seems pretty easy to do, I might upload own packages to my PPA
[14:43] <bmhm> ok
[14:43] <shadeslayer> bmhm: dholbach_ is your man :)
[14:44] <bmhm> I see, thx
[14:53] <bmhm> I think it should be reported upstream
[16:00] <rhpot1991> got a general license question, not ubuntu specific but I'd love to hear some opinions.  I have a license header on the top of all my source files, do/should I need to worry about putting this same header into the top of machine generated code?
[16:02] <sistpoty|work> rhpot1991: no need to do that. However I'd put "generated by <scriptname>" in there, so that it's clear that the code is generated (and I think licensecheck uses "generated by" as a regexp)
[16:11] <bddebian> Heya gang
[16:11] <sebner> huhu bddebian :)
[16:11] <bddebian> Heya sebner
[16:11] <rhpot1991> sistpoty|work: thanks
[16:12] <sistpoty|work> hi bddebian
[16:12] <bddebian> Hi sistpoty|work
[16:14]  * Rhonda waves to bddebian ;)
[16:14] <bddebian> Hi Rhonda
[16:25] <rhpot1991> sistpoty|work: thoughts on machine generated configuration files, say xml?
[16:28] <cody-somerville> xml sucks for config files
[16:28] <rhpot1991> well in this batch of code its .net, so this is Visual Studio generated garbage
[16:31] <sistpoty|work> rhpot1991: I assume visual studio doesn't restrict the distribution of these in any way? if so, just ignore them
[17:18] <christoph_debian> ubuntu's already in feature-freeze? /me should double check but debbug 567812 should affect ubuntu as well
[17:19] <Laney> debian bug 567812
[17:19] <Laney> bug fixes are almost always alright to sync
[17:19] <christoph_debian> jep and it's minimal
[17:20] <christoph_debian> I'll probably go and request the sync after verigfying it's there
[17:21] <Laney> good stuff
[17:39] <Laibsch> How can I withdraw a request for sponsorship on REVU?
[17:48] <persia> Laibsch: It can be archived.  Which package?
[17:49] <Laibsch> I found the knob now, thanks
[17:50] <Laibsch> your interpretation about the isdnutils situation seems to have been correct
[17:51] <Laibsch> thank you for preventing me from wasting any further time
[17:51] <persia> I'm not saying it can't be done, only that it needs review.
[17:51] <persia> If you think it ought be fixed, please file for a freeze exception.
[17:53] <Laibsch> I'll build the package locally
[17:54] <Laibsch> Why expend an increasing amount of effort?
[17:55] <Laibsch> when that effort mostly does not find an echo in a timely reaction
[17:56] <Laibsch> and thus bitrot will necessitate even more work next time round
[17:58] <persia> Laibsch: The other alternative is to just wait until the archive opens, and then push for it to get in then.
[17:58] <persia> The trick is to not try to get new stuff between FeatureFreeze and Release.
[17:59] <Laibsch> that's what I did six months ago
[17:59] <Laibsch> not again
[17:59] <persia> six months ago was also right after FeatureFreeze.  The secret number is three months.
[18:05] <Laibsch> persia: OK, OK
[18:05] <Laibsch> that's what I did eight months ago
[18:05] <Laibsch> and nothing happening in between
[18:05] <Laibsch> Thank you for pointing out the knob
[18:06] <Laibsch> Bye
[18:12] <BlackZ> how can I make a changelog/debdiff between two upstream versions?
[18:13] <hyperair> debdiff bla_source.changes bla2_source.changes
[18:13] <hyperair> or debdiff bla.dsc bla2.dsc
[18:15] <BlackZ> hyperair: thanks
[18:15] <hyperair> BlackZ: you can find out more by typing "man debdiff" in a terminal, or searching for man:debdiff in yelp
[18:24] <randomaction> What's generally preferred, a 99_autoconf.patch or b-dep on autoconf+automake + autoreconf in rules?
[18:25] <kklimonda> probably depends - desktop team prefers 99_autoreconf patch
[18:25] <persia> randomaction: maintainer preference.  I prefer the latter, because it auto-ports to new environments.  Some people prefer the former, because it is then possible to repeat a build.
[18:25] <directhex> mono team prefers the latter
[18:26] <directhex> since we don't need to refresh the 99_autoconf.patch for every single bloody minor update to the autohell stack
[18:26] <hyperair> persia: it's also possible to repeat a build for the latter.
[18:26] <persia> hyperair: Not always, because autotools-dev can have new stuff.
[18:26] <hyperair> my preference is to patch the autohell generated files individually, if it isn't too much.
[18:27] <hyperair> stuff like adding new files to Makefile.am can be added to Makefile.in trivially
[18:27] <hyperair> changing flags as well
[18:27] <hyperair> and maybe minor changes in configure.ac
[18:27] <persia> That's harder to submit upstream, or even carry over to the next release though.
[18:27] <hyperair> i submit my patch upstream, *then* i put it into the package and add the Makefile.in/configure bits
[18:28] <hyperair> but either way, it's not too hard to just strip away the Makefile.in/configure bits of the patch
[18:28] <hyperair> vim and the visual line mode works wonderfully for that
[18:29] <hyperair> or filterdiff or whatever that utility was called..
[18:29] <persia> filterdiff indeed.
[18:30] <randomaction> for 99*patch, I like that there are no additional build-deps and build actions, but it's usually a big patch and it needs more maintenance
[18:32] <persia> But not that much maintainance, if it's just an autoreconf patch.
[18:33] <persia> On upgrade, delete it and regenerate.
[18:33] <randomaction> in this case I think I'll settle for build-time autoreconf because I need to modify m4/gettext.m4
[18:50] <stochastic> Both Bug #360590  and Bug #152487 were awaiting a MIR approval that went through just a few hours ago.  They both have patches ready to be uploaded and if anyone is willing the entire Ubuntu Studio team would love for them to be uploaded.  I realize this is pushing into the FF a little much, do I need to get FFE bugs written up for these?
[19:14] <hyperair> anyone from motu-release? ^^
[19:15] <persia> motu-release is no more: long live ubuntu-release
[19:16] <hyperair> heh right
[19:16] <sebner> persia: Have the members merged too?
[19:16] <hyperair> i keep forgetting
[19:18] <fabrice_sp> Some to update the topic to mention Feature Freeze?
[19:18] <fabounet> BlackZ : Hi, what about the builds of Cairo-Dock 2.1.3 ?
[19:18] <fabounet> Is there somewhere I could see the results ?
[19:20] <BlackZ> fabounet: I'm building it
[19:21] <fabounet> BlackZ : ok, was there any problem with the build yesterday ?
[19:22] <fabounet> BlackZ : by the way I've noticed that someone has launched the builds of the 2.0.9. I see no reason for building this old version since it's not maintained anymore. Do you have any info about it ?
[19:22] <BlackZ> fabounet: I have started to work on it today - no, I haven't
[19:23] <fabounet> BlackZ : ah ok, I thought you did it yesterday. Do you know how much time it may take ?
[19:23] <BlackZ> fabounet: it depends, for now I have applied the patch and fixed the build issues
[19:24] <fabounet> BlackZ : ok, thanks, I'll wait then.
[19:25] <persia> sebner: Read your mail for the latest updates :)
[19:25] <BlackZ> fabounet: I think I'll end for sun
[19:27] <BlackZ> fabounet: if I don't answer here, probably I'm away, btw you can reply to the bug or send me an e-mail
[19:27] <sebner> hrm ^^
[19:27] <BlackZ> fabounet: or you can let a pm
[19:27] <fabounet> BlackZ: yep sure, where is this bug ?
[19:28] <BlackZ> bug #521536
[19:28] <BlackZ> bug #521534
[19:28] <fabounet> BlackZ: have you a mail address where I could contact you when you're away on IRC ?
[19:28] <fabounet> BlackZ: ok I see thanks. I'll reply them
[19:29] <BlackZ> fabounet: you can find it on launchpad, by registring yourself
[20:03] <FLOZz> hello _o/
[20:23] <directhex> bddebian, what're the chances of taking a look at mono in debian NEW? it's largely what was there before, but with some non-dfsg elements replaced upstream (and, as a result, a new binary package, hence NEW). this is the version i want in lucid, give or take
[20:30]  * Rhonda wonders, libsdl1.2 1.2.14 was synced into lucid though that has a major bug that affects at least wesnoth …
[20:31] <Rhonda> wesnoth developers discussed it with libsdl upstream and they confirmed that there's something fishy going on. In Debian we managed to keep 1.2.14 out of squeeze through a release-critical bugreport, but like said, it did manage to get into lucid  :-/
[20:32] <sebner> Rhonda: manually? autosyncs are nasty ...
[20:33] <Rhonda> sebner: Only could have happened manually because it never was in squeeze and from what I understood autosync only happens from squeeze this time and not from unstable?
[20:33] <sebner> Rhonda: right
[20:33]  * sebner looks
[20:34] <Rhonda> I am not interested in who did request the sync, I'm especially not interested in "blaming" someone.
[20:34] <bddebian> I think dtchen brought it from experimental
[20:34] <bddebian> directhex: I'll see what I can do
[20:35] <sebner> Rhonda: who -> contact -> gives you a reason
[20:35] <Rhonda> I just want to bring up the issue - but I have no real clue what would be possible to work around that …
[20:35] <bddebian> Fix the bug! ;-P
[20:35] <Rhonda> sebner: Pardon?
[20:35] <Rhonda> bddebian: If it would be that easy the bug would have been fixed in Debian since weeks already.
[20:36] <persia> Does it look like there can be a fix in the next couple months?
[20:36] <persia> Otherwise we'd have to do 1.2.14+really... or something
[20:36] <Rhonda> Ah, right, have seen such versioning games in the past.
[20:36] <Rhonda> I fear the bug isn't easy to fix. :/
[20:38]  * c_korn found bug 491335
[20:39] <persia> Rhonda: Do you happen to know the Debian RC bug offhand?
[20:39] <ajmitch> lucid's sdl was upgraded before the debian bug was filed, by the look of things
[20:39] <ajmitch> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565788
[20:39] <Rhonda> Yes, 565788
[20:39] <Rhonda> Thanks ajmitch for being faster. :)
[20:39]  * ajmitch had it open there :)
[20:40]  * sebner kicks his router for being laggy again
[20:40] <ajmitch> looks like it was upgrade for good reasons, and needs fixed/downgraded for good reasons as well
[20:40] <Rhonda> Interesting, fix released for something undecided?  :P
[20:40] <persia> Rhonda: People aren't always best about setting status :)
[20:41] <Rhonda> oh! bddebian!
[20:41] <Rhonda> bddebian fixed #557711 in debian. bad bddebian :D
[20:42] <ajmitch> now to find a version that doesn't have a serious regression
[20:42] <Rhonda> Looks like both versions do have their issues.  %-/
[20:43] <randomaction> looks like downgrading will break other apps
[20:44] <randomaction> Ubuntu and Debian have different X, right? Maybe Wesnoth in Ubuntu isn't broken (this needs testing at least)
[20:45] <Rhonda> randomaction: Sure, that would be something to test indeed.
[20:45] <ajmitch> the wesnoth problem also looks to be WM-related, according to those bug reports
[20:46] <persia> WM-related?
[20:46] <Rhonda> window manager
[20:46] <ajmitch> only happening on some window managers
[20:47] <Rhonda> so s/related/specific/ :)
[20:47] <persia> Which seems confusing to me, because SDL tries to capture everything.
[20:48] <Rhonda> persia: If you want to have fun take a look at what libsdl-net offers. Then you might understand how "universal" sdl _really_ is.
[20:48]  * Rhonda . o O ( short story: not much )
[20:48] <ajmitch> it's only when running the game in windowed mode, upstream report at http://bugzilla.libsdl.org/show_bug.cgi?id=894
[20:48] <persia> Rhonda: I know.  The goal is there, but ...
[20:49] <Rhonda> There was something that you can't make it bind to a specific interface only: If you give it an interface IP it behaves like a client.
[20:49] <ajmitch> that's a bit weird
[20:49] <Rhonda> fun things like that ;)
[21:04] <jfcg6> hi. i have an external usb hard disk with ext4. when inserted it is auto mounted with (rw,nosuid,nodev,uhelper=devkit). i also want to have "noatime" mount option. how do i add that to "auto mount options"?
[21:04] <persia> jfcg6: You want to ask that either in #ubuntu or #ubuntu+1 if you're running lucid.
[21:05] <jfcg6> i did but got an answer for modifying fstab file which is for statis fs info
[21:05] <jfcg6> i dont think that is what i should do
[21:06] <jfcg6> should be something about devkit
[21:06] <persia> You might be right.
[21:06] <persia> But this channel is just very much not the right place.  We tend to maintain otherwise unmaintained software on the edges of the distribution.
[21:06] <persia> And the problem you describe doesn't sound like it falls in that area.
[21:07] <jfcg6> ic thx
[21:07] <persia> So, either keep pushing at the regular support channels, or file a bug (which may be invalid if it's not really a bug)/
[21:16] <ScottK> There's also the buy a support contract option.
[21:17]  * persia always forgets that one
[21:23] <fabounet> BlackZ : may I know how is going the build ?
[21:23] <fabounet> Is this page the right one to see when they are finished ? https://launchpad.net/ubuntu/+builds?build_state=all&build_text=cairo-dock
[21:29] <jfcg6> im failing to find "file a bug" link on bugs.launchpad.net, am i looking at the wrong place?
[21:32] <persia> jfcg6: Try running `ubuntu-bug` locally.
[21:37] <arand> If there anything in particular that has to be done for pbuilder to change the repo mirror it uses, I've changed the global one but pbuilder still pulls from the old one.
[21:37] <arand> s/If/is/ s/./?/
[21:42] <persia> arand: You have to edit pbuilder-dist
[21:43] <arand> persia: so it "soft-locks" itself on first run?
[21:43] <persia> hrm?
[21:47] <arand> persia: Ah, pbuilder-dist is a command.. Though it was just config file that gets set on first-run of pb.
[21:47] <persia> It may be both.  I know very little about pbuilder, except from running it once, and editing pbuilder-dist once.
[21:50] <geser> what should work is to login into your pbuilder (with --save-after-login) and edit /etc/apt/sources.list
[22:26] <arand> When running debuild -S, complaints about nonexistent original tar, should one care?
[22:26] <arand> (this when using a ~blah-ppa1 rename)
[22:26] <azeem> arand: does it mean it builds a native package?
[22:26] <azeem> i.e. no .diff.gz
[22:27] <lifeless> yes
[22:27] <lifeless> arand: what is a ~blah-ppa1 rename
[22:28] <vorian> it's just a renaming for ppa reasons /me thinks
[22:28] <arand> nautilus_2.28.1-0ubuntu3.1~arand-ppa1, edited in dch -i (doing it wrong?)
[22:29] <vorian> arand: to andwer your first question, it doesn't matter as long as the builder knows which source to use
[22:29] <vorian> ie, orig.tar.gz
[22:32] <arand> Ah, yes, I do get a nautilus_2.28.1-0ubuntu3.1~arand-ppa1.tar.gz, so is there any way to point debuild to the right orig archive?
[22:32] <vorian> what do you mean?
[22:33] <arand> vorian: like azeem pointed out, I get no diff.gz, which I guess isn't an ideal situation..
[22:33] <vorian> you need to make sure your changelog version matches your tar file
[22:34] <persia> For the upstream part.
[22:34] <azeem> or make sure the tarfile is actually present
[22:34] <persia> changelog has ${VERSION}-${REVISION}, and only ${VERSION} has to match.
[22:36] <arand> hm, ok, seems like it doesn't like the two-part ~arand-ppa1 whereas ~ppa1 works, well well, so be it.
[22:50] <jariq> I've read that I can use pbuilder on ubuntu to build packages for debian sid. But to test if debian package is functional I need to install sid right ?
[22:50] <persia> Well, kinda.
[22:51] <persia> There are ways to access chroots that let you do some testing of some things.
[22:51] <persia> So it really depends on what you are testing.
[22:51] <jariq> But when using chroot I am still under ubuntu kernel?
[22:52] <persia> (but I don't know how to manipulate or share environment with pbuilder chroots, so someone else may have to suggests runes for your grimoire)
[22:52] <persia> If you're testing anything kernel related, chroot testing can't help at all.
[22:54] <jariq> ok so I will try to install sid once again
[22:55] <persia> You can always use a VM
[22:55] <persia> Or if sid is hard to install, install squeeze and dist-upgrade.
[22:56] <jariq> i installed lenny and then tried to dist-upgrade to sid but too many packages failed
[22:57] <ari-tczew> could someone look @ bug 521390 and check my debdiff?
[23:01] <sebner> ari-tczew: you have a) a comment b) it's in main so -devel might a better place to ask c) it's not before FF so not super urgent so you might want to wait until a sponsor shows up without asking every time in the chan ;)
[23:04] <paissad> E: pms-linux source: not-using-po-debconf
[23:04] <paissad> o0
[23:04] <paissad> do no tell me that i have to create translations for all languages in debian/po ^^
[23:04] <ari-tczew> sebner: I asked here, because I hope that someone from MOTU know answer for dholbach question in the bug. I'm not master developer, I just make debdiffs.
[23:05] <sebner> ari-tczew: then you should specify that and of course you don't need to be master but you should know why you do some changes
[23:07] <persia> ari-tczew: More importantly, if you don't know why you're changing something, you should think twice about changing it.
[23:08] <paissad> is there a tool which create debian/po/ files  from a debian/$package_name.template  ?
[23:08] <ari-tczew> persia, sebner: I only move changes from delta into latest testing revision, lol
[23:09] <paissad> here is my template
[23:09] <paissad> http://pastebin.com/f13e19fee
[23:09] <paissad> but i do  not have a debian/po directory yet
[23:09] <sebner> ari-tczew: that's certainly not the right attitude.
[23:10] <persia> ari-tczew: I understand.  But my contention is that if you want to contribute to Ubuntu, you should understand what it is that you are contributing.
[23:11] <sebner> ari-tczew: a) look at the changes that have been made in the past b) understand them c) look if you can drop them (maybe Debian included them) d) use the changes for the next version if you think it's necessary and/or adjust them if necessary
[23:13] <ari-tczew> sebner, persia: I can do nothing for Ubuntu and at all and leave more outdated merges for you, do you want?
[23:13] <persia> ari-tczew: I think there's somewhere between those two values.
[23:13] <persia> ari-tczew: I strongly suspect that you're capable of understanding some of the changes, or learning to do so.
[23:14] <persia> And if you do that, then I *very much* want you to keep sending patches.
[23:14] <sebner> ari-tczew: We are thankful for your help but this is really the wrong attitude
[23:14] <persia> Getting a patch for every Debian upload is perhaps less interesting, as it distracts the sponsors from other work that is known to fix specific bugs.
[23:16] <persia> ari-tczew: If you have questions about a given patch, or similar, please ask.
[23:16] <persia> ari-tczew: But do so *before* bothering with the merge work.
[23:17] <ari-tczew> persia: I asked @ 23:57
[23:17] <persia> You asked someone to check your debdiff.
[23:17] <persia> What I'm suggesting is you might ask something specific about a change.
[23:18] <persia> For instance "What virtual packages are good for Java for lucid?"
[23:18] <ari-tczew> I think that dholbach give a suggest for sync package
[23:18] <persia> Part of the work is in asking that kind of question.
[23:18] <persia> (because you have to understand how to translate the patch into English)
[23:19] <ari-tczew> then I asked here, because I'm not sure, because I'm not a developer master, because I don't know ALL
[23:20] <persia> OK.  Let's try this differently.  What questions do you have about the patch?
[23:23] <ari-tczew> the delta is:
[23:23] <ari-tczew> -Depends: default-jre-headless | java1-runtime-headless | java2-runtime-headless |
[23:23] <ari-tczew> +Depends: default-jre-headless | java2-runtime-headless |
[23:23] <ari-tczew> is it necessary?
[23:24] <persia> Well, what does it do?
[23:25] <ari-tczew> +    - debian/control: Runtime depend on headless JREs
[23:26] <persia> That's what the changelog says.  What does it do?
[23:26] <ari-tczew> I don't know
[23:27] <persia> And that is why you got asked in the bug :)
[23:27] <persia> So, What does Depends: mean in a control file?
[23:28] <ari-tczew> Depends is depends on packages needed for work
[23:28] <persia> OK.  And what does '|' mean in a Depends: line?
[23:28] <ari-tczew> This is always enigma for me :)
[23:29] <ari-tczew> I don't know. Maybe do you tell me?
[23:29] <persia> http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-relationships.html is worth reading then :)
[23:29]  * persia is not going to answer dholbach's question, but will help to get it answered
[23:30]  * sebner also advices to read the packaging guide
[23:30] <cjwatson> paissad: 'man po-debconf'
[23:31] <sebner> To know what's living in debian/*
[23:31] <cjwatson> (install the po-debconf package if you don't already have it)
[23:33] <ari-tczew> persia: ok what's next?
[23:33] <cjwatson> I think perhaps ari-tczew's problems may be a symptom of us recommending merging as something that trainee developers can do before they really know what's going on
[23:33]  * persia agrees
[23:33] <persia> ari-tczew: OK.  So, waht does '|' mean?
[23:33] <cjwatson> merging is often not straightforward at all and can require deep understanding - if we're presenting it as a "getting started" task, that's our fault
[23:34] <persia> We've changed that a couple times, but it inevitably gets added back somehow.
[23:34] <persia> The issue being that getting people to look at fixing bugs is hard.  We need to get better at building a set of stuff that is easy to fix as candidates.
[23:35] <persia> But in many cases, it's easier to just fix them.
[23:35] <sebner> persia: cjwatson We have byte-size bugs to start with
[23:35] <persia> sebner: Have you looked at the bitesize list recently?  It needs help getting bigger.
[23:35] <sebner> persia: that's true and most merges are not difficult so it's clear that many start with merges
[23:36] <sebner> cjwatson: btw, thanks again for fixing dpkg :)
[23:36] <cjwatson> you're welcome
[23:36] <persia> well, except, it's really easy to get merges wrong.
[23:36] <persia> Or to make a change that we *don't* want, just because it's shiny.
[23:36] <sebner> aye
[23:36] <sebner> like bumping Standards-Version?
[23:36] <cjwatson> the problem with the merge queue is that the difficulty level is completely nonlinear
[23:36] <persia> That's harmless, but useless.
[23:37] <cjwatson> a bunch of trivial stuff, mixed in with some rocket science, and there's no way to tell in advance
[23:37]  * sebner thinks about courier and shivers
[23:37] <cjwatson> perhaps we need a way to note merges as bitesize or hard
[23:37] <cjwatson> I suppose we have MoM comments
[23:38] <persia> We do, but distinguishing the two isn't that much harder than doing the merges.
[23:38] <sebner> + better changelog entries explaining *why* a change was made. /me still seems a great lack there
[23:38] <sebner> *sees
[23:38] <ari-tczew> persia: english isn't my native language, but I think that "|" works following: that package can work java1-runtime-headless and can work with java2-runtime-headless ; correct me if I'm wrong
[23:39] <persia> ari-tczew: That's right.
[23:39] <persia> ari-tczew: So, what does the diff do?
[23:40] <ari-tczew> \o/
[23:41] <ari-tczew> hmm, currect delta prefer to use java2-runtime-headless, not java1-runtime-headless
[23:42] <persia> No preference, really.  Just dropping support for dava1-runtime-headless.
[23:42] <persia> Now, does the package *work* with java1, or does it require java2?  Also, do we have a java1-runtime-headless package?
[23:42] <cjwatson> sebner: *shrug* maybe I'm arrogant, but I've seen newcomers make a thorough mess of installer merges, and I prefer to put this down to inexperience with installer code rather than my poor changelog entries ;-)
[23:43] <cjwatson> it's often a bit of both
[23:43] <persia> ari-tczew: Once you dig up the answers to those questions, you should know if this is something we want.
[23:43] <sebner> cjwatson: I really didn't want to attack anyone personally and especially not *you*, mighty colin ;)
[23:44] <cjwatson> sebner: I didn't take it as an attack :)
[23:44] <ari-tczew> persia: packages.ubuntu.com says: Sorry, your search gave no results
[23:44] <cjwatson> nor am I fishing for compliments - just noting that sometimes it really is OK to put things down to lack of experience from the merger if that's what it is
[23:44] <cjwatson> anyway, bed
[23:45] <sebner> cjwatson: totally right. gn8 /me too :)
[23:45] <ari-tczew> persia: I checked packages.ubuntu.com for java2-runtime-headless and it doesn't exist too! wtf?
[23:45] <cjwatson> ari-tczew: packages.ubuntu.com won't list virtual packages.  the tools in the dctrl-tools package may come in handy.
[23:45] <cjwatson> (if you don't know what a virtual package is, go back to the policy document.)
[23:46] <ari-tczew> cjwatson: I'm very tired after work and I f_ck the policy
[23:46] <cjwatson> I shan't bother trying to help you again, then!
[23:49] <sebner> ari-tczew: If you are really that tired and don't care about the policy you should save your time for something else than ubuntu ..
[23:49] <cjwatson> I'd much rather point people to documentation (which they can read around in and find out more in their own time), rather than repeating little bits of the documentation on demand.  If that doesn't suit you, I'm sorry.  Good night.
[23:51]  * sebner says gn8 too
[23:53] <ari-tczew> hmm, other words: maybe I don't f_ck the policy, but a milions clauses are boring
[23:54] <ari-tczew> and as I said english isn't my native language so sometimes I don't see sense for reading these documentations if I''ll not understand these
[23:54] <persia> ari-tczew: If you don't understand the policy, you are going to have a hard time understanding how the packaging works, or why it might be done that way.
[23:55] <ari-tczew> and sorry for bad words
[23:55] <persia> We will happily answer questions about the policy, but you are expected to read it.
[23:55] <ari-tczew> persia: can we back into review debdiff?
[23:57] <persia> ari-tczew: I didn't know we stopped.  You were investigating about the virtual packages, and which were correct for this package.
[23:58] <ari-tczew> I think that virtual package is a package, which was a normal package but now it name has been changed, is it right?