[00:41] <poolie> hi jam, spiv, lifeless
[00:44] <lifeless> hiya
[01:02] <spiv> Morning.
[01:02] <poolie> hi spiv
[01:42] <poolie> spiv, i'm preparing my session for the epic
[01:42] <poolie> what are you up to today
[01:50] <spiv> poolie: working on bug 522637, there seems to be some disagreement between a repo and its fallback about the CHK roots for an inventory (and as a tangent having some ideas on a new hpss verb)
[01:50] <spiv> poolie: then thinking about the epic
[01:50] <poolie> ah that sounds good :)
[01:50] <poolie> i'm just about to propose we fork off 2.2 and do 2.2b4
[01:51] <poolie> i want to make the branch allow at this point non-bugfix changes but no api breakage
[01:51] <spiv> Or at least controlled API breakage :)
[01:51] <poolie> i wonder if having it be different to released stable branches will cause confusion
[01:51] <poolie> no intentional api breakage :)
[01:51] <poolie> actually i think not even any deprecations
[01:52] <poolie> but having an 'api freeze' phase is not unprecedented
[02:36] <jbowtie> I just got approval from legal to release my Bazaar plugin.
[02:37] <jbowtie> I'm planning on pushing it to Launchpad under GPLv2 or later; any best practices for publishing plugin projects?
[02:38] <lifeless> generally they are found on LP in bzr-pluginname projects
[02:38] <lifeless> often people put them in the 'bazaar' project group, which gives ~bzr (the broad set of developers of bzr and its plugins) access to do bug triage etc
[02:39] <lifeless> and sometimes people make the trunk branch owned by ~bzr or a dedicated group which ~bzr is in, so that other folk can update the plugin when API changes break it.
[02:39] <lifeless> these are all optional voluntary things of course
[02:43] <jbowtie> lifeless: Thanks, the 'bazaar' project group stuff I didn't know.
[03:09] <poolie> lifeless: i was just wondering why you declined bug 522637 for 2.0 and 2.1
[03:09] <poolie> is it infeasible to fix there?
[03:09] <lifeless> checking
[03:13] <lifeless> poolie: it was ages ago that I declined it
[03:13] <lifeless> the UI kind of encourages 'propose for' on *problems* but perhaps its *solutions* that should be proposed.
[03:13] <lifeless> its the conflation between bug exists and will-fix-in again.
[03:14] <poolie> maybe so
[03:14] <lifeless> ...anyhow... I suspect the fix will be non trivial
[03:14] <poolie> well, i guess the merge can be proposed to either
[03:14] <lifeless> but spiv is working on it I think ?
[03:14] <poolie> but it may be nice to say "we want to try to fix it in 2.0."
[03:14] <poolie> he is
[03:14] <poolie> if he think it's easy to backport
[03:14] <poolie> we can do that
[03:14] <poolie> was just curious
[03:14] <lifeless> I'd get the fix and then make an assessment of that.
[03:14] <poolie> yep
[03:15] <EdWyse_Home> Is there a way to convert a lightweight checkout to a heavyweight one? or do I just have to re-checkout the whole thing?
[03:16] <lifeless> bzr reconfigure --checkout, I think.
[03:17] <EdWyse_Home> Close enough... Thanks
[03:44] <jbowtie> There we go... https://launchpad.net/bzr-tfs
[03:47] <lifeless> \o/
[03:48] <jbowtie> It's a pure python solution, too (relies on python-ntlm for authentication) - means it works nicely on Linux, not just on Windows.
[03:48] <jbowtie> I suppose now I need to write some documentation, and tests, and so on...
[03:48] <lifeless> thats really cool
[04:41] <lifeless> poolie: brief call ?
[04:56] <poolie> lifeless: hi, sure
[04:56] <lifeless> could you ring my NZ house # ?
[04:56] <thumper> how do I cherry pick a revision?
[04:56] <lifeless> merge -c revno branch
[04:56] <thumper> ta
[05:00] <thumper> jbowtie: that's pretty cool
[05:00] <thumper> jbowtie: I don't suppose you are looking at a visual studio plugin are you?
[05:17] <jbowtie> thumper: Not for a while, too many other things on my plate.
[05:29] <parthm> i am seeing some weird error on pqm for the bad-pattern patch. http://dpaste.com/215805/ .. the tests pass locally.
[05:29] <parthm> any ideas?
[05:35] <parthm> the pqm-stderr has this http://pastebin.com/Fn6zSE79
[05:40] <spiv> parthm: those pastes don't give many clues :(
[05:41] <parthm> spiv: i am downloading pqm-stdout to see if that has something.
[05:43] <lifeless> look at the end of pqm-stdout generally
[05:48] <parthm> is there a quick pattern i can search for? the summary shows 3 failures: http://pastebin.com/XL5NHXu7 ... its difficult to different expected tracebacks from actual failures.
[05:50] <lifeless> have you got subunit installed ?
[05:52] <parthm> lifeless: yes. '/usr/lib/python2.6/dist-packages/subunit/__init__.pyc'
[05:52] <parthm> is DeprecationWarning considered an error? .. http://pastebin.com/V8kEyB1z
[05:53] <lifeless> parthm: 'gunzip -c pqm-stdout.gz | subunit-filter --no-skip | subunit2pyunit'
[05:54] <parthm> lifeless: i don't have subunit-filter and subunit2pyunit. where can I get that?
[05:55] <lifeless> parthm: apt-get install subunit
[05:59] <parthm> lifeless: thats pretty neat. http://pastebin.com/hJ98AauT
[06:01] <parthm> bt.test_globbing and bt.test_osutils seem to work fine locally.
[06:04] <parthm> for re_compile_checked the only difference is that its deprecated now. test results: http://pastebin.com/B5JaL8k9
[06:06] <spiv> parthm: IllegalUseOfScopeReplacer means lazy_import is involved
[06:07] <spiv> parthm: which suggests that it might be sensitive to the exact order imports happen :/
[06:07] <spiv> (And so presence/absence of plugins could affect that)
[06:07] <parthm> spiv: ah yes. i see the error now.
[06:08] <parthm> spiv: there is a direct import (not lazy) "from bzrlib.trace import ( errors, ...)" ... note the trace.
[06:08] <parthm> spiv: interestingly it passes locally. i don't know why.
[06:09] <lifeless> plugins
[06:09] <parthm> spiv, lifeless: the import errors is for globbing.py .. forgot to mention.
[06:10] <parthm> i suspect that will fix the scope error. any idea on the re_compile_checked error?
[06:11] <spiv> parthm: regardnig globbing.py, that is pretty weird that lazy_import is involved in the traceback when it's not used in that file.
[06:14] <parthm> spiv: yes. its surprising. also, the tests passing (locally) with that is weird.
[06:15] <spiv> parthm: regarding the deprecation, I think pqm runs python with -Wall, which means warnings are raised as errors, including deprecations
[06:15] <spiv> The docs on writing tests should explain how to write tests for deprecated functions (i.e. how to expect a deprecation from a particular call)
[06:16]  * parthm goes digging into testing docs for deprecation.
[06:17] <spiv> (I mean "should" in the sense of "I do not know if they actually cover that, but if they don't then please file a bug and/or fix that" :)
[06:18] <spiv> If they don't, you should be able to grep the test suite for how other tests do it.
[06:19] <parthm> spiv: its not mentioned in the testing doc. but HACKING.txt mentions "TestCase.applyDeprecated" without much explanation. i will file a bug for updating the testing doc.
[06:20] <spiv> parthm: thanks :)
[06:21] <parthm> spiv, lifeless: thats for the help in locating the issues :) ... i will try to land this again once these are fixed.
[06:39] <poolie> hi spiv, parthm
[06:40] <parthm> poolie: hi
[07:46] <vila> hi all
[07:47] <lifeless> hiya
[08:04] <parthm> looks like another error. http://pastebin.com/Z4qRJUGX ... looks like re.compile is calling python2.4 re.compile directly and not the lazy one. test passes locally (python2.6)
[08:04] <parthm> lazy re_compile: http://bazaar.launchpad.net/~parthm/bzr/300062-bad-pattern-error-part-1/annotate/head:/bzrlib/lazy_regex.py#L61
[08:04] <parthm> compile failure should be raising InvalidPattern and not re.error. any ideas?
[08:10] <parthm> lifeless: just saw the mail on your move to launchpad. congratulations and thanks for all the reviews and piloting :) good luck.
[08:10] <lifeless> thanks!
[08:17] <parthm> hmm. i ran the test with python2.4 and didn't see any problem. so its not python related.
[08:17] <lifeless> parthm: have you tried with --no-plugins ?
[08:18] <parthm> lifeless: yes. i am running it with no-plugins. the tests pass locally with 2.4 and 2.6.
[08:19] <parthm> looks like re is not being lazy on babune. the stack trace doesn't seem to be going through lazy regex http://pastebin.com/Z4qRJUGX
[08:20] <lifeless> mmm
[08:20] <lifeless> vila: ^ :)
[08:21] <parthm> does the test generate a .bzr.log with exception details?
[08:22] <parthm> vila: "python -Wall ./bzr --no-plugins selftest -v -s bt.test_osutils.TestReCompile" passes locally but fails on pqm.
[08:22] <vila> parthm: what os are you using ?
[08:22] <lifeless> parthm: oh
[08:22] <lifeless> parthm: run other tests that use re perhaps ?
[08:22] <lifeless> parthm: I suspect you're running into a test isolation issue of some sort.
[08:23] <parthm> vila: ubuntu 9.10
[08:23] <lifeless> possibilities: something puts the real re back; something triggers the regex you expect to be lazy before your test runs (solution, use your own private re), $something else.
[08:23] <parthm> lifeless: thats the only test thats failing now (even on pqm). rest all pass.
[08:23] <lifeless> parthm: great.
[08:23] <lifeless> bbiab
[08:24] <vila> parthm: babune is not supposed to change anything regarding loading python modules (the mere thought of it scares the hell out of me)
[08:25] <parthm> vila: is pqm on babune or is it a different system. just curious.
[08:25] <vila> parthm: nah, pqm is a totally different host/chroot/etc
[08:26] <parthm> oh ok. then its what i am seeing on pqm. babune is fine :)
[08:26] <vila> But is pqm still running 2.4 ?
[08:27] <parthm> vila: yes. thats what the error shows http://pastebin.com/Z4qRJUGX
[08:29] <parthm_> sorry. i dropped off.
[08:30] <parthm_> this is the failing test case. http://bazaar.launchpad.net/~parthm/bzr/300062-bad-pattern-error-part-1/annotate/head:/bzrlib/tests/test_osutils.py#L1718
[08:30] <parthm_> maybe its playing badly because i now have assertRaises + applyDeprecated together.
[08:31] <parthm_> but interestingly it works ok locally.
[08:31] <spiv> parthm_: have you tried 2.4 locally?
[08:32] <parthm_> spiv: yes. it passes with 2.4 as well as 2.6.
[08:33] <spiv> I doubt assertRaises or applyDeprecated would interact or otherwise be the cause.
[08:33] <spiv> Perhaps the deprecation decorator itself is involved?
[08:34] <spiv> Though that seems a bit unlikely too.
[08:35] <vila> parthm: too many interacting stuff here to diagnose remotely without reproducing :-/
[08:36] <parthm> vila: yes :( ... will see if i can try to reproduce it locally.
[08:36] <vila> parthm: generally, a test subset pass but not the whole test suite, you need to first run the full suite locally to see if *that* reproduce it
[08:38] <parthm> vila: makes sense. i will try to do that.
[08:39]  * parthm fires the full test suite
[08:41] <vila> lifeless: hmpf, best wishes for your new role but while this isn't fully unexpected it makes me sad :-(
[08:55] <parthm> i am starting to get the "can't start new thread" errors. is there something i can do? i am already using --parallel=fork.
[08:56] <vila> parthm: bump BZR_CONCCURENCY up
[08:57] <vila> BZR_CONCURRENCY
[08:57] <parthm> vila: what should i set it to? i have two cores.
[08:57] <vila> the precise value is: it depends :->
[08:58] <vila> I'd try with 4 then 6 or 8 depending on available resources
[08:58] <vila> parthm: be ready to ^C it if it start swapping like hell
[08:58] <parthm> vila: at the moment its not set. ok. i will try with 4. hopefully my 1gb ram won't be an issue. maybe its time for an upgrade :)
[09:00] <vila> 1GB seems a bit short, all babune slaves have 2GB
[09:00] <parthm> ok. everything seems ok till now ... 1500 tests. ... and its fast :)
[09:01] <vila> parthm: hehe, it sure is :)
[09:03] <lifeless> vila: THANKS
[09:03] <lifeless> bah
[09:03] <lifeless> thanks
[09:10] <parthm> vila: yup. the error is reproducible half way through the full suite run. now i just need to figure out whats causing the laziness to go away.
[10:03] <parthm> forcing lazyness seems to fix the problem http://pastebin.com/b5csDHQd .. while not the _right_ solution, i feel it should be ok as the api being tested is deprecated anyway and is not used.
[10:04] <parthm> should i be filing a bug for test isolation?
[12:59] <lifeless> night
[14:34] <GaryvdM> Hi all - Why do I get this error: http://pastebin.org/386377
[14:34] <GaryvdM> Which differs from the documentation: http://docs.python.org/release/2.6/library/threading.html#id1
[14:38] <GaryvdM> Ah - nvm - must just do lock.acquire(False), not lock.acquire(blocking=False)
[14:50] <mgz> hey Gary. where are you at with the installers? is 2.2b3 is a finished-ish state?
[15:13] <GaryvdM> Hi mgz
[15:13] <mgz> hey.
[15:13] <mgz> I'm just writing up a message for the list, can you read it before I post to make sure it makes sense?
[15:14] <GaryvdM> mgz: 2.2b3-2 does the -OO backed out...
[15:14] <GaryvdM> let me try again..
[15:14] <GaryvdM> mgz: 2.2b3-2 is built with your org  -OO patch backed out...
[15:15] <mgz> need to leave in an hour, won't be around again till Tuesday, so make any final choices on that for me
[15:15] <GaryvdM> mgz: I would like to try you py2exe hack
[15:16] <GaryvdM> mgz: Ok - I'm only going to start trying to build 2.2b4 next week any way
[15:16] <mgz> ah, cool.
[15:16] <GaryvdM> So - yhea - 2.2b3 probably  won't get any more bulids....
[15:16] <GaryvdM> (from me)
[15:17] <GaryvdM> mgz: I was just about to go to ice hockey practice, so I will only be able to read your mail much later.
[15:18] <mgz> ah, I'll just post it when I'm done then.
[15:18] <GaryvdM> ok
[15:18] <GaryvdM> mgz: What is it re?
[15:19] <mgz> what plugin authors need to know about docstring stripping
[15:19] <mgz> bascially summing up what's been said in the merge proposal and in here the last few days
[15:19] <GaryvdM> Oh - ok.
[15:21] <GaryvdM> mgz: I just want to make sure that we are on the same page with the -OO issue: We want to get it so that library.zip is -OO, but the exe's are -O.
[15:22] <mgz> ideally, yup.
[15:22] <GaryvdM> mgz: ok cool.
[15:22] <GaryvdM> bye
[16:06] <mgz> urk, running out of time
[16:15] <mgz> okay, email sent, and I'm leaving
[16:15] <mgz> as did it in a hurry, probably full of mistakes, feel free to correct me on things
[16:15] <mgz> back Tuesday.
[18:45] <LeoNerd> I don't suppose there's much by way of bzr/perforce integration, is there?
[18:46] <rockstar> LeoNerd, I know some Nvidia folks that are doing it, but I don't think it's publicly available.
[18:46] <LeoNerd> Right.. ahwell
[18:57] <james_w> LeoNerd: there is https://code.launchpad.net/bzrp4
[18:58] <james_w> no idea what state it is in
[19:05] <idnar> what are branch nicknames for?
[19:25] <chaosaddict> It seems like with a large repository (6000 commits, 40gb of files+history), routine commands take about an hr to return and use up all available memory. Does anyone know if this is a known issue and if it will be fixed in the future? I'm looking into migrating from Perforce to Bazaar for my company, but right now it looks like it would be much too costly.
[19:28] <idnar> is there an easier way to do "bzr merge -r before:ancestor:trunk.. feature-branch"?
[19:35] <mkanat> chaosaddict: I think one of the problems there is that most VCSes don't expect to be storing enormous binary blobs.
[19:35] <mkanat> chaosaddict: It is a known issue, though, that bzr uses up a lot of memory when dealing with large files.
[19:36] <mkanat> chaosaddict: I'll take a wild guess and say that this is a VCS for a game?
[19:36] <mkanat> Those are the only people I know who store enormous binary blobs in the VCS, are game developers.
[19:36] <mkanat> I understand why, it's just not something that most VCSes are geared toward.
[19:37] <mkanat> idnar: They show up in the log history.
[19:37] <mkanat> idnar: So you can tell what branch a commit was made on.
[19:37] <idnar> okay
[19:43] <chaosaddict> mkanat: It's not for a game. I think we just have a lot of files. It's been complicated by Perforce storing branches as copies of files, so we often have maybe 30 copies of the same file.
[19:43] <mkanat> chaosaddict: All right. But a single checkout is 40GB?
[19:44] <mkanat> chaosaddict: Or just the history is 40GB?
[19:56] <chaosaddict> mkanat: I imported all the code for one product, which probably has multiple logical projects that would normally be tracked separately in bazaar. Additionally, there are maybe 20 branches, that have no concept of a main trunk, so all the files are duplicate each time. The fast-import dump file was 30gb, and the resulting bazaar repository after import is 40GB for all the files, with the history.
[19:57] <mkanat> chaosaddict: Hmm. I wonder if you'd want to somehow hack up the importer to understand that some of those files have a common history.
[20:02] <chaosaddict> I think it did a good job of replicating what was in Perforce. I'm not quite sure how I would fix it. Maybe split off each branch into its own bazaar repository and merge it back into a main branch to preserve the history.
[20:14] <mkanat> chaosaddict: Well, if they have identical files, that won't work.
[20:14] <mkanat> chaosaddict: Because bzr doesn't recognize files by name, but by an internal id.
[20:20] <chaosaddict> mkanat: ah. So if the files don't have the same origin, as far as Bazaar knows, then they can't be merged with history preserved? We have fields in the files that Perforce updates with revision numbers and date submitted, etc, so the files won't even hash to the same value, even if they were the same as far as Perforce was concerned.
[20:20] <mkanat> chaosaddict: Right.
[20:20] <mkanat> chaosaddict: The importer has to understand from the start that those files have a common history.
[20:46] <lifeless> morning
[20:48] <chaosaddict> good morning
[22:14] <detritux> hi
[22:40] <hicham> bzr is acting weird when cloning a repo from lp
[22:44] <hicham> i have 50 MB of history for a 15 revisions branch, and it not finished yet
[23:20] <EdWyse_Office> Is there a way to fix an InconsistentDelta?
[23:21] <EdWyse_Office> I can find a lot of things that tell how to get to that state, but nothing about how to repair from it.


[07:39] <seaLne> has anyone heard of kmail no longer fetching (imap) after update to 4.13.97?
[10:25] <Mamarok> do you folks read the kubuntu-users list?
[10:28] <shadeslayer> I do not :(
[10:29] <yofel> I do usually
[10:30] <Riddell> only occationally
[10:30] <Riddell> Mamarok: something up?
[10:40] <shadeslayer> kubuntuBot: quit
[10:42] <shadeslayer> kubuntuBot is no more, all hail kubotu
[10:43] <yofel> kubuntuBot: he's trying to make fun of you :(
[10:43] <shadeslayer> kubuntuBot: quit
[10:43] <shadeslayer> why did that come back
[10:43] <shadeslayer> what
[10:43] <shadeslayer> what
[10:43] <shadeslayer> apachelogger: is that you
[10:43] <yofel> haha
[10:44] <Blizzz> hm, updates want to remove software calligra, digikam and kdenlive… ?
[10:44] <apachelogger> shadeslayer: no
[10:44] <apachelogger> dawn of the dead
[10:44] <apachelogger> clearly
[10:44] <shadeslayer> ok
[10:44] <apachelogger> ..
[10:44] <shadeslayer> dead
[10:44]  * shadeslayer shoots it in the head
[10:45] <shadeslayer> if it comes back, neon host has been take over by zombies
[10:45] <shadeslayer> IDK what you did in that last update
[10:46] <apachelogger> I think you just don't know how to use upstart :P
[10:46] <yofel> Blizzz: trusty with backports?
[10:47] <Blizzz> yofel: yes
[10:47] <yofel> ok, seems like Riddell never did the library transitions for this backport :/
[10:47] <Riddell> still in progress
[10:47] <Riddell> calligra is a beast..
[10:48] <yofel> shouldn't that just be a no-change rebuild?
[10:48] <Riddell> not really because it uses nepmouk so I wanted to work out what to do with it in utopic and backport that
[10:49] <yofel> ah
[10:49] <Riddell> and I've only just worked out what to do in utopic (I think, upstream is unsure but seems it only uses soprano not nepomuk and doesn't need virtuoso so I'll just change that build-dep)
[10:50] <yofel> Riddell: if you use copyPackage() you should also please read the PPA page a  while later:
[10:50] <yofel> Copied from: Private PPA for Kubuntu Ninjas. Copied by: Jonathan Riddell Target series: Trusty
[10:50] <yofel> artikulate 4:4.13.97-0ubuntu1~ubuntu14.04~ppa2 in trusty (source has no binaries to be copied)
[10:50] <apachelogger> needs automation
[10:51] <Riddell> artikulate needs the new qtgstreamer which is waiting on new kamoso and new kde-telepathy to exist
[10:51] <yofel> then don't copy it if it's incomplete :S
[10:52] <Riddell> yay 4.13.3 in trusty! vishesh will be happy
[10:53] <apachelogger> I think that is overestimating the enjoyment of software landing 6 weeks after upstream release :/
[10:54] <Riddell> I want to write a blog post to explain why patience is golden for packaging
[10:56] <yofel> ... as long as you apply that to your backports...
[10:56]  * yofel makes coffee and tries to stop being grumpy
[10:57]  * valorie adds a bit of brandy to yofel's coffee
[10:57] <soee> what about this http://qa.kubuntu.co.uk/plasma-status/build_status_5.0.1_utopic.html > :)
[10:58] <yofel> mhhh, thanks valorie :D
[10:58]  * shadeslayer is thinking of writing software to auto check for file conflicts
[10:58] <shadeslayer> on upgrades
[10:58] <valorie> why are you thinking instead of writing, shadeslayer?
[10:58] <shadeslayer> would supplement britney quite well
[10:59] <shadeslayer> valorie: not awake enough
[10:59] <Riddell> or do it like us catalans, cafe con heilo y cacaolat
[10:59]  * shadeslayer is reading ki18n docs
[10:59] <Riddell> shadeslayer: I'm pretty sure that already exists
[10:59] <yofel> shadeslayer: first write one that can go back and update broken breaks/replaces versions
[10:59] <shadeslayer> Riddell: oh? then why are not using that :S
[10:59] <shadeslayer> yofel: hm?
[11:00] <valorie> ah, reading the docs is preparation for writing, excellent
[11:00] <apachelogger> Riddell: depeche mode - slow
[11:00] <yofel> most of our beta/rc issues come from existing breaks/replaces whose versions are invalid
[11:00]  * valorie goes to lunch
[11:00] <apachelogger> yofel: broken versions?
[11:00] <shadeslayer> ^^
[11:01] <yofel> apachelogger: merge done in 4.13.1 -> breaks/replaces << 4:4.13.1-0ubuntu2~ or so, trusty now has 4.13.3 and is upgraded to .97, find the error
[11:02] <apachelogger> well
[11:02] <apachelogger> .97 is supposed to be derived from utopic, no?
[11:03] <yofel> so? the breaks/replaces are still wrong
[11:03] <Riddell> shadeslayer: dunno only exists for the ubuntu archive? needs investigation
[11:03] <apachelogger> and for the regular update stuff... perhaps it would be best if we always added the ubuntu version to all packages ever?
[11:03] <Riddell> shadeslayer: I'm also curious to know how rpm distros manage
[11:04] <apachelogger> oh wait that had not helped much had it
[11:04] <yofel> apachelogger: back when .1 was current we had: trusty: .1/utopic: .1 with b/r - now we have: trusty: .3, utopic .97 with .1 b/r
[11:04] <yofel> so they don't do anything unless you don't use trusty-updates
[11:04] <apachelogger> yes that computed
[11:05] <apachelogger> but the problem is not that .3 > .1 it is that 14.04.3 < 14.10.3
[11:05] <apachelogger> an issue to be mused on for sure
[11:05] <apachelogger> anyway, lunch
[11:06] <yofel> well yeah, lets use the ubuntu version as epoch? ^^
[11:08] <BluesKaj> Hiyas all
[11:43] <Riddell> ug, you can't comment a json file?
[11:49] <soee_> green :)
[12:02] <soee> lool :D
[12:02] <soee> just used the CTRL + SHIFT + M shortcutm in muon :)
[12:31] <Mamarok> Riddell: actually the last thread, where Orjen complains of not having announcements on Kubuntu news for new releases anymore
[12:35] <yofel> I'll excuse myself that recently I've had major issues editing drupal posts in rekonq and konqueror lately so I only do it when I really need to...
[12:35] <yofel> (Sometimes the javascript stops working completely so I have to edit the html classes in the rekonq dev tools to make items appear)
[12:36] <yofel> ovidiu-florin: how's the new site progressing?
[12:36]  * yofel goes to try writing a .3 post
[12:44] <yofel> shadeslayer: how do I run your patch parser?
[12:44] <yofel> $ ruby ubuntu-patch-parser.rb
[12:44] <yofel> ubuntu-patch-parser.rb:154: syntax error, unexpected tCONSTANT, expecting ')'
[12:44] <yofel>                          <meta charset="UTF-8">\n
[12:44] <shadeslayer> yofel: you want to use the python script
[12:44] <yofel> there is none
[12:44] <shadeslayer> oh
[12:44] <shadeslayer> wat
[12:44] <shadeslayer> damn
[12:44] <shadeslayer> yofel: I have it written on my work pc
[12:44] <yofel> ah well
[12:44] <yofel> do you have the link to your example output?
[12:44] <shadeslayer> yofel: essentially you want ubuntu-patch-parser.rb branch_name
[12:45] <yofel> do you by chance require ruby2?
[12:45] <shadeslayer> no
[12:45] <shadeslayer> hm
[12:45] <shadeslayer> something broke
[12:47] <shadeslayer> I know
[12:47] <shadeslayer> yofel: http://paste.ubuntu.com/8026477/
[12:48] <yofel> heh
[12:48] <yofel> hm, a setup.rb would be nice
[12:48] <yofel> /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- htmlentities (LoadError)
[12:48] <shadeslayer> ^^
[12:49] <yofel> how do I install that again?
[12:49] <shadeslayer> sudo gem install htmlentities
[12:49] <yofel> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kde4libs/debian/patches/".
[12:50] <yofel> this isn't svn ^^
[12:50] <shadeslayer> branch ? 0.o
[12:50] <shadeslayer> 165     branched = `bzr export patches lp:~kubuntu-packagers/kubuntu-packaging/#{package}/debian/patches`
[12:51] <yofel> aaaah
[12:51] <yofel> my fault, kde4libs != kdelibs
[12:51] <shadeslayer> ^^
[12:51] <yofel> that did the trick
[12:52] <shadeslayer> cool
[12:54] <soee> Riddell: release the kraken (5.0.1) :)
[12:55] <shadeslayer> yofel: essentially I wrote a python helper script that gets all the branches in kubuntu-packagers and feeds them to patch-parser
[12:55] <shadeslayer> yofel: but it's still on my work machine, I possibly forgot to bzr add
[12:56] <yofel> shadeslayer: also: http://paste.ubuntu.com/8026542/ - html doesn't know \n
[12:56] <shadeslayer> ah hm
[12:56] <shadeslayer> send MR
[12:57] <yofel> k
[12:57]  * shadeslayer rages at internet
[12:57] <shadeslayer> http://www.last.fm/user/shadeslayer_/now
[12:57] <shadeslayer> xD ^^
[12:58] <shadeslayer> oh hm
[12:58] <shadeslayer> spotify not scrobbling
[12:58] <shadeslayer> now it is \o/
[12:59] <shadeslayer> oh oh, I got upto 11100 plays
[13:00] <mcstr_> hmmm i have a problem.... since upgrading kde libs from 4.13.3 to 4.13.97 kdenlive is broken, calligra is broken and a few others as well
[13:00] <shadeslayer> mcstr_: define broken
[13:01] <mcstr_> @shadeslayer it was broken until i did a -f upgrade it fixed a few things then i did a -autoremove and now i have no kdenlive anymore no calligra anymore and if i want to install it over synaptic it says calligra-libs package is defect
[13:01] <yofel> mcstr_: known issue, Riddell was working on it
[13:01] <shadeslayer> :S
[13:01] <mcstr_> okay thx yofel
[13:19] <ovidiu-florin> yofel: It's usable, but I dont' think it's worthy of the public yet
[13:20] <yofel> ok
[13:37] <yofel> shadeslayer: http://yofel.dyndns.org/ext/patches/ubuntu-patch-status.html
[13:37] <shadeslayer> oooh
[13:37] <yofel> preferably I would like colors for upstream_*.diff etc. too
[13:37] <shadeslayer> nice
[13:37] <yofel> how do I do string matching in ruby?
[13:38] <shadeslayer> foo='foo'
[13:39] <yofel> hm, I'm off by one ^^
[13:39] <shadeslayer> yofel: hm?
[13:40] <valorie> ovidiu-florin: did you find anybody to test kde-telepathy/kdetalk with?
[13:40] <yofel> refresh and  look at the bottom ^^
[13:40]  * valorie just got both set up
[13:42] <apachelogger> ?
[13:49] <shadeslayer> yofel: ahh
[13:49] <yofel> I'm dropping rowspan, looks good but is a pain
[13:50] <yofel> (I need the final item count before the table is printed)
[13:50] <yofel> hm
[13:53]  * yofel hits shadeslayer for using a 2 space indent
[13:53] <yofel> who does that o.O?
[13:55] <valorie> shadeslayer is ignoring this
[13:55]  * yofel then hits ruby instead
[13:58] <yofel> fixed
[13:59] <shadeslayer> heh
[14:02] <yofel> not sure yet if I like or hate ruby, it has its good points, but so has pythong
[14:03] <yofel> the built-in perl stuff is tempting
[14:06] <yofel> kdelibs has a series.old o.O
[14:17] <yofel> shadeslayer: refresh, comments?
[14:18] <shadeslayer> oh oh oh
[14:18] <shadeslayer> what's the green stuff
[14:18] <shadeslayer> ah
[14:18] <shadeslayer> yofel: <3
[14:30] <yofel> shadeslayer: http://bazaar.launchpad.net/~yofel/+junk/ubuntu-patch-parser/revision/10
[14:30] <yofel> I'll leave it at that for now
[14:30] <shadeslayer> plz file mr
[14:31] <shadeslayer> https://www.dropbox.com/s/des7p23vf2tw9ew/randa_group_pic_preview.jpeg < konqi is sad
[14:31] <shadeslayer> because of all the sunlight
[14:32] <yofel> shadeslayer: launchpad doesn't seem to offer +register-merge for +junk :(
[14:32] <shadeslayer> :O
[14:32] <shadeslayer> stupid lp
[14:32]  * shadeslayer merges by hand
[14:34] <shadeslayer> yofel: merged and pushed
[14:56] <Riddell> mcstr_: what else is broken?
[14:58] <mcstr_> @riddell actually, only the calligra-libs package is shown as defective in synaptic BUT  see http://s8.postimg.org/e8349pe3p/synaptic2.jpg   all these above got removed when i checked for the kdelibs update....
[15:00] <Riddell> mcstr_: all the zu entfernen packages?
[15:00] <mcstr_> yeh... i cant reinstall them via synaptic as they require the calligra-libs package which then is marked as defective
[15:01] <Riddell> mcstr_: yep, that's all calligra stuff, I'm compiling that locally and should upload, it'll take a few more hours to compile in the PPA then you can install it
[15:01] <mcstr_> if i do it via apt-get in the console it suggests me to install other packages instead but whenever i try the suggested they depend on other things or refer to other things and cant be installed
[15:02] <mcstr_> cool thx riddell
[15:02] <mcstr_> and kdenlive btw
[15:02] <mcstr_> kdenlive got removed too and i cant reinstall that one either
[15:02] <Riddell> already uploaded should be compiling away
[15:02] <Riddell> watch the dials turn at https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/backports/+packages?field.name_filter=kdenlive&field.status_filter=published&field.series_filter=trusty
[15:03] <mcstr_> thx currently kdenlive depends on libnepomuk4 here and cant be installed
[15:04] <mcstr_> waiting thx
[15:31] <Riddell> mcstr_: calligra uploaded https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/backports/+packages?field.name_filter=calligra&field.status_filter=published&field.series_filter=trusty
[15:31] <Riddell> thanks for being an unwitting guinea pig
[15:32] <mcstr_> :p
[15:33] <mcstr_> negative... calligra still shows as defective, so does kdenlive
[15:34] <Riddell> mcstr_: it'll take a few hours to compile
[15:35] <mcstr_> ok then i ll check again later this evening after gym
[15:35] <Riddell> seaLne: ↑
[15:46] <seaLne> thanks
[16:28] <kdeuser56> apachelogger: https://forum.kde.org/viewtopic.php?f=285&t=122399
[16:29] <kdeuser56> apachelogger: please ping if you are back
[16:29] <apachelogger> ping?
[16:30] <kdeuser56> apachelogger: :)
[16:31] <kdeuser56> apachelogger: why the question mark? I meant mention my name so that I get an notification
[16:31] <kdeuser56> isn't this normally called ping?
[16:33]  * kdeuser56 away for some fresh air
[17:10] <Riddell> download.kubuntu.co.uk redirected to cdimage, cost for its use over the 10 days was $US 81.09
[17:10] <Riddell> with up to 100 downloads a day
[17:32] <allee> riddel: trusty 4.13.97 upgrade:  baloo4 should Replaces: baloo (because 2 files are in both pkgs)
[17:33] <allee> there's more confilkts, that vanished after 2nd dist-upgrade run
[17:33] <Riddell> thanks allee
[17:37] <allee> Riddell: new khelpcenter4 and kde-runtime-data .3 have a othercontrolmodules.desktop
[17:38] <allee> Riddell: both, new baloo-dev and baloo .3 have org.kde.baloo.file.indexer.xml
[17:39] <allee> looks like that's all
[17:43] <Riddell> who's the sflphone dude?
[17:50] <allee> a right, more recent sflpone would be nice.  Dude pong?  Take the pkg from daily ppa this starts at least.  Pkg in upstream 'stable' ppa is broken
[17:50] <kdeuser56> apachelogger: what do you think?
[17:51] <apachelogger> not sure applications should be listed
[17:51] <kdeuser56> apachelogger: why not, kmix currently does the same
[17:52] <kdeuser56> apachelogger: we could call it "streams" which would maybe be the more correct term
[17:53] <apachelogger> just because kmix does it doesn't mean it makes sense really
[17:53] <allee> kdeuser56: keep applications that's something my familie understands.   Stream and uhh, sink and they start screaming and run away
[17:54] <kdeuser56> apachelogger: i think many users will cry when they cannot control volume application wise ... that would be a very hated change imho
[17:55] <apachelogger> ehm
[17:55] <apachelogger> can't control it
[17:55] <apachelogger> except in the application :P
[17:55] <kdeuser56> yeah, but imagine the you can't in the application
[17:55] <kdeuser56> apachelogger: how would you turn off sound in firefox?
[17:57] <kdeuser56> apachelogger: imagine the user opens some site that plays sound all time and it annoys him because he wants to listen to music while being on that site ... the average user can't delete the sound file out of the source
[17:58] <apachelogger> firefox should allow muting?
[17:58] <kdeuser56> apachelogger: where?
[17:58] <apachelogger> well I dunno, I am not a firefox developer
[17:58] <kdeuser56> apachelogger: see, so is the average user
[17:59] <kdeuser56> apachelogger: i think you can compare it with client side decorations ... imho the same
[17:59] <apachelogger> no you can't
[17:59] <kdeuser56> why not?
[18:00] <kdeuser56> same situation: control something centrally vs. let only the application control it
[18:00] <apachelogger> applications can change the volume if you have global control
[18:00] <apachelogger> which you have anyway
[18:00] <apachelogger> just not in the default mixer display
[18:00] <apachelogger> because why would you because you have it in the app
[18:01] <yofel> apachelogger: I *do* like to be able mute specific stuff in kmix so please don't remove that.
[18:01] <yofel> but I guess I could just use pavucontrol
[18:01] <kdeuser56> apachelogger: would assume all applicaitons behave sane, which is obviously not the case
[18:01] <kdeuser56> yofel: the second argument was not a good one :p
[18:02] <apachelogger> I am not removing nothing
[18:02] <apachelogger> I am saying that having applications in the default mixer display is silly
[18:02] <yofel> aah
[18:02] <yofel> where would that be then?
[18:02] <yofel> kmix main window?
[18:02] <apachelogger> kcm
[18:02] <yofel> ok
[18:02] <yofel> I could live with that
[18:03] <kdeuser56> no, i could not live with that
[18:03] <kdeuser56> too much trouble
[18:03] <yofel> one more click is too much trouble o.O?
[18:03] <kdeuser56> yofel: no, buts not elegant imho and it add nothing
[18:04] <yofel> if you have many applications open then the kmix dialog is pretty cluttered
[18:04] <kdeuser56> yofel: why make things harder accessible when it's not necessary
[18:04] <kdeuser56> yofel: thats why my mockup has a scrollbar
[18:05] <Riddell> allee: uploaded fixes, those are issues with updates to 4.13.3 when replaces are set to 4.13.2
[18:05] <apachelogger> kdeuser56: you do not consider inputs in your mockup btw
[18:06] <yofel> how would those be different than outputs o.O?
[18:06] <kdeuser56> apachelogger: would be under applications (or better named streams, like it is currently in kmix). input stream is also just a stream
[18:07] <20WAA14SW> @riddell its looking good now with calligra.... synaptic seems to install it without any defective packages
[18:07] <kdeuser56> yeah one could seperate between input and output, but i guess adding "input" and "output" to the stream name is clear enough
[18:08] <Riddell> 20WAA14SW: great :)
[18:10] <Riddell> umm, why does this want to copy 5.0.0 and not 5.0.1?  ./copy-package -s utopic -p kubuntu-ppa --ppa-name=next-staging -b -p kubuntu-ppa --ppa-name=next oxygen
[18:10] <20WAA14SW> was a bit of a shock for me this morning to just doing an upgrade and it asked me to remove whole calligra suite and kdenlive :o
[18:11] <Riddell> sorry about that 20WAA14SW
[18:11] <apachelogger> kdeuser56: how do you tell apart input from output devices then?
[18:12] <kdeuser56> apachelogger: clicking, going to sinks tab, see if input is ticked
[18:12] <20WAA14SW> riddell no issue, i basically knew i join the irc channel and someone would either being already there fixing it or would start doing so... thx god this is not microsoft :P
[18:12] <kdeuser56> apachelogger: when you seperate input and output streams and list them, you will have duplicates, in case of stuff that goes to both, which is and should be also possible
[18:13] <yofel> Riddell: you want --to-ppa-name for the 2nd ppa
[18:15] <Riddell> oh yes, well spotted yofel
[18:16] <kdeuser56> apachelogger: by simply labeling them input /output, both
[18:16] <apachelogger> kdeuser56: the volume of the input device
[18:16] <apachelogger> not an source output
[18:16] <kdeuser56> what do you mean?
[18:17] <kdeuser56> input device volume control makes sense
[18:17] <apachelogger> yes but where does it go
[18:17] <kdeuser56> under devices
[18:18] <kdeuser56> now imagine you would want to test the microphone: simply click the input device, go to sinks tab, and select output device, then, if the microphone works, you can hear yourself speaking
[18:19] <apachelogger> kdeuser56: how do you tell an input and an output apart?
[18:20] <kdeuser56> apachelogger: by the name, we can simply append input or output to the name
[18:20] <kdeuser56> or do you mean pulse audio wise?
[18:20] <apachelogger> Oo
[18:20] <apachelogger> why don't we only make one list and append what kind of volume the bar might control
[18:20] <apachelogger> this seems rather inconsequential
[18:21] <kdeuser56> apachelogger: one list of what?
[18:22] <kdeuser56> apachelogger: because this would not allow advanced stuff in an easy way like looping back stuff to both output and input
[18:23] <kdeuser56> apachelogger: my idea is to add kind of an abstraction layer to make it easier for the user to achieve more advanced tasks
[18:24] <apachelogger> why would we do that?
[18:24] <apachelogger> there's a kc
[18:24] <apachelogger> m
[18:25] <apachelogger> where they could do eeeeeeeeeeeeeeeeeeverything
[18:25] <apachelogger> and in a much more convenient way than would ever be possible in the confiend space of the systray popup
[18:26] <kdeuser56> kc?
[18:26] <apachelogger> kcm
[18:28] <kdeuser56> apachelogger: i am not saying the systray popup should o eeeeeeeeeeverything ... just a few sensible taks, which DO fit in the space
[18:28] <kdeuser56> otherwise it will look pretty empty
[18:28] <kdeuser56> one slider is not much
[18:28] <kdeuser56> or two
[18:28] <apachelogger> why do we need to fill up the space?
[18:28] <kdeuser56> if we have something sane to represent in the space, why not?
[18:29] <apachelogger> because the user can have n inputs and n outputs
[18:29] <apachelogger> so the more stuff you add other than inputs and outputs the harder it gets to do anything
[18:30] <kdeuser56> that argument applies to anywhere ... even to a kcm
[18:33] <apachelogger> kdeuser56: no because we have no constraints on how much stuff fits inside
[18:33] <apachelogger> the tray area however is constraint by plasma itself
[18:33] <kdeuser56> i think opening a window for everything really sucks, especially if you work with many windows anyway. systray stuff and popups are supposed to save use from that.
[18:34] <kdeuser56> want to mute that distracting application? click, popup, mute, no window navigation needed
[18:35] <kdeuser56> that very much questions plasma in itself: why would anyone every need plasmoids, when everything fits in a window/kcm?
[18:36] <kdeuser56> we could throw the network plasmoid which is around of the same complexity over board with the same argument too
[18:36] <kdeuser56> cause you can have 10000 connections too
[18:37] <kdeuser56> or you could argue the tabs are useless, cause the monitoring is better done in an own kcm/application
[18:37] <kdeuser56> it is simply not imho
[18:41] <kdeuser56> most people do not have many sinks and streams, so it will fit in most of the cases without much scrolling
[18:41] <kdeuser56> i think regarding input/output sorting it is the same as in networkmanager plasmoid: sort after name, or signal strengh? ... the discussion will never end
[18:55] <soee> kinfocenter - have been kept back
[18:55] <soee> latest updates
[18:56] <yofel> which ones?
[18:57] <ovidiu-florin> valorie: yes, myself
[18:57] <ovidiu-florin> I created another account
[18:57] <soee> http://paste.ubuntu.com/8029006/
[18:57] <valorie> ha
[18:57] <valorie> well, I'm valorie there.....
[18:57] <ovidiu-florin> and logged in with both
[18:57] <valorie> Riddell: when you have a min, can you create a kanban board for KDE Books?
[18:58] <ovidiu-florin> I've added you, any notifications?
[18:58] <valorie> yes, it just went away quickly and I had to find it
[19:00] <yofel> Riddell: are you working on the digikam or kdenlive backport issues?
[19:07] <yofel> Riddell: I'm uploading a no-change rebuild for digikam until the new one is ready and I'll fix the kdenlive rebuild version
[19:27] <Riddell> thanks yofel
[19:30] <Riddell> valorie: ok
[19:30] <valorie> thank you my dear
[19:31] <Riddell> valorie: https://todo.kde.org/?controller=board&action=show&project_id=15
[19:32] <valorie> {{{{{{{{{{{{{{{{{{{{{{hugs}}}}}}}}}}}}}}}}}} and thanks!
[19:46] <ovidiu-florin> valorie: so it's developer oriented, very nice
[19:46] <ovidiu-florin> I want a copy
[19:46] <ovidiu-florin> when it's done
[19:47] <Mamarok> Riddell: thank ou verymuch for breaking Amarok, you removed libnepomuk...
[19:47] <Mamarok> doesn't run anymore
[19:49] <Mamarok> now I can't even test anything anymore, pplease put that library back!
[19:50]  * yofel wonders why it's again just me and maxy talking about the debian VCS move considering apachelogger was the one that originally wanted it -.-
[19:51] <apachelogger> because I am not connected to other networks righ now
[19:51] <yofel> we're freakin' CC-in kubuntu-devel..
[19:51] <yofel> *ing
[19:52] <Riddell> Mamarok: really? works great for me
[19:53] <yofel> libnepomukcore4abi1 is not removed on upgrade here so it shouldn't be broken...
[19:53] <Mamarok> yeah, had to rebuild it completely
[19:53] <yofel> Mamarok: how exactly did it break?
[19:53] <Mamarok> it expects libnepomuk4
[19:53] <Riddell> Mamarok: apt-cache policy amarok ?
[19:53] <Mamarok> I build my own one
[19:54] <yofel> doesn't here
[19:54] <yofel> # apt-cache depends amarok | grep nepo
[19:54] <yofel>   Depends: libnepomukcore4abi1
[19:54] <yofel> that's all
[19:54] <Mamarok> and I didn't rebuild after the kubunntu upgrade
[19:54] <Mamarok> -n
[19:55] <Riddell> Mamarok: what kubuntu version?
[19:55]  * Mamarok rebuilds...
[19:55] <Mamarok> takes like ages
[19:55] <Mamarok> well, the 4.13.97 updates you pushed yesterday
[19:55] <Mamarok> on 14.04
[19:57] <soee> Riddell: please take a look @ kinfocenter in a free time, some problems installing it
[20:05] <Riddell> soee: installing what version?
[20:06] <soee> Riddell: http://paste.ubuntu.com/8029510/
[20:10] <Riddell> soee: and what's the issue?
[20:10] <Riddell> aah I see it
[20:16] <Riddell> soee: uploaded ~ppa4 to fix it
[20:20] <soee> Riddell: what does the ~ppaX means ?
[20:20] <yofel> *sigh*
[20:20] <yofel> this backport is so buggy
[20:25] <yofel> Riddell: next time, before you copy *anything* into backports, please do an upgrade test in a chroot with the backports enabled and *at least* this installed: (with recommends) kubuntu-desktop, kubuntu-full, kde-full, digikam, kdevelop, calligra
[20:26] <yofel> nvm backports, anything except experimental, staging and staging-next
[20:35] <shadeslayer> needs automation
[20:35] <shadeslayer> all of it needs automation
[20:35]  * shadeslayer volunteers to write automation
[20:35] <yofel> go do that then, I don't care if it's automated or not
[20:35] <yofel> $something has to do it
[20:36] <valorie> sorry ovidiu-florin, I was off talking book
[20:36] <valorie> absolutely, it will be available in multiple formats, to one and all
[20:41] <valorie> I'm asked if ctrl-alt-backspace is disabled in Kubuntu?
[20:42] <soee> Riddell: fix for kinfocenter works fine
[20:43] <shadeslayer> valorie: controversial change
[20:43] <shadeslayer> valorie: it is
[20:44] <valorie> elcaset won't like that answer, I'm afraid
[20:45] <yofel> not our call to make I fear
[20:45] <yofel> IIRC sysrq+k is disabled by default too for security reasons
[20:45] <valorie> right, it's an ubuntu thing I believe
[20:51] <5EXAAN0YF> @riddell kdenlive is installing now fine too
[23:23] <allee> Riddell: trusty: kdepimlibs5-dev does not contain libkdepim.so  (and digikam 4. cmake claims can find libkdepimlibs)
[23:24] <allee> Riddell: trusty: kdepimlibs5-dev does not contain libkdepim.so (and digikae-m 4. cmake claims can find libkdepimlibs)
[23:25] <apachelogger> allee: libkdepim.so is from actual kdepim and not kdepimlibs
[23:28] <apachelogger> allee: apparently libkdepim doesn't even install headers
[23:28] <apachelogger> gotta check
[23:28] <allee> seem to be kdepim-dev ?
[23:30] <apachelogger> oh
[23:30] <apachelogger> allee: can you give me an error?
[23:31] <allee> uh, installing kdepim-dev wants to install the hole set of KDEPIM programs.  WTF?
[23:33] <allee> apachelogger: not a real error: digikam 4.2 cmake: --  libkdepimlibs library found.............. NO  (optional)
[23:33] <apachelogger> ah
[23:33] <apachelogger> allee: libkdepimlibs-dev? :P
[23:33] <apachelogger> NB: libkdepimlibs != libkdepim
[23:33] <allee> apachelogger: and I've noticed that /usr/lib/libkdepim misses the .so
[23:34] <apachelogger> latter is a private library used by kdepim and cannot be used form the outside because there's no headers
[23:36] <allee> apachelogger:  Hmm, okay.  then I have to restart ;-)
[23:51] <allee> apachelogger: is there a log that shows why     MACRO_OPTIONAL_FIND_PACKAGE(KdepimLibs) was not found?


[00:04] <stgraber> skaet: do we want tonight's daily to be considered as candidates? (if so, I'll need to enable the milestone and someone will need to change the config on the CD image builder)
[00:05] <skaet> stgraber,   pitti turned off the cron,  so please go ahead and enable the milestone.   The next set of builds should probably be posted.
[00:06] <stgraber> skaet: ok, do you want the daily milestone completely gone from the UI or just read only (marked as released)? (I guess it depends if you want to make it easy to see the current daily results)
[00:08] <skaet> stgraber,  I'm tempted to hide it to keep the confusion to a minimum,  but think it should be jibel's call.    Make it read only for now,  and lets see what he says tomorrow.
[00:08] <stgraber> skaet: done
[00:08] <skaet> Thanks stgraber. :)
[00:09] <stgraber> pitti: when you start building, just set milestone to "Precise Alpha 1" in ~/.isotesting.conf
[00:19] <cjwatson> ~/.isotracker.conf actually
[00:20] <cjwatson> stgraber,pitti: I've gone ahead and done ^- that now
[00:24] <stgraber> ah, right, isotracker.conf. Thanks
[04:18] <infinity> pitti: Does your ddeb-scraping mojo handle armhf?
[04:18] <infinity> pitti: Cause... We're building. ;)
[04:19] <infinity> pitti: And I have a hello-debhelper.ddeb for you. ;)
[04:24] <skaet> infinity,  \o/
[04:25] <wgrant> And now we wait...
[04:26] <infinity> And I keep sneakily seeding in more and more manually bootstrapped stuff to the stage-2 archive...
[04:30] <infinity> skaet: Almost done my testing here to feel good about that eglibc upload.  It'll definitely be "before I got to bed".
[04:31] <skaet> infinity,  coolio.   good to hear.
[04:39] <micahg> ooh, armhf, pretty
[06:39] <pitti> good morning
[06:41] <pitti> stgraber: noted for next time
[06:41] <pitti> infinity: not yet, hang on
[06:54] <pitti> infinity: eek
[06:54] <pitti> IOError: [Errno 28] No space left on device
[06:54] <pitti> infinity: so much for mopping up the new armhf ddebs :(
[06:55] <infinity> pitti: Erk.
[06:55] <pitti> a few weeks ago I already killed some 60 GB worth of maverick ddebs
[06:55] <infinity> pitti: Is that on your ddebination machine, or a buildd?
[06:55] <pitti> infinity: on macquarie, aka ddebs.u.c.
[06:55] <pitti> not the builders
[06:55] <pitti> but this now hosts the shop, ddebs, langpacks, etc.
[06:55] <infinity> Ouch.
[06:55] <pitti> and video.u.c.
[06:55] <infinity> video is likely the culprit...
[06:55] <pitti> /dev/sda3             537G  529G  2.7G 100% /
[06:56] <pitti> well, ddebs are huge, too
[06:56] <infinity> But you might want to put in an emergency call to IS before ddebs start disappearing from the buildds.
[06:56] <infinity> (I gave you 7 days or something, didn't I?)
[06:56] <pitti> right
[06:56] <infinity> It's been a while since all that insanity was written.
[06:57] <pitti> "nothign lasts longer than a stopgap solution"
[06:58] <pitti> I could also kill natty ddebs
[06:58] <pitti> but I'll file an RT first and whine in #is
[06:58] <pitti> but first I kick off a1 image buildls
[06:59] <infinity> Killing ddebs for releases we support really seems suboptimal.
[06:59] <infinity> Oh, thanks for the reminder that I need to upload eglibc and screw with your Alpha1. ;)
[06:59] <infinity> (It shouldn't screw with anything)
[07:00] <pitti> yes, it's the last resort indeed; I wasn't too attached to the maverick and powerpc ones, but it's still a pity
[07:00] <pitti> (we stopped collecting powerpc altogether)
[07:00] <infinity> ...
[07:01] <infinity> Yeah, also not happy about that. :P
[07:03] <pitti> ok, all builds are running, and shoudl auto-post
[07:03] <pitti> noted so in the pad
[07:04]  * infinity uploads eglibc, as promised earlier...
[07:07] <tumbleweed> meh, I was just asking for more stuff to be put on video.u.c
[07:07] <infinity> Those two services might need different machines. :P
[07:07] <infinity> Or to be moved to the NAS.
[07:08] <infinity> SAN?
[07:08] <infinity> I can never remember.
[07:08] <infinity> One of those.
[07:08] <infinity> I propose "NASAN" to end the confusion.
[07:08] <pitti> hm, so ddebs.u.c. weighs 308 GB
[07:09] <pitti> video.u.c. is just 27 GB
[07:09] <infinity> So, where's the other 200?
[07:09] <tumbleweed> video.u.c is about 20G out of date (probably more)
[07:10] <infinity> langpacks?
[07:10] <pitti> that's also quite heavy
[07:10] <pitti> but there's also a mirror on there
[07:10] <pitti> and shop. and uds.
[07:11] <pitti> and bugs-mirror.d.o, debzilla, and whatnot
[07:11] <pitti> it's a "dump it all here" machine
[07:17] <pitti> infinity: RT sent
[07:17] <broder> :( is there any way i can slurp down the ddebs before you start purging natty ones? i still care about those
[07:17] <infinity> pitti: I saw, thanks.
[07:17] <pitti> I don't want to remove them today
[07:17] <pitti> broder: I postpone armhf ddebs for the next 6 days (unless we get more space by then)
[07:18] <pitti> broder: but in general, it's a standard archive layout, so debmirror should do fine
[07:18] <broder> hmm, ok. now /me just has to go find 300G of spare space
[07:18] <pitti> broder: no, 308 GB is the whole archive
[07:19] <pitti> that is, {lucid,natty,oneiric,precise} x {i386,amd64,armel}
[07:19] <broder> oh, ok. so probably 1/4 of that for natty or so?
[07:19] <pitti> yes, or less if you only want one arch
[07:20] <pitti> my "next against the wall" is natty armel, when it comes down to "now or never"
[07:20] <pitti> http://<IP_ADDRESS>/qatracker/milestones/205/builds
[07:20] <pitti> nice, images do appear
[07:20] <broder> ok. i don't personally care about armel, so maybe i'll be ok :)
[07:21] <pitti> ♪ It's a kind of maaaagiiiic ♩ ♫
[07:22] <pitti> err, desktop livefses are built in a mere 8 minutes now!?! wow
[07:22] <pitti> our progress this cycle doesn't stop amazing me
[07:22] <pitti> if it wasn't for powerpc ruining the performance, we'd have kubuntu built by now, too
[07:26] <infinity> ppc will improve a bit "soon".
[07:53] <jibel> skaet, I'l hide dailies during a1 testing to avoid confusion
[07:56] <pitti> ah, thanks
[07:56] <pitti> jibel: bonjour
[07:56] <jibel> pitti, guten morgen
[07:57] <pitti> jibel: is there a difference between the "Precise" and "Precise daily ISOs" views?
[07:57]  * pitti figures it is currently autotesting the ubuntu desktops
[07:59] <jibel> pitti, as far as I can see, there's not much difference. Precise = Precise daily ISOs + upgrades
[08:00] <pitti> ah, upgrades and boot speed
[08:00] <pitti> right, thanks
[08:00] <jibel> right + boot speed
[08:49] <pitti> jibel: maybe I'm just too impatient, but desktop amd64 have finished testing half an hour ago, but no sign of the i386 iso tests yet; not even a failed one
[08:49] <pitti> or are other tests running in between?
[08:50] <jibel> pitti, they crashed
[08:50] <jibel> 'invalid argument'
[08:51] <pitti> ah, so that wouldn't show up as a "fail"
[08:51] <jibel> they will fail when the test will reach its timeout which is 60min
[08:51] <pitti> ah, good to know
[08:51] <jibel> I'll cancel the tests and run them again
[08:51] <pitti> merci
[08:52] <pitti> jibel: I'll try to find a simpler reproducer today, after I'm done with my current bug fix
[08:52]  * tumbleweed kicks himself for not getting the aptitude + multiarch breakage into the oneiric release notes :/ I keep seeing people hitting it
[08:52] <pitti> the "i386 on amd64" was a good hint, usually I'm using amd64 everywhere
[08:53] <cjwatson> infinity: hmm, what's up with https://launchpadlibrarian.net/86161322/buildlog_ubuntu-precise-armhf.net-snmp_5.4.3~dfsg-2.3ubuntu2_FAILEDTOBUILD.txt.gz ?
[08:54] <infinity> cjwatson: sbuild patch incoming.
[08:54] <pitti> oh, a cj "I ought to be on holiday" watson!
[08:54] <pitti> good morning
[08:54] <jibel> pitti, thanks. jsalisbury is on the case too.
[08:54] <infinity> cjwatson: base system dpkg doesn't know about armhf.  Fixing sbuild to use the dpkg-architecture in the chroot seems saner than trying to upgrade dpkg in every past release that's running on all the buildds.
[08:55] <cjwatson> I am on holiday, I've just been rousted out of bed in order to make a trip to the doctor's surgery, and IRC/mail is a good way to wake up
[08:55] <cjwatson> infinity: ah, good, yes
[08:56] <cjwatson> that makes everything fail to build, yes? :)
[08:56] <infinity> cjwatson: No, just anything with "Architecture: any all" and anything with "foo [linux-any]" style build-deps.
[09:00] <cjwatson> ah, ok, not quite the whole world then
[09:05] <infinity> cjwatson: No, just large portions of it. ;)
[09:09] <mvo> is it ok to upload a new update-manager and software-center today (asking because of the soft freeze)
[09:11] <pitti> mvo: what's the nature of the changes there?
[09:12] <mvo> pitti: for u-m its merging back the recent security and some minor fixes, for s-c mostly the addition of the system-wide license key support
[09:13] <mvo> pitti: I can wait with the s-c upload as it will also bring in a new dependency (software-center-aptdaemon-plguins)
[09:13] <pitti> mvo: u-m sounds fine, please go ahead
[09:13] <pitti> for s-c, I agree, let's wait until after a1
[09:13] <mvo> thc
[09:13] <mvo> ups, thanks
[09:13] <pitti> that'll need an MIR?
[09:14] <pitti> oh, source/bin NEW
[09:14] <mvo> I guess, but its really part of s-c itself, its just the twisted setuptools that made me split it into its own package
[09:14] <pitti> yeah, MIR should be trivial
[09:15]  * mvo nods
[09:42] <jibel> cjwatson, the logging issue with desktop tests is fixed, I'll update jenkins in the afternoon after Carlos review.
[09:49] <pitti> jibel: so the i386 desktop tests worked now, nice
[09:51] <jibel>  pitti , yes, just need to run it 2 or 3 times. this bug is painful. I can't reproduce it on HW which is good news.
[10:02] <cjwatson> jibel: thanks
[11:16]  * pitti retries the xubuntu daily, there's no obvious reason for the bzr branch checkout failure (checked with #bzr)
[11:16] <pitti> looks like a glitch
[11:20] <cjwatson> that looked like temporary network trouble to me
[11:26] <pitti> cjwatson: right, that's what I hoped; and there it is
[11:27] <pitti> (i. e. both buildds succeeded)
[11:38] <wgrant> pitti: What time was it?
[11:38] <wgrant> LP was down from 0831-0832ish.
[11:39] <pitti> From<EMAIL_ADDRESS>Tue Nov 29 09:28:58 2011
[11:39] <pitti> wgrant: so, could be
[11:39] <wgrant> Hm.
[11:41] <nigelb> pitti: the builds should go make tea when LP is down (I think the package importer had a bug for that)
[12:17] <debfx> can I upload kde-workspace to drop kde-wallpapers (~40 MB) from the kubuntu image again?
[13:32] <pitti> fine for me
[14:35] <jibel> bug 897680
[14:35] <ubot4> Launchpad bug 897680 in ubiquity (Ubuntu Precise) (and 1 other project) "12.04 64Bit: libc6 fails to install if "install 3rd party software" is selected (affects: 1) (heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/897680
[14:36] <pitti> jibel: thanks
[15:08] <skaet> pitti,  good morning
[15:09] <pitti> hey skaet
[15:10] <pitti> FYI, we have two reasons for respinning, see pad
[15:10] <skaet> pitti,  looks like iso tracker is up, bugs getting reported, all flowing as it should,  will look at the pad now.
[15:16] <skaet> pitti, re: libc one, ouch.   Do we need to find someone to help figure it out, or are you looking into it.
[15:16] <skaet> ?
[15:17] <pitti> skaet: mterry is looking into it for now, but I'll also have a look
[15:17] <pitti> I spent most of the day on bug 894768 and bug 893826
[15:18] <ubot4> Launchpad bug 894768 in linux (Ubuntu Precise) (and 1 other project) "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument (affects: 5) (dups: 4) (heat: 44)" [High,Triaged] https://launchpad.net/bugs/894768
[15:18] <ubot4> Launchpad bug 893826 in qt4-x11 (Ubuntu Precise) (and 3 other projects) "symlinked docs are different between architectures, depending on dpkg-deb package order (affects: 19) (dups: 17) (heat: 172)" [High,Fix released] https://launchpad.net/bugs/893826
[15:18] <pitti> skaet: I need to run out for a bit, but we'll continue to look into this
[15:19] <cjwatson> pitti: I left a comment explaining bug 897680
[15:19] <ubot4> Launchpad bug 897680 in ubiquity (Ubuntu Precise) (and 1 other project) "Precise Desktop 64Bit: libc6 fails to install if "install 3rd party software" is selected (affects: 1) (heat: 8)" [Critical,Triaged] https://launchpad.net/bugs/897680
[15:20] <cjwatson> judging from the archive, a respin with no changes should fix that
[15:20] <cjwatson> I mean with no further uploads
[15:20] <skaet> cjwatson, mterry - thanks.   :)
[15:22] <pitti> cjwatson: oh, splendid
[15:22] <skaet> pitti, so language selector appears build and published, kick off the respins?
[15:22] <pitti> skaet: looks like it then
[15:22] <skaet> :)
[15:23]  * skaet looking forward to seeing this new stuff in action
[15:24] <pitti> skaet: it's great
[15:24] <pitti> I basically just did the image commands on nusakan, and posting and smoketesting happened fully automatically
[15:25] <stgraber> good to hear nothing exploded :)
[15:25] <pitti> so 897680 affects all desktops/DVDs
[15:25] <pitti> so we can keep kubuntu alternate, server, and core
[15:28] <skaet> won't language selector be needed for those?
[15:29] <pitti> right
[15:30] <pitti> skaet: ah, misinterpreted as "for the rebuilds"
[15:30] <pitti> skaet: the language-selector crash only affects the -gnome flavour
[15:32] <skaet> heh,  time for me to do some learning,  I was seeing the other binary packages built by this source, and figuring the scope was larger.
[15:39] <pitti> skaet: ok, all builds running; had to wait for a bit with the alternates for l-s
[15:39] <pitti> let the magic do its work
[15:39]  * pitti really needs to run out now, bbl
[15:41] <skaet> thanks pitti,  l8r
[15:45] <skaet> stgraber,  where should the comments be in the tracker about the reason for the rebuild?
[15:46] <stgraber> skaet: they'll appear at the top of a build page (testcase list, result list, download information, ...) in the notice board.
[15:49] <skaet> stgraber,  am not seeing anything about the current rebuild there right now,  does the reason need to be manually added?
[15:51] <stgraber> skaet: yes, someone to update it. It can be updated from the admin UI or when adding a new build (from either the admin UI or the API).
[15:51] <skaet> stgraber, ok,  we'll need to make that explicit.   Let me try now.
[15:52] <stgraber> I think the best would be to have that note be on nusakan and automatically pushed through the API when the new builds are ready. This way it'll get included in the notification e-mail.
[15:53] <stgraber> so instead of saying why something is being rebuilt (that needs manually updating from the admin UI and won't notify the testers by e-mail), we tell them what's different when the new build is announced
[15:55] <skaet> stgraber,  yeah that seems like a better flow.
[15:57] <stgraber> cjwatson: do you want a patch for that one ^ (basically passing the content of a file to the note parameters of builds.add, currently set to '')?
[16:03] <scott-work> skaet (and probably stgraber) if it's not too much trouble i would prefer not to publish and test the ubuntustudio alpha 1 image since there really isn't much difference from oneiric
[16:08] <skaet> scott-work,  no trouble and your call,   we'll remove them from the alpha-1 list then.
[16:09] <skaet> pitti ^ ubuntu-studio removed (but may reappear from your rebuilds).
[16:12] <scott-work> skaet: would you prefer such a notice earlier?  is it bad form to ask this close to alpha1?
[16:13] <skaet> scott-work,  earlier the better.  :)   I'll have the ReleaseImageContacts page sorted out soon,  and you can just indicate the milestones you want to participate in on there.
[16:14] <scott-work> i'm creating a project lead/team "playbook" for ubuntu studio parsed by milestone that lists required activities and i'll place this in there as well
[16:19] <cjwatson> stgraber: sure - if we want it for a1 get somebody else to review/apply/deploy it though, I'm not really here :)
[16:20] <stgraber> cjwatson: oh right, I forgot you're not supposed to be around today ;)
[16:33] <mterry> Hello!  Is bug 897380 important enough to break soft freeze for?  Debdiff in the bug
[16:33] <ubot4> Launchpad bug 897380 in imagemagick (Ubuntu) "PerlMagick fails at runtime in precise (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/897380
[16:34] <stgraber> pitti: that's the change to isotracker_xmlrpc.py I mentioned before: http://paste.ubuntu.com/753813/
[16:34] <stgraber> pitti: then if present ~/.isotracker.note will be sent to the tracker, included in the notification e-mails and displayed in the header on the site
[16:35] <pitti> stgraber: ah, thanks
[16:48] <skaet> mterry,  change seems small,  not sure we'll respin for just it,  but if we need to respin for something else,  it wouldn't hurt to have it in I think,   pitti - feel free to disagree.  :)
[16:51] <pitti> mterry: looks fine to upload
[16:51] <mterry> k
[17:17] <SpamapS> hmm seems amarok missed the libmysqlclient transition sweep..
[17:19] <debfx> SpamapS: I've uploaded amarok yesterday, what's missing?
[17:20] <SpamapS> hm never mind, its good
[17:20] <SpamapS> for some reason my system showed it still needing libmysqlclient16
[17:30] <debfx> SpamapS: do you know why mysql-client-core-5.5 gained so much weight compared to 5.1 (+ 6.5 MB installed size)?
[17:30] <SpamapS> debfx: I don't, but I'll look into it.
[17:31] <debfx> thanks
[17:33] <SpamapS> debfx: I'm going to guess cmake has had a hand in this evil ;)
[17:35] <SpamapS> debfx: doh!!!
[17:36] <SpamapS> debfx: libmysqclient is statically linked in
[17:37] <debfx> nice
[17:39]  * SpamapS curses cmake
[17:39]  * SpamapS also curses mysql's source release engineering.. or lack thereof
[17:42] <nigelb> heh
[17:56] <pitti> skaet: so, new builds trickle in and get properly auto-posted
[17:56] <pitti> and jenkins jumps at them and tests them, too
[17:57] <skaet> pitti,  i'm seeing,  and beeing delighted.   MUCH MORE EFFICIENT!
[17:57] <pitti> you bet!
[17:57] <pitti> skaet: can you take it from here?
[17:57] <pitti> the fix for bug 897680 should be confirmed
[17:57] <ubot4> Launchpad bug 897680 in ubiquity (Ubuntu Precise) (and 1 other project) "Precise Desktop 64Bit: libc6 fails to install if "install 3rd party software" is selected (affects: 1) (heat: 10)" [Critical,Fix released] https://launchpad.net/bugs/897680
[17:57] <pitti> but otherwise I'm not aware of outstanding blockers
[17:57] <pitti> jibel mentioned OEM mode being slightly broken
[17:57] <skaet> pitti,  let me check a couple of things quickly (ie. access is working ok0
[17:58] <pitti> but that sounds like something we could document
[17:58]  * skaet nods re: OEM stuff
[17:58] <pitti> precise-desktop-i386_oem didn't re-test, I suppose it's another victim of the EINVAL bug
[17:58] <pitti> so jibel or someone else needs to poke this to have it re-run
[17:58] <pitti> but I can't do that eitehr
[18:02] <utlemming> Cloud images are being respun -- eta is 22:00 UTC
[18:02] <skaet> thanks utlemming
[18:05] <skaet> pitti,  ok,  access check out.   I've got it for now.    Have a good evening.
[18:05] <pitti> cool, see you tomorrow!
[18:17] <pitti> skaet: will you remove the "rebuild in progress.." note from the tracker once all images are back in?
[18:18] <skaet> pitti, yup, was planning on doing it after the last one landed.
[18:23] <Daviey> skaet: currently cloud images for Alpha 1 do not boot in kvm or openstack.  The fix has been identified, but would require a kernel upload.
[18:23] <Daviey> For alpha 1, I'm not sure it's worthy of a new kernel, unless one is needed for another reason.
[18:24] <Daviey> ogasawara said that they can have a fix queued for upload as soon as you thaw the freeze, and we can have functional images 4-5 hours later.
[18:24] <smoser> the -virtual kernel is never selected by the installer, is it?
[18:24] <Daviey> no, not afaik
[18:25] <smoser> i did not think so, but cjwatson would know. if it is, then this is more serious as it would affect all vm install.
[18:25] <skaet> Daviey,  yup, was following in release channel.    Having it uploaded and ready in case we respin would make sense.    Do we want this just for the cloud images, or for all of them?
[18:25] <smoser> or some subset of vm install.
[18:25] <smoser> the -virtual kernel is not on the media so it would not affect ISOs i would not think.
[18:25] <Daviey> skaet: it's the virtual kernel flavour which only makes sense on kvm/xen/cloud
[18:26] <skaet> thanks smoser,  Daviey.
[18:26] <skaet> Daveiy,  if its only for the virtual kernel, then yes, I'm fine with the timing you and ogaswara recommend.
[18:27] <Daviey> skaet: In perspective, this is Alpha 1.  I'm really excited about rushing around to get this solid.  It's a benchmark in the cycle, and we have caught the fix that can be release noted.
[18:27] <Daviey> smoser feels it's more pressing
[18:28] <smoser> i feel that a -virtual kernel that is not useful in a virtual environment is a significant issue.
[18:28] <smoser> but we would be running around like a chicken for 20 hours probably to get it fixed.
[18:29]  * skaet scratches head over Daviey's comments "I'm really excited"... did he mean "I'm really not excited"?
[18:30] <bjf> does QA use the -virtual kernel for any of their testing ?
[18:30] <skaet> bjf,  good point.
[18:30] <skaet> jibel, ^^
[18:30] <smoser> the primary benefit to me is having alpha1 images that booted in openstack so we can later compare something against a known quantity.
[18:30] <ogasawara> bjf: I'd guess no, if we're just seeing this now.
[18:30] <smoser> if the image doesn't boot, then we can't do that.
[18:31] <bjf> ogasawara: i agree, but i wanted to make sure
[18:31] <smoser> ogasawara, i would also guess 'no', but we will be getting there with openstack testing. automatically testing latest images.
[18:31] <smoser> but even if we were, we found this pretty soon after it landed in the archive.
[18:31] <Daviey> skaet: yes, really not
[18:32] <Daviey> I can confirm that precise worked for me on sunday, under kvm/openstack
[18:33] <tgardner> Daviey, wouldn't that have been a 3.2 kernel ? It should have had the same issues.
[18:33] <skaet> interesting,   we did pick up a new kernel but it should have been unrelated I would have thought.
[18:33] <ogasawara> Daviey: which version?  the last upload we did was on Friday. but the 3.2 kernel we've had uploaded and in the archive for a while now.
[18:34] <ogasawara> Daviey: correction, the last upload was yesterday, but that was only a config change that affected arm.
[18:34] <Daviey> ogasawara: hmm, that doesn't make sense
[18:35] <tgardner> ogasawara, when did you upload meta ?
[18:35] <ogasawara> tgardner: apw uploaded meta yesterday?
[18:35]  * ogasawara checks
[18:36] <tgardner> ogasawara, I was just wondering when the 3.2 kernel might have actually been referenced.
[18:36] <smoser> the last thing know i've booted in kvm with networking was from the 22nd.
[18:36] <Daviey> Hmm, seems i am on 3.1 kernel
[18:36] <smoser> ok..
[18:37] <smoser> so another option we could pursue here is to respin cloud-images with a one time inclusion of 'linux-image-extra-virtual'
[18:37] <ogasawara> smoser, Daviey, tgardner: yep the first <IP_ADDRESS>.1 linux-meta package was uploaded on Nov 23
[18:37] <smoser> which woudl get us the necessary modules. and i've verified that that gets me a booting system.
[18:37] <smoser> it comes at a cost of 87M (per apt) of modules that we've not had before.
[18:37] <Daviey> smoser: that wouldn't be removed on upgrades?
[18:38] <smoser> well, if we added the meta-package, it would pull in the -extra for new kernels on upgrade.
[18:38] <smoser> if we add just linux-image-extra-3.2.0-2-virtual, then we'd only get it for that kernel.
[18:39] <smoser> i dont think *anything* (kernels) get deleted on upgrades
[18:39] <tgardner> smoser, that true. besides, its a development problem. what a few extra MB ?
[18:40] <smoser> at the moment i'm leaning towards that hack solution.
[18:40] <ogasawara> smoser: +1
[18:40] <smoser> as it limits the people who are running around like chickens without a head.
[18:40] <tgardner> I resemble that remark.
[18:40] <ogasawara> heh
[18:40] <smoser> and i'm thinking to just add the linux-image-extra-3.2.0-2-virtual also so that upgrades wont get the -extra.
[18:41] <ogasawara> smoser: yep, sounds good
[18:41] <ogasawara> smoser: we can still have the official fix queued and I'll immediately upload upon Alpha1's release
[18:42]  * skaet nods
[18:43] <Daviey> smoser / ogasawara / tgardner: As long as it is removed on upgrades, works for me
[18:44] <smoser> it wont be removed on upgrades.
[18:44] <ogasawara> Daviey: it won't be removed on upgrades
[18:44] <smoser> kernels are never removed on upgrades
[18:44] <Daviey> then it sucks as a hack.
[18:44] <smoser> (it matches linux-image, so it would not be).
[18:44] <smoser> no more so than kernels are a hack.
[18:44] <smoser> :)
[18:44] <Daviey> i'd rather we defer the cloud image release by 24 hours TBH.
[18:45] <tgardner> Daviey, I think smoser's hack would only apply to one kernel. The next ABI bump would be back to normal.
[18:46] <smoser> right. you'd only get -extra on upgrades from alpha1 cloud images for that kernel.
[18:46] <smoser> the 2 things that will suck about it that i can think of now are
[18:47] <smoser> a.) 87M of wasted space (i'm not concerned about that)
[18:47] <smoser> b.) you would not know that othe rmodules you needed are not going to be there later
[18:48] <smoser> if someone is actually upgrading all the way to release from alpha1, they're going to have work around worse than having to 'apt-get --purge remove linux-image-extra-*'
[18:51] <smoser> Daviey, ?
[18:51] <Daviey> sure
[18:53] <GrueMaster> stgraber: The links to images on the new tracker are off for all of armel & core.  Neither have "iso" files.
[18:53] <stgraber> jibel: ^ (want me to fix that?)
[18:54] <GrueMaster> I take it back.  Looks to be core only.
[18:54] <stgraber> ok, if it's only core I can just fix them by hand now
[18:55] <GrueMaster> http://cdimage.ubuntu.com/daily-preinstalled/20111129/precise-preinstalled-desktop-armel+mx5.iso should be http://cdimage.ubuntu.com/daily-preinstalled/20111129/precise-preinstalled-desktop-armel+mx5.img.gz (or whatever after the rebuild).
[18:56] <GrueMaster> ac100 is perfect.  Has both the bootimg & rootfs tarball linked.  That is excellent.
[18:56] <stgraber> GrueMaster: looks like ti affects desktop armel mx5 as well
[18:56] <stgraber> ah right, just read backlog :)
[18:57] <stgraber> so my query seems to match your list, good, fixing that now
[18:57] <GrueMaster> I'm double checking the links now.  Core and desktop-armel+mx5 are the only ones so far.
[18:58] <stgraber> qatracker=> SELECT DISTINCT qatracker_product_download.filename, qatracker_product.id FROM qatracker_product_download LEFT JOIN qatracker_product ON qatracker_product.id = qatracker_product_download.productid WHERE qatracker_product_download.filename ~ '.iso' AND qatracker_product.title ~'armel';
[18:58] <stgraber>                   filename                  | id
[18:58] <stgraber> --------------------------------------------+-----
[18:58] <GrueMaster> omap/omap4 both look good.
[18:58] <stgraber>  precise-preinstalled-desktop-armel+mx5.iso | 229
[18:58] <stgraber>  precise-preinstalled-core-armel.iso        | 220
[18:59] <GrueMaster> precise-preinstalled-core-[armel|amd64|i386] all should be .tar.gz.
[19:07] <stgraber> GrueMaster: ok, I think I got them all
[19:08] <stgraber> GrueMaster: can you also confirm that it's only the ac100 that requires a separate boot image?
[19:09] <GrueMaster> Yes, it is at the moment.  Not sure what the future may hold if we can get more community enabled platforms.
[19:09] <GrueMaster> We'll cross that when it happens.
[19:09] <stgraber> good, just wanted to make sure I didn't forget any
[19:14] <stgraber> GrueMaster: there you go for an ac100 image: http://<IP_ADDRESS>/qatracker/milestones/205/builds/7250/downloads
[19:14] <stgraber> oh, interesting, seems like the table title is wrong, fixing that now
[19:16] <stgraber> fixed
[19:16] <GrueMaster> Excellent!
[19:17] <GrueMaster> Now I just need to figure out the best way to test core images.  Was thinking lxc, but may just use chroot for now (less confusing and quicker).
[19:18] <stgraber> GrueMaster: want an lxc one liner to start them?
[19:19] <stgraber> (testing the idea on my panda quickly)
[19:19] <GrueMaster> If you have one, that would be cool.  Need to be able to control on i386 & arm ideally.  I'm creating a jenkins job here now.
[19:39] <stgraber> GrueMaster: looks like I have something that works (not exactly one line, but one script), just re-running to test, forgot how bad my panda is at I/O :)
[19:40] <stgraber> currently using it as a mediacenter with xbmc using a network drive so I only really notice when messing with the system :)
[19:40] <GrueMaster> My pandas are all running off USB-Sata, so I can get a little better performance.
[19:41] <stgraber> GrueMaster: so that's what it looks like http://paste.ubuntu.com/754014/ and the script (prepare.sh) is http://paste.ubuntu.com/754015/
[19:42] <stgraber> GrueMaster: you'll probably want to change some bits to make it entirely automated
[19:42] <stgraber> but at least it unpacks, it boots and it shuts down
[19:42] <stgraber> lxcguest is currently required so that mountall plays nice but we plan on fixing that this cycle so any regular Ubuntu system can boot in LXC without modification
[19:43] <GrueMaster> I'll also have to ass a step to run apt-get update and install a test package, but thanks.  Helps out a lot.
[19:43] <GrueMaster> Erm.  Add a step (sorry).
[20:07]  * skaet notes that everything has now been rebuilt except the arm image in less than 4 hours...  sweet.
[20:08] <micahg> now if we can just get the builders to work that fast :)
[22:12] <bdmurray> How do the meta-release files get updated on changelogs.ubuntu.com?  I ask as I just fixed a mistake in one of them
[23:22] <infinity> Oh, FFS.  I completely forgot about the freeze and uploaded mono.
[23:22] <infinity> (armhf-only fix, not impact on other arches except for a version bump)
[23:22] <infinity> s/not/no/
[23:23]  * skaet hopes those are not famous last words....
[23:23] <Laney> Is mono still on images?
[23:23] <infinity> Oh, there's that.  We may have removed it by now anyway. :P
[23:24] <infinity> skaet: It added one symbols file with an extension of .armhf, if that breaks other arches, then mono was already broken. ;)
[23:24] <skaet> :)
[23:24]  * skaet doesn't rule this out,  but last touch rule applies ;)
[23:25] <tumbleweed> Laney: mono-runtime still seems seeded for edubuntu
[23:25] <infinity> Yeah, I don't look forward to all the TILM I'll end up with.
[23:25]  * skaet hopes we won't need to rebuild then.
[23:26] <skaet> no blockers showing up so far this afternoon that anyone has pinged me about.
[23:27] <infinity> A bit of archive/image skew on alphas isn't the end of the world anyway.  And if a rebuild needs to happen for some other reason, fresh mono for edubuntu for free. :P
[23:27] <Laney> good, I'm glad edubuntu knows what's right :-)
[23:27]  * infinity keeps the soft freeze in mind and stages the rest of his armhf fiddling locally.
[23:29] <Laney> infinity: do you have a build log perchance?
[23:29] <infinity> Laney: Of..?
[23:29] <Laney> I would be interested to see if the situation has improved since debian bug 639342
[23:29] <ubot4> Debian bug 639342 in mono "mono: please add armhf support [PATCH]" [Important,Open] http://bugs.debian.org/639342
[23:29] <infinity> https://launchpadlibrarian.net/86215844/buildlog_ubuntu-precise-armhf.mono_2.10.5-1_FAILEDTOBUILD.txt.gz
[23:30] <Laney> a successful one ...
[23:31] <infinity> Laney: That would be successful if the symbols file was right.
[23:31] <infinity> Laney: (Which is what I just uploaded to fix)
[23:31] <Laney> thought you might have a local one
[23:31] <infinity> Nein.
[23:31] <infinity> Though I'm now wondering if I wanted that --with-fpu hack from the Debian bug...
[23:32] <infinity> Maybe it cleverly autoselects.
[23:33] <Laney> I'm not sure it will work. Upstream were talking about an armhf port the other day, which implies that mainline is not (fully) ported.
[23:34] <infinity> Hrm.  Well, it fails a few more tests than armel, but not a lot.
[23:34] <infinity> Perhaps I should do some local fiddling.
[23:34] <infinity> I still suspect my upload will be enough to get it built and function as a build-dep.
[23:34] <Laney> yeah, 'least we can test
[23:35] <stgraber> hmm, wondering why Edubuntu still has mono, thought we got rid of that...
[23:36] <Laney> boo
[23:36] <Laney> do you have gbrainy?
[23:36] <infinity> Laney: Going to do some local testing now.
[23:36] <infinity> Laney: It's that or java, and mono being installable makes it win.
[23:37] <stgraber> we shouldn't have it, we're based on the ubuntu desktop seed, so we should have lost tomboy, banshee and gbrainy at the same time Ubuntu did
[23:37] <Laney> ok. vargaz in #monodev is your man btw.
[23:37] <stgraber> oh, found it, pdfmod is probably the one pulling mono
[23:38]  * Laney sheds a tear for good apps
[23:38] <stgraber> we're currently in the position where we'll drop mono for 12.04 if we are the ones who end up having to care for it for the LTS (5 years). If someone else is going to take care of mono anyway (because of bindings or whatever), then we'll seed gbrainy explicitly as well as make sure we keep pdfmod and maybe bring back tomboy (not sure about that one)
[23:39] <stgraber> (where we means Edubuntu)
[23:39] <Laney> meh, we never got that much support from non-mono-team anyway
[23:40] <stgraber> Laney: yeah, it's just that for LTS approval I have to give a list of source packages that aren't seeded and that we ship, we're expected to take care of these for the 5 years of the LTS
[23:40] <stgraber> and my personal goal is to make sure we don't have mono, java or any programming language on that list :)
[23:41] <stgraber> I'm fine supporting apps for 5 years, not programming language and hundreds of libraries (that last one is mostly for our java stuff ;))
[23:43] <stgraber> anyway, I need to clarify that for our proposal to the TB (exact list of Edubuntu-specific packages, list of these that we'll support ourselves, mostly these that aren't in main and list of these that we'll try to drop somehow)
[23:44]  * Laney thinks mono could be advertised to people being held on other operating systems by .NET apps as a route to migration
[23:45] <stgraber> it probably could yes, not sure what's the state of mono's winforms support nowadays, used to work decently last I tried as long as you the app wasn't using weird widgets and all new .net features
[23:46] <Laney> not pretty, but works quite well ime
[23:47] <GrueMaster> Oops.  Login screens all show 11.10 for our Alpha 1 image candidate.  Not that I am advocating a respin or anything.
[23:48] <stgraber> GrueMaster: not Edubuntu ;) I fixed that one on Sunday (it's a .png in the lightdm greeter theme)
[23:49] <stgraber> though I didn't think Ubuntu was still showing 11.10 or I'd have fixed it or at least poked Robert about it
[23:49] <GrueMaster> Well, it is on armel desktop.
[23:49] <infinity> I assume we're not abnormal there.
[23:49] <GrueMaster> Don't know about the x86 world.
[23:49] <infinity> Unless we have an old version of the theme.
[23:50] <stgraber>  /usr/share/unity-greeter/logo.png also says 11.10 on my laptop, so definitely not arm specific
[23:53] <skaet> hmm,  sounds release notable, but should be fixed and picked up if we respin.
[23:54] <Laney> is there a "things to change at new release opening" checklist?
[23:56] <skaet> Laney,  https://wiki.ubuntu.com/NewReleaseCycleProcess - probably a good thing to add in the "First weeks" section.
[23:56] <stgraber> doh, skaet was faster :) took me a while to dig that wiki page, should bookmark it
[23:56] <Laney> yep
[23:57] <Laney> i tried to google it but failed
[23:57] <skaet> :)
[23:57] <stgraber> yeah, both google and wiki search fail usually :) so I went to the releaseteam wiki page and looked from there
[23:58]  * skaet is glad it gets some use.  ;)


[02:29] <terlmann> ☞ ⨀⨀ ☜ BOOBIES!
[02:29] <terlmann> you havnt changed the topic in 4 months!
[02:29] <DanaG> -þ
[02:29] <DanaG> =þ
[02:29] <terlmann> how did you like the release?
[02:29] <terlmann> :-P
[02:30] <DanaG> Actually, I'm going to have dinner soon.
[12:00] <thorwil> nand: morning! the ascii art captcha is nice and easy. for me, at least :)
[12:05] <nand> thorwil: hehe nice!
[12:05] <nand> A few minor remaining bugs, and brainstorm should be back to normal :)
[19:13] <nxvl> hi
[19:13] <nxvl> does anyone knows where can i get the server team logo?
[19:20] <troy_s> nxvl: link?
[19:26] <nxvl> troy_s: that's what i want
[19:26] <nxvl> :D
[19:36] <troy_s> nxvl: What is the link to the logo that you are talking about (not the logo itself, but an image thereof)
[19:38] <nxvl> oh ok
[19:38] <nxvl> https://launchpadlibrarian.net/11124085/server.png
[19:47] <troy_s> nxvl: I hope you are kidding
[19:48] <troy_s> nxvl: You are looking for the SVG of a blob?
[19:48] <troy_s> nxvl: I sincerely doubt an SVG exists for that... it is probably pix muddled.  Which would loosely translate into 'you already have the source'.
[19:49] <troy_s> nxvl: There _may_ be an SVG, but to be honest, the Ubuntu folks aren't that great at making sure that SVG sources exist for much of the work.  Even the 'source' packages of some artwork don't have the sources.
[19:50] <nxvl> heh
[19:50] <nxvl> no, i have seen a bigger image of it
[19:50] <nxvl> but i can't find it
[19:51] <troy_s> nxvl: Hrm... you certain?
[19:51] <troy_s> nxvl: If you can find a bigger one it would help tracking it down.
[19:51] <nxvl> yup


[01:06] <cesar_bo> Sorry, the Session: "Encouraging women to participate in Ubuntu", would be tomorrow, I don't find the event on the schedule on the wiki ...
[01:12] <cesar_bo> where can I find information about the session of tomorrow?
[16:43] <huats> there :)
[16:44] <persia> heh
[16:44] <persia> The idea of attending 1/3 meetings was about a demonstration of commitment.  I have no strong feelings about it.
[16:45] <huats> Oh
[16:45] <huats> I think it is necessary to show the commitment...
[16:45] <huats> but maybe 1/3 is a bit to hard to acheive
[16:45] <huats> especially with the rotation of timezone
[16:45] <huats> ...
[16:46] <huats> may be a good idea could be, but I am sure many mentors wont agree, to let the mentor handle this commitment dea
[16:46] <huats> idea (I mean)
[16:47] <norsetto> who is pleia2, james_w ?
[16:47] <huats> why not have a "regular" meeting beetween a mentor and his mentees...
[16:47] <huats> so the mentee can show his progress...
[16:47] <huats> or at least his activities
[16:47] <huats> or just an email from the mentee to the mentor, to keep him imformed
[16:48] <huats> of the work in progress
[16:49] <persia> huats: Could be: I was thinking of education as much as mentoring.
[16:49] <norsetto> what would be different from now? I mean, do we need to say to the mentor to keep track of his mentee activities?
[16:49] <huats> norsetto: we should not
[16:49] <huats> but you cannot impose someone to attend regular meetings...
[16:49] <huats> the mentee can have his commitment when he can...
[16:49] <huats> that is my main pb...
[16:49] <norsetto> why not? thats what you normally do in schools, isn't?
[16:50] <huats> norsetto: sure
[16:50] <huats> but may be just a regular report might do it..
[16:50] <norsetto> I mean, when you attend your fine arts lesson, you know there are these lessons, at a certain time, why would it be different here
[16:50] <huats> norsetto: i clearly see you point...
[16:51] <huats> and I agree that this proof of commitment is a necessity
[16:52] <huats> I am not sure, that attending a meeting is a good prrof
[16:52] <norsetto> the proposal is to integrate the two activities more closely, in a way school and mentoring will not be two separate activities anymore
[16:52] <huats> I understand
[16:52] <huats> and it is great
[16:53] <norsetto> we will not require to attend all lessons, but we have to guarantee a minimum attendance, at least to show that you are serious and willing to take commitments
[16:53] <norsetto> to me, having mentees available to act as "teachers" for these lessons, is a very good plus
[16:54] <huats> but I would rather a report from a mentee that tells me :"I could not attend the lesson, but I use it in my work in progress for the last week" rather than someone who shows up idling... because he uses sccreen...
[16:54] <huats> if putput that "small" reaction
[16:54] <huats> aside, I strongly agree with the idea...
[16:55] <huats> and allowing mentees to act as teachers is great too...
[16:55] <norsetto> but by making it free we will end it up in weaking the bond
[16:57] <norsetto> you know, people just say, oh well, I can't make, I have to walk the dog, and next time will be grandma sick and so on
[16:57] <huats> norsetto: I agree
[16:58] <norsetto> what do you think of the time limit for mentoring totally new contributors?
[16:58] <huats> my idea would be : ask mentee to send regular reports of the work in progress, showing their usage of the last classrooms...
[16:58] <huats> this is my idea for showing the commitment, that is all :)
[16:59] <norsetto> I have to think about it, I'm not thrilled to add more and more bureaucracy
[16:59] <huats> norsetto: i understand
[17:00] <persia> From my limited experience as a mentor (one mentee now almost u-u-c), I'll say that more reports aren't interesting: it's mostly about interaction with the group.
[17:00] <huats> it was just a rought idea
[17:00] <huats> persia: I totally agree
[17:01] <huats> but if we do the 1/3 stuff, we have some problems : when to have meetings
[17:01] <huats> let's start with the timezone rotation
[17:02] <huats> so I can only attend 2//3 of the lessons (related to the timezone pb) ... at the maximum...
[17:02] <huats> then we should have a rotation between, weekend and work days...
[17:03] <huats> so we split again in 2
[17:03] <huats> so I can only attend 1/3 of the lessons
[17:03] <norsetto> in the proposal we say "those not in regularattendance (at least 1/3 sessions) may no longer be eligible forMentoring
[17:03] <persia> Which was the reason for the initial 1/3 sessions :)
[17:04] <huats> so I cannot miss even 1 lesson that I cannot be part of the mentoring... I think it is too strict
[17:05] <norsetto> first of all, its may, not shall, second, we talk about mentoring, if you can't make a committment, we should not be obliged to waste resources for nothing
[17:05] <huats> norsetto: come on... we are talking about missing 1 lesson let's say out of 10....
[17:06] <norsetto> of course if one loses a lesson, will be ok, the spirit is that a certain level of commitment must be given
[17:06] <huats> norsetto: but I strongly agree....
[17:06] <huats> i just say that may be, we can be a little more comprehensive...
[17:07] <norsetto> we will, but not upfront
[17:07] <huats> ok
[17:08] <huats> regarding the limited time, once again, I fear that 3 monthes can be a little short for new comers...
[17:08] <norsetto> I'm a bit confused now, wasn't james_w looking at the school?
[17:09] <huats> if I remember correctly, to become a member it is needed to be active for at least 2 monthes...
[17:09] <norsetto> thats good, I thougth it was too long :-)
[17:10] <huats> on the other side, it is enought time...
[17:10] <huats> sure
[17:10] <huats> I agree too :)
[17:10] <norsetto> again, this falls into the committment basket
[17:10] <huats> 3 monthes is great
[17:11] <norsetto> I don't know, I feel as if it is too long actually, depends very much on the contributor and his level of committment
[17:12] <norsetto> you see, what I want to avoid is having mentors frozen for long time, for contributors which are not particularly (if at all) active and on the other side have willing contributors which have to wait because we have no mentors
[17:13] <persia> I think it's a good timeframe for the mentoring.  If someone needs longer, they may do well with team help, or switching mentors.
[17:13] <norsetto> huats: by the way, before I forget, do you think you can take care of jadi?
[17:14] <huats> norsetto: sure
[17:14] <huats> I'll be happy to
[17:14] <huats> !
[17:14] <huats> but you know I am not even a contributor yet ...
[17:15] <norsetto> what I have seen so far, is that willing and committed contributors take a month or less to be productive, while if they take longer, is certainly longer than 3 months
[17:15] <huats> (well I have to admit that I am not really sure what would be better for me if I apply)
[17:15] <norsetto> huats: I mean to couple him with a mentor :-)
[17:15] <huats> norsetto: oh :)
[17:16] <huats> i think you were refering to this proposal already :)
[17:16] <norsetto> huats: you can help him if you are willing, that would be a great idea
[17:16] <huats> norsetto:  no pb I'll find a match :)
[17:16] <norsetto> huats: it will help you too to see things in a different perspective
[17:16] <huats> norsetto: definitly...
[17:17] <norsetto> huats: as far as I'm concerned, I'll be happy if you introduce him to the basics
[17:17] <huats> norsetto: I can do that sure...
[17:17] <huats> (I just need to find out what are the basics)
[17:17] <huats> ;)
[17:17] <huats> but I will help him...
[17:17] <norsetto> huats: well, I can help you to help him ;-)
[17:18] <huats> norsetto: anyhow you know that I would bother you if I have some pbs ;)
[17:18] <norsetto> huats: alas !
[21:14] <Drk_Guy> Hi all


[01:21] <CyberKnet> are there any known issues with lirc upgrading from natty to oneiric?
[01:22] <CyberKnet> my remote doesn't work after I allowed ubuntu to upgrade to oneiric
[01:22] <CyberKnet> mythfrontend logs say it's using /dev/lircd and the appropriate configuration file
[01:27] <CyberKnet> irw shows keypresses
[01:28] <CyberKnet> but mythfrontend isn't using them
[01:32] <CyberKnet> did the progid change for myth from mythtv ??
[01:39] <CyberKnet> vlc also isn't working - but honestly I never tried it before.
[01:48] <CyberKnet> ugh. and I can't get lircd to accept a -L or --logfile parameter
[01:49] <CyberKnet> man page shows it exists... but it sure doesn't work.
[05:30] <Success> hello
[05:32] <Success> So i thought i installed mythbuntu-desktop right, i left, came back, asks some questions, seems to be done, not really sure, notifications went away, but so did unity so i did alt f1 to see terminal ran unity, gave me failish bar at the top cant see open windows or anything assume its done and restart to try to go in to mythbuntu, i select option but instead of signing in it just flashes and goes no where, so in effort to
[05:32] <Success> use my computer i just go to ubuntu and here i am, so how do i get mythbuntu to work
[05:42] <[R]> this isn't #mythbuntu
[05:43] <Success> well how get just mythtv then and mythbuntu points here
[05:45] <[R]> oh wait
[05:45] <[R]> it tis
[05:45] <[R]> lol
[05:45] <[R]> installing mythbuntu-desktop probably makes it unhappy
[05:46] <Success> http://pastebin.com/HN5SQp4H thats errpr
[05:46] <Zinn> [pastebin.com] -Title-: An unhandlable error occured -Message-: There seems to be a pro - Pastebin.com
[05:47] <Success> makes what unhappy
[05:47] <[R]> wait, did you install mythbuntu on an existing install, or did you use the mythbuntu cd?
[05:47] <Success> on existing install...
[05:47] <[R]> yeah, you probably made it unhappy
[05:47] <Success> imonnormal gnome3unity ubuntu
[05:48] <Success> how not make it unhappy
[05:48] <[R]> why would you install mythbuntu-desktop on an existing install to begin with?
[05:48] <Success> because i like gnome3
[05:48] <[R]> ok... and?
[05:49] <[R]> mythbuntu-desktop is gonna install xfce
[05:49] <Success> dude just how make it work
[05:49] <[R]> i dunno, you probably broke it
[05:50] <Success> wow thanks
[05:50] <Success> MythTV backend setup isnt working, thts the message i gave you
[05:51] <[R]> what?
[05:51] <Success> MythTV Backend Setup on ubuntu isnt working
[05:51] <[R]> huh?
[05:52] <Success> wow
[05:52] <[R]> first you say you cant log in, then you paste some random python error, then you say setup isnt working
[05:52] <[R]> make up your mind
[05:55] <Success> I am on ubuntu. I tried to install mythbuntu-desktop. Seemed to install, (my very first post after the hey) that didn't work, shows up on sessions, but can't login. Second I tried to install the backend setup, that didnt work, thats the random python error i showed you
[05:55] <[R]> one little snippet of a python error from "installing the backend setup" means nothing
[05:57] <Success> make something work
[06:03] <Success> oh there we go i started doing something lamp and it appeared to continue install of myth
[08:58] <superm1> mrand, interesting, i didn't realize that do-release-upgrade doesn't detect that it needs --mode=desktop internally
[08:58] <superm1> if that's the root cause to all these problems, we should get that resolved
[08:58] <superm1> now if this is actually just a bunch of people who manually removed mythbuntu-desktop, that's another story
[11:02] <qwebirc47642> Does any one have diskless working with 11.10? I have been using it successfully for several years, but with 11.10 am having problems with nbd.  [ 5.073687] nbd0: Wrong magic (0x25609513)
[11:40] <patdk-lap> I gave up on diskless in 10.04
[11:40] <patdk-lap> and have switched to iscsi diskless
[11:43] <qwebirc47642> any particular reason?  Do you have any instructions you followed to get iscsi working?
[11:44] <patdk-lap> not really, pretty simple
[11:44] <patdk-lap> insert cd, select iscsi disk, install
[11:44] <qwebirc47642> do you have a separate image per front end?
[11:44] <patdk-lap> yep
[11:45] <qwebirc47642> bummer, I have 4 front ends.  Love the way diskless overlays a master image with a unionfs of local changes.  Only one image to upgrade/keep in sync
[11:45] <patdk-lap> I manage a few hundred ubuntu servers
[11:45] <patdk-lap> so management of 4 frontends is nothing
[11:54] <qwebirc47642> any thoughts on the nbd magic number error.  nbd just seems broken in 11.10.  I can't even get nbd-client to mount on the localhost
[13:28] <mrand> superm1: *shrug* I don't know if a missing -m desktop was the cause or not.