[00:01] <bryceh> hud sure spews a lot of errors and warnings
[00:01] <bryceh> think those are all subsequent to the crash though
[00:07] <bryceh> interesting; elmo's stacktrace does not match the one upstream
[00:17] <smoser> if someone can help, i *just now* uploaded a cloudinit at http://paste.ubuntu.com/861292/
[00:17] <smoser> it fixes 2 bugs that i'd like to have fixed in beta1
[00:17] <smoser> but i am willing to have someone say "no, not important enough" or "no, too late".
[00:19] <lynxman> jdstrand: ping
[00:23]  * smoser is out. if anyone can ACK that though, i'd appreciate it. but otherwise, it can just land the other side of beta.
[00:34] <dachary> Hi, I wonder how long it takes for a package in Debian testing ( http://qa.debian.org/developer.php?packages=libbpp-core ) reach ubuntu ( https://launchpad.net/ubuntu/+source/libbpp-core ) ? Does it require a manual operation ?
[00:35] <RAOF> dachary: It depends on the time of the Ubuntu cycle.
[00:36] <dachary> RAOF: at this time does it require a manual intervention ?
[00:36] <RAOF> dachary: At *this* point in the cycle (after DebianImportFreeze) it's manual.  Also, we're after FeatureFreeze, so if the package introduces a new feature it needs justification.
[00:36] <dachary> it's not about https://wiki.ubuntu.com/StableReleaseUpdates just yet, I guess ;-)
[00:36] <dachary> oh
[00:37] <RAOF> Finally, we're currently in BetaFreeze, so there's basically no chance until the Beta is released.
[00:37] <broder> that's not true for packages in universe/multiverse
[00:38] <dachary> broder: I should have mentionned these packages are in universe. The rule is different there ?
[00:38] <broder> as long as they're not on an image, beta freeze mostly doesn't apply (they have to be approved, but it's virtually automatic)
[00:38] <broder> but FF and DIF are still relevant
[00:40] <dachary> There are a few new features in this set of bioinformatics packages http://biopp.univ-montp2.fr/wiki/index.php/Packaging
[00:40] <dachary> broder: does that mean they will be rejected even if they are in universe ?
[00:42] <dachary> I would like to make sure I'm not missing an opportunity to have them in the next ubuntu release. But if the rules say it can't, they will have to be obeyed ;-)
[00:42] <broder> dachary: it means that you have to manually request the sync (because it's post-DIF), and get a FeatureFreezeException approved (because it's post-FF), and that if the sync was sponsored right now, it would be held for approval (due to BF), but that it would with high certainty get waved through the beta freeze queue
[00:43] <dachary> broder: that's hopefull :-)
[00:50] <dachary> border thanks for the help. I'll proceed with https://wiki.ubuntu.com/SyncRequestProcess and https://wiki.ubuntu.com/FreezeExceptionProcess
[01:06] <bryceh> elmo, thanks again for your help.  I've been in contact with Intel and it's marked as a priority issue for investigation with them.
[01:15] <slangasek> smoser: please use #ubuntu-release for such questions rather than relying on someone to catch it in scrollback on #ubuntu-devel... :)
[06:04] <pitti> Good morning
[06:05] <pitti> iulian: you can upload stuff at any time; during the freeze it'll be caught in unapproved, and you should poke in #ubuntu-release to get it through quickly; but yes, ghc seems fine now
[06:07] <micahg> I think that was discussed on Friday and it was decided that after beta 1 would be easiest
[06:14] <pitti> ok
[06:14] <pitti> well, I guess I can use the buildds to do some rebuilds for bug 875466
[06:26] <larsduesing> hi together
[06:26] <larsduesing> a small question about creating patches
[06:27] <larsduesing> in a project there is a patch named "01_no-shipped-init-script.patch"
[06:28] <larsduesing> which uses debian/$PROJECT.init.debian to be copied
[06:28] <larsduesing> now I am building an upstart patch
[06:29] <pitti> that sounds overly complicated
[06:29] <larsduesing> so this patch is no longer neccesary...
[06:29] <larsduesing> Is it advisable to kill this 01_patch alltogether?
[06:29] <pitti> a patch that creates debian/project.init.d ?
[06:29] <larsduesing> no
[06:29] <larsduesing> it is more funny
[06:30] <larsduesing> --
[06:30] <pitti> larsduesing: it's a little vague, but just build the package and see what comes out of it
[06:30] <larsduesing> 01_no-shipped-init-script.patch:-	@echo "Installing Debian-style init.d"
[06:30] <larsduesing> 01_no-shipped-init-script.patch:-	@mkdir -p ${DESTDIR}${diretc}init.d
[06:30] <larsduesing> 01_no-shipped-init-script.patch:-	@cp doc/${PROJECT}.init.debian ${DESTDIR}${diretc}init.d/${PROJECT}
[06:30] <larsduesing> 01_no-shipped-init-script.patch:+#	@echo "Installing Debian-style init.d"
[06:30] <larsduesing> 01_no-shipped-init-script.patch:+#	@mkdir -p ${DESTDIR}${diretc}init.d
[06:30] <larsduesing> 01_no-shipped-init-script.patch:+#	@cp doc/${PROJECT}.init.debian ${DESTDIR}${diretc}init.d/${PROJECT}
[06:30] <larsduesing> ---
[06:30] <pitti> larsduesing: in general, if you just have debian/project.upstart, dh_installinit will do the right thing
[06:30] <larsduesing> it is even commented out... :)
[06:31] <pitti> larsduesing: no, the patch comments it out, i. e. disables it
[06:31] <pitti> so you need to keep that
[06:31] <larsduesing> ah... yes
[06:31] <pitti> as you still don't want the init script
[06:31] <larsduesing> i saw this NOW... sorry
[06:31] <larsduesing> :)
[06:31] <larsduesing> yes, it's about Makefile
[06:32] <larsduesing> sorry
[06:37] <larsduesing> sorry, another question...
[06:37] <larsduesing> in ubuntu i cannot use dch --nmu --close bug#, correct?
[06:37] <larsduesing> (it querries the debian bug-database...)
[06:44] <RAOF> larsduesing: I think you can, but (a) we don't have NMUs (because we don't have maintainers), and (b) --close will add a closes tag for the BTS, rather than Launchpad; that's probably not what you're after.
[06:45] <rickspencer3> good morning/evening all
[06:45] <pitti> hey rickspencer3
[06:45] <rickspencer3> pitti, Daviey what's the word on the street for beta1? looking good?
[06:45] <pitti> rickspencer3: no catastrophes that I could see, anyway
[06:45]  * rickspencer3 eyes precice_probs and smoke tests
[06:46] <rickspencer3> pitti, good to hear ... it's nice to see the archive and smoke tests are in good shape
[06:46] <pitti> rickspencer3: ISO tracker for ubuntu images has just one red bug, which is a xubuntu bug and already fixed; it seems it just got mis-placed
[06:47] <pitti> rickspencer3: precise_probs has that long-standing problem of the new armadaxp kernel, but it's not really user-visible
[06:47] <pitti> rickspencer3: openjdk will be fixed once it finishes building on arm*
[06:49] <pitti> rickspencer3: upgrades are a bit unstable unfortunately, bug 927993
[06:53] <didrocks> @pilot in
[06:56] <YokoZar> larsduesing: btw, the Ubuntu equivalent of Debian's Closes is to put (LP: #123456) in a changelog entry
[06:57] <YokoZar> This will automatically fix-released the bug when the package hits the archive (provided the bug is filed against that package)
[07:08] <larsduesing> YokoZar: thanks
[07:15] <larsduesing> hmm...
[07:15] <larsduesing> sorry...
[07:15] <larsduesing> how to get quilt to delete a file?
[07:15] <larsduesing> (not a patch, but a file in debian/ )
[07:20] <larsduesing> (I think I am in a complete wrong way... I want to make a patch which exchanges init.d to upstart... ONE Change out of the debian-dir, all others are in debian...)
[07:20] <larsduesing> (this patch is to be given to ubuntu-sponsors
[07:23] <pitti> larsduesing: just delete the file
[07:23] <pitti> we don't patch files in debian/
[07:25] <larsduesing> ok, so a patch for sponsors should be a normal diff?
[07:25] <larsduesing> (and nothing with quilt ?
[07:25] <pitti> yes, ideally a debdiff between the current package and your new one
[07:25] <pitti> i. e. debdiff foo_current.dsc foo_new.dsc
[07:25] <larsduesing> ok
[07:26] <larsduesing> but in new should be a changelog-entry?
[07:26] <pitti> yes, of course; any change you need to make
[07:26] <larsduesing> ok
[07:27] <larsduesing> thanks
[07:49] <dholbach> good morning
[07:50] <dholbach> pitti, nothing like a few rebuilds in the morning, right? :)
[07:50] <pitti> dholbach: yeah, felt like the buildds needed to produce some heat :)
[07:50] <pitti> they were getting bored and crummy
[07:54] <dholbach> can somebody please reject https://code.launchpad.net/~maxolasersquad/ubuntu/precise/stellarium/add_quicklist/+merge/94312?
[07:55] <pitti> dholbach: *zap*
[07:56] <dholbach> thanks pitti :)
[08:01] <larsduesing> is anybody able to set bug 223825 to triaged?
[08:16] <pitti> larsduesing: yes, but "in progress" seems appropriate as there is a patch now and you are workign on it?
[08:16] <larsduesing> pitti: patch is completed... (and working since more than half a year in my ppa)
[08:17] <larsduesing> so what type is to be set?
[08:17] <larsduesing> *sorry* I'm rather new to all this :(
[08:17] <pitti> larsduesing: ah, sponsors are subscribed already
[08:17] <pitti> larsduesing: that's pretty much it then
[08:18] <larsduesing> sponsors and sru
[08:18] <larsduesing> ok
[08:18] <pitti> larsduesing: btw, no need to remove debian/aiccu.init.d
[08:18] <larsduesing> thanks for your help
[08:18] <pitti> larsduesing: instead, you should call dh_installinit with --upstart-only
[08:18] <pitti> (smaller diff)
[08:19] <larsduesing> so I should put a new diff?
[08:19] <pitti> larsduesing: hang on, you don't even need --upstart-only; if .upstart exists, that will be used
[08:19] <pitti> larsduesing: would make it easier for sponsors, yes (and you can do another final test build)
[08:20] <larsduesing> but the init.d is the source of that bug
[08:20] <larsduesing> (I did a build - but interestingly on updating /etc/init.d/aiccu WON'T be deleted :( )
[08:22] <pitti> larsduesing: yes, but that's not because you removed debian/init.d
[08:22] <pitti> larsduesing: the init script is a dpkg-managed configuration file, and you need to remove it manually in maintainer scripts
[08:22] <pitti> larsduesing: see man dpkg-maintscript-helper
[08:22] <larsduesing> arghs, so I have to edit these, too?
[08:23] <pitti> larsduesing: if you don't feel up to this, please mention it in the bug, so that the sponsor can add the necessary bis
[08:23] <pitti> bits
[08:23] <larsduesing> I'm able, but I'm learning still
[08:23] <larsduesing> (and if I do it not myself, I will never learn...)
[08:24] <pitti> larsduesing: no, it's actually enough to add a debian/aiccu.maintscript with something like "rm_conffile /etc/init.d/aiccu 20070115-14.1"
[08:24] <pitti> larsduesing: the dpkg-maintscript-helper manpage explains the problem with conffiles, and how to remove them on upgrade
[08:24] <larsduesing> ok
[08:24] <pitti> fortunately it's relatively easy to do this these days with .maintscript
[08:25] <larsduesing> there is no debian/*.maintscript
[08:25] <larsduesing> only .postrm
[08:26] <larsduesing> (and pre*/post*.debhelper)
[08:26] <pitti> yes, you need to create it
[08:26] <larsduesing> ok
[08:26] <larsduesing> *reading*
[08:26] <larsduesing> :)
[08:26] <larsduesing> thanks pitti
[08:26] <pitti> larsduesing: kein Problem :)
[08:26] <larsduesing> *g*
[08:32] <larsduesing> pitti - so I should leave the buggy init.d-script in place?
[08:32] <pitti> larsduesing: yes, it won't be installed if there is an .upstart script as well (see man dh_installinit)
[08:32] <larsduesing> ok
[08:32] <pitti> that reduces the delta with debian
[08:32] <pitti> i. e. the packaging difference
[08:32] <larsduesing> yes
[08:32] <larsduesing> I understand
[08:36] <larsduesing> still one question - should I update debian/control Standads-Version: 3.9.1 to 3.9.2 ?
[08:36] <larsduesing> lintian mentions it...
[08:36] <infinity> No.
[08:36] <infinity> Not unless you're planning to take over upstream maintenance too.
[08:36] <larsduesing> ok
[08:37] <pitti> larsduesing: that'd be unnecessarily diverging from Debian, indeed, so we leave it
[08:38] <infinity> Also, rm_conffile surely isn't enough in this case, you'd also want an update-rc.d remove?
[08:38] <infinity> Or you leave a mess of dangling symlinks.
[08:38] <larsduesing> oh
[08:38] <larsduesing> that's right...
[08:39] <larsduesing> so somewhere put an "update-rc.d aiccu disable"?
[08:40] <infinity> larsduesing: Not disable, remove.
[08:40] <larsduesing> ah, yes...
[08:40] <larsduesing> sure
[08:42] <larsduesing> infinity: aiccu.postinst.debhelper DOES that
[08:42] <larsduesing> # Automatically added by dh_installinit
[08:42] <larsduesing> update-rc.d -f aiccu remove >/dev/null || exit $?
[08:43] <pitti> isn't that just on "remove", not on "upgrade"?
[08:44] <larsduesing> "aiccu.postinst.debhelper"
[08:45] <larsduesing> I read that, do that after installing
[08:45] <pitti> larsduesing: righht, but this line is usually surrounded by if [ "$1" = "purge" ]
[08:45] <infinity> I'd actually be shocked if it's there at all after dh_installinit switches to installing an upstart script instead.
[08:45] <infinity> (Have you made that change yet?)
[08:47] <larsduesing> pitti: no dependencies for that line
[08:47] <pitti> nice, magic
[08:47] <pitti> so perhaps dh_installinit is clever enough to do that by itself then
[08:47] <broder> uh, are you guys sure? it makes perfect sense for dh_installinit to cleanup the rc*.d symlinks if you start shipping an upstart job
[08:47] <larsduesing> I HATE magic, esp. if I don't understand it
[08:47] <pitti> broder: yes, it does, but I wasn't aware that it does that by itself
[08:48] <infinity> broder: I don't think it makes sense at all for it to universally have that in every upstart-using package (and I'm betting it doesn't).
[08:48] <larsduesing> so, I'll try an update.. let's see
[08:48] <larsduesing> :)
[08:48] <broder> looks like it adds it unless you specify --upstart-only
[08:49] <broder> err, wait, and unless some other things
[08:49] <pitti> so that was probably added so that maintainers don't have to add the same snippet over and over again
[08:50] <infinity> I suppose.  But then they'll be there "forever".  I guess it doesn't hurt, unless the user adds their own init script with the same name, assuming some silly maintainer script that doesn't own the file won't mess with them.
[08:51]  * infinity shrugs.
[08:51] <pitti> infinity: remove only removes symlinks if the script doesn't exist
[08:51] <infinity> True.
[08:51] <infinity> So, it's just a lot of unnecessary noops.
[08:52] <infinity> Good thing it's Perl instead of Python, so it doesn't take 5 seconds to run and do nothing? ;)
[08:52] <larsduesing> hmm
[08:52] <larsduesing> I am running into problems...
[08:52] <larsduesing> *checking again*
[08:53] <larsduesing> nothing had been deleted
[08:53] <larsduesing> *checking*
[08:55] <larsduesing> arghs
[08:56] <larsduesing> in postinst there is an "exit 0" - and dh_installinit is in the last lines
[08:57] <larsduesing> (and I enterered nothing in the config, therefore I ran into the exit 0)
[09:01] <larsduesing> with correct settings it is ok
[09:01] <larsduesing> thanks
[09:01] <larsduesing> so, I'll publish new patch
[09:02] <larsduesing> thanks infinity and pitti (and sorry for so many newbie-questions and -errors... :) )
[09:03] <pitti> larsduesing: np; conffile handling isn't exactly a newbie topic
[09:04] <larsduesing> I learned a bunch of new things... mission accomplished :)
[09:12] <didrocks> dholbach: guten morgen, how are you?
[09:13] <dholbach> hey didrocks
[09:13] <dholbach> good good
[09:13] <dholbach> how about you?
[09:14] <didrocks> dholbach: piloting, seeing that all keywords patch have no changelog, inline patches, not to the correct branch, but well, in easy brain-off mode :)
[09:14] <didrocks> dholbach: I'm trying to get a good text for commenting on them, do you have wiki page handy explaining shortly having a patch in quilt + changelog?
[09:15] <dholbach> didrocks, here's what I did: https://code.launchpad.net/~maxolasersquad/ubuntu/precise/smplayer/add_quicklist/+merge/94500
[09:15] <didrocks> dholbach: ah excellent! was looking for a model :)
[09:15] <didrocks> dholbach: was exactly what I needed, thanks!
[09:15]  * dholbach hugs didrocks
[09:16]  * didrocks hugs dholbach back
[09:16] <dholbach> didrocks, one thing I was wondering about: how are you going to do it? are you going to use their email address or yours?
[09:17] <dholbach> personally, I used theirs, so it would be indicated as their contribution in LP - but I'm not sure how everybody else does it
[09:17] <didrocks> dholbach: well, we will only upload that part of GNOME .91
[09:17] <didrocks> dholbach: as*
[09:17] <dholbach> aha!
[09:17] <didrocks> dholbach: so I'm adding the [ … ]
[09:18] <dholbach> ok :)
[09:18] <didrocks> yeah, the one making the .91 update on the component will win the sponsoring :)
[09:18] <didrocks> not me on the chart :p
[09:18] <didrocks> dholbach: I'm also sending that upstream FYI
[09:18] <didrocks> (as there is no indication it has been done)
[09:19] <dholbach> didrocks, for future reference , I would give them a link to a "forwarding patches to gnome" wiki page, so they do it themselves next time
[09:19] <didrocks> dholbach: yeah, and stating in the merge that it was done :)
[09:19] <dholbach> yeah
[09:19]  * dholbach hugs didrocks
[09:19] <didrocks> right now, doing the call for help is easy and we are taking all the extra load :/
[09:20] <didrocks> so anything in that regard will be appreciate!
[09:20] <didrocks> appreciated :)
[09:20] <dholbach> yes
[09:24] <larsduesing> oh, I'm sort of late, ubuntu is in freeze already...
[10:15] <dholbach> SpamapS, smoser: are you going to figure out https://code.launchpad.net/~smoser/ubuntu/precise/sysvinit/rc.local.d/+merge/88323? (I'm trying to get older merge proposals off the list :-))
[10:15] <dholbach> pitti, do you think it'd be OK to reject https://code.launchpad.net/~pali/ubuntu/natty/plymouth/plymouth/+merge/61897 based on broder's comment?
[10:16] <pitti> dholbach: yes, absolutely; there is no chance that we'll upload this
[10:16] <pitti> and not for oneiric anyway
[10:17] <pitti> (rejected)
[10:17] <dholbach> stgraber, are we still going to get https://code.launchpad.net/~sdeziel/ubuntu/oneiric/openvpn/subnet-icmp-disable/+merge/90740 into precise?
[10:17] <dholbach> thanks a lot pitti
[10:18] <Amoz> dholbach, oh hai
[10:18] <dholbach> hey Amoz
[10:21] <Amoz> I'm running precise with latest updates, I think the battery indicator in gnome-shell is freezing, upower reports correct values, restart gnome-shell, batteryindicator shows correct values again
[10:22] <Amoz> how can one debug the indicator?
[10:35] <dholbach> Amoz, you could try asking in #ubuntu-desktop
[10:38] <seb128> dholbach, Amoz: ask #gnome-hackers on irc.gnome.org
[10:39] <seb128> we don't have gnome-shell hackers on #ubuntu-desktop
[10:39] <seb128> oh
[10:39] <seb128> that might be a distro issue, I will respond there
[10:43] <didrocks> can someone reject https://code.launchpad.net/~nik90/ubuntu/precise/vlc/keywords/+merge/95085 please? need to go upstream first
[10:45] <pitti> done
[10:45] <didrocks> thanks pitti :)
[11:14] <dholbach> I'm currently putting together tasks for Fix It Friday (coinciding with Ubuntu Global Jam) - any requests? I was think of http://qa.ubuntuwire.com/ftbfs/ and https://bugs.launchpad.net/ubuntu/+bugs?field.status_upstream=resolved_upstream for now
[11:16] <pitti> presumably most of the older bugs on that list have been fixed ages ago; but working on that starting from the newest bugs sounds interesting
[11:18] <nigelb> 24
[11:18] <nigelb> urgh
[11:23] <dholbach> pitti, yeah, and if we can close some of the older bugs during the process, then that's cool too :)
[11:23] <dholbach> "just" a matter of making the instructions clear enough :)
[12:23] <didrocks> @pilot out
[12:51] <bdrung> didrocks: bug #943014
[12:53] <didrocks> bdrung: thanks for the notice
[13:17] <smoser> dholbach, well, slangasek was fairly anti rc.local.d
[13:18] <dholbach> smoser, maybe it should be discussed on the mailing list then? *shrug*
[13:19] <smoser> dholbach, my feelings will not be hurt if you make that disappear from the queeu
[13:19] <smoser> i agree it isn't worht other pilots looking at really.
[13:20] <dholbach> I don't have the necessary powers
[13:20] <smoser> what do you need me to do then?
[13:20] <dholbach> can somebody please reject https://code.launchpad.net/~smoser/ubuntu/precise/sysvinit/rc.local.d/+merge/88323? (based on the discussion above)
[13:20] <dholbach> thanks a lot smoser
[13:20] <smoser> work in progress ?
[13:20] <smoser> is that good enough ?
[13:23] <dholbach> it will make it drop off the list
[13:27] <infinity> smoser: I can delete the proposal, is that the sort of rejection you're looking for?
[13:27] <infinity> smoser: Surely you can do that too...
[13:33] <smoser> infinity, i moved it to "workin progress" an that is good enough.
[13:33] <smoser> please do not delete.
[13:34] <infinity> smoser: Alright. ;)
[14:05] <stgraber> dholbach: yes, I have a package ready for upload, waiting for beta-1 freeze to be lifted
[14:05] <stgraber> dholbach: it's in my PPA and already tested
[14:05] <dholbach> awesome
[14:05] <dholbach> :)
[14:10] <Amoz> dholbach, you want a merge proposal or a patch in the bugreport?
[14:10] <Amoz> for the upg
[14:10] <dholbach> Amoz, as you like it - whatever is easier for you
[14:11] <Amoz> dholbach, http://paste.ubuntu.com/861948/
[14:11] <dholbach> thanks Amoz
[14:11] <Amoz> np
[14:12] <Amoz> my bad for not checking it more carefully
[14:12] <Amoz> we fixed it this way last time as well I suppose
[14:13] <dholbach> Amoz, ah, cool
[14:16] <dholbach> Amoz, applied, tested and committed :)
[14:16] <dholbach> good work
[14:16] <Amoz> dholbach, nah you did the work ^^
[14:17] <dholbach> no no
[14:17] <dholbach> I had no idea what I was doing
[14:19] <dholbach> Amoz, did you get your indicator-power query sorted out?
[14:19] <kenvandine> @pilot in
[14:19] <Amoz> dholbach, filed a bug
[14:19]  * dholbach hugs kenvandine
[14:19] <dholbach> Amoz, ok cool
[14:19]  * kenvandine hugs dholbach
[14:19] <stgraber> dholbach: the merge proposal can probably be killed though as the real fix is a merge from Debian
[14:19] <dholbach> stgraber, excellent
[14:20] <dholbach> an somebody please reject https://code.launchpad.net/~sdeziel/ubuntu/oneiric/openvpn/subnet-icmp-disable/+merge/90740?
[14:20] <dholbach> ^ based on the discussion above
[14:39] <pitti> done
[14:46] <tsdgeos> who do i need to ask to move to a newer openjpeg?
[14:46] <tsdgeos> we are two releases behind
[14:47] <tsdgeos> in a project that releases every year or more
[15:30] <slangasek> smoser: I'm not anti rc.local.d, I'm anti putting this in sysvinit ;)
[15:31] <smoser> i kind of realized that when i re-read the conversation
[15:31] <smoser> and updated the bug with a summary in its final comment.
[15:36] <jokerdino> anyone wants to submit a branch on my behalf? (https://bugs.launchpad.net/ubuntu/+source/unity/+bug/942476)
[15:36] <jokerdino> i can't ssh in here, the network blocks any port other than 80.
[15:37] <bdmurray> pitti: I've noticed that some python tracebacks reported by apport are missing information bug 942439 is an example
[15:37] <bdmurray> pitti: is missing the source package, version and distrorelease bits at least
[15:38] <pitti> hm, curious -- no idea how this would happen
[15:38] <bdmurray> bug 942888 is another example
[15:39] <bdmurray> this is rather recent
[15:39] <pitti> that at least has a rather weird Dependencies: field
[15:49] <bdmurray> pitti: if you need it another example is bug 940800
[15:50] <pitti> bdmurray: oh, I believe that it's happening now, I just don't know why :/
[15:50] <pitti> I guess something weird with the new async way of collecting information
[15:50] <pitti> ah, no Evan
[15:51] <bdmurray> he's at a conference this week
[15:52] <pitti> so apparently there's some way of sending the report without collecting all the information
[16:08] <diwic> pitti, can I borrow your expert brain for a moment?
[16:15] <pitti> hey diwic, what's up?
[16:16] <diwic> pitti, the stacktrace given by apport seems inconsistent and I'm not sure what I can trust or not
[16:17] <diwic> pitti, in bug 924416, stack trace top is at "drop_block (bq=0xfd6170, q=0x7fede800f440) at pulsecore/memblockq.c:180"
[16:18] <diwic> pitti, it says that q=0x7fede800f440 when the function was called. However, at line "pulsecore/memblockq.c:18" is "pa_assert(q)"
[16:18] <diwic> pitti, which should succeed if q is non-zero.
[16:19] <diwic> pulsecore/memblockq.c:180
[16:22] <diwic> pitti, so how should I go about this?
[16:22] <pitti> hm, I'm as baffled as you; sometimes optimization plays dirty tricks, but SIGABRT very much does sound like an assert failure
[16:22]  * pitti downloads and looks at source
[16:24] <pitti> diwic: hm, it doesn't show the value of bq, is there any chance that it really hits the next assertion, pa_assert(bq->n_blocks >= 1); ?
[16:25] <pitti> diwic: is pa_assert() even active, i. e. do we not build with NDEBUG?
[16:25] <diwic> pitti, I'm pretty certain pa_assert() is active
[16:26] <diwic> pitti, but what technique would I use to verify? I assume gdb is involved somehow :-)
[16:28] <pitti> diwic: at this point it'd be good to get a core dump
[16:29] <diwic> pitti, can we get one from launchpad or is it forever lost?
[16:30] <pitti> it's already a month old, so I think it's gone for good
[16:31] <diwic> pitti, bug 932178 is from 14 feb if that helps (it's a duplicate)
[16:31] <pitti> diwic: if I read macros.h correctly, pa_assert_se should drop a log message into pulse's log; is that anywhere in teh attachments?
[16:32] <diwic> pitti, no, I think it should be in /var/log/syslog though, we might want to apport-collect that...
[16:32] <pitti> diwic: Eric says he gets it a few times a day; perhaps he can attach the .crash report the next time it happens, then we'll have it for closer inspection
[16:33] <pitti> diwic: oh, I had expected ~/.xsession-errors
[16:35] <diwic> pitti, good idea. that would be in /var/crash/apport something?
[16:35] <pitti> diwic: yes, /var/crash/_usr_bin_pulseaudio.1000.crash presumably
[16:36] <pitti> cd
[16:36] <diwic> cd ?
[16:36] <Amoz> compact disc
[16:37] <Amoz> or see directory ? :)
[16:39] <diwic> pitti, ok, I will update the bug and ask for this information. Thanks!
[16:40] <pitti> diwic: thanks; sorry that I cannot be more helpful
[16:41] <diwic> pitti, both you and apport is already very helpful, so don't feel bad about it :-)
[16:50] <PaoloRotolo> Hi all!
[16:56] <cnd> bdmurray, do you have instructions on how to use set_serial for wacom touchscreens?
[16:56] <slangasek> pitti: bug #828731> no, kexec-tools hasn't been accepted into lucid-proposed...
[16:57] <slangasek> pitti: should I go ahead and accept the lucid/natty versions?
[16:58] <pitti> slangasek: odd, it had a comment; click failure :/ please do, thanks
[16:58] <bdmurray> cnd: this is all I have http://www.murraytwins.com/blog/?p=103
[16:59] <cnd> bdmurray, ok, thanks!
[16:59] <slangasek> bdmurray: so I can comment on bug #659438, but hit a timeout trying to move the bug to 'triaged', bah
[16:59] <bdmurray> slangasek: might work via the api which task?
[17:00] <slangasek> bdmurray: the devel task for aptdaemon (Ubuntu)
[17:01] <bdmurray> slangasek: re bug 937638 its duplicate bug 937630 also seems to have hardware errors
[17:01] <slangasek> bdmurray: right, those two are from the same submitter; there was another one, let me find it
[17:01] <bdmurray> ah, got it
[17:02] <slangasek> bdmurray: bug #938306
[17:07] <bdmurray> slangasek: what about EXT2-fs (loop1): error: ext2_lookup: deleted inode referenced: 64092 ?
[17:09] <slangasek> bdmurray: well, it's not a hardware error in that case - may simply be fs corruption
[17:11] <SpamapS> I just love mdadm.. 44,000 lines of C, about 9 lines of comment
[17:15] <SpamapS>     if (ioctl(fd, GET_ARRAY_INFO, &array) != 0 ||
[17:15] <SpamapS>         array.raid_disks <= 0)
[17:15] <SpamapS>         return 0;
[17:15] <SpamapS> So.. either there aren't enough disks, or the ioctl exploded. Either way.. lets just fail the same way. <sigh>
[17:39] <infinity> SpamapS: By "not enough disks", you mean "no disks", which is equavalent to "no array at all", which may well be about the same as GET_ARRAY_INFO returning a failure.
[17:40] <infinity> SpamapS: Looks more like just covering their bases for all the different "vaguely undefined" ways that an array can not exist.
[17:41] <infinity> SpamapS: (I do like that the check accepts the possibility that there may be a negative number of disks, though)
[17:52] <SpamapS> infinity: I'm fairly certain that in this case the ioctl is complaining because the array is degraded.. but I really have no good way to prove that. :-P
[17:54] <infinity> SpamapS: GET_ARRAY_INFO should return info on a valid array, surely.
[17:54] <infinity> SpamapS: Even a degraded one.
[17:55] <SpamapS> infinity: in that case, it should have set the number of disks to 1, not 0
[17:55] <infinity> You'd think.
[17:55] <infinity> Unless the array just plain doesn't exist from mdadm's POV.
[17:56] <SpamapS> its also possible the disc.major != 0 or the disc.minor != 0
[17:56] <SpamapS> thats in another part of the code
[17:56]  * SpamapS is writing a tiny version of mdadm's ioctls to determine that right now. :p
[17:56] <SpamapS> would be nice if the program actually reported *why* it can't re-add this disk
[19:21] <bdmurray> mvo: so I was unable to recreate bug 659438 do you have any other ideas on how to test it?
[19:29] <SpamapS> [  172.326867] mdadm: sending ioctl 1261 to a partition!
[19:29] <SpamapS> Interesting..
[19:32] <mvo> bdmurray: unfortunately not
[19:32] <mvo> bdmurray: thanks a bunch for the test though
[19:37] <bdmurray> mvo: do you think the bug should be left open?
[19:41] <dupondje> pitti: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/936629 why is this marked incomplete?
[19:42] <dupondje> got the same issue today
[19:42] <dupondje> if you need some debugging
[19:42] <mvo> bdmurray: if its still collecting dupes then I would say yes :/
[19:43] <dupondje> tkamppeter: seems like you set it on inc
[20:20] <kenvandine> @pilot out
[20:57] <tkamppeter> dupondje, you are welcome to helpon the bug, simply answer my questions and supply the information which I have asked for from the original poster.
[21:03] <dupondje> tkamppeter: tried it again, but unable to simulate it now
[21:03] <dupondje> btw, I have the gs command that was executed
[21:03] <dupondje> http://paste.ubuntu.com/862514/
[21:20] <bdmurray> slangasek: regarding bug 849414 is there anyway to just make 'plymouth:debug' the default for a while?
[21:20] <slangasek> bdmurray: we could, but I don't believe that would actually help us narrow it down
[21:20] <slangasek> the backtraces all point to a signal handler gone rogue
[21:21] <slangasek> and we know we have an Ubuntu-specific signal handler that we need to get rid of
[21:32] <barry> slangasek: so bug 941172.  i can easily update the version numbers, but i think it would be useful to link to bryceh 's description in comment #4.  only i'm not sure whether to move that text to the wiki and add a link to that, or just link to the comment in the bug.  thoughts?
[21:34] <slangasek> barry: I guess the wiki would be better
[21:34] <barry> slangasek: agreed. i'm inclined to just copy that whole text to the wiki, mark it up minimally, and link to that
[21:34] <bryceh> barry, yeah put it in wiki.  the text should be trimmed down a lot, it was just a brain dump and is probably TMI
[21:35] <barry> bryceh: okay, i'll do that, thanks.  i'll follow up with the wiki url once that's done
[23:04] <dupondje> apport-bug is broken - https://bugs.launchpad.net/bugs/943661
[23:22] <tkamppeter> dupondje, thanks. I have subscribed you to the bug now. Please provide any further information through the bug report, especially whether "sudo aa-complain cupsd" eliminates your problem completely.
[23:24] <micahg> tkamppeter: that also removes apparmor protection from the cups daemon and is not recommended
[23:24] <seb128> it's seems fair enough to run once to see if that workaround a bug to know if the bug is due to restrictions
[23:25] <tkamppeter> micahg, I ask the users only for doing this to determine whether their printing got really blocked by AppArmor. I do not consider the bug fixed when it works with aa-complain.
[23:25] <micahg> sure
[23:25] <micahg> tkamppeter: ok, but I didn't see that note :)
[23:43] <SpamapS> slangasek: opinion sought.. mdadm has added some checks that prevent one from re-hot-adding out of sync former-members of a RAID array without zeroing the superblock..
[23:44] <SpamapS> slangasek: I have a feeling this is unintended consequences of some other check...
[23:45] <SpamapS> slangasek: 1) how much do we care (at worst, this means people will always have to do a full sync instead of a catch up), and b) if we care, do we push back to Debian or ???
[23:46] <slangasek> er, I think all my information about mdadm is out of date.  what's the difference between a full sync and a catch-up, here?
[23:46] <slangasek> I mean, doesn't mdadm just know that they're out of sync, and has no choice but to overwrite?
[23:52] <SpamapS> slangasek: yes, so this may be a kernel issue too.
[23:52] <SpamapS> slangasek: mdadm tells the kernel to re-add a disk to an array
[23:53] <SpamapS> slangasek: in the past that was fine. but in this case, mdadm looks at the disk and says "no, its no good for adding, please zero the superblock"
[23:53] <slangasek> right
[23:53] <SpamapS> slangasek: I'm more looking for how much we care about this, because the debugging effort will be brutal.
[23:53] <SpamapS> slangasek: in the new case.. it seems mdadm is being more careful, so I'm ok with it.
[23:53] <slangasek> we care about mdadm working smoothly
[23:54] <slangasek> but I'm deathly afraid of touching that code at all this cycle
[23:56] <SpamapS> slangasek: the scenario that has bothered me for a while is where I break a mirror temporarily, and the put the disk back in. I've always felt md should re-sync that, but it never seems to
[23:56] <slangasek> well
[23:56] <slangasek> in past cycles, you would have counted yourself fortunate to have it just fail to resync
[23:57] <slangasek> because we have had some data corruption bugs related to hot remove/add
[23:57] <SpamapS> Yeah, I think its more careful now
[23:57] <slangasek> so I wouldn't recommend trying to address this without coordinating with upstream+Debian
[23:59] <SpamapS> I'm not really looking to touch it at all