[00:08] 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] psusi: rmadison [00:16] psusi: yes, apt_preferences(5); see apt-pinning [00:17] ari-tczew, don't see what that has to do with my situation [00:18] 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] 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] hoping I can do them all at once from the command line [00:23] ari-tczew: if that's cecilia is valid, then yes [00:25] crimsun: how can I check whether cecilia is valid? do you mean run command from /usr/bin? [00:26] psusi: are you using pin priorities? Use something > 1000 for maverick. [00:26] ari-tczew: no, I assumed you knew what mimetype to use. [00:31] 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] 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] does this mean that 'apt-get' try to stop init.d scripts before removing packages ? [01:17] 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] that looks like "apt-get" tried to start twice the init.d script ! [01:17] i don't understand the reason why it try twice ! [01:17] it tries* [01:29] nobody knows ? [02:50] paissad_: you should read the contents of those maintainer scripts to see how invoke-rc.d is used === fabo_ is now known as fabo === thekorn is now known as th3k0rn === th3k0rn is now known as thekorn === fabo__ is now known as fabo === warp10 is now known as af_warp10 === af_warp10 is now known as dp_warp10 === dp_warp10 is now known as warp10 === warp10 is now known as dp_warp10 === bilalakhtar_ is now known as bilalakhtar [13:11] bilalakhtar: are you merging/will you merge the "courier" package? [13:12] BlackZ: I am making attempts of fixing an FTBFS in it [13:12] BlackZ: But you are free to take it [13:12] bilalakhtar: do you have a build log of the FTBFS? [13:12] I tried over 10 builds with it [13:12] yes, just a sec [13:12] thanks [13:14] BlackZ: Wait a sec, my latest build on a PPA succeeded and I didn't even notice that :) I am merging it [13:14] BlackZ: Do you want to, or should I go ahead [13:14] ? [13:15] bilalakhtar: go ahead with the merge then ;) [13:19] BlackZ: uploaded [13:22] bilalakhtar: thanks [13:50] tumbleweed: do you have any bluetooth device to use in Ubuntu? [13:54] 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] tumbleweed: sad to hear that. I'd like to ask you about test bluez 4.70 from Debian unstable on natty. [13:56] ari-tczew: I can look [13:58] thanks [14:05] hi [14:06] Hi [14:06] hrw: btw the vim merge is almost done, just waiting on main sponsors coming back from UDS [14:07] geser: cool [14:29] lucas: how often does your merge script is updating? [14:33] ari-tczew: every few hours === dholbach_ is now known as dholbach [14:39] lucas: it seems to not updating about 14 hours [14:40] 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] tumbleweed: I'll look into diffs tomorrow. [14:41] ari-tczew: the ubuntu-natty sources/packages info is updated at: (UTC times) [14:41] 30 2,14 * * * $UAR ubuntu-natty [14:41] so it's due to be updated in <1h [14:42] 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] 0.7.2-2ubuntu1 is the merged version? [14:43] ScottK: as discussed at breakfast I added a bug to lucid-backports, see bug 667285. If anything is missing let me know [14:43] Launchpad bug 667285 in lucid-backports "Please backport ibm-3270 from maverick/natty to 10.04 LTS" [Undecided,New] https://launchpad.net/bugs/667285 [14:43] (for python-scipy) [14:44] lucas: https://launchpad.net/ubuntu/+source/python-scipy/0.7.2+dfsg1-1ubuntu1 [14:47] ari-tczew: it will be updated during the next UDD data update [14:47] ari-tczew: apparently it wasn't there yet during the previous mirror sync [14:47] ari-tczew: I'm not sure how often mirror syncs happen [14:47] lucas: where is next UDD data update? [14:47] ari-tczew: (mirror sycs to UDD) [14:47] 30 2,14 * * * $UAR ubuntu-natty === dp_warp10 is now known as warp10 [18:47] 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? === bilalakhtar_ is now known as bilalakhtar [19:10] psusi: it happens sometime when a source package got renamed that we have both: the old and the new one [19:12] both appear to be in debian [19:12] psusi: http://packages.debian.org/changelogs/pool/non-free/f/frobtads/current/changelog [19:17] 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? === bilalakhtar_ is now known as bilalakhtar [19:19] it seems that ubuntu does not have frobtads [19:19] it only gives problems, when you need to upload the old package [19:20] check if the other binaries from tads are r(build)depends somewhere [19:20] why? [19:20] and asking the Debian maintainer of both packages could be a good idea too [19:21] yea, I sent him an email [19:21] 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] 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] (but I didn't check if something provides them) [19:22] and it would be a bad idea to remove something that is needed as a (build-)dependency [19:23] hrm... how would you check for that? [19:23] apt-cache rdepends tads2 [19:23] and ubuntu-dev-tools has a script for rbuilddepends [19:25] doesn't that only check the packages I have installed on my system? [19:26] no [19:27] 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] geser: does the checkbuilddepends script work? I haven't been able to get anything from it [19:30] 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] is $ sudo apt-get install build-essential fakeroot dpkg-dev enought ? [19:31] hrm... I wonder why the frobstads package has not been synced to ubuntu? [19:31] micahg: I use an other one and not the one from u-d-t. And the one I use works so far [19:32] psusi: I don't see that on pqda [19:32] *pqdo [19:33] micahg: eh? [19:33] psusi: I don't see that in Debian [19:33] micahg: frobtads, not frobstads [19:33] ajmitch: ah [19:34] I was confused as well :) [19:34] hehe [19:34] it probably wasn't synced because it's in non-free [19:35] ajmitch: is syncing new packages already done? [19:35] ajmitch: why does that matter? [19:36] geser: it's been in debian for over a year now [19:36] geser: I think the issue is that it should have been sync'd last cycle [19:37] psusi: I don't believe that automatic syncing is done for contrib/non-free [19:37] an archive admin can clarify it [19:37] so you need to explicitly request it eh? [19:37] I think so [19:38] 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] 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] make it -0ubuntu1 instead of -0 [19:53] Ok. So even though its not yet officially part of Ubuntu, that is the way to go? [19:54] it's the -0~ which makes it less than 1.0.0 [19:54] you can compare with dpkg --compare-versions a ge b && echo yes [19:54] which tests if a >= b according to dpkg [19:55] Ok. Thanks! === zul__ is now known as zul [22:10] tumbleweed: i don't like the '-u' parameter of syncpackage. my brain associates -u with --upload [22:12] 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] bdrung: suggestions? [22:12] tumbleweed: --dont-sign [22:13] ok, so no short option, that's fine [22:13] tumbleweed: i have no better idea [22:27] tumbleweed: do we want that: "env = os.environ"? [22:28] 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] if we want to extend the environment, we start with the current one [22:30] tumbleweed: we don't do that for dch [22:32] bdrung: I do that so that we generate Launchpad-Bugs-Fixed [22:32] it's only really needed for things calling dpkg-genchangelogs [22:32] (err, the above when running on Debian, which is what I do) [22:33] 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] we also need things like PATH [23:14] tumbleweed: seems we are NM buddies! [23:15] ps. changing the interface of a tool like that might not be the best idea [23:15] you don't know who/what relies on it [23:15] Laney: heh [23:15] which interface are we talking about? [23:15] this -u thing [23:15] flags for requestsync? [23:15] I only added that yesterday [23:16] oh ok [23:16] if it's not in a release then cool [23:16] btw ack-sync has no manpage [23:16] oh, I see I have an AM assigned [23:17] Laney: so, taking bets who finishes first? :) [23:17] whoever has the more sensible AM [23:17] yeah that's what I heared [23:17] i.e. who asks only the appropriate questions [23:17] and not the whole template [23:18] Laney: that's one reason why it's not in the binary package [23:18] :) [23:18] you guys remind me to ping my AM [23:19] Laney: feel free to write one (or better integrate the functionality into sponsor-patch) ;) [23:19] now that it's not going ot offend archive-admins, I suppose a manpage is in order [23:19] no i don't use such tools :P [23:19] * Laney really hopes that LP functionality will actually happen [23:19] upload-from-branch is sexy [23:20] tumbleweed: ack-sync doesn't upload changes files by default [23:20] it shouldn't offend archive-admins [23:20] bdrung: it used to [23:20] yes [23:22] Laney: right, the whole build-from-branch stuff is nice, it does lose the trust path of the signed .changes file though [23:22] that's what caused 3.0 (git) to be nacked in debian [23:22] depends if you trust your browser cookie as much as a gpg signature :P [23:22] but it means less duplication of commiting changes to a branch, pushing & then still having to dput [23:22] tumbleweed: though git revisions can also be signed [23:22] err actually it was reviewability of the distributability of branches, IIRC [23:23] because of the non-DFSG-free stuff in branches? [23:23] in the history [23:23] yeah [23:23] you can't review the entire history [23:23] becaus ftp-masters wouldn't be able to review the entire history of a branch [23:23] * ajmitch remembers reading that one [23:23] especially if you're merging in the upstream branches, rather than importing a tarball each time [23:24] sure, you could rebase all the time, but that screws up history