[00:49] <lamalex> Is there a simple way find what packages depend on package foo?
[00:51] <mathiaz> lamalex: apt-cache rdepends package-name
[00:51] <ari-tczew> apt-cache rdepends foo
[01:00] <lfaraone_> ScottK: would it be too late to upload calibre 0.6.17 to karmic, if I were to prepare a debdiff? (0.6.17 fixes  numerous bugs present since 0.6.13)
[02:13] <rmjb> hello? anyone here?
[02:24] <rmjb> I want to fix a bug in a package for karmic
[02:34] <lamalex> rmjb: great, go for it
[02:34] <rmjb> my question is on the SRU
[02:34] <rmjb> thanks for the response lamalex
[02:34] <lamalex> anytime
[02:35] <rmjb> it's this bug: https://bugs.launchpad.net/ubuntu/+source/backintime/+bug/409130
[02:35] <rmjb> there's already a fix and branch linked, how do I get that into the karmic package?
[03:07] <theholyduck> would it be possible to get the opencore-amr codecs added to backports for various ubuntu versions? (jaunty mainly). or is this totally the wrong channel for asking this?
[03:09] <theholyduck> i guess i could just get the debs and install them and hope nothing breaks, but some official solution would be better
[04:02] <_Andrew> In the .install file is there a way to prevent files from being installed in a package?
[04:03] <_Andrew> Maybe something like "usr/include/*\n ^usr/include/*NOTWANTED"  ??
[04:04] <_Andrew> So it wouldn't include any files with the name blahblahNOTWANTED ?
[04:30] <Teddy_> Hi there.  My package needs updating from Debian testing.  This is the right place, right?
[04:33] <Teddy_> The package's name is "mandos", and Ubuntu has version 1.0.11, and Debian testing has had 1.0.12 for a while now, which fixes several bugs.
[04:42] <philwyett> Teddy_, See the email just posted by ScottK @ https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-October/000634.html
[04:45] <Teddy_> philwyett: Hmm, that seems to say that the deadline has *not* been passed.
[04:47] <philwyett> Teddy_, Indeed. You can always subscribe to the motu list (https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu) and ask how to get your update pulled.
[04:48] <Teddy_> philwyett: I was hoping to avoid subscribing to yet another mailing list and just ask here instead...
[04:49] <philwyett> Teddy_, Wait for ScottK to appear and he will most likely be able to help you out.
[04:49] <Teddy_> philwyett: Sounds like a plan.
[04:49] <philwyett> lol
[04:52] <philwyett> Teddy_, Just to ask being that it is only a minor revision number bump, it is only a bug fix release with no new features and API changes?
[04:53] <Teddy_> philwyett: Yes, that is correct.  1.0.11 -> 1.0.12
[04:54] <philwyett> Teddy_, Cool, I can see no reason for it not to be pulled. :-)
[04:54] <Teddy_> philwyett: Me neither; I expected it to be done semi-automatically, but the date keeps creeping closer and I'm getting worried.
[04:55] <philwyett> Teddy_, merge-o-matic does pull automatically up to a certain time before release. It's last run was early Sept.
[04:57] <Teddy_> philwyett: I see that the package entered Debian testing on Oct 1.  I though it was less recent than that.  Oh well, "missed it by *that* much".
[04:59] <philwyett> Teddy_, Seems so. I only know the last run as I am subscribed to way too many lists. ;-)
[05:00] <philwyett> Teddy_, To learn about motu, you can read all about it here: https://wiki.ubuntu.com/MOTU
[05:04] <philwyett> Teddy_, This section will be of particular interest https://wiki.ubuntu.com/SyncRequestProcess
[05:05] <Teddy_> philwyett: Oo, looks interesting
[05:08] <fabrice_sp> Teddy_, if it's a bug fixing only, and the package compile/install/run in Ubuntu, it's still possible to have it in KArmic
[05:10] <Teddy_> fabrice_sp: Yes, so I've come to understand.  But the question still remains: How do I get the package to actually update/sync?
[05:10] <fabrice_sp> !sync
[05:10] <fabrice_sp> :-/
[05:10] <fabrice_sp> you can use requestsync in Ubuntu
[05:11] <Teddy_> fabrice_sp: Well, I don't actually *run* Ubuntu...
[05:11] <fabrice_sp> oh
[05:11] <fabrice_sp> you should :-D
[05:11] <fabrice_sp> what is the package name?
[05:11] <Teddy_> fabrice_sp: I'm happy with Debian.
[05:11] <Teddy_> fabrice_sp: The package is "mandos".
[05:12] <fabrice_sp> ok: I'll test build it, and if it works, I'll send it
[05:12] <wrapster> if i have a pkg built only for 32bit.. how do i compile it for 64 as well? eg : libtspi-dev
[05:12] <wrapster> where should i be looking and for what?
[05:12] <Teddy_> fabrice_sp: Oh wow, that would be great!
[05:13] <fabrice_sp> is there an upstream changelog somewhere? (just to check that it's a bug fixing only release)
[05:13] <Teddy_> fabrice_sp: Hmm, w8
[05:14] <Teddy_> fabrice_sp: You'll have to use the VC browser: http://bzr.fukt.bsnet.se/loggerhead/mandos/release/changes
[05:16] <fabrice_sp> Teddy_, ok. I'll have a look, and in the meantime, I will testbuild/install it
[05:18] <Teddy_> fabrice_sp: Thanks a lot!
[05:18] <wrapster> guys can anyone help me?
[05:19] <fabrice_sp> Teddy_, thanks to contribute with this app and Debian packaging :-)
[05:19] <fabrice_sp> wrapster, where are you compiling it?
[05:20] <BlueT_> #302330 the xmail bug in Hardy exist for a long time, and there's somebody have a patch with it
[05:21] <BlueT_> anyone can help to apply/commit it? :)
[05:21] <fabrice_sp> bug #302330
[05:22] <wrapster> fabrice_sp: on ubuntu 64
[05:22] <fabrice_sp> Teddy_, the installation is ok, but it fails to run in a chroot, with a python exception on dbus. Is it a known issue?
[05:23] <fabrice_sp> BlueT_, subscribe Ubuntu Sponsors for Universe to the bug report, and put a debdiff
[05:23] <Teddy_> fabrice_sp: Well, the mandos server needs an avahi daemon running, which in turn need a d-bus daemon.  I guess that could be it?
[05:24] <fabrice_sp> wrapster, so do I. How do you compile it? With a pbuilder?
[05:25] <BlueT_> fabrice_sp: i know that's the best way and I'd really like to do so for a long time :)
[05:25] <BlueT_> fabrice_sp: but before that...
[05:25] <wrapster> fabrice_sp: no
[05:25] <Teddy_> fabrice_sp: D-Bus communicates over a Unix domain socket, which probably is not connected inside the chroot.
[05:25] <fabrice_sp> Teddy_, yes: I get a connection refused to socket /var/run/dbus/system_bus_socket
[05:26] <wrapster> im very new to this .. so ,so far what i've been doing is to download the source.. do necessary modifications...(to suit my requirements) then build it...
[05:26] <Teddy_> fabrice_sp: You need a D-Bus daemon (and an Avahi daemon) running inside the chroot then.
[05:26] <fabrice_sp> wrapster, then, how are you building it?
[05:26] <wrapster> but as an example ,i want libtspi-dev in 64 but not availbale.. so would like to compile for it.
[05:26] <fabrice_sp> Teddy_, shouldn't that be pulled by dependencies?
[05:27] <Teddy_> fabrice_sp: They should be, and they are, as far as I know.
[05:27] <fabrice_sp> wrapster, install a pbuilder, in amd64 flavor, and you will be able to compile it, if you have Ubuntu running  the amd64 flavor
[05:27] <fabrice_sp> Teddy_, could be a problem of using a chroot. I'll try in a VM
[05:28] <Teddy_> fabrice_sp: Yeah, that should work fine
[05:28] <mzz> wrapster: it's probably possible to do something screwy with bindmounts to get the system's bus socket to show up inside the chroot (doing that instead of running a second chrooted system bus may or may not make sense)
[05:29] <mzz> wrapster: (specifically: a second bus is a nonissue, but if that seconds bus starts a second networkmanager confusing stuff might happen)
[05:29] <wrapster> oh
[05:29] <mzz> err, do I have the wrong nick?
[05:29] <fabrice_sp> BlueT_, so, what are you expecting? :-D
[05:30] <fabrice_sp> mzz, I think it was for Teddy_  :-)
[05:30] <mzz> thanks
[05:30] <mzz> well, see above
[05:30] <fabrice_sp> and for myself (as user :-) )
[05:30] <wrapster> mzz: / fabrice_sp: im just starting off without understanding the issues ... so could you point out to any resource online that i can use to learn the nitty gritty issues of compiling for 64B
[05:31] <mzz> wrapster: are you doing your compiling on a 64 bit system? :)
[05:31] <wrapster> mzz: yeah
[05:31] <wrapster> i think i know that much at leat :D
[05:31] <mzz> wrapster: if you don't actually have a 64bit system it might be easiest to just use a ppa
[05:31] <fabrice_sp> !pbuilder
[05:31] <fabrice_sp> wrapster, ^
[05:31] <mzz> wrapster: otherwise I'm a fan of sbuild's lvm support, which is a bit slow but very thorough
[05:31] <mzz> also, that
[05:32] <BlueT_> fabrice_sp: dunno how much time it would take for the MOTU application, and would like the patch to be applied if there's anyone can do so before me :p
[05:32] <fabrice_sp> it rocks with apt-cacher-ng! :-)
[05:32] <fabrice_sp> BlueT_, sponsorship is different than MOTU application
[05:33] <fabrice_sp> sponsorship is when you you get a debdiff or a patch uploaded by a MOTU
[05:34] <fabrice_sp> you have to get 'some' pathees/debdiff sponsored before being able to apply fo MOTUship
[05:34] <Teddy_> mzz: When is it important to be able to run in a chroot?  My application just uses the Avahi libraries; should it be my responsibility to know that it's using D-Bus and provide some workaround for running chroot:ed?
[05:34] <fabrice_sp> Teddy_, I would say no
[05:34] <mzz> Teddy_: I wouldn't bother doing anything special unless you know many of your users are going to run it chrooted for some reason
[05:34] <fabrice_sp> that's why I have a VM (not updated since a long time, btw)
[05:35] <Teddy_> fabrice_sp: OK, that's good then.
[05:35] <Teddy_> mzz: No, there's no particular reason.
[05:35] <fabrice_sp> yes: I'm updating it (192 Mb to download)
[05:36] <mzz> Teddy_: especially because frequently you simply *cannot* offer a sane chroot-specific mode
[05:36] <Teddy_> fabrice_sp: I thought I *had* an Ubuntu image for QEMU, but it seems to have gotten corrupted somehow.  I'm downloading installation media now to recreate it.
[05:36] <fabrice_sp> Teddy_, ok. It seems updating my vm will take 15 min :-/
[05:37] <Teddy_> fabrice_sp: 24 min left to download the DVD here...
[05:37] <fabrice_sp> DVD?!
[05:37] <mzz> meh, dvds
[05:37] <fabrice_sp> you could have downloaded only the CD :-)
[05:37] <Teddy_> fabrice_sp: That's what was there for karmic beta
[05:37] <fabrice_sp> and no CD? Strange
[05:37] <mzz> then you found a weird download link
[05:37] <Teddy_> fabrice_sp: http://cdimage.ubuntu.com/releases/karmic/beta/
[05:38] <mzz> yeah, don't use that, use the regular mirrors
[05:38] <mzz> http://releases.ubuntu.com/releases/9.10/ for example
[05:38] <Teddy_> mzz: Thanks!
[05:39] <mzz> well, might as well use the dvd if you've already grabbed most of it, I'm assuming it'll work
[05:39] <Teddy_> mzz: No, only got about 25%
[05:40] <Teddy_> mzz: 5 min remaining on CD download...
[05:40] <mzz> heh
[05:40] <fabrice_sp> BlueT_, the patch has not been seen because it's attached to a duplicate... And u-u-s has not been subscribed
[05:41] <fabrice_sp> still 8 minutes to update my vm
[05:41] <fabrice_sp> mandos is very qucik to compile, so it should quick after :-)
[05:41] <Teddy_> fabrice_sp: It'll take ages for me to install a new OS so I think you'll beat me.  :)
[05:42] <fabrice_sp> I think so :-D
[05:42] <Teddy_> fabrice_sp: Yeah, the C programs are small and the server is in Python, so yeah, quick to compile. :)
[05:43] <MTecknology> When using xdm in Ubuntu, the logo used is Debian. It makes people think I'm using Debian and not Ubuntu. If I submitted a fix for it, would it be able to be in the repos or could there be issues in that?
[05:59] <BlueT_> fabrice_sp: trying to figure what should I do now
[06:00] <fabrice_sp> BlueT_, https://wiki.ubuntu.com/MOTU/Contributing
[06:01] <fabrice_sp> Preparing new revisions part
[06:01] <BlueT_> fabrice_sp: checking
[06:13]  * fabrice_sp is still updating his Karmic VM :-/
[06:14]  * Teddy_ is still installing a new Karmic :)
[06:14] <fabrice_sp> lol
[06:14] <Teddy_> ..In a QEMU.
[06:15] <fabrice_sp> I'm using Virtualbox for virtualization
[06:16]  * hyperair updates his karmic installation which isn't in a VM :)
[06:16] <maco> hyperair: may i PM?
[06:16] <hyperair> go ahead
[06:17] <hyperair> but i have to go soon so make it quick
[06:39] <BlueT_> KVM's nice
[07:08] <fabrice_sp> Teddy_, it installs fine in a VM. I'll request & ack the sync request
[07:09] <Teddy_> fabrice_sp: Wonderful.
[07:09] <Teddy_> fabrice_sp: Thanks a lot!
[07:10] <fabrice_sp> yw ;-)
[07:23] <dholbach> good morning
[07:47] <_Andrew> Anyone know why "dh_install ... -XCEGUI" includes CEGUI files in my package?
[08:13] <highvoltage> morning jono!
[08:13] <jono> hey highvoltage :)
[08:34] <goshawk> hi
[08:35] <goshawk> is anyone using karmic with 2.6.31-14 official kernel? well, it gives me kernel panic cuz it's unable to mount rootfs (ext4) 2.6.31-11 works.
[08:37] <mzz> goshawk: seems to work for me
[08:37] <mzz> goshawk: (my root is ext4 in lvm on ide)
[08:37] <goshawk> mzz: exactly the same here
[08:38] <goshawk> but i've just installed karmic and did the update.. i should investigate more
[08:51] <mzz> goshawk: actually that sounds as if it's not mounting the initrd
[08:52] <goshawk> uhm... i can force a initramfs rebuild
[08:52] <mzz> goshawk: do you have enough output when it panics to tell if the initramfs mounted?
[08:52] <goshawk> no
[08:52] <mzz> if for whatever grub isn't feeding it that it won't boot at all if you're using lvm
[08:52] <goshawk> i just see that line
[08:53] <goshawk> i think initramfs is not mounted
[08:53] <goshawk> cuz i don't see the usplash logo too
[08:53] <goshawk> (which is in initramfs
[08:53] <mzz> I'd boot off something bootable and doublecheck the initrd is in the right place and /boot/grub/grub.cfg makes sense
[08:53] <goshawk> i'm on 2.6.31-11 now, which works
[08:53] <mzz> that's weird, unless you're missing the initrd for 14 or grub.cfg is borked
[08:54] <goshawk> running update-initramfs -k all -c
[08:54] <mzz> (your symptoms sound exactly right for grub trying to boot without feeding the kernel a working initrd)
[08:54] <goshawk> yep
[08:54] <goshawk> so i'm rebooting
[08:54] <goshawk> and see what wil happen
[09:08] <goshawk> mzz: solved
[09:08] <goshawk> it works now
[09:08] <mzz> hmm, odd. Wonder how it broke
[09:09] <goshawk> me too
[09:09] <goshawk> hope i'm a odd case
[09:09] <goshawk> time to go for me
[09:09] <goshawk> see you
[10:51] <joaopinto> hello
[10:51] <joaopinto> how do we request a package removal ?
[10:54] <sistpoty|work> joaopinto: file a bug specifying which package and why it should get removed and subscribe ubuntu-archive
[10:55] <geser> check rdepends, check rbuilddepends, file a bug with any info you find (like no r(build)depends, debian removal bugs) and apply the usual sponsoring (if needed)
[10:55] <joaopinto> ok, gave up on grnotify
[11:01] <joaopinto> does it make sense to mark all the "package is broken" bugs as duplicates from the removal request ?
[11:01] <Laney> joaopinto: no
[11:02] <Laney> there's no point tracking bugs on a removed package
[11:02] <Laney> except maybe for sru
[11:02] <joaopinto> Laney, so what will happen to the open bugs ?
[11:02] <Laney> they'll stay
[11:02] <joaopinto> and what's the point of keeping bugs for a package which is no longer on the archive ?
[11:03] <Laney> history
[11:03] <Laney> srus
[11:03] <Laney> if it's ever reintroduced
[11:04] <joaopinto> that may represent introducing infite bugs, aren't closed bugs ketps for history already ?
[11:04] <joaopinto> also it gives the bug reporter some expectation that someone will work on the bug, which is not the case
[11:05] <geser> joaopinto: just because you remove the package from the archive, it doesn't automatically disappear from the users systems so it might be good for them to still see the unfixed bugs
[11:06] <joaopinto> geser, the app does not work, and never worked
[11:06] <joaopinto> actually on karmic is not even installable
[11:06] <Laney> there's no reason we could not SRU a removed package
[11:06] <geser> joaopinto: did it work in jaunty? or was it broken there too?
[11:07] <joaopinto> geser, yes, at least from my test in a chroot
[11:07] <joaopinto> it was a bad revu package
[11:07] <joaopinto> ubuntu only
[11:08] <Laney> you know
[11:09] <Laney> this might be good for a revu case study
[11:09] <joaopinto> anyway, enough effort about a broken package, removal request filled, done
[11:09] <Laney> how did such a broken package get in?
[11:09] <Laney> and why did the packager not take care of it?
[11:10] <sistpoty|work> in this case the package==upstream iirc
[11:11] <sistpoty|work> which is even more interesting
[11:11] <joaopinto> and why did it get in, when there are other packages sitting, like mine, pending due to an unclear license, from the review perspective :P
[11:50] <walterl> hi
[11:50] <walterl> is there a way to update only a specific repository?
[11:55] <sistpoty|work> walterl: only add that to sources.list? (that might of course hold back a lot of packages, or force removals of packages not in this repository depending on apt's resolver)
[11:56] <walterl> sistpoty|work: in my case i only want to update packages from a ppa. wouldn't removing the other sources cause the rest of the packages to "disappear"?
[11:56] <sistpoty|work> walterl: it would mean that apt doesn't have an idea about them, not that these will get removed on your system
[11:57] <walterl> sistpoty|work: k. so there's no way to tell update to ignore repo's?
[11:59] <sistpoty|work> walterl: not too sure actually. if it's a different release name, I guess you could use -t as apt-get parameter (however ppa's share the same release name as the distro)
[11:59] <sistpoty|work> walterl: maybe apt pinning can do what you want, however I don't have too much clue about that
[12:00]  * walterl googles
[13:12] <benste> Hi, I'm about to go through the Packaging guide linked on your motu site and noticed that e.g debhelper version has been changed - willsomeone correct this locked wiki pack to e.g. use compat with 7 ?
[13:15] <benste> and the hello source version has been change from 2.1.1 to 2.5
[13:15] <benste> sorry 2.4
[13:18] <benste> and I'm having problems locating postinst and prerm in the original source directory - may so give me an advise ?
[13:19] <av`> benste, postinst and prerm shouldnt be located into the original source
[13:19] <av`> they care called maintainer scripts
[13:20] <av`> * are
[13:20] <av`> plus I don't think you need them for 'hello' example
[13:28] <benste> av`: I just came across them cause there are mentioned in the guide that they should be in the source which I copyied from archive.ubunt
[13:29] <av`> benste, orig source contains upstream files only
[13:29] <av`> benste, and debian/ dir contains maintainer scripts
[13:30] <av`> if you did a dh_make all maintainer scripts got created
[13:30] <av`> it's now up to you to keep the ones you need and remove the one you don't need
[13:30] <benste> :-) now I now what you wanted to say me:-) - could you take a look at https://wiki.ubuntu.com/PackagingGuide/Basic#postinst%20and%20prerm
[13:31] <benste> av`: in my selfmade /debian dir - maintainer scripts - I already have those
[13:31] <benste> but now I should copy pre and post files but they don't exist
[13:31] <av`> benste, maybe they got removed
[13:31] <benste> possibly, so I can skip them?
[13:31] <benste> - who'll update the wiki page ?
[13:32] <av`> benste, to know that you should have a look at changelog
[13:32] <joaopinto> benste, the documents does not refer to a prristine source dir, it refers to a debian source, which is the original source + building diff
[13:32] <av`> you should see if those files are mentioned and if yes why
[13:33] <benste> joaopinto: what's prristine ?
[13:33] <av`> benste,  * Removed prerm and postinst, as info files are missing now.
[13:33] <av`> benste, they got removed, the info file is no more there, then you can skip them
[13:33] <joaopinto> hum, maybe I was reading it wrong :P
[13:34] <geser> benste: pristine (in this context) = unmodified; as you can download it from the upstream webpage
[13:34] <benste> av`: so may someone be so kind to correct the guide for newbees like me ?
[13:34] <benste> geser: joaopinto - thanks
[13:34] <joaopinto> benste, still, it was refering to copy from a debian source, not from a source
[13:35] <joaopinto> there is no debian/* on a source tarball :)
[13:35] <av`> benste, I dunno who has the rights to change it :)
[13:35] <av`> benste, and that page looks a bit outdated, yes
[13:35] <benste> joaopinto: there is a hello_2.4-debhelper
[13:35] <benste> dir in it which has maintainer scripts
[13:35] <av`> joaopinto, depends
[13:35] <joaopinto> erm, except native packages
[13:35] <av`> joaopinto, upstream may want to include it
[13:35] <joaopinto> which are not usuaul cases
[13:36] <av`> which is way to bad
[13:36] <joaopinto> av`, that is a bad thing to do :P
[13:36] <av`> yep^^
[13:36] <av`> but it happens
[13:36] <benste> so usually it should have the -debhelper dir ?
[13:36] <av`> no
[13:37] <benste> sorry I forogt the not :-)
[13:37] <av`> usually should have nothing debian-related
[13:37] <av`> you should add debian-related stuff in it
[13:37] <av`> it = source tree
[13:37] <benste> to the original source, but also to the one I got through APT ?
[13:37] <joaopinto> benste, hello-debhelper_2.2.orig.tar.gz does not contain debian/*
[13:38] <av`> benste, if you do apt-get source foo
[13:38] <joaopinto> benste, you are looking into a debian source, which is the orig source withe the building diff applied
[13:38] <av`> benste, it will contain debian dir in it, yes
[13:38] <av`> benste, apt-get source downloads orig and applies the diff.gz
[13:38] <benste> av`: thanks
[13:38] <av`> np :)
[13:41] <benste> where will debuild -S look for my PGP key ?
[13:42] <joaopinto> benste, have you set DEBEMAIL ?
[13:42] <av`> benste, it will verify if your secret key is available
[13:42] <joaopinto> it will use the standard gpg sign
[13:43] <benste> joaopinto: I've set it to MYadress+motu@gmail.com
[13:43] <av`> benste, if it fails either set a correct email with DEBEMAIL or use -kKEYID
[13:43] <joaopinto> benste, and did you create the GPG key for it ?
[13:43] <av`> benste, try debuild -S -kYOURKEYIDHERE
[13:43] <walterl> sistpoty|work: thanks for your help :)
[13:43] <benste> joaopinto: I've got a pgpkey for MYadress@gmail.com which includes some sub keys with the +
[13:43] <benste> including a motu one
[13:43] <joaopinto> ok
[13:44] <benste> possibly it can't find my gpg key cause of the sub key ?
[13:44] <benste> I#ll try to search my key from CLI with gpg - usually I use seahorse
[13:45] <av`> benste, yeah, maybe it's unable to use your subkey, I don't know, alwais worked for me as main key
[13:46] <av`> benste, otherwise use the -kKEYID option and you are done
[13:46] <joaopinto> benste, does the email address shows at gpg --list-secret-keys ?
[13:47] <benste> joaopinto: yes it does, including the right commend and name
[13:48] <benste> av`: 91E4A5BE is key id ?
[13:51] <benste> av`: Enter passphrase: gpg: gpg-agent is not available in this session - does this encounter any problems - with keyid it woun't accept my right passphrase
[13:52] <benste> strange 5th try - accepted :-)
[13:55] <benste> av`: - next question I'll read the whole paragraph before asking :-)
[14:08] <jbernard> can someone give me advise about Bug #449349 ? is it right to request a sync at this stage in the release cycle?
[14:15] <joaopinto> jbernard, I would decided that based on what was changed on the debian version
[14:16] <joaopinto> if there are non trivial changes, a specific bug fix patch would be safer
[14:24] <benste> what's wrong with the first paragraph of the following changelog? - http://paste.ubuntu.com/294695/
[14:24] <benste> debuild -S woun't work cause of this
[14:27] <Hobbsee> benste: the fact that it's not built for an ubuntu release?
[14:27] <Hobbsee> (ie, unstable --> karmic)
[14:27] <Hobbsee> i'm assuming, anyway, without the error
[14:33] <benste> Hobbsee: but it worked using unstable with only the lower one
[14:34] <benste> Hobbsee: http://paste.ubuntu.com/294706/
[14:34] <benste> still not working
[14:36] <sistpoty|work> benste: looks like your trailer line is badly formatted? (try dch -i and check the difference between the generated trailer line and yours)
[14:39] <benste> sistpoty|work: I added the upper paragraph so I know the dif - am I allowed to change the changelog manually with nano ?
[14:40] <sistpoty|work> benste: sure, if you're careful
[14:41] <benste> sistpoty|work: I guess I wasn't - I wanted to add a new entry in the exact formatting, with only one point
[14:41] <benste> looks like it didn't work
[14:41] <benste> sistpoty|work: - I changed the revision number, does this take an effect ?P
[14:42] <sistpoty|work> benste: yes, it will change the version.
[14:44] <benste> checked again and looks like ; was missing in header - now working
[14:45] <benste> sistpoty|work: do you know who I can solve this error "Enter passphrase: gpg: gpg-agent is not available in this session" so that I can use debuild without -kKEYID ?
[14:46] <sistpoty|work> benste: you can set DEBSIGN_KEYID in your ~/.devscripts.conf (or /etc/devscripts.conf)
[14:46] <benste> sistpoty|work: not in .bashrc ?
[14:47] <sistpoty|work> benste: it's not an environment variable, but rather a config option of devscripts
[14:49] <benste> can't I simply import my gpg private key or set seahorse as keyring in # A colon separated list of extra keyrings to read.
[14:49] <benste> # DSCVERIFY_KEYRINGS=""
[14:49] <benste> sistpoty|work:
[14:59] <sistpoty|work> benste: why would you want to do this?
[15:04] <benste1> sistpoty|work: for not entering the keys the whole time and auto signing with the key mentioned in the feils ?
[15:04] <benste1> files
[15:04] <sistpoty|work> benste1: how about using a gpg-agent?
[15:05] <benste1> I'm using seahorse, but it looks like there is a problem between seahorse and gpg which ned up not finding my private key
[15:05] <benste1> - but strangely it's listed with gpg --list-private-keys
[15:05] <benste1> or similar
[15:09] <sistpoty|work> benste1: but it does work with -k<keyid>?
[15:09] <sistpoty|work> (using debisgn, i.e)
[15:10] <benste1> sistpoty|work: with -k it works fine
[15:10] <benste1> - with debuild - guess it's the parent app isn't it ?
[15:10] <sistpoty|work> benste1: then you can just set DEBSIGN_KEYID
[15:11] <benste1> and if I want to sign with anotehr key ?
[15:11] <benste1> sistpoty|work: I'll set up your solution looks like it's the easiest atm
[15:12] <sistpoty|work> benste1: I'm not too sure, but I guess that -k<anotherkeyid> will override it then
[15:12] <benste1> simply adding at the first line of /etc/devscripts.cond
[15:12] <benste1> f
[15:12] <benste1> ?
[15:13] <sistpoty|work> benste1: no you have to place it exactly at line 42 :P
[15:13] <sistpoty|work> (just kidding)
[15:14] <benste1> :-)
[15:19] <benste1> sistpoty|work: looks like it worked, strange thing is that I still didn't get a .deb using pbuilder too
[15:19] <benste1> but I'll go on the Guide first , so maybe at the end .. - thanks for helping
[15:19] <av`> benste1, check /var/cache/pbuilder/result
[15:21] <benste1> av`: lol my first deb - why wasn't it copied to the curent dir when building it ?
[15:21] <av`> benste1, cause pbuilder uses that dir as default
[15:22] <av`> benste1, if you give a dpkg-buildpackage you'll find it on the current dir
[15:23] <benste1> av`:  but than it's build withouht fakeroot , on the installed system ?
[15:24] <benste1> strange - there is only rev 1 and not 2
[15:29] <av`> benste1, it's built with fakeroot on installed system as well
[15:29] <av`> if not some targets on debian/rules would fail
[15:30] <av`> benste1, dh_testroot tests if you are running it as fakeroot
[15:30] <av`> if not fails
[16:23] <sistpoty|work> bdrung: imho eclipse failed on the buildds, because only i386 builds the arch:all package
[16:25] <bdrung> sistpoty|work: that's a good point. thx
[16:25] <sistpoty|work> bdrung: I'm not too sure about the actual debian/rules invocation on the buildds, but I think it's binary-arch for non-i386, so common-install-indep might not be executed (?)
[16:27] <geser> it's binary on the i386 and binary-arch on all others (see a build log of your choice)
[16:31] <sistpoty|work> thanks geser
[16:52] <c_korn> eh, if libpurple-dev depends on libpurple0 (>= ${source:Version}) lintian claims: E: pidgin source: weak-library-dev-dependency libpurple-dev on libpurple0 (>= ${source:Version}) ; but if it depends on libpurple0 (= ${source:Version}) lintian __additionally_ claims: E: pidgin source: not-binnmuable-all-depends-any libpurple-dev -> libpurple0
[16:57] <sistpoty|work> c_korn: is libpurple-dev or libpurple0 arch:all?
[16:59] <c_korn> sistpoty|work: libpurple-dev is arch:all
[16:59] <sistpoty|work> c_korn: it should be arch:any, I guess (static library in there?)
[17:00] <sistpoty|work> c_korn: otherwise you'd need binary:Version instead of source:Version
[17:00] <sistpoty|work> (though we don't really have binNMU's here... yet)
[17:02] <c_korn> sistpoty|work: eh, you are right. http://packages.ubuntu.com/karmic/all/libpurple-dev/filelist it has a shared library in it but it is arch:all. this is a bug
[17:03]  * c_korn wonders it has not been detected all these years
[17:03] <joaopinto> libpurple is not that old :P
[17:04] <sistpoty|work> c_korn: I guess that's just the symlink, so it could in theory be arch:all
[17:04] <geser> c_korn: the .so are pretty sure just symlinks to the real lib
[17:04] <sistpoty|work> c_korn: makes me wonder though, why there isn't a static library
[17:05] <geser> why should there? static linking is not really liked
[17:07] <sistpoty|work> it can be useful from time to time, so why deprive users of this ability?
[17:07] <joaopinto> geser, that's not a general purpose "dislike"
[17:08] <c_korn> geser: you are right. they are just symlinks
[17:09] <sistpoty|work> (and the library packaging guide still mentions it, however the guide also still mentions libtool files, which shouldn't be in there any longer)
[17:10] <geser> even libpurple-dev in lenny has no .a file
[17:11] <sistpoty|work> hm, maybe the upstream build system only builds a shared library?
[17:12] <sistpoty|work> anyway it's not like the world ends if there's no static library, it's just a nice to have
[17:12] <ScottK> sistpoty|work: Actually Debian is pushing to have them removed.
[17:12] <sistpoty|work> ScottK: oh? hm... :(
[17:13] <ScottK> There was a thread on debian-devel about it.
[17:21] <c_korn> with libpurple0 (>= ${binary:Version}) the error is: E: pidgin source: weak-library-dev-dependency libpurple-dev on libpurple0 (>= ${binary:Version})
[17:22] <c_korn> with libpurple0 (= ${binary:Version}) the error is: E: pidgin source: not-binnmuable-all-depends-any libpurple-dev -> libpurple0
[17:23] <sistpoty|work> c_korn: oh, yeah, my mistake. arch:all aren't part of a binNMU, so the version of libpurple-dev's dependency isn't increased
[17:25] <c_korn> exactly, how is situation being solved then ?
[17:25] <c_korn> making the -dev arch:any ?
[17:25] <sistpoty|work> yes
[17:26] <sistpoty|work> you could also use = source:Upstream-Version (unless you change a header in a debian revision)
[17:26] <sistpoty|work> c_korn: what do you have in mind btw.? preparing an upload for ubuntu?
[17:27] <c_korn> I am not allowed to do so I think. I just wanted to test the new pidgin release. because ICQ seems to be instable at the moment
[17:28] <sistpoty|work> ah, k
[17:29] <sistpoty|work> (because I don't really think these changes should be introduced for Ubuntu unless coming from debian)
[17:33] <benste1> what's wrong with: http://paste.ubuntu.com/294816/
[17:33] <benste1> ~/.dbut.cf has got http://paste.ubuntu.com/294819/
[17:34] <benste1> put
[17:36] <sistpoty|work> benste1: the colon... dput <where> <changesfile> (no ":")
[17:36] <benste1> LP howTo says  ppa:benste/ppa
[17:37] <benste1> sistpoty|work: yours seem to work
[17:37] <james_w> benste1: you don't need to edit ~/.dput.cf
[17:37] <james_w> you can just type "dput ppa:benste/ppa ..."
[17:37] <james_w> not "test-ppa:..."
[17:38] <benste1> always difficult with those things :-) https://help.launchpad.net/Packaging/PPA/Uploading
[17:38] <benste1> and now it even asks a password I don#t know ROFL -
[17:39] <benste1> james_w: , sistpoty|work: does it take some time after CLI has finished ?  - https://launchpad.net/~benste/+archive/ppa
[17:39] <james_w> yes
[17:40] <james_w> a couple of minutes
[17:40] <benste1> james_w: why doesn't it upload a .DEB file to PPA ?
[17:40] <james_w> because the PPA builds the .deb
[17:41] <benste1> ah that's meant by      A recent upload has resulted in     3     pending builds.
[17:41] <benste1> right ?
[17:42] <benste1> so I don't have to use pbuilder if I'll upload the debuild to PPA ?
[17:43]  * sistpoty|work heads home and is off over the weekend... cya
[17:43] <geser> no, but testing if you package builds in a pbuilder will probably be faster than waiting on the PPA build
[17:44] <benste1> james_w: thanks for helping now I'll try to rebuild those files modify changelog and add a package description :-)
[17:44] <benste1> geser: just noticed that it will be build in 8h - long time :-)
[17:45] <benste1> -> for changing something now I can simply edit the unpacked version, and modify changelog and some other stuff and upload the changes again ?
[17:45] <james_w> you need to build the source package again
[17:45] <james_w> and your modifications of the changelog have to increase the version number
[17:52] <fabrice_sp> james_w, I fixed a package (classpath-common) that was making fail the rebuild of cacao. Is it possible to retry the build of cacao in the test of rebuild or I should upload a build1 version?
[17:52] <james_w> fabrice_sp: I don't think it is possible
[17:54] <fabrice_sp> james_w, ok. So I should just upload a build1 debdiff, to 'delete' it from the FTBFS? Or let it be?
[17:55] <james_w> you know cacao builds now?
[17:55] <james_w> and it builds in the archive?
[17:55] <james_w> built I mean
[17:55] <geser> fabrice_sp: is the FTBFS in the copy archive (rebuild) or main one?
[17:55] <james_w> if so then I would suggest leaving it
[17:56] <fabrice_sp> geser, only in the copy. So I'll leave it. Thanks guys
[17:56] <geser> fabrice_sp: knowing that it would build again (in case we need to) is enough, no reason to get it rebuild
[17:57] <fabrice_sp> crystal clear. Thanks :-)
[18:02] <mne> Hi. I'm running ubuntu 9.04 on x86-32 kernel 2.6.28-6-686 and noticed that all programs (so far) have a non executable heap although there is no NX support in the kernel ? How is this possible ? For vulnerability research I would like to temporarily set the execute permission for the heap segment of a binary. How can I do this ?
[18:02] <benste1> If I would start a very big package (>1gb) what could I do to expand PPA space ?
[18:02] <av`> benste1, I've never heard of a package bigger than 1 gb
[18:03] <ScottK> benste1: Ask on #launchpad
[18:03] <benste1> thanks
[18:03] <av`> benste1, anyway you should fillout a question against launchpad asking why you need more space
[18:03] <av`> e.g you need a good rationale
[18:03] <mne> does apparmour or selinux set the heap to non-executable ?
[18:04] <ScottK> av`: They exist, but aren't in the official archive due to the effect on mirrors.  The largest I've heard of in Ubuntu was around 750mb
[18:04] <av`> ScottK, they really exist? bigger than 1 gb?
[18:04] <ScottK> mne: You should probably ask in #ubuntu-hardened
[18:04] <ScottK> av`: Yes.
[18:04] <av`> I guess that building one of them would make me crying
[18:04] <benste1> av`: atm I'm still learning on how to build packages but I just thought if there would be a big game, e.g. WOW comes with ~ 10 Gb in Windows installation now - but you're right, simply asking to expand ro create a group with a bigger PPA would be the smartest way.
[18:04] <mne> ScottK, thanks, I'll do so
[18:06] <benste1> av`: ScottK - I'm sure I'll choose to go to local uniersity If I'll ever be in the situation to build something big - you know about the IBM servers at FH-Aachen (at campus Jülich) in germany?
[18:07] <av`> benste1, I don't think someone will ever make WOW package :)
[18:07] <joaopinto> benste1, WOW ? You can't upload non free games into a PPA
[18:07] <benste1> .-)
[18:07] <benste1> was just an example as my brother is playing it atm in ubuntu with wine
[18:07] <benste1> beside some teamspeak PA errors all is better than in windows :-)
[18:08] <benste1> back to topic, my pacakge has bee rejected from PPA :-)
[18:08] <benste1> if the old version number is 2.4.1 and the new is 2.4.0ubuntu2 he nodes the 0 ? or the 2 ?
[18:08] <benste1> does I have to use 2.4.1ubuntu2 ?
[18:09] <benste1> av`:  ?
[18:10] <av`> benste1, how can the new version be lower than the old one?
[18:11] <av`> 2.4.1 old 2.4.0 new
[18:11] <benste1> but new ist 2.4.0ubuntu2
[18:11] <benste1> o lats number is 2 I thought
[18:11] <av`> 2.4.0ubuntu2 is wrong
[18:11] <benste1> why ?
[18:12] <benste1> it's explained to use so which would be <deb revision version>ubuntu<ubuntu revision version>
[18:12] <av`> there is no debian revision there
[18:12] <av`> 2.4.0 is upstream
[18:12] <av`> debian is missing
[18:12] <benste1> ?
[18:12] <benste1> in my PPA ?
[18:13] <av`> benste1, please tell me the upstream revision
[18:13] <av`> the debian revision
[18:13] <av`> and I make you the ubuntu one
[18:13] <av`> if I lack to know upstream and debian revision I can't help you
[18:14] <benste1> normally it should be for me 0 debian and 2 ubuntu
[18:14] <benste1> - 2 ubuntu cause it's my 2nd
[18:14] <benste1> (for ubutnu)
[18:14] <benste1> ~ of course not for real yet
[18:15] <av`> please give me some details about the package you're working on
[18:15] <benste1> it's the Test hello package from gnu
[18:15] <benste1> https://wiki.ubuntu.com/PackagingGuide/Basic
[18:15] <benste1> but it's my own attemp to change it
[18:17] <benste1> av`: ?
[18:17] <av`> benste1, upstream revision is 2.4
[18:18] <av`> our ubuntu revision will be 2.4-0ubuntu1
[18:18] <av`> next will be 2.4-0ubuntu2
[18:18] <benste1> yes
[18:18] <av`> and next is 2.4-0ubuntux
[18:18] <av`> etc
[18:18] <benste1> but the problem is that I named the first one 1 withouht ubunut
[18:18] <av`> 2.4-1?
[18:18] <benste1> and the 0ubuntu2 is now regretted
[18:18] <benste1> yip
[18:19] <benste1> https://launchpad.net/~benste/+archive/ppa/+packages
[18:19] <av`> well, 2.4-1 is how debian do versioning
[18:19] <av`> that way ubuntu will be 2.4-1ubuntu1
[18:19] <av`> and if you upload another revision in ubuntu you bump ubuntuX
[18:19] <benste1> ah k I'll try that so 1ubuntu1 > 0
[18:19] <benste1> and > 1
[18:19] <av`> X should be >= 1
[18:20] <benste1> and next correction will be 1ubuntu3
[18:20] <av`> 1-2-3 etc...
[18:22] <benste1> av`: so let's see it's uploading
[18:22] <benste1> and I possibly understood the basics after a whole day  :-)
[18:23] <fabrice_sp> porthose, ping
[18:24] <av`> benste1, it's good to attach something like ~ppa1 to PPA packages
[18:24] <av`> benste1, so 2.4-0ubuntu1~ppa1
[18:24] <benste1> during changelog ?
[18:24] <av`> or 2.4-0ubuntu1~benste1 or whatever
[18:25] <av`> in changelog yes
[18:25] <av`> that's where versioning happens
[18:25] <benste1> and then counting my own versioning
[18:25] <av`> yep
[18:25] <av`> so your PPA has its own versioning
[18:25] <av`> which is different from the archive one
[18:25] <benste1> that's a smart idea not to confuse  the original ubuntu package to mine
[18:26] <av`> so you can keep track of the packages you uploaded on yoour PPA without bothering to change ubuntu or debian versioning
[18:26] <av`> exactly
[18:26] <av`> you upload to a PPA so you should use a PPA-like versioning
[18:26] <benste1> :-)
[18:26] <av`> it's recommended not a must
[18:28] <benste1> thank you very much for helping me the whole day, hopefully I'll come back tomorrow or next week asking for a real package to learn on.
[18:28] <benste1> cya
[18:29] <av`> np
[18:29] <av`> have a good day
[20:21] <benste> how can I apply the build from source strategy on a package of files, e.g. Backgrounds ?
[20:23] <joaopinto> benste, you build a source tarball with the backgrounds
[20:34] <benste> joaopinto: so I should better google around how to build a source tarball ?
[20:37] <benste> thanks
[20:37] <benste> sag einfach kurz bescheid wenn dein key mit dem inet synchronisiert ist,
[20:37] <benste> - sorry wrong tab in pidgin :-)
[20:46] <joaopinto> benste, you need to learn how to create a .tar.gz archive
[20:47] <benste> joaopinto: any advises on where to look - usually I would just right click in nautilus and create archive, but I#am sure this woun't be enough for thi case :-)
[20:47] <benste> since today I#ll use "tar cfz" ;-)
[20:47] <joaopinto> well, that will your but shuld learn to use tar :P
[20:47] <joaopinto> should
[20:50] <benste> joaopinto: is there any kind of documnetary on what has to be in the archive to see it as a source code ?
[20:54] <joaopinto> benste, on your case because you are packaging backgrouns, is not source code
[20:54] <joaopinto> and there is nothing special about a source code archive, is just an archive containg source
[20:54] <joaopinto> anyway if you are building a package from scratch you can just use the --createorig option for dh_make from the "source" directory
[20:55] <benste> joaopinto: - you're kidding - for me source of some jpeg files would only be a folder of jpeg files, but I sure here it will need a kind of installation script to move those image to the right place ?
[20:56] <ari-tczew> hello
[20:57] <joaopinto> benste, you mentioned "source code", which is different from "source"
[20:57] <joaopinto> benste, no, you just need the files listed on the debian/install, and call dh_install on the building rules
[20:58] <joaopinto> benste, if you are learning one approach is to just grab the source for an existing package with a similar purpose
[20:58] <joaopinto> so that you look how it works
[20:59] <joaopinto> apt-get source some wallpapers pacakge and look at the contents
[20:59] <joaopinto> hello ari-tczew
[20:59] <benste> joaopinto: nice idea :-) forgot about this
[21:00] <joaopinto> benste, the core files you will want to look are debian/control and debian/rules
[21:02] <fabrice_sp> Hello ari-tczew
[21:03] <ari-tczew> developers, please answer what about lm-sensors for karmic? bug exist for jaunty, now karmic, lucid?... bug #336418
[21:07] <joaopinto> isn't a bit late to handle merge requests ?
[21:11] <geser> not if it fixes important bugs
[21:11] <ari-tczew> date request: 2009-03-01
[21:13] <ari-tczew> comment #11 by Stevenk
[21:13] <ari-tczew> You've now had four archive admins touch this bug, please stop changing the status without doing any of the work that has been requested.
[21:13] <ari-tczew> 2 months ago
[21:28] <lamalex> Can anyone tell me (or point me to the doc that does) how to modify debian/rules to pass arguments to configure?
[22:05] <geser> does the package use debhelper or cdbs?
[22:40] <joaopinto> lamalex, ^ does the package use debhelper or cdbs?
[22:43] <lamalex> joaopinto: i figured it out
[22:43] <lamalex> thank you though
[22:43] <ari-tczew> what I need to have done if I want to join ~MOTU?
[22:53] <joaopinto> ari-tczew, you should start by getting familiar with the ubuntu wiki, https://wiki.ubuntu.com/MOTU
[22:53] <geser> read https://wiki.ubuntu.com/UbuntuDevelopers and let your contributions get sponsored. if you gathered enough experience and your sponsors support you, you can apply
[23:55] <jdong> /usr/bin/pdebuild: line 39: /dev/fd/62: No such file or directory
[23:55] <jdong> *scratches head*
[23:58] <jdong>     exec > >(tee "${PBUILDER_BUILD_LOGFILE}");