[00:08] <psusi> is there a way to have apt-get force version to a specific distro for all packages?  I seem to have accidentally gotten a number of natty package versions installed under maverick and need to downgrade them back to the maverick versions
[00:16] <ari-tczew> psusi: rmadison
[00:16] <crimsun> psusi: yes, apt_preferences(5); see apt-pinning
[00:17] <psusi> ari-tczew, don't see what that has to do with my situation
[00:18] <psusi> crimsun, the thing is, I added natty as a source, and set my preferences file to default to maverick to prevent any natty packages from being installed without an explicit -t natty.. but while apt obeyed, it seems the gui update manager did not
[00:18] <psusi> and now I have a number of packages installed from natty.... I can use synaptic to force version on each of them back to maverick, but there are a lot so that will take a long time doing one at a time
[00:18] <psusi> hoping I can do them all at once from the command line
[00:23] <crimsun> ari-tczew: if that's cecilia is valid, then yes
[00:25] <ari-tczew> crimsun: how can I check whether cecilia is valid? do you mean run command from /usr/bin?
[00:26] <crimsun> psusi: are you using pin priorities?  Use something > 1000 for maverick.
[00:26] <crimsun> ari-tczew: no, I assumed you knew what mimetype to use.
[00:31] <psusi> crimsun, I set Apt::Default-Release: to maverick then added the natty repos to sources... that seemed to prevent update to natty packages when I ran apt-get update && apt-get upgrade, but then I started getting updates from the update-manager and noticed today I have natty versions of a bunch of packages installed
[01:14] <paissad_> guys, i'm confused about some postrm, postinst, prerm ... actually i have this message "Warning: pms-linux is NOT running !" which is in the /etc/init.d/pms-linux script  ( and i got the message during the run of -> apt-get remove pms-linux)
[01:14] <paissad_> does this mean that 'apt-get' try to stop init.d scripts before removing packages ?
[01:17] <paissad_> but the thing that bother me the most is that when i run "apt-get install pms-linux" ... i have "Warning: pms-linux is already running !"
[01:17] <paissad_> that looks like "apt-get" tried to start twice the init.d script !
[01:17] <paissad_> i don't understand the reason why it try twice !
[01:17] <paissad_> it tries*
[01:29] <paissad_> nobody knows ?
[02:50] <crimsun> paissad_: you should read the contents of those maintainer scripts to see how invoke-rc.d is used
[13:11] <BlackZ> bilalakhtar: are you merging/will you merge the "courier" package?
[13:12] <bilalakhtar> BlackZ: I am making attempts of fixing an FTBFS in it
[13:12] <bilalakhtar> BlackZ: But you are free to take it
[13:12] <BlackZ> bilalakhtar: do you have a build log of the FTBFS?
[13:12] <bilalakhtar> I tried over 10 builds with it
[13:12] <bilalakhtar> yes, just a sec
[13:12] <BlackZ> thanks
[13:14] <bilalakhtar> BlackZ: Wait a sec, my latest build on a PPA succeeded and I didn't even notice that :) I am merging it
[13:14] <bilalakhtar> BlackZ: Do you want to, or should I go ahead
[13:14] <bilalakhtar> ?
[13:15] <BlackZ> bilalakhtar: go ahead with the merge then ;)
[13:19] <bilalakhtar> BlackZ: uploaded
[13:22] <BlackZ> bilalakhtar: thanks
[13:50] <ari-tczew> tumbleweed: do you have any bluetooth device to use in Ubuntu?
[13:54] <tumbleweed> ari-tczew: Yes, but my bluetooth often isn't working (suspend related, I seem to recall there being a bug, but can't remember)
[13:54] <ari-tczew> tumbleweed: sad to hear that. I'd like to ask you about test bluez 4.70 from Debian unstable on natty.
[13:56] <tumbleweed> ari-tczew: I can look
[13:58] <ari-tczew> thanks
[14:05] <hrw> hi
[14:06] <geser> Hi
[14:06] <geser> hrw: btw the vim merge is almost done, just waiting on main sponsors coming back from UDS
[14:07] <hrw> geser: cool
[14:29] <ari-tczew> lucas: how often does your merge script is updating?
[14:33] <lucas> ari-tczew: every few hours
[14:39] <ari-tczew> lucas: it seems to not updating about 14 hours
[14:40] <tumbleweed> ari-tczew: had a quick play with it, seems fine. But haven't reviewed the diffs and that package has been forked for a while...
[14:40] <ari-tczew> tumbleweed: I'll look into diffs tomorrow.
[14:41] <lucas> ari-tczew: the ubuntu-natty sources/packages info is updated at: (UTC times)
[14:41] <lucas> 30 2,14 * * * $UAR ubuntu-natty
[14:41] <lucas> so it's due to be updated in <1h
[14:42] <ari-tczew> lucas: so, something is wrong. package python-scipy has been merged 14 hours ago and it exist on the list. the same thing with denemo.
[14:43] <lucas> 0.7.2-2ubuntu1 is the merged version?
[14:43] <TeTeT> ScottK: as discussed at breakfast I added a bug to lucid-backports, see bug 667285. If anything is missing let me know
[14:43] <lucas> (for python-scipy)
[14:44] <ari-tczew> lucas: https://launchpad.net/ubuntu/+source/python-scipy/0.7.2+dfsg1-1ubuntu1
[14:47] <lucas> ari-tczew: it will be updated during the next UDD data update
[14:47] <lucas> ari-tczew: apparently it wasn't there yet during the previous mirror sync
[14:47] <lucas> ari-tczew: I'm not sure how often mirror syncs happen
[14:47] <ari-tczew> lucas: where is next UDD data update?
[14:47] <lucas> ari-tczew: (mirror sycs to UDD)
[14:47] <lucas> 30 2,14 * * * $UAR ubuntu-natty
[18:47] <psusi> boy this is really odd... I'm seeing a binary package with two different source packages... there is tads, and there is frobtads... both claim to build the binary packages tads3-dev and tads3-common, and tads2-dev... what gives?  did someone screw up and repackage something that was already packaged?
[19:10] <geser> psusi: it happens sometime when a source package got renamed that we have both: the old and the new one
[19:12] <Laney> both appear to be in debian
[19:12] <geser> psusi: http://packages.debian.org/changelogs/pool/non-free/f/frobtads/current/changelog
[19:17] <psusi> yea, debian appears to have both... but they both output some of the same binary packages, which isn't allowed right?  so the old one should be dropped?
[19:19] <psusi> it seems that ubuntu does not have frobtads
[19:19] <geser> it only gives problems, when you need to upload the old package
[19:20] <geser> check if the other binaries from tads are r(build)depends somewhere
[19:20] <psusi> why?
[19:20] <geser> and asking the Debian maintainer of both packages could be a good idea too
[19:21] <psusi> yea, I sent him an email
[19:21] <psusi> bug we have a bug asking for it to be updated to a new upstream release... it seems that was done, but the name changed, causing all this mess so now I'm not sure what to do with the bug, heh...
[19:21] <geser> if you drop tads, then the binaries tads2, tads3 and tads3-doc are deleted too and I don't see them in frobtads
[19:22] <geser> (but I didn't check if something provides them)
[19:22] <geser> and it would be a bad idea to remove something that is needed as a (build-)dependency
[19:23] <psusi> hrm... how would you check for that?
[19:23] <geser> apt-cache rdepends tads2
[19:23] <geser> and ubuntu-dev-tools has a script for rbuilddepends
[19:25] <psusi> doesn't that only check the packages I have installed on my system?
[19:26] <geser> no
[19:27] <psusi> how does it do that then?  don't you have to have the package to get the depend info from the control file?  or is it listed in the repository Packages.gz?
[19:29] <micahg> geser: does the checkbuilddepends script work?  I haven't been able to get anything from it
[19:30] <benste> hi, what was the name of the meta package includin dbuild ... for all these tasks - e.g. got a deb from google code, and wanted to add it into my own PPA - changed version to ...ubuntu1 and now having the files only, but need the source.changes
[19:30] <benste> is $ sudo apt-get install build-essential fakeroot dpkg-dev enought ?
[19:31] <psusi> hrm... I wonder why the frobstads package has not been synced to ubuntu?
[19:31] <geser> micahg: I use an other one and not the one from u-d-t. And the one I use works so far
[19:32] <micahg> psusi: I don't see that on pqda
[19:32] <micahg> *pqdo
[19:33] <psusi> micahg: eh?
[19:33] <micahg> psusi: I don't see that in Debian
[19:33] <ajmitch> micahg: frobtads, not frobstads
[19:33] <micahg> ajmitch: ah
[19:34] <ajmitch> I was confused as well :)
[19:34] <psusi> hehe
[19:34] <ajmitch> it probably wasn't synced because it's in non-free
[19:35] <geser> ajmitch: is syncing new packages already done?
[19:35] <psusi> ajmitch: why does that matter?
[19:36] <ajmitch> geser: it's been in debian for over a year now
[19:36] <micahg> geser: I think the issue is that it should have been sync'd last cycle
[19:37] <ajmitch> psusi: I don't believe that automatic syncing is done for contrib/non-free
[19:37] <ajmitch> an archive admin can clarify it
[19:37] <psusi> so you need to explicitly request it eh?
[19:37] <ajmitch> I think so
[19:38] <psusi> ok... we'll see if the dd drops the old source package then I can request syncs to drop the old and sync the new to ubuntu
[19:50] <ElementGreen> I have question concerning a PPA package version which has never been in Debian or Ubuntu.  I tried using libinstpatch-1.0.0-0~maverick1~ppa1 but this fails to satisfy >= 1.0.0 for some reason, which another package in my PPA is dependent on.  Help appreciated!
[19:52] <Laney> make it -0ubuntu1 instead of -0
[19:53] <ElementGreen> Ok.  So even though its not yet officially part of Ubuntu, that is the way to go?
[19:54] <Laney> it's the -0~ which makes it less than 1.0.0
[19:54] <Laney> you can compare with dpkg --compare-versions a ge b && echo yes
[19:54] <Laney> which tests if a >= b according to dpkg
[19:55] <ElementGreen> Ok.  Thanks!
[22:10] <bdrung> tumbleweed: i don't like the '-u' parameter of syncpackage. my brain associates -u with --upload
[22:12] <tumbleweed> bdrung: ok, in fact I have a fix for that (it broke fakesync for ack-sync), so I need to do a commit anyway
[22:12] <tumbleweed> bdrung: suggestions?
[22:12] <bdrung> tumbleweed: --dont-sign
[22:13] <tumbleweed> ok, so no short option, that's fine
[22:13] <bdrung> tumbleweed: i have no better idea
[22:27] <bdrung> tumbleweed: do we want that: "env = os.environ"?
[22:28] <tumbleweed> If env is not None, it must be a mapping that defines the environment variables for the new process; these are used instead of inheriting the current process’ environment, which is the default behavior.
[22:28] <tumbleweed> if we want to extend the environment, we start with the current one
[22:30] <bdrung> tumbleweed: we don't do that for dch
[22:32] <tumbleweed> bdrung: I do that so that we generate Launchpad-Bugs-Fixed
[22:32] <tumbleweed> it's only really needed for things calling dpkg-genchangelogs
[22:32] <tumbleweed> (err, the above when running on Debian, which is what I do)
[22:33] <bdrung> tumbleweed: setting env['DEB_VENDOR'] = 'Ubuntu' is a good idea, but i don't know if it useful to pass all env settings
[22:34] <tumbleweed> we also need things like PATH
[23:14] <Laney> tumbleweed: seems we are NM buddies!
[23:15] <Laney> ps. changing the interface of a tool like that might not be the best idea
[23:15] <Laney> you don't know who/what relies on it
[23:15] <tumbleweed> Laney: heh
[23:15] <tumbleweed> which interface are we talking about?
[23:15] <Laney> this -u thing
[23:15] <ajmitch> flags for requestsync?
[23:15] <tumbleweed> I only added that yesterday
[23:16] <Laney> oh ok
[23:16] <Laney> if it's not in a release then cool
[23:16] <Laney> btw ack-sync has no manpage
[23:16] <tumbleweed> oh, I see I have an AM assigned
[23:17] <tumbleweed> Laney: so, taking bets who finishes first? :)
[23:17] <Laney> whoever has the more sensible AM
[23:17] <tumbleweed> yeah that's what I heared
[23:17] <Laney> i.e. who asks only the appropriate questions
[23:17] <Laney> and not the whole template
[23:18] <bdrung> Laney: that's one reason why it's not in the binary package
[23:18] <Laney> :)
[23:18] <bdrung> you guys remind me to ping my AM
[23:19] <bdrung> Laney: feel free to write one (or better integrate the functionality into sponsor-patch) ;)
[23:19] <tumbleweed> now that it's not going ot offend archive-admins, I suppose a manpage is in order
[23:19] <Laney> no i don't use such tools :P
[23:19]  * Laney really hopes that LP functionality will actually happen
[23:19] <Laney> upload-from-branch is sexy
[23:20] <bdrung> tumbleweed: ack-sync doesn't upload changes files by default
[23:20] <bdrung> it shouldn't offend archive-admins
[23:20] <tumbleweed> bdrung: it used to
[23:20] <bdrung> yes
[23:22] <ajmitch> Laney: right, the whole build-from-branch stuff is nice, it does lose the trust path of the signed .changes file though
[23:22] <tumbleweed> that's what caused 3.0 (git) to be nacked in debian
[23:22] <Laney> depends if you trust your browser cookie as much as a gpg signature :P
[23:22] <ajmitch> but it means less duplication of commiting changes to a branch, pushing & then still having to dput
[23:22] <ajmitch> tumbleweed: though git revisions can also be signed
[23:22] <tumbleweed> err actually it was reviewability of the distributability of branches, IIRC
[23:23] <ajmitch> because of the non-DFSG-free stuff in branches?
[23:23] <Laney> in the history
[23:23] <ajmitch> yeah
[23:23] <Laney> you can't review the entire history
[23:23] <tumbleweed> becaus ftp-masters wouldn't be able to review the entire history of a branch
[23:23]  * ajmitch remembers reading that one
[23:23] <ajmitch> especially if you're merging in the upstream branches, rather than importing a tarball each time
[23:24] <ajmitch> sure, you could rebase all the time, but that screws up history