[00:00] <slangasek> leex: actually, it seems that this package only breaks things if you specifically choose to configure it
[00:01] <slangasek> Choices: configure now, configure later, skip and leave config as it is
[00:01] <slangasek> Default: skip and leave config as it is
[00:01] <slangasek> by default, the package does not create /etc/decnet.conf
[00:01] <slangasek> and with no decnet.conf, /etc/init.d/decnet does not mangle the interface configuration.
[00:02] <leex> slangasek: as said I did not install it by hand, it must have been part of a dependency, therefore I did not configure anything on my own
[00:03] <leex> just did aptitude update+upgrade, wouldn't have noticed it unless it happened on both my machines
[00:04] <leex> slangasek: but i am using the daily ppa for firefox and mplayer, that might have something to do with it
[00:04] <slangasek> leex: ah, I see, this is Debian bug #637179, which did exist in versions prior to the latest version in precise
[00:05] <SpamapS> slangasek: ok, the mysql 5.5.17 in the repo I pointed you to builds...
[00:05] <SpamapS> Build needed 02:24:21, 1379708k disc space
[00:05] <SpamapS> slangasek: with current sid
[00:05] <slangasek> SpamapS: spiff
[00:05] <SpamapS> did not build an experimental chroot :p
[00:06] <slangasek> shouldn't be necessary :)
[00:06] <SpamapS> slangasek: I also have a merged version for Ubuntu.. so as soon as its accepted we can upload a merge and start the rebuilding.
[00:06] <SpamapS> probably worth loading up a PPA with those rebuilds now
[00:06] <SpamapS> no sense waiting
[00:07] <slangasek> hmm, not in sync?
[00:09] <jasox> slangasek, I solve probelem, I used another mail :)
[00:09] <SpamapS> slangasek: no, there's an upstart job and a few other bits
[00:10] <SpamapS> slangasek: I'm sure we can get them in sync soon tho
[00:10] <slangasek> jasox: great :)
[00:10] <leex> slangasek: I will go to bed now, it's quite late here, but I will check for PMs tomorrow if you send me one ;)
[00:10] <leex> good night and thanks
[00:10] <slangasek> leex: good night
[00:10] <SpamapS> slangasek: IIRC some of our changes were somewhat big so we could drop some binary bits to universe.
[00:17] <poolie> tjaalton, RAOF, can you give me any suggestions on what to do/test for https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745112
[00:22] <bryceh> poolie, slangasek, are either of you able to set releasedate for oneiric in launchpad?  It's returning None presently
[00:22] <broder> slangasek: can you point me at an old version of something that is missing the .xz pre-depends so i can test the lintian check?
[00:23] <poolie> bryceh, just so you know you can ask 'losa' in #launchpad to do superuser type things
[00:23] <slangasek> bryceh: no; I've been asked this before, I've never seen any releasedate for distributions
[00:23] <slangasek> we have release dates for milestones, the releasedate for the series is something new
[00:23] <slangasek> poolie: I doubt it's in the UI at all
[00:24] <micahg> broder: I did this one: https://launchpad.net/ubuntu/precise/+source/lyx/2.0.1-1ubuntu1
[00:24] <bryceh> released:  oneiric None
[00:24] <bryceh>  Supported  natty 2011-04-28 11:36:14+00:00
[00:24] <bryceh>  Supported  maverick 2010-10-10 10:19:39.197066+00:00
[00:24] <bryceh>  Supported  lucid 2010-04-29 17:33:27.289933+00:00
[00:24] <bryceh>  Supported  hardy 2008-04-24 00:00:00+00:00
[00:24] <poolie> i doubt i can change it myself
[00:24] <broder> micahg: perfect, thanks
[00:24] <spm> poolie: as a general rule, with some known exceptions, we don't go near the ubuntu stuff. "can" as distinct from "should/shall"
[00:24] <infinity> bryceh: Are those actually accurate?
[00:25]  * infinity grumbles at no longer having access to things like https://launchpad.net/ubuntu/oneiric/+edit
[00:26] <bryceh> infinity, they appear to be in the ballpark but I didn't check exact dates
[00:26] <slangasek> infinity: hrm, *that* seems to be a regression
[00:27] <infinity> slangasek: I don't think it is.
[00:27] <infinity> slangasek: Unless you mean me not being a duckie is a regression, and I agree. ;)
[00:27] <slangasek> infinity: I'm pretty sure I remember ubuntu-release giving access to that before
[00:28] <infinity> slangasek: I don't think release ever did, except as a subset of drivers, which they no longer are.
[00:28] <slangasek> well
[00:28] <slangasek> that's a regression ;)
[00:28] <infinity> slangasek: Ubuntu and ubuntu-drivers is still ickily special-cased all over, despite the lies the UI tells.
[00:29] <tumbleweed> bryceh: I filed a bug for that date to be changed, too. Hoping that someone would at least set oneiric's date before ignoring the longer term bug of setting it automatically, but no such luck
[00:31] <tumbleweed> bug 876345 fwiw
[00:31] <bryceh> tumbleweed, thanks
[00:35] <NCommander> Who do I poke to get a new topic added to the status.u.c page?
[01:03] <cjwatson> bjsnider: dh_make puts '8' in debian/compat, so the Build-Depends it sets is correct for that.  If you want to make it build in contexts where debhelper 8 is unavailable, then you also need to drop the compat level; but I do think the default in dh_make is reasonable, given that 8 is debhelper's current recommended lvel
[01:03] <cjwatson> *level
[01:03] <cjwatson> spm: FWIW we asked for the natty release date to be set by LOSAs (and it was done) on the basis that there was no way for us to do it otherwise and people were complaining to us
[01:04] <cjwatson> (for values of "we" that aren't me; I don't know if a bug was filed)
[01:04] <cjwatson> oh, let's read more scrollback, how about that
[01:04] <spm> cjwatson: ahh! that's new to me. it's usually just been the freeze/unfreeze thing.
[01:04] <spm> heh
[01:04] <cjwatson> spm: I'd kind of hoped it was a one-off
[01:05] <cjwatson> it's clearly nonsense for it to have to be set manually after the fact
[01:07] <infinity> @pilot out
[01:26] <slangasek> SpamapS: still doing the build here; I think I started mine significantly after yours :)
[01:28] <SpamapS> slangasek: the tests are brutal on I/O
[01:29] <SpamapS> @pilot out
[01:29] <slangasek> maybe I should've run 'eatmydata svn-buildpackage'
[01:33] <SpamapS> I have a feeling that might cause the test suite to freak out. ;)
[01:38] <dr3mro> hello , I am new to linux programming and I want to create a package for ubuntu contains some files to extract on certain paths on my system .. i did create the deb file using dpkg-deb but I need to create a PPA for that can you hel me :)
[01:44] <bregma> dr3mro, you can create a PPA from the home page of your Launchpad account
[01:46] <dr3mro> bregma, i did the ppa and fail to build
[01:46] <dr3mro> bregma, it's not a source code but rather a bunch of scripts and files to extract
[01:48] <bregma> PPAs require a proper source package to build the debs from, perhaps you just want a local archive on your own machine?
[01:54] <bjsnider> dr3mro, where's the buildlog?
[03:03] <mwhudson> SpamapS: have you seen https://bugs.launchpad.net/ubuntu/+source/offlineimap/+bug/877883 ?
[03:26] <infinity> dbus build-depending on dbus is brilliant.
[03:27]  * infinity shakes his head.
[03:27] <broder> ugh, there are too many of those
[03:28] <infinity> broder: Some of them have valid excuses (like compilers).
[03:28] <infinity> broder: dbus has no such clever excuse.
[03:29] <StevenK> Perhaps dbus only wishes to send messages to itself about how the compile is going.
[03:30] <infinity> StevenK: *laugh*
[03:30] <infinity> StevenK: It actually build-deps on python-dbus, libdbus-glib-1-dev, which is actually pretty bizarre, but I can't be bothered to hunt down why.  A few by-hand builds and some mangling, and it's easy enough to work around.
[03:31] <infinity> I'd like to get to a point some day where after hand-bootstrapping a toolchain, the rest of the distro can "just build", though.  That would be novel.
[03:31] <StevenK> infinity: See also 'pipe-dream'
[03:31] <infinity> That was a good game.
[03:31] <broder> infinity: debian/control has:
[03:32] <broder> # libdbus-glib-1-dev and libglib2.0-dev can be omitted for bootstrapping,
[03:32] <broder> # but if you have them in Build-Depends, more tests can be run
[03:32] <infinity> broder: And python-dbus?
[03:32]  * infinity shrug.
[03:32] <infinity> s
[03:32] <infinity> That's basically what I did anyway.
[03:32] <broder> uh, don't know - i only have an old package lying around at the moment
[03:32] <infinity> Though, with the usual interim "build, fail, and install anyway" step.
[03:33] <infinity> I'm already over it. ;)
[05:11] <pitti> Good morning
[05:13] <ajmitch> hi pitti
[06:24] <SpamapS> mwhudson: no I hadn't, but that is *definitely* my issue
[06:26] <broder> hmm...pkgbinarymangler always strips out upstream changelogs, right? so i should probably suppress that tag on lintian.uw.o
[06:26] <pitti> broder: yes
[06:26] <pitti> broder: btw, thanks for setting this up!
[06:26] <broder> no problem!
[08:09] <dholbach> good morning
[08:35] <lapo> Can someone please upgrade this patch to 11.10 http://bigbrovar.aoizora.org/index.php/2011/05/24/better-clickpad-support-for-ubuntu-11-04/
[09:29] <pitti> lool: bonjour, ca va?
[09:30] <pitti> lool: AFAIR you were able to reproduce the udev boot breakage which you resolved by reverting the SOCK_NONBLOCK option, right?
[09:31] <pitti> lool: do you have some time to test https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034386.html ?
[10:39] <didrocks> hum, I guess there is a tool that parses debian/changelog to know what the last package revision of a source is
[10:39] <cjwatson> dpkg-parsechangelog
[10:39] <didrocks> thanks cjwatson, my tab completion skill was pretty poor ;)
[10:44] <OdyX> SpamapS: w.r.t. cmake and multiarch, take a look at the pyside stack (apiextractor, generatorrunner,shiboken,pyside). But it mostly works thanks to their CMakefiles...
[11:27] <Daviey> Could an archive admin please sync bug 882507, thanks.
[11:49] <StevenK> cjwatson: I think I've tracked down why datereleased doesn't get set for Ubuntu.
[11:52] <cjwatson> oh good
[11:54] <StevenK> Or not. It should be set.
[11:56] <StevenK> cjwatson: Actually, that might it. It seems that +edit will only set .datereleased in some circumstances, but +admin will always set it. Which is making me go O.o
[12:09] <StevenK> cjwatson: Do you know if there is there a bug for the datereleased thing?
[12:20] <cjwatson> 00:29 <tumbleweed> bryceh: I filed a bug for that date to be changed, too. Hoping that someone would at least set oneiric's date before ignoring the longer term bug of setting it automatically, but no such luck
[12:21] <cjwatson> 00:31 <tumbleweed> bug 876345 fwiw
[12:21] <cjwatson> StevenK: ^-
[12:21] <StevenK> Excellent, thank you.
[13:03] <StevenK> cjwatson: Fixed. https://code.launchpad.net/~stevenk/launchpad/distroseries-edit-datereleased/+merge/81730 has the gory details.
[13:05] <cjwatson> StevenK: excellent, thanks
[13:05] <StevenK> cjwatson: I can also prod to get Oneiric fixed if you wish.
[13:05] <StevenK> cjwatson: Or you can, I don't mind.
[13:06] <cjwatson> StevenK: please go ahead
[13:22] <Laney> broder: should be easy to do: copy the existing lintian stuff in config-org.yaml, add some sql to sql/setup.sql and modify the lintian gatherer to insert into the ubuntu table based on 'source'
[13:23] <Laney> the last part might not even be necessary
[13:24] <nigelb> 20
[13:24] <nigelb> ERR
[13:24] <nigelb> sorry
[13:51] <cjwatson> jelmer: any progress on the bzr/armel build failure?  and is anyone working on making bzrtools and bzr-git installable again in precise?  I'm happy to help given pointers
[14:27] <lool> cjwatson: after submitting some patches to P-a-s, I discovered that Debian is now looking at dropping most entries there when "Auto-not-for-us" is enough; do we have plans to implement this in Launchpad too?
[14:28] <cjwatson> lool: I don't know
[14:28] <cjwatson> lool: but we shouldn't maintain a delta against P-a-s just for the sake of it
[14:28] <lool> cjwatson: I can drop an email to the lp stakeholders list
[14:29] <cjwatson> well, is it possible LP already DTRT?
[14:29] <jelmer> cjwatson: one of the other bzr devs is looking at the bzr build problem. I'm about to upload bzrtools.
[14:29] <lool> it's entirely possible, I don't know
[14:30] <cjwatson> lool: for example, syslinux-themes-ubuntu isn't in P-a-s but https://launchpad.net/ubuntu/+source/syslinux-themes-ubuntu/2 only built on the architectures listed in the Architecture line
[14:30] <cjwatson> lool: I think there's nothing to do in LP
[14:30] <Laney> auto-nfu is using the Architecture: list in control?
[14:30] <cjwatson> I believe so
[14:30] <lool> cjwatson: awesome, so we can just merge the removals then; thanks
[14:30] <cjwatson> you used to get a trivial build failure instead
[14:30] <lool> Laney: yes
[14:30] <Laney> nice
[14:30] <cjwatson> jelmer: thanks
[14:30] <cjwatson> jelmer: and bzr-git too?
[14:31] <lool> cjwatson: do we have some process to update ubuntu's P-a-s?
[14:31] <cjwatson> lool: JFDI
[14:31] <cjwatson> do you mean merging from Debian?  I do a bzr merge occasionally
[14:32] <lool> cjwatson: that's what I meant
[14:32] <cjwatson> just 'bzr merge lp:packages-arch-specific', resolve, commit
[14:32] <lool> our branch is lp:~ubuntu-core-dev/packages-arch-specific/ubuntu right?
[14:32] <lool> seems that's the only other one
[14:32] <cjwatson> yes
[14:32] <lool> thanks
[14:33] <jelmer> cjwatson: sorry, yes - that too. It just needs to be synced from Debian.
[14:33] <cjwatson> it gets deployed every hour or so I think
[14:33] <cjwatson> jelmer: OK, you should be able to do that with 'syncpackage -d unstable bzr-git'
[14:35] <jelmer> cjwatson: thanks
[14:38] <rbasak> Do I need to declare a versioned dependency if I know that a particular release will have the version I need?
[14:40] <cjwatson> rbasak: not doing so can be a dangerous game
[14:41] <rbasak> cjwatson: OK I'll take that as a yes then, thanks :)
[14:41] <cjwatson> rbasak: sometimes people drop them after an LTS cycle has passed, but personally I would always keep them.  What's the exact situation?
[14:42] <jdstrand> @pilot in
[14:42] <cjwatson> versioned dependencies are cheap and they help with things you might not have thought of like LTS-to-LTS upgrades, bootstrapping new architectures, etc.
[14:42] <rbasak> cjwatson: I'm backporting a fix for an SRU to Oneiric. The fix requires a particular version of python-django. The previous control file does not specify a required version, but I know that the fix does require a version which we have in Oneiric already, so I was wondering if I should amend the control file
[14:42] <geser> rbasak: think also about backports. when someone backports this package to a previous release then the depedency is fulfilled but not the version requirement
[14:43] <cjwatson> rbasak: imagine somebody upgrading from natty to oneiric + updates in one shot
[14:43] <cjwatson> SRUs shouldn't assume that they are being installed on a system that's already been upgraded
[14:44] <cjwatson> so if it needs something in particular, then absolutely include the versioned dep
[14:49] <rbasak> cjwatson: OK will do, thanks.
[15:01] <SpamapS> http://packages.qa.debian.org/m/mysql-5.5/news/20111109T134815Z.html
[15:01] <SpamapS> woot
[15:12] <apw> can anyone tell me what extras.ubuntu.com is, and whether i would expect that to exist for precise yet
[15:13] <tumbleweed> apw: it should be empty for precise. https://wiki.ubuntu.com/AppReviewBoard
[15:14] <tumbleweed> (but yes, probably should exist)
[15:14] <cjwatson> yes please because then I could install its signatures in apt-setup
[15:14] <cjwatson> it's a problem if it doesn't exist pre-release
[15:14] <apw> it cirtainly doesn't exist as we stand
[15:15] <apw> should i file a bug, or will someone handle it
[15:16] <tjaalton> slangasek: looks like ia32-libs-multiarch mistakenly depends on gtk2-engines-murrine, which doesn't seem to be multiarched (and forces partial upgrade to precise)
[15:17] <bigon> sforshee: hi, do you know if the alps patch you have made will be merged?
[15:17] <sforshee> bigon, the upstream maintainer has accepted the patches, and we'll be using them in the precise kernel
[15:18] <bigon> the 0.10 version of the patches?
[15:18] <sforshee> basically, with a few minor (non-functional) updates
[15:20] <bigon> sforshee: thx :)
[15:21] <apw> sforshee, did those hit 3.2 ?
[15:21] <sforshee> apw, no, they're in linux-next now
[15:22] <apw> sforshee, ok so are you going to send us a pile of those ?
[15:22] <sforshee> apw, i sent the pull request yesterday, and ogasawara just applied them to master-next
[15:22] <apw> sforshee, oh then i'll shut up :)  cool, good work
[15:27] <apw> so do we expect to be able to update via update-manager this early in the cycle?  seems to let me use -d and tell me 12.04 is there, but then dies later with "WARNING: Failed to read mirror file"
[15:28] <mvo> apw: it should allow the upgrade at this point, the warning there is harmless
[15:32] <apw> mvo, ok so after the -d making me be unsupported on oniric i see the normal screen.  hit upgrade and it tries to scare me.  hit upgade again and it does its normal stuff preparing, then setting new channels, then it errors about the extras.ubuntu.com being missing.  (which i also thought was not a big issue) and then close causes it to backout
[15:32] <apw> so perhaps then its the extras.ubuntu.com not having anything for precise thats fubaring me
[15:33] <mvo> apw: right, its there now, it will take a bit (probably until tomorrow) to get synced, if you want to upgrade now you could simply comment it out in sources.list (/etc/apt/sources.list that is)
[15:35] <apw> mvo, ok confirmed that fixes it
[15:36] <broder> Laney: are those scripts public? i can't find any reference to them on the udd page
[15:36] <m4n1sh> mvo: can you look at one more merge proposal for software-properties?
[15:37] <mvo> m4n1sh: absolutely!
[15:37] <m4n1sh> sorry, not able to provide the link as I am on EDGE network (tethered), so can't even open launchpad now.
[15:39] <slangasek> tjaalton: it's not a mistake; see https://lists.ubuntu.com/archives/ubuntu-devel/2011-October/034279.html
[15:43] <mvo> m4n1sh: no problem I will followup in the merge proposal :)
[15:43] <m4n1sh> sure
[15:43] <tjaalton> slangasek: ah ok, seems I missed/forgot that one
[15:43] <m4n1sh> mvo, can you make some minor tweaks if needed. I can't even branch or push on this slow connection
[15:46] <mvo> m4n1sh: ok, when will you be back on a faster one? soon(ish) or will that be a matter of days? (just curious so that I can judge if I should tweak it myself or followup in the proposal)
[15:47] <tumbleweed> broder: yes, http://anonscm.debian.org/viewvc/collab-qa/
[15:47] <m4n1sh> mvo, I just shifted house  today
[15:47] <m4n1sh> so I hurriedly finished the proposal yesterday
[15:47] <m4n1sh> mvo, not sure about when I get a faster one. Need to call the iSP
[15:47] <m4n1sh> *ISP
[15:47] <m4n1sh> mvo, well you are the maintainer, you can tweak it
[15:48] <m4n1sh> not a problem
[15:48] <mvo> m4n1sh: great, thanks, will do :)
[15:48] <m4n1sh> thanks :)
[15:48] <lynxman> hey everyone, which would be the best way to check for the existance of a package? My package depends on either of two packages (activemq | rabbitmq-stomp) and on the postinst I need to check the existance of either to do the proper config, I was thinking about checking for the config dir to exist but not sure if that's the best method, recommendations?
[15:48] <mvo> m4n1sh: the only small tweak is to move it into a function I think
[15:49] <m4n1sh> mvo, I think that is fine. Not something really big or anything that changes the behaviour of the script
[15:50] <SpamapS> lynxman: the config dir would still be there if one had been removed and the other were installed
[15:50] <Laney> broder: in svn.d.o/svn/collab-qa/udd
[15:50] <lynxman> SpamapS: that's why :)
[15:51] <mvo> m4n1sh: yeah
[15:51] <SpamapS> lynxman: do the two conflict?
[15:51] <lynxman> SpamapS: not necessarily, but they could
[15:52] <SpamapS> lynxman: so it seems that you probably need to configure for them both separately based on the existence of their executables
[15:52] <broder> lynxman: could you split the setup into two subpackages - one for each - and then have the parent package depend on package-that-configs-activemq | package-that-configs-rabbitmq-stomp?
[15:54] <lynxman> broder: that could be an option, but it would break compatibility with the previous versions of the same package
[15:54] <lynxman> broder: that's why I'm trying to be just smart enough to solve it out :)
[15:54] <lynxman> SpamapS: checking the binaries is a good idea indeed...
[15:55] <SpamapS> like,    if -x rabbitmqctl ; then ... fi ; if -x activemq ; then ... fi
[15:55] <lynxman> SpamapS: would you say relative or full paths are the best way for that?
[15:56] <lynxman> SpamapS: I tend to do full paths but I know is a bit frowned upon
[15:56] <broder> lynxman: debian policy says use relative paths in maintainer scripts
[15:57] <SpamapS> errr
[15:57] <broder> lynxman: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s6.1
[15:57] <lynxman> broder: ah there you go :)
[15:57] <broder> (last paragraph)
[15:57] <broder> i know because i noticed there was a lintian tag for it :)
[15:57] <SpamapS> relative to what?
[15:57] <brendand> are there instructions on building compiz somewhere?
[15:57] <SpamapS> He's not calling
[15:57] <SpamapS> checking for existence/executableness
[15:58] <SpamapS> my -x was just an example
[15:58] <SpamapS> you *must* do the path for -x
[15:58] <lynxman> SpamapS: yeah, doing if -x /usr/bin/activemq or just if -x activemq
[15:58] <broder> if hash foo >/dev/null 2>&1; then ...
[15:58] <broder> is the standard incantation
[15:58] <SpamapS> hash? I've never seen that.
[15:58] <lynxman> broder: oh interesting, any examples?
[15:58] <SpamapS> but that makes sense
[16:00] <SpamapS> lynxman: so    if hash rabbitmqctl > /dev/null 2>&a; then
[16:00] <lynxman> SpamapS: cool :)
[16:03] <lynxman> SpamapS: broder: thank you very much for your answer, I'll use hash then
[16:06] <smoser> $ sh -c 'hash foo'
[16:06] <smoser> sh: 1: hash: foo: not found
[16:06] <smoser> the *right* way to say "is this something i can run" is
[16:06] <smoser> sh -c 'command -v foo >/dev/null'
[16:07] <smoser> sh -c 'command -v foo >/dev/null' && echo yes || echo no
[16:07] <smoser> broder, ^. hash is a bash builtin. not available in posix sh.
[16:07] <broder> huh? it's totally available
[16:07] <broder> evan@caron:~$ sh -c 'type hash'
[16:07] <broder> hash is a shell builtin
[16:08] <broder> foo on the other hand...
[16:10] <cjwatson> I tend to use 'type', or 'which' in contexts where /usr is available, or on occasion a tiny shell function equivalent to 'which'
[16:10] <cjwatson> you totally don't need to fork a new shell to use 'command -v', in any event
[16:11] <smoser> broder, yes, you are correct. i am a dolt.
[16:11] <SpamapS> smoser: hash is in dash
[16:11] <cjwatson> 'type' (or 'command -v') tells you whether the command exists with varying levels of standards conformance; 'which' tells you whether it exists specifically on $PATH
[16:11] <broder> smoser: no worries - it's still early for us US folks ;)
[16:17] <broder> Laney: i couldn't figure out how to checkout the svn repo, but http://paste.ubuntu.com/733216/ and http://paste.ubuntu.com/733219/ should be sufficient if i understand this stuff correctly
[16:17] <smoser> it appears to me that type, command -v and hash all search PATH.
[16:17] <smoser> http://paste.ubuntu.com/733217/
[16:17] <smoser> cjwatson, were you stating otherwise ?
[16:17] <Laney> broder: right, and you need an entry in config-org.yaml
[16:18] <cjwatson> they search PATH but they *also* search builtins
[16:18] <smoser> ah.
[16:18] <cjwatson> 'which' only searches PATH
[16:18] <smoser> right.
[16:18] <broder> Laney: first pastebin :)
[16:18] <Laney> oh yeah
[16:18] <cjwatson> (by design, and because it's an external command)
[16:18] <Laney> svn> svn co svn+ssh://svn.debian.org/svn/collab-qa/udd/
[16:18] <smoser> right
[16:18] <broder> svn+ssh://> still don't think i have that setup
[16:19] <Laney> should work without +ssh
[16:19] <broder> ah, so itdoes
[16:20] <cjwatson> there's a 'searchpath' function in base-passwd.postinst which I cut down from 'which', and there's osextras.find_in_path in ubiquity if you want a Python implementation, and I have a C one in man-db/lib/pathsearch.c - I've written this several times ;-)
[16:30] <Laney> broder: will deploy it later
[16:30] <Laney> cheers
[16:30] <broder> cool, no rush from me
[16:31] <broder> i'll probably end up stealing the script and running it on my lintian lab anyway so i can make the report generation a bit more configurable (e.g. ubuntu-only package report)
[16:31] <Laney> which script?
[16:32] <broder> the importer
[16:32] <zul> cjwatson:  can you review python-passlib please?
[16:32] <Laney> thought you were mirroring udd
[16:33] <broder> i am. but for things like the ubuntu-only report, i'm planning to slurp the lintian.log into a database, then filter it appropriately, spit it back out, then run it through the html report generator again
[16:35] <cjwatson> zul: hm, I think I'm out of time for today (or rather all my remaining time is already committed), sorry, it would be better if somebody else could do it but otherwise I can look tomorrow morning
[16:35] <zul> cjwatson: ok ill bug someone else then
[16:46] <SpamapS> silly question, when using sbuild, whats the appropriate way to set DEB_BUILD_OPTIONS ?
[16:49] <broder> SpamapS: looks like you might be able to set $build_environment = {'DEB_BUILD_OPTIONS' => 'stuff' }; in your ~/.sbuildrc?
[16:50] <SpamapS> ahh, /usr/share/doc/sbuild/examples/example.sbuildrc is quite helpful :)
[16:51] <lool> pitti: Sorry for the delay, tried udev from your PPA now and it failed to boot
[16:51] <pitti> lool: oh, what happens?
[16:52] <pitti> lool: stuck in initramfs?
[16:54] <chrisccoulson> slangasek, i still can't reproduce the addon problem you had yesterday. is it easily reproducible for you (ie, if you uninstall firefox-globalmenu, restart firefox, reinstall firefox-globalmenu and restart again, do you get the extra tab asking you to enable the addon?)
[16:55] <slangasek> cjwatson: mmk, Debian publisher has had time to catch up, I'm syncing all the X packages in the libxmu stack now
[16:55] <slangasek> chrisccoulson: nothing about having to restart firefox is easy, but I'll check :)
[16:55] <chrisccoulson> slangasek, thanks
[16:55] <cjwatson> slangasek: great
[17:04] <SpamapS> slangasek: https://launchpadlibrarian.net/84784123/buildlog_ubuntu-precise-i386.mysql-5.5_5.5.17-1ubuntu1~ppa0_FAILEDTOBUILD.txt.gz .. segfault on the buildds :-/
[17:05] <slangasek> hmm!
[17:05] <slangasek> well, it's i386
[17:05] <slangasek> who uses that anyway :)
[17:05] <SpamapS> only the weak
[17:05] <lool> pitti: Yes; uploading pictures of the crash
[17:06] <lool> sorry for the delay, had to solve another ubuntu install not starting weirdly -- unrelated
[17:06] <SpamapS> slangasek: no such failure on amd64 .. :-P
[17:07]  * SpamapS builds an i386 precise chroot.. :-P
[17:07] <lool> pitti: http://ubuntuone.com/5UdVl0S9Nnf7qNqI6TfhH6 http://ubuntuone.com/01ckC0NMdYZb8Y423lMlmf
[17:07] <mterry> slangasek, your upload of popt that now depends on gettext:any seems to confuse the buildd: https://launchpadlibrarian.net/84756245/buildlog_ubuntu-precise-i386.popt_1.16-1ubuntu1_FAILEDTOBUILD.txt.gz
[17:08] <mterry> slangasek, do you know what the fix for that is?
[17:08] <lool> pitti: apparently, initramfs gives up waiting for root device before it appears, not sure what udev fails to do there, perhaps it thinks all events have been processed when they haven't; should I set some debug flags in the initramfs to check it out?
[17:08] <slangasek> mterry: the fix is that the new sbuild will be rolled out tomorrow morning UK time
[17:08] <mterry> slangasek, beautiful  :)
[17:32] <cjwatson> jelmer: bzr-git failed to build; I don't know if LP has fixed the bug where the syncer doesn't get mailed about such things
[17:33] <Laney> given that they went for recording synced packages separately, I think probably not
[17:34] <jelmer> cjwatson: I didn't get any email so I guess not. Thanks for the ping.
[17:35] <slangasek> SpamapS: so how did mysql 5.5 wind up with cmake anyway?  It seems to have been pleasantly autoconfy in 5.1
[17:39] <SpamapS> slangasek: upstream wanted to use the same build tool on windows and *nix
[17:39] <SpamapS> slangasek: basically all the smart people in the build team left when Sun bought MySQL AB .. ;)
[17:40] <SpamapS> s/smart/autoconfy people/
[17:40]  * SpamapS should really be nicer, they've been quite pleasant when we've reported bugs in the new cmake build. ;)
[17:40] <SpamapS> [100%] Building CXX object sql/CMakeFiles/sql.dir/sys_vars.cc.o
[17:40] <SpamapS> and cmake at least has a % done counter.. :)
[17:40] <slangasek> heh
[17:42] <slangasek> cjwatson: do you remember which packages were mangling the console from underneath X most recently?  some Russian support package?
[17:43] <cjwatson> console-cyrillic is the one you're thinking of I think
[17:43] <slangasek> right, thanks
[17:43] <cjwatson> I hit it with a hammer.  bug 597673
[17:43] <slangasek> :)
[17:44] <slangasek> bug #887445 has a user reporting the same behavior... no console-cyrillic installed. looking through his package list now
[17:57] <highvoltage> Riddell: hi, have Kubuntu decided yet about its 12.04 LTS status? and whether it will be supported for 3 or 5 years?
[17:58] <YokoZar> What do I do after a kernel panic in a stable release if I'm a good citizen?
[17:58]  * YokoZar hasn't had one till now in 7 years of Ubuntu...
[18:12] <SpamapS> [1:1:157311113007:ERROR:nacl_fork_delegate_linux.cc(78)] Bad NaCl helper startup ack (0 bytes)
[18:12] <SpamapS> I keep seeing these...
[18:12] <SpamapS> wtf?
[18:14] <LaserJock> lol, I automatically read that as "Bad salt helper".
[18:15] <SpamapS> "Your table salt has failed to fork" does conjure up an interesting image
[18:16] <LaserJock> I'm teaching general chemistry this semester, I guess it's starting to soak in :-)
[18:22] <micahg> well, chromium has NaCL...
[18:22] <micahg> SpamapS: ^^which version are you running?
[18:23] <SpamapS> ii  google-chrome-stable    15.0.874.106-r107270    The web browser from Google
[18:23] <SpamapS> so just chrome whining about something
[18:23] <micahg> SpamapS: I can't help you if you're running chrome
[18:23] <micahg> we didn't build chromium with NaCL for M15, toolchain issue
[18:23] <SpamapS> will ignore it for now
[18:23] <Laney> who maintains the ubuntu pastebin?
[18:24] <Laney> having to log in for plaintext is really annoying
[18:24] <micahg> laney: I thought it's ubuntu-website, but I could be wrong
[18:27] <infinity> Laney: Canonical IS.
[18:28] <Laney> do they have anything other than RT?
[18:28] <infinity> Laney: And they have the login-for-plaintext thing set up that way intentionally, so you might have to present an argument.
[18:28] <infinity> Laney: (It's to prevent people using pastebin as a file trading service, as I recall)
[18:29] <Laney> I'm sure; it must have taken some effort.
[18:30] <Laney> It could perhaps generate private links which bypass the logging in requirement
[18:30] <infinity> Laney: How would that help?  Then people storing files there would just pass people said private links?
[18:31] <Laney> whereas now they just have to log in?
[18:31] <tumbleweed> infinity: and it also means you can't curl $url | patch -p1
[18:32] <tumbleweed> which is something one wants to do rathe roften
[18:32] <infinity> Laney: Sure, but requiring a launchpad account is a high enough barrier, I suspect.  Either way, wasn't my call.  Bug the IS folks. ;)
[18:32] <infinity> (I'd like plain-text-without-login to work too, I'm just pointing out the arguments I've seen against it)
[18:33] <infinity> ...
[18:33] <infinity> Really?  We still have packages that build-dep on dbs?
[18:33] <infinity> REALLY?!
[18:34] <LaserJock> wow
[18:34] <infinity> And not, like, crazy leaf packages.
[18:34] <infinity> newt.
[18:34] <infinity> Pretty core.
[18:34] <infinity> Wow.
[18:34] <infinity> I'm shocked.
[18:34] <LaserJock> huh, interesting
[18:35]  * infinity wonders if that's a sign that newt needs to be hijacked in Debian.
[18:35] <micahg> slangasek: I reproduced your firefox upgrade issue, so you're not alone, but chrisccoulson still can't...he's still investigating though
[18:35]  * infinity promptly forgets about the previous statement.
[18:36] <chrisccoulson> micahg, how reproducible is it for you?
[18:36] <slangasek> micahg: ok
[18:37] <micahg> chrisccoulson: new profile works, let me try the other one that existed
[18:37] <LaserJock> infinity: is there any mechanism in Debian that would tell a maintainer "look, it'd be swell if you could update your build system"?
[18:37] <micahg> chrisccoulson: I got it in the other profile that existed before upgrade as well
[18:37] <infinity> LaserJock: A bug report? :P
[18:38] <LaserJock> I would think unless it became like a security issue it's pretty much up to the maintainer
[18:38] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576054
[18:38] <broder> LaserJock: formal deprecation as a release goal :)
[18:38] <cjwatson> ^- like that one
[18:38] <infinity> Usertags: drop-dbs
[18:38] <infinity> Hah.
[18:39] <cjwatson> Usertags: drop-kick-dbs
[18:39] <infinity> The dbs maintainer just needs to do a no-code-change upload that renames it back to Doogie Build System.
[18:40] <infinity> That should prompt some action.
[18:46] <lynxman> jhunt: ping
[18:48] <jhunt> lynxman: hi
[18:48] <lynxman> jhunt: my man :)
[18:48] <lynxman> jhunt: I see that "pid file" is no longer supported in upstart, what should I try to manually specify the pid file for a process?
[18:48] <lynxman> jhunt: since it's getting it wrong (logging pid from parent that dies after fork)
[18:49] <jhunt> lynxman: funny you should say that - I'm currently working on a cookbook update that will cover all that in truly painful detail.
[18:49] <lynxman> jhunt: can you give me a painless preview? :)
[18:50] <SpamapS> lynxman: if the pid it thinks is the right one is dying too early, then you actually *do* have 2 forks, and you need expect daemon.
[18:50] <lynxman> jhunt: I can go the never daemon route and just respawn on demand as well, just trying to avoid that one
[18:50] <Laney> broder: it iz dun
[18:50] <SpamapS> lynxman: and if the process ever re-forks (like sshd does on SIGHUP) then you can't use expect fork / daemon and have to use foreground mode.
[18:50] <lynxman> SpamapS: coolio :)
[18:51] <broder> Laney: cool. i'll check it out next time i pick up a dump
[18:51] <jhunt> lynxman: SpamapS types faster than me :)
[18:51] <lynxman> jhunt: heh :) he's on his morning coffee I reckon
[18:51] <Laney> sweet
[18:52] <jhunt> lynxman: coffee levels dangerously low over here, in fact... pop.
[19:04] <Laney> http://ubuntu-dev.alioth.debian.org/junk/lintian.txt
[19:06] <rando_uu> beginners question: I want to build package_b on launchpad but it requires package_a, which is in my ppa, to be installed in the chroot environment, can I just add package_a to build dependes?
[19:07] <cjwatson> yes
[19:07] <cjwatson> that's exactly what build-depends is for
[19:09] <rando_uu> thx I'll give it a shot ;)
[19:10] <binarymutant> is Ubuntu still using revu?
[19:11] <maco> There's talk of getting rid of it
[19:12] <maco> It's frequently ignored and getting packages into debian first is preferable
[19:13] <binarymutant> ah, thanks for the info
[19:21] <Randolph> hi all
[19:21] <Randolph> I wanted to know if it is normal that when there are some updates for Ubuntu 11.10, the user does not need to supply the root password ?
[19:22] <micahg> Randolph: yes, https://wiki.ubuntu.com/SecurityTeam/FAQ#Update_Manager_doesn.27t_prompt_for_security_updates
[19:22] <micahg> Randolph: and it would be the user's password not root in any event
[19:23] <Randolph> You mean it is normal ?
[19:24] <Randolph> I think it is not a good idea in term of security
[19:24] <jdstrand> Randolph: sure it is. we make it easier for people to install security updates. you can't install new software without a password
[19:25] <Randolph> It could be a break into security, maybe with possibility of privilege escalation
[19:26] <micahg> Randolph: have you read the link I provided?
[19:26] <jdstrand> Randolph: I suggest reading the FAQ if you haven't already. the behavior is configurable via PolicyKit if you prefer to be prompted
[19:26] <Randolph> I read it quickly I must admit
[19:26] <maco> That's pretty cool
[19:27] <Randolph> that sound right
[19:27] <maco> I remember using a local root escalation exploit to gwu root so I could install security updates on one of the machines at my school since the admins weren't really doing their jobs
[19:28] <maco> s/gwu/get/
[19:28] <jdstrand> heheh
[19:28] <jdstrand> nice
[19:28] <Randolph> s/gwu/get/ what is this ?
[19:29] <micahg> ubottu isn't as talented as kubotu in explaining such things
[19:29] <micahg> exactly
[19:31] <broder> Randolph: s/gwu/get/ refers to a syntax in scripting languages for substitution
[19:31] <broder> so maco was indicating that she typo'd, and we should mentally replace "gwu" with "get" when we read her message
[19:31] <Randolph> broder, oki s for substitute
[19:32] <maco> Yes
[19:32] <Randolph> broder, I do not link with it
[19:32] <Randolph> like in VI or sed
[19:32] <maco> Yes
[19:32] <micahg> or perl regexps
[19:33] <maco> Vi is where I got the regex habit
[19:56] <broder> hmm.../etc/console-setup/cached.kmap.gz on my machine has keycode 58 = CtrlL_Lock (keycode 58 is caps lock). is this one of those weird bits of keymap arcana, or is that actually wrong?
[20:16] <mwhudson> SpamapS: ubuntu support via the company quotes page!!
[20:18] <broder> slangasek, ogra: have you guys thought at all about dealing with fscking the root partition in the no-initrd world? just came to mind as something i don't think we talked about
[20:18] <SpamapS> mwhudson: indeed, really, thanks.. I've already uploaded it to oneiric-proposed.. that was a REALLY annoying problem.
[20:18] <mwhudson> SpamapS: no kidding
[20:18] <slangasek> broder: we always do that from the root fs anyway
[20:18] <slangasek> we mount ro, and let mountall fire off the fsck
[20:18] <broder> oh right, because we haven't remounted rw yet
[20:19] <broder> so yes, you've thought about it more than me :)
[20:19] <mwhudson> SpamapS: would a comment from me somewhere that the version from precise fixed the problem help the SRU process along?
[20:19] <mwhudson> i guess i've already said that on the report
[20:19] <SpamapS> mwhudson: its in the bug already, yeah.
[20:19] <SpamapS> mwhudson: would help if you downgraded to the oneiric version when it hits oneiric-proposed, since that would count as verification. :)
[20:20] <mwhudson> SpamapS: ah ok
[20:20] <mwhudson> SpamapS: what is the version you uploaded?
[20:22] <SpamapS> mwhudson: 6.3.3-somethingubuntusomething ;)
[20:22] <mwhudson> SpamapS: haha ok
[20:22] <SpamapS> 6.3.3-3ubuntu1
[20:22] <SpamapS> has not been SRU reviewed quite yet
[20:38] <SpamapS> slangasek: looks like the build problem is not unique to 5.5 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627208
[20:38] <slangasek> "fixed"?
[20:39] <SpamapS> Yeah, apparently its a gcc 4.6 issue
[20:39] <SpamapS> so the fix was to force 4.5
[20:40] <SpamapS> http://bugs.mysql.com/bug.php?id=61509
[20:40] <SpamapS> I didn't merge that bit in from the 5.1 packaging...
[20:40] <SpamapS> trying now.
[20:58] <slangasek> chrisccoulson: so after doing that restart dance, I get *no* tab asking about re-enabling; this time it gets reenabled automatically
[20:58] <chrisccoulson> slangasek, yeah, i think we understand the bug now
[20:58] <chrisccoulson> thanks
[20:58] <slangasek> ok
[20:58] <chrisccoulson> i need to fix it quickly because it blocks the security update for oneiric :)
[20:59] <slangasek> right :)
[20:59] <slangasek> SpamapS: so I played around and got myself a multiarching patch for mysql-5.1; how soon will that be obsolete? :)
[21:00] <SpamapS> slangasek: hopefully by Monday
[21:00] <slangasek> hmm
[21:00] <slangasek> I'll upload anyway then :)
[21:00] <slangasek> because I want cross-buildable qt4-x11 *now* :)
[21:01] <SpamapS> slangasek: yeah inevitably there will be barriers to this transition.. I haven't even started the rebuild tests of all reverse deps.. :-P
[21:01]  * SpamapS ponders starting up a c1.medium to at least do all the amd64 rebuilds while he fixes i386
[21:02] <SpamapS> so many rebuidls, so few cores... ;)
[21:03] <slangasek> ooh, I bet the gcc 4.5 handling in mysql-5.1 isn't cross-build-safe
[21:07] <slangasek> pitti: libncurses5-dev has inconsistent symlinking of changelog.Debian.gz across architectures... on armel it's a symlink, on amd64 it's a file.  Should pkgbinarymangler's behavior be consistent here?
[21:10] <slangasek> cjwatson: what do you recommend for keeping track of generic autoconf checks that should be added to dpkg-cross?  File a bug on dpkg-cross for each?
[21:23] <slangasek> tjaalton: has libx11 102_double_arrows_Compose.patch been submitted to Debian? seems to be the only delta...
[21:24] <slangasek> tjaalton: also, the patch doesn't seem to be in effect in my own compose map :)
[21:24] <slangasek> (and furthermore, <= collides with the compose map for ≤)
[21:28] <slangasek> tremolux, barry: what other information would be useful to provide in bug #888297 (before I bypass aptdaemon and finish the upgrade with apt-get)?
[21:32] <tremolux> slangasek: hmm, so does sudo apt-get dist-upgrade -o Debug::pkgProblemResolver=true show anything interesting?
[21:33] <slangasek> tremolux: nope - a brief discussion of the packages I have held back (mythtv stuff), otherwise nothing
[21:33] <slangasek> tremolux: note that every single one of the complaining lines from aptdaemon is something that shouldn't be an issue, either
[21:33] <tremolux> slangasek: yeah, sounds like apt itself is happy
[21:34] <tremolux> slangasek: I don't know of anything else offhand you might add, seems to me like the info there is good
[21:34] <tjaalton> slangasek: right, it's a bogus patch that should be dropped if it's still there
[21:35] <slangasek> tremolux: ok, moving along with dist-upgrade then
[21:35] <slangasek> tremolux: thanks
[21:35] <tremolux> slangasek: you bet
[21:35] <slangasek> tjaalton: right, will drop it and sync
[21:35] <tjaalton> slangasek: yeah, thanks
[21:39] <barry> slangasek: i always just `apt-get install -f` before i follow up with `apt-get upgrade`.  /me commmented on the bug
[21:39] <slangasek> barry: yeah... apt-get itself works just fine here, it's an aptdaemon problem
[21:40] <barry> slangasek: smart is similarly busted, hence the continual landscape failures
[22:07] <cjwatson> broder: CtrlL_Lock> there's a comment in the console-setup source about that - it's a choice between two bugs, one major and one minor
[22:07] <cjwatson> slangasek: dpkg-cross> yeah
[22:08] <jdstrand> @pilot off
[22:08] <udevbot_> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[22:08] <jdstrand> @pilot out
[22:08] <slangasek> cjwatson: right-o
[22:08] <cjwatson> broder: it's a choice between the caps lock key not working, or caps lock not actually doing anything for non-ASCII letters (as I remember)
[22:08] <cjwatson> er, the caps lock *light* not working I mean
[22:08] <cjwatson> I consider the light bit minor
[22:08] <cjwatson> (annoying, granted)
[22:09] <angelo-c> Hi guys, I was here yesterday for LP: #881695
[22:09] <angelo-c> Ca anyone help me?
[22:12] <angelo-c> patch pilots out there?
[22:13] <Fusionite> Hey all
[22:15] <maco> Angelo-c say bug instead of lp and the bit will provide a handy link and summary
[22:15] <maco> *bot
[22:15] <angelo-c> https://bugs.launchpad.net/ubuntu/+source/xoscope/+bug/881695
[22:19] <angelo-c> I'm proposing a patch to be SRU:ed
[22:22] <maco> Use nominate for series button to add a task for the ubuntu version you want to sru (so your patch has something to close)
[22:22] <micahg> maco: only bug control can nominate
[22:23] <broder> cjwatson: yes, you're absolutely correct. it was fairly well documented once i figured out where to look, but oh god are my eyes bleeding :)
[22:23] <maco> Since when?
[22:23] <micahg> almost a year I think
[22:23] <maco> I thought anyone could but only bug control could approve
[22:23] <micahg> no, only uploaders, release team, drivers can approve
[22:23] <maco> *grumble*
[22:24] <angelo-c> this page https://answers.launchpad.net/launchpad/+question/140509 says that only bug supervisor can make something
[22:24] <micahg> angelo-c: right, that's what I was saying
[22:25] <angelo-c> this page is nominated by this official one https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[22:25] <maco> Security through pain-in-the-butt-ery
[22:25] <angelo-c> any bug supervisor here?
[22:25] <micahg> maco: not security, lack of utility, people were clicking for their pet fixes, so the nominations became useless
[22:26] <slangasek> maco: it's not security, it's "can we please have a queue that's not completely useless as a source of data kthx"
[22:26] <slangasek> when everyone could nominate, everyone did
[22:26] <cjwatson> broder: it's not an entirely fun problem
[22:26] <maco> Any of the three people talking now are able to
[22:26] <maco> Four
[22:27] <maco> I have no idea what that software is though
[22:27] <slangasek> so the nominations were useless and just wasted the time of those clicking the button
[22:27] <angelo-c> wow, fantastic! This is my first bug, so be clement whit me!
[22:27] <broder> cjwatson: i'm currently looking at https://lkml.org/lkml/2010/3/10/188 to see whether it can be revived, which i think might largely reduce the outstanding issues to a that-makes-me-want-to-cry-but-it-will-at-least-work level
[22:28] <slangasek> angelo-c: which releases did you care about seeing this fixed in?
[22:28] <slangasek> (i.e., which ones will you actually test the fix for? :)
[22:28] <cjwatson> broder: *nod*
[22:28] <cjwatson> Samuel has contributed to the userspace side of things too so knows what he's doing
[22:28] <maco> *snerk*
[22:29] <slangasek> angelo-c: IIRC from yesterday, your main concern was for oneiric... so I've opened an oneiric task there
[22:29] <angelo-c> tha branch was accepted yestarday for precise, i think should go also on oneiric-proposed
[22:30] <angelo-c> slangasek: yep, you are right!
[22:31] <angelo-c> I complied the bug description to include necessary sections, am I right?
[22:31] <slangasek> angelo-c: ok.  The bug state is as it should be for this.  Can you take care of the next steps from https://wiki.ubuntu.com/StableReleaseUpdates#Procedure ? (test case, debdiff prepared with appropriate version number and target in the changelog)
[22:31] <slangasek> yes, please :)
[22:31] <infinity> angelo-c: Have you tested the precise binaries from yesterday's upload to make sure they do what they should?
[22:32] <slangasek> cjwatson: ok, libx11 is the last blocker for libxmu; it's stuck in Debian new though, and I'm afraid of trying to get syncpackage to actually DTRT for a fakesync :)
[22:33] <angelo-c> slangasek: I think i wrote everything on bug description
[22:34] <maco> I suspect it's the debdiff he's asking about
[22:34] <cjwatson> slangasek: fakesyncs are the only thing syncpackage used to be good for, before the recent API enhancements :-)
[22:34] <infinity> angelo-c: And please, base the debdiff off the source I uploaded to precise, rather than your branch. ;)
[22:34] <infinity> angelo-c: (I converted your changes to a patch in debian/patch)
[22:34] <angelo-c> infinity: glad to see you! nop, but I think that the sources are identical because they had the same version number before the patch
[22:34] <infinity> es
[22:35] <infinity> Well, yes.  Just taking my sources, and changing the version number in the changelog (and the target) would work fine. ;)
[22:35] <slangasek> angelo-c: ah, I see the information in the comments, ok.  Normally we put this information in the bug description (using the pencil icon to edit), because comments don't stay where you can find them as a bug grows
[22:35] <cjwatson> slangasek: it looks it will need to be a merge though?
[22:35] <slangasek> cjwatson: according to tjaalton we can drop that last patch
[22:35] <cjwatson> ah
[22:36] <cjwatson> so why would it need to be a fakesync?
[22:36] <maco> Infinity: I'm going to have to actually install precise and oneiric if I want to start doing srus for o, huh? *lazy semi-dev*
[22:36] <cjwatson> do you just mean to accelerate past Debian NEW?
[22:36] <slangasek> cjwatson: perhaps I'm meaning something different by the word.  "sync from NEW"
[22:36] <slangasek> yes
[22:36] <angelo-c> slangasek: oh, my fault
[22:36] <cjwatson> ah.  I'm sure you know enough bribable ftpmasters. :-)
[22:37] <infinity> maco: Not sure about installing precise to do oneiric SRUs.. :P
[22:37] <cjwatson> though it's so fast these days I don't usually bother
[22:37] <slangasek> heh
[22:37]  * slangasek impatient
[22:37] <maco> Infinity: there was an and in there. I'm on maverick and natty
[22:38] <cjwatson> SRUs> chroots work for a lot of things ...
[22:38] <cjwatson> (spot the non-desktop developer)
[22:38]  * slangasek grins
[22:38] <angelo-c> slangasek: ok, I removing the comment and editing the bug description
[22:38] <slangasek> angelo-c: thanks :)
[22:38] <infinity> cjwatson: *grin*
[22:38] <maco> I did all of my oneiric stuff in a vm since ubiquity was pretty much all I did
[22:39]  * cjwatson ponders purging his hardy chroot
[22:39] <maco> Start the install, swear, poke python, start the installer again...
[22:39] <infinity> cjwatson: We still support it.
[22:39] <cjwatson> yeah, but like I ever actually touch it
[22:39] <infinity> cjwatson: I did a hardy SRU of apt only a month ago!
[22:39] <cjwatson> overachiever
[22:39] <angelo-c> slangasek: ok, done
[22:39] <maco> Haha
[22:39] <DktrKranz> slangasek: do you need libx11 out of NEW?
[22:40] <infinity> cjwatson: Pot, kettle?
[22:40] <cjwatson> infinity: shh
[22:40] <maco> I'm going to go with hoping colin doesn't screw around too much with a grub that seems to work!
[22:41] <cjwatson> well, since you ask, there've been a lot of nice fixes upstream lately ;-)
[22:41] <maco> Hardy boots, now lets never touch it's grub again!
[22:41] <cjwatson> I suspect this will be a cherry-pick cycle though
[22:41] <infinity> maco: The upshot is that if he screws it up, it's even MORE his job to fix it than ever before.
[22:41] <angelo-c> infinity: I have to test the patch mandatory?
[22:42] <angelo-c> infinity: I tested the patch extensively for oneiric!
[22:42] <infinity> angelo-c: In the case where it's literally the same source package, and I based it on your original patch, I think we can let the pre-upload testing slide.
[22:42] <infinity> angelo-c: Obviously, post-upload, it'll need to be tested from -proposed.
[22:44] <angelo-c> infinity: I think that
[22:45] <slangasek> DktrKranz: "need" is overstating it slightly... "getting twitchy waiting for" :)
[22:47] <angelo-c> infinity: testing from -proposed implies only to add the proper repository to sources.list, right?
[22:48] <infinity> angelo-c: Or, in the case of a single fixed package, just downloading the one deb and installing it manually. :P
[22:48] <infinity> angelo-c: But the point is testing the built binaries, that's all.
[22:48] <slangasek> -b$R{53<B2><87>Qv<B7><AF><CC>^? <B0>-^T<D6><8D><F9>M<94>Q9I<CD><87>.<FF>^KZl<8D><F6><80>5^@^@
[22:48] <slangasek> +b$R{53<B2><87>Qv<B7><AF><CC>^? <B0>-^T<D6><8D><F9>M<94>Q9I<CD><F7>P<FF>^WZl<8D><F6><80>5^@^@
[22:48] <infinity> slangasek: I agree.
[22:48]  * slangasek calmly stabs gzip
[22:48] <angelo-c> infinity: ok, it's really in my intrest!
[22:48] <infinity> slangasek: Oh, the manpage bug?
[22:48] <slangasek> infinity: yep, finding more hits
[22:48] <slangasek> libtasn1-3 NEWS.gz
[22:49] <infinity> slangasek: Outside of PAM finally?
[22:49] <slangasek> oh yes
[22:49] <infinity> slangasek: That's oddly comforting.
[22:49] <slangasek> it's not at all isolated to PAM
[22:49] <slangasek> there's a Debian bug filed about it now as well
[22:49] <slangasek> jwilk ran an archive scan to find inconsistencies in packages marked M-A: same.. turned up a few
[22:49] <slangasek> Debian bug #647522
[22:49] <infinity> slangasek: That's... Two characters different?
[22:49] <maco> Gzip is fubar?
[22:49] <slangasek> infinity: three
[22:49] <DktrKranz> slangasek: processed, it will be accepted in ~12 minutes
[22:50] <slangasek> DktrKranz: thanks :)
[22:50] <infinity> slangasek: How is that even the same stream when unzipped?  Still makes my head hurt.
[22:50] <DktrKranz> so, does anybody say I'm bribable? ;)
[22:50] <infinity> slangasek: I liked Colin's dictionary theory, but that would lead to drastically different streams.
[22:50] <slangasek> infinity: dunno yet, haven't had a chance to dig
[22:50] <infinity> (Or, more than 3 chars, anyway)
[22:51] <slangasek> 7msg DktrKranz when will you collect this beer?
[22:51] <SpamapS> slangasek: so, for multiarch, the -dev packages can have executables, right?
[22:51] <broder> oh noes! slangasek has accidentally revealed the secret to his success at manipulating ftpmasters! :-P
[22:51] <SpamapS> slangasek: just not the runtime libs?
[22:51] <infinity> slangasek: Are we supposed to believe you don't use a US keyboard?
[22:52] <slangasek> SpamapS: if you want co-installable -dev packages, they generally need to be free of executables; but this is a softer goal than the goal of coinstallable runtime libs
[22:52] <angelo-c> infinity: how do you converted my changes to a patch in debian/patch?
[22:52] <slangasek> infinity: I don't use the US keymap!
[22:53] <SpamapS> slangasek: libmysqlclient-dev has /usr/bin/mysql_config ..
[22:53] <infinity> slangasek: You use... A... German one?  I can't think of who else has the / there.
[22:53] <SpamapS> oh wait
[22:53] <SpamapS> thats a script
[22:53] <PasNox> Evening
[22:53] <slangasek> SpamapS: scripts are sometimes fine... and sometimes they foolishly embed library paths, so *look* fine when you start out and become less fine after you've built for multiarch :)(
[22:53] <infinity> angelo-c: In the case of that package, it was just pruning 'bzr diff' into a sane patch, dumping it in debian/patches, and adding it to debian/patches/series.
[22:53] <PasNox> I'm trying to create a package for my lib for oneiric, but the deb generation fails after a success build with error : http://paste.kde.org/144506
[22:54] <PasNox> do u have any hint on why ?
[22:54] <slangasek> infinity: yeah, that's a German typo :)
[22:54] <SpamapS> bah.. that will be updated based on the LIB_PREFIX ..
[22:54] <slangasek> PasNox: looks like your packaging has failed to install libfresh.so.1.0 into the binary packages
[22:55] <PasNox> the file exists but not in the same path that the fresh.so python binding file
[22:55] <slangasek> SpamapS: yep :)  But I wouldn't worry about that for now
[22:55] <infinity> slangasek: I don't actually consider this a good thing that I know the German layout well enough to know that.  I wonder what useful thing I've forgotten as a result.
[22:55] <SpamapS> slangasek: indeed, libmysqlclient18 is the one we need fixed
[22:55] <slangasek> SpamapS: it's not like X libs, where your headers have circular dependencies on the foreign-arch versions :P
[22:55] <sebner> slangasek: please put 500€ into an envelope and send it to DktrKranz drive 666, Italy
[22:55] <PasNox> slangasek: the file exists : http://wstaw.org/m/2011/11/10/plasma-desktoppU1919.jpg
[22:56] <PasNox> but i want to create 4 package, 2 -dev package and 2 libs package
[22:56] <angelo-c> infinity: really thanks, another army in my bag!
[22:56] <slangasek> PasNox: but what does 'find debian -name libfresh.so.1.0' return?
[22:57] <PasNox> slangasek: here is my control file that i build with cowbuilder : http://paste.kde.org/144512
[22:57] <PasNox> slangasek: the fresh lib is not installed system wide
[22:57] <slangasek> PasNox: if debhelper is told to install the library into one of the binary packages, dh_shlibdeps will automatically know how to find it.
[22:57] <slangasek> I understand that
[22:58] <slangasek> but it needs to be installed into the target directory for one of the binary packages you're building
[22:58] <slangasek> the error message indicates that it isn't
[22:58] <PasNox> i'm not familiar with creating package, it's my first try :D
[22:58] <angelo-c> inifinity: so what happens now to the package in oneiric proposed?
[22:59] <PasNox> slangasek: in the image i give the url some lines ago we can see fresh.so ( python lib binding ) and libfresh.so* exists but not in same folders )
[22:59] <PasNox> i then use *.install files to copy files in correct package folder
[22:59] <PasNox> currently i make install in the tmp folder, and move fiels using *.install rules
[22:59] <slangasek> PasNox: please show me the output of 'find debian -name libfresh.so.1.0' run from the package root
[22:59] <PasNox> yes, sorry
[23:00] <PasNox> slangasek: from which path i should execute this ?
[23:01] <slangasek> PasNox: from the top level of the directory where you built this and got the error message
[23:01] <slangasek> the directory above the one named 'debian' that contains your packaging
[23:01] <PasNox> i created a script for packaging the lib and then it's cowbuilder building the lib in a chrooted env so i have not the build folder
[23:01] <slangasek> but the command needs to be run after a failed build
[23:01] <slangasek> right
[23:01] <slangasek> so you need to tell cowbuilder to not throw away the build directory on failure
[23:02] <PasNox> ah ok, so let restart the build :)
[23:02] <slangasek> (there's a pbuilder option for this, but I don't use pbuilder so can't tell you what it is)
[23:02] <PasNox> ah, and how i can do that ?
[23:02] <PasNox> oki
[23:02] <slangasek> I guess there are others here who use pbuilder and can tell you
[23:02] <PasNox> i will add the commande before executeing the dh_install
[23:04] <PasNox> slangasek:
[23:04] <PasNox> find /tmp/buildd/fresh-1.1.0/debian -name libfresh.so.1.0
[23:04] <PasNox> /tmp/buildd/fresh-1.1.0/debian/tmp/usr/lib/x86_64-linux-gnu/libfresh.so.1.0
[23:05] <PasNox> as expected in the correct folder
[23:05] <slangasek> PasNox: that's not the correct folder :)
[23:05] <PasNox> xD
[23:05] <SpamapS> slangasek: first attemptted multiarch build starting...
[23:05] <slangasek> the correct folder would be /tmp/buildd/fresh-1.1.0/debian/libfresh/usr/lib/x86_64-linux-gnu/libfresh.so.1.0
[23:05]  * SpamapS will not attempt proper spelling tho
[23:06] <slangasek> PasNox: if find only shows it in the debian/tmp directory, this means it's missing from your libfresh.install file
[23:06] <slangasek> (also, 'libfresh' is the wrong name for a runtime library package; it should be named 'libfresh1')
[23:06] <PasNox> slangasek: ok, i will rename it once the package build fine ;)
[23:06] <bjsnider> PasNox, if you add a hook script it will preserve the build dir in pbuilder if the build fails. there's an example on the ubuntu wiki page for pbuilder
[23:07] <PasNox> slangasek: btw ias i said, as the make install will produce 4 package, i make install in tmp, and then use *.install fiels to mvoe files to correct folder
[23:07] <slangasek> PasNox: once the packaging for libfresh (or libfresh1) is correct, dh_shlibdeps will see it and generate the correct autodependency
[23:07] <PasNox> maybe this install file is run before the needed one ?
[23:07] <slangasek> dh_install needs to run before dh_shlibdeps
[23:07] <PasNox> let me check
[23:07] <slangasek> if you're using any of the common packaging tools, this will be done for you
[23:08]  * cjwatson waves a flag with "dh $@" written on it
[23:08] <slangasek> ooh, are you selling those at cafepress
[23:08] <PasNox> slangasek: http://paste.kde.org/144518
[23:08] <cjwatson> now there's an idea
[23:08] <PasNox> i call the dh_install in the 'install' rule ( so just after 'make install XXX'
[23:08] <PasNox> it's not the good place ?
[23:09] <slangasek> PasNox: oh, you inserted the find command directly in debian/rules?  That's not what I expected :)
[23:09] <cjwatson> DH_VERBOSE=1 in the environment is usually a good way to track down this kind of bug
[23:09] <slangasek> PasNox: what does debian/libfresh.install contain?
[23:09] <PasNox> slangasek: yes not optimal but it was working :)
[23:09] <PasNox> i will remove it after
[23:10] <PasNox> slangasek: libfresh.install: http://paste.kde.org/144524
[23:10] <PasNox> cjwatson: yeah i will activate it if i can't resolve easily this problem :)
[23:10] <slangasek> PasNox: ok... that .install file looks correct.  I think you want to double check, by getting the output of that find command *after* dh_install runs
[23:12] <PasNox> slangasek: http://paste.kde.org/144530 looks it's called before :/
[23:12] <slangasek> yes
[23:12] <slangasek> so move the 'find' command down a line :)
[23:12] <angelo-c> i saw tha bug was triaged for oneiric, so what's next?
[23:12]  * cjwatson refers to jml's "hack like an evil overlord" talk (you can google it): "If I have an unstoppable superweapon, I will use it as early and often as possible"
[23:13] <cjwatson> don't hold back your debugging tools that give you extensive traces of what's going on until you're already confused
[23:13] <infinity> angelo-c: Well, normally, next would be you submitting a debdiff for the proposed upload.  But since it's literally identical to the one I did yesterday (modulo version number), and you'd need it sponsored anyway, I'll spare you that hassle, and just do it in a bit.
[23:13] <slangasek> oh, oops
[23:13] <slangasek> Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file.
[23:13] <slangasek> PasNox: ^^ you need to call dh_makeshlibs
[23:13] <slangasek> by which I mean, you should replace this packaging with dh(1)
[23:14] <slangasek> because sequencing debhelper commands by hand is a waste of your valuable time :)
[23:14] <infinity> cjwatson: And this is why every command on my system is aliased to "strace $@"
[23:14]  * slangasek lols
[23:14] <angelo-c> infinity: thank you!
[23:14] <PasNox> slangasek: hm not sure i got u :/
[23:15] <slangasek> PasNox: you have a difficult to spot error in your debian/rules, which is that dh_makeshlibs must be called before dh_shlibdeps if you are building a shared library package.
[23:15] <PasNox> ok so i have to put this command before the seconds, let me check
[23:16] <slangasek> PasNox: this "difficult to spot error" would not exist if you were using dh(1) for your packaging, which is my current recommendation for all packages
[23:16] <cjwatson> PasNox: the point is that there exists a program which does all the commands in the right order for you
[23:16] <PasNox> hm ??
[23:16] <PasNox> i use dh_XXX tools it's not what to use ?
[23:16] <cjwatson> #! /usr/bin/make -f
[23:16] <cjwatson> %:
[23:16] <cjwatson>         dh $@
[23:16] <cjwatson> (starting point)
[23:16] <PasNox> slangasek: here are the result for before / after the dh_install call
[23:17] <PasNox> /tmp/buildd/fresh-1.1.0/debian/libfresh/usr/lib/x86_64-linux-gnu/libfresh.so.1.0
[23:17] <PasNox> /tmp/buildd/fresh-1.1.0/debian/tmp/usr/lib/x86_64-linux-gnu/libfresh.so.1.0
[23:17] <cjwatson> it understands qmake already so there's a fairly decent chance it will just work as is
[23:17]  * SpamapS <heart> dh7+
[23:17] <cjwatson> /usr/share/doc/debhelper/examples/rules.tiny, and 'man dh' for help on customising it if it does turn out that the defaults aren't quite right
[23:18] <cjwatson> this is one layer above the dh_* tools you are already using
[23:18] <slangasek> PasNox: yep.  add a call to dh_makeshlibs immediately before the call to dh_shlibdeps
[23:18] <slangasek> PasNox: then, once you've confirmed that this fixes your problem, replace your debian/rules with the stuff cjwatson is pointing to :)
[23:19] <PasNox> slangasek: ok, let try, thank u
[23:19] <broder> slangasek: you should file a bug against dh-make - i think it still spits out old-style dh_ rules files :)
[23:19] <slangasek> broder: I don't think that's the default anymore, is it?
[23:20] <slangasek> broder: dh_make(8) says it is not
[23:20] <broder> slangasek: ooh! it changed since i last looked. awesome
[23:20] <PasNox> btw i create the template using 'dh_make -c XXX' and it's what the ubuntu wiki told me to do :/
[23:21] <PasNox> i was using this how to: https://wiki.ubuntu.com/PackagingGuide/QtApplication
[23:21] <PasNox> so u say they are outdated ?
[23:21] <slangasek> PasNox: I don't think the documentation is outdated, that's still a reasonable way to create the template
[23:21] <slangasek> PasNox: what version of Ubuntu did you run this on?
[23:21] <SpamapS> dh_make spits out shiny new tiny rules files
[23:21] <PasNox> slangasek: kubuntu oneiric 64bits
[23:21] <SpamapS> and has for quite some time
[23:22] <slangasek> PasNox: ok.  Then there is a bug in dh_make, unfortunately
[23:22] <PasNox> xD ok
[23:22] <cjwatson> that's odd, I tested that recently
[23:23] <slangasek> cjwatson: maybe specific to some multipackage option chosen interactively?
[23:23] <PasNox> this was the command i used:
[23:23] <PasNox> dh_make -c "lgpl3" -f "$START_PWD/$FRESH_FILE_SRC" --createorig -l
[23:23] <cjwatson> perhaps; I just tested it with single-package and it gave me dh7
[23:23] <slangasek> PasNox: can you point me to the original upstream source for fresh, so I can test here?
[23:24] <PasNox> then i added new *.install *.dirs and package rule in the control files to create 4 package instead of 2
[23:24] <PasNox> shadeslayer:
[23:24] <cjwatson> same with -l, which I agree might have influenced this
[23:24] <PasNox> https://github.com/pasnox/fresh/tree/master/debian
[23:24] <PasNox> this is my current files for create / build the packages
[23:24] <PasNox> and i use the master working copy to be packaged
[23:25] <cjwatson> PasNox: can I have the output of 'dpkg-query -W dh-make'?  that debian/rules is not consistent with the version I'm looking at
[23:26] <PasNox> from where i should run that ?
[23:26] <cjwatson> a terminal, anywhere, doesn't matter
[23:26] <PasNox> cjwatson: dh-make 0.59
[23:26] <cjwatson> huh
[23:27] <cjwatson> well, then I don't understand this; the comment "This version is for packages that are architecture dependent" near the top of the file looks like it's from a template, but it's not in any of the current dh_make templates
[23:28] <PasNox> hm
[23:28] <PasNox> yeahs
[23:28] <PasNox> the
[23:28] <cjwatson> incidentally, I have to very strongly recommend against the practice in debian_fresh_packaging.sh of putting dh_make in a script
[23:28] <PasNox> dh_shXXX call shadeslayer say to add
[23:28] <PasNox> fix my problem
[23:28] <PasNox> :)
[23:29] <PasNox> the deb are built and they content what i wanted them to contains
[23:29] <cjwatson> it's something you run once at the very start, not something you should be putting in a script you run to update your package to new versions
[23:29] <PasNox> cjwatson: yes it's why it's in the function i no longer call
[23:29] <PasNox> but i keep it becasue it can help me later for create other package
[23:29] <PasNox> i'm so noob / new at creating package :)
[23:30] <slangasek> yeah, I can't reproduce this dh_make behavior
[23:31] <cjwatson> so shadeslayer advised you to replace the debian/rules template created by dh_make with this version?  in that case I think shadeslayer should take the blame for having to support the result :-)
[23:31] <slangasek> oh
[23:31] <PasNox> i do not understand xD
[23:31] <slangasek> cjwatson: I think that's tab-complete-error and he's saying that dh_makeshlibs fixed his error?
[23:31] <PasNox> i did not repalce the template rules files
[23:31] <PasNox> i jsut added what it seem to be a missing command
[23:32] <cjwatson> then none of us understand how that debian/rules got there in its current state
[23:32] <PasNox> ah
[23:32] <PasNox> xD
[23:32] <PasNox> what i'm sure is that it comes from a dh_make -c XXX call
[23:32] <cjwatson> you weren't running it in a chroot or something?
[23:33] <PasNox> no
[23:35] <SpamapS> slangasek: looks like cmake actually makes it pretty simple
[23:35] <PasNox> i commited in master my last rules file that works
[23:36] <cjwatson> now, the version in PackagingGuide/QtApplication looks like your version
[23:36] <PasNox> so now it create correct deb package, but it seem u say me my tempaltes are bad and i should recreate them from a clean  debian folder ?
[23:36] <cjwatson> and it's also based on /usr/share/doc/debhelper/examples/rules.arch from old (pre-oneiric) versions of debhelper
[23:37] <cjwatson> PasNox: we're not saying they're *bad* as such, we're saying that this entire conversation would have been unnecessary if you were using a modern rules format because you wouldn't have to micromanage which dh_* commands to call in which order
[23:37] <PasNox> cjwatson: i see, the problem is that i follow the how to from https://wiki.ubuntu.com/PackagingGuide/QtApplication
[23:37] <PasNox> so this is outdated ?
[23:38] <cjwatson> it is not adequate for libraries and it is not up to date with current recommendations
[23:38] <PasNox> oh i think i remember
[23:38] <cjwatson> it would be better off recommending /usr/share/doc/debhelper/examples/rules.tiny
[23:38] <slangasek> SpamapS: yeah, cmake was already multiarch-sorted in the first round :)
[23:39] <PasNox> possible i copy / paste the content from the how to in my rules files
[23:39] <PasNox> :/
[23:39] <PasNox> it's why it does not looks like the generated one ??
[23:39] <cjwatson> this sort of thing is really nice to remember so that you don't send people off on wild goose chases ;-)
[23:40] <PasNox> ok so the better, is to get rules.tiny and make changes to it and use this one instead of my current rules file ?
[23:40] <cjwatson> that would be my recommendation, yes.  you don't need to start again as far as the rest of the files under debian/ are concerned, though
[23:40] <SpamapS> is there a script somewhere to do a mass upload of all the rdeps of something? I want to do a test-rebuild against MySQL 5.5 in my PPA before raining down rebuilds on the main archive.
[23:41] <PasNox> cjwatson: ok, i will try that now, thanks u
[23:41] <cjwatson> 'man dh' has a bunch of examples of how to do little customisations - the idea is that you only have to describe how your package differs from normal
[23:41] <PasNox> and thank u all for your valuable help :)
[23:42] <slangasek> SpamapS: StevenK probably has such a script, but I'd think it's a shell oneliner
[23:43] <cjwatson> I use variations of http://paste.ubuntu.com/733682/ (and a for loop) for my mass rebuilds
[23:43] <SpamapS> Thats precisely what I need. :)
[23:44] <broder> SpamapS: i think you could do this with a really short shell loop combining tumbleweed's new rdepends service (http://qa.ubuntuwire.org/rdepends/) and backportpackage
[23:44] <cjwatson> wait for vi to appear, wait one second to be sure the timestamp has ticked over, :wq, check diff, enter
[23:44] <SpamapS> well, that and an unlicensed particle accelerator that I can carry on my back.. but.. need may be too strong for that..
[23:45] <cjwatson> SpamapS: if it's a biggish library soname transition, we can set up a transition tracker for it
[23:46] <cjwatson> all that needs is patterns for affected (which packages should we bother to look at, usually a regex on build-depends), good (usually a regex on depends), and bad (ditto)
[23:46] <infinity> cjwatson: libmysqlclient qualifies as big, yeah.
[23:47] <cjwatson> so what are the old/new sonames?
[23:47] <infinity> adconrad@cthulhu:~$ apt-cache rdepends libmysqlclient16 | wc -l
[23:47] <infinity> 164
[23:47] <cjwatson> er, package names
[23:47] <infinity> Old is anything <= 16, new is 18.  Looks like.
[23:48] <cjwatson> we can ignore < 16 for these purposes I think
[23:48] <cjwatson> given that we only have 16 in precise
[23:48] <infinity> Yeah, looks like < 16 got properly transitioned from where I'm sitting.
[23:48] <infinity> SpamapS: Verify that the new SOVER is 18?
[23:49] <infinity> SpamapS: I've only been half awake today.
[23:49] <slangasek> that's the sover he mentioned earlier
[23:50] <cjwatson> http://people.canonical.com/~ubuntu-archive/transitions/libmysqlclient.html should appear in a few minutes
[23:50] <cjwatson> anyone in https://launchpad.net/~ubuntu-transition-trackers can tweak it if I got it wrong
[23:50] <SpamapS> infinity: yes, its 18.. or at least, it was at 5.5.15 ..
[23:50]  * SpamapS re-checks 5.5.17
[23:50] <SpamapS> cjwatson: thank you
[23:51] <angelo-c> bye, thank you all!
[23:55] <slangasek> SpamapS: bah, mysql-5.1 ftbfs on amd64: https://launchpadlibrarian.net/84808548/buildlog_ubuntu-precise-amd64.mysql-5.1_5.1.58-1ubuntu2_FAILEDTOBUILD.txt.gz
[23:55] <slangasek> main.query_cache_28249                   [ fail ]
[23:56] <cjwatson> SpamapS: whoops, I got the good/bad regexes backwards; but you can look at that tracker page now and check the 'good' button to get a list of source packages
[23:56] <cjwatson> fixed for the next regen in an hour from now
[23:57] <PasNox> for the package name
[23:57] <PasNox> i should calle libfresh1 and libfresh1-dev ?
[23:57] <PasNox> or libfresh1 and libfresh-dev ?
[23:57] <PasNox> should name*
[23:58] <SpamapS> slangasek: hmm.. http://bugs.mysql.com/bug.php?id=43861
[23:58] <slangasek> ibfresh1 and libfresh-dev is best
[23:58] <cjwatson> I would normally recommend libfresh-dev, unless you think you're likely to be in a position to want to support people building against multiple different versions of the library in the same release
[23:58] <slangasek> sorry, libfresh1 of course
[23:59] <cjwatson> (which you probably aren't)
[23:59] <slangasek> SpamapS: so... give-back? :P
[23:59] <PasNox> ok, so let got for libfresh1 and libfresh-dev