[00:12] <Gasher^> Hi everyone. Where can I download Ubuntu Personal image, as opposed to the one with Unity 7?
[01:29] <goddard> will i be prevented from upgrading to 16.04 if i am running a custom kernel?
[01:30] <goddard> should i uninstall the nvidia driver from the website
[01:52] <Daekdroom> goddard, no, but the kernel - might - not work with 16.04. If it doesn't boot, try the default 16.04 kernel.
[01:52] <Daekdroom> As for the nvidia driver, I'd recommend it.
[01:52] <Daekdroom> (uninstalling)
[02:21] <goddard> Daekdroom: ok ill give it a shot
[14:47] <z4sk4> hi somebody have installed kubuntu 16.04?
[14:48] <z4sk4> imposiible install for me in virtualbox, i open a bug, but  still cant install it...
[14:48] <z4sk4> i opened 2 weeks ago
[14:49] <z4sk4> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1535323
[15:01] <lordievader> z4sk4: That is a known bug, as a workaround you could use the net-installer or upgrade from wily.
[15:02] <z4sk4> lordievader: thanks, with net installer work then? what it means wily?
[15:03] <lordievader> z4sk4: Wily is 15.10 ;)
[15:04] <z4sk4> lordievader: oh! ok ok, with a dist upgrade on 15.10 i can get 14.04?
[15:04] <z4sk4> cool
[15:04] <z4sk4> 16.04*
[15:04] <lordievader> Yes, with a 'sudo do-release-upgrade -d' on Wily you upgrade to Xenial (16.04).
[16:12] <lotuspsychje> !info linux-image-generic xenial
[23:03] <ChibaPet> !info grub
[23:03] <ChibaPet> !info grub2
[23:03] <ChibaPet> \o/


[07:06] <AfC> Hm. Found a (minor) bug with the lp:distribution/codename/package syntax
[07:06] <AfC> Where do I report that?
[15:45]  * thumper found a bug in bzrlib in precise
[15:45] <thumper> must get around to filing a bug for it
[15:46] <thumper> hi jelmer
[15:46] <thumper> are you home?
[15:46]  * jelmer waves to thumper
[15:46] <jelmer> no, still in Budapest.. just getting a coffee after spending the day sightseeing
[15:47] <jelmer> thumper: what about you? somewhere in Asia by now?
[15:47] <wgz> what did you see jelmer?
[15:48] <thumper> jelmer: no, vienna
[15:48] <jelmer> thumper: that's the wrong way, isn't it?
[15:48] <thumper> jelmer: there is an engineering manager meeting here for a few days
[15:49] <jelmer> wgz: jtv and I went to the museum about the Nazi/Soviet occupations, and I strolled around the river for a couple of hours
[15:49] <jelmer> thumper: ah!
[15:50] <wgz> neat.
[15:50] <thumper> yay precice, battery showing 4:49 to go
[15:50] <jelmer> yeah, it's a *really* significant improvement here too
[15:50] <thumper> :-| dropped to 4:15 after typing
[15:51] <jelmer> wgz: you made it to Norwich safely then?
[15:51] <wgz> what precisely is your precise bzrlib issue thumper?
[15:52] <thumper> if you start a python prompt from within a bzr branch, try
[15:52] <wgz> jelmer: yup, though it was a bit of a race in schiphol and I had to jump the security queue a bit
[15:52] <jelmer> I think that's spelled presaisy
[15:52] <thumper> from bzrlib.workingtree import WorkingTree
[15:52] <thumper> WorkingTree.open('.')
[15:52] <thumper> it'll fail
[15:52] <jelmer> thumper: that's fixed in bzr.dev
[15:52] <thumper> however if you import bzrlib.branch first, it works
[15:53] <thumper> jelmer: ok
[15:53] <wgz> and will be released in 2.5b5... probably in the coming week
[15:53] <jelmer> thumper: the problem is that we reduced our imports so much that the working tree module no longer imports bzrlib.bzrdir, which registers a couple of things - including the bzr native formats
[15:53] <thumper> kk
[15:53] <jelmer> thumper: so newer versions are explicitly importing from bzrlib.bzrdir in bzrlib.workingtree
[15:53] <wgz> we do have some test coverage holes for bzrlib being imported in non-bzr-script ways
[15:54] <jelmer> wgz: yeah :(
[15:56] <wgz> ideally people's bzrlib-using tools test suites would help
[20:31] <PCJockey> I'm new to Bazaar, so please excuse me if this answer is easily found, but I've been looking in the docs and new user info from the website. So, now I'm here to ask the experts for direction to the answer to my question. Thank-you in advance for your help!!
[20:31] <PCJockey> What is the design of a Bazaar repository? My primary interest is in knowing if it offers historical cryptographic integrity like a git repository does.
[21:07] <jelmer> PCJockey: hi
[21:08] <PCJockey> jelmer: Hello!! I hope you are well today...:)
[21:08] <jelmer> PCJockey: what do you mean with cryptographic integrity exactly? Git doesn't sign revisions in any way, though it can sign tags if you want to.
[21:10] <PCJockey> jelmer: I'm referring to the idea that because of each commit being named with a hash of the contents, you can go back through full history to know bit for bit it's accurate. I.E. nobody has altered the history or no media failures have altered the repo.
[21:13] <jelmer> PCJockey: bzr does have various mechanisms for verifying revisions contents, but it uses arbitrary unique strings to refer to revisions
[21:14] <jelmer> we do store the hash as part of the revision, it's just not use to reference that revision
[21:14] <PCJockey> jelmer: My point isn't to compare to git. Just that I know git has the feature. I also don't care what the commits are named. All I really want to know is how bazaar confirms integrity.
[21:15] <jelmer> PCJockey: it stores the SHA1 of the contents and verifies that, just like git does
[21:16] <jelmer> (currently it's SHA1, but we might swap that for something else in the future if more attacks against SHA1 arise)
[21:17] <PCJockey> jelmer: Got it. I guess if I had just installed it the answer would have been obvioius. I appreciate your help!!
[21:19] <jelmer> np
[21:21] <PCJockey> I look forward to trying Bazaar out now. It looks like the community has some very cool things going on!
[21:21] <fullermd> The two aren't exactly comparable.  bzr's SHA1 doesn't help much against [competent] attacks.
[21:23] <PCJockey> fullermd: Oh, now that is what I wanted to know about...and I'm sorry to hear it.
[21:24] <PCJockey> fullermd: So, there is no assurance of repository integrity?
[21:32] <fullermd> The SHA1 in the revs gives excellent protection against accidental damage.  For intentional, you have to look to other mechanisms.  And that comes down to the eternal "what's your threat model".
[21:34] <PCJockey> fullermd: Admittedly I'm not too concerned about malicous attack, but it's a nice and seemingly free thing to have in the modern era, but yes the more likely threat is non-malicious.
[21:35] <fullermd> Security is never free   :)
[21:35] <fullermd> The SHA1 in git doesn't provide any automatic protection against malicity (that's a word.  I just decided) either, after all.  Just that the way it's used compared to bzr gives it potential in that way.
[21:36] <PCJockey> fullermd: Even so, I'm not sure it's worth giving up the feature...comes down to an argument of how important it is to me. I guess I just want it all...:)
[21:37] <PCJockey> fullermd: Do you know why the bzr team made the decision not to include the capacity?
[21:38] <fullermd> Because using the hash as revision identifier has various drawbacks.
[21:41] <PCJockey> fullermd: I don't mean using it as an identifier, but implementing an alternate way of integrity assurance.
[21:41] <fullermd> Right, but using it as an identifier is *WHY* it has potential to be useful that way in git, but not in bzr.
[21:41] <PCJockey> BTW, I agree using a hash as an identifier is pretty UGLY!!
[21:42] <fullermd> A hash doesn't tell you anything by itself, after all.  I could send you a bzr tarball and tell you the SHA1, and that doesn't give you any assurance that it's not actually a virus.
[21:42] <fullermd> All it would tell you is that you got the file *I* wanted you to have.  To know you had the one the bzr team released, you'd have to know what that has was _supposed_ to be.
[21:42] <fullermd> If I go in and maliciously change the content of some rev in a bzr history, then the SHA1 in the rev will no longer match and it'll scream bloody murder.
[21:43] <fullermd> That just means I have to change the SHA1 too.  Then everything will look just fine.
[21:43] <fullermd> I can do the same thing in git too.  The difference is, that since the SHA1 is the identifier, I'll be changing the identifier of the rev too, which means you're more likely to notice that it happened.
[21:44] <fullermd> So in git, you have that assurance, assuming you know what the revid was supposed to be.
[21:44] <fullermd> So if Linus tells you "hey, run rev 4bbc82ad2", you have [for practically, purposes, sufficiently] total assurance that you have what he meant.
[21:44] <PCJockey> fullermd: I realize it's just an arbitrary code, but why can't you...I guess I'm missing something. Too many distractions at the house right now to get my thoughts out clearly...:(
[21:45] <fullermd> Whereas if jelmer tells you to run revid<EMAIL_ADDRESS>of bzr, that by itself doesn't prove that you have the same rev he meant.
[21:45] <fullermd> Since the identifier itself isn't the same thing as the integrity check.
[21:46] <fullermd> bzr's mechanism to do the same is PGP signing of revs, which conceptually gives you greater assurance.  A number of practical issues present themselves with a little thought.
[21:46] <PCJockey> fullermd: I guess my point is that it seems there should be a way to solve the issue w/o using a hash as a commit id.
[21:46] <fullermd> Well, if I tell you what the hash is supposed to be too, you get the same.
[21:47] <fullermd> It's just that now, I have to give you TWO pieces of info (the revid and the hash).
[21:47] <fullermd> With the hash being the revid, you get both automatically any time things are referred to.
[21:51] <PCJockey> fullermd: I like everything I've read/seen about bzr up to now...but this seems like an issue to me. Maybe I'm worried about an improbability, but it does seem that over time data errors are likely...the issue is whether or not I'm giving it too much attention perhaps.
[21:51] <fullermd> Well, the way to protect against malice is PGP signing.  That adds process burden.
[21:57] <PCJockey> fullermd: Yes, burden with benefit though...:)
[21:59] <fullermd> PGP signatures have the advantage that they're a lot more self-manifest than a hash.
[22:00] <fullermd> With a hash, you have to know what it's supposed to be for any rev you care about.  With a signature, you just have to know what key you're expecting, then any rev with that key can be checked.
[22:01] <fullermd> The principal burden with PGP is tracking which keys are expected.  I mean, I can make a key with your email on it and use it to sign things, so you'd have to somehow know which keys were really you authorizing stuff.
[22:01] <fullermd> Related is that you have to know it's supposed to be there.
[22:02] <fullermd> e.g., I make malicious changes to the rev, and the PGP verification will fail.  I can't make a new signature with your key that'll pass.
[22:02] <fullermd> But I CAN just go ahead and throw away the signature wholesale.  And then "verification" will pass just fine, since a rev with no signature can't fail a signature check.
[22:02] <PCJockey> fullermd: Yep. As, you said in the beginning...nothing is free...:)
[22:03] <fullermd> You'd have to know there was supposed to be one (either specifically, or by setting a hard requirement that EVERY rev be signed) to know something was up.
[22:04] <PCJockey> fullermd: Bzr is definitely has my attention now. The question is what will I do with it. How long have you been using it? Is there anything you'd like to see changed?
[22:04] <fullermd> I've been using it for...  uh...  a long time.  Not too long after it first became publically available.
[22:05] <PCJockey> fullermd: I really appreciate you taking the time to talk this out with me!
[22:05] <fullermd> Jeez, more'n 6 years now.  Wow.  Hard to believe I've been largely CVS-free that long.  I can still feel the scars...
[22:06] <fullermd> There are all sorts of things I'd like changed/fixed/etc.  With me, that's pretty much a constant with any software   ;>
[22:06] <fullermd> But I chose it because I liked it better than the other VCS choices at the time.  Still using it because that decision still holds.
[22:10] <PCJockey> fullermd: I must admit I'm impressed by my 2nd look. I had looked in the past pre v2, but decided it wasn't mature enough to garner a further look. This time however, we're talking about the only thing I'm struggling with...and as you have pointed out, there is a work around if it matters that much to me...I just need to figure out what to do with it from here. I should probably install and then decide on experience versus theory.
[22:12] <fullermd> I've scrawled up some docs that may help you with the gestalt (not in security or internals so much, but what pieces you use and how they fit together).
[22:13] <fullermd> Not a substitute for the sort of intro tutorials that are out there, but I think they're a useful second step ("OK, I can follow this cookbook to do basic interactions, but I don't really understand just what the implications of all the things I do are")
 is intended to be a useful intro to the Repo/Branch/WT triumvirate, which underlies how everything in bzr works.
[22:14] <PCJockey> Great!   It's happened before.


[01:12] <asac> yeah ... but we have a branch to maybe enhance packaging ... or adapt or something
[01:12] <Ubulette> we may touch debian/whatever if needed, but not orig.tgz
[01:12] <asac> Ubulette: who keeps track of that?
[01:12] <Ubulette> that's not my idea of nspr.ubuntu.trunk
[01:13] <asac> so what is your idea?
[01:13] <Ubulette> anyone aware of the bump requirement
[01:13] <Ubulette> and willing to react
[01:13] <asac> so i want to build a package for trunk now ... how can i do that without knowing any details?
[01:14] <asac> i just want to go ... get a branch ... produce an orig with the info included there ... and build it.
[01:14] <asac> i mean i want to build ffox-trunk today ;)
[01:15] <Ubulette> the two -gp are enough, before i've kept them up to date
[01:16] <Ubulette> and of course, ff-trunk should bump its builddeps
[01:16] <asac> against what?
[01:16] <Ubulette> "Upgrade Mozilla trunk to NSPR_HEAD_20070820"
[01:16] <asac> and then ? how do i get the right nspr for that?
[01:16] <asac> the right bzr branch ... commit
[01:17] <Ubulette> so nspr >= cvs20070820
[01:17] <gnomefreak> thats for trunk?
[01:17] <gnomefreak> or gp
[01:17] <asac> i have no idea
[01:17] <gnomefreak> im looking for trunk tarball for nss nspr
[01:17] <gnomefreak> like right this sec
[01:17] <gnomefreak> :)
[01:17] <Ubulette> gp a7 is older so it can still accomodate with previous nspr
[01:17] <Ubulette> gp a8 will not
[01:18] <Ubulette> as a8 will be more than what trunk is today
[01:18] <Ubulette> well, more or less
[01:18] <asac> so you want to maintain the trunk nss in the nss.grapnaradiso branch?
[01:18] <gnomefreak> nspr-trunk_4.7.0~cvs20070820.orig.tar.gz  and nss-trunk_3.12.0~cvs20070825.orig.tar.gz  for ff-trunk?
[01:19] <asac> Ubulette: what i read now is that you really want to maintain the nss trunk branch in the granparadiso one
[01:19] <asac> is that correct?
[01:19] <Ubulette> no
[01:19] <gnomefreak> brb
[01:20] <asac> he? but that is what you are saying ... isn't  it? e.g. when ffox-trunk needs a new nss, you will update paradiso branch ... as both trun + paradiso have to use nss.paradiso package
[01:20] <asac> otherwise i still don't get what you want
[01:20] <Ubulette> i maintain nss trunk (ie HEAD) so I know what is needed when moz guys say "hey, you now need cvs xyz", because it will be a date older than my freshest build
[01:21] <asac> yeah lets call it HEAD please
[01:21] <asac> Ubulette: ok i understand that
[01:21] <asac> Ubulette: now what happens if they need that?
[01:22] <asac> e.g. when ffox-trunk says we need nss from yesterday
[01:22] <asac> while ffox-gp still officially needs nss from 4 weeks ago
[01:22] <Ubulette> merge is an option, pull too
[01:22] <asac> ok ... lets stick there
[01:22] <asac> merge where?
[01:22] <asac> on which branch?
[01:23] <asac> (pull in case that branch has not been diverged)
[01:23] <Ubulette> gp merge head or head rev n-1
[01:23] <asac> i can't parse that
[01:23] <asac> what is gp? nss.gp ?
[01:23] <asac> ok ... now gp branch is nss for ffox-trunk
[01:24] <Ubulette> from nss.gp, bzr merge nss.head -rev x
[01:24] <Ubulette> or latest
[01:24] <asac> right?
[01:24] <asac> e.g. nss.gp branch is for ffox.trunk
[01:25] <asac> so nss.gp tracks nss for ffox.trunk ... which is all what i said above
[01:26] <gnomefreak> atm his branches dont reflect that
[01:26] <asac> do you really have issues to just name that branch nss.trunk ... and the dev branch nss.dev or .HEAD ... and then merge down as needed?
[01:26] <asac> Ubulette: ?
[01:27] <asac> imo it would just be one tiny step more ... and would make things much cleaner
[01:27] <asac> e.g. it would just be cd nss.trunk; bzr merge ../nss.dev ... when trunk needs new nss
[01:27] <asac> and cd nss.gp; bzr merge ../nss.trunk ... as soon as gp needs new nss
[01:28] <Ubulette> gp<-trunk<-head/dev ?
[01:28] <asac> yeah ... all main debian packaging development happens on dev
[01:28] <asac> we merge down as needed
[01:29] <asac> and if we need a tiny chnage on gp we can do it there ... and maybe even merge that up to turnk or something
[01:29] <asac> but usually the direction should be just down
[01:29] <asac> and since the probably don't bump nss/nspr tags that frequently, the .trunk and the .gp branches should be quite stable
[01:30] <Ubulette> i don't get it. what will be in the repo ? ie, i've installed both ff-gp and ff-trunk
[01:30] <asac> without much noise
[01:30] <asac> Ubulette: well ... first ... if you are on gutsy
[01:30] <Ubulette> i am
[01:30] <asac> (or whatever is current dev version)
[01:30] <asac> then ff-gp is in official repo
[01:30] <asac> and ff-trunk in ppa
[01:31] <asac> further upon request i would like to keep our gp backport we used to provide
[01:31] <asac> in old mt archive.
[01:31] <asac> for feisty
[01:31] <Ubulette> so i end up with gp running with nss-trunk, right ?
[01:31] <asac> in that case probably yes
[01:31] <asac> but if you just install gp you just have gp nss
[01:32] <asac> binary backward compatibility should be guaranteed ... its just source forward compatibility is known to break
[01:33] <asac> Ubulette: so maybe you understand better ... when gp.nss is in official archive ... i want a dedicated branch to track that .... so i can always make changes for the released version
[01:33] <asac> wihtout the need to do a mini-branch fork from the past
[01:34] <Ubulette> ok
[01:34] <asac> imo thats reasonable?
[01:35] <asac> i just fear that at some point we need to fix something in gp ... and gp has already moved away ... not a big issue, and if you really don't want that branch we can go that way
[01:36] <Ubulette> what if dev is far ahead trunk and suddenly, moz guys decide for a tag in the middle ?
[01:36] <asac> Ubulette: well ... by admitting that we will merge down ... i implicitly say that its ok for me to track down the commit we need
[01:36] <asac> dev should have daily checkins or something i guess
[01:37] <asac> or at least one checkin for every day where cvs has a checkin
[01:37] <asac> can we do that with your bot?
[01:37] <asac> so we can verify that build works ... and maybe even run some tests (later)
[01:37] <Ubulette> we svn/git/hg/bzr yes, cvs is trickier
[01:38] <Ubulette> -we+with
[01:38] <asac> Ubulette: you can use bonsai
[01:38] <Ubulette> i do
[01:38] <Ubulette> but it's seamonkey
[01:38] <asac> Ubulette: i have perl scripts i used to work on the bonsai checkins
[01:38] <asac> it allows you to extract single commits pretty easily
[01:38] <asac> without all this cvsps crap
[01:38] <asac> e.g. extract atomic commits with comment time et al
[01:38] <Ubulette> i'd like a kind of commit id for nss, another for nspr, etc
[01:39] <asac> well thats simple the perl scripts alread yhave all those fields
[01:39] <asac> you can just concatenate something like project.datetime
[01:39] <Ubulette> nss is 4 trees, not 1
[01:40] <asac> why is that a problem?
[01:40] <asac> (you can list multiple directories) ... in bonsai
[01:40] <asac> http://bonsai.mozilla.org/cvsqueryform.cgi
[01:40] <asac> the perl scripts i have just need a bonsai url that have the commits you want to be extracted
[01:41] <asac> first you get lightweight summaries ... which you can then say .. produce_patch
[01:41] <asac> or something like that
[01:41] <asac> maybe i should even try to sync to our debian git tree that way ;)
[01:42] <asac> but that is more tricky, because its diferent branches for different directories ... so real work involved ;)
[01:43] <Ubulette> i've already hacked around bonsai too. look at the rss dir in my web site ;)
[01:44] <asac> then when you have what you need ...fine ... if you want those scripts, ... i hope i can resurrect them somewhere
[01:44] <asac> they apparently are not in my p.d.o account anymore
[01:44] <asac> hmm
[01:49] <asac> well that really sucks soo much
[01:49] <Ubulette> asac, done. my bot will only fetch/build when there's a new commit since the last build
[01:49] <asac> only chance is that they are on my other system
[01:50] <Ubulette> does not matter
[01:50] <asac> oh how i hate me ... see what happens if you clean up ... you remove your 10 fold redundant bits everywhere
[01:50] <Ubulette> ..and you loose everything in the process :p
[01:50] <asac> Ubulette: yes then autocommit ... and refrain from new builds if build fails somehow
[01:50] <asac> so we can fix the last revision ;)
[01:50] <asac> manually ... then bot will resume
[01:51] <Ubulette> no need to autocommit, most of the time, there's no reason to update debian/*
[01:51] <asac> yeah ... apparently yes. i can just hope that its on my old system or mike has it
[01:51] <asac> anyway ... my git history is definitly lost forever
[01:51] <Ubulette> gasp
[01:54] <asac> no its not :)
[01:54] <asac> i found it ... on my laptop
[01:54] <asac> YUHUU
[01:54] <asac> redistributed to multiple places :)
[01:56] <asac> http://people.debian.org/~asac/msectools.1.tar.gz
[01:56] <asac> with a bunch of data garbage :)(
[02:00] <Ubulette> spreading is also my method to backup my stuff
[02:01] <asac> yes ... but i have a bit of a backup thing here ...only problem is that really old stuff is apparently not included :)
[02:01] <asac> and for worst case scenario i have real solution :)
[02:01] <asac> so spreading is important component of my data life :)
[02:03] <Ubulette> i still have everything from back in the late 80s :)
[02:03] <asac> thats luck :) ... i definitly lost my atari games :(
[02:03] <asac> floppy discs just suck
[02:03] <Ubulette> cd too
[02:03] <asac> i mean my own games :/
[02:04] <Ubulette> me too. i only keep my stuff
[02:10] <Ubulette> asac, tell me if you have any idea for my xul/ff3 problem
[02:10] <Ubulette> asac, if you're lazy, you can get my latest builds there: http://www.sofaraway.org/ubuntu/minirepos/xul/
[02:10] <Ubulette> or the apt-line : deb http://www.sofaraway.org/ubuntu/minirepos xul/
[02:11] <Ubulette> bed time. see you.
[03:53] <Jazzva> Hello...
[03:53] <Jazzva> asac: I've finished the plugin hbox -> table transition... though I have two minor visual glitches to fix
[03:54] <Jazzva> BTW, it was a simple change, but first I tried to do it the harder way, that wasn't really working...
[03:55] <Jazzva> And it took me some time until I saw the problem, which was quite obvious...
[03:57] <Jazzva> Anyhow, here' s the screenshot: http://img169.imageshack.us/img169/59/screenshotpluginfinderste2.png
[03:58] <Jazzva> The first glitch is that the missing label for radio causes that little selection square in front of the logo. The second one is that the plugin name label is not correctly vertically aligned... I tried with valign, but nothing :/... Will try to fix it.
[04:37] <Jazzva> asac: Pushed the new revision... I'll fix those glitches in the next one.
[10:08] <asac_> argh
[10:09] <tonyyarusso> asac_: wassamatta?
[11:32] <gnomefreak> has anyone played with system-config-printer in gutsy yet?
[11:44] <asac> gnomefreak: i have no printer :)
[11:44] <asac> too spartanic for me
[11:44] <gnomefreak> lol
[11:44] <asac> i print right in my head ;)
[11:44] <gnomefreak> i do but im scared of SCP
[11:45] <asac> its new, isn't it?
[11:45] <asac> afaik it should really rock now :)
[11:45] <gnomefreak> i cant believe hes blaming the pc instead of updatedb
[11:45] <asac> at least thats the idea
[11:45] <gnomefreak> yeah new
[11:45] <gnomefreak> brb tea
[11:46] <tonyyarusso> asac: what is ubufox?
[11:47] <gnomefreak> gives you settings to cchange in about:config in ff afaik (i have it but never changed settins
[11:47] <tonyyarusso> oh
[11:48] <gnomefreak> if updatedb runs daily and takes alot of mem (with system minimum atleast) its the systems fault that it takes >5minutes to start
[11:48] <asac> tonyyarusso: yes it contains the default pref tweaks we have
[11:48] <gnomefreak> thats gonna piss me off seeing its not mandatory for it to run at all
[11:48] <asac> + its a staging area for new features that need to be cleaned up before we can submit upstream
[11:48] <asac> like the new plugin finder dialog/wizard
[11:48] <tonyyarusso> asac: got it - thanks
[11:49] <asac> tonyyarusso: later today i will move ubuntu default bookmarks there as well
[11:49] <asac> tonyyarusso: why you ask?
[11:49] <asac> ah
[11:49] <tonyyarusso> asac: ^^
[11:49] <asac> ok
[11:49] <asac> tonyyarusso: please don't blog about  it ... i still have to talk with mofo about that
[11:49] <tonyyarusso> asac: noted
[11:49] <asac> the more press-coverage this gets the more difficult my talks will be :)
[11:58] <gnomefreak> asac: using his test cases i still cant reproduce this to save my life. what do we do next, https://bugs.launchpad.net/ubuntu/+source/iceape/+bug/124365  i doubt closing it would satisfy him
[11:58] <ubotu> Launchpad bug 124365 in iceape "Iceape-Browser: Theme setting reverts on restart" [Low,Incomplete]
[11:58] <gnomefreak> brb smoke
[12:05] <gnomefreak> i might have a clue on something
[12:07] <gnomefreak> asac: if you have iceape can you check your chrome.rdf to see if it has info in it
[12:08] <gnomefreak> yeah see mine is empty
[12:08] <gnomefreak> new profile and old profile
[12:10] <gnomefreak> what would cause chrome.rdf to be written to?
[12:10] <gnomefreak> here is his .rdf http://launchpadlibrarian.net/8914245/chrome.rdf
[12:10] <gnomefreak> here is mine file:///home/gnomefreak/.mozilla/Default/wugqljj5.slt/chrome/chrome.rdf
[12:13] <gnomefreak> i attached mine to bug report. but that makes me think maybe somethink he has or is doing is writing to it when it shouldnt
[12:13] <gnomefreak> or its a PPC bug
[12:18] <gnomefreak> tonyyarusso: you have iceape installed by chance?
[12:18] <tonyyarusso> gnomefreak: No.  I have the source, but not installed.
[12:19] <gnomefreak> ok ill tag it and see what happens
[12:22] <gnomefreak> would be odd that its only a PPC issue
[12:25] <gnomefreak> shit
[12:26] <gnomefreak> asac: we might have issue give me a few minutes to check
[12:27] <gnomefreak> i dont think the checkfor updates link is gone
[12:28] <gnomefreak> reinstalling to find out right now
[12:32] <gnomefreak> damnit
[12:35] <gnomefreak> adding "pref" failed to fix update issue
[12:45] <gnomefreak> brb
[12:53] <gnomefreak> ok the "pref" fixed part of the issue. what file holds the menu entries?
[01:01] <gnomefreak> ok now i need to figure out what to add to .desktop file to fix this half of the update issue
[01:04] <gnomefreak> if i ever get my sid chroot up and running i can look in that
[01:08] <gnomefreak> asac: having connection issues?
[01:21] <gnomefreak> ok im gone for a while, ill find the file to fix when i get home [i hope]
[01:52] <asac> gnomefreak: i am now back
[01:52] <asac> online :(
[01:53] <asac> thas really no fun here
[01:54] <asac> pochu always pings me and then he is offline when i want to pong him
[04:15] <asac> _Ubulette: we saw a preference checkin on trunk that switched to use serif/sans fonts instead of times helvetica, right?
[04:15] <asac> you still have that in your backlog?
[04:20] <gnomefreak> asac: im here for a minute but sunbird we fixed the update thing in prefferences but in help> check for updates needs to be removed greyed out from help menu
[04:21] <gnomefreak> !ppa
[04:21] <ubotu> With Launchpad's Personal Package Archives (PPA), you can build and publish binary Ubuntu packages for multiple architectures simply by uploading an Ubuntu source package to Launchpad. See https://help.launchpad.net/PPAQuickStart.
[04:21] <asac> gnomefreak: why? thats for extension updates, isn't it?
[04:21] <gnomefreak> asac: no
[04:22] <gnomefreak> asac: its used just like ff update checker in menu
[04:22] <gnomefreak> let me check to make sure
[04:22] <asac> gnomefreak: what is the setting for:
[04:22] <gnomefreak> i checked this am but i was kind of pissed off atm
[04:22] <asac> app.update.enabled
[04:22] <asac> and for
[04:22] <asac> app.update.auto
[04:22] <asac> if you look in config editor?
[04:23] <asac> both false? with the former being locked?
[04:23] <gnomefreak> both are false
[04:23] <gnomefreak> both locked
[04:24] <asac> interesting ... for firefox only the former is locked for me
[04:24] <asac> can you ack?
[04:24] <asac> but that shouldn't make a difference
[04:25] <asac> what happens if you try to do that?
[04:25] <asac> e.g. check for updates?
[04:25] <gnomefreak> both locked here in ff as well
[04:25] <asac> ok
[04:25] <gnomefreak> says there are none
[04:25] <asac> i am on feisty ;) ... so that might be the diff
[04:26] <asac> hmm
[04:26] <asac> maybe sunbird code is broken for that?
[04:26] <gnomefreak> dont know where to check, i was hoping there was a setting in .desktop or someplace to remove that option
[04:27] <asac> hehe go dream :)
[04:27] <asac> why would .desktop influence mozill apps :)
[04:27] <gnomefreak> my sid is borked atm so i cant see if sid has it disabled
[04:27] <asac> they usually ignore anything that is not their own
[04:28] <gnomefreak> the synaptic.desktop has option to not show in kde menu (but more i think of it its for main menus not app menus
[04:28] <asac> huh?
[04:28] <asac> but thats something completely different
[04:29] <asac> on the one hand its gnome/kde feature ... for us we are completely in land of mozilla here
[04:29] <asac> or where do you see that check fo updates?
[04:29] <gnomefreak> more of a main menu placment than an app menu
[04:30] <gnomefreak> open sunbird click help its right there. foxes is greyed out but for some reason ours isnt
[04:30] <gnomefreak> am i missing something (we used firefox as template for sunbird
[04:30] <gnomefreak> )*
[04:31] <asac> gnomefreak: sorry ... i don't get why its not an app menu ... aren't we talking about the menu in top of the application window? or do you see that somewhere else?
[04:31] <gnomefreak> see the menu check for updates is enable in upstream mozilla products (all of them) so maybe one of our ubuntu patches we dropped have it in it)
[04:31] <gnomefreak> asac: yes that menu
[04:31] <asac> ok ... just to know we are talking about the same
[04:31] <asac> its a mozilla menu
[04:31] <gnomefreak> asac: open sunbird click help
[04:32] <asac> no chance to fix it by other means than mozilla
[04:32] <gnomefreak> or open firefox click help
[04:32] <asac> gnomefreak: iirc we don't have a patch for that
[04:32] <asac> my suspeciion is that sunbird and firefox don't share the same code, but forked the code for that menu entry at some point
[04:32] <gnomefreak> but isnt it always enabled upstream and we fix it in firefox thunderbird ect...
[04:32] <asac> and sunbird now ha a bug that ffox has fixed long ago
[04:32] <asac> gnomefreak: no we just set the settings
[04:32] <gnomefreak> oh
[04:33] <asac> if the update settings are falsed it should be greyed out
[04:33] <asac> so sunbird doesn't honour that
[04:33] <asac> for whatever reason
[04:33] <gnomefreak> so should i file it upstream and attach to our report
[04:33] <asac> upstream?
[04:33] <gnomefreak> mozilla
[04:33] <asac> no ... we first have to be sure
[04:33] <asac> i mean ... this is by 60% likelyhood a bug from us
[04:33] <asac> and 40% a bug from them
[04:34] <gnomefreak> it was there from first build of ours
[04:35] <gnomefreak> frigging debootstrap
[04:35] <gnomefreak> W: Failure while installing base packages.  This will be re-attempted up to five times.
[04:35] <asac> sid has the same issue in iceowlk
[04:35] <asac> i verified
[04:35] <asac> but sid didn't even receive the latest patch for prefs extension yet
[04:35] <asac> so its borked anyway
[04:37] <gnomefreak> only problem with that is iceowl is built from our sunbird
[04:37] <gnomefreak> so its gonna have the same problems without knowning anything more
[04:47] <asac> right
[04:56] <gnomefreak> so what do we do about it? im gonna assume if 1.1.5 is released that will upgrade people but fail since its a ubuntu package not upstream package
[04:56] <gnomefreak> sorry fixing others screw ups atm
[05:06] <gnomefreak> ok trying to build sid chroot using feisty deboostrap now
[05:08] <asac> is holiday in uk today?
[05:08] <asac> ah right
[05:08] <asac> i remember
[05:09] <gnomefreak> yesterday
[05:09] <gnomefreak> thats why ppa wasnt released
[05:10] <asac> gnomefreak: better get a real sid install and tell me how well network-manager works for them
[05:10] <gnomefreak> 1.0.1 is failing as well but atleast it is retring
[05:10] <gnomefreak> seems x11common is failing to install
[05:18] <gnomefreak> asac: you pushed tbird <IP_ADDRESS> to feisty right?
[05:19] <gnomefreak> !info mozilla-thunderbird feisty
[05:19] <ubotu> mozilla-thunderbird: Mozilla Thunderbird standalone mail client. In component main, is optional. Version <IP_ADDRESS>-0ubuntu0.7.04 (feisty), package size 10660 kB, installed size 29752 kB
[05:27] <asac> gnomefreak: all fine with tbird?
[05:28] <asac> gnomefreak: what nm problems do you have?
[05:29] <gnomefreak> ever since latest upload i cant keep a connection
[05:29] <gnomefreak> it happened in PA and here
[05:29] <gnomefreak> notice last few days been the worst
[05:31] <asac> what chip?
[05:31] <asac> wired? wireless?
[05:33] <gnomefreak> wired
[05:34] <gnomefreak> 02:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]  (rev 78)
[05:35] <gnomefreak> neither win pcs disconnect all 3 pcs 2 win and this are all on same router& modem
[05:35] <gnomefreak> it could be freenode but why only me
[05:40] <asac> gnomefreak: well ... od you see actual reconnects?
[05:40] <asac> or just disconnects from freenode?
[05:41] <gnomefreak> just freenode that i can tell but im not refreshing browser all the time
[05:42] <asac> then its not nm
[05:46] <gnomefreak> if i saw it on other pcs i could go with that but i know the card is good and none of the other pcs have connection issues so maybe it is freenode but only me ?
[05:48] <gnomefreak> but some days it happens all the time others it happens once or twice so far today none that i know of
[05:51] <asac> do you see anything interesting in daemon.log while this is happening?
[05:53] <gnomefreak> never looked
[05:54] <gnomefreak> i have 5 of them
[06:00] <gnomefreak> bbl lunch time
[06:02] <gnomefreak> make that 7 daemon.log
[08:10] <Ubulette> hi
[08:13] <asac> hi
[08:17] <Admiral_Chicago> alll peers is awesome
[08:18] <asac> does it work properly?
[08:19] <asac> Ubulette: which branches nss/nspr do i need for xulrunner trunk?
[08:19] <asac> is it .trunk already ... or granparadiso for now?
[08:22] <Ubulette> both are fine. take gp
[08:22] <Ubulette> (if you use my orig for xul)
[08:23] <Ubulette> if you fetch yourself, you need the new nspr
[08:23] <asac> Ubulette: nspr has only gp?
[08:23] <asac> further it fails to build here
[08:23] <asac> because maintainer isn't ubuntu, but changes suggest it
[08:24] <asac>  dpkg-source -b nspr-trunk-4.7.0~cvs20070820
[08:24] <asac> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
[08:24] <Ubulette> ?
[08:25] <asac> hmm so nspr in gp branch is already ahead of gp?
[08:25] <Ubulette> i did that before our last discussion
[08:25] <asac> yeah
[08:26] <Ubulette> i still need to rename accordingly
[08:26] <asac> ok i will push .trunk (or .fortrunk?) ... and uncommit gp by one afterwards
[08:26] <Ubulette> i'll do it
[08:26] <Ubulette> just pull and uncommit once
[08:26] <Ubulette> locally
[08:27] <asac> Ubulette: i will do it ... i have to fix the build ;)
[08:27] <asac> nspr fails here
[08:28] <Ubulette> are you sure it fails on the email (which is yours btw)
[08:28] <Ubulette> it's usually just a warning
[08:28] <asac> yes, i am sure
[08:28] <asac> the maintainer has to be an ubuntu address if you have a ubuntu version
[08:30] <Ubulette> looking at nspr.ubuntu.granparadiso commit 14, it is your email
[08:32] <asac> that sucks
[08:32] <asac> Ubulette: ??
[08:32] <asac> Maintainer:
[08:32] <asac> read error above ... for me its still debian maintainers
[08:32] <asac> i mean it sucks that lp is down
[08:32] <asac> or at least i cannot pull
[08:32] <asac> neither ssh ... sftp ... http
[08:33] <Ubulette> really ?
[08:36] <Ubulette> fta@ix:~ $ mkdir /tmp/gru
[08:36] <Ubulette> fta@ix:~ $ cd !$
[08:36] <Ubulette> cd /tmp/gru
[08:36] <Ubulette> fta@ix:/tmp/gru $ bzr co http://bazaar.launchpad.net/~mozillateam/nspr/nspr.ubuntu.granparadiso
[08:36] <Ubulette> WARNING: the 'deb822' top-level module is *DEPRECATED*, please use 'debian_bundle.deb822'
[08:36] <Ubulette> fta@ix:/tmp/gru $ l
[08:36] <Ubulette> total 4
[08:36] <Ubulette> drwxr-xr-x 4 fta fta 4096 2007-08-28 20:34 nspr.ubuntu.granparadiso/
[08:36] <Ubulette> works fine for me
[08:36] <asac> yeah now its back
[08:36] <asac> :=
[08:47] <asac> ok i pushed nspr branches (overwrite for gp) ...  and fixed nss.gp ... which should be good for xulrunner-trunk i guess
[08:47] <asac> nss.trunk i didn't touch yet
[08:48] <asac> please merge down the last nss.gp commit (e.g. maintainer fix)
[08:48] <asac> though i think you will do automatically ... please merge (not manually redo), because then later merging down from trunk to gp will not have conflict
[08:52] <Ubulette> ok, but i still don't get why it failed for you but not for me
[08:52] <asac> no idea ... how do you build?
[08:53] <Ubulette> dpkg-buildpackage -kB6EE20E8  -rfakeroot
[08:53] <asac> if you build manually (e.g. without debuild dpkg-buildpackage) ... it probably doesn't fail
[08:53] <asac> if you build in feisty ... it won't fail either
[08:53] <Ubulette> gutsy
[08:53] <asac> if you use debian dpkg toolks it won't fail as well
[08:53] <Ubulette> just gutsy
[08:54] <asac> then no idea ... it should be enforced
[08:54] <asac> since gutsy
[08:54] <asac> i build with bzr bd ... but had the same errors before ... maybe its not enforced anymore, but bzr bd has not been updated? no idea
[08:57] <asac> its really strange
[08:57] <asac> maybe its indeed the way i said last
[08:57] <Ubulette> warning, `debian/libnspr4-0d/DEBIAN/control' contains user-defined field `Original-Maintainer'
[08:57] <Ubulette> dpkg-deb: ignoring 1 warnings about the control file(s)
[08:57] <asac> anyway ... the maintainer field should be fixed anyways
[08:58] <asac> Ubulette: ok its probably a warning which is fatal in bzr bd ... no big thing it needed to be fixed anyway
[08:59] <asac> Ubulette: afaik that warning is harmless
[08:59] <Ubulette> it is
[08:59] <asac> important is that the Original-Maintainer field is available as package meta-data
[08:59] <asac> if not i have a typeo in control
[09:00] <asac> Ubulette: you want to update Maintainer field in xulrunner.trunk?
[09:01] <Ubulette> ok
[09:01] <asac> ah its already motu
[09:01] <asac> switch that to Mozillateam
[09:01] <asac> which hopefully will hold people off from just sponsoring things without checkin back with us
[09:02] <asac> Ubulette: i think you can be X-Original-Maintainer: (if you want of course)
[09:02] <asac> otherwise just drop it as its our own package for now
[09:03] <Ubulette> i used Maintainer: Ubuntu MOTU Developers<EMAIL_ADDRESS>for xul
[09:03] <asac> yeah ... use the same i used for nspr
[09:04] <asac> i don't think it will prevent all accident ... but hopefully some
[09:07] <Ubulette> done. rev5
[09:07] <asac> thx
[09:11] <Ubulette> well, tell me what you find, it's still broken here
[09:11] <Ubulette> i mean ff3+xul
[09:15] <asac> yeah
[09:15] <asac> takes a bit :)
[09:16] <Ubulette> no need to tell me, i know :)
[09:16] <asac> well ;) ... i should get more cores ;)
[09:17] <asac> like 4 more or something
[09:18] <asac> i really want to fix system cairo
[09:18] <asac> this is one of the greatest challenges i currently see
[09:18] <asac> upstream appears not to care at all
[09:19] <Ubulette> they will next time they bump cairo
[09:20] <asac> he?
[09:20] <asac> i doubt it
[09:20] <asac> they saw it
[09:20] <asac> and fixed it by patching internal cairo header
[09:20] <asac> its not that their version is too low to see it
[09:20] <asac> its just that they think its good to have it that way for now
[09:21] <asac> so it doesn't get too critical for their own development
[09:22] <Ubulette> last time i've checked, they only made assert() print without dying, everything else unchanged
[09:22] <asac> yeah
[09:22] <Ubulette> but running their cairo doesn't even show the warning
[09:22] <asac> well ... thats strange ... it definitly popped-up for us at some time that definitly was close to that assertion fix
[09:23] <asac> but maybe you are right
[09:23] <asac> the reverted the cairo bump
[09:23] <asac> because of some issues ... i think it was performance issues, like a 25% drawback on their test machines
[09:23] <Ubulette> yep. hopefully someone is still working on fixing that
[09:23] <Ubulette> mozilla bug 388371
[09:24] <ubotu> Mozilla bug 388371 in Location Bar and Autocomplete "Text in URL bar moves because it has ligatures when host highlighted" [Normal,New]  http://bugzilla.mozilla.org/show_bug.cgi?id=388371
[09:28] <Ubulette> i'm sick of that copy/paste bug in trunk
[09:31] <asac> hmm
[09:31] <asac> fix it :)
[09:31] <tonyyarusso> asac: I'm guessing you're probably enormously busy as usual, but if not, would you be able to have a look at http://revu.tauware.de/details.py?upid=130 to supplement StevenK's comments?
[09:33] <asac> tonyyarusso: that sounds a bit like i would constantly ignore you :) ... hope thats not the case ;)
[09:34] <asac> i might be blind but i don't see any comment yet
[09:35] <tonyyarusso> asac: He just gave some in -motu, not on REVU itself.  And no, you don't ignore me, I just try not to burden you too much ;)
[09:39] <asac> tonyyarusso: what comments/critique did he bring up?
[09:39] <tonyyarusso> asac: see just pasted again in -motu
[09:42] <asac> tonyyarusso: i think the point about not using a patch-system is a bit valid ... the other point about commented stuff in rules is not imo
[09:42] <asac> tonyyarusso: but use quilt as dpatch is braindamaged for mozillas ;)
[09:42] <tonyyarusso> asac: Yeah, that particular patch line is useless now anyway.
[09:43] <asac> tonyyarusso: but you have kompozer.patch as well
[09:43] <asac> that should either be dropped (if not applied anymore) ... or moved to a patchsystem
[09:43] <tonyyarusso> asac: Being dropped.
[09:43] <asac> setting up a patchsystem is definitly worth the effort
[09:43] <asac> should be unlikely that you can go completely without patching kompozer
[09:44] <asac> tonyyarusso: yeah then remove it from debian/ ... so it doesn't pop up in diff.gz
[09:45] <asac> tonyyarusso: do you use mozconfig.debian?
[09:45] <tonyyarusso> asac: what about point 1) regarding copyright, and 3) about a manpage - (do you have any idea what he was trying to say here?)
[09:45] <tonyyarusso> asac: yes, we do.
[09:45] <asac> tonyyarusso: i didn't read anything about that in that post
[09:45] <asac> let me look again
[10:09] <asac> tse ... bzr is again down
[10:09] <asac> shame on lp
[10:09] <asac> wanted to do the last step :)
[10:09] <asac> get latest ffox trunk :/
[10:10] <Ubulette> asac, still fine here
[10:11] <asac> not for me
[10:13] <Ubulette> so maybe it's you :)
[10:13] <asac> no idea
[10:13] <asac> want tell why
[10:13] <asac> normal launchpad works
[10:13] <asac> just bzr has issues
[10:13] <asac> so the genereal route (read within the realm of my provider) should be fine
[10:14] <Ubulette> tried bzr, bzr+ssh, http, all worked as usual
[10:15] <asac> no idea
[10:16] <asac> i wait 10 min then try again (well i keep it running, but i don't think it will get connection)
[10:16] <asac> oh it finishe :)
[10:17] <asac> Ubulette: its not on mt branch
[10:17] <Ubulette> what ?
[10:17] <asac> the one there still doesn't use system-nss/nspr
[10:17] <asac> so its probably not the latest you have
[10:17] <Ubulette> oh, it's not committed yet as it's broken
[10:17] <Ubulette> well, not pushed
[10:18] <asac> ok pulling from your branch then
[10:18] <asac> Ubulette: will you rename the branch? i see that yours is not named trunk anymore
[10:19] <Ubulette> ?
[10:19] <asac> ah there is no difference ... can you please push what you ahve to "trunk" in mt?
[10:19] <asac> your branch also has the --without-system ... things
[10:19] <Ubulette> -        --without-system-nspr \
[10:19] <Ubulette> -        --without-system-nss \
[10:19] <Ubulette> +       --with-libxul-sdk=/usr/lib/xulrunner-devel-1.9a8pre \
[10:19] <Ubulette> +        --with-system-nspr \
[10:19] <Ubulette> +        --with-system-nss \
[10:19] <Ubulette> just that
[10:20] <Ubulette> i don't want to commit something broken, as you said you just want to pull and have something working
[10:21] <Ubulette> mozilla bug 394056
[10:22] <Ubulette> ubotu> Error: Could not parse XML returned by Mozilla: HTTP Error 500: Internal Server Error
 Error: I am only a bot, please don't think I'm intelligent :)
[10:22] <Ubulette> lol
[10:23] <asac> ok
[10:23] <asac> pushed
[10:23] <asac> (just nss/nspr for now)
[10:23] <asac> now let me build after the tarball is here
[10:24] <Ubulette> take mine
[10:24] <asac> haha messed up :)
[10:25] <Ubulette> hmm, last tabmixplus-dev is perfect with trunk, but now broken as hell in gp-a7 making gp unusable
[10:28] <Ubulette> >= 4.7.0 will not work
[10:28] <Ubulette> as 4.7.0~cvs is lower, right ?
[10:28] <asac> its fixed
[10:28] <asac> thought i was fast enough
[10:29] <asac> otherwise shame on me
[10:29] <Ubulette> got a diff by email
[10:29] <asac> yeah i repushed
[10:29] <Ubulette> 3 mails
[10:30] <Ubulette> oh, i didn't know about about:buildconfig
[10:30] <Ubulette> mozilla bug 394056
[10:30] <ubotu> Mozilla bug 394056 in Toolbars "double click on urlbar is no longer copying the url" [Minor,Unconfirmed]  http://bugzilla.mozilla.org/show_bug.cgi?id=394056
[10:30] <Ubulette> nice
[10:31] <Ubulette> thanks ubotu :)
[10:33] <Ubulette> asac, are you done ?
[10:33] <Ubulette> it's quick
[10:33] <Ubulette> ...with --with-libxul-sdk
[10:34] <asac> i already saw that error ... yes.
[10:36] <Ubulette> ?
[10:36] <asac> the xbl one
[10:37] <Ubulette> so you have it too ?
[10:38] <asac> yes
[10:38] <asac> which i never doubted ;)
[10:47] <Ubulette> so, what now ?
[10:47] <Ubulette> missing or misplaced files in xul ?
[10:47] <asac> not yet sure
[10:47] <asac> i think it fails to find the base definition of browser
[10:48] <asac> aka xul:browser
[10:48] <asac> not sure where that is in
[10:48] <asac> e.g. not the browser.xml
[10:49] <Ubulette> btw, i've --disable-javaxpcom in xul, hope it's not that
[10:51] <Ubulette> seems unlikely
[10:51] <asac> unlikely
[10:55] <Ubulette> hmm, print preview in trunk is now broken in gutsy
[10:56] <Ubulette> http://www.sofaraway.org/ubuntu/tmp/Print%20Preview%20Error.png
[11:56] <Ubulette> asac, so ? any clue ?
[11:57] <asac> well ... build xulrunner flat now
[11:57] <asac> in the meantime i do enigmail security upload ... and its scary ... its a regression fix that was introduced by thunderbird sec update
[11:58] <Ubulette> oh
[11:58] <asac> interesting thing ... about 30 days ago ... i applied the fix to dapper, edgy, feisty ... and build against thunderbird dev package <IP_ADDRESS>
[11:58] <asac> interestingly build still worked in feisty
[11:58] <Ubulette> is songbird in ubuntu or debian ?
[11:58] <asac> but was broken in dapper + edgy
[11:58] <asac> had to fix build system
[11:58] <asac> *now*
[11:58] <asac> i  want reupload to security (previous went to proposed which was not really right)
[11:59] <asac> edgy builds fine ... but feisty fails in exactly the same way as dapper edgy before
[11:59] <asac> well i have it fixed now ... but its scary that it came exaclty one thunderbird upstream version later in feisty than in edgy/dapper
[12:00] <Ubulette> indeed
[12:04] <Ubulette> asac, songbird ?
[12:09] <asac> huh?
[12:09] <Ubulette> is that something already packaged ?
[12:09] <Ubulette> or rejected for some reason ?
[12:10] <asac> don't know it :)
[12:10] <Ubulette> (a xul media player)
[12:10] <asac> is that an official mofo project?
[12:10] <Ubulette> a xulrunner app
[12:10] <Ubulette> hmm, don't think so
[12:10] <asac> is it different to "listen" ?
[12:10] <Ubulette> http://www.songbirdnest.com/
[12:11] <asac> except that listen uses gtkmozembed i think
[12:11] <Ubulette> listen is like exaile
[12:52] <asac> Ubulette: didn't you get an exception with debug ffox+xul ?
[12:53] <Ubulette> you mean an abort ? no
[12:53] <asac> didn't you show me some log from a debug build once?
[12:53] <Ubulette> everything's in the logs i've posted yesterday
[12:53] <asac> ok
[12:54] <asac> yeah places
[12:54] <asac> maybe thats it ... it prevents browser.xml to load
[12:54] <asac> its not even attempted from what i see
[12:54] <Ubulette> places ?
[12:54] <Ubulette> the sqlite thing ?
[12:55] <asac> but now that toolbar.xml throws an exception it might be true that it just doesn't apply that anymore
[12:55] <asac> -1211734336[805c3e0] : file (null), line 0: uncaught exception: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsINavBookmarksService.removeObserver] "  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://browser/content/browser.js :: BrowserShutdown :: line 1010"  data: no]
[12:55] <asac> -1211734336[805c3e0] : file chrome://browser/content/places/toolbar.xml, line 60: TypeError: null has no properties
[12:55] <asac> so exclude places from build or fix that null value
[12:55] <asac> to fix the build :)
[12:56] <Ubulette> hmm, i thought that places were now mandatory in trunk
[12:56] <asac> well ... its all #ifdef'ed ... so unset MOZ_PLACES will exclude it most likely
[12:57] <asac> but look in browser.js which property is accessed ... then see why that is null
[12:58] <Ubulette> mozilla bug 392291
[12:58] <ubotu> Mozilla bug 392291 in Places "add a preference to disable places in xulrunner" [Enhancement,Unconfirmed]  http://bugzilla.mozilla.org/show_bug.cgi?id=392291
[12:58] <Ubulette> hmm, no
[12:59] <asac> hmm
[12:59] <asac> first problem is
[12:59] <asac> -1211734336[805c3e0] : file chrome://global/content/bindings/findbar.xml, line 304: TypeError: this._browser.fastFind has no properties
[01:02] <Ubulette> Zarro Boogs found
[01:04] <asac> findbar is document.getBindingParent(this);
[01:04] <asac> aeh fastFind i mean


[12:26] <Ubugtu> New bug: #63445 in xorg "When editing xorg.conf for logitech mouse, wacom settings are added, and I'm locked out of X server." [Undecided,Unconfirmed]  http://launchpad.net/bugs/63445
[02:00] <Ubugtu> New bug: #63461 in mesa-utils "Xlib:  extension "GLX" missing on display ":0.0"" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63461
[09:10] <Ubugtu> New bug: #63500 in xorg "Latest xorg does not work with savage driver" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63500
[09:35] <Ubugtu> New bug: #63503 in xserver-xorg-video-ati "graphics lockups with radeon DRI" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63503
[11:06] <Ubugtu> New bug: #63152 in xorg (main) "[Edgy-Beta]  vesa driver for an ATI 9600" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63152
[12:05] <Ubugtu> New bug: #62775 in casper "Incorrect keyboard in live session" [Undecided,Fix released]  http://launchpad.net/bugs/62775
[02:25] <Ubugtu> New bug: #63551 in xorg "X.org doesn't detect widescreen resolution" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63551
[02:40] <Ubugtu> New bug: #63559 in linux-restricted-modules-2.6.17 "Have to reinstall nvidia kernel module on reboot" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63559
[02:45] <Ubugtu> New bug: #63560 in xorg "installing 915resolution for the correct resolution shouldn't be necessary" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63560
[03:15] <Ubugtu> New bug: #63037 in xorg-server (main) "Freeze during startup of installer with edgy beta" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63037
[05:23] <Ubugtu> New bug: #63584 in xorg (main) "[edgy]  Freeze when switching to VT in AIGLX" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63584
[07:17] <mvo_> rodarvus: imake was moved into xutils-dev in edgy it seems. we may have to create a transition package because the upgrade seems to not pull it in automatically but keeps the old version
[07:18] <rodarvus> mvo_, right, this is on my todo list
[07:18] <mvo_> rodarvus: cool, thanks
[07:18] <Ubugtu> New bug: #63396 in imake (main) "Upgrading to edgy beta leavs imake and makedepend" [Undecided,Confirmed]  http://launchpad.net/bugs/63396
[07:18] <rodarvus> there was an 'xutils' package, which was apparently dropped on our upgrade to debian's xorg package
[07:18] <rodarvus> (which was not handled by me)
[07:19] <rodarvus> I guess I'll just create a transitional xutils package inside xorg for now
[07:19] <mvo_> rodarvus: ok, thanks a lot! I'm reviewing upgrade issues right now and came across this one
[07:19] <rodarvus> mvo_, thank YOU for the report!
[08:25] <Ubugtu> New bug: #63611 in xrdb "xrdb crashes on startup" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63611
[09:40] <Ubugtu> New bug: #63618 in linux-restricted-modules-2.6.17 "atheros laptop LED not activated" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63618
[10:20] <Ubugtu> New bug: #63625 in linux-restricted-modules-2.6.17 "edgy - nvidia-glx install causes x to fail" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63625
[10:20] <Ubugtu> New bug: #63627 in linux-restricted-modules-2.6.17 "Graphic Acceleration dont work" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63627


[03:20] <BuSdRiVer320> Hi All
[03:20] <BuSdRiVer320> Which is the best DLNA server app to install? I've used miniDLNA in the past, but had problems setting it up
[13:31] <Noboru55> diogenes_ hello, that tuto works very well, i can now install xfce4 stuff, like xfce4-screensaver. in 18.04 it just works with lock screen enable, but its ok.. no problem to me
[13:32] <Noboru55> diogenes_ i have a problem with touchpad, it always happened to me, like when typing for some reason the mouse go to other place so i start to type in wrong place, so i need to disable touchapd when typing, its a configuration in touch pad and mouse config....  but would be perfect if the sensitive touchpad was not soooo sensitive
[13:33] <Noboru55> windows is perfetc to configure touchpad sensitive  ... ubuntu i always get a problem
[13:35] <diogenes_> Noboru55, maybe it's a focus issue, my touchpad works fine.
[13:39] <Noboru55> diogenes_ fixed, did not see before, i can set the duration to unable touchpad when typing, so i confiure to 0,2
[13:40] <Noboru55> now, its ok... goog to know if someone asks about it too
[15:59] <lochnas> I got stuck in the login loop a few nights ago on my Xubuntu 18.04 machine.
[16:00] <lochnas> Is there any fix for this bug in future releases?
[16:03] <diogenes_> lochnas, it is not a but, there must have been something that has caused this behavior like for instance playing around with config files, driver installations etc.
[16:04] <diogenes_> bug*
[16:11] <lochnas> Nope.
[16:12] <lochnas> diogenes_: I haven't been doing much of anything "under the hood" on the Xubuntu machine.
[16:14] <diogenes_> check if "save session" is enabled.
[16:19] <lochnas> Yes, on logout.
[16:19] <diogenes_> that's what might have caused the problem.
[16:20] <lochnas> It's been like that for a year now without resulting in the login loop.
[16:23] <diogenes_> it takes one time to have some corrupted file that has been saved and there you have a login loop.
[16:26] <lochnas> Well darn.
[16:27] <lochnas> I wonder what caused the corruption.
[16:28] <diogenes_> look in .xsession-errors
[16:53] <tomreyn> could also be that you ran something graphical with sudo and it took over ownership of some files in your home directory as the root user.
[16:55] <tomreyn> lochnas: ^ i'm late to the party, but if this is still unsolved, try looking for such files in your $HOME: login via !tty by running:      sudo find . -not -user $USER -or -not -group $USER -ls
[17:05] <lochnas> .Xauthority was still owned by me.
[17:07] <lochnas> It ended out that I re-installed ubuntu-session and ubuntu-desktop, and that did the trick, but I feel like I should have re-installed xubuntu-session since the login is all which ways of different.
[17:07] <lochnas> ..and now I have extra software (from ubuntu-desktop) that I'll have to clean up.
[17:30] <Noboru55> diogenes_ hey again... do you know the terminam command to copy many directories at same time to other directory?  cp -R  *.* /place  doesn't works
[17:33] <diogenes_> Noboru55, cp -r /home/username/Documents/* /some/place
[17:33] <Noboru55> oh.. my mystake
[17:33] <Noboru55> its now files, so doesnt need *.*  only *
[17:33] <Noboru55> diogenes_ thank you, i forgot that
[17:33] <diogenes_> np
[17:33] <Noboru55> isn't files i meant
[17:34] <diogenes_> it copies everything.
[17:34] <Noboru55> sometimes i forgot easy things
[17:34] <Noboru55> yes..
[17:35] <Noboru55> now i have many audacious skins...


[11:00] -queuebot:#ubuntu-release- New binary: ruby-mocha [amd64] (artful-proposed/universe) [1.2.1-1] (no packageset)
[12:29] -queuebot:#ubuntu-release- New binary: libmicrohttpd [ppc64el] (artful-proposed/universe) [0.9.55-1] (no packageset)
[12:30] -queuebot:#ubuntu-release- New binary: libmicrohttpd [amd64] (artful-proposed/universe) [0.9.55-1] (no packageset)
[12:30] -queuebot:#ubuntu-release- New binary: libmicrohttpd [s390x] (artful-proposed/universe) [0.9.55-1] (no packageset)
[12:30] -queuebot:#ubuntu-release- New binary: libmicrohttpd [i386] (artful-proposed/universe) [0.9.55-1] (no packageset)
[12:31] -queuebot:#ubuntu-release- New binary: libmicrohttpd [arm64] (artful-proposed/universe) [0.9.55-1] (no packageset)
[12:33] -queuebot:#ubuntu-release- New binary: libmicrohttpd [armhf] (artful-proposed/universe) [0.9.55-1] (no packageset)
[14:02] -queuebot:#ubuntu-release- New: accepted klaus [amd64] (artful-proposed) [1.2.1-3]
[14:02] -queuebot:#ubuntu-release- New: accepted libmicrohttpd [arm64] (artful-proposed) [0.9.55-1]
[14:02] -queuebot:#ubuntu-release- New: accepted libmicrohttpd [i386] (artful-proposed) [0.9.55-1]
[14:02] -queuebot:#ubuntu-release- New: accepted libmicrohttpd [s390x] (artful-proposed) [0.9.55-1]
[14:02] -queuebot:#ubuntu-release- New: accepted ruby-mocha [amd64] (artful-proposed) [1.2.1-1]
[14:02] -queuebot:#ubuntu-release- New: accepted libmicrohttpd [amd64] (artful-proposed) [0.9.55-1]
[14:02] -queuebot:#ubuntu-release- New: accepted libmicrohttpd [ppc64el] (artful-proposed) [0.9.55-1]
[14:02] -queuebot:#ubuntu-release- New: accepted libmicrohttpd [armhf] (artful-proposed) [0.9.55-1]
[14:02] -queuebot:#ubuntu-release- New: accepted ruby-googleauth [amd64] (artful-proposed) [0.5.1-2]