[00:10] <TheMuso> slangasek: Ok so I am working on the separate libpulsedsp package for pulse, however it turns out that pulseaudio-utils has lintian overrides for libpulsedsp.so. How can these effectively be used in the case of a multi-arch same package like libpulsedsp?
[00:19] <slangasek> TheMuso: you can use a wildcard for the path, so */libpulsedsp.so in the libpulsedsp package
[00:20] <TheMuso> slangasek: Thats not what I was thinking of. I am aware of the wildcard, but the override file is owned by both the amd64 and i386 version of the package... How does that get resolved?
[00:21] <slangasek> TheMuso: as long as the file contents are the same, the file is shared
[00:22] <TheMuso> slangasek: Oh ok great.
[01:08] <TheMuso> Anybody else on oneiric using sbuild and schroot for precise finding that dbus is starting in their chroot for any packages depending on dbus?
[01:12] <broder> ooh, does that mean that upstart chroot support is working now?
[01:15] <TheMuso> I don't know.
[01:15] <TheMuso> But I earlier found that I still had lots of chroots mounted, because they had running processes in them.
[01:16] <broder> hmm...so schroot tries to kill off all processes in the chroot before unmounting it
[01:16] <broder> but /etc/init/dbus.conf has respawn
[01:17] <TheMuso> Haven't looked into it, but that sounds possible.
[01:19] <broder> does your chroot have a /usr/sbin/policy-rc.d file?
[01:25] <TheMuso> just a sec, I'll check.
[01:27] <TheMuso> I don't appear to.
[01:27] <broder> you probably want one
[01:27] <broder> something like "#!/bin/sh\nexit 101"
[01:27] <broder> and chmod +x it
[01:28] <TheMuso> Oh ok.
[01:28] <TheMuso> Thanks
[01:28] <broder> (see also the invoke-rc.d manpage)
[01:29] <broder> mk-sbuild should handle all of that setup, though, for future reference
[01:30] <TheMuso> I find mk-sbuild a bit too generic for my needs, so I've got scripts that derive from it. I'll just extend them. :)
[01:49] <Laibsch> good morning
[01:49] <Laibsch> does the verification-done-lucid tag also trigger the "green" state in http://people.canonical.com/~ubuntu-archive/pending-sru.html?
[01:50] <RAOF> I believe the answer to that is ?yes?.
[02:07] <Laibsch> OK.  I set it on a bug about 17-18 hours ago, but it did not trigger anything so far.
[03:48] <pitti> Good morning
[03:50] <ajmitch> morning pitti
[05:16] <slangasek> TheMuso, broder: yes, chroot support works in upstart now, and policy-rc.d is the right workaround for a build chroot :)
[05:27] <micahg> TheMuso: can you extend the core-dev membership in ubuntu-audio-dev
[05:29] <TheMuso> micahg: sure
[05:30] <TheMuso> micahg: For what reason?
[05:31] <TheMuso> In any case, it should never expire, so changing.
[05:33] <micahg> TheMuso: because I got a nice e-mail asking to have it extended :), thanks for the permanent membership :)
[07:01] <dholbach> Guten Morgen Berlin! :)
[07:04] <gs_> hello all. I am doing a project in which I need to read .deb files. Is there any library or interface available which I can use in my program to read these files. If this is a wrong channel Please forgive me and if you could suggest me some other channel for query regarding apt ?
[07:04] <gs_> hello all. I am doing a project in which I need to read .deb files. Is there any library or interface available which I can use in my program to read these files. If this is a wrong channel Please forgive me and if you could suggest me some other channel for query regarding apt ?
[07:04] <gs_> Please reply
[07:06] <dholbach> gs_, which information do you need?
[07:07] <RAOF> gs_:  You'd be looking for libapt and friends.  Or just extracting them; they're simple archives.
[07:07] <StevenK> gs_: If you're an Ubuntu machine, 'man 5 deb' tells you about .deb files
[07:07] <StevenK> If you're *on* an Ubuntu machine
[07:10] <RAOF> Or if you *are* an Ubuntu machine that would work, too.  (If you *are* an Ubuntu machine, awesome!  Please tell us where the AI research has succeeded ?)
[07:11] <ajmitch> heh
[07:11] <gs_> dholbach: I need information regarding some library or interface which can be used for reading debian files
[07:12] <gs_> Actually I am writing a system restore like application for ubuntu
[07:12] <gs_> which will save the current state of packages and then restore them when needed
[07:14] <gs_> RAOF: ok. using these libraries I can get list of the files which a package is intending to install ? and If i need details about the contents of those files then ?
[07:14] <dholbach> gs_, sorry, I meant: which information in the packages are you after?
[07:14] <RAOF> gs_: Probably, but I wouldn't do it that way; I'd just expand the .deb and list the files in the data.tar.*
[07:14] <gs_> dholbach: I am looking for list of files in the package and their contents so that I can determine what changes have occur to the system
[07:15] <gs_> RAOF: so we can convert .deb file in tar.gz archive ?
[07:15] <RAOF> gs_: Note that what you want to do is impossible in general; the packaging can (and will in some circumstances) use programatic means to create or modify files on the filesystem.
[07:15] <ajmitch> also the original .deb may not be on the system still
[07:15] <RAOF> gs_: The .deb file contains two .tar.* files; control and data.
[07:16] <Chipzz> RAOF: md5sums?
[07:16] <ajmitch> iirc not every package has a list of md5sums
[07:16] <Chipzz> RAOF: this isn't very ingrained in debian, but IIRC in rpm based distro's ALL files have their md5sum stored
[07:17] <gs_> RAOF: like when we open a deb file in gdeb we can get the list of all files so I thought there might be an existing library for doing that
[07:17] <Chipzz> ajmitch: yes and that's a defect imo
[07:17] <RAOF> gs_: Yes, there is; tar.
[07:17] <RAOF> Chipzz: Does the rpm packaging format not have a way of generating files at install time?
[07:17] <Chipzz> ajmitch: regardless, merely pointing out that RAOF's statement is incorrect and it is possible in theory
[07:18] <Chipzz> RAOF: at does; it also has the concept of ghost files which debian lacks
[07:18] <gs_> OK. So there is a tar and then how will I read that tar ? After extracting it ?
[07:18] <Chipzz> s/debian/dpkg/
[07:18] <gs_> Ya I know the package file might not be on the system. In that case I think I would need to download the package file from internet ?
[07:18] <RAOF> Chipzz: No, it's not possible in theory.  I've worked on packages whose postinsts process existing files on the filesystem and incorporate state from other files, then write out a new conf file.
[07:19] <RAOF> Chipzz: That package cannot have a pregenerated md5sum for all the files it generates.
[07:19] <ajmitch> gs_: in terms of libraries, I know of python-debian which you can use to inspect the contents of a .deb
[07:19] <Chipzz> RAOF: that statement is simply silly; you can't account for /home/* either
[07:20] <gs_> ajmitch: Could you please give me some link related to that library ?
[07:20] <RAOF> Chipzz: True, but that's not owned by the package manager.
[07:20] <Chipzz> RAOF: you could argue that config files aren't either
[07:20] <gs_> Could you please provide me some suggestions regarding how to implement a system restore like application for ubuntu
[07:21] <gs_> I have two approaches
[07:21] <gs_> in one approach I will use a copy-on-write and save-on-delete approach
[07:21] <gs_> so that I will take care of all the files in system directories
[07:21] <ajmitch> gs_: I'd have to look on google for info about it, but the package is just named 'python-debian', I don't know what is available as a library for other languages
[07:22] <RAOF> If you're allowed to use magical filesystems, then btrfs + apt-snapshot-btrfs does all this for you; it takes a snapshot of the system state on each apt transaction that you can roll back to.
[07:22] <gs_> ajmitch: ok I will search for that thanks for helping.
[07:23] <gs_> ok thats quite nice, how much space would that system occupy ?
[07:23] <gs_> But that would require user to reinstall the whole system with "/" on brtfs ?
[07:24] <RAOF> It's copy-on-write, so roughly the changed set size.
[07:24] <RAOF> It would indeed require / to be a btrfs partition.  It also has other constraints (there need to be appropriately named subvolumes, home needs to be a subvolume)
[07:25] <gs_> ok, that would be not good as users need a reinstall for using the system
[07:25] <gs_> If I implement that approach in my program would that be possible
[07:25] <gs_> I can put hooks to the filesystem
[07:26] <gs_> so whenever a file is written I can make a copy
[07:27] <gs_> Or I can have this package approach
[07:28] <gs_> in this approach I will create a package whenever user creates a restore point
[07:28] <gs_> I will use this package to restore the system to an earlier state
[07:28] <ajmitch> if you're looking at creating a package, take a look at dpkg-repack
[07:29] <gs_> Ok thanks and could you please provide some feedback on my approach
[07:29] <RAOF> I suspect it might be easier to do something similar to a combination of etckeeper and oneconf+snapshotting.
[07:30] <RAOF> ie: store a list of all the packages which are installed + all the modified stuff (/etc /var)
[07:32] <gs_> RAOF : ok, like these files are in /var/lib/dpkg/info
[07:32] <gs_> ?
[07:32] <gs_> now for the modified stuff /etc /var is it better to create a separate package or implement a copy-on-write approach?
[07:33] <Chipzz> gs_: imo your approach is not the best approach anyway
[07:33] <Chipzz> files in /usr aren't interesting anyway
[07:33] <micahg> slangasek: you made a change to pygments back in jaunty that suggested python-chardet shouldn't be a recommends: https://launchpad.net/ubuntu/+source/pygments/0.10-1ubuntu2, python-chardet is now in main, do you still feel it shouldn't be a recommends?
[07:34] <Chipzz> if those change, the change is probably invalid, and you probably want to restore from the package anyway, so you probably shouldn't care about these
[07:34] <gs_> chipzz : So please could you provide me some suggestions in how can I improve this
[07:34] <slangasek> micahg: I feel nothing about it, do whatever you think is best ;)
[07:34] <micahg> slangasek: thanks :)
[07:34] <Chipzz> you probably want to focus on config files, and maybe files in /var
[07:35] <Chipzz> I would look into ucf and try to integrate with that
[07:35] <gs_> ok so files in /var are more imprtant and /etc also
[07:35] <Chipzz> and figure something out for other files in /etc that aren't managed by ucf
[07:36]  * ajmitch rather likes etckeeper
[07:36] <gs_> sorry but what is ucf ?
[07:36] <Chipzz> dpkg --get-selections will give you a list of packages installed
[07:36] <Chipzz> apt-cache show ucf?
[07:37] <Chipzz> /srv, /usr/local and /opt are interesting candidates too
[07:37] <gs_> ok thats easier
[07:38] <gs_> but like if some of the files installed by a package are damaged then ? Do I need to recopy those files or reinstalling the package would be a better option ?
[07:39] <Chipzz> users aren't supposed to write in /usr, since that's owned by the package management system; if they do, they're probably wrong, for example they have compiled from source and installed in /usr, which is a cause of havoc anyway, and most likely the kind of situation you want to recover FROM, not TO
[07:39] <Chipzz> gs_: like I pointed out, if those files are damaged, you can restore them from the package; which is exactly why they are not interesting
[07:41] <gs_> Ok so I would ignore the files present in /usr
[07:41] <gs_> or better I could clear /usr to a fresh installed system state
[07:42] <gs_> and if the files in /bin or /sbin are damaged then ?
[07:42] <gs_> I would get a list of installed packages and then reinstall those packages ?
[07:42] <gs_> Better I need to see which packages have missing files
[07:43] <gs_> and so those only *system packages* need to be downloaded and reinstalled ?
[07:48] <gs_> Also is there any documentation describing exact steps performed by the system when any package is installed ?
[07:48] <gs_> or I could  see that by browsing apt-get or dpkg code ?
[08:57] <fhd> How is the Ubuntu stance towards Vala? Good idea for apps primary targeting Ubuntu?
[08:58] <fhd> Don't want to alienate. The typical choices seem to be C++ or Python.
[09:16] <cjwatson> fhd: well, it's listed on developer.u.c - http://developer.ubuntu.com/resources/programming-languages/vala/
[09:17] <cjwatson> fhd: I believe Unity lenses are typically written in Vala, for example
[09:24] <fhd> cjwatson: Java is also listed, haven't seen many Java apps in Ubuntu
[09:25] <fhd> cjwatson: But if the Unity guys use it...
[09:45] <cjwatson> fhd: it depends where you look
[10:41] <Daviey> I can't understand why ruby-stomp has seeminly never been in Ubuntu.  Is it blacklisted?
[10:42] <Daviey> https://launchpad.net/ubuntu/+source/ruby-stomp , no publishing history
[10:42] <Daviey> Been in sid since Jan 2009
[10:44] <geser> Daviey: https://launchpad.net/ubuntu/+source/libstomp-ruby ; the source package got recently (this month) renamed from libstomp-ruby to ruby-stomp
[10:44] <cjwatson> Daviey: it's not blacklisted, but attempting to sync it says http://paste.ubuntu.com/720566/
[10:45] <cjwatson> we have what might politely be called an abysmal lack of crowdsourcing for this kind of thing
[10:45] <cjwatson> so basically somebody needs to say "yes, dear archive admins, please throw away the existing Ubuntu-specific package and replace it with this one with a different source package name from Debian"
[10:46] <cjwatson> well, not Ubuntu-specific, Ubuntu-modified
[10:47] <Daviey> cjwatson: it needs AA intervention, or can i just sync with --force?
[10:48] <Daviey> (geser: thanks)
[10:48] <cjwatson> Daviey: you can syncpackage it if you've checked that none of the Ubuntu modifications are still needed
[10:48] <cjwatson> (although it'll land in the NEW queue, but that's trivial)
[10:49] <Daviey> cjwatson: Great, thought so - thanks
[10:49] <cjwatson> it wasn't just an upstream update, James made some packaging changes too
[10:50] <Daviey> Yeah, seems i sponsored it :)
[10:51] <cjwatson> unfortunately I'm not sure syncpackage notices the Ubuntu modifications to matching binary packages
[10:51] <cjwatson> which is IMO a syncpackage bug if true
[10:52] <cjwatson> yeah, doesn't require --force, buggily
[10:54] <Daviey> Thanks.
[10:55] <\sh> hmm...anybody with upload powers can use syncpackage now? (instead of using requestsync)
[10:56] <Daviey> \sh: Yes, but requestsync is still needed for sponsored sync's
[10:57] <\sh> Daviey, sure, what I mean is i.e. for universe uploaders who are doing the merge/sync  run now
[10:57] <Daviey> \sh: yup
[10:57] <\sh> Daviey, nice :)
[10:58] <Daviey> \sh: $ syncpackage -d (wheezy|sid) -r precise foobar
[10:58] <cjwatson> we should update docs and stuff
[10:58] <cjwatson> there are still some limitations, e.g. not usable for sponsored syncs
[10:59] <Daviey> and no karma.. "oh well"
[11:00] <\sh> Daviey, no need to sign ? or does it do it automagically?
[11:01] <cjwatson> no need to sign
[11:01] <cjwatson> it doesn't sign, it copies the publishing record from Debian
[11:03] <Daviey> Incidently there is the 'beta' webui method, https://launchpad.net/ubuntu/precise/+localpackagediffs .. a bit whizzy for some.
[11:05] <\sh> let's try :)
[11:06] <\sh> so I need --force to overwrite ubuntu modifications
[11:13] <\sh> cjwatson, what does this mean: syncpackage: Source package gauche-c-wrapper is blacklisted.
[11:14] <cjwatson> an obscure way of saying that it has Ubuntu modifications which need to be reviewed.  Use --force
[11:15] <cjwatson> Daviey: please don't use or recommend that - it doesn't and can't apply Ubuntu-specific policy
[11:15] <cjwatson> (well, s/can't/won't/ perhaps)
[11:15] <Daviey> cjwatson: wow, it doesn't do ACL?
[11:15] <cjwatson> there is more policy than ACL
[11:15] <cjwatson> it can't do things like handling packages with Ubuntu-specific modifications with more care
[11:16] <cjwatson> use the API tool and pretend the UI doesn't exist
[11:17] <Daviey> cjwatson: You mean it doesn't give a warning to say, "Are you sure you want to overwrite ubuntu changes?"
[11:17] <cjwatson> no
[11:18] <cjwatson> essentially because the way to detect that isn't particularly consistent across derivative distributions and Launchpad officially doesn't know about it
[11:20] <Daviey> Does syncpackage care greater than checking for 'ubuntu' in the version string?
[11:20] <cjwatson> that's what it does, but Launchpad doesn't do that
[11:21] <cjwatson> in general we can do much more sophisticated things using an API tool because we don't have to make them fully general for all derivative distributions
[11:22] <cjwatson> (+localpackagediffs was designed principally for Ubuntu derivatives and requested by Linaro, not for us)
[11:22] <cjwatson> oh, syncpackage also detects fakesync-requiring situations, I don't think +localpackagediffs does (or if it is it's less helpful about it)
[11:23] <cjwatson> and syncpackage allows you to sync from suites other than the single nominated "derivative parent" suite (currently Debian testing)
[11:23] <cjwatson> and deals with closing bugs which I don't think +localpackagediffs currently does
[11:23] <cjwatson> etc.
[11:24] <Laney> think it got that one
[11:24] <Laney> well, you can't nominate an additional bug
[11:24] <cjwatson> could be
[11:25] <TLE> pitti: hey, we saw some lang packs in -proposed, are they all good to go?
[11:27] <pitti> TLE: good for testing, anyway, yes
[11:27] <pitti> German looks fine
[11:27] <TLE> pitti: great, thanks
[11:35] <SpamapS> slangasek: re bug 859075 , I have laid no claim to it, though I do think its something wrong with the order in which we bring down the network and unmount things.
[12:16] <doko> pitti, bdmurray: why do we still get reports like https://bugs.launchpad.net/ubuntu/+bug/882445?
[12:16] <pitti> we can write a pattern for it, to avoid further reports
[12:17] <pitti> I'm fairly sure I've seen that --fsys-tarfile bug somewhere
[12:18] <pitti> let's take bug 773172
[12:21] <pitti> doko: added bug pattern, closed as dupe
[12:24] <doko> pitti, thanks
[12:35] <zyga> did postgresql change the default listen port for 9.1?
[12:36] <zyga> it was 5432 and now I can see 5433
[12:36] <pitti> zyga: no; presumably you still have an 8.4 cluster around which is on 5432; check pg_lsclusters
[12:36] <zyga> ah
[12:36] <zyga> pitti, so after having both installed I need to tweak something to get the default port back
[12:37] <zyga> yeah, I have 5433 used now, I removed my 8.4 cluster earlier today
[12:37] <zyga> thanks
[13:38] <Daviey> Anyone know of a prior example of an SRU introducing a new src package?
[13:38] <Daviey> (as a dep)
[13:38] <Daviey> Or rather, the SRU requiring a new source package which is a dep.
[13:42] <SpamapS> Daviey: meaning the src package would effectively be "NEW" for -proposed ?
[13:43] <Daviey> SpamapS: yes sir
[13:50] <tumbleweed> talking of this, can an AA process bin-NEW for my botan1.8 SRU?
[13:54] <geser> Daviey: I guess you would need a good rationale for this
[13:54] <Daviey> geser: that some upstreams are really bad at following their own policy? :)
[13:55] <Daviey> right, soren? :)
[14:00] <SpamapS> Daviey: how big is this new dependency? Might it work embedded in the source?
[14:01] <soren> SpamapS: I dont' see how that would be preferable.
[14:01] <SpamapS> soren: if its a 1 file python module or something that is better.
[14:01] <soren> Daviey: We have had kernels come in this way. Backported kernels from newer releases back to the most recent LTS.
[14:03] <Daviey> SpamapS: yeah, checked that.. it's not just one .py
[14:03] <Daviey> SpamapS: but embedding a whole module, need to start worrying about upgrade paths.
[14:04] <soren> SpamapS: Even then, it seems questionable.
[14:04] <soren> Precise will have it in a separate package. That's what we'll test.
[14:04] <soren> Right?
[14:04] <soren> And once validated, will backport to Oneiric.
[14:06] <soren> I'm just not sure I think breaking two rules (embedding "foreign" libraries in other source packages + not staying close to how you're solving the same problem in the dev release) is necessarily better than breaking something that isn't even a rule, AFAICT (uploading new source packages to -proposed).
[14:09] <cjwatson> yeah, I'm not aware of a rule against new source packages in -proposed; it's certainly unconventional but not forbidden TTBOMK
[14:10] <cjwatson> if the purpose of the fix meets the SRU rules, then I wouldn't exclude it simply on the basis of requiring a new package
[14:10] <cjwatson> although it would have to have a good reason
[14:10] <soren> Yeah.
[14:11] <soren> ...and avoiding embedding it in the source package that depends on it isn't that good a reason, IMO.
[14:12] <soren> Didn't the openss{l,h} blacklist stuff come in its own source package?
[14:12] <cjwatson> yes
[14:12] <cjwatson> albeit through -security not -proposed, but whatever
[14:13] <soren> Yeah, but that usually has a higher barrier of entry, not lower.
[14:13] <soren> Anyway, I think we agree :)
[14:36] <slangasek> SpamapS: well, a) one of the commentors is having the problem with USB disks, not network mounts, b) we've been through all this before with network-manager being killed before umountnfs.sh and that's been fixed - so if something's regressed I think it's on the NM side of the equaton
[15:09] <Wismon> Hi, I'm new to Ubuntu development (bug fixing) and fixed a bug the other day, uploaded my branch to Bazaar and made a merge request. I'm just wondering what the next logical step would be? I read about the sponsoring process but have to admit I don't really get how it works in reality. I just don't know if I should simply wait for now or if there's something more I should do. Maybe someone more knowledgeable than m
[15:09] <Wismon> e can point me in the right direction?
[15:09] <Wismon> </wall of text>
[15:10] <SpamapS> slangasek: I do think that eventually we'll find the problem outside of sysvinit. I have it assigned to sysvinit because thats where the debugging has led the investigation thus far
[15:10] <slangasek> SpamapS: ok
[15:11] <Riddell> Wismon: is the package has a likely team or person who might upload it you can politely ping them
[15:16] <Wismon> Riddell: Hmm, I think I found one person... Thank you, I'll try that!
[16:08] <kirkland> mterry: hiya
[16:08] <mterry> kirkland, hi!
[16:08] <kirkland> mterry: fyi, ecryptfs-verify-private just landed in precise
[16:08] <mterry> kirkland, oh, that didn't get into oneiric?
[16:08] <kirkland> mterry: nope, sorry
[16:09] <mterry> hmm
[16:09] <kirkland> mterry: needed an FFE
[16:09] <kirkland> mterry: i never filed it, don't know if anyone else did either
[16:09] <kirkland> mterry: was it you who was asking for this?
[16:09] <kirkland> mterry: or someone else?  seb maybe?
[16:10] <mterry> that means it's probably easy to break your system in oneiric by enabling autologin (the patch I added to gnome-control-center used verify-private if available)
[17:33] <barry> @pilot in
[17:38] <smoser> am i the only one having problems ssh to bazaar.launchpad.net ?
[17:39] <smoser> (ie, i can't push a branch)
[17:39] <smoser> $ ssh bazaar.launchpad.net
[17:39] <smoser> ssh_exchange_identification: Connection closed by remote host
[17:41] <jelmer> smoser: it appears to be fine here ("No shells on this server.")
[17:41] <smoser> carp.
[17:41] <smoser> it doesn't like me from 2 different systems (same key/user, but its not just my laptop thats foobarred)
[17:41]  * micahg hugs barry for the mail to UDD
[17:42]  * barry is glad he remembered!
[17:45] <Daviey> smoser: odd, i am getting the same.. I used to get No shells on this server.
[17:45] <Daviey> dave@voodoo:/tmp/test$ bzr push lp:~davewalker/+junk/delete_me
[17:45] <Daviey> Created new branch.
[17:45] <Daviey> dave@voodoo:/tmp/test$ ssh davewalker@bazaar.launchpad.net
[17:45] <Daviey> ssh_exchange_identification: Connection closed by remote host
[17:45] <smoser> others in #launchpad  are echoing my issues.
[17:46] <Daviey> smoser: but push seemed to work
[17:46] <smoser> it was refusing 30 seconds ago
[17:46] <smoser> but now seems good.
[21:19] <rbasak> slangasek: I was just looking at bug 881579 and noticed that you did a merge today, but the bug is still present. It's a missing '\' in debian/samba.if-up
[21:19] <rbasak> slangasek: I was going to fix it but if you're working on it anyway...
[21:31] <slangasek> rbasak: hah, fail.  Sorry for not noticing that.  Feel free to fix, I've moved on to other things already
[21:31] <rbasak> slangasek: well I'm going to need you to sponsor it anyway... :)
[21:45] <slangasek> rbasak: ok, pushing
[21:46] <rbasak> slangasek: thanks!
[22:02] <TheMuso> @pilot in