[00:39] <slicer> Hi. Is there somewhere I can check the state of imports from testing? Alternately, does anyone know how often syncs are done?
[00:42] <micahg> slicer: http://people.ubuntuwire.com/~lucas/merges.html
[00:43] <persia> slicer: syncs are done by a script the archive admins run on their respective archive-admin day, so it's usually about once a weekday, except when someone is busy/sick/on holiday/forgets/etc,
[00:44] <slicer> persia: Aha, and this being the holidays, that would explain the delay :) I'll wait a week then.
[00:45] <slicer> micahg: Thanks.
[00:46] <persia> slicer: Is there something you *need* pulled that's blocking your work?
[00:46] <persia> If so, you may be able to find an archive admin to help, or find some minor bug that needs fixing to justify an Ubuntu upload (assuming you have the time to go get it back in sync later)
[00:46] <slicer> persia: Not really, just had a user ask why it wasn't available yet. I have no problem telling them to wait a week though :)
[00:47] <persia> If not, better to just wait :)
[00:47] <persia> Yeah, when it comes to user queries, that's the best option :)  Might be a couple weeks, as most of the archive admins seem to be on holiday, and there may be some backlog on the buildds when they return.
[00:48] <slicer> As long as it happens before the import freeze, I'll be happy.
[00:48] <persia> Should do, I'd think.
[00:49] <slicer> Isn't that february sometime? :) The imports shouldn't be THAT lagged.
=== Amaranth_ is now known as Amaranth
[01:26] <BLUG_Fred> hi everyone, doing my first package (a python program) and I have a few question. I'm trying to work out the control file and more specifically the "depends" section. How do i specify that the application depends on wxgtk2.6 and not wxgtk2.8? Also from the examples I looked at, the package full name must be specified: does it make my deb Ubuntu specific or will it work on debian as well?
[01:32] <Locke> What would be changed in a source package to cause dh_make to debianize for autotools, when it previously used (and should still) cmake?
[01:38] <freeflying> BLUG_Fred: Depends: python-wxgtk2.6
[01:38] <BLUG_Fred> freeflying: hey! morning! so no need for the full ubuntu package name?
[01:39] <freeflying> BLUG_Fred: for packaging, ubuntu is nearly 100% compatiable with debian
[01:39] <freeflying> BLUG_Fred: no
[01:39] <BLUG_Fred> freeflying: ok thanks.
[01:39] <freeflying> BLUG_Fred: np
[01:40] <BLUG_Fred> freeflying: and since wxgtk2.6 only works with python 2.4 to 2.6, python >=2.4 is enough?
[01:40] <BLUG_Fred> freeflying: actually i wrote Depends: python (>=2.5.2) so far
[01:40] <BLUG_Fred> freeflying: but the apps won't work with >=3
[01:41] <freeflying> BLUG_Fred: dpkg will solve the revert dependency automatically, just let it depends on python-wxgtk is enough
[01:41] <freeflying> BLUG_Fred: since pyhton-wxgtk2.6 has specified its dependency already, so you needn't write it in your package
[01:41] <BLUG_Fred> freeflying: oh.. so not even necessary to specify python then... i see!
[01:42] <freeflying> BLUG_Fred: no
[01:42] <BLUG_Fred> freeflying: great! thanks a lot.
[01:42] <freeflying> BLUG_Fred: np, dude
[01:49] <Locke> What would be changed in a source package to cause dh_make to debianize for autotools, when it previously used (and should still) cmake?
[01:55] <freeflying> Locke: cmake is different from autotools
[01:56] <Locke> I know
[01:57] <Locke> And the programmer has used cmake from the beginning, but now when I debianize his source, the rules and control reflect autotools rather than cmake
[01:58] <freeflying> Locke: you mean upstream switch from cmake to autotools?
[01:58] <Locke> It not. Upstream says it is still cmake, as it's always been.
[01:59] <freeflying> Locke: then whats your issues?
[01:59] <Locke> If I used the rules and control from an older version I've built, it builds fine. If I use the rule and control that dh_make provides for this version, it fails.
[02:00] <freeflying> Locke: fails at which step?
[02:00] <Locke> My issue i that dh_make is generating the wrong rules/control file now, when it didn't in the past.
[02:00] <Locke> Lemme get some output for you.
[02:01] <freeflying> well, I goona go, ttyl
[02:02] <Locke> http://launchpadlibrarian.net/37187459/text_outputs.tar.gz
[02:02] <Locke> Ok
[02:19] <jmarsden> Locke: Sounds like either the CMakelists.txt is missing or moved, or there is a configure.ac or configure.in which wasn't there before ?
[02:19] <wgrant> Locke: Why are you running dh_make if a package already exists?
[02:20] <Locke> jmarsden: I'll check the source package
=== asac_ is now known as asac
[02:21] <Locke> wgrant: I'm packaging newer, unbuilt and unpackaged versions of this.
[02:21] <jmarsden> Locke: wgrants point is valid -- if you already have debian/* files from an earlier version, use those as a starting point.
[02:21] <wgrant> You still shouldn't be using dh_make, unless you want to create about AN AWFUL LOT more work for yourself.
[02:22] <wgrant> https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate
[02:23] <Locke> wgrant: I'm not submitting these to the repo's, they're just for me and the people I play with. dh_make is simple when all I am making is a simple package.
[02:24] <Quintasan> Locke: this package is using cmake?
[02:24] <Locke> Yes
[02:24] <Quintasan> Locke: is this kde related?
[02:25] <Locke> Not particularly.
[02:25] <Quintasan> Locke: Did you try cdbs
[02:25] <Quintasan> ?
[02:26] <Quintasan> well
[02:26] <Locke> I did not, but I'm curious why it functioned properly previously, but now generates debian/ wrong.
[02:26] <Quintasan> maybe some compatibility problems, we have new debhelper :P
[02:27] <Locke> Ack
[02:27] <Quintasan> Locke: You can try copying your old rules files to somewhere and put "import /usr/share/cdbs/1/class/cmake.mk" into rules
[02:27] <Quintasan> also add cdbs to build-depends and try building
[02:27] <Locke> Will do
[02:28] <Quintasan> Mind showing me the rules you have now?
[02:28] <Locke> The ones that work, or the ones that don't?
[02:28] <Quintasan> The ones that don't work
[02:28] <Quintasan> Hmm though the working ones would be good too
[02:29] <Locke> http://launchpadlibrarian.net/37187459/text_outputs.tar.gz
[02:29] <Locke> They're in there.
[02:30] <Locke> The one labeled 0.44-rules are new and don't work, the 0.40-rules are old and do work, when I use them to build 0.44.
[02:30] <Locke> Perhaps the templates changed during an update..... The original source is not debianized.
[02:30] <Quintasan> hmm, cmake.mk should really solve everthing
[02:31] <Quintasan> cdbs does magic sometimes :P
[02:31] <Locke> :) I'll try that. I've never used it. I'm not a packager or anything, just a casual user trying to make this work; and if possible let upstream know why it's not debianizing correctly.
[02:32] <jmarsden> Quintasan: Which is why quite a few packagers prefer dh to cdbs -- less magic :)
[02:32] <Quintasan> IMHO It's wrong for upstream to provide debian/ dir :P
[02:32] <Locke> I agree
[02:33] <Quintasan> jmarsden: well I like dh too, but packaging KDE releases would be a PITA with no cdbs :P
[02:34] <Quintasan> Well it's 3am here, I'm going to bed, good night
[02:34] <jmarsden> Quintasan: Maybe so (I've not tried!) but this is just a simple application that has already been packaged once... using the existing working set of debian/* files to work from would seem more logical than starting over with dh_make (especially if issues occur, which seems to be happening here).
[02:35] <jmarsden> Locke: You can and should ask upstream not to provide a debian/ directory in their source tarballs.
[02:35] <Locke> I just feel that it functioned before, but does not now. If I had not done this previously and already had proper rules, it would have been a pain. Some other casual packager like myself trying to do this for the first time with this source would fail and not have proper rules to make it work.
[02:35] <Locke> jmarsden: They don't, I am generating them.
[02:35] <jmarsden> Ah.  OK.
[02:36] <Locke> Thats the issue: they are generating wrong now, when they generated correctly with previous versions.
[02:36] <jmarsden> Where is the original (current) source tarball ?
[02:36] <Locke> Launchpad; lemme find an address for you.
[02:37] <Locke> https://launchpad.net/springlobby/+download
[02:39] <Locke> I packaged 0.38, 0.39, and 0.40 when they were current without a hitch.
[02:39] <jmarsden> Locke: There is a file in the top level called configure -- was that present in the earlier version?
[02:39] <jmarsden> I strongly suspect that is what is confusing dh_make
[02:40] <Locke> it is there. I diff'd it, and it was the same.
[02:41] <Locke> locke@pimpshit:~/my_build$ diff springlobby-0.40/configure springlobby-0.44/configure
[02:42] <Locke> ^^ returns no output.
[02:43] <jmarsden> mv configure oldconfigure ; dh_make ; mv oldconfigure configure     # works for me...
[02:44] <jmarsden> By convention a script called configure at the top level of a source tree implies autotools... using that exact name for a non-autotools script is asking for trouble, really.
[02:47] <Locke> So I guess I'm asking: What changed? configure existed in previous versions, and is identical to the current configure. dh_make generated the proper debian/ in previous versions (and still does) and generates an incorrect debian/ in the current version
[02:47] <Locke> I know how to get around it and make it work, but I'd rather know what changed so I can fix it, instead of doing workarounds
[02:48] <jmarsden> Sounds like someone changed the way dh_make checks what kind of configuration system a package has, probably to fix things for some other use case.
[02:49] <jmarsden> If you want to check on it, grab the dh-make source package and take a look, including reading the changelog
[02:49] <Locke> So your guess is possibly an update to one of the dh*/debhelper packages isn't compatible with this somehow?
[02:49] <Locke> I'll be sure to do that.
[02:50] <jmarsden> Since there *is* a trivial workaround, and you aren't packaging for Ubuntu or Debian, I'm not very convinced it's worth the work, but OK.
[02:51] <jmarsden> I'd guess a bug fix or update to dh-make changed its behaviour for your particular source package.
[02:51] <Locke> :) It's something for me to do when I'm bored, that is why I started building and packaging in the first place. :)
[02:51] <jmarsden> Then take it to the next level and actually package the thing properly and get it submitted to REVU or sponsored into Debian unstable!
[02:52] <Locke> I've considered "proper" packaging :) I should consider it further.
[02:53] <Locke> The process is laid out pretty forwardly in the wiki then, yes?
[02:53] <jmarsden> Yes.  https://wiki.ubuntu.com/PackagingGuide/Complete is one starting point.
[02:55] <Locke> That is a pretty thick guide: thorough I'd imagine. I'll read through that and try with the next batch of stuff I build.
[02:55] <jmarsden> Go for it :)  Ask questions here if you get stuck.
[02:55] <Locke> I'm sure I will :) Thanks.
[02:55] <jmarsden> You're welcome.
[02:57] <Locke> I'm out for the night; thanks for the effort with my issue guys. Later.
[03:08] <wgrant> I don't think he understands the purpose of dh_make.
[03:16] <dhillon-v10> wgrant, so from what I understand, using debuild -S -sa reduced a lot of work while packaging
[03:16] <wgrant> dhillon-v10: How were you doing it before?
[03:17] <dhillon-v10> wgrant, using dh_make
[03:17] <dhillon-v10> wgrant, thanks for that tip
[03:17] <wgrant> They serve completely different purposes.
[03:19] <dhillon-v10> wgrant, hey i have another question: I am packaging a little ppa that doesn't have anything that needs compiling, so debuild works fine, but launchpad make .deb packages that are like 2.4 kbs. while the orig file is 43 mgs
[03:19] <dhillon-v10> wgrant, here's my directory structure: http://paste.ubuntu.com/347784/
[03:24] <wgrant> dhillon-v10: Have you told it to install files into the package?
[03:30] <dhillon-v10> wgrant, please elaborate, are you referring to the rules file, I am not too good at packaging from scratch
[03:38] <jmarsden> dhillon-v10: man dh_install and read https://wiki.ubuntu.com/PackagingGuide/Complete for more info.  You probably need to create a debian/install file indicating which files to install where.
[03:39] <dhillon-v10> jmarsden, thanks I didn't know that i have to make a /install file
[03:39] <jmarsden> dhillon-v10: Seriously, read that Guide :)
[03:40] <dhillon-v10> jmarsden, alright will do :D
[03:46] <bddebian> dhillon-v10: Sorry was/am afk off and on
=== Whoopie_ is now known as Whoopie
[03:47] <dhillon-v10> bddebian, nah that's okay plus Scott said that we shouldn't be talking on that channel, I think I figured out what the problem is thanks anyways god ;)
[03:52] <ScottK> bddebian: FYI, there a a graphviz update needed for the Python 2.4 transition in Debian (it's QA maintained at the moment).  I'm working on it.
[03:56] <bjsnider> dh_make should create a rules file that installs the files into the package
[03:57] <bddebian> ScottK: OK cool, let me know if/when you need an upload
[03:57] <bjsnider> the install target name needs to match the package name in the control file
[03:57] <ScottK> Will do.
[04:06] <dhillon-v10> bjsnider, alright thanks it works now :D
[04:07] <bjsnider> cool
[05:24] <lfaraone> Wheere could I find an example get-orig-source for a package which uses git upstream?
[05:48] <porthose> https://wiki.ubuntu.com/MOTU "Joining MOTU" Is this the correct procedure for applying for MOTU?
[05:54] <crimsun> lfaraone: nouveau-kernel-source
[05:58] <lfaraone> crimsun: thanks
=== asac_ is now known as asac
[08:51] <BLUG_Fred> hi again! I was wondering whether the trunk code needs to be modified to reflect packaging constraint (file locations specifically) or you just manually change it every time you package?
[08:52] <BLUG_Fred> the application is a python app.. sorry
[08:52]  * BLUG_Fred hopes the question was clear enough.
[08:58] <diwic> BLUG_Fred: it needs a little background information for newcomers such as myself
[08:58] <diwic> BLUG_Fred: what trunk?
[08:59] <BLUG_Fred> diwic: well I am (trying to...) packaging a python application which has never been packaged. Everything runs from the same directory. Now in order to follow Linux directory structure I need to move some files and modify the code to reflect those changes.
[09:00] <BLUG_Fred> diwic: should this code modification only be used everytime I package or should I commit them to the application trunk?
[09:00] <diwic> BLUG_Fred: if you have access to commit things upstream, that seems to be the best way...?
[09:00] <BLUG_Fred> diwic: doing so will break compatibility with Windows I guess, so maybe i need to add OS detection and.. well I have a few questions as you see.
[09:00] <diwic> BLUG_Fred: aha
[09:01] <BLUG_Fred> diwic: yes
[09:01] <BLUG_Fred> diwic: i started as a translator and well.. i'm doing a bit more now
[09:01] <diwic> BLUG_Fred: ok then I'll suggest you use the build/install process to move them
[09:01] <ghostcube> whats the sense of this now ? DONT WORK AS TRANSLATOR YOU GET LOST IN YOUR WORK
[09:01] <BLUG_Fred> diwic: since it's a python program it could be used on Linux, MAC and Windows...
[09:01] <ghostcube> heh
[09:02] <tjingboem> is this the place to ask for getting software placed in the repo from ubuntu?
[09:02] <BLUG_Fred> diwic: what is the build/install process?
[09:03] <BLUG_Fred> tjingboem: please shoot! I'd be interested in the answer as well ;-)
[09:03] <tjingboem> i know that Csound 5.11 is available for debian
[09:03] <diwic> BLUG_Fred: Do you know the difference between a source package and a binary package?
[09:03] <BLUG_Fred> diwic: and we use the application on at least Linux and Windows regularly
[09:03] <tjingboem> i would like it to be available for Ubuntu
[09:04] <BLUG_Fred> diwic: yes. but in python everything is... source somehow
[09:04] <tjingboem> right now there is Csound5.10
[09:04] <tjingboem> but 5.11 has important updates for me
[09:06] <diwic> BLUG_Fred: in this case I would say the source package would have the files in one dir, but the binary would have it in FHS structure
[09:08] <diwic> tjingboem: Ubuntu has local changes to csound, it needs someone to merge them
[09:09] <tjingboem> who can that be?
[09:09] <BLUG_Fred> diwic: ok. clear. so my changes to the source code should be considered as the building process? is that what you suggest?
[09:10] <tjingboem> should i come back later and just try again hoping that person is there?
[09:11] <diwic> tjingboem: If you just need to use a newer version of csound, download the source package from Debian and build it for yourself
[09:11] <tjingboem> that is something i was hoping to avoid :)
[09:12] <diwic> tjingboem: download the binary package from "testing" then and pray that it works ;-)
[09:13] <BLUG_Fred> diwic: should I upload those changes somewhere in the source repository then (in case someone else takes over)?
[09:13] <diwic> BLUG_Fred: changes to the source code should be done with patches
[09:14] <diwic> BLUG_Fred: otoh, as you're an upstream developer, your interest would be to make it work for all linux distros, not just debian
[09:14] <BLUG_Fred> diwic: right
[09:14] <BLUG_Fred> diwic: i was planning to supply a deb and a rpm
[09:15] <BLUG_Fred> diwic: (alien-ized rpm.. hehe)
[09:16] <diwic> BLUG_Fred: btw, what is it in your python code that needs to be platform specific?
[09:17] <BLUG_Fred> diwic: icons, documentation and po files I guess
[09:18] <BLUG_Fred> diwic: documentation is actually 48 lessons on how to program in python
[09:18] <BLUG_Fred> diwic: in html
[09:22] <diwic> BLUG_Fred: To sum up, my recommendation (as a python layman, I must point out) is to 1) what needs changing in the actual source code, commit that upstream, and for moving files, use a makefile
[09:25] <diwic> BLUG_Fred: you can look at the makefile I wrote for codecgraph for inspiration, see https://launchpad.net/~diwic/+archive/ppa/+packages
[09:25] <BLUG_Fred> diwic: i will look as all is not quite so clear for me yet. Thanks a lot for your help!
[09:29] <diwic> BLUG_Fred: the makefile in debian packaging is called debian/rules, btw.
[09:29] <BLUG_Fred> diwic: ah.. yes I am at the rules file stage actually
[09:30] <diwic> BLUG_Fred: but that one often just calls other files
[09:30] <BLUG_Fred> diwic: and the copying file stage...
[09:31] <diwic> BLUG_Fred: hmm...looking at my own code, I see that upstream actually supplied that makefile.
[09:31] <diwic> BLUG_Fred: it probably makes sense for your upstream to do the same
[09:34] <BLUG_Fred> diwic: you mean that I should upload a copy of control and rules into the source svn?
[09:35] <diwic> BLUG_Fred: no, no debian directory upstream
[09:35] <BLUG_Fred> diwic: sorry for my  total lack of knowledge on the topic. I read 10 pages on packaging and got even more confused.. and the "simple" tutorials don't touch about source svn
[09:36] <diwic> BLUG_Fred: for the moving files stuff, have a look at codecgraph
[09:37] <diwic> BLUG_Fred: it has a simple file-moving Makefile in its top directory
[09:39] <diwic> BLUG_Fred: learning how to package takes time. Try not to take it all in at once.
[09:40] <BLUG_Fred> diwic: well I think I am ok with the "how to move files", but if i do so without changing the source code, the application will not work
[09:41] <diwic> BLUG_Fred: assuming upstream ships a Makefile which moves files, upstream should of course also work with the files moved.
[09:41] <BLUG_Fred> diwic: but those changes are Linux specific
[09:42] <BLUG_Fred> diwic: ok... that answers my question
[09:42] <BLUG_Fred> diwic: not the easiest path, but a clear answer...
[12:34] <persia> porthose: Yes, that is the correct procedure.
[12:49] <porthose> persia, thx, :)
[13:53] <slytherin> Does anyone know how to typecast char * to const char *?
[13:56] <diwic> slytherin: (const char *)
[13:56] <slytherin> doesn't seem to work.
[13:57] <diwic> slytherin: depends on the situation then
[13:58] <diwic> slytherin: but basically the question is, if the string is really constant, why wasn't it const char in the first place?
[13:59] <slytherin> Actually it is i18nized string. Sadly gettext returns it as char * instead of const char *. And GTK+ meny requires that the label be const char *.
[14:01] <slytherin> there is a wrapper around gettext in glib but that requires me to bump the glib dependency version.
[14:02] <diwic> slytherin: seen from ubuntu'
[14:02] <diwic> s perspective, bumping glib dependency wouldn't be a problem...?
[14:05] <slytherin> diwic: Hardy has an older version. And I want this application to be installable on hardy for as long as possible. :-)
[14:05] <diwic> slytherin: ok. Then look at the source for how glib did it ;-)
[14:05] <slytherin> yes that's the last resort.
=== jtechidna is now known as JontheEchidna
=== maco2_ is now known as maco2
=== maco2 is now known as Guest82669
=== Guest82669 is now known as maco2
[15:20] <jezier> hi... I have a question about package versioning... lets say that I want my pacakges with suffix "foo"...  and for example I have patched iptables... (current deb filename is iptables_1.4.4-1ubuntu1_i386.deb)... what name should I choose so that package manager will know that mine is new version... iptables_1.4.4-1ubuntu1foo1_i386.deb ?
[15:21] <maco2> i usually go with 1ubuntu1~foo1
[15:21] <maco2> er wait... no you want +
[15:21] <hyperair> + is right
[15:22] <maco2> ~ makes official package supercede yours
[15:22] <jezier> oh.. ok :)
[15:22] <jezier> I know about ~ but it is opposite of what I want :)
[15:22] <jezier> ok.. will try +
[15:22] <jezier> thx
[15:22] <hyperair> you can test by using dpkg --compare-versions
[15:23] <hyperair> e.g.
[15:23] <hyperair> $ dpkg --compare-versions 1.0 gt 1.0~1 && echo yes || echo no
[15:23] <hyperair> yes
[15:23] <asac> Lutin: thx. only the launcher now missing ;)
[15:38] <Lutin> asac: I assumed either mterry or jamie would be updating the REVU package or uploadding it, but maybe they're busy with other work/holidays
=== maco2_ is now known as maco2
[15:51] <asac> Lutin: its uploaded ... just not bin NEWed
[15:51] <asac> waiting for archive admin push
[15:53] <Lutin> asac: ah, ok. as I didn't see any reply on REVU, I assumed nobody had been working on it, sorry
[16:12] <asac> np
[16:26] <sbalneav> If I wanted to build a package from a git repo checkout, what would be the naming convention?
[16:26] <sbalneav> pkgname_x.xx.x-git.orig.tar.gz?
[16:28] <persia> sbalneav: I'd recommend using '+' rather than '-' to separate the base upstream and the checkout.
[16:28] <persia> For a more robust scheme, consider pulling the base version, and applying the checkout patch as a patch in the packaging, rather than attempting to construct a tarball based on the checkout.
[16:29] <sbalneav> ok
[16:29] <persia> e.g. 1.2.3-4ubuntu2 where the difference between -4ubuntu1 and -4ubuntu2 is the updates from the upstream git repo.
[16:31] <sbalneav> I also happen to be upstream for this gnome, project, one supposes I could just ping the gnome release manager, and bump my configure.ac version numbers a bit early, and release a new upstream tarball a few days sooner than expected :)
[16:31] <sbalneav> might be easier :)
[16:31] <sbalneav> persia: Thanks!
[16:32] <persia> sbalneav: Either works.  I just usually try to avoid having too many tarballs floating around, because it's harder to verify the trust path on the code, etc.
[16:33] <sbalneav> Well, I'm running into the "I'd like people to test before I make an upstream release, but no-one knows how to compile code anymore, so unless I make a package, no one can test it" problem :)
[16:33] <persia> Heh.  I understand.
[16:34] <persia> For that, you might try 1.2.3~rc1-0ppa1 as a version-revision string.
[16:34] <persia> And then go from 1.2.3~rc1 to 1.2.3 when there is an actual release.
[16:34] <sbalneav> Ah, good idea!
[16:34] <sbalneav> perfect.
[16:35] <persia> If you end up having issues, 1.2.3~rc2 >> 1.2.3~rc1, so you can do multiple rcs.
[16:35] <sbalneav> Bingo
[16:35] <persia> And, just as importantly, 1.2.3-1 >> 1.2.3~rc* which means that when the release happens, everyone will get upgraded.
[16:36] <persia> Note that this only makes sense when you *are* upstream.  If it's someone else's git checkout, it's less right to call it "~rcX", and applying the patches in packaging may make more sense :)
[16:40] <sbalneav> right.
=== \vish is now known as mac_v
=== mac_v is now known as \vish
[16:58] <maxb> If you really feel the need, 1.2.3~git20091228+g03c5f9a is an option
=== yofel_ is now known as yofel
[18:48] <randomaction> Is there any difference between "Recommends: iceweasel | firefox | www-browser" and "Recommends: iceweasel | firefox | abrowser | www-browser"? Is seems to me that there isn't as both firefox and abrowser depend on packages providing www-browser, so either nothing of firefox will be installed.
[18:50] <micahg> randomaction: it pulls in the first one that in recommends by
[18:50] <micahg> default
[18:50] <micahg> that's available
[18:52] <randomaction> Yes, so that would be firefox (if there's no browser) or nothing (is there is), regardless of whether abrowser is in Recommends.
[18:52] <randomaction> I'm asking because it's our delta for nip2 package and I wonder if it should be kept.
[18:52] <micahg> well, if abrowser in installed, then it wouldn't try to pull in another browser
[18:52] <micahg> randomaction: yes
[18:53] <randomaction> (This has been carried forward for a long time, maybe there's a reason I miss)
[18:53] <micahg> randomaction: abrowser is our version of iceweasel
[18:54] <randomaction> Yes, I know.
[18:54] <randomaction> "Yes" as in "Yes, keep it"?
[18:54] <micahg> randomaction: yes, I think it should be kept
[18:54] <randomaction> OK, thank you
[19:00] <geser> abrowser provides firefox so the unmodified recommends will be fulfilled when abrowser is installed
[19:02] <micahg> geser: hmmm, let me ask asac about it then
[19:02] <randomaction> Indeed, so I think it's only advertising.
[19:04] <micahg> randomaction: I can ping you when I find out
[19:04] <randomaction> thank you
[19:35] <asac> yes. its advertising
[19:44] <micahg> randomaction: it's advertising per  asac
[19:44] <randomaction> ok, so intentional and should be kept
[19:44] <micahg> randomaction: yep
[19:55] <polac> Beginners question about Bug #439256 which is tagged as needs-packaging. Upstream source allready contains debian folder. Should I work together with Upstream mainteiner or override debian folder completely or try to build it and if success just replace the package maintainer info?
[19:55] <ubottu> Launchpad bug 439256 in ubuntu "[needs-packaging] java bindings for sqlite" [Wishlist,New] https://launchpad.net/bugs/439256
[19:55] <Laney> polac: you could ask the upstream maintainer if he is interested in (co)maintaining the package in Ubuntu/Debian
[19:57] <Quintasan> Good evening
[19:58] <highvoltage> hi Quintasan
[19:58] <polac> Laney: Ok. Thanks.
[19:59] <geser> Hi Quintasan
[19:59] <polac> Laney: Can you say why there is a debian folder? I cannot find that package from the Debian or any other debian based distro. Or at least google can't
[20:00] <Laney> polac: it's probably unofficial, upstreams often like to ship .debs to make it easier to install
[20:00] <Laney> but with help they might be receptive to making it an official package
[20:04] <polac> This is going to be my first contribution to ubuntu community and first attempt to create/maintain package. Maybe I should start from some other package. That upstream fellow might not appreciate the help if he needs to guide me all the time. :)
[20:07] <Quintasan> polac: well, it's not like packaging is a very hard thing all of the time, you just have to try. IMHO developers providing debian/ dir in tarball are doing it wrong, they should provide it somewhere else :P
[20:11] <polac> Quintasan: And it is even easier when almost everything you need to do comes with the tarball. ;)
[20:12] <Quintasan> lol, I wonder how we are supposed to manage this since Debians policy forbids modyfing the upstream tarball
[20:12] <Laney> source format 3.0 helps here
[20:22] <polac> Quintasan: What would be the correct way to distribute tarball without the debian folder and still allow people to create unofficial .debs simple?
[20:24] <polac> Laney: Any suggestions?
[20:24] <Quintasan> polac: a) Provide it as a separate tar b) provide all required information like dependecies, all authors (with emails!) and supply LICENSE file (some developers forget this!)
[20:25] <Quintasan> Ad b) Thos information would be best in a file called PACKAGING or something like this
[20:26] <polac> Ok. I try to work something out with the upstream fellow.
[20:30] <Laney> polac: they can maintain the packaging data in a separate branch
[20:30] <Laney> and use that to build their .debs
[20:32] <polac> Laney: One tip more. Thanks.
[21:05] <ari-tczew> in lucid if I want to do merge on package based unstable (not yet testing), can I do it or do I need to wait for migrate package into testing?
[21:06] <geser> ari-tczew: if you have a reason to merge from unstable instead of testing, you can do it
[21:07] <sebner> huhu geser :D
[21:07] <geser> Hi sebner
[21:08] <geser> your notebook working again?
[21:08] <sebner> geser: I have my laptop back :D but lucid is not stable here so I have to use karmic ^^
[21:09] <ari-tczew> geser, so I prefer to waiting for migrate -> testing
[21:09] <ari-tczew> there is no reason
[21:33] <bjsnider> is there a way to use dpkg-source -b so that it creates an untouched orig tarball, ie. leaves out the debian directory?
[21:34] <geser> why would you need that?
[21:34] <bjsnider> why would i need an orig tarball?
[21:35] <geser> ah, so you don't have an orig tarball?
[21:35] <bjsnider> if i do a git or svn instead of downloading it
[21:35] <geser> svn export
[21:36] <bjsnider> svn export creates an orig tarball?
[21:37] <geser> you can use it to create a tarball which is your orig tarball (if you rename it to the expected name)
[21:37] <christoph_debian> svn export creates a checkout without .svn dirs
[21:37] <geser> which is good as you usually don't want .svn  inside the tarball
[21:38] <bjsnider> well, dpkg-source -I also leaves out the svn directories.
[22:22] <bjsnider> how could i alter the destination directory in a cdbs package?
[22:41] <crimsun> bjsnider: same way as other packages
[22:47] <bjsnider> i can't add any commands to the rules filebecause it results in "commands commence before first target.  Stop."
[22:50] <asac> bjsnider: thats a make syntax issue most likely
[22:50] <asac> in rules
[22:50] <asac> accidential whitespaces or something i guess
[23:09] <crimsun> dhillon-v10: qa.ubuntuwire.org/ftbfs
[23:09] <dhillon-v10> crimsun, alright
[23:16] <bjsnider> actually i think this is the problem. this is a very rough package. there is a built target but no install target. so can i add an install target in a cdbs rules file?
[23:52] <Duck-> Hi, does anyone know where I can find a cracked version of inbunto 9?
[23:53] <directhex> !ops
[23:53] <ubottu> Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpds!
[23:56] <Quintasan> nice, cracked version of Ubuntu? :D
[23:56] <bjsnider> what did he ask?
[23:56] <directhex> something stupid
[23:56] <Quintasan> really stupid
[23:56] <sladen> did seem quite draconian
[23:57] <sladen> we could have explained how Ubuntu is already legal to copy and modify
[23:57] <elky> sladen, he's been trolling other channels
[23:57] <directhex> it was clearly trolling
[23:58] <Quintasan> It's very amusing to see that it's possible to from questions that don't make any sense so much.
[23:58] <bjsnider> too bad you can't send the user an electric chock when they get kicked from an ubuntu channel
[23:59] <elky> bjsnider, yes, it's such a shame we can't potentially kill people with heart issues.
[23:59] <Quintasan> I think we would  already have a deficiency of users :P