[00:07] <nhandler> Congrats jpds!
[00:11] <Laney> what's the outcome of the vote?
[00:12] <nhandler> Laney: https://edge.launchpad.net/~ubuntu-dev/+polls
[00:12] <nhandler> Yes majority on all 3 votes
[00:12] <Laney> nice one, congrats
[00:12] <Laney> (I didn't know how to interpret the results)
[00:13] <ajmitch> just a rubber-stamp
[00:13] <ajmitch> if more yes than no, it passes
[00:14] <dtchen> Andrew Mitchell for MOTU Council in 2007  - closed on 2007-02-15 ;-)
[00:14] <dtchen> geez, we're fogeys
[00:14] <Laney> *ancient*
[00:14] <ajmitch> yep
[00:14] <ajmitch> such a long time ago now
[00:36] <blackmoon105> if i rebuild a .deb package that already exist in the debian repositories (with a debian mantainer), i must write my name as mantainer in the "control" file for the ubuntu build, it's right?
[00:37] <nhandler> Where are you building the package blackmoon105 ? In your PPA?
[00:38] <blackmoon105> nhandler: yes, in my PPA
[00:39] <blackmoon105> nhandler: yes, i'm building the package in my PPA
[00:40] <nhandler> blackmoon105: Then I would set yourself as the Maintainer and move the Debian Maintainer to the XSBC-Original-Maintainer field
[00:41] <blackmoon105> nhandler: ok, thanks
[01:18] <wasabi> savvas: ping
[01:21] <Kamping_Kaiser> is there an ubuntu equivilant to Debians dev-ref? I've found the customised Ubuntu debian-policy, but not the ref.
[01:25] <ScottK> Kamping_Kaiser: Is there something specific you're looking for?  Most of our stuff is in w.u.c somewhere.
[01:26] <Kamping_Kaiser> ScottK, the build dependancies allowed/disallowed between parts of the archive (main/universe/restrcited and release/release-updates/release-security etc)
[01:27] <ScottK> I'm sure that's documented somewhere, but I couldn't tell you exactly where.
[01:27] <ScottK> I can tell you how it works though if you want.
[01:28] <Kamping_Kaiser> please do. (it'll give me a starting point to try and find the 'proper' documentation)
[01:30] <ScottK> OK
[01:31] <ScottK> Each layer of the archive has to be completely self contained.
[01:31] <ScottK> Packages in Main can only build-dep, depend, or recommend other packages in Main.
[01:32] <ScottK> Then for Universe it's Universe + Main.
[01:32] <ScottK> Restricted is Main + Restricted.
[01:32] <ScottK> Multiverse is Main, Restricted, Universe, and Multiverse.
[01:32] <ScottK> Is that sensible?
[01:33] <Kamping_Kaiser> yep, with you so far.
[01:33] <ScottK> OK.
[01:33] <ScottK> At release time you get the release pocket.
[01:34] <ScottK> -updates and -security both build on themselves and -release.
[01:34] <ScottK> The trick is that -security updates get copies from -security to -updates on some periodic.
[01:34] <ScottK> So -updates ends up with all the post-release changes.
[01:35] <ScottK> (if a package has a -update and then gets a security fix in -security you have to change the package in -updates (or -proposed) to have that security fix.
[01:36] <ScottK> Packages destined for -updates are uploaded to -proposed and then built and tested there.
[01:36] <ScottK> Once blessed they are copied from -proposed to -updates.
[01:36] <ScottK> How's that?
[01:37] <ScottK> Kamping_Kaiser: ^^^
[01:37] <Kamping_Kaiser> so if i undestand correctly, -release is equivilant to debians 'frozen'. then after release -updates builds using -updates and -release, security builds using -security and -release. but does not build using -security, -release *and* -updates ?
[01:38] <ScottK> Yes.  I'm not certain, but I think -updates also builds against -security although it doesn't matter much because stuff gets copied from -security to -updates anyway.
[01:39] <ScottK> The reason for this is that running with just security updates and not bugfixes is a supported use case.
[01:39] <ajmitch> security is considered more conservative, so it won't grab any of the 'riskier' stuff from -updates
[01:39] <Kamping_Kaiser> i see. this bit is specifically what i'm trying to find a policy on.
[01:39] <ScottK> ajmitch: I'd put it slightly differently.  I'd say it's considered more essential.  The risk may be higher or lower, but it's more worth taking.
[01:40] <ajmitch> same thing, different perspective really
[01:40] <Kamping_Kaiser> ScottK, current linux-image in hardy-security depends on stuff in -updates to build and install. this is a pita for gNewSense, since we dont offically support updates, and which is whats started me looking into this whole thing. (i posted on -dev about this last night but go no bites)
[01:40] <ScottK> There was a recent discussion on this in ubuntu-devel because of gcc updates getting into -updates and the risk of some stuff ending up misbuilt.
[01:41] <ajmitch> the discussion on -devel sounds like exactly what you're talking about with the kernel there
[01:41] <ScottK> Yes
[01:41] <Kamping_Kaiser> and since my recollection was '-updates should be optional', and we've had packages rebuilt because they depended on -updates before, i was surprised to be told privately -security could depend on -updates
[01:42] <ScottK> It's not supposed to as I understand it.  I'd ask kees.
[01:42] <ajmitch> or doko, he seemed to know about it as well, since it was gcc
[01:43] <Kamping_Kaiser> would sending kees an email be the best move, or ping him on irc later?
[01:43] <Kamping_Kaiser> I guess email, then i can include this convo for background.
[01:45] <Kamping_Kaiser> ScottK, and ajmitch  thanks very much for the help
[01:46] <ajmitch> you've read the thread about this time last month about kernel-compiler mismatches?
[01:46] <Kamping_Kaiser> no, but i could do.happened on u-dev list?
[01:47] <ajmitch> yeah it did, it pretty much covers what you were talking about, I think
[01:47] <Kamping_Kaiser> I'll go and check, thanks.
[01:47] <ajmitch> https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027366.html
[01:48] <Kamping_Kaiser> ta
[02:01] <Kamping_Kaiser> I dont see anyone object to ScottK 's mention of the 'without updates' usecase, so I might file a bug on the linux packages
[02:27] <Kamping_Kaiser> I've jut fired off an email. Thanks again. I'm sure I'll be back later.
[03:23] <jdong> what do people feel about backporting config-package-dev?
[03:23] <jdong> bug 315264
[03:23] <jdong> I was looking over the diff and couldn't really see anything that would pose a problem
[06:13] <dholbach> good morning
[06:18] <iulian> Morning dholbach.
[06:18] <dholbach> hey iulian!
[07:13] <fabrice_sp_> Hi. About python2.6 transition. What should I do if a package still depends on python2.5, but build with python2.6, and don't have any issues with python2.6? add an entry for package rebuild in changelog?
[07:13] <fabrice_sp_> and submit hte debdiff?
[07:15] <fabrice_sp_> have to go now.  If not then it should be removed from kubuntu-restricted-extras dependencies.
[09:38] <directhex> slytherin, try playing a dvd with xine - libdvdread spams output on stdout iirc
[09:40] <dholbach> directhex: uploaded
[09:41] <directhex> dholbach, thanks. sorry for the debdiff cock-up. i wasn't thinking properly - it's a while since i've merged anything since full syncability was a jaunty goal
[09:41] <dholbach> directhex: no worries
[09:42] <directhex> which gnome# 2.24's abi break hasn't helped with. such is life
[09:44] <slytherin> directhex: Will try tonight
[09:45] <directhex> dholbach, i'll ask the maintainer if he'd consider adding planet ubuntu at that end
[09:45] <dholbach> directhex: super, thanks
[10:06] <dholbach> can't believe there's not more people in the motu group: http://identi.ca/group/motu
[10:07] <directhex> i don't "get" this twittering things
[10:07] <directhex> also, not a motu
[10:07] <dholbach> ... yet :)
[10:08] <cristi> dholbach: hy, are you Daniel Holbach ?
[10:08] <dholbach> cristi: yep
[10:09] <cristi> dholbach: you asked for mmkeys.so here https://bugs.edge.launchpad.net/ubuntu/+source/sonata/+bug/341409
[10:09] <cristi> dholbach: i don't know what are you refering
[10:09] <dholbach> cristi: run less on the old python-mmkeys .deb and on the new one and compare
[10:09] <dholbach> or dpkg -c
[10:10] <dholbach> you'll see that the old package had two versions (one for python2.4, one for python2.5) of the .so file, the new package just has one for python2.5
[10:11] <cristi> dholbach: i see your point now
[10:11] <dholbach> ok good
[10:11] <dholbach> I'm not an expert, I just thought it might be a problem :)
[10:12] <cristi> dholbach: however, since 2.4 will not be used anymore, and it was posted for the python transition, is it necessary to add the 2.4 version?
[10:12] <dholbach> cristi: no, dropping 2.4 is fine - there's just no 2.6 version
[10:16] <cristi> dholbach: i am new with packaging, so i don't really know what i have to do now. i followed https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027528.html for the python transition. i used a jaunty pbuilder to build. what should i do?
[10:16] <dholbach> cristi: to be honest, I don't know - as I said: I'm not an expert
[10:18] <cristi> dholbach: oh, mkay, then hopefully soon a motu will take a look for sponsoring, and give me a feedback with what is wrong
[10:18] <dholbach> yep
[11:03] <jpds> nhandler: Thank you, you too!
[11:44] <AdamDH> if I change my package to a different Series say Januty instead of Intrepid but the version does not change do I need a change log entry to reflect this?
[11:44] <AdamDH> I noticed some package do some do not, just wanted to know what was best practice
[11:51] <directhex> you can't have 2 different packages with the same version number
[12:08] <AdamDH> I am just changing the packaging more than anything not the actual source
[12:08] <directhex> so?
[12:09] <AdamDH> so just bump the version and change the changelog to show the packaging has been updated?
[12:09] <AdamDH> this is the first time I have been in this situation with packages I have created
[12:09] <hyperair> AdamDH: that's right.
[12:10] <hyperair> AdamDH: you cannot have two packages of the same version in the same repository, even if it's in a different series
[12:10] <directhex> AdamDH, the bit after the - is specifically for packaging-related versioning
[12:10] <directhex> that's why -2, -3, etc, exist
[12:11] <AdamDH> so could I just append say -0ubuntu1~ppa1 to show the packaging has been update and change the changelog?
[12:11] <AdamDH> or is it just -0ubuntu1 and increase the 1?
[12:11] <hyperair> AdamDH: something like that.
[12:12] <hyperair> AdamDH: read the packaging guide
[12:12] <hyperair> and read the ppa guide
[12:12] <directhex> AdamDH, append -0ubuntu1~ppa1 to what existing version?
[12:12] <AdamDH> 0.14 is the version
[12:13] <hyperair> try not to have <upstream-version>-N or <upstream-version>-NubuntuM in a ppa.
[12:13] <hyperair> add a suffix
[12:13] <directhex> AdamDH, 0.14 is the PACKAGE version?
[12:13] <hyperair> ~somethingX if you want it to be superseded by the corresponding ubuntu/debian version
[12:14] <hyperair> +somethingX otherwise
[12:14] <AdamDH> yup 0.14 is the upstream version
[12:14] <hyperair> okay, and what's the ubuntu version?
[12:14] <directhex> AdamDH, i didn't ask that, i asked what the PACKAGE version was.
[12:15] <directhex> AdamDH, packages are versioned upstreamver-pkgrevision, unless they are "native" packages (i.e. the distro is upstream and it's only used in the distro), say... update-manager
[12:16] <AdamDH> there is no pkgrevision yet I am doing the revision
[12:16] <hyperair> then 0ubuntu1
[12:16] <hyperair> 0ubuntu1 if it goes into ubuntu
[12:17] <hyperair> 1 if it goes into debian
[12:17] <directhex> you said you were changing your package though. you have an EXISTING package, with package version number 0.14?
[12:17] <hyperair> and 0ubuntu1~ppa1 if it goes into a ppa
[12:17] <AdamDH> yes there is an exsisting package for intrepid with version 0.14 but the code will not change just the packaging
[12:17]  * hyperair headdesks
[12:17] <hyperair> i give up
[12:17] <directhex> sigh, i feel i'm having trouble communicating here
[12:17] <hyperair> directhex: you and me both
[12:18] <AdamDH> sorry The versioning ubuntu is using is just confusing me at the moment
[12:18] <directhex> 0.14 is NOT A VALID PACKAGE VERSION, other than a HIGHLY specific exception. if you've been using it, you've been doing things wrong.
[12:18] <hyperair> AdamDH: did you read ANY DAMN THING that directhex just said?!
[12:19] <AdamDH> yes I did, want to start a fresh so I can explain what I have started with?
[12:19] <directhex> if the upstream tarball says 0.14, and versions are meant to be upstream-revision, then the format must be 0.14-1 or 0.14-0ubuntu1
[12:19] <AdamDH> I think your refering to something I know as something else so its causing a little confusion, sorry
[12:19]  * hyperair will now head out to eat dinner.
[12:19] <directhex> using a native package causes significant issues, as it kills off the orig/diff system
[12:20] <directhex> i.e. you no longer have a pristine upstream tarball (orig) against which your packaging work applies (diff) so updates to the existing version are impossible (can't re-use orig)
[12:20] <AdamDH> the upstream tar is 0.14 so it should be upstream-revision? so I should be using 0.14-1 or 0.14-0ubuntu1 ?
[12:20] <AdamDH> right makes sense
[12:21] <directhex> and if you're only going into a PPA for now, append ~ppa1 to the end, meaning "this is the PPA version of 0.14-0ubuntu1, but i want the 'real' 0.14-0ubuntu1 to be installed given the option"
[12:21] <directhex> that way a distro 0.14-0ubuntu1 repolaces your PPA version
[12:22] <AdamDH> the packages I created in my PPA I did msp430-binutils - 2.19.1-0ubuntu1~ppa4 etc
[12:23] <AdamDH> but I am working with packages created by some one else at the moment hence the confusion and updating those
[12:23] <AdamDH> thanks for the help directhex, hyperair
[12:26] <directhex> james_w, ping
[12:26] <james_w> directhex: hey
[12:27] <directhex> james_w, can you forward me the monodevelop-debugger-gdb reject mail? it's simply not on the ubuntu-archive archive
[12:27] <james_w> the reject mail is just the autogenerated one
[12:27] <james_w> I haven't received an explanation mail
[12:28] <directhex> no clue who rejected?
[12:28] <james_w> nope
[12:38] <kaushal> hi
[12:38] <kaushal> what does motu means ?
[12:38] <Pici> !motu
[12:38] <kaushal> Thanks Pici
[12:38] <Pici> kaushal: surely
[12:39] <kaushal> will tomboy 0.12 be backported to Ubuntu 8.04 Desktop ?
[12:41] <kaushal> ii  tomboy                            0.10.1-1                          desktop note taking program using Wiki style links
[12:42] <directhex> only if someone does the work
[13:47] <slytherin> directhex: xine uses it's own private version of libdvdread/libdvdnav and while option to compile against external libdvdread exists it is not recommended (as said by configure --help)
[13:53] <directhex> slytherin, how lame
[13:54] <jdstrand> Kamping_Kaiser, ScottK: while kees is the person to talk regarding the kernel -security/-updates issue, I can say that systems without -updates enabled are entirely supported and anything in -security that depends on -updates is a bug
[13:56] <Kamping_Kaiser> jdstrand, bril, thank you! I've sent kees an email. with any luck i'll still be awake when he gets on IRC (its about 5am where he is i think).
[13:58] <bddebian> Heya gang
[13:58] <nhandler> Hey bddebian !
[13:58] <jdstrand> Kamping_Kaiser: fyi, in these cases it is entirely appropriate just to send to<EMAIL_ADDRESS>[13:58] <jdstrand> Kamping_Kaiser: we'd all get it and then also be in the loop on it
[13:58] <Kamping_Kaiser> bddebian, hey mate.
[13:58] <bddebian> Hello nhandler
[13:59] <bddebian> Heya Kamping_Kaiser
[13:59] <jdstrand> Kamping_Kaiser: don't feel you have to resend though-- just fyi
[13:59] <slytherin> directhex: Do you think we should compile xine against the libdvdread/libdvdnav in repos? Because a private copy means that we are not sure of it's status.
[14:00] <Kamping_Kaiser> jdstrand, ok. I've been getting mixed messages, and been unable to find anything in an Ubuntu policy about it.
[14:00] <jdstrand> Kamping_Kaiser: sorry about that. I can fix the policy. Where were you looking?
[14:01] <jdstrand> Kamping_Kaiser: and where did you expect to find it?
[14:01] <Kamping_Kaiser> jdstrand, I was going through the ubuntu-policy package, but hadnt found it (iirc i was 10-15% of the way through).
[14:02] <jdstrand> Kamping_Kaiser: interesting-- I can take a look at it
[14:02] <Kamping_Kaiser> none of my searches using google got me joy either, but its one of those situations where i'm not sure what i can search for to get the right results.
[14:04] <jdstrand> Kamping_Kaiser: I think going to wiki.ubuntu.com/Security and/or SecurityTeam should get you there
[14:04] <jdstrand> Kamping_Kaiser: I say 'should' as in "I'm going to check to make sure it does"
[14:05] <Kamping_Kaiser> hehe. ok, thanks. I'll have a try too
[14:05] <jdstrand> Kamping_Kaiser: if there is an appropriate place in ubuntu-policy for referencing it, then we can have a generic blurb and maybe reference the wiki
[14:05] <directhex> slytherin, hm, i'd ask someone like siretart for opinion on that
[14:05] <directhex> slytherin, FWIW i ignore recommendation & use distro cairo for moon
[14:05] <jdstrand> Kamping_Kaiser: but the team will talk about improving the situation
[14:06] <siretart> slytherin: have you verified the changes done to those libraries in xine?
[14:07] <Kamping_Kaiser> jdstrand, thanks. I was specifically looking in the section regarding repository split up (main/universe/r/m) in ubuntu-policy, but if theres a better place I wouldnt object to reading further for it
[14:09] <jdstrand> Kamping_Kaiser: I know I have certainly talked about that in several places-- and pretty sure I wrote about it in the wiki. I think I also came across it the other day in ArchiveReorganisation
[14:09] <jdstrand> Kamping_Kaiser: thanks for your feedback. We'll get that fixed up
[14:10] <Kamping_Kaiser> jdstrand, tbh, even though I can roughly describe what I'm trying to get at, and ScottK explained it all, i'm still not sure i'd know what to search for to find the right answer. (a personal problem, but perhaps relevant when trying to work out what to put on the page)
[14:11]  * jdstrand nods
[14:11] <jdstrand> Kamping_Kaiser: I fully agree that it is not widely known
[14:11] <jdstrand> (which is why I've talked to a bunch of people about it :)
[14:11] <Kamping_Kaiser> :)
[14:11] <slytherin> siretart: not yet, but the last entry in upstream changelog about update of libdvdnav is from December 2004
[14:12] <Kamping_Kaiser> jdstrand, if i can be a help re this, feel free to ping me.
[14:13] <jdstrand> Kamping_Kaiser: cool. thanks :)
[14:14] <Kamping_Kaiser> np! thanks for /your/ help
[14:36] <c_korn> does someone know when mok0 usually comes online?
[15:04] <ripps> Hey, I'm trying to run a PPA team repository that keeps in sync often with git. The problem is that the program has about 20 plugins that need to be rebuilt whenever a change happens to the main program. Is there some way to automate the rebuilding process for these plugins?
[15:05] <ripps> This isn't counting all the backports for the plugin, the archive contains
[15:23] <Kamping_Kaiser> hopefully almost kees-gets-back-oclock. *tick tock tick* :)
[15:26] <porthose> Would a kind MOTU from the release team please have a look at Bug #338408 thx;-)
[15:34] <gaspa> dholbach: did you see my proposal for harvest-data?
[15:34] <dholbach> gaspa: no, sorry - seems I did not get that mail - will take a look at it in a sec
[15:35] <gaspa> thanks. ;)
[15:48] <mbudde> I'm working on packaging pidgin-plugin-pack 2.5.1. When I build it I get loads of dpkg-shlibdeps warnings (see http://launchpadlibrarian.net/23781571/buildlog_ubuntu-jaunty-i386.purple-plugin-pack_2.5.1-0ubuntu1~ppa2_FULLYBUILT.txt.gz ) Is there something wrong and can I do anything about it?
[16:06] <hyperair> mbudde: look into banshee packaging, and copy the debian/patches/99_ltmain-as-needed.patch
[16:06] <hyperair> mbudde: then add LDFLAGS += -Wl,--as-needed into debian/rules
[16:07] <hyperair> mbudde: if the patch doesn't apply due to some context changes in ltmain.sh, you may need to manually make those changes and refresh the patch
[16:08] <mbudde> hyperair, ok, I'll take a look at it :) Thanks!
[16:08] <hyperair> mbudde: np
[16:22] <wasabi> savvas: added to group
[16:22] <wasabi> savvas: curios about your plans for gapti
[16:34] <Kamping_Kaiser> jdstrand, btw, the KernelMaintenance page at the bottom has a section "main, proposed and security". Might be worth linking from there to whatever doco gets put together about the -updates/-security bit.
[16:34] <Kamping_Kaiser> sneaky bastard. :o
[16:40] <Kamping_Kaiser> jdstrand, btw, the KernelMaintenance page at the bottom has a section "main, proposed and security". Might be worth linking from there to whatever doco gets put together about the -updates/-security bit. (sorry to the channel who have to see this twice)
[16:40] <jdstrand> Kamping_Kaiser: thanks. I also found where I wrote it: SecurityTeam/FAQ
[16:40]  * Kamping_Kaiser looks
[16:41] <jdstrand> Kamping_Kaiser: it isn't really that exciting :)
[16:41] <Kamping_Kaiser> jdstrand, how exciting can you make kernel packaging? ;)
[16:41] <jdstrand> heh
[16:43] <Kamping_Kaiser> Now i have to go and look at the email i sent kees to check how much is still relevant *heh*
[16:43] <RainCT> Is anyone here using LXDE?
[16:44] <kees> Kamping_Kaiser: heh, it'll be a bit before I get through my email this morning.  :)
[16:44] <Kamping_Kaiser> kees, i've waited to 3am, i'm sure i can wait another hour or two.
[16:45] <Kamping_Kaiser> now, where did i put that can of caffeine...
[16:45] <Toadstool> RainCT: yep, I am
[16:46] <kees> Kamping_Kaiser: heh, ah, just got to it.
[16:46]  * RainCT has just installed it out and can only say.. "wow" :). Login time is less than 1 second and it has panel and everything (unlike openbox) and actually looks great :D
[16:47] <Kamping_Kaiser> kees, dont recall exactly what i wrote, but since then i'm told canonically that -security should stand alone, so anything about confusion can be ignored. the bit about 'what happens now' remains.
[16:47] <Kamping_Kaiser> RainCT, o_0 1 second? thats faster then e16 :o
[16:47] <RainCT> Toadstool: .. but I've got some untranslated entries in the menu (like "Game" and "Network"), do you happen to know why that happens?
[16:47] <RainCT> heh
[16:48] <RainCT> well, it's on a new laptop here.. I'll try it on my sister's PC later (which has 256MB RAM)
[16:48] <Toadstool> RainCT: uh, er, no, I am using LANG=en_US here
[16:48] <kees> Kamping_Kaiser: right, it is a bug that anything in -security would depend on -updates.  it sounds like fixing the compiler glitch needs to move forward.
[16:49] <kees> Kamping_Kaiser: is this a problem for hardy, intrepid, or both?
[16:50] <Kamping_Kaiser> kees, i know its a problem in hardy (gNS bases off it), dont know about intrepid
[16:50] <kees> Kamping_Kaiser: okay
[16:52] <Kamping_Kaiser> kees, is there a bug about the gcc shuffle i can sub to? i'd like to keep a tab on it.
[16:52] <kees> Kamping_Kaiser: let me ask the kernel team...
[16:53] <Kamping_Kaiser> kees, ok. i'm in there too, so i can hang around if theres no quick reply.
[16:55] <RainCT> uhm.. e16 looks interesting, but I don't like it on a first try (and it took ages to generate a menu :P)
[16:56] <Kamping_Kaiser> e ftw.
[16:58] <RainCT> hm, perhaps I could even get used to it.. anyway, I'm off, cya
[16:59] <Kamping_Kaiser> later mate
[17:17] <Kamping_Kaiser> kees, I might head to sleep. I'm still in -kernel, so if the bug report gets found i'll subscribe myself tomorrow. Thanks for looking into it.
[17:21] <kees> Kamping_Kaiser: cool, g'night
[17:22] <Kamping_Kaiser> later mate.
[17:25] <ripps> I'm trying to setup an autoppa system for maintaing a bunch of packages. I have 20 plugins that I want to bundle into a single source package that I can upload and build into 20 seperate binary packages. I've seen other packages do this, is there some information somewhere on how to do this?
[17:34] <eMerzh> I'm looking for a motu to review my package at http://revu.ubuntuwire.com/details.py?package=sqliteman
[17:34] <savvas> wasabi: well not much, just planning to fix it upstream to be compatible with python 2.6 / 3.0 - we'll see how it goes heh :)
[17:34] <savvas> be back later
[18:46] <fabrice_sp> Hi. gcompris appears as depending in python2.5 in Jaunty, but it build fine in a schroot. Should I open a bug to bump the version to force the rebuild or it will be automatically rebuild at some point?
[18:47] <fabrice_sp> (it's for python2.6 transition)
[19:13] <ScottK> It won't get automatically rebuilt.
[19:22]  * fabrice_sp will open a bug, then.
[19:40] <Ornedan> Depends line of libghc6-network-doc: Depends: ghc6-doc (>= 6.8.2), ghc6-doc (<< 6.8.2+), libghc6-parsec-doc (= <IP_ADDRESS>-2)
[19:40] <Ornedan> Is that as self-contradictory as it seems to be?
[19:41] <ScottK> It's not.
[19:42] <Ornedan> Ok. So what does that << mean, then?
[19:43] <soren> Ornedan: The '<<' means what you expect. The '+' probably doesn't.
[19:44] <Ornedan> 'k. Something does seem contradictory, though, since trying to install the package fails with
[19:44] <Ornedan> Depends: ghc6-doc (>= 6.8.2) but it is not going to be installed Depends: ghc6-doc (< 6.8.2+) but it is not going to be installed
[19:44] <ScottK> Ornedan: It means any version  6.8.2 - 6.8.2+ inclusive of 6.8.2, but exclusive of 6.8.2+.
[19:44] <directhex> i.e.  6.8.2-*
[19:45] <directhex> 6.8.2-1 or 6.8.2-10ubuntu67~ppa3 matches that
[19:45] <ScottK> Ornedan: What version of ghc6-doc do you have?
[19:47] <Ornedan> Hmm... Seems none. Blargh and nvm. I was trying to get haskell set up with haddock more recent than is available from the official repositories, seeing as the version there is 0.8 and latest release is 2.4.1
[19:49] <ajmitch> ghc6 is another one of those special packages
[19:49] <soren> "spethial"
[19:49] <Ornedan> And the documentation syntax has changed somewhat since 0.8, so it fails on some 1/3 of recent libraries
[19:50] <jdong> nxvl, other motu-SRU and similar folk, can someone weigh in on bug 341832?
[19:51] <unit3> #ubuntu-dev pointed me here. I'm doing some backporting with prevu, but I can't seem to pass it -j8 or similar to do some parallel building.
[19:51] <Ornedan> Someone did have haddock 2.4.1 & a more recent ghc packaged in their PPA, but that ghc was missing the critical standard libraries :P
[19:51] <unit3> Is there a way to pass that through prevu to dpkg-buildpackage so I can take advantage of all my iceccd installs?
[19:51] <jdong> well that should be a DEB_MAKE_OPT in debian/rules.
[19:52] <jdong> and is not a prevu-specific problem -- it's a debian packaging problem
[19:52] <jdong> err DEB_BUILD_OPTIONS rather.
[19:52] <unit3> ok, but generally, I can go "dpkg-buildpackage -j8 -b" and it does what I expect.
[19:52] <soren> #ubuntu-dev?
[19:53] <unit3> so how do I get prevu to call dpkg-buildpackage that way?
[19:53] <jdong> well, you really shouldn't.
[19:53] <jdong> prevu does not support such options, just like the Ubuntu build servers
[19:53] <jdong> to do parallel builds you should really edit your rules file to do so correctly
[19:54] <unit3> Ok, is there a way to get prevu to just grab and unpack a specific source release, so at least I don't have to manually hunt that down?
[19:54] <unit3> then I can edit the debian/rules file myself.
[19:54] <unit3> also... if you're not supposed to do that, then why does dpkg-buildpackage have a -j option?
[19:54] <unit3> it's confusing, to say the least.
[19:55] <jdong> well dpkg-buildpackage has a lot of liberties for in place builds that pbuilder/sbuild do not.
[19:55] <unit3> ok.
[19:55] <jdong> http://www.debian.org/doc/debian-policy/ch-source.html
[19:55] <jdong> see 4.9.1 about parallelism
[19:55] <maxb> jdong: Why shouldn't prevu/pbuilder do parallelism?
[19:56] <jdong> maxb: it shouldn't handle it sopecially as a -j flag IMO. AFAIK setting DEB_BUILD_OPTIONS in your environment passes it in correctly
[19:56] <unit3> That seems not particularly well thought out. I mean, I see it there, but the package build system has no idea what level of parallelism is appropriate to my build environment, so why does hardcoding the number of jobs there make sense?
[19:56] <jdong> which is AFAIK how the buildd's do it.
[19:56] <unit3> oh, you can set the environment var?
[19:57] <unit3> that makes more sense.
[19:57] <unit3> and I'm fine with that. :)
[19:57] <jdong> unit3: no no, having your build system support DEB_BUILD_OPTIONS as per 4.9.1. then setting environment :)
[19:57] <maxb> unit3: note that dpkg-buildpackage -jX is only a shorthand for setting MAKEFLAGS and DEB_BUILD_OPTIONS envvars anyway.
[19:58] <jdong> correct
[19:58] <unit3> jdong: ok, I'm confused again. my build system is prevu. Does it support the DEB_BUILD_OPTIONS stuff?
[19:58] <jdong> unit3: no no, your buildsystem is the debian/rules file.
[19:58] <jdong> prevu/pbuilder is your build...er? I guess
[19:58] <jdong> whatever the correct terminology is.
[19:58] <unit3> erm... hrm... that terminology doesn't make sense to me. but I see what you're saying now.
[19:59] <jdong> lol that could be my fault or the pre-existing terminology's fault ;-)
[19:59] <unit3> yeah, it's existing terms, I just mapped them to something else in my head. ;)
[20:00] <jdong> maxb: I'm surprised MAKEFLAGS is being set by dpkg-buildpackage though... are the debian/rules targets really parallel-safe?
[20:00] <jdong> or am I confusing MAKEFLAGs with MAKEOPTS again?
[20:00] <jdong> stupid similarly named environment variables.
[20:00] <unit3> again, though, hardcoding number of jobs into debian/rules still seems badly planned. it certainly means prevu is much less handy ootb in my environment, since I now have to manually unpack all the source packages and edit the debian-rules manually.
[20:00] <unit3> or, at least, that's how I'm reading this.
[20:00] <jdong> unit3: no no, your environment has DEB_BUILD_OPTIONS="parallel=3" or something
[20:00] <unit3> Oh! I see.
[20:00] <maxb> unit3: prevu is a simplified wrapper around pbuilder.  pbuilder is a means to invoke dpkg-buildpackage in a minimal clean environment.
[20:00] <jdong> and debian/rules is responsible for parsing out parallel=3 into -j3
[20:00] <unit3> and then debian/rules handles it.
[20:00] <unit3> if appropriate.
[20:00] <jdong> right
[20:00] <unit3> Gotcha.
[20:01] <unit3> That makes so much more sense. :)
[20:01] <jdong> that's what the snippet of makefile under 4.9.1 is for :)
[20:01] <unit3> Ahhh.
[20:01] <unit3> Ok, I'll try that. Hopefully mysql builds in parallel, because it takes a really long time on my system without the build cluster to help. ;)
[20:01] <jdong> that it does :)
[20:01] <jdong> kernels, too.
[20:02] <unit3> Awesome. :)
[20:02] <unit3> I've got about 6-8 faster cores I can use via icecc, so I'd like to. ;)
[20:04] <directhex> 8 cores?
[20:05] <unit3> directhex: on multiple machines, available via icecc. hence the need for parallel job processing.
[20:05] <jdong> pfft don't provoke directhex
[20:05] <jdong> he'll pull out his 9000000 core itaniums
[20:05]  * directhex fluffles jdong
[20:05] <unit3> hahahaha
[20:05] <directhex> jms@orac:~> grep -c ^processor /proc/cpuinfo
[20:05] <directhex> 256
[20:05] <jdong> what did I just tell you?
[20:05] <unit3> oh man. I wish. no, I'm using consumer grade amd64 stuff.
[20:05] <directhex> and yet gnome still runs like a dog ;)
[20:06] <unit3> hahahaha
[20:06] <unit3> switch out metacity for xfwm. your system will thank me. ;)
[20:06] <directhex> and it's crap for x264 dvd ripping
[20:06] <unit3> why? too many optimizations for x64 in x264's codebase?
[20:06] <directhex> more or less
[20:07] <unit3> 'cause otherwise I'd expect it to just scale through the roof, so that's too bad.
[20:08] <jdong> it doesn't scale to more than 4 or so threads well does it?
[20:08] <jdong> I always felt x264 did much better with one core twice as fast than two cores the same speed.
[20:08] <unit3> I thought they showed it scaling up to 8 at least on the new core i7 stuff?
[20:10] <jdong> it barely scales well to 4 on a core 2 quad I tested.
[20:10] <directhex> unit3, it scales well on i7 :)
[20:11] <jdong> it was very much margin of diminishing returns for me...
[20:11] <directhex> unit3, well... except it doesn't fill the hyperthreads, but that's not news
[20:11] <directhex> HT in "sucks" shocker
[20:11] <unit3> yeah.
[20:11] <unit3> But I thought part of the benchmarks I saw indicated that that just showed that i7 scales better than core 2 does in general, and that x264 will scale well if the arch lets it.
[20:12] <directhex> nothing scales like itanic
[20:14] <jdong> unit3: does it really scale better than having one or two cores under the +300MHz IDA boost?
[20:14] <unit3> directhex: yeah? I'd be curious to see how something like luxrender scales on it, then...
[20:14] <unit3> jdong: dunno, tracking down the benchmarks I saw before to try and determine that, since I don't remember well enough.
[20:14] <directhex> most people don't want scalability, they want throughput.
[20:14] <directhex> where clocks can often win
[20:15]  * jdong agrees
[20:15] <unit3> true.
[20:15] <unit3> but only at the bottom end.
[20:15] <unit3> of course, the bottom end is huuuuge now. ;)
[20:15] <jdong> I still feel if you're talking your average person doing X264 encodes, 2 faster cores is better than 4 not-as-fast ones.
[20:15] <unit3> computing: now with more junk in the trunk!
[20:15] <jdong> scalability is a different topic.
[20:15] <jdong> doesn't x264 still slice the image in some arrangement to thread?
[20:16] <unit3> jdong: no, I seem to recall it was more comprehensive than that, and tried to look at thread count and stuff.
[20:16] <jdong> i.e. somewhat reduced PSNR?
[20:17] <directhex> jdong, don't forget i7 is faster per clock than anything else
[20:18] <unit3> true too.
[20:18] <jdong> absolutely is.
[20:18] <directhex> trust me :)
[20:18] <unit3> I think I was thinking of these two: http://arstechnica.com/hardware/reviews/2008/11/nehalem-launch-review.ars/9 http://arstechnica.com/hardware/reviews/2008/11/nehalem-launch-review.ars/6
[20:18] <directhex> directhex@desire:~$ grep name /proc/cpuinfo | tail -1
[20:18] <directhex> model name	: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz
[20:18] <unit3> Which shows i7 scaling well with more threads in another test.
[20:18] <unit3> but also a little more oomph using 8 threads with HT than 4 threads and no HT.
[20:18] <unit3> So inconclusive I guess.
[20:19] <unit3> You'd want to get a system with 2x4core nehelem xeons or something and bench with threads from 4-16
[20:20] <unit3> Meh. Once a mobo+cpu combo is < $300 I'll upgrade my desktop to i7, but I imagine that won't be for a while.
[20:22] <jdong> unit3: you're thinking the core i5.
[20:23] <unit3> jdong: huh? I thought i7 was just branding for the desktop version of nehelem?
[20:23] <jdong> unit3: the core i5 is an upcoming consumerization of the nehalem
[20:23] <jdong> should bring prices way down into the current core 2 ranges
[20:24] <jdong> unfortunately you're not gonna get your nerdcore 24xSLI whatnot gaming leet card slots
[20:24] <jdong> but you can build yourself a nehalem architecture machine without selling a kidney
[20:24] <directhex> only dual-channel ram though :'(
[20:24] <directhex> laaaaame!
[20:24] <unit3> that's fine.
[20:24] <jdong> *cough* :)
[20:24] <unit3> I never even max out my RAM on my home desktop.
[20:24] <directhex> Mem:          5974       5938         35          0         25       5081
[20:24] <unit3> and DDR3's still expensive.
[20:25] <unit3> erm RAM bandwidth that is, I totally max out RAM usage. ;)
[20:25] <unit3> yeah, looks like i5 is what I'll be after for home, and then the Xeon i7 stuff for work once it's a little cheaper.
[20:25] <jdong> unit3: that's how I figure.
[20:26] <jdong> I would like to be able to justify to myself building a xeon mac pro like workstation
[20:26] <jdong> but umm... never worked out.
[20:26] <unit3> yeah, me too, but not in this recession. contract work to buy toys is pretty hard to come by right now. :P
[20:26] <jdong> you know I have the money, just don't feel THAT is what I should dump it on.
[20:26] <jdong> hwoever, IMO in this economy rainy day bank money is a bad thing to keep.
[20:27] <jdong> just watching it lose its value is depressing.
[20:28] <unit3> heheh
[20:28] <geser> the question is what will lose value faster: your desktop or your bank money
[20:28] <unit3> I guess it depends on where you're keeping it.
[20:28] <unit3> yeah, computers generally depreciate the fastest.
[20:33] <e-jat> Successfully uploaded packages.
[20:33] <e-jat> Not running dinstall.
[20:33] <e-jat> anyone can help me?
[20:33] <jpds> e-jat: That sounds fine, are you loading to revu?
[20:34] <e-jat> my ppa
[20:49] <e-jat> jpds: uploaded to revu
[20:50] <jpds> e-jat: What exactly was your problem?
[20:51] <e-jat> not running dinstall .. sorry.. its my 1st package ..
[20:51] <jpds> That's not a problem, you can ignore that message. :)
[20:52] <e-jat> jpds: owh ok .. thanks ..
[20:52] <e-jat> hoping/waiting that someone will comment about it .. so i can learn from my mistake ..
[21:01] <hyperair> e-jat: i've received that message for every upload i've made, and i still haven't figured out what it means ;)
[21:02] <e-jat> owh ..
[21:02] <hyperair> jpds: do you know what it means? =\
[21:02] <hyperair> i mean what's dinstall for?
[21:03] <broonie> When uploading to Debian it used to be possible to run dinstall, the tool that processed uploads, by hand to check that the package was acceptable to dinstall.
[21:03] <broonie> So dput has the ability to do that automatically when uploading via SSH.
[21:03] <hyperair> i see
[21:09] <unit3> heh, my backport of mysql failed yesterday, and now I see in the build that the test which failed is marked as "[ disabled ]  randomly fails on Ubuntu amd64 buildds".
[21:09] <unit3> Good to know. :)
[21:31] <blizzkid> lo all. Screen resolution on my EEE900 dropped to 800 by 600 after today's upgrade, and no option of 1024 by 600. Any idea how I can get it back?
[22:06] <blizzkid> noone any idea about the resolution?
[22:06] <ajmitch> ask in #ubuntu, or #ubuntu+1 if you're using jaunty
[22:07] <blizzkid> ajmitch: it's jaunty, it was fine until todays upgrade
[23:02] <unit3> Heh... went to all this work backporting the jaunty mysql-server-5.1 packages to hardy, and they don't include the mysql-cluster / ndb stuff.
[23:02] <unit3> Can someone clue me in what's going on with 5.1 in Ubuntu, since packages says MOTU is maintaining that one?
[23:03] <savvas> gfax: Depends: libgnomeprint2.2-0 (< 2.18.6) but 2.18.6-1 is to be installed.
[23:03] <savvas> is anyone working on this?
[23:04] <ScottK> unit3: #ubuntu-server is a better channel to ask mysql stuff.
[23:04] <unit3> oh ok. will do.
[23:04] <unit3> Just looked here first since it had MOTU stamped on it. ;)
[23:05] <ScottK> Reasonable enough.
[23:08] <Laney> savvas: does it just need a rebuild?
[23:08] <savvas> Laney: I'm checking it right now :)
[23:09] <savvas> Laney: should I file a bug? I'm one button away :P
[23:09] <Laney> find out!
[23:09] <savvas> ok :)
[23:14] <savvas> libgnomeprint2.2-0 (>= ${misc:libgnomeprint-upversion}), libgnomeprint2.2-0 (<< ${misc:libgnomeprint-next-upversion})
[23:14] <savvas> Laney: yes, I think it does, should I make a quick ppa test build?
[23:14] <Laney> why ppa?
[23:14] <Laney> don't you have pbuilder?
[23:15] <savvas> I do but.. the logs include more info
[23:15] <savvas> ok, pbuilder it is :)
[23:29] <savvas> Laney: works on amd64! :) rebuilt and runs fine: http://paste.ubuntu.com/130391/ http://paste.ubuntu.com/130393/
[23:30] <Laney> cool
[23:30] <Laney> I'll upload a rebuild
[23:30] <savvas> thanks
[23:40] <Laney> done, thanks for investigating
[23:47] <bcurtiswx> hi all, i followed dholbachs youtube packaging tutorials and got to the debuild stage but it failed... since this is my first time building a package, would someone mind helping me troubleshoot the errors?
[23:53] <nhandler> bcurtiswx: Could you pastebin the output?
[23:56] <savvas> friday the 13th again hehe :p
[23:56] <nhandler> savvas: I still have a few more hours ;)
[23:56] <Laney> I donated my 13th pint of blood yesterday....
[23:57] <bcurtiswx> hi all, sorry i got disconnected, did anyone reply to my debuild debugging request
[23:57] <savvas> nhandler: the funny thing is that it was friday the 13th last month too :)
[23:57] <nhandler> bcurtiswx: I did. Could you pastebin the output?
[23:58] <nhandler> savvas: I noticed that. We also have Pi Day coming up
[23:58] <bcurtiswx> nhandler: instead of in the channel, may i PM you?
[23:58] <nhandler> bcurtiswx: That is fine. But please pastebin the output instead of sending it all in /msg's
[23:59] <maxb> Though other people may also try to help if you keep things in the channel.
[23:59] <nhandler> That is true
[23:59] <nhandler> It also allows other users to learn from the problem
[23:59] <bcurtiswx> ok, i will keep in chan.. sorry if this is a dumb ?, but what is pastebin


[00:02] <jcastro> hey asac/fta
[00:02] <jcastro> if we're shipping google gmail and cal prism stuff
[00:02] <jcastro> wouldn't it make sense to bundle offline support (gears) with that?
[00:03] <asac> jcastro: whats the license of that?
[00:04] <fta> i wanted to do that more than a year ago
[00:04] <jcastro> bsd afaict
[00:04] <fta> i don't remember what stopped me
[00:04] <jcastro> http://code.google.com/p/gears/
[00:05] <asac> so thats a xulrunner extension ?
[00:05] <jcastro> because I just set up gears with fta's 3.5 package, and it's pretty awesome
[00:05] <asac> jcastro: can you copy the extension into xulrunner-addons and flip the targeta pplication to<EMAIL_ADDRESS>[00:05] <asac> and then see if it just works?
[00:05] <jcastro> yeah it's an extensiion
[00:06] <asac> jcastro: or give me the xpi ;) ... they dont offer it to me
[00:07] <asac> as i run trunk ;)
[00:08] <asac> gears-read-only/gears/test/testcases/testaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.txtfoo
[00:08] <asac> heh
[00:08] <jcastro> http://dl.google.com/gears/current/gears-linux-opt.xpi
[00:08] <jcastro> how's that?
[00:11] <fta> so many third_parties in the source tree :P
[00:11] <asac> jcastro: http://people.ubuntu.com/~asac/tmp/gears.tgz
[00:12] <asac> unpack that in /usr/lib/xulrunner-addons/extensions/
[00:12] <jcastro> ok
[00:12] <asac> and check whether it "just works" ;)
[00:12]  * asac  installs prism-gmail
[00:12] <jcastro> ok, one moment
[00:12] <asac> jcastro: oh. also touch /usr/lib/xulrunner-1.9.0*/.autoreg
[00:13] <fta> asac, do you want to just ship a repackaged xpi blob? or build it from source?
[00:13] <asac> hmm.
[00:13] <asac> fta: obviously from source
[00:13] <asac> its just for testing
[00:13] <fta> k
[00:13] <asac> not sure how offline would work in prism ;)
[00:13] <asac> guess prism could deserve a offline switch
[00:14] <asac> fta: is there a way to access about:config ?
[00:14] <asac> jcastro: does that work on amd64 at all?
[00:14] <asac> or just 32 bits?
[00:14] <jcastro> I am 90% sure it does not
[00:14] <jcastro> it's 32 bit only
[00:14] <asac> heh
[00:14] <asac> ok
[00:14] <asac> so my test failed
[00:14] <jcastro> I am on 32 bit
[00:15] <jcastro> one moment
[00:15] <asac> jcastro: try it then
[00:15] <asac> jcastro: howveer for setting to offline we might need a trick
[00:15] <asac> hmm ... i guess network-manager _should_ work
[00:15] <fta> nspluginwrapper
[00:15] <jcastro> well, the gmail will tell me if it works
[00:15] <asac> that doesnt work for extensions ;)
[00:15] <asac> jcastro: how?
[00:15] <asac> :)
[00:16] <asac> jcastro: you can check whether the extension is properly setup in the bottom right menu of prism
[00:16] <jcastro> you click the button and if it doesn't work it tells you you can't go offline
[00:16] <asac> there you can access tools -> addons
[00:16] <fta> http://groups.google.com/group/gears-users/browse_thread/thread/4584842dd14a4882
[00:16] <asac> well. the source seems to come with full v8 and so on ;)
[00:16] <asac> gears-read-only/third_party/v8/bindings_local/v8_np_utils.h
[00:16] <asac> thats ridiculous ;)
[00:17] <asac> grant-google-svn
[00:17] <asac> grand
[00:17] <fta> $ du -sm gears-read-only
[00:17] <fta> 670     gears-read-only
[00:17] <asac> what a mess
[00:18] <fta> i think that's what stopped me
[00:18] <jcastro> haha
[00:18] <asac> jcastro: so from here i would say its afe to say, that this wont happen for jaunty ;)
[00:18] <jcastro> asac: !!!! it worked!
[00:18] <jcastro> asac: oh no dude, I was thinking ppa
[00:18] <asac> jcastro: cool. thats good news at least ;)
[00:19] <fta> http://paste.ubuntu.com/142406/ pfff
[00:19] <asac> at some point ppa folks will hunt us down for putting tera-bytes of sources in it ;)
[00:19] <jcastro> asac: I was just thinking that 3.5+gears in a ppa for laptop users for gcal/gmail would be sweet
[00:20] <asac> jcastro: i think we should write a simple how to
[00:20] <jcastro> ok
[00:20] <jcastro> what did you do to make that tgz?
[00:21] <asac> and ppa when we manage to figure out the packaging
[00:21] <asac> jcastro: magic ;)
[00:21] <asac> jcastro: poked install.rdf
[00:21] <asac> and created a proper top level dir
[00:21] <asac> matching the extension id
[00:21] <jcastro> ah, I saw people doing that on blogs
[00:22] <asac> not sure if they poked it the way i did though
[00:22] <asac> i will look if its submit worthy
[00:22] <asac> maybe we can make it "just" work with upstream .xpis
[00:22] <asac> jcastro: do we know anthing about gears release cycle?
[00:23] <asac> update-cycle actually
[00:23] <jcastro> nope
[00:23] <asac> good :-P
[00:23] <jcastro> let me hunt down stuff
[00:23] <asac> nah. no need to
[00:23] <asac> if it makes sense we should submit the generic install.rdf i guess
[00:24] <jcastro> I know they keep a copy of it in chromium
[00:26] <asac> some captchas are really ridiculous
[00:44] <fta> lp is back
[00:45] <asac> thats too late for me ;)
[00:45] <asac> i am down
[00:45] <asac> :-P
[00:45] <asac> cu
[00:47] <fta> cu
[00:50] <Jazzva> asac: rev 52 pushed. I'll ask for merge so you can see it when you get up :)
[00:59] <fta> armin76, did you fix that on sparc? http://paste.ubuntu.com/142423/
[01:01] <asac> Jazzva: its not there yet
[01:02] <asac> Jazzva: you forgot to push as it seems
[01:02] <asac> even ssh doesnt have it
[01:02] <Jazzva> asac: No new revisions to push.
[01:03] <Jazzva> maybe it's LP lag or something...
[01:03] <Jazzva> hmm... I suppose it will be visible soon :/
[01:03] <asac> https://code.edge.launchpad.net/~jazzva/nspluginwrapper/ubuntu.1.2.2-0ubuntu3?
[01:03] <Jazzva> yep, that's the one
[01:04] <asac> really odd. i go through bzr+ssh ... whihc accesses a not mirrored machine i think
[01:04] <Jazzva> asac: http://paste.ubuntu.com/142428/
[01:05] <Jazzva> that's what I get on "bzr push"
[01:05] <asac> bzr log -l1 ;)
[01:05] <asac> is that 52?
[01:05] <Jazzva> http://paste.ubuntu.com/142429/
[01:06] <Jazzva> yep
[01:10] <asac> so no luck today
[01:10] <asac> guess "code" didnt like the maintenance today
[01:10] <asac> Jazzva: can you paste the diff?
[01:10] <asac> ;)
[01:10] <Jazzva> umm, sure
[01:10] <asac> i mean the latest patch ;)
[01:11] <Jazzva> -r52..50?
[01:11] <Jazzva> I think you have the rev 50
[01:11] <asac> that or just the .diff of the patch
[01:11] <asac> the rest is probably good ;)
[01:12] <asac> i mean cat debian/patches/yourpatch.diff | pastebinit
[01:12] <Jazzva> yeah, just reworded changelog :)
[01:12] <Jazzva> oh, also edit to the Makefile, to include glib for npw-config.c
[01:13] <asac> oh that wasnt there. hmm
[01:13] <asac> well.
[01:13] <asac> we can also look tomorrow
[01:13] <asac> maybe the push made it through by then ;)
[01:13] <asac> cu. and thanks!
[01:14] <Jazzva> asac: no problem, sorry for the delay :)
[01:14] <asac> if we still can gt that fixed in jaunty, the world will be better
[01:14] <asac> not your fault ;)
[01:14] <Jazzva> here's the paste in case you want to inspect
[01:14] <Jazzva> http://paste.ubuntu.com/142435/
[01:14] <Jazzva> I guess this can make it to jaunty
[01:16] <asac> Jazzva: GLIB_CFLAGS + GLIB_LDFLAGS dont work?
[01:16] <asac> i guess we should use those there
[01:17] <Jazzva> Umm... not sure, I just tried to copy what npw developers used for other npw-*.c files
[01:18] <asac> ok. if they use that for glib its probably fine
[01:19] <asac> Jazzva: they also use GLIB_CFLAGS and _LDFLAGS
[01:19] <Jazzva> asac: hmm, I'll check
[01:20] <asac> ok.const char **dirs = malloc((n_default_dirs + n_env_dirs + 2) * sizeof(dirs[0]));
[01:20] <asac> shouldnt that be env_dirs[0] ?
[01:22] <Jazzva> asac: I left what he used before. And sizeof(dirs[0]) will be sizeof(char *), just as size of(env_dirs[0]) (which is gchar *, which is the same as char *) IIRC
[01:23] <asac> ok. wonder why he just doesnt do char* but ok
[01:24] <Jazzva> I wondered that too
[01:24] <asac> i mean it dereferences an unintialized pointer somewhat
[01:24] <asac> meaning: *0xRANDOM
[01:24] <asac> of course sizeof isnt runtime
[01:25] <asac> ;)
[01:25] <Jazzva> asac: Well, we can always change that and submit upstream :)
[01:25] <asac> Jazzva: i think we should cache the split array in the get_ function
[01:25] <Jazzva> though, I think this way works too (though, a little bit confusing :))
[01:25] <asac> its const char
[01:26] <asac> so folks shouldnt free it and we can reuse it
[01:26] <Jazzva> ok
[01:26] <asac> Jazzva: or does get_mozilla_plugin_dirs cache things?
[01:26] <asac> if not dont bother
[01:27] <asac> it leaks mem anyway then.
[01:28] <asac> i will check the bzr branch tomorrow in detail
[01:28] <asac> cu
[01:28] <Jazzva> ok, cu
[10:04] <fta> asac, https://code.edge.launchpad.net/~fta/+junk/ppa-confs
[10:06] <armin76> fta: i haven't tried 1.9.1 on sparc lately, so haven't seen that
[10:10] <fta> armin76, according to http://popcon.ubuntu.com/, we just have 39 sparc users
[10:10] <fta> so, well...
[10:10] <fta> *sigh*
[10:18] <armin76> :D
[10:19] <asac> armin76: you are lacking and slacking ;)
[10:19] <asac> bundle your sparc builders to our daily build;)
[10:19] <fta> lol
[10:19] <asac> gentoo dailies
[10:20] <fta> armin76, https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
[10:25]  * armin76 yawns
[10:36] <fta> asac_, https://edge.launchpad.net/ubuntu/jaunty/+queue?queue_state=0&queue_text=firefox  ???
[10:37] <asac_> fta: yeah we pushed it in
[10:38] <asac> https://edge.launchpad.net/ubuntu/+source/firefox-3.5/3.5~b4~hg20090330r24021+nobinonly-0ubuntu1
[10:39] <fta> fta@ix:~ $ apt-cache madison firefox-3.5
[10:39] <fta> firefox-3.5 | 3.5~b4~hg20090401r24201+nobinonly-0ubuntu1~umd1 | http://ppa.launchpad.net jaunty/main Packages
[10:39] <fta> firefox-3.5 | 3.5~b4~hg20090330r24021+nobinonly-0ubuntu1~fta1 | http://ppa.launchpad.net jaunty/main Packages
[10:39] <fta> firefox-3.5 | 3.5~b4~hg20090330r24021+nobinonly-0ubuntu1 | http://archive.ubuntu.com jaunty/universe Sources
[10:39] <fta> firefox-3.5 | 3.5~b4~hg20090330r24021+nobinonly-0ubuntu1~fta1 | http://ppa.launchpad.net jaunty/main Sources
[10:39] <fta> firefox-3.5 | 3.5~b4~hg20090401r24201+nobinonly-0ubuntu1~umd1 | http://ppa.launchpad.net jaunty/main Sources
[10:39] <fta> can't see the bins
[10:40] <fta> i thought they were still in the NEW bin queue
[10:40] <asac> fta: they are waiting for a publisher run most likely ;)
[10:40] <asac> we bin NEWed them not long ago
[10:41] <fta> ok
[10:41] <asac> 40 minutes
[10:41] <asac> probably just missed that run
[10:41] <fta> strange i didn't get any email for that whole thing
[10:42] <asac> fta: you get a NEW in the beginning thats it
[10:42] <asac> we dont send any "now NEWed" mails
[10:42] <asac> irritating, but known :)
[10:48] <fta> didn't get the initial, accepted but delayed for approval, as usual
[10:48] <fta> strange
[11:09] <BUGabundo> guud morning
[11:14] <fta> firefox-3.5 | 3.5~b4~hg20090330r24021+nobinonly-0ubuntu1 | http://archive.ubuntu.com jaunty/universe Packages
[11:14] <fta> good, it's in
[11:14] <BUGabundo> yay
[11:14] <BUGabundo> \o/
[11:40] <asac> jcastro: does epiphany also have gears for you now?
[14:30] <jcastro> asac: nope, doesn't work there
[14:33] <asac> jcastro: running epiphany-gecko?
[14:33] <asac> maybe you are on -webkit?
[14:33] <asac_the_bumber> ricing!
[14:33] <jcastro> nope, gecko
[14:34] <asac> k
[14:34] <jcastro> I don't see why it would work, it's a firefox extension?
[14:34] <asac_the_bumber> i bumb!
[14:35] <asac_the_bumber> asac: you guys bumb hppa to?
[14:35] <asac_the_bumber> too?
[14:36] <asac> hppa is ready for action for us
[14:36] <asac> jcastro: its a xulrunner extension
[14:36] <asac> ephy runs xulrunner
[14:38] <armin76> asac: [reed]: under which category should i fill bugs about the configure file?
[14:41] <armin76> oh, nvm
[14:42] <Jazzva> asac: I'll set char *'s as const and push a new revision. Then you can release it :)
[14:42] <Jazzva> (that is if you reviewed everything else
[14:44] <jtv> asac: good news for you—I worked up a sweat last night and fixed all those unreported exceptions with the XPI imports.  Fix is waiting for review.
[14:50] <asac> jtv: great
[15:04] <Jazzva> asac: I pushed up to rev 54 https://code.edge.launchpad.net/~jazzva/nspluginwrapper/ubuntu.1.2.2-0ubuntu3/+merge/5140
[15:06] <asac> Jazzva: use GLIB_LDFLAGS too please
[15:06] <asac> Jazzva: also have you checked that get_plugin_dirs is run just once?
[15:06] <asac> otherwise we should cache it
[15:06] <asac> and dont do the env parsing over and over again
[15:10] <Jazzva> asac: you mean instead of GTK_LDFLAGS?
[15:12] <Jazzva> asac: I think it's called only once, AFAICS from the code. It's called only to get the list and then it just iterates through it (in auto_{install,remove,update}_plugins and process_list)
[15:14] <asac> Jazzva: yes
[15:14] <asac> Jazzva: ok.
[15:15] <asac> but fixing GLIB_LDFLAGS makes more sense for what we are trying to do
[15:15] <Jazzva> asac: fixing? what do you mean?
[15:16] <asac> Jazzva: using it ;)
[15:16] <Jazzva> asac: instead of GTK_CFLAGS? just checking if I understood correctly
[15:16] <Jazzva> *GTK_LDFLAGS
[15:17] <asac> yes
[15:17] <Jazzva> ok
[15:17] <Jazzva> I'm running a test build
[15:19] <Jazzva> asac: done, pushed
[15:20] <asac> ok rejected the previous merge
[15:21] <Jazzva> and proposed a new one for rev 55 :)
[15:21] <Jazzva> https://code.edge.launchpad.net/~jazzva/nspluginwrapper/ubuntu.1.2.2-0ubuntu3/+merge/5142
[15:22] <asac> odd ... there is no diff :(
[15:22] <asac> maybe that takes a bit to generate?
[15:22] <Jazzva> hmm, it's generated now
[15:22] <Jazzva> http://bazaar.launchpad.net/~jazzva/nspluginwrapper/ubuntu.1.2.2-0ubuntu3/revision/55
[15:23] <asac> no look at the other merge page
[15:23] <asac> you can review the diff directly there
[15:23] <asac> its not visible on the new merge for unknown reasons
[15:23] <Jazzva> where should it be on that page?
[15:25] <Jazzva> ok, just to change UNRELEASED to jaunty in changelog
[15:26] <Jazzva> I forgot to do that
[15:28] <Jazzva> asac: https://code.edge.launchpad.net/~jazzva/nspluginwrapper/ubuntu.1.2.2-0ubuntu3/+merge/5143 sorry for the reproposal
[15:28] <asac> Jazzva: hold on :) ... so *count = 0 is missing i guess
[15:29] <asac> depending on having that set to 0 is not good i think
[15:30] <Jazzva> asac: int n_env_dirs = 0;
[15:30] <Jazzva> asac: const gchar **env_dirs = get_env_plugin_dirs(&n_env_dirs);
[15:31] <Jazzva> I just thought it shouldn't be the get_env_plugin_dirs' job to  set that to 0, since I'm passing it as a parameter. But in this case it wouldn't change anything if it was reset there to 0.
[15:31] <asac> yes the problem is inside the get_env_plugin_dirs
[15:31] <asac> you shouldnt depend on whatever the caller sets
[15:31] <asac> so just int n_dev_dirs; is enough
[15:32] <Jazzva> aha... so to set it inside the get_env?
[15:32] <asac> its best practices that the caller doesnt need to set the value for call by reference. caller is only responsible that the mem is allocated
[15:32] <asac> Jazzva: right
[15:32] <Jazzva> mhm... ok
[15:32] <asac> Jazzva: so what caller has to do is:
[15:32] <asac> int *n_dev_dirs = malloc (sizeof (int));
[15:33] <asac> or (int n_dev_dirs;) of course
[15:33] <Jazzva> yeah, the second is already there, and then get_env...(&n_env_dirs)
[15:40] <Jazzva> asac: https://code.edge.launchpad.net/~jazzva/nspluginwrapper/ubuntu.1.2.2-0ubuntu3/+merge/5146
[15:45] <asac> Jazzva: merged
[15:46] <asac> pushed
[15:46] <Jazzva> asac: noticed, thanks :)
[15:46] <Jazzva> I'll mark branch as merged... or is that done automatically...
[15:47] <asac_the_bumber> bumb!
[15:49] <thunderstruck> oh what the fuck
[15:52] <asac> Jazzva: should be automatically i think
[15:56]  * asac_the_bumber has patches, asac doesn't
[16:25] <gnomefreak> asac: what version of pango is used in TB3 and FF 3.5 3.6?
[16:25] <asac> gnomefreak: the current version
[16:26] <gnomefreak> 1.24?
[16:27] <gnomefreak> makes me wonder why they dont fail to build since it is a core bug
[16:28] <gnomefreak> this is the upstream patch https://bug478871.bugzilla.mozilla.org/attachment.cgi?id=369648
[16:29] <asac> bug 197911 bug 195698
[16:47] <gnomefreak> anyone getting keyring errors in Gwibber?
[16:48] <gnomefreak> looks like it froze now
[16:50] <gnomefreak> its nokeyringdaemonerror  when trying to retrieve messages and replies
[16:51] <gnomefreak> and it keeps crashing
[17:09] <Mirv> Was there a reason http://bazaar.launchpad.net/~asac/ubufox/main/revision/141.1.1 resetted browser.throbber.url and app.update.url.details to the English version instead of localized ones? No in Jaunty only English is shown even though localized versions would be there. (when offline)
[17:13] <asac> Mirv: which language was reset?
[17:15] <Mirv> asac: all that had the localized version in use before that commit, eg. fi, lt. In the bug report the changes are claimed to come from, I submitted a tarball that did use the localized version URL.
[17:15] <Mirv> I now wrote details at https://bugs.launchpad.net/ubuntu/+source/ubufox/+bug/353924
[17:16] <Mirv> In that commit, all files under "files modified" title are the same: release notes changed to 810 and URLs resetted from the localized ones to the English one (even if in the bug report #283517 localized URLs would have been offered)
[17:17] <asac> seems to be a bug
[17:17] <asac> seems lots of translations were added
[17:17] <asac> and the modified ones have regressions
[17:17] <asac> but not all
[17:17] <asac> actually havent found any other language than FI ;)
[17:18] <asac> bug 283517
[17:18] <Mirv> pt-BR, lt, uk, cs_CZ
[17:19] <asac> Mirv: those are already in intrepid, arent they?
[17:19] <Mirv> el_GR, it_IT, ru_RU, sl_SI, sv_SE. and that fi.
[17:20] <asac> https://bugs.edge.launchpad.net/ubuntu/+source/ubufox/+bug/283517/comments/6
[17:20] <asac> isnt that what we have now?
[17:20] <asac> hmm
[17:20] <asac> seems saivvan didnt do it right
[17:20] <Mirv> asac: probably. I think I never checked if that bug was really fixed for intrepid, since normally I am not offline :)
[17:20] <asac> but those should be in intrepid or is it just jaunt?
[17:21] <Mirv> let me check with my intrepid to make sure
[17:22] <asac> seems we have to rereview that commit
[17:22] <asac> and fix regressions
[17:22] <asac> but tomorrow
[17:22] <asac> have to run
[17:22] <Mirv> interesting, looks like it works in intrepid for some reason or another
[17:24] <asac> it ws committed before 0.6 final
[17:24] <asac> which should be what we have in intrepid
[17:25] <Mirv> I'll check it a bit more
[17:25] <asac> Mirv: maybe intrepid still has the alternative which is right for you for fi
[17:25] <asac> so in theory you would always get fi even if you used one of the other languages that point to that generic path now
[17:29] <Mirv> asac: in intrepid the starpage.html constructed the URL by itself
[17:30] <Mirv> so that's why the URLs in ubufox.properties did not matter. somehow that same thing doesn't now work in jaunty
[17:31] <asac> good point
[17:31] <Mirv> and it's probably related to http://bazaar.launchpad.net/~asac/ubufox/main/revision/149 somehow ("drop localizable general.useragent.locale pref from ubuntu-mods.js to unbreak mozilla usage stats")
[17:31] <asac> i will check that
[17:32] <asac> yeah. i have to check
[17:32] <asac> thought i fixed everything
[17:32] <Mirv> there is some code still there, but it doesn't work at the moment
[17:32] <Mirv> ok, thans
[17:32] <Mirv> +k
[17:32] <gnomefreak> asac: where is the profile kept for gwibber? i dont see a .gwibber
[17:32] <asac> gnomefreak: have to run
[17:32] <asac> i would think there
[17:32] <asac> or in .gnome2/gwibber
[17:32] <asac> or in .config/gwibber
[17:33] <gnomefreak> ok ill look
[17:37] <gnomefreak> its .gconf/apps/gwibber/ and its not being very helpful
[17:53] <BUGabundo_> hey
[17:53] <BUGabundo_> asac ping
[17:55] <BUGabundo_> asac https://bugs.edge.launchpad.net/ubuntu/+source/mobile-broadband-provider-info/+bug/353957
[17:56] <BUGabundo_> bye
[18:22] <Mirv> asac: ok added some more details to bug #353924 ... it seems there is zero way in jaunty to get the user's language otherwise than Accept-Language HTTP header, since everything is hard-coded to en-US.
[18:23] <Mirv> I believe it also breaks all pages that expect to show correct language via javascript instead of PHP
[18:25] <Mirv> I now reopened bug #117915
[19:55] <asac> Mirv: i have attached a patch. you can just apply it after apt-get source ubufox and build with debuild -b
[20:07] <jcastro> asac: hey so sorry I dropped out early last night, what was the plan as far as prism/gears? (I am assuming you have no time to look at it until past release)
[20:07] <asac> jcastro: yeah. we can investigate then. just wondered if it works for epiphany too now that you installed it in system xulrunner
[20:07] <jcastro> yeah it definately doesn't
[20:07] <asac> but you already denied it ;)
[20:08] <asac> i will check with the prism guy then if he did something to make this happening
[20:08] <jcastro> asac: I am unsure if it would make sense to ship it with xulrunner unless one installs a prism app
[20:08] <jcastro> so like, only install it if I install prism-google-mail or something
[20:08] <asac> jcastro: i need to figure out if it would work in all xulapps
[20:09] <asac> epiphany is a bit special because its not a xulapp, but rather just an embedder
[20:09] <asac> jcastro: it would be a separate package for sure
[20:10] <jcastro> right
[20:10] <asac> i will dig out a simple browser xulapp for you to check ;)
[20:11] <Mirv> asac: tried the patch, does not seem to help. did you read the updated description? it's en-US everywhere, so there's not much to get something else out of
[20:11] <jcastro> asac: I think this whole thing is FF specific tbh
[20:12] <asac> Mirv: you sure you didnt manually tweak your preferred lanaguages list in firefox?
[20:12] <asac> e.g. the one in preferences -> content
[20:12] <asac> jcastro: well. prism doesnt have much with firefox in common ;)
[20:13] <asac> at least not more than any other xulapp ;)
[20:13] <Mirv> asac: there is Finnish (fi) first, English (en) second...
[20:13] <jcastro> asac: ah ok, fair enough
[20:13] <Mirv> asac: I have touched those, though
[20:14] <Mirv> asac: I also tried with mv .firefox test
[20:14] <Mirv> .mozilla, that is
[20:14] <asac> Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefBranch).getCharPref("general.useragent.locale")
[20:14] <asac> Mirv: can you run that in tools -> error console please
[20:14] <asac> (e.g. hit clear first)
[20:15] <Mirv> asac: en-US
[20:16] <Mirv> also the bug report has the .html attachment which gives en-US for everything in jaunty and fi-FI in intrepid
[20:16] <asac> yeah obviously kind of sucks ;)
[20:17] <Mirv> and that's why I reopened bug #117915 now
[20:17] <asac> Mirv: err. the ubuntu starpage online works right
[20:17] <asac> hmm
[20:17] <Mirv> asac: it probably uses PHP to get Accept-Language, but it's not receivable via javascript
[20:20] <asac> so we need to fix the other bug which was made wontfix upstream because we shouldnt use the other mechanism
[20:25] <asac> Mirv:  can we close the old bug please and open a regression bug instead?
[20:26] <Mirv> asac: yes I'll do that.
[20:27] <Mirv> so what has changed since intrepid?
[20:27] <asac> Mirv: lets keep it ;)
[20:27] <asac> Mirv: we dropped localized pref for user locale
[20:28] <Mirv> so no closing of the old bug? :)
[20:29] <asac> Mirv: its fine
[20:29] <Mirv> ok.
[20:29] <asac> usually i dont like reopening old bugs
[20:29] <asac> if its a regression its a different bug
[20:29] <asac> this is different because its an upstream bug
[20:30] <Mirv> ok. I have to flee now, but good that the problem is becoming understood
[20:55] <gnomefreak> ok its fixed :)
[21:00] <[reed]> asac: upstream bug?
[21:12] <gnomefreak> asac: bug 347972 is fixed debdiff attached
[21:26] <gnomefreak> damn it
[21:26] <gnomefreak> its fixed im working out kinks in branching
[21:32] <gnomefreak> ok fixed i can go eat dinner now its already 4:30pm
[21:33] <armin76> fta: from what i can tell, that sparc failure its because its using a solaris function, yay...
[21:39] <armin76> [reed]: mozilla bug 476042 uses a solaris function, should i open a new bug or comment there?
[21:39] <[reed]> new bug
[21:39] <armin76> k, thanks
[21:39] <[reed]> mark dependencies correct
[21:39] <[reed]> etc.
[21:54] <armin76> mozilla bug 486584
[21:54] <armin76> have fun
[22:00] <fta> armin76, thanks
[22:05] <gnomefreak> asac: ok i provided a fix for the above ubufox bug, it was easy and fast so i didnt do anything else to it.
[22:06] <gnomefreak> im gone ;)
[23:06] <rzr> hi
[23:40] <fta> asac, SEAMONKEY_1_1_16_RELEASE
[23:41] <rZr> asac: i'll be back for FB tomorow k ?


[03:24] <mathod_man> Hello
[16:26] <wxl> oi you ready to partay yet elopio? :)
[16:30] <elopio> wxl: almost. But many hours left to finish the details :)
[16:30] <wxl> :)
[18:40] <wxl> elopio: we up and running yet?
[18:40] <elopio> wxl: starting the hangout...
[18:42] <jakewalker> Do I need a webcam?
[18:43] <wxl> nope, but if you want us to see your face you do XD
[18:52] <elopio> we will start in 10 minutes.
[18:52] <elopio> 8
[18:53] <wxl> jakewalker: we're not hearing you. not sure if that's intentional :)
[18:57] <elopio> for people wanting to join the video chat: https://hangouts.google.com/hangouts/_/q742z6ihg5dmfgzxfh65eyvniye
[19:05] <wxl> konrad11901: go poland! :)
[19:07] <wxl> https://www.ubuntu.com/about/about-ubuntu/conduct
[19:12] <konrad11901> wxl: that's interesting, I'll definitely take a look at it ;)
[19:12] <konrad11901> m4sk1n_: check that :)
[19:23] <wxl> oooh maybe we should make a task to sign the Code of Conduct!
[19:23] <m4sk1n_> :)
[19:23] <konrad11901> wxl: that's a good idea!
[19:23] <elopio> wxl: that would be great!
[19:23] <wxl> i'll get on that then!
[19:27] <gsilvapt> https://wiki.ubuntu.com/LoCoCouncil/Minutes/20171211
[19:28] <CMatomic> .
[19:28] <m4sk1n_> konrad11901: what should I check?
[19:29] <gsilvapt> https://community.ubuntu.com/t/ubuntu-loco-council-election-results/1948
[19:41] <ads20000> https://tutorials.ubuntu.com/ https://tutorials.ubuntu.com/tutorial/create-your-first-snap#0 (see the language-specific ones too) https://www.youtube.com/snapcraftio
[19:42] <m4sk1n_> my english is so bad XD
[19:44] <ads20000> oh are you Marcin? You're very muffled, that's all, I think
[19:44] <ads20000> If your voice was clearer on the video then we could probably understand you better!
[19:44] <m4sk1n_> my internet is also bad…
[19:45] <ads20000> Yeah fair enough, bad combination!
[19:45] <wxl> one thing that i might suggest if you're low on bandwith, turn the video off
[19:45] <ads20000> oh yeah good point
[19:45] <ads20000> sounds like Gustavo(? I don't recognize the avatar) got what you were on about before though
[19:53] <gsilvapt> ads20000, hi :)
[19:56] <ads20000> ohhh, not the Gustavo I was thinking of that makes sense xD
[19:58] <gsilvapt> Awesome, thanks for this hour guys :)
[19:59] <wxl> thank you gsilvapt
[21:25] <z3ldie> hello...
[21:25] <m4sk1n_> hi
[21:26] <z3ldie> i finally got rid of the spyware os
[21:26] <wxl> android?
[21:26] <z3ldie> and im now running sweet fresh and fast ubuntu 17.10
[21:27] <z3ldie> no windows 10
[21:27] <wxl> tjat too XD
[21:27] <z3ldie> im pretty new
[21:28] <z3ldie> for example idk where is little icon in discord
[21:28] <z3ldie> its not up, down or left
[21:33] <wxl> ?
[21:33]  * wxl doesn't use discord..


[15:24] <tracker2> #xubuntu-offtopic
[15:55] <esdwdftty> hadinfo close when i use test FPU FFT. VirtualBox guest xu, lu, u-mate(I do not remember witch mate) host win, A4-4020 report error went to the server. ~8 from 10 with this test, program closes
[15:57] <esdwdftty> version 17
[15:58] <esdwdftty> hardinfo
[16:56] <esdwdftty> every second new recording in .xsession-errors when working Indicator System Monitor. "(wrapper-2.0:1603): Gtk-WARNING **: Allocating size to GtkImage 0x55576fea5fa0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?"
[16:57] <esdwdftty> System Load Indicator 0.4
[16:57] <esdwdftty> System Load Indicator 0.4 not Indicator System Monitor
[17:21] <esdwdftty> http://www.fayloobmennik.net/6979581
[19:59] <flocculant> pleia2: http://www.dedoimedo.com/computers/xubuntu-zesty.html
[20:12] <pleia2> knome: I don't remember how to add new links to press things :D
[20:12] <pleia2> (we need a new page for 17.04)
[20:13] <pleia2> ooh, release links I think...
[20:13] <pleia2> yep, figured it out
[20:13] <knome> haha, yes
[20:13] <knome> i guess i should write some website documentation
[20:13] <knome> thought about that yesterday or so
[20:14] <knome> but sigh, writing documentation :)
[20:15] <pleia2> I didn't break /press :D
[20:15] <knome> hooray
[20:15] <knome> did you find it hard not to?
[20:15] <pleia2> replaced 16.10 with 17.04
[20:15] <knome> :)
[20:15] <knome> wasn't that easy?
[20:15] <pleia2> easy easy
[20:16] <knome> good good :)
[20:17] <pleia2> also added the 16.04 article for the eeepc that flocculant shared the other day
[20:17] <knome> thanks
[20:19] <pleia2> flocculant: thank you :)
[20:20] <flocculant> np
[20:47] <knome> pleia2, http://bazaar.launchpad.net/~xubuntu-doc/xubuntu-docs/zesty/revision/636
[20:51] <knome> slickymaster, artful docs branch created for your pleasure...
[21:30] -SwissBot:#xubuntu-devel- ::xubuntu-docs:: [zesty] r636 Add website maintenance documentation.... (by Pasi Lallinaho)


[11:20] <gubluntu> i get:
[11:20] <gubluntu> [    3.958346]  PCI: Address space collision on region 6 [000001ff00080000:000001ff000bffff]  of device 0000:00:05.0
[11:20] <gubluntu> when trying to install ubuntu sparc on my sunfire v100