[07:20] <dholbach> good morning
[09:18] <hakermania> tumbleweed, what an instant review! Thanks :D We have made ourselves the one sound, the other will be removed anyway :) As for the images they all come from public domains. Document them exactly as the Pictures/screen.png, or something additional?
[09:21] <tumbleweed> hakermania: oh I forgot to mention, but there's a bunch of stuff in debian/install that probably isn't needed. I'd remove it all, test-build, and put back what was missing
[09:23] <tumbleweed> hakermania: document copyright and licencing in debian/copyright
[09:23] <hakermania> tumbleweed, it is needed. debian/install puts some files to the appropriate position. As for the 'documentation', does this mean to add some extra info, site URL for example of the public domain?
[09:23] <tumbleweed> oh right you did for that one. Yeah more like that. Bonus points for mentioning where you got them from
[09:24] <tumbleweed> hakermania: ok, why do you install data/doc/wallch/copyright /usr/share/doc/wallch/ ?
[09:24] <tumbleweed> that overwrites debian/copyright
[09:28] <hakermania> tumbleweed, oops, you're right
[09:34] <hakermania> tumbleweed, we've made the notification sound, so it is included on the Files: *, OK?
[09:35] <tumbleweed> fine
[09:39] <hakermania> tumbleweed, the unistallation script uses /home/$(logname) because it has to be run with root priveleges and then ~ will be /root. Is this wrong?
[09:40] <tumbleweed> yes, although that isn't used in the debian packaging, so we don't care too much
[09:40] <tumbleweed> use ~logname
[09:40] <tumbleweed> or even better, just don't delete it. A debian package wouldn't
[09:41] <hakermania> tumbleweed, OK, I will just don't have the option to delete the configuration files from the unistallation script
[09:43] <tumbleweed> if a user knows that running it will delete those files, that's fine. If they don't then you probably shouldn't. (again this has nothing to do with debian/ubuntu)
[09:45] <hakermania> OK
[09:51] <jtaylor> syncing new packages needs a ffe or?
[09:52] <Laney> yes
[09:52] <jtaylor> ones that aren't in oneiric yet
[09:52] <jtaylor> k
[09:52] <nigelb> unless its a bugfix. (I think)
[09:52] <Laney> a bugfix new package?
[09:52] <nigelb> bah, should read.
[09:52] <nigelb> sorry.
[09:52] <jtaylor> well python-traitsui is needed so python-chaco in oneric can be installed
[09:53] <pmjdebruijn> hi all
[09:53] <tumbleweed> jtaylor: that's pretty good argument for the FFe then
[09:53] <pmjdebruijn> http://packages.debian.org/wheezy/libspice-server1
[09:53] <pmjdebruijn> is anybody familiar with that construct?
[09:53] <pmjdebruijn> [spice_0.8.2.orig-celt.tar.gz] [spice_0.8.2.orig.tar.bz2] [spice_0.8.2-1.debian.tar.gz]
[09:53] <pmjdebruijn> two .orig files?
[09:54] <tumbleweed> yes
[09:54] <pmjdebruijn> how does it work?
[09:54] <pmjdebruijn> just unter the second .orig.tar.gz into the other?
[09:54] <Laney> jtaylor: is that accidental autosync fallout?
[09:54] <pmjdebruijn> untar*
[09:54] <tumbleweed> pmjdebruijn: http://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/
[09:54] <pmjdebruijn> ah cool, thanks
[09:54] <pmjdebruijn> though one last question... is it compatible with PPA?
[09:55] <jtaylor> Laney: I think yes, was synced 4 weeks ago
[09:55] <tumbleweed> pmjdebruijn: yes, you can use it wherever you can use 3.0 (quilt)
[09:55] <Laney> :(
[09:56] <pmjdebruijn> tumbleweed: cool thanks!
[09:56] <Laney> might as well have done a new-source run when that happened
[09:58] <jtaylor> hm it is no new package, its a rename :/
[10:06] <jtaylor> great it looks like a messed up transition
[10:32] <jtaylor> tumbleweed: where you somehow involved with python-vtk?
[10:32] <jtaylor> it only installs files for python2.7, causing mayavi (also accidentally synced) to ftbs
[10:33] <tumbleweed> yeah I have that bug in an open tab
[10:34]  * tumbleweed actually looks at it
[10:42] <jtaylor> mayavi2 worked around this in debian by setting X-Python-Version to 2.6
[10:42] <tumbleweed> yeah I'm trying to see how that worked
[10:42] <tumbleweed> because vtk isn't built for 2.6
[10:44] <tumbleweed> oh right, it is in debian
[10:44] <jtaylor> yes
[10:44] <tumbleweed> bug commented on
[10:44] <jtaylor> I wrote a mail to the mayavi maintainer asking if there was another reason for this change
[10:44] <jtaylor> bug number?
[10:44] <tumbleweed> bug 831224
[10:45] <jtaylor> if not we could do the same workaround in ubuntu aftr we sync traitsui
[10:45] <tumbleweed> yeah, vtk was manually changed to use 2.7
[10:46] <jtaylor> can't vtk be fixed?
[10:47] <tumbleweed> to use 2.6? We're trying to get rid of 2.6
[10:47] <tumbleweed> vtk and mayavi2 should both be fixed in Debian to build with the default python version
[10:48] <tumbleweed> unfortunatly that's not trivially simple any more, because we got rid of XS-P-V: current
[10:48] <jtaylor> why can't vtk build for both python versions?
[10:48] <tumbleweed> haven't tried, it may be possible
[10:48] <tumbleweed> but we should still run mayavi2 on 2.7 unless we know it won't work
[10:49] <jtaylor> it builds for 2.7, testing some runtime stuff
[10:54] <jtaylor> mh also needs ffe for pyface
[10:58] <jtaylor> and python-envisage -.-
[11:02] <jtaylor> hm not fully functional
[11:03]  * tumbleweed was planning to look at scientific packages for global jam. /me wonders if jtaylor will leave any for us (don't stop :) )
[11:22] <jtaylor> ok now it all works
[11:22] <jtaylor> I'll file the ffe's
[11:42] <hakermania> tumbleweed, about Package doesn’t clean correctly. "(You should be able to debuild -uc -us twice in a row)" Do you mean running in a terminal: debuild -uc -us; debuild -uc -us ?
[11:44] <jtaylor> yes but better yet, pbuilder --build dsc --twice
[11:45] <hakermania> jtaylor, I don't use pbuilder anyway. Should I use these commands except from normal debuild or debuild -S?
[11:46] <tumbleweed> jtaylor: aah, didn't know about --twice :)
[11:46]  * tumbleweed wants something similar in sbuild
[11:47] <hakermania> Can I use pbuilder as well for doing so? And again, should I run this instead of normal debuilding?
[11:47] <tumbleweed> hakermania: you should test-build in pbuilder, because it's a clean environment (so it ensures your package has the correct Build-Deps)
[11:47] <tumbleweed> it also means you don't need to run oneiric to build for oneiric
[11:53] <hakermania> tumbleweed, running the debuild twice failed. It doesn't clean the generated translation files and so it sees them as changed files. How can I add a rule to clean them also? Inside the debian/rules or this will overwrite the cleaning rule?
[11:53] <udienz> hi, what's limit of Ffe? i got mention that upstream project released new release. can i upload new release to oneiric?
[11:55] <tumbleweed> hakermania: you should probably fix the upstream makefile to clean correctly, but the easy workaround for debian/ubunt is to put *.qm in debian/clean
[11:55] <tumbleweed> udienz: there's no limit, you just need to justify that it's worth the risk
[11:55] <hakermania> yee
[11:56] <jtaylor> udienz: have you read https://wiki.ubuntu.com/FreezeExceptionProcess?
[11:56] <jtaylor> ffe's for the enthough stuff filed
[11:57] <udienz> jtaylor, tumbleweed: thanks i'll read about FFe and tested new version
[12:01] <hakermania> tumbleweed, Ok, I documented the pictures, removed the hardcored /home and running debuild with the arguments you told twice worked OK. Uploading?
[12:02] <tumbleweed> hakermania: those were all the issues I saw
[12:05] <hakermania> tumbleweed, it seems that running debuild with the options you told doesn't signed the .changes with my GPG. I cannot upload
[12:05] <tumbleweed> sign it with debsign, then
[12:06]  * tumbleweed builds without uploading a lot more than for uploading, so -uc -us is automatic
[12:08] <tumbleweed> jtaylor: for future, you can request it all in one FFe
[12:08] <jtaylor> oh ok
[12:09] <jtaylor> can syncrequests also be done in one bug?
[12:10] <tumbleweed> these days all uploaders can process sync requests
[12:11] <hakermania> Ok, thanks again, uploading :D
[12:25] <tumbleweed> jtaylor: it would be helpful to include debc output in your build logs (I recommend some pbuilder hooks / sbuild)
[12:26] <jtaylor> hm yes that would be useful, do you have a ready hook?
[12:26] <tumbleweed> jtaylor: there's one in examples
[12:27] <jtaylor> thx
[16:47] <joru> hi, a noob question. how can i know what packages are installed by default in say natty? (e.g. after a fresh install before adding ppa's and other repos)
[16:49] <jtaylor> juru: apt-cache policy package  will show all available versions of a package and which is installed
[16:49] <jtaylor> dpkg -l will list all installed packages
[16:49] <jtaylor> with "ii" as status
[16:55] <joru> jtaylor: ok that is good. so if there is a "candicate" for lets say the zip-package this will is included when i run an apt-get update?
[16:56] <joru> jtaylor: and if i want do know which packages are included by default (fresh install) in a distro, do you know how to do that?
[16:57] <joru> jtaylor: kinda like a diff of my local environment in rel to fresn install
[16:57] <joru> fresh
[16:59] <jtaylor> sorry I don't know if you can do that in a simple way
[16:59] <joru> darn :)
[17:00] <joru> maybe look into contents of one of the isos
[17:00] <jtaylor> besides comparing dpkg -l output with a clean install
[17:02] <joru> uups, wrong button
[17:10] <joru> jtaylor: maybe the file here contains this sort of info? http://se.archive.ubuntu.com/ubuntu/dists/natty/universe/binary-amd64/
[17:10] <joru> jtaylor: some 25k packages in natty amd64
[17:32] <jtaylor> joru: those are all packges, not all of these are installed in a default install
[17:32] <joru> jtaylor: ok
[17:33] <joru> jtaylor: such as depending on if installing the server or desktop edition i guess?
[17:35] <joru> jtaylor: well in any case apt-cache policy is ok for me atm so thanks for the help
[17:36] <jtaylor> maybe there is a Packages file on the install iso you can use
[17:36] <joru> jtaylor: I will look into that. thanks
[19:36] <tumbleweed> joru: debootstrap works out what ot install from Priority, but that's for a *minimal* install. For any of the standard install types, look at the meta-packages (i.e. ubuntu-desktop / ubuntu-standard)
[20:21] <joru> tumbleweed: ah that is excellent