[00:04] <slangasek> SpamapS: Reject Reasons:
[00:04] <slangasek> libmysqlclient18: lintian output: 'missing-pre-dependency-on-multiarch-support
[00:04] <slangasek> +', automatically rejected package.
[00:05] <slangasek> forgot that svn-buildpackage doesn't use debuild so doesn't call lintian :P
[00:08] <slangasek> SpamapS: so, bumping the debhelper build-dep and setting Pre-Depends: ${misc:Pre-Depends} per http://wiki.debian.org/Multiarch/Implementation is needed here
=== fisted_ is now known as fisted
[00:39] <Daviey> infinity: Do you think you'll be able to look at bug 759545 before a1?
[00:39] <ubottu> Launchpad bug 759545 in grub2 (Ubuntu Precise) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged] https://launchpad.net/bugs/759545
[00:42] <slangasek> given that infinity is still bootstrapping armhf, I wouldn't count on it
[00:44] <Daviey> slangasek: thanks.
[00:59] <SpamapS> slangasek: ACK, will fix and make sure to run lintian
[00:59] <slangasek> SpamapS: ta
[01:06]  * SpamapS slogs through missing/broken perl deps...
[01:24] <SpamapS> slangasek: so, can we re-use 5.5.17-3 or do we need to bump to 5.5.17-4 ?
[01:34] <poolie> does USC have an option to install stuff from tarballs or is this user just confused about tarballs vs debs?
[01:38] <SpamapS> slangasek: anyway, bumped to 5.5.17-4. I'll be in the mountains for the next 3 days, so hopefully this one works. :)
[01:50] <slangasek> SpamapS: thanks, building
[01:51] <slangasek> SpamapS: btw, Pre-Depends: ${misc:Pre-Depends} should have been sufficient here, the substition gets expanded to multiarch-support
[01:51] <slangasek> (so the explicit declaration is a redundant no-op)
[02:01] <SpamapS> slangasek: *ahhh*
[02:19] <slangasek> SpamapS: lintian doesn't think much of your debian/copyright. ;) uploading anyway
=== RoAkSoAx is now known as roaksoax
=== roaksoax is now known as andreserl
=== andreserl is now known as roaksoax
[04:14] <infinity> Daviey: What vorlon said.  I might find time, but armhf is everything right now.  And she'll hit me if I say otherwise.
[05:02] <pitti> Good morning
[05:03] <pitti> slangasek: no worries, it wasn't a bad breakage; but I thought it was a good candidate/exercise for reversion, as per Rick's new policy
[05:23] <ScottK> What policy is that?
[05:24] <pitti> ScottK: "never break precise"
[05:25] <pitti> ScottK: well, less of a policy, more a set of best practices
[05:25] <ScottK> So all those times when we broke the development release before were on purpose?
[05:25] <ScottK> Good thing we have the new policy to avoid it...'
[05:25] <pitti> if we introduce a regression that breaks daily images or upgrades, and reverting it doesn't make things worse, we sohuld revert
[05:25] <ScottK> ;-)
[05:25] <ScottK> Right.  I remember something about that now.
[05:26] <pitti> and for bigger transitions, we need to come up with a staging area solution (such as using -proposed and running automatic tests against that), but that hasn't been fleshed out fully yet
[05:26] <ScottK> We could all is "Unstable".
[05:26] <ScottK> all/call
[05:29] <pitti> ScottK: we'll never get this perfect anyway, but there have been several situations in the past where breakage has been sitting there for days and weeks, so a little more rigor there is certainly adequate
[05:29] <ScottK> I agree with that.
[07:46] <dholbach> good morning
[07:59] <freeflying> slangasek: procps (1:3.2.8-11ubuntu4) failed again
[08:25] <slangasek> freeflying: failed how?
[08:43] <freeflying> slangasek: Errors were encountered while processing: procps
[08:43] <freeflying> E: Sub-process /usr/bin/dpkg returned an error code (1)
[08:44] <slangasek> freeflying: not reproducible, need the full error message please
[08:45] <pitti> I ran my oneiric VM, switched apt to precise, apt-get install procps -> fine
[08:46] <pitti> freeflying: locally modified conffile perhaps? as a workaround to the previous failure?
[08:46] <pitti> precise(yesterday) -> precise(today) on my workstation also worked, FTR
[08:47] <freeflying> slangasek: http://paste.ubuntu.com/742035/
[08:48] <slangasek> freeflying: is this a chroot?
[08:48] <freeflying> slangasek: no
[08:48] <slangasek> hmm
[08:48] <freeflying> pitti: fresh installation with today's daily build iso, previous was 3.2.8-11ubuntu3
[08:49] <slangasek> well, that's a pretty generic upstart failure.  What happens if you try to manually run the command from /etc/init/procps.conf?  cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p -
[08:51] <freeflying> slangasek: manually run is fine
[08:51] <slangasek> freeflying: is it a locally modified conffile maybe, like pitti asks?
[08:51] <slangasek> oh, you said it's a fresh install
[08:51] <freeflying> slangasek: no
[08:51] <slangasek> so probably not
[08:51] <slangasek> :)
[08:52] <slangasek> freeflying: can you do 'initctl log-priority info', try to configure the package again, and then check /var/log/kern.log for any information from upstart?
[08:56] <freeflying> slangasek: nothing output to kern.log
[08:56] <broder> slangasek: ...kern.log? do we even still use that?
[08:56] <slangasek> don't we?
[08:56] <pitti> sure we do
[08:56] <broder> i thought we rolled everything into syslog
[08:57] <broder> huh. i stand corrected
[08:57] <slangasek> no, only the things that it's reasonable to merge :)
[08:57] <pitti> broder: we got rid of /var/log/messages
[08:57] <pitti> which was really redundant, given sys/auth/kern logs
[08:58] <slangasek> freeflying: please post a copy of whatever file you have as /etc/init/procps.conf currently; also, please show 'initctl list | grep procps'
[09:02] <freeflying> slangasek: http://paste.ubuntu.com/742046/
[09:02] <freeflying> slangasek: initctl list | grep procps
[09:02] <freeflying> procps stop/waiting
[09:02] <slangasek> freeflying: well, that looks correct
[09:04] <slangasek> freeflying: when you ran the command by hand, did it return 0?
[09:04] <freeflying> slangasek: which one
[09:05] <slangasek> freeflying: the 'cat ... | sysctl' one
[09:05] <freeflying> slangasek: yes, return 0
[09:05] <infinity> cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p - || echo Bollocks.
[09:14] <cjwatson> SpamapS: which missing/broken perl deps did you run into?  (I have a full report, I'm just interested in which of the 14 remaining problems bit you)
[09:23] <Mirv> does someone know the definitive list of needed kernel config options to have ureadahead working?
[09:24] <Mirv> google is not much of a friend this time, or the information is obsolete, or I'm having some unrelated problem. for example it seems CONFIG_ENABLE_DEFAULT_TRACERS is no more.
=== dholbach_ is now known as dholbach
[09:53] <dbarth> rickspencer3: ping?
[09:54] <rickspencer3> hi dbarth
[09:54] <rickspencer3> s'up?
[09:54] <dbarth> hi
[10:07] <ev> @pilot in
=== udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | archive.u.c mirroring broken | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev
=== _salem is now known as salem_
[12:04] <highvoltage> dholbach: hey there, edubuntu.org is down and I filed a ticket on RT, do you know if there's anyone in particular I could (or should) poke about that?
[12:05] <dholbach> highvoltage, #canonical-sysadmin
[12:05] <dholbach> I'd simply ask in there
[12:05] <dholbach> highvoltage, and http://edubuntu.org/ works for me
[12:06] <highvoltage> ah, and so it does for me now. that was fast :)
[12:06] <zumbi_> ogra_: hi!
[12:06] <ogra_> hey :)
[12:07] <zumbi_> ogra_: re ubuntu core, I wonder how gcc cross fits, as it is multiarch, so it links to system libraries
[12:07] <zumbi_> ogra_: so imagine my product uses distro suite N and my host is suite N+2
[12:08] <zumbi_> ogra_: if I cross compile my app against multiarch system libraries, it will link to suite N+2
[12:08] <ogra_> oh, i think that might get you into probs
[12:08] <zumbi_> ogra_: thats why a sysroot enabled cross tool migh tbe useful
[12:08] <ogra_> not sure though, hrw is our cross toolchain specialist
[12:09] <ogra_> and riku 8as i said in the other channel) works on porting packages to cross buildability
[12:09] <zumbi_> yes, I have contact to these people, I follow what they do too
[12:09] <ogra_> we also have a spec for that for 12.04 to get a subset of packages cross functional
[12:09] <ogra_> but i fear you need to use the same release version for both atm
[12:10] <zumbi_> I just wanted to point out a possible pitfall, now that you seem to be going commercial with it
[12:10] <zumbi_> I have to say I am very please to see it happening
[12:10] <ogra_> yeah, it was overdue
[12:10] <zumbi_> *pleased
[12:11] <ogra_> we will still go on building the distro natively on the buildds though :)
[12:11] <zumbi_> sure, cross compiling the debian core from scratch is not easy task
[12:11] <ogra_> well, its a future target for linaro
[12:11] <ogra_> some day they will make it :)
[12:12] <zumbi_> ogra_: as a hobby project, which I have no time for, I wanted to create a mini-core based around busybox and uclibc
[12:13] <ogra_> well, that will surely get you a lot of trouble if you start using "normal" packages ... the busybox tools are to different in many earas
[12:13] <zumbi_> that might be interesting for a future milestone too
[12:13] <ogra_> *areas
[12:13] <ogra_> iirc that was discussed at UDS ...
[12:14] <zumbi_> ogra_: surely it would be incompatible with normal packages, but maybe we could find a way to upgrade from uclibc minimal core into eglibc core
[12:14] <ogra_> what i would do to get a minimal system would just be using update-initramfs turn it into a tarball ;)
[12:14] <hrw> zumbi_: if you want sysrooted cross toolchain then you can build it ;D
[12:14] <ogra_> +and
[12:14] <zumbi_> hrw: yep, thats for sure
[12:15] <zumbi_> hrw: but I dont think thats the binary based distro mindset
[12:15] <hrw> yep
[12:16] <zumbi_> ogra_: uhm.. initramfs rootfs tarball, might be kinda of curious
[12:16] <ogra_> the prob with these minimal fses is that at some point you want a package tool ...
[12:16] <ogra_> which in the end forces you to have perl (dpkg) and pathin (apt)
[12:16] <ogra_> *python
[12:17] <ogra_> which then bloats the rootfs, no matter how small it was initially
[12:17] <zumbi_> ogra_: yes, but busybox has dpkg replacement
[12:17] <ogra_> which doesnt help with maintainer scripts :)
[12:17] <zumbi_> I got mini python, kernel and uclibc minimal system in 2.5MB :)
[12:18] <zumbi_> ogra_: indeed, it would require another pool of packages, not compatible with main pool
[12:18] <ogra_> indeed, but at what compatibility level ?
[12:18] <hrw> I got x11, wifi, bt, pim, glibc, kernel in 16MB
[12:18] <hrw> with package management - but not debian/ubuntu
[12:18] <zumbi_> hrw: thats huge :P
[12:19] <hrw> zumbi_: ok, I got ~2MB free in this flash too ;d
[12:20] <zumbi_> hrw: hey.. you and your open embeddish hat :)
[12:21] <zumbi_> well, I'll have a look to ubuntu core stuff, its great to see it happening
[12:21] <ogra_> :)
=== MacSlow is now known as MacSlow|lunch
[12:58] <dantti> cnd: ping
[13:50] <ogra_> pitti, poke
[13:50] <ogra_> pitti, looking at http://status.ubuntu.com/ubuntu-precise/ubuntu-arm.html i'm wondering why all WIs from foundation team members show up for https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-lts-upgrades in our chart
[13:51] <ogra_> doko__ and infinity are in ubuntu-arm, but why do mvo's items show up there ?
=== MacSlow|lunch is now known as MacSlow
[14:17] <herton> pitti: hi, I noted some packages are on universe instead of main, if you can take a look: http://archive.ubuntu.com/ubuntu/pool/universe/l/{linux,linux-lts-backport-natty,linux-lts-backport-maverick} and http://ports.ubuntu.com/pool/universe/l/{linux-ti-omap4,linux-fsl-imx51,linux-ports-meta,linux-meta-ti-omap4,linux-lts-backport-natty,linux-lts-backport-maverick} and http://ports.ubuntu.com/pool/universe/l/linux/ (this last one only the hardy 3
[14:17] <herton> 0.96 pkgs)
[15:41] <cnd> dantti, pong
[16:03] <pitti> herton: meh, one of these days we need to fix this more permanently
[16:07] <pitti> herton: do you happen to have an automatically generated report for this somewhere, which includes the corresponding releases?
[16:07] <mterry> doko__, you around?  Curious whether you were going to grab the ocaml merge or whether you want to hand it off
[16:07] <herton> pitti: unfortunately no, I'm thinking about writing a tool to verify it and produce a report though
[16:08] <pitti> jdstrand: ^ for example, the security team has a script which yells "archive is broken" on ABI inconsistencies, but unfortunately it doesn't check components
[16:08] <cjwatson> pitti: there's pocket-mismatches in cocoplum:~lp_archive/dak/, although it has kind of noisy output and I haven't got round to putting it somewhere public yet
[16:08] <cjwatson> if that helps
[16:09] <jdstrand> mdeslaur has that script these days
[16:20] <pitti> herton: I think I caught them all, but might have missed some; need to check again later/after meeting/Monday
[16:20] <herton> pitti: ok, thanks
[16:21] <pitti> then pocket-mismatches should have a more useful output again, too
[16:22] <pitti> and in fact the very ones I just moved aren't even in there
[16:22] <dantti> cnd: hi, I'm trying to probe the battery status of my apple trackpad/keyboard, and I saw you were the one that added support for it, I see it has a feature 71 that seems to be battery stuff, do you have any hints on how to probe that?
[16:23] <pitti> ah, it's split by release, nevermind
[16:23] <dantti> cnd: do I have to code this on hid or is it possible to write some app that can talk to hid directly?
[16:24] <doko__> mterry, ok, I can do that, will look at it tomorrow
[16:24] <mterry> doko__, oh sweet, thanks
[16:24] <mterry> tomorrow is saturday!  I don't want it that bad  :)
[16:26] <doko__> yeah, have to take care about my mobile contract which was terminated without reason while I was in the US ...
[16:29] <cjwatson> doko__: bug 891720 needs to be fixed quickly; can you do it, or want me to?
[16:30] <ubottu> Launchpad bug 891720 in icedtea-web (Ubuntu Precise) "missing replaces between icedtea-next-common, icedtea-netx" [High,Triaged] https://launchpad.net/bugs/891720
[16:33] <cnd> dantti, I don't really know
[16:33] <cnd> that comment in the code was from the guy who wrote the magic mouse support
[16:34] <cnd> I just added magic trackpad support onto it
[16:34] <cnd> if you have a mac, you can sniff the hid packets and maybe figure it out
[16:34] <cnd> that's what I did to reverse engineer the input protocol for the trackpad
[16:35] <cnd> by "have a mac", I mean if you "have OS X"
[16:35] <dantti> cnd: hmm I don't :P
[16:35] <dantti> I tried to run it on VBox but didn't worked...
[16:35] <cnd> dantti, you could try poking at it with different feature report values, but I have no clue how successful you would be :)
[16:36] <dantti> cnd: right but how do I do that?
[16:36] <cnd> dantti, modify the hid-magicmouse module
[16:36] <dantti> as it really seems that if I ask the feature 71 it would report that but I have no clue on how to do that :P
[16:36] <cnd> or maybe use hidraw somehow
[16:37] <doko__> cjwatson, need to run to the shop. will do it within the next hour
[16:37] <dantti> hmm right there is no such nice hid lib.. :P
[16:37] <dantti> cnd hidraw can be used by an user space app?
[16:38] <cjwatson> doko__: thanks
[16:38] <cnd> dantti, I think so
[16:38] <cnd> I've never used it myself
[16:38] <dantti> cnd: hidraw or the mouse? :P
[16:39] <dantti> well probaly the former..
[16:39] <cnd> hidraw
[16:39] <cnd> I have both a mouse and a trackpad :)
[16:40] <dantti> cnd: I have a keyboard and a trackpad, the keyboard I received broken from my boss but it stopped working and I'm not sure if it was because of the batteries, that's why I want this to work...
=== dendrobates is now known as dendro-afk
[16:43] <hallyn> zul, oh hey, are you piloting this afternoon?
[16:44] <hallyn> zul,  today is my first turn.  can i co-pilot with you if you do this afternoon?  :)
=== dendro-afk is now known as dendrobates
[16:48] <pitti> ev: accepted https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-crash-signatures for precise, so that it'll appear in the WI tracker
[16:49] <hallyn> eh, maybe i'll just focus on virt patches
[16:50] <Daviey> hallyn: Have you seen, https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Patch_Pilots ?
[16:51] <hallyn> Daviey, yup
[16:51] <hallyn> its what i'm looking through this morning
[16:54] <SpamapS> cjwatson: I'm still not entirely sure, but one was libsvn-perl .. I did start my dist-upgrade right before the transition, so it was likely a transient problem
[16:54] <ev> pitti: cheers!
[16:54] <cjwatson> SpamapS: libsvn-perl is fixed
[16:54] <SpamapS> cjwatson: update/install forcibly fixd it
[16:55] <cjwatson> http://people.canonical.com/~ubuntu-archive/transitions/perl5.14.html <- remaining problems
[16:56] <cjwatson> there's a doc-base upgrade bug (awaiting perl sync) and possibly an update-inetd problem with samba which will be a replay of the previous one; fixes for both in progress
[16:56] <SpamapS> cjwatson: yeah it seems all of it is working now.
=== Topic unset by hallyn on #ubuntu-devel
[16:57] <hallyn> wtf
=== cjwatson changed the topic of #ubuntu-devel to: Precise open for uploads | archive.u.c mirroring broken | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev
[16:57] <hallyn> cjwatson, thanks
[16:57] <cjwatson> ~praise topic-diff.pl
[16:59] <SpamapS> cjwatson: I think the other one was libdbi-perl
[16:59] <cjwatson> that's fixed too
[16:59] <SpamapS> cjwatson: which I just now got back by re-installing mysql-client
[16:59] <cjwatson> you must have been fairly early in the transition
[17:03] <SpamapS> slangasek: About that copyright file and dep5 ... I think I want to raise a bug in the dep5 format that encourages hyper redundancy.
[17:04] <SpamapS> slangasek: the missing paragraphs are identical to all the other paragraphs of the same type... so I'm thinking we should be able to just say "Standard GPLv2 header md5sum affaed8daf7af7faf8..." or something like that.
=== dendrobates is now known as dendro-afk
[17:09] <slangasek> SpamapS: you're supposed to be able to have a stand-alone License: paragraph that other paragraphs can refer to?
[17:10] <slangasek> SpamapS: but the spec is currently not clear about this, which is one of the things that needs fixed before I'll personally bless the spec
[17:11] <SpamapS> slangasek: definitely not clear, I read it as License: is always attached to Files:
=== beuno is now known as beuno-lunch
[17:14] <SpamapS> slangasek: its possible I could have put this Comment: as the paragraph I suppose..
[17:15] <SpamapS> Comment: These files fall under the blanket license specified in the file COPYING
[17:15] <SpamapS> License: GPL-2
[17:15] <slangasek> SpamapS: Standalone License Paragraph (Optional, Repeatable)
[17:16] <slangasek> SpamapS: please raise this issue on debian-project, this ambiguity is critical :)
[17:16] <SpamapS> slangasek: is that new?
[17:16] <SpamapS> I admit I have not tracked changes to it since I first read it over a year ago.
[17:17] <slangasek> it may have been rearranged, but it's not new in the past year
[17:18] <Daviey> dep-'s having ambiguity shocker.
[17:18] <SpamapS> slangasek: hrm.. ok, well I totally missed the standalone license bits. I think I could save 500 lines in the copyright file with that.
[17:18] <SpamapS> given that it is 762 lines.. thats significant. :)
[17:21]  * slangasek nods
[17:22] <SpamapS> actually I think I already made that optimization
[17:23] <SpamapS> I just forgot the bit about the standalone license paragraph
[17:23] <broder> slangasek: gah. vmware just released an update to vmplayer that still has the buggy insserv call
[17:24] <slangasek> \o/
[17:24] <slangasek> yes, I meant to buttonhole them at UDS about it and never got a chance
[17:24] <broder> no, no. it's still broken
[17:24] <slangasek> that was an ironic \o/, see how the hands list a little bit to the left
[17:24] <broder> ah, i see that now :)
[17:25] <broder> the worst part is that the shell script has a comment "# Ubuntu will spew unrelated warnings..  Hide these."
[17:26] <SpamapS> hrm is there a way to run a single lintian check outside of lintian?
[17:27] <broder> SpamapS: there's a --tags argument to lintian
[17:37] <SpamapS> broder: no I just want to run a single check standalone
[17:37] <SpamapS> broder: like not against a .dsc ..
[17:37]  * SpamapS curses svn-buildpackage for not being able to build w/ local changes
[17:38] <broder> SpamapS: i haven't dug into it enough to know for sure, but i don't think lintian is architected to allow that
[17:38] <broder> but not really sure
[17:38] <SpamapS> yeah
[17:38] <SpamapS> easier to just workaround svn-buildpackage's deficiencies
[17:39] <cjwatson> I'd tend to agree with broder; at the very least you'd have to somehow arrange to run the appropriate collection scripts as well and put their output somewhere
[17:43] <slangasek> broder: unrelated warnings! awesome
[17:44] <slangasek> SpamapS: svn-buildpackage --svn-ignore-new
[17:44] <broder> slangasek: do you remember off the top of your head the LP bug about this? i'm having a hard time finding it
[17:44] <slangasek> or, bzr branch svn+ssh:// [...] && bzr bd ;P
[17:45] <slangasek> broder: not off the top of my head, just off the middle of my mail; one sec
[17:45] <slangasek> broder: bug #858122
[17:45] <ubottu> Launchpad bug 858122 in sysvinit (Ubuntu Precise) "incomplete migration to /run (shutdown script order has been demolished)" [High,Triaged] https://launchpad.net/bugs/858122
[17:45] <broder> thanks
[17:48] <SpamapS> slangasek: does that actually keep local changes?
[17:48] <slangasek> SpamapS: yes; you do have to 'svn add' any new files before calling it, I think
[17:49] <zul> hallyn: sure
[17:53] <dantti> cnd: I'm compiling the mouse module, I'm just not sure about what u8 features means, do you know why it has two values?
[17:55] <cnd> dantti, they are magical values that make the devices change modes
[17:55] <cnd> you'll have to figure out the magical values for getting battery information
[17:56] <dantti> cnd: right my guess is that the value is 71, so it would be __u8 features[] = { 71 };  ?
[17:56] <cnd> I don't know :(
[17:56] <cnd> well, yes, what you wrote is correct
[17:56] <cnd> I meant I don't know if 71 is the value
[17:57] <cnd> sorry if I sound confused, I'm juggling conversations :)
[17:57] <dantti> cnd: ok, the features the device returns seems to be so..  also from a report from hadess 71 is reported as Battery_Strength
[17:58] <cjwatson> jdstrand: we seem to be carrying a patch to iptables introduced by you which installs .la files when Debian doesn't.  this seems like the wrong direction and causes a build failure in collectd (after I fix the first thing it's failing on) - can you explain why it's needed?
[17:58] <dantti> cnd: the min and max goes from 0 to 100 ... :P hopefully this will work ..
[17:58] <cnd> cool
[17:59] <jdstrand> cjwatson: that didn't originate with me, but I merged it. I am assuming you are talking about 9001-build-libipq_pic.la.patch?
[17:59] <cjwatson> no, I'm talking about one that did originate with you, according to the changelog
[17:59] <cjwatson> +  [ Jamie Strandboge ]
[17:59] <cjwatson> [...]
[18:00] <cjwatson> +  * debian/iptables-dev.install: install lib/*.la in usr/lib
[18:00] <cjwatson> those files should in general not be installed unless there is a reverse-dependency that hasn't been weaned off them yet
[18:00] <cjwatson> in this case one of the dependency_libs entries is wrong
[18:01] <jdstrand> I actually that is from 1.4.3.2-2ubuntu1 in karmic
[18:01] <jdstrand> from nxvl
[18:01] <cjwatson> really?  it's not changelogged there
[18:01] <cjwatson> 9001-build-libipq_pic.la.patch is not a problem
[18:02] <nxvl> that was a FTBFS IIRC, right?
[18:02] <nxvl> back around barcelona
[18:02] <jdstrand> let me put it this way. my intent was to just pull what came before along. If I messed up, please correct it :)
[18:03] <cjwatson> it's not in http://patches.ubuntu.com/by-release/atomic/ubuntu/i/iptables/iptables_1.4.3.2-2ubuntu1.patch.bz2 either
[18:03] <cjwatson> (well, there's a .la entry there but it's commented out
[18:03] <cjwatson> )
[18:06] <jdstrand> cjwatson: the bottom line is I'm happy to fix it. I can't really explain why it is there
[18:06] <cjwatson> jdstrand: ok, well, I can take it out and test collectd with the fixed version if you're cool with that
[18:06] <jdstrand> I should have looked at that more closely during the merge
[18:06] <cjwatson> just wanted to check it wasn't deliberate
[18:06] <jdstrand> cjwatson: I'm totally cool with that :)
[18:07] <cjwatson> ideally I'd like to scan to check it isn't used ...
[18:09] <jdstrand> cjwatson: ah I remember the history of that changelog entry (1.4.10-1ubuntu1). someone submitted a merge request, but didn't merge a bunch of stuff. I was attempting to give the submitter as much credit as possible, but the parts he missed I put under me
[18:09] <jdstrand> cjwatson: that doesn't mean that I didn't screw up or that I shouldn't have looked at that bit more closely of course :)
=== doko__ is now known as doko
[18:11] <doko> mterry, ocaml uploaded
[18:12] <mterry> doko, cool, thanks
[18:13] <jdstrand> cjwatson: looking at a debdiff between lucid and natty, it looks like I did goof
[18:13] <jdstrand> cjwatson: and inverted the .a and the .la
[18:14] <cjwatson> ok - I'm just getting hold of aba's script to test whether it's safe to remove the .la entirely
[18:14] <cjwatson> or whether we need to just take out dependency_libs
[18:14] <jdstrand> cjwatson: k, sorry about that
[18:14] <cjwatson> so I can sort it out once I've done that
[18:14] <cjwatson> np
=== beuno-lunch is now known as beuno
[18:20] <hallyn> @pilot in
=== udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | archive.u.c mirroring broken | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev, hallyn
[18:27] <hallyn> zul, all right, i guess i'll take another stab at this libvirt migration on lucid one
[18:27] <zul> sweet
[18:30] <dantti> cnd: do you know where hid_output_raw_report store the return data?
[18:31] <cnd> dantti, no, sorry
[18:31] <cnd> I really don't know much about hid
[18:31] <dantti> cnd: k, thanks
[18:31] <cnd> I only knew the very least amount to be able to sniff packets using OS X software and then take what was already in hid-magicmouse and rework it for the trackpad
[18:32] <cnd> dantti, you can ask on the linux-input mailing list
[18:32] <cnd> that is the best source for answers to questions about hid and input in general
[18:33] <dantti> cnd: right thanks, if I can't find anything in google or on any other hid driver I'll try that
=== Guest54373 is now known as Lutin
[19:17] <dantti> cnd: ok, it's was not output_raw... I should use get_... now I have G�Dp as %s what do you think?
[19:56] <hallyn> jdstrand, for bug 869553, are you working on the patch for upstream (and precise), or should I push/test that?  Is regular qa-regresion-testing (with -m to test migration) sufficient, or were you planning to write some new test for it?
[19:56] <ubottu> Launchpad bug 869553 in libvirt (Ubuntu) "Apparmor prevents KVM tunnelled migration" [High,Triaged] https://launchpad.net/bugs/869553
[19:57] <hallyn> i'd be nice if I could push the fixes for that and bug 869590 into lucid-proposed together :)
[19:57] <ubottu> Launchpad bug 869590 in libvirt (Ubuntu Lucid) "KVM migration fails when tunnelled due to parsing error in qemu monitor" [Medium,In progress] https://launchpad.net/bugs/869590
[20:24] <hallyn> maybe a silly question...  is verifying verification-needed bugs in SRU queue an ok thing to do on patch pilot time?  :)
[20:25] <hallyn> (it does hold up patches, so I assume so...)
[20:30] <jdstrand> hallyn: I am not actively working on it
[20:30] <hallyn> jdstrand, cool, thanks.
[20:30] <jdstrand> hallyn: feel free to push it upstream
[20:31] <jdstrand> (and into precise)
[20:31] <hallyn> ok, will do.
[20:31] <jdstrand> thanks! :)
[20:31] <hallyn> (want to finish up with the 0.9.7 merge first;  but that sort of conflicts with the patch piloting way;  so it feels weird :)
[20:33] <slangasek> hallyn: I don't think anyone's going to slap you for doing SRU verification, though it isn't actually in scope for patch piloting
[20:34] <hallyn> slangasek, ok, thanks.
[20:36]  * hallyn biab
[20:48] <ivacco> help
[20:49] <slangasek> ivacco: this is not a help channel; you probably want #ubuntu
[20:50] <ivacco> not, i like information about how contribute for development of ubuntu
=== salem_ is now known as _salem
[21:13] <ivacco> i like information about how contribute to development of ubuntu.
[21:14] <slangasek> ivacco: this is probably a good starting point: https://wiki.ubuntu.com/ContributeToUbuntu
[21:24] <slangasek> pitti: I think someone in the session for https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-power-consumption volunteered to look into the black/white screen question, do you recall who?
[21:28] <hallyn> so i gather once i'm done with a patch, i shoud unsubscribe ubuntu-sponsors?
[21:29] <infinity> hallyn: Doesn't really matter if the bug gets closed.
[21:30] <infinity> hallyn: (And, on the flipside, if the bug is reopened, only sponsors are in a position to do anything about it, since the original patch submitter obviously doesn't have access to)
[21:30] <hallyn> well its ending in sru, so closing could still take awhile
[21:30] <hallyn> ok
[21:30] <hallyn> won't do that then, thx :)
[21:30] <infinity> hallyn: See second point.  If the SRU team finds the fix defficient, a sponsor may still need to be involved.
[21:30] <infinity> ;)
[21:31] <broder> i'd prefer if sponsors were unsubscribed if a bug isn't blocking on sponsor action
[21:31] <broder> i think the SRU team generally resubs sponsors when necessary
[21:32] <infinity> broder: I'm not sure if that theory holds up in practice, but *shrug*... That workflow also sounds sane, if it happens.
[21:32] <broder> leaving them subscribed clutters the queue, which generally causes the sponsorship process to take longer
[21:32] <hallyn> right, i was thinking of reducing the clutter;  but OTOH we don't want bugs to get lost...
[21:32] <broder> when i'm worried about that, i usually subscribe to the bug myself
[21:32] <hallyn> that's what i was just thinking
[21:33] <broder> it might not be ideal, but it is generally effective
[21:33] <hallyn> so i think that's what i'll do.  thanks guys
[21:33] <hallyn> i can always re-subscribe sponsors if it turns out i failed :)
[21:33] <hallyn> oh i was worried aobut nothing - i can't do it anyway :)
[21:33] <broder> i may be unusually allergic to cruft in the queue, though
[21:42] <tumbleweed> whenever I unsubscribe sponsors, I add a comment saying "if you need us, please re-subscribe us"
[21:42] <tumbleweed> (well, a little more fleshed out...)
[21:43] <infinity> "Thank you for using our sponsorship services.  We hope you were satisfied with our product today, and should you need us again, please don't hesitate to re-subscribe us"?
[21:44] <tumbleweed> heh
[21:47] <dupondje> pitti: kenvandine: Uploaded fixes for papyon: https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349
[21:47] <ubottu> Launchpad bug 887349 in papyon (Ubuntu Lucid) "Can't login in Windows live acount using empathy" [High,Triaged]
=== EyesIsServer is now known as EyesIsAsleep
[22:40] <SpamapS> slangasek: FYI, silenced the lintian warnings about the copyright file for the next upload...
[22:41] <SpamapS> slangasek: speaking of that.. should the next thing be to merge experimental into precise, and start the libmysqlclient transition?
[22:42] <SpamapS> slangasek: or do we need a DD to start all the binNMU rebuilds in experimental first?
[22:52] <slangasek> SpamapS: well, binNMU rebuilds in experimental aren't going to happen on their own, you'd need to talk somebody into doing such a rebuild test; maybe it's more straightforward to do your own rebuild testing, and then discuss with the +1maint team how and when it's best to add that to precise?
[22:58] <hallyn> @pilot out
=== udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | archive.u.c mirroring broken | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev
[23:17] <SpamapS> slangasek: sorry, I don't really grok the debian release process yet. I'll gladly do a full rebuild test on my own.. but then who is this +1maint team and how would I contact them?
[23:17] <slangasek> SpamapS: https://wiki.ubuntu.com/PlusOneMaintenanceTeam
[23:18] <SpamapS> AHHH that
[23:18] <slangasek> SpamapS: the reason binNMUs don't happen automatically for experimental is that packages don't transition from experimental to unstable without an upload
[23:18] <slangasek> which means everything would be binNMUed again once the lib hits unstable
[23:18] <SpamapS> slangasek: right so I'd need to do my own tests, file bugs for things that need changing, and then give people time to fix them in experimental before moving 5.5 to unstable?
[23:19] <slangasek> that's considered best practice, yes
[23:19] <SpamapS> sounds reasonable. I'll start a mass rebuild tonight...
[23:19] <slangasek> because mysql-5.1 is a separate source package, it's technically possible to transition mysql-5.5 to testing before all the revdeps are converted, so I don't think you need to coordinate with the Debian release team on this one
[23:20]  * SpamapS wonders if Lucas Nussbaum's tools are available for reporting on the results
[23:20] <slangasek> but for precise, coordination with +1maint is a good idea
[23:20] <slangasek> SpamapS: I guess you should ask lucas :)
[23:21] <SpamapS> Yeah I'll do that all next week. Just getting the list of what FTBFS will be useful.
[23:21] <slangasek> cjwatson: libdbd-sybase-perl and unixodbc-gui-qt both uploaded to unstable
[23:26] <cjwatson> slangasek: thanks, I'll sync those once LP notices them
[23:26] <cjwatson> SpamapS: I think we will have space for another transition in precise early next week, if that works for you
[23:36] <SpamapS> cjwatson: Yes, I'll try to get an intial test rebuild done on my box over the weekend so we can skip obviously broken stuff.
[23:37] <SpamapS> assuming the wind stops blowing at 40mph tomorrow I won't need my box as I'll be sailing down mammoth mountain.. ;)
[23:38] <SpamapS> ok no more working ,time to enjoy holidaying
[23:38]  * slangasek waves