[05:14] <ScottK> bdrung: $ reverse-depends -b devscripts|grep -c \* says 282 for a quantity.  It seems to be a wide variety of things.
[07:59] <dholbach> good morning
[08:02] <ESphynx> good morning :)
[08:07] <geser> good morning
[08:15] <bkerensa> dholbach: so the adding of the ubuntu changes by submittodebian this is in fact a bug or intentional of the tool?
[08:16] <dholbach> if you work on 1.2.3-4ubuntu2, submittodebian will include the changes of 1.2.3-4ubuntu1 as well
[08:17] <bkerensa> but if I am bzr branch debian:package name I am not working on 1.2.4.-4ubuntu2 but instead am working with upstreams source package and yet in these cases it still drops ubuntu changes into it
[08:18] <dholbach> it might be that submittodebian always uses the last ubuntu revision to diff against and not care about bzr branches overly much
[08:18] <dholbach> in that case just      bzr diff > ~/patch
[08:19] <dholbach> and submit this on your own (https://wiki.ubuntu.com/Debian/Bugs)
[08:40] <bdrung> ScottK: how many have "build-depends: @cdbs@" in control.in?
[08:55] <bdrung> ScottK: see my comments in debian bug #694760
[08:55] <bdrung> ScottK: the only valid reverse dependency is bzr-builddeb (using dch)
[09:09] <hrw> Rhonda: hi
[09:11] <cjwatson> bdrung: I didn't really look since I don't care about the reasons :)
[09:12] <cjwatson> bdrung: why argue?  M-A: foreign would be harmless
[09:13] <bdrung> cjwatson: because you actually mention two issues: multiarch and build dependencies on devscripts
[09:15] <cjwatson> bdrung: it doesn't hurt to M-A: foreign random things with no architecture-dependent interfaces, regardless of the reasons
[09:16] <bdrung> cjwatson: agreed. i was just commenting that package build depend on devscripts, which is wrong IMO
[09:17] <cjwatson> I don't care about that - I'm just trying to unblock as many cross-build issues as I can
[09:17] <cjwatson> the more things we unblock with strategic multiarching, the more we get to find out about real per-package issues
[09:18] <cjwatson> if you require us to change cdbs, then it'll be months or years before we can find out whether those packages cross-build once their dependencies are satisfied
[09:19] <cjwatson> sure, by all means try to reduce the build-dep graph - I'd just like that to be done in parallel with this
[09:19] <bdrung> cjwatson: they are two different issues. i will commit your fix.
[09:20] <cjwatson> thanks
[09:21] <bdrung> cjwatson: how import is that fix? do you think we will get a unblock request granted?
[09:22] <cjwatson> I wouldn't expect the Debian release team to consider it important for wheezy
[09:22] <Laney> aboudreault: great news. will you submit the fix to ubuntu/debian?
[09:22] <bdrung> cjwatson: ok, then i will commit it into our master branch (will be in the next upload to experimental)
[09:23] <cjwatson> I'd like to have it for raring
[09:23] <cjwatson> ta
[09:30] <bdrung> cjwatson: done: http://anonscm.debian.org/gitweb/?p=devscripts/devscripts.git;a=commitdiff;h=ae4fb54bdeb59649bcf89103d73bcf97b0dbd81b
[09:31] <bdrung> cjwatson: when is feature freeze?
[09:34] <Laney> https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule
[09:37] <bdrung> okay, still enough time to do the experimental upload
[09:43] <Rhonda> hrw: hmm?
[09:44] <hrw> Rhonda: packages.ubuntu.com question - why it does not list armhf/armel packages?
[09:45] <Rhonda> Because noone told me it should?
[09:45] <hrw> Rhonda: :)
[09:46] <Rhonda> Since which release are they to be included?
[09:46] <hrw> Rhonda: armel was lucid->quantal, armhf precise->raring
[09:47] <Rhonda> Hmm, I don't se a Contents-armel.gz or Contents-armhf.gz in *any* release?
[09:47] <Rhonda> http://archive.ubuntu.com/ubuntu/dists/raring/
[09:47] <Laney> lives on the ports archive
[09:47] <Laney> ports.ubuntu.com
[09:47] <hrw> Rhonda: http://ports.ubuntu.com/dists/
[09:47] <Rhonda> http://archive.ubuntu.com/ubuntu/dists/raring/main/ also only lists binary-amd64 and binary-i386
[09:47] <Rhonda> Well, if it's ports and not official archs …
[09:48] <hrw> and here we have standard problem ;)
[09:48] <Laney> it's various hysterical raisins - armhf is pretty supported (moreso than powerpc, which packages does already list)
[09:48] <hrw> each time when I ask why arm is still on ports everyone dissapear
[09:49] <Rhonda> If I would include ports I probably should include armel, armhf, hppa, ia64, lpia, powerpc and sparc, the full suite?
[09:49] <Rhonda> ah, that was hardy.
[09:49] <hrw> Rhonda: armel, armhf, powerpc only - rest died already
[09:49] <Laney> armel already did too?
[09:50] <Laney> depends how much work you want to do for non-current series
[09:50] <hrw> Laney: in raring yes.
[09:50] <hrw> lucid had sparc but oneiric didn't
[09:50] <hrw> but I have no idea was sparc supported at all
[09:51] <hrw> hi infinity
[09:51] <Rhonda> So if I could get some sort of "official" statement which archs from ports should be listed …  I could try to add them.
[09:52] <Rhonda> Or if I should just pull all from ports that are available for the releases, that's fine with me too
[09:52] <infinity> Rhonda: The latter.
[09:52] <infinity> Rhonda: It's more useful for people to be able to see everything.  Much like packages.d.o shows debian-ports stuff, even if it's "unofficial".
[09:52] <Laney> Yeah, you might as well do that
[09:53] <Rhonda> Will take me a bit.  We have "ports" support in the packages code on packages.debian.org, so there's not too much to do here, I just have to give it a good whack at the right spot to make it work properly.
[09:53] <infinity> We don't actually treat our ports as second-class citizens.
[09:53] <Laney> it must already be working for .u.c somehow because powerpc
[09:53] <infinity> If they can just be mushed together into one, that would be nice.
[09:54] <infinity> (On ftpmaster, it's all one archive, we only split it for mirrors)
[09:54] <Rhonda> weeeelllll
[09:54] <Rhonda> And packages.debian.org seemingly only shows ports for unstable
[09:54] <Rhonda> Laney: Where do you see powerpc listed?
[09:54] <Laney> Search the contents of packages -> architecture
[09:55] <Rhonda> Right, but there are no packages therein
[09:55] <Laney> perhaps it's listed but doesn't work - i didn't try a search :-)
[09:56] <Rhonda> packages.ubuntu.com/irssi does list powerpc only at the top as selection (together with armel, FWIW)
[09:56] <infinity> The links at the top seem to have not much to do with functionality of the site. :)
[09:57] <Rhonda> Ah, wait, it has "arch all" packages for hardy in its list  :P
[09:57] <Rhonda> s/for hardy //
[09:57] <infinity> Rhonda: Just combining dists from archive and ports should DTRT.
[09:57] <infinity> Rhonda: Perhaps even almost magically, though I've never looked at the packages.d.o code. :/
[09:58] <infinity> (Though, I guess the links to "download this package" would still need love..)
[09:58] <Rhonda> What was the hostname again, sulfur was the old one :)
[09:59] <Rhonda> jubany
[09:59]  * Laney sheds a tear for sulfur
[09:59] <infinity> jubany was quite the upgrade...
[09:59] <infinity> Unless it got stripped down before it was given to you.
[09:59] <Rhonda> I would have liked to help, but I never heard anything back to my canonical sysadmin application.  :P
[09:59] <infinity> That used to launchpad's master postgresql instance.
[13:42] <aboudreault> Laney, yes, we are already committers in DebianGIS
[18:29]  * Laney discovers that you can hover over package names in Launchpad bugs and get some useful information
[20:33] <robottinosino> I am having problems with texlive-base (http://paste.ubuntu.com/1400458/), I am assuming this is a common issue? Saw a few bugs filed about this..
[20:47] <tumbleweed> Laney: it's less useful than you think, though. last upload is often not what you want to see
[21:26] <robottinosino> Is this a bug? http://paste.ubuntu.com/1400458/ http://paste.ubuntu.com/1400609/
[21:28] <tumbleweed> why does this remind me of askubuntu.com? :)
[21:29] <tumbleweed> robottinosino: all we can see is that the last thing executed was /etc/libpaper.d/texlive-base - that's the next thing to investigate
[21:30] <robottinosino> sounds great. :) if you can guide me, I am here to troubleshoot this :)
[21:30] <robottinosino> i honestly think this may be common to many machines, not just mine
[21:32] <robottinosino> dpkg status gives me this: http://paste.ubuntu.com/1400638/
[21:33] <tumbleweed> robottinosino: set -x in /etc/libpaper.d/texlive-base and run it
[21:33] <robottinosino> (Status: install ok half-configured) - sure, will do...
[21:34] <robottinosino> http://paste.ubuntu.com/1400645/
[21:36] <robottinosino> I have seen more than one bug related to this (example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648278 from askubuntu, which you know - but there are others)
[21:37] <robottinosino> solution does not work for me, is it possible?
[21:37] <tumbleweed> doesn't look related to me
[21:38] <robottinosino> Well, sorry for steering the issue away from the right path then. I apologise.
[21:38] <robottinosino> tumbleweed: are you able to reproduce it? the (Status: install ok half-configured)  I mean
[21:38] <tumbleweed> robottinosino: no, can't reproduce it
[21:38] <tumbleweed> that last command sholud have returned a4, don't know why it didn't
[21:39] <robottinosino> does it help to get a list of my installed packages?
[21:39] <robottinosino> do i do that with a `dpkg --get-selections` ?
[21:41] <tumbleweed> doubt it. I can't see anything obvious, and don't really know much about the tex / papersize bits
[21:42] <robottinosino> None of these issues/bugs are related? https://www.google.es/search?q="dpkg-query+--status+texlive-base"
[21:42] <tumbleweed> it'd be easy enough to make it install (you can exit 0 early in /etc/libpaper.d/texlive-base ), but I still don't know why it's failing
[21:47] <robottinosino> very odd. :(
[21:59] <robottinosino> tumbleweed: thanks for your help anyway
[23:13] <jtaylor> if a sru depends on another sru do I have to put in versioned (build-) depends?
[23:24] <ScottK> If it will FTBFS on the older version no.  If it will misbuild, yes.
[23:24] <ScottK> b-d versioning shouldn't be about bugs or archive skew, but sometimes you have no choice.
[23:24] <jtaylor> why not for ftbs?
[23:26] <ScottK> Because then you could just retry it
[23:26] <ScottK> No harm done.
[23:26] <ScottK> If it will misbuild with the older one, then add the version limit to avoid a misbuild.
[23:26] <jtaylor> so its not like e.g debian exp were it will use unstable unless its versioned?
[23:27] <ScottK> Correct.