[01:25] <Fujitsu> Morning all.
[01:26] <geser> Hi Fujitsu
[01:29] <jrib> hey Fujitsu
[01:29] <Fujitsu> Hi geser, jrib.
[01:45] <LaserJock> hi hi hi MOTU Land!
[01:46] <geser> Hi LaserJock
[01:48] <Fujitsu> Hi LaserJock.
[01:48] <LaserJock> Fujitsu!!
[01:48] <LaserJock> hi geser
[01:48] <LaserJock> Fujitsu: you still doing MOTU Science lists?
[01:50] <LaserJock> hi imbrandon
[01:50] <imbrandon> heya LaserJock
[01:50] <Fujitsu> LaserJock: What kind of lists?
[01:50] <Fujitsu> Hi imbrandon.
[01:50] <LaserJock> Fujitsu: the mdt and bug lists
[01:50] <Fujitsu> MDT: yes. Bugs: I don't think so... the script broke, and we can do it in the normal interface anyway.
[01:51] <Fujitsu> geser: Night.
[01:51] <LaserJock> Fujitsu: I don't like the normal interface
[01:51] <LaserJock> but that's a small thing
[01:51] <LaserJock> the mdt lists are a bigger deal
[01:51] <Fujitsu> I'll see how broken the bug thing is.
[01:51] <Fujitsu> But as far as I know mdt is still going fine.
[01:51] <LaserJock> I can make the lists, but I can't really cron it
[01:52] <LaserJock> as my server isn't running Debian/Ubuntu
[01:52] <Fujitsu> Ah.
[01:52] <Fujitsu> I was fortunately on one of the ServerPronto servers that wasn't compromised.
[01:52] <Fujitsu> We've had a pretty good security policy from the start.
[01:56] <Fujitsu> LaserJock: Back up at http://people.ubuntu.org.au/~fujitsu/motuscience/bugs/
[01:58] <LaserJock> Fujitsu: excellent
[01:59] <Fujitsu> LaserJock: Do we want to kill of scigraphica like Debian?
[01:59] <Fujitsu> *off
[02:00] <LaserJock> oh, did they finally get rid of it?
[02:00] <Fujitsu> We've only got the two nasty bugs.
[02:00] <Fujitsu> They did.
[02:00] <Fujitsu> Debian bug #438774
[02:00] <ubotu> Debian bug 438774 in ftp.debian.org "RM: scigraphica -- RoQA; unmaintained; dead upstream" [Normal,Open]  http://bugs.debian.org/438774
[02:00] <LaserJock> Fujitsu: sounds reasonable to me
[02:01] <Fujitsu> Ah, and textopo can die too, as it's replaced by texlive-science.
[04:31] <bddebian> Heya gang
[04:32] <justinwray> Hola
[04:32] <LaserJock> hola Barryson
[04:32] <bddebian> Heh, hi justinwray, LaserJock
[04:32] <Fujitsu> Hi bddebian.
[04:33] <bddebian> Heya Fujitsu
[04:33] <bddebian> Now why the heck would the binaries of jmagick end up in NEW?
[04:37] <Fujitsu> bddebian: It has never built before.
[04:38] <Fujitsu> We got it building rather then removing it? So I wasn't entirely on crack?
[04:39] <Fujitsu> tonyyarusso: `they'?
[04:41] <bddebian> Fujitsu: Yeah, even though the Debian changelog said it added a b-d for kaffe-dev, they didn't.  All I had to do was change the kaffe b-d to kaffe-dev
[04:41] <tonyyarusso> Fujitsu: archive gods
[04:45] <Fujitsu> The archive guys don't build things...
[04:45] <LaserJock> i.e. LP cron jobs
[04:51] <tonyyarusso> Fujitsu: They "approve" or some such, right?  I don't know...there's some sort of step between sitting in +queue and sitting in +builds
[05:04] <Fujitsu> tonyyarusso: Ah, they approve sources from NEW, but only if they're NEW.
[05:04] <tonyyarusso> Fujitsu: Ah.
[05:05] <tonyyarusso> Fujitsu: So then some sort of "A Okay" tag gets thrown on, and the auto-building stuff looks for that?
[05:11] <Fujitsu> tonyyarusso: The package is approved from NEW, moves to ACCEPTED, then to DONE, then the build-queuer sees it and queues builds.
[05:12] <tonyyarusso> Fujitsu: How can you view those different stages on LP ?
[05:12] <Fujitsu> tonyyarusso: /ubuntu/gutsy/+queue, the dropdown at the top.
[05:13] <tonyyarusso> Fujitsu: Ooooh (My eyes always ignore helpful dropdowns on LP for some reason - this happens a lot)
[05:13] <Fujitsu> Mhm.
[05:14] <tonyyarusso> so mine's not even accepted yet :(
[05:14] <Fujitsu> Sources can sit in new for a while.
[05:15] <tonyyarusso> Now, when things are accepted or rejected, is any sort of comment attached?
[05:16] <Fujitsu> tonyyarusso: NAFAIK
[05:23] <tonyyarusso> ok
[05:26] <ScottK> Is there a way to specify to requestsync which GPG key/email address to use?
[05:29] <tonyyarusso> Speaking of GPG keys...I could use some advice:
[05:29] <xtknight> is there a guide to making an orig.tar.gz?  do you just tar.gz up the folder into the tar?  e.g. asdf.tar.gz\asdf\[source files are here] ?  or, asdf.tar.gz\[source files are here]  (omitting redundant dir name)?
[05:29] <bddebian> You do not want the redundant sub-dir, no
[05:29] <xtknight> likewise speaking of gpg keys i was wondering what happens if you lose the key you made for yourself.  are you doomed?  (not that i did)
[05:30] <tonyyarusso> I have to use a mobile drive for school - it's a real 3.5" hard drive, installed into a removable tray, which then fits into a rack that installs into any 5 1/4" bay.  This means I can boot my systems on any computer at school.  Should I create a GPG key on there for those purposes I may use it for, or just avoid it altogether b/c of the security risk?
[05:30] <ScottK> xtknight: You should have a backup, but if you lose either your secret key or the passphrase, you need to make a new one.
[05:30] <tonyyarusso> I anticipate that this drive will never leave my sight, but I'm not 100% sure.
[05:30] <xtknight> ScottK, what if i remember the PW i just didn't export the public or private key?
[05:31] <xtknight> e.g. data loss
[05:31] <ScottK> You need to have the private key or you need to start over.
[05:31] <xtknight> if i start over, won't they think im an imposter?
[05:31] <ScottK> Who?
[05:31] <tonyyarusso> "they" being?
[05:31] <ScottK> For LP, just add the new key to your LP ID.
[05:31] <xtknight> ah ok
[05:32] <xtknight> the point of signing something is so that they know it's "you".  if i created a new key all of a sudden that didnt match any of my previous ones, that probably wouldnt go over too well.
[05:32] <ScottK> As long as it's in LP, LP won't care.
[05:32] <xtknight> k
[05:40] <xtknight> how would you make a .diff.gz?
[05:41] <xtknight> does that sound good? "diff -u ../orig/hugin/ hugin > hugin_0.7~svn2420.diff.gz"
[05:41] <Fujitsu> xtknight: debuild
[05:41] <Fujitsu> Or dpkg-buildpackage
[05:42] <xtknight> Fujitsu,  oh so debuild will make it once i give it the orig in ../ ?
[05:42] <tonyyarusso> xtknight: yeah
[05:42] <xtknight> cool beans :)
[05:42] <bddebian> Is there a better replacement for j2re1.4?
[05:42] <tonyyarusso> (how do debuild and dpkg-buildpackage differ?)
[05:42] <Fujitsu> bddebian: Yeah. Not java.
[05:43] <bddebian> Fujitsu: Well that's obvious, but besides that :-)
[05:43] <Fujitsu> tonyyarusso: debuild does some build environment cleaning and various other magic... it's basically a wrapper around dpkg-buildpackage.
[05:43] <tonyyarusso> Fujitsu: so debuild would be preferred then.
[05:43] <LaserJock> debuild is *the* way to go
[05:43] <zakame> pdebuild too
[05:44] <LaserJock> I don't know why people use dpkg-buildpackage
[05:44] <xtknight> now if i'm updating "somebody else"'s package, should the maintainer be him, me, or Ubuntu MOTU?  The XSBC-Orig should still be the first Debian maintainer of the package?
[05:44] <LaserJock> debuild is shorter
[05:44] <bddebian> LaserJock: I do :-)
[05:44] <Fujitsu> zakame: sbuild > pbuilder
[05:44] <bddebian> I'm old and crusty ya know :-)
[05:44] <LaserJock> bddebian: well, we know you are special
[05:44] <LaserJock> ;-)
[05:44] <bddebian> That's spethial ;-P
[05:45] <bddebian> So let me ask differently.  Is there a runtime match for gcj ?
[05:45] <Fujitsu> gij?
[05:45] <zakame> Fujitsu: right
[05:45] <LaserJock> I like pbuilder
[05:45] <LaserJock> I need to try sbuild out, but I've just not had time
[05:45] <zakame> but I still find pdebuild/cowdancer easier to set up
[05:45] <LaserJock> but I don't use LVM so I'm not sure why it would be that much better
[05:46] <bddebian> Fujitsu: But that's just the interpreter.  It doesn't include a vm right?
[05:47] <bddebian> I wonder if kaffe would work
[05:47] <Fujitsu> bddebian: No idea. I don't do Java.
[05:47] <bddebian> Me either :-(
[05:49] <nixternal> bddebian: there is no better replacement for any of the sun java components
[05:49] <nixternal> blackdown was the closest on the jre side
[05:49] <bddebian> j2re1.4 is blackdown isn't it?
[05:50] <LaserJock> that's why I just won't deal with Java until Sun open sources their stuff
[05:50] <LaserJock> it's just to messy for me to get straight
[05:50] <nixternal> blackdown is something different I thought
[05:51] <nixternal> I just use all of the java components right now because they are the only ones that work worth a darn for my java classes
[05:51] <tonyyarusso> LaserJock: I think part of the wiki still says dpkg-buildpackage, or I wouldn't have tried it.
[05:51] <bddebian> !j2re1.4
[05:51] <ubotu> Sorry, I don't know anything about j2re1.4 - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[05:51] <bddebian> pfft
[05:51] <zakame> blackdown is still sun java right?
[05:51] <LaserJock> well, it's not a "still" thing. Some people prefer dpkg-buildpackage it seems
[05:51] <nixternal> !jre
[05:51] <ubotu> Sorry, I don't know anything about jre - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[05:51] <nixternal> !java
[05:51] <ubotu> To install a Java compiler/interpreter on Ubuntu, look at https://help.ubuntu.com/community/Java - For the Sun Java runtime install sun-java5-jre from the !Multiverse repository. Enable the backports repository on Edgy to install sun-java6-jre
[05:52] <nixternal> ahh, you are right about blackdown
[05:52] <nixternal> j2* is blackdown
[05:53] <bddebian> Well freemind fails to build with j2sdk1.4.  I can build it with gcj but I don't know what that will do to the runtime environment
[05:57] <ScottK> StevenK: If I came up with a patch for requestsync to add the equivalent of -k in dpkg-buildpackage, would you take the patch?
[05:58] <ScottK> Not saying on what schedule, but I'll add it to the TODO if you're good with the idea.
[06:00] <tonyyarusso> Freemind is going into gutsy?
[06:00] <bddebian> It's already in but FTBFSs
[06:01] <tonyyarusso> Fun.  Hope it gets fixed - could be useful.
[06:01] <bddebian> Well as I said, I can build it with gcj but that doesn't help the runtime environment
[06:02] <tonyyarusso> bddebian: Have you talked to Eric Lavarde yet?
[06:02] <bddebian> Nope
[06:02] <tonyyarusso> bddebian: Seems to manage it in Debian, according to http://packages.debian.org/unstable/text/freemind
[06:02] <bddebian> Yep
[06:04] <tonyyarusso> bddebian: Have you been able to compare your source packages yet?
[06:04] <bddebian> tonyyarusso: ??
[06:05] <tonyyarusso> bddebian: Were you working from his, or starting from scratch?
[06:06] <bddebian> tonyyarusso: It was synced from Debian.  Same version
[06:07] <tonyyarusso> bddebian: oh.  nvm me then :S
[06:08] <bddebian> :-)
[06:09] <xtknight> what tells debian to make multiple debs for one source package?
[06:09] <bddebian> debian/control
[06:09] <xtknight> how does it know which files to give to each deb?
[06:10] <bddebian> There is 1 source entry and x binary package entries
[06:10] <bddebian> Oh
[06:10] <bddebian> Depends on the packaging type
[06:10] <xtknight> hmm
[06:10] <LaserJock> generally you can use a .install file
[06:11] <LaserJock> so like binarypackage1.install binarypackage2.install
[06:11] <LaserJock> if you are using debhelper/cdbs
[06:11] <xtknight> .install is a static thing that it always looks for, i assume?
[06:11] <xtknight> i dont see .install referenced
[06:11] <crimsun> debian/*.install
[06:11] <LaserJock> there isn't a .install file in debian/ ?
[06:11] <bddebian> They are inside the debian/ dir as well
[06:11] <LaserJock> crimsun!!!
[06:11] <LaserJock> holy cow!
[06:11] <xtknight> there is, but what tells it to look at .install and not .destroy? :)
[06:12] <LaserJock> dh_install is a debhelper script
[06:12] <xtknight> it always has to be "binarypkg.install"?
[06:12] <LaserJock> and it know to look at .install
[06:12] <bddebian> heh
[06:12] <LaserJock> well, if you don't have to distinguish you can do just install
[06:13] <LaserJock> but yeah, if you have multiple binaries you do <binarypackage>.install
[06:13] <LaserJock> crimsun: nice to see you are still alive
[06:14] <white> !info polipo gutsy
[06:14] <ubotu> polipo: a small, caching web proxy. In component universe, is optional. Version 1.0.1-2ubuntu1 (gutsy), package size 186 kB, installed size 800 kB
[06:14] <white> someone might want to look into an upgrade for polipo
[06:15] <bddebian> ho hum
[06:15] <crimsun> to 1.0.2-1?
[06:15] <white> !info backup-manager gutsy
[06:15] <ubotu> backup-manager: command-line backup tool. In component universe, is optional. Version 0.7.6-1 (gutsy), package size 111 kB, installed size 604 kB
[06:15] <white> crimsun: that is the version, which is marked as fixed, yes
[06:15] <xtknight> ok what is  ${shlibs:Depends} replaced by?
[06:15] <white> backup-manager to 0.7.6-3
[06:16] <white> !info mapserver gutsy
[06:16] <ubotu> Package mapserver does not exist in gutsy
[06:16] <crimsun> likely just needs UVF exception requests
[06:16] <white> !info perl-mapscript gutsy
[06:16] <ubotu> perl-mapscript: perl mapserver library. In component universe, is optional. Version 4.10.2-1 (gutsy), package size 699 kB, installed size 2048 kB
[06:16] <crimsun> I've been away most of this dev cycle, so I'm not 100% on the protocol
[06:17] <white> mapserver to 4.10.3-1 , but the patch could probably be backportet
[06:20] <LaserJock> white: do you have time to file bugs?
[06:20] <LaserJock> white: if so tag them with "upgrade"
[06:21] <ScottK> LaserJock: white serves as a communication device from Debian to Ubuntu.  AFAIK he doesn't actually do stuff like that.
[06:22] <LaserJock> communication is much nicer via bugs than IRC though
[06:22] <LaserJock> or at least email
[06:23] <LaserJock> but I realize he probably doesn't have a  lot of time, hence my first question
[06:23] <ScottK> Sure.  Just saying.
[06:24] <ScottK> Maybe there's a motu hopeful here that would be willing to file bugs ...
[06:24] <white> LaserJock: nope, sorry just wanted to forward the stuff from last night and after i upload the bugzilla NMU i need to study a bit :/
[06:25] <LaserJock> no problemo
[06:26] <bddebian> Yes lord knows we need more bugs :-)
[06:26] <crimsun> well you two are 2/3 of the trinity, so that's a non-issue ;)
[06:27] <bddebian> Hah, not anymore.  I'm pretty much more useless than ever :-(
[06:34] <minghua> banshee's "shuffle playback mode" seems to be completely broken.
[06:34] <minghua> It neither is random nor covers all the songs.
[06:35] <minghua> I have five songs in my list, and banshee gives me 1->3->5->1->3->5... in this shuffle mode.
[06:35] <minghua> :-(
[06:35] <Flannel> minghua: How do you know that's not random?
[06:36] <minghua> Flannel: I am not exactly sure, but I can calculate the probability if you really want...
[06:36] <xtknight> so dpkg-shlibdeps makes shlibs:Depends what does the misc Depends?
[06:36] <minghua> I think this is the fourth round it starts with no. 1.
[06:37] <minghua> xtknight: Please rephrase, I don't understand you question.
[06:37] <xtknight> minghua, how do i get ${misc:Depends} ?
[06:37] <Flannel> minghua: maybe you should go play the lottery if it keeps playing 1,3,5...
[06:37] <minghua> xtknight: ${misc:Depends} is added by different programs.
[06:37] <xtknight> minghua, dpkg-shlibdeps made substvars that set ${shlibs:Depends}, but there is a ${misc:Depends} i need to set
[06:38] <xtknight> (basically i'm using another package as a template and these variables don't exist anymore, i'm not sure how to create them for what's in the package now)
[06:38] <LaserJock>  misc:Depends is used by debhelper
[06:38] <LaserJock> to add in stuff it needs
[06:39] <minghua> xtknight: For example, I believe dh_installdebconf adds debconf into ${misc:Depends}.
[06:40] <xtknight> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
[06:40] <xtknight> ?
[06:40] <minghua> xtknight: Exactly what do you want to set ${misc:Depends} to?
[06:40] <xtknight> that happened for shlibs.  then i ran dpkg-shlibdeps and the shlibs error is gone.  now i need to deal with misc
[06:40] <minghua> xtknight: If you don't need/use ${misc:Depends}, don't add it in Depends: line in debian/control.
[06:40] <xtknight> minghua,  hmm.  i guess i dont.  i can always check deps with pbuilder right?
[06:41] <minghua> xtknight: pbuilder usually only find problems in build dependencies, not (binary) dependencies.
[06:41] <xtknight> i'm wondering where ${misc:Depends} is set, though.  what tells debuild what the variable misc:Depends is ?  i would like to take a look at what another pkg has this variable set to, for example
[06:42] <minghua> You really need to know your package to decide if you need ${misc:Depends} or not.
[06:42] <xtknight> it's pretty small, so probably nothing
[06:42] <minghua> xtknight: After building, the value of ${misc:Depends} is in debian/<package-name>.substvars.
[06:42] <xtknight> ahh ok
[06:43] <xtknight> if it installs and runs on a fresh chroot, the it Depends on nothing, is that righT?
[06:44] <xtknight> or maybe if it needs a specific version of something
[06:44] <minghua> Okay, I got my no. 2 song.  Never mind what I complained about banshee.
[06:44] <minghua> (I still suspect there is something wrong, though.)
[06:44] <xtknight> what did shlibdeps do?  didn't that just detect the dependencies of my binary package?
[06:45] <RAOF> minghua: It's because it's actually random, not a shuffle.
[06:45] <RAOF> I think you'll find that rhythmbox does an actual shuffle without replacement, but banshee doesn't (yet).
[06:46] <minghua> RAOF: Yeah, good point.  Still many 1->3->5 rounds should be a rather small probability event...
[06:46] <minghua> Yes, rhythmbox's shuffle mode goes over all songs before starting next round.
[06:46] <RAOF> minghua: That's actually really hard to determine :).
[06:47] <minghua> I'll report a bug after some more experimentation.
[06:47] <RAOF> The next banshee release is getting an actual play queue as a part of it's huge rewriting.  Maybe that'll turn "random" into "shuffle".
[06:47] <minghua> At least, there is a "call it random mode instead of shuffle mode" bug to report.
[06:47] <RAOF> Point.
[06:48] <minghua> RAOF: Nice.  Do you happen to know the ETA of next banshee release?
[06:48] <RAOF> minghua: No.  We've actually got all the code (it's in the 0.13.1 release we've currently got), it's just not hooked up to anything yet!
[06:48] <minghua> Hmm.
[06:49] <minghua> RAOF: Thanks for the explanation.
[06:49] <white> !info bugzilla gutsy
[06:49] <ubotu> bugzilla: web-based bug tracking system. In component universe, is optional. Version 2.22.1-2.1ubuntu1 (gutsy), package size 811 kB, installed size 4436 kB
[06:49] <RAOF> Actually, the next banshee release should bring it pretty much up to parity with rhythmbox.  There's a lot of performance work done, play queue, etc.
[06:50] <white> you might want to check out the NMU 2.22.1-2.2
[06:50] <white> there was another CVE fixed
[06:50] <LaserJock> heah, is anybody writing this down? :-)
[06:50] <RAOF> Eh, it's all logged :)
[06:50] <crimsun> nmu should be a non-issue, since it's not an uv
[06:51] <white> LaserJock: actually it might be a good idea, if one MOTU would subscribe to the testing-security tracker list and maybe he and me could have a list somewhere, so you guys could work on syncing/merging it
[06:51] <LaserJock> RAOF: yeah, but people need to actually do it, you know ;-)
[06:51] <white> LaserJock: or someone subscribes to the whole crap i am saying here
[06:51] <white> anyway, see you later
[06:51] <LaserJock> thanks white
[06:52] <RAOF> Yeah, thanks.
[06:52] <bddebian> Any of you use/know audacious?
[06:52] <LaserJock> is that the audo editor app?
[06:52] <LaserJock> *audio
[06:52] <bddebian> Yeah I think
[06:52] <RAOF> Isn't that the xmms forky thing?
[06:53] <RAOF> There's audacious & audacity, and they're two different projects, right?
[06:53] <LaserJock> yeah
[06:53] <LaserJock> maybe audacity is the audio editor
[06:54] <RAOF> That's what aptitude thinks, too :)
[06:54] <bddebian> Yeah audacious is a fork of xmms
[07:02] <xtknight> well i've got my package built with debuild.  all goes well it is installs my program.  but im having troubles with pbuilder, ./configure script permission denied.  i think this is why: " dpkg-source: warning: executable mode 0755 of 'configure' will not be represented in diff." but how can i solve this?  the orig.tar.gz uses a "bootstrap" that creates a configure file.
[07:02] <xtknight> it installs my program*
[07:04] <minghua> xtknight: Don't put the configure script in .diff.gz, and run bootstrap at build time, is one option.
[07:05] <xtknight> ok
[07:05] <xtknight> minghua, the package of "hugin" (that i am updating) which is in gutsy uses a "configure" in its main dir which is why i went that route to begin with
[07:06] <minghua> xtknight: Is the configure script in gutsy package in .orig.tar.gz or .diff.gz?
[07:06] <bddebian> Gnight folks
[07:07] <xtknight> minghua, well he put it in the orig
[07:07] <xtknight> minghua, i don't think that is the "true" original though, because that orig file still has a bootstrap
[07:08] <xtknight> my orig is a direct mirror of what i got off sourceforge
[07:08] <minghua> xtknight: Are you packaging a new upstream?
[07:09] <minghua> !info hugin gutsy
[07:09] <ubotu> hugin: a Panorama Tools GUI to make panoramas from multiple pictures. In component universe, is optional. Version 0.7~beta4-0ubuntu1 (gutsy), package size 88 kB, installed size 132 kB
[07:09] <xtknight> minghua,  ok a bit complicated.  i am packaging part of "Hugin SVN", align_image_stack which needs to be built against Hugin SVN.  it will not build against the hugin in there.  so i made a new pkg with align_image_stack and all the updates headers it needs to compile.  great, so with no dynamic libraries we're all set right?
[07:10] <xtknight> ( i could not simply update hugin to hugin svn for regressions reasons )
[07:10] <xtknight> align_image_stack is only in Hugin svn
[07:10] <xtknight> there is no release which contains it
[07:11] <minghua> xtknight: Honestly I don't see much point talking about updating a package to an SVN version at this stage of release cycle.
[07:11] <xtknight> minghua,  this is a different package, not an update
[07:12] <minghua> xtknight: It's essentially the same.  I don't think it stands any chance of getting into gutsy.
[07:12] <xtknight> minghua, ok well i wouldn't really like to explain the whole situation again.  Bug 135111
[07:12] <ubotu> Launchpad bug 135111 in hugin "[UVFe]  hugin svn needs packaged for qtpfsgui" [Wishlist,Confirmed]  https://launchpad.net/bugs/135111
[07:13] <xtknight> basically i decided i could not update it because it may cause regressions (see last comment)
[07:13] <xtknight> so instead i am making a new pkg to include the program i need, standalone
[07:13] <xtknight> i think this is the best option for best user experience
[07:14] <xtknight> in fact i should add this to the comments there to clarify things
[07:14] <xtknight> sorry for the confusion
[07:16] <minghua> xtknight: I see the whole picture now.  However you didn't put you new plan (two packages) in the bug report, and you haven't got approval yet.  And this time you need a New Package Freeze exception, and I doubt the current UVF exception approval counts.
[07:18] <xtknight> minghua, ok I have no problem filing for the New Package Freeze exception and ditching the previous UVFe idea.  i would like the new program included in Gutsy (it is very small and depends on very little), but I don't want to cause regressions by needlessly updating hugin
[07:19] <minghua> xtknight: I understands you goal.  However I don't think you approach is a good idea, and I wouldn't grant approval if I were the release manager.
[07:20] <xtknight> minghua, how would you go about it?
[07:21] <minghua> xtknight: I would just bite the bullet and prepare the updated hugin and new package for hardy.
[07:21] <minghua> xtknight: Because in my opinion release pre-mature packages is worse than not release anything at all.
[07:22] <xtknight> since align_image_stack is in no hugin release then i will probably just forget about it, and make a new package once it is contained in a stable release which probably won't be until Hardy
[07:23] <xtknight> it would save a lot of trouble but i don't see how the current solution is any worse than what was already approved
[07:24] <xtknight> it would be the same code basically in a different package to avoid conflicts
[07:24] <minghua> "what is already approved" is not achieved yet.
[07:25] <minghua> In case it's not clear, my preference is "keeping the status quo", no updating hugin package, nor new hugin-svn package, everything can wait for hardy.
[07:26] <ScottK> xtknight: You are on a different plan now than we acked.  IMO you need to ask again.
[07:26] <xtknight> ScottK, oh, i have no problem asking for a New Package approval instead, but i am confused about the resistance to my current plan
[07:27] <xtknight> well i'll just do it and see what happens.  if they think it will wait until Hardy they will disapprove it, right?
[07:27] <ScottK> From my perspective, you asked for one thing and now you do another.
[07:27] <minghua> xtknight: I'm not a release manager (or motu-uvf team member?), so my resistance doesn't really matter.
[07:28] <ScottK> So it's not a freebie option.
[07:28] <minghua> xtknight: My suggestion would be "ask first".
[07:29] <xtknight> don't know it is probably too much trouble than it's worth for everybody
[07:32] <ScottK> xtknight: Off the top of my head, I'd say wait for Hardy.
[07:33] <ScottK> That's my advice, not speaking as motu-uvg
[07:33] <ScottK> err uvf
[07:36] <StevenK> ScottK: Re: your patch for requestsync, why?
[07:37] <ScottK> Because requestsync takes the first secret key on your keyring.
[07:37] <ScottK> In my case, that's not the one I use for Ubuntu, so it's  PITA.
[07:38] <ScottK> Note that I don't have the patch yet, just the annoyance factor that may rise into motivation.
[07:41] <ScottK> I think I should get to bed.  Good night all.
[07:42] <tonyyarusso> g'night
[07:48] <StevenK> ScottK: Drat, I missed you since I was putting shopping away. I'm happy to wait for a patch. If you have any trouble writting it, I'm happy to fix/debug, too.
[07:50] <xtknight> ScottK, minghua thank you for your thoughts.  i will see what my mentor thinks but most likely i will wait until Hardy
[07:50] <minghua> xtknight: You are welcome.
[07:50] <xtknight> i wasn't too happy about this but worst case i can put up a page about "how to get qtpfsgui" working in ubuntu on the forums, etc in absense of a package
[07:51] <ScottK> StevenK: I'm actually still here.
[07:52] <ScottK> StevenK: If you feel motivated, feel free to go ahead.  I've a long TODO list, so I don't know how soon I'd get to it.
[07:54] <StevenK> ScottK: I had to add the code for option parsing to requestsync due to sponsorship and such like, and it's actually a nice request. I think I can knock it over quickly, unless you want to cut your teeth on some Python.
[07:55] <ScottK> No.  I do enough Python on other things, so go ahead.
[07:55] <ScottK> Thanks for looking into it.
[07:56] <StevenK> It seems more interesting than looking at unmetdeps right now.
[07:56] <ScottK> Heh.
[08:07] <ScottK> OK.  Off to bed, really this time...  Good night once again.
[08:07] <StevenK> Night ScottK
[08:57] <TheMuso> Hey folks
[10:13] <RAOF> So, I'm trying to debug why trackerd segfaults somewhere in my $HOME.
[10:14] <RAOF> It's nice and reproducible.  However, the gdb backtrace is populated by 71 ?? calls.
[10:14] <RAOF> Also, valgrind SIGILLs when I try to run valgrind against it.
[11:01] <\sh> moins
[11:10] <\sh> anyone upto sponsor some bugfixes to universe? :)
[11:12] <geser> morning
[11:20] <jeromeg> geser : hello, have you been able to test dvgrab 3.0 with your dv camera ?
[11:26] <geser> not yet, will do it today
[11:27] <jeromeg> geser : thx very much, could you add your comments on the LP bug ?
[11:28] <jeromeg> cause I'll be away today
[11:37] <enyc> Hrrm'' i should suggest -motu include  nsd3 in ubuntu universe (please) -- its in debian testing, low dependancies, no non-free troubles, small and efficient ;-)
[11:38] <enyc> [please]  ;-) --   shoul i be posting a wishlist bug or something?  should i be testing it myself somehow?
[11:38] <minghua> !info nsd3
[11:38] <ubotu> Package nsd3 does not exist in feisty, feisty-seveas
[11:38] <minghua> !info nsd3 gutsy
[11:38] <ubotu> Package nsd3 does not exist in gutsy
[11:39] <enyc> ('nsd' is there already, which is NSD2)
[11:39] <enyc> nsd3 is not compatible config, the debian packgae uses /etc/nsd3 instead of /etc/nsd  etc.
[11:39] <enyc> !info nsd gutsy
[11:39] <minghua> enyc: You need to file an UVF exception request if you want to get it into gutsy.
[11:39] <ubotu> nsd: authoritative name domain server. In component universe, is optional. Version 2.3.7-1 (gutsy), package size 152 kB, installed size 516 kB
[11:40] <enyc> minghua: o
[11:40] <minghua> enyc: s/UVF exception/Universe New Package Freeze exception/
[11:41] <minghua> enyc: Briefly -- probably too late to ask at this time.
[11:41] <minghua> enyc: It should be automatically imported in the next release (a.k.a. hardy) though.
[11:46] <enyc> minghua: i see ;-)
[11:46] <enyc> minghua: so "Briefly" 'all' debian packages are normally imported into ubuntu one way or another?
[11:48] <minghua> enyc: Yes, at the start of a development cycle.  All main package (i.e. the free stuff) in unstable anyway.
[11:48] <enyc> minghua: got you
[11:49] <minghua> enyc: Which means special care probably needs to be taken for contrib/non-free or experimental packages.
[11:49] <enyc> minghua: actually I would rather that ubuntu supported some of the newer NSD tools (i.e. not bind*) in main but thats another story ;-)
[11:49] <enyc> minghua: yes... some go into multiverse... some may be medubuntu and not in  uubuntu as-such
[11:49] <minghua> Yeah, get it into universe first before talking about main inclusion...
[11:49] <enyc> minghua: ;-)
[11:54] <jussi01> Hmmm, can someone point me to a page that explains the philosofy of why we update every 6 months and not when the app comes out?
[11:54] <jussi01> ie. the release system?
[11:54] <jussi01> Its not I dont understand it, I just want it in writing... :)
[12:01] <\sh> jussi01, what needs to be written? there are several documents about "why is gentoo not enterprise ready", and that's all about it, that's why ubuntu is releasing every six months, or opensuse every year or so...
[12:02] <jussi01> \sh: I was just meaning is there something on the official site (as I cant see it) that explains that we release every 6 months and a breif reason for it??
[12:03] <\sh> isn't anywhere an blog article of Mark about it...hmm
[12:08] <\sh> if anyone has time, and is so nice to sponsor some uploads...please see bug 136544 , bug 136547 and bug 136552 , thx :)
[12:08] <ubotu> Launchpad bug 136544 in etoken "[FTBFS]  etoken " [Undecided,New]  https://launchpad.net/bugs/136544
[12:08] <ubotu> Launchpad bug 136547 in fxload "[FTBFS]  fxload (needs to be synced)" [Undecided,New]  https://launchpad.net/bugs/136547
[12:08] <ubotu> Launchpad bug 136552 in galculator "[FTBFS]  galculator " [Undecided,New]  https://launchpad.net/bugs/136552
[12:10] <\sh> cu later
[12:13] <jussi01> see ya \sh
[12:23] <zakame> quit
[12:44] <emiri_> good morning, someone can advice me to get involved with ubuntu dev?
[12:45] <geser> emiri_: hello, have you read https://wiki.ubuntu.com/MOTU already?
[12:45] <emiri_> no, im going
[12:45] <emiri_> Masters of the Universe?
[12:46] <minghua> (or just read the channel topic...)
[12:49] <emiri_> im reading the MOTU Recruitment page
[12:50] <geser> emiri_: the community cared part from the archive is called universe and the dev responsible for it are called MOTUs
[12:52] <emiri_> i knew universe and multiverse archives...
[12:52] <emiri_> generate a contributor name as 'Masters of universe' from this is little bit funny
[12:52] <emiri_> thats all
[01:37] <DarkSun88> Hi
[02:15] <soren> Could someone set the clock on the new revu machine? It's waaaay off.
[03:06] <bluefoxicy> freaking crashers
[03:07] <bluefoxicy> and damnit the -rt restricted modules don't have the nvidia driver >:|
[03:07] <zakame> what crashers?
[03:09] <bluefoxicy> I don't know
[03:09] <bluefoxicy> my system was hanged this morning
[03:14] <zakame> what were the charges?
[03:43] <emiri_> can anyone add me to patch my first package?
[03:45] <emiri_> I'm having problems in signing changes step
[03:48] <geser> what problem do you have?
[03:49] <emiri_> im following this tuto
[03:49] <emiri_> https://wiki.ubuntu.com/MeetingLogs/openweekedgy/Packaging101
[04:08] <emiri_> i have this problem : apparently doing a patch we need to sign the changes
[04:08] <emiri_> and my home dir .gnupg is owned by root
[04:08] <gnomefreak> emiri_: change the owner
[04:09] <gnomefreak> chmod
[04:09] <geser> emiri_: signing is only important if you want to upload it somewhere
[04:14] <emiri_> there is an option to tell "debuild" command to not sign the changes?
[04:14] <geser> -uc -us
[04:14] <emiri_> thanks I try
[04:20] <emiri_> I have my .deb without signature
[04:21] <emiri_> but I can't no longer clean the source
[04:21] <emiri_> if I do "fakeroot debian/rules clean"
[04:22] <emiri_> I find the following error:
[04:22] <emiri_> Trying reverse patch debian/patches/01-fix-gtk-breakage.patch at level 1 ... 0 ... 2 ... failure.
[04:23] <emiri_> how can I clean the source+patch to do another job?
[04:23] <emiri_> such as a new source package with the changes (for example)
[04:29] <emiri_> there's another way to clean the source?
[04:30] <geser> have you modified the file this patch patches?
[04:31] <emiri_> yes, I have executed the "cdbs-edit-patch" command
[04:31] <emiri_> logged in a console
[04:31] <emiri_> edit and save the file
[04:31] <emiri_> and Control-D
[04:31] <emiri_> after this I have compiled the .deb file
[04:32] <emiri_> now I want to clean the compiled source to make a source .deb
[04:33] <emiri_> thats ok?
[04:33] <geser> should be, I don't see the error right now
[04:34] <emiri_> usually do you use "fakeroot debian/rules clean" to clean the source?
[04:34] <geser> I usually patch and build then the source package and let then a pbuilder build it
[04:35] <geser> you could now save your patch outside the package dir and start from fresh
[04:36] <geser> you need then only to copy back your saved patch to the patches dir again
[04:37] <emiri_> pbuilder build packageName?
[04:39] <geser> pbuilder build package.dsc
[04:40] <emiri_> I try
[04:41] <emiri_> it is instally many packages
[04:41] <emiri_> excuse-me, instally->installing
[04:42] <emiri_> argh!
[04:42] <emiri_> "No package 'gtk+-2.0' found"
[04:42] <emiri_> it may look for libgtk+-2.0
[04:42] <emiri_> but it looks for gtk+-2.0
[04:43] <emiri_> I thing the tuto its a bit out-of-date
[04:44] <emiri_> I have to edit debian/control file?
[04:44] <zakame> libgtk2.0-0
[04:44] <emiri_> thx
[04:48] <geser> emiri_: is that from running configure?
[05:05] <luisbg> IT Crowd 2x2 is out!
[05:05] <luisbg> =)
[05:07] <Fujitsu> Ooh, didn't know 2x had started.
[05:11] <StevenK> Neither did I.
[05:12] <Fujitsu> Probably won't get it in .au for a few months.
[05:13] <soren> ScottK: Thanks for the ack on system-config-samba
[05:13] <ScottK> soren: No problem.  I agree it's something we really need.
[05:14] <Fujitsu> Sounds nice and shiny.
[05:14] <luisbg> =)
[05:14] <ScottK> StevenK and soren: There are a number of UVFe's that I think are reasonable looking for a 2nd ack, so I'd commend the queue to you for a look...
[05:14] <soren> ScottK: First thing Monday morning.
[05:15] <soren> ScottK: I've got a huge backlog of real world shit to take care of after my holiday, too.
[05:15] <StevenK> ScottK: I was planning to sleep, it being 1:20am
[05:15] <ScottK> K
[05:16] <StevenK> ScottK: In other news, http://wedontsleep.org/~steven/requestsync.py
[05:16] <ScottK> Most of them are sync's so now or Monday doesn't may much difference.
[05:16] <StevenK> ScottK: Please test that -k works before I upload it.
[05:18] <Fujitsu> Damn, 2x2 will take >1h :(
[05:25] <ScottK> StevenK: Does not appear to be working for me.  Let me investigate.
[05:27] <StevenK> ScottK: I add -r <keyid> to the gpg command line. I'm not certain if that is the right option.
[05:28] <ScottK> I'm reading man gpg right now and I don't think it is.
[05:28] <ScottK> From that man page that looks like an encryption recipient thing.
[05:28] <StevenK> Doh
[05:29] <ScottK> StevenK: -u
[05:30] <StevenK> ScottK: Since it's a one-char change: the line number in question is 155, s/-r/-u/
[05:30] <ScottK> Yes and it works.
[05:31] <ScottK> You've also got an extraneous debug print statement left in there too.
[05:31] <StevenK> Noted and killed, ta.
[05:32] <ScottK> This is a separate feature request that just ocurred to me...
[05:32] <ScottK> If DEBEMAIL isn't set properly the script dies on the assert myemailaddress
[05:33] <ScottK> It would be handy to trap that error and raise a useful error message.
[05:34] <ScottK> Right now it just says "AssertionError"
[05:34] <ScottK> Maybe something for the next upload ...
[05:35] <StevenK> I haven't uploaded yet, and it sounds like a short change
[05:36] <ScottK> OK.
[05:36] <ScottK> Would you rather just do it or I give you a diff?
[05:36] <ScottK> It'll be ~ 3 lines
[05:38] <StevenK> I've just done it.
[05:38] <StevenK> But thanks for the offer. :-)
[05:38] <ScottK> OK.  Not a problem.
[05:40] <StevenK> ScottK: I'll upload devscripts after I get up.
[05:41] <ScottK> Sounds good.
[05:41] <ScottK> Havd a good night.
[05:41] <ScottK> Havd/Have
[05:51] <ScottK> soren: Are you there?
[05:54] <soren> ScottK: Yes?
[05:54] <ScottK> soren: I'm looking at the samba config thing now.
[05:54] <ScottK> Why XS-Python-Version: current?
[05:55] <soren> Either someone told me to, or I copied it from a similar package.
[05:55] <soren> I packaged it months ago, you see.
[05:55] <ScottK> OK.
[05:55] <ScottK> I see.
[05:55] <soren> It's a good question, though.
[05:56] <ScottK> I've seen Debian Python experts get in deep arguements about what current means/should mean.
[05:56] <ScottK> If the poeple that are writing the tools can't agree on the semantics of current (and it doesn't appear to me that they can), I think it should be avoided.
[05:56] <soren> I still haven't quite wrapped my head around the difference between current and all.
[05:56] <POX_> ScottK: use it if you want to compile pyc files for one Python version only
[05:57] <POX_> it's useful for python applications
[05:57] <ScottK> OK.
[05:57] <POX_> python modules should be compiled for all supported (and installed) Python versions
[05:58] <ScottK> Why would you not want to do the same for apps?
[05:58] <soren> POX_: I just don't quite understand how the statement "I believe this package will work with whatever is current at any given time" is different from "I believe this package can work with any version".
[05:58] <POX_> if app is using /usr/bin/python, why shoul it's modules be compiled for other python versions?
[05:58] <POX_> it's just a waste of space
[06:00] <ScottK> Good morning mohammad
[06:00] <mohammad> Good morning ScottK
[06:01] <mohammad> it seems that the binary of https://launchpad.net/ubuntu/gutsy/+source/ttf-sil-scheherazade has not been generated yet. is that ok?
[06:01] <POX_> soren: the difference is that you will not have pyc files compiled for python2.3, python2.4 and python2.6 if you use python2.5 only
[06:02] <ScottK> mohammad: ttf-sil-scheherazade is now in Binary NEW, this means the source was accepted: https://launchpad.net/ubuntu/gutsy/+queue?queue_state=0&queue_text=&start=0
[06:02] <ScottK> Once the binary is accepted, please file a removal request for ttf-scheherazade
[06:03] <ScottK> POX_: So I guess it's a tradeoff between do you want the app compiled for all installed Python versions versus just one.  Disk space versus performance if someone uses the non-default Python.
[06:03] <mohammad> how can I file this removal request? is there any special form?
[06:04] <ScottK> mohammad: https://wiki.ubuntu.com/MOTU/Removal
[06:05] <ScottK> We'll want to do a revision to zekr removing the dependency first.
[06:05] <ScottK> soren: I guess my view tends to be that disk space is cheap, so why not make .pyc for all installed Python versions.
[06:06] <POX_> ScottK: if someone uses non-default Python version, he will not be able to use this module, other python versions will simply not see it
[06:06] <POX_> if module can be used outside application, sure - compile it for all versions
[06:07] <ScottK> POX_: Thanks.
[06:08] <mohammad> ScottK: Nicolas Spalinger asked me to synch ttf-sil-scheherazade in Ubuntu with http://yosch.org/packages/debian/ . Should I wait until the binary of ttf-sil-scheherazade be accepted?
[06:09] <ScottK> mohammad: Let me look.
[06:09] <yosch> mohammad, ScottK: hi guys
[06:09] <ScottK> Hello.
[06:09] <mohammad> Hello
[06:09] <yosch> actually there are no changes between the package as uploaded to Debian and the one on my personal website
[06:09] <ScottK> OK.
[06:10] <yosch> and thanks for the quick reaction :)
[06:10] <ScottK> If it's in Debian and the upstream source is the same version, it should'n't be a problem to sync it.  I would wait until after it gets out of Binary NEW.
[06:10] <yosch> ScottK: ideally we should aim at reducing the deltas between font packages between Debian and Ubuntu (and other derivatives)
[06:11] <mohammad> yosch: ok, but I think you sent me an email regarding the synch a few minutes ago.
[06:11] <ScottK> yosch: I agree.  In general the smaller the diff with Debian, the better for both Ubuntu and Debian.
[06:12] <ScottK> joing/joined
[06:12] <mohammad> yosch: I think in debian/ttf-sil-scheherazade.defoma-hints Farsi should be replaced by Persian
[06:13] <soren> ScottK: I suppose all would make more sense, then. I've already uploaded it, so I'll wait until it gets through NEW.
[06:14] <yosch> mohammad: sorry. A bit confused here...
[06:15] <ScottK> yosch: mohammad and I argued about this the other day.
[06:15] <yosch> mohammad: the sync was to keep packages similar but the package I see in the queue has an ubuntu tag.
[06:15] <mohammad> yosch: I am a persian native speaker, and as far as I know the official name of our language in English is Persian
[06:16] <ScottK> soren: It's also be nice if you added comments in your patches DP# ...
[06:16] <ScottK> yosch: Once we sync from Debian, that will go away.
[06:16] <yosch> ScottK: OK got it.
[06:18] <ScottK> mohammad: In general, there should be a good reason to maintain a difference between Debian and Ubuntu.  Since yosch is the Debian maintainer, I expect that Ubuntu will respect his choice on this.  So whatever he decides is fine here.
[06:18] <ScottK> Each time there is an Ubuntu unique revision, it means more manual work by people who are already busy.
[06:19] <yosch> mohammad: about the defoma hints. ISO 639-3 is "pes", I see alternate names:  	Persian, New Persian, Parsi, Irani
[06:19] <mohammad> I agree to use the debian package :)
[06:19] <yosch> mohammad: but you're the native speaker, we can change if needed
[06:19] <mohammad> just take a look here: http://osdir.com/ml/misc.persiancomputing/2004-06/msg00158.html
[06:20] <yosch> ScottK: mohammad has nicely agreed to join the fonts team and help the overall font efforts :)
[06:20] <ScottK> Sounds great.
[06:20] <yosch> mohammad: but I admit defoma is still misterious to me...
[06:21] <ScottK> The more of this work gets done in Debian, the better for all of us.
[06:21] <yosch> the goal is to enable the language communities to have good fonts and have packaging that make sense and is easier to maintain long term
[06:22] <yosch> ScottK: yep teamwork
[06:23] <mohammad> yosch, ScottK: I have to go, see you later
[06:23] <ScottK> See you later.
[06:24] <yosch> mohammad: OK bye
[06:38] <LaserJock> hi Nafallo
[06:38] <Nafallo> how much resources is needed for an ubuntuwirebox?
[06:48] <Nafallo> imbrandon: awake? ;-)
[06:50] <Nafallo> would C2D suffice or would C2Q be better? x86 + x86-64 builders
[06:51] <LaserJock> I think anything that boots would suffice ;-)
[06:52] <Nafallo> baah.
[06:52] <Nafallo> if I would do this I would want to do it proper.
[06:53] <LaserJock> Nafallo: maybe send imbrandon an email
[06:53] <Nafallo> probably place the server in the same building where Canonical has their servers as well.
[06:54] <Nafallo> LaserJock: good idea.
[07:02] <Nafallo> do we need ubuntuwire now that PPA is in place btw?
[07:05] <LaserJock> PPA is only i386 and amd64
[07:06] <LaserJock> and I'm starting to wonder if the build queue is going to be a problem
[07:06] <LaserJock> cbx33 uploaded a small package to his PPA yesterday and it took over 2hr before it got to the buildds
[07:06] <geser> and you can't debug an FTBFS on an arch you don't have on PPA
[07:07] <zul> heylo
[07:09] <Nafallo> the box I'm thinking of would be x86 and x86_64 as well
[07:10] <LaserJock> I think anything we get will be put to use
[07:10] <Nafallo> oki :-)
[07:10] <LaserJock> but it might be good to discuss it with a larger set of the team
[07:10] <LaserJock> I personally don't know how much the current machines are being used
[07:11] <Nafallo> agreed, and get pricing before I promise anything :-)
[07:11] <LaserJock> other than I know sparky has been running REVU for us
[07:11] <Nafallo> I think the current machines are offline, no?
[07:13] <Nafallo> 3wared RAID10 with WD RE2 at least.
[07:13] <Nafallo> that is probably as far as my spec has landed :-P
[07:14] <norsetto> hello any and all
[07:15] <Nafallo> and I would make sure it's in the same building as Canonicals racks
[07:15] <LaserJock> wahoo, we are gonna have a good Behind MOTU interview
[07:16] <norsetto> LaserJock: hmmm, I thought they were all good ....
[07:16] <LaserJock> well, they are
[07:16] <LaserJock> but it's been a while
[07:16] <LaserJock> and this will  be a good one
[07:17] <norsetto> LaserJock: is she good looking :-)
[07:18] <LaserJock> no, I wouldn't necessarily call him good looking. I'm sure his girlfriend would though ;-)
[07:18] <zul> argh...baby is on acid or something
[07:19] <LaserJock> ?
[07:19] <norsetto> how is sciovinist spelled? if I have to die for it at least I would like to be able to write it properly
[07:19] <LaserJock> zul: you're giving your baby acid?
[07:20] <zul> LaserJock: hes acting like he is on acid
[07:20] <LaserJock> you guys don't have any pot smokers around do you? :-)
[07:21] <zul> umm...no of course not
[07:21] <norsetto> chauvinist ... who would have thought
[07:22] <norsetto> !jdong
[07:22] <ubotu> jdong is Hobbsee: jdong: yes, but you're FULL OF CRACK!
[07:22] <jdong> who rang?
[07:22] <norsetto> .me hides behind laserjock
[07:23] <Nafallo> jdong: hi :-)
[07:23] <jdong> hi :)
[07:23] <norsetto> anyone feel like reviewing an easy one on REVU?
[07:24] <Nafallo> jdong: now that you're here. what's a good ubuntuwire box for x86 x86_64 when speaking resources?
[07:25] <norsetto> just in case: http://revu.tauware.de/details.py?upid=197. It should be an easy one
[07:25] <norsetto> zul: thx for the ditto
[07:26] <zul> norsetto: np
[07:27] <jdong> Nafallo: hmm, sorry, I woudln't know....
[07:27] <Nafallo> jdong: thought you built a lot of stuff :-P
[07:27] <geser> Nafallo: it can't never be to big
[07:29] <norsetto> geser: hi there
[07:29] <\sh> hey guys, if anyone has time, and is so nice to sponsor some uploads...please see bug 136544 , bug 136547 and bug 136552 , thx :)
[07:29] <ubotu> Launchpad bug 136544 in etoken "[FTBFS]  etoken " [Undecided,New]  https://launchpad.net/bugs/136544
[07:29] <ubotu> Launchpad bug 136547 in fxload "[FTBFS]  fxload (needs to be synced)" [Undecided,New]  https://launchpad.net/bugs/136547
[07:29] <ubotu> Launchpad bug 136552 in galculator "[FTBFS]  galculator " [Undecided,New]  https://launchpad.net/bugs/136552
[07:30] <Nafallo> geser: I know :-P
[07:30] <Nafallo> geser: but I should be able to afford it as well ;-)
[07:31] <geser> Hi norsetto
[07:32] <geser> \sh: can you subscribe u-u-s the next time so it doesn't get lost?
[07:32] <\sh> geser, u-u-s?
[07:34] <geser> ubuntu-universe-sponsors
[07:36] <norsetto> zul: for bug 131325: just to be sure, is it ok for me to send the package to REVU for review? Or should I wait until the bug report is confirmed?
[07:36] <ubotu> Launchpad bug 131325 in conky "Gutsy uses old version of conky." [Undecided,Fix committed]  https://launchpad.net/bugs/131325
[07:36] <\sh> done
[07:37] <\sh> ok..now switching to windows and fireing up css
[07:50] <xtknight> a package can still be in universe if the maintainer is Ubuntu Core developers ?  i was under impression that these packages would be main but is that not always the case?  Ubotu is saying universe for qt4-qtconfig
[07:51] <norsetto> xtknight: the criteria for the package to be in a certain repository is not related to the maintainer
[07:52] <geser> xtknight: a source package can be in main but a binary package in universe
[07:52] <xtknight> hmm
[07:52] <xtknight> is ubotu giving the location of the src package or the binary package?  since the debdiff would be of the source package qt4-x11?  (ubotu doesn't have qt4-x11 in its memory, though)
[07:53] <xtknight> a bit confused, i guess qt4-qtconfig is the binary and qt4-x11 is the source.  Bug 136425
[07:53] <ubotu> Launchpad bug 136425 in qt4-x11 "qtconfig-qt4 in Accessories?" [Undecided,New]  https://launchpad.net/bugs/136425
[07:53] <xtknight> i had a debdiff ready just not sure to subscribe ubuntu motu or ubuntu main
[07:54] <geser> ubotu knows only binary package (see also bug #135690)
[07:54] <xtknight> Bug 135690
[07:54] <ubotu> Launchpad bug 135690 in ubuntu-bots "ubotu doesn't handle source packages" [Undecided,New]  https://launchpad.net/bugs/135690
[07:55] <norsetto> xtknight: yes, qt4-x11 is a source package which provides, amongst others, qt4-qtconfig
[07:55] <xtknight> k, packages.ubuntu.com has qt4-x11.  it's universe
[07:55] <LaserJock> I filed a bug against ubotu for that, btw
[07:56] <xtknight> well, it was for dapper.  it's not mentioned for gutsy.  http://packages.ubuntu.com/gutsy/source/qt4-x11
[07:56] <norsetto> xtknight: qt4-x11 is reported in main
[07:56] <xtknight> ok so it was universe in dapper, main for gutsy
[07:56] <norsetto> xtknight: yes, its main for gutsy
[07:56] <xtknight> thanks
[07:56] <norsetto> xtknight: and indeed universe for dapper
[07:59] <norsetto> this package too: http://revu.tauware.de/details.py?upid=200 could do with some reviewing
[08:07] <LaserJock> ok everybody
[08:08] <LaserJock> Behind MOTU is up!
[08:13] <soren> ScottK: I thought the dpatches were pretty self-explanatory, actually. Anything in particular in there that isn't?
[08:18] <ScottK> soren: I could tell what they were from looking at them and the changelog, I just think it's a good general practice to say something in the dpatch comment line.  Not a big deal.
[08:46] <jdong> Lutin: hey are we gonna get ffmpeg medibuntu for gutsy? :)
[08:46] <Lutin> jdong: hopefully yes :)
[08:47] <jdong> Lutin: fantastic
[08:47] <Lutin> jdong: although I don't know when ... we're quite busy with gutsy stuff atm ;)
[08:48] <jdong> Lutin: okay, no rush
[08:58] <ScottK> norsetto: Ping
[09:13] <ScottK> norsetto: There's a new clamav revision from Debian, but with a little changelog fiddling your patch applied, so I'm using it and leaving your name on it.
[09:24] <norsetto> ScottK: as you wish, you can also use your name, I don't mind at all
[09:36] <norsetto> What would you guys say about a package that has its own copy of a library that its already in the repositories (although two different snapshots with some API incompatibilities).
[09:39] <geser> norsetto: for a security point of view the external copy should be used if possible
[09:40] <norsetto> geser: external you mean, the self shipped one?
[09:43] <broonie> No, you want to minimise the number of live copies of the library in the archive.
[09:44] <crimsun> norsetto: meaning don't use the bundled one if at all possible.
[09:44] <broonie> That way if there's a security problem in the library only one copy has to be updated.
[09:47] <norsetto> broonie, crimsun: I'm glad to hear it, it confirms what I think. But let me play the devil's advocate for a moment. In this case, we carry and old snapshot (09/06) while for this package the developer wants to use a more recent snapshot (08/07) otherwise his package will not work (or might not work totally correctly). The problem is that this lib (libspeex) is unstanble, and the API is still in development.
[09:48] <norsetto> broonie, crimsun: would it make sense to update our library too? Should we wait until the API is stable? Or we just impose our version upstream?
[09:52] <norsetto> broonie, crimsun: let me add that our version is in sync with Debian
[09:53] <crimsun> I think it would be very unwise to bundle a snapshot if we were in the 8.04 LTS dev cycle.  Given that we're not, I'm a bit less rigid.  You should assess how risky it will be to bundle a snapshot where the API is known to be a moving target.
[09:56] <crimsun> 1) Despite -backports and -updates being options, we should act as if binary packages will only be installed once and not updated via any mechanism.  Will the program using the libspeex snapshot be stable and useful for 18 months?
[09:57] <norsetto> crimsun: perhaps we can be pragmatic, the supposedly stable api is now in beta, so it could make sense to wait until this is officially released, which should be in time for 8.04
[09:58] <geser> norsetto: given that libspeex1 has some rdepends, it's questionable if updating libspeex is a wise option
[09:58] <crimsun> 2) Since our resources for Universe are limited, remaining synced with Debian's source versions poses less of a risk, generally, than bundling our own.
[09:59] <crimsun> 3) Since speex is a main source package, my opinion is that we should not bundle further updates of our (Ubuntu) own this late in this dev cycle.
[09:59] <crimsun> [to which geser has alluded]
[10:04] <norsetto> thanks, I think I have enough munitions
[10:08] <norsetto> sorry, I forgot to give the bug number. Its bug 129081; I'm summarising the result of our discussion here, feel free to add to it if you think it necessary
[10:08] <ubotu> Launchpad bug 129081 in ubuntu "[needs-packaging]  Mumble" [Wishlist,In progress]  https://launchpad.net/bugs/129081
[10:20] <xtknight> what should i do about bugs like this?  Bug 136641 and 136643    they say that SVN fixes an issue, does that mean we should update mono to svn, or does it mean we should find which patch fixed the problem and backport it to the current version?
[10:20] <ubotu> Launchpad bug 136641 in mono "Mono: Exception attempting to join IPv6 multicast group" [Undecided,New]  https://launchpad.net/bugs/136641
[10:20] <ubotu> Launchpad bug 136643 in mono "Mono: System.Net.Sockets.SocketOptionName 0xe is not supported at IPv6 level" [Undecided,New]  https://launchpad.net/bugs/136643
[10:20] <LaserJock> xtknight: the latter at this point
[10:21] <xtknight> if i try and work on it, should be "In Progress" and assigned to me?
[10:21] <LaserJock> sure
[10:21] <xtknight> thx
[10:22] <xtknight> LaserJock, now there will probably be two patches for both of these.  do i need to a debdiff for each or should i just do one debdiff and do both at once?  (since if the package is updated my same old debdiff may have trouble applying)
[10:23] <LaserJock> one debdiff should suffice
[10:24] <xtknight> one debdiff that fixes both at once?
[10:24] <LaserJock> yes
[10:24] <xtknight> k
[10:26] <norsetto> LaserJock: I thought BMOTU was out already!?
[10:28] <geser> xtknight: I haven't checked if mono uses a patch system but if yes: put each fix into an own patch but you can provide only one debdiff for both bugs (containing both patch files)
[10:29] <xtknight> geser, ok
[10:34] <norsetto> LaserJock: http://laserjock.us/files/geser_screenshot.jpg => Page not found (geser: only 2 desktops: booooo :-))
[10:36] <cbx33> ping imbrandon
[10:36] <ScottK> norsetto: Uploaded already.  Used your name since you did all the work.
[10:37] <norsetto> ScottK: actually, you did it, but never mind
[10:38] <norsetto> scottK: well, my patch its your stuff (I only added the dependancies changes)
[10:38] <ScottK> norsetto: If you are feeling guilty, expunge your guilt by filing Debian bugs on the differences .... ;-)
[10:39] <ScottK> Wow.  It even built for lpia already....
[10:39] <norsetto> superm1: if you ever read this, your desk is a shame on the hackers category (not even a crust of old pizza....)
[10:41] <norsetto> scottK; hehe, you volunteered already to file that bug :-D
[11:06] <LaserJock> norsetto: where was that link?
[11:07] <norsetto> laserjock: geser's interview I think
[11:12] <norsetto> scottK: do you remember by any chance which executable required libcurl? Can't find any with ldd :-(
[11:13] <LaserJock> norsetto: k, fixed
[11:15] <ScottK> In clamav?
[11:15] <norsetto> scottK: yes
[11:15] <ScottK> norsetto: ^^
[11:16] <ScottK> It was all the ones that I listed the dependency for it (3 IIRC).
[11:16] <ScottK> I confess to guessing on the -dev dependency
[11:17] <prak> is there a piklab on the list?
[11:18] <norsetto> scottK: these 3 then: clamav-freshclam, clamav-milter, clamav-daemon. I didn't check the last two yet, but freshclam seems libcurl free
[11:19] <nixternal> woo, new behind motu :)
[11:21] <ScottK> Hmmm
[11:21] <ScottK> norsetto: clamd definitely died with no libcurl.
[11:22] <norsetto> cesare@desktop:~/clamav/clamav-0.91.2$ ldd /usr/sbin/clamd
[11:22] <norsetto>         libclamav.so.2 => /usr/lib/libclamav.so.2 (0x00002b4091987000)
[11:22] <norsetto>         libnsl.so.1 => /lib/libnsl.so.1 (0x00002b4091c26000)
[11:22] <norsetto>         libpthread.so.0 => /lib/libpthread.so.0 (0x00002b4091e3f000)
[11:22] <norsetto>         libc.so.6 => /lib/libc.so.6 (0x00002b409205a000)
[11:22] <norsetto>         libz.so.1 => /usr/lib/libz.so.1 (0x00002b40923b6000)
[11:22] <ScottK> Maybe it got fixed in the 0.91.2 release.  The 0.91 changelog claimed they had dropped libcurl.
[11:22] <norsetto>         libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00002b40925cd000)
[11:22] <norsetto>         libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00002b40927dd000)
[11:22] <norsetto>         /lib64/ld-linux-x86-64.so.2 (0x00002b4091769000)
[11:22] <joejaxx> norsetto: please use pastebin
[11:22] <norsetto> joejaxx: sorry
[11:23] <ScottK> norsetto: Force remove libcurl and start clamd.  If it doesn't die, then I'll believe ldd.
[11:23] <joejaxx> norsetto: no problem :)
[11:23] <joejaxx> nixternal: where do you see the new behind motu?
[11:23] <nixternal> planet ubuntu
[11:24] <joejaxx> ok
[11:25] <norsetto> ScottK: if I remove libcurl I remove half of my packages too .....
[11:25] <ScottK> OK.  Let me try.
[11:36] <ScottK> norsetto: I see what you mean.
[11:37] <prak> is there a piklab on the list?
[11:37] <ScottK> I'm building a non curl version now.  I should be able to install that on another machine that doesn't have X
[11:37] <prak> for the deb packages?
[11:37] <prak> or any plans of doing so?
[11:37] <ScottK> prak: Are you asking if anyone has packaged it?
[11:38] <prak> yes
[11:38] <prak> or planning to package it?
[11:38] <prak> i used to be able to look it up on adept/synaptic, but can't do it anymore
[11:38] <ScottK> Hmm.  I didn't see it on Launchpad, so I don't think it's packaged.
[11:39] <ScottK> For Gutsy, we are not accepting new packages anymore.
[11:39] <norsetto> scottK: yeah, I've build one too
[11:39] <prak> ScottK: ok
[11:39] <Baby> which package?
[11:40] <ScottK> prak: I don't see a needs-packaging bug either, so I doubt anyone has plans.
[11:40] <ScottK> Baby: piklab
[11:40] <Baby> hmmm it is for pic processors, isn't it?
[11:40] <ScottK> prak: ^^^
[11:42] <Baby> it would be nice to have piklab in debian too, btw
[11:42] <Baby> doesn't seem to be there
[11:45] <geser> MOTU now also maintains packages in Debian?
[11:46] <Baby> nope, afaik
[11:46] <Baby> but i'm interested in PICs :)
[11:46] <norsetto> geser: U = Universe .....
[11:46] <Baby> so I'll probably file an ITP for that
[11:46] <geser> http://packages.qa.debian.org/g/gcc-snapshot/news/20070830T230223Z.html
[11:47] <ScottK> It would be nice if someone would make that stop.
[11:48] <Baby> stop what?
[11:49] <ScottK> doko apparently uploaded something to Debian with MOTU still set as maintainer.
[11:49] <ScottK> doko: http://packages.qa.debian.org/g/gcc-snapshot.html
[11:49] <ScottK> So our mailing list is getting the bugmail.
[11:50] <mr_pouit> ^^'
[11:51] <doko> ScottK: shit happens
[11:51] <ScottK> It does.
[11:57] <Baby> prak: I'll probably package piklab for Debian, I've just emailed upstream about that, so I guess it'll enter Ubuntu afterwards
[11:57] <Baby> if anyone else is interested in packaging it, please get in contact with me :)
[11:57] <prak> Baby: how long do you think it will take?
[11:58] <prak> and will it be in the Debian repository?
[11:58] <Baby> yup
[11:58] <Baby> probably 2 or 3 weeks
[11:59] <Baby> and then whatever it takes to Ubuntu to syncronize with Debian SID
[11:59] <ScottK> For Ubuntu it won't be until after Gutsy releases.
[11:59] <Baby> yup I guess so
[12:00] <Baby> but I don't know how much time that'll be
[12:00] <Baby> piklab seems a really cool program
[12:00] <Baby> i didn't know about it
[12:01] <prak> Baby: it looks like it's the only program which supports my current PIC programmer
[12:01] <prak> in linux
[12:01] <prak> I've been having problems with mplab and PicKit 2 programs in Windows
[12:02] <prak> always freezes
[12:03] <ScottK> Note that once stuff is uploaded to the "Hardy Herron" repositories, it can be backported to gutsy-backports after Gutsy is released.
[12:07] <Baby> prak: once I have it ready, in one or two weeks, we can port it to gutsy and try it in your system if you want
[12:07] <prak> Baby: thank you
[12:07] <Baby> :)
[12:08] <Baby> there's already a quick and dirty package for it, it seems
[12:08] <Baby> so i won't have to start from scratch
[12:14] <prak> what do you mean, Baby?
[12:14] <prak> rpm?
[12:14] <Baby> .deb
[12:15] <Baby> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387703
[12:15] <ubotu> Debian bug 387703 in wnpp "RFP: piklab -- IDE for PIC and dsPIC microcontrollers" [Wishlist,Open]
[12:15] <Baby> http://www.janw.dommel.be/piklab/i386/
[12:17] <Baby> but it doesn't even have the build-dependencies OK
[12:18] <prak> what do you mean about the build-dependencies?
[12:18] <Baby> if you want to create the binary package from the source
[12:19] <Baby> anyway, enough for today :)
[12:19] <Baby> goodnight all!
[12:20] <norsetto> bye bye
[12:23] <prak> Baby: turns out that i can install a older version of piklab that has a deb package
[12:23] <prak> thanks for your help
[12:29] <norsetto> time to go
[12:30] <norsetto> g'bye all, good luck scottK ;-)


[01:08] <lamont> so ia32-libs is 560MB of so-called source, and we're ok with that beast?  I mean, I know it's "just temporary until multiarch is done in 2006" and all that, but really...couldn't we break it up even a little?
[01:11] <TheMuso> lamont: I believe there is a plan to reduce it somewhat. I know for one that pulseaudio and its dependencies will probably have bi-arch packages in the coming months. Not elligant by any means, but better than nothing.
[01:11] <lamont> TheMuso: it was more one of we could split it up into ia32-libs-XX for some value of XX
[01:20] <TheMuso> lamont: right
[01:21] <TheMuso> lamont: I think cjwatson was working on reducing ia32-libs somewhat, not sure what he has in mind though.
[01:22] <cjwatson> it's certainly not worth splitting it up by any means other than creating individual biarch packages (which I haven't got round to yet, but may well do for pulseaudio). I don't know the current state but slangasek is pretty gung-ho about getting multiarch actually in place for 9.10
[01:22] <lamont> yay!!!
[01:23] <TheMuso> cjwatson: Well if user bug reports re audio/pulse are anything to go by, bi-arch packages for pulseaudio are the best bet if multi-arch doesn't happen.
[01:24] <cjwatson> right, I just didn't get time for a4
[01:24] <TheMuso> right thats fine.
[01:35] <directhex> cjwatson, i think he's off his rocker given i've been watching zero happen on that front since 2004. but hey, let's see!
[01:38] <cjwatson> directhex: there's a serious design that actually got widespread consensus at debconf (I nearly fell off my chair), and actual code being written
[01:38] <directhex> blimey
[01:38] <directhex> whatever next, HURD being usable?
[01:40] <cjwatson> not to say it isn't still pretty challenging as a target, but it isn't quite the outer-space thing I thought it was going to be when he proposed it for karmic :)
[01:48] <directhex> so when's alpha 4 ready? :p
[02:26] <billybigrigger> ctrl-alt-bkspace works i guess
[03:28] <TheMuso> cd ..
[03:28] <TheMuso> woops
[04:51] <ojwb> when preparing an upload for a PPA, is there an easy (ideally scriptable) way to tell if the orig source needs to be uploaded?
[04:52] <ojwb> it seems I can just always upload it, but that seems a bit wasteful
[05:10] <fabrice_sp> ojwb, for ppa's question, better ask in #launchpad
[05:11] <ojwb> ta
[06:22] <TheMuso> c
[06:52] <dholbach> good morning
[07:58] <gp_will_be_back> is the intel graphic driver issue in jaunty has been fixed ?
[08:57] <gp_will_be_back> is the intel graphic driver issue in jaunty has been fixed ? -> is there a patch ?
[09:28] <ogra> cjwatson, so it looks like rtg built the linux-fsl package with a full set of udebs (https://launchpad.net/ubuntu/+source/linux-fsl-imx51/2.6.31-0.2/+build/1157092) do you think i can save my energy and not hack around in debian-cd now ?
[09:29] <ogra> (i guess it still requires d-i adjustments)
[09:31] <cjwatson> ogra: sure, if they're about the right shape you shouldn't need further hacks
[09:32]  * cjwatson pokes
[09:32] <ogra> great, i'll only change livecd-rootfs then ... once i know for sure how they want to call the new metapackage
[09:33] <cjwatson> you'll have to make d-i or debian-cd or whatever build from universe too, I'm not really comfortable with putting this in main just yet
[09:33] <ogra> oh
[09:33] <cjwatson> that shouldn't be difficult
[09:33] <ogra> i guess that requires some tinkering in livecd-rootfs too
[09:33] <cjwatson> hardly major
[09:33]  * ogra goes to look
[09:34] <cjwatson> binaries accepted
[09:34] <geser> can a buildd admin please give back "bogl", "cheese" (both CHROOTWAIT) and "liblauncher" (Failed to upload). thanks
[09:34] <ogra> thanks :)
[09:34] <cjwatson> geser: doesn't need a buildd admin, any uploader can give stuff back
[09:35]  * ogra wonders why he gets a Conflicting tags: 0.69 with bzr pull of livecd-rootfs
[09:35] <geser> right
[09:35] <StevenK> I'm not comfortable giving liblauncher back, I don't understand the error Soyuz is throwing
[09:37] <cjwatson> cheese appears to be successfully built everywhere already
[09:37] <cjwatson> I've retried bogl
[09:47] <ogra> does that diff look ok for livecd-rootfs ? http://paste.ubuntu.com/251232/
[09:50] <ogra> well, it wont break anything but my own images anyway ....
[09:50] <geser> StevenK: liblauncher got promoted to main while the buildd tried to upload the debs, so for soyuz liblauncher was in both universe and main till the next publisher run (as far as I understand it)
[09:50]  * ogra commits and uploads
[09:53] <cjwatson> ogra: yes, except temporary -> temporarily
[09:53] <ogra> whoops
[09:53] <cjwatson> ogra: though surely multiverse is overkill ...
[09:53] <ogra> i just copied the xubuntu line :)
[09:53]  * ogra fixes
[09:59] <ogra> pushed
[10:24] <dholbach> warp10:
[10:24] <dholbach>  _   _    _    ____  ______   __  ____ ___ ____ _____ _   _ ____    _ __   ___
[10:24] <dholbach> | | | |  / \  |  _ \|  _ \ \ / / | __ )_ _|  _ \_   _| | | |  _ \  / \\ \ / / |
[10:24] <dholbach> | |_| | / _ \ | |_) | |_) \ V /  |  _ \| || |_) || | | |_| | | | |/ _ \\ V /| |
[10:24] <dholbach> |  _  |/ ___ \|  __/|  __/ | |   | |_) | ||  _ < | | |  _  | |_| / ___ \| | |_|
[10:24] <dholbach> |_| |_/_/   \_\_|   |_|    |_|   |____/___|_| \_\|_| |_| |_|____/_/   \_\_| (_)
[10:24] <dholbach>
[10:24] <hyperair> O_O
[10:25] <wgrant> StevenK: "Duplicated ancestry" really means "I am terribly confused by the override that occurred while the build was doing its thing"
[10:25] <warp10> dholbach: :D man, that's awesome! Thank you very much! :)
[10:25] <seb128> for those who didn't notice, dholbach is back ;-)
[10:26] <ogra> haha
[10:26] <dholbach> :-D
[10:26] <warp10> :D
[10:26] <highvoltage> wb dholbach :)
[10:26] <dholbach> hey highvoltage :)
[10:28] <ogra> ugh, who did give back qt4-x11 on armel
[10:28] <ogra> mcasadevall, ^^^ was that you ?
[10:29] <ogra> oh, there was an actual upload, nevermind me then
[10:51] <StevenK> wgrant: So a giveback will clear it?
[10:51] <wgrant> StevenK: Yes.
[10:52] <wgrant> In this case the override actually occurred just before the build started, but the key bit is that the publisher didn't run between the override and the build finishing.
[10:53] <wgrant> The publisher has hopefully run in the past three days, so it should be fine now.
[11:35] <YokoZar> Hey could someone with an ATI card on amd64 do me a quick favor and ldd /usr/lib32/libGL.so.1 (with ia32-libs installed) ?
[12:14] <mdz> has anyone else seen bug 411889 happen?
[12:16] <sladen> not, but one should depend on the other if it's enhancing it
[12:17] <sladen> (that __init__ file should only be present in python-desktopcouch, not python-desktopcouch-records aswell
[12:18] <YokoZar> Who would be the right person to talk to about upload.ubuntu.com -- I want to use sftp rather than anonymous ftp (because dput keeps failing with ftp due to my internet provider, but sftp works) ?
[12:24] <liw> YokoZar, is your dput configured to use "passive ftp"?
[12:24] <damo22> how do i blacklist a udev module in ubuntu?
[12:25] <damo22> i dont want ubuntu to claim my usb printer
[12:30] <wgrant> YokoZar: upload.ubuntu.com is Launchpad. But SFTP is a completely different protocol from FTP, and LP uses a custom FTP server, so it's not at all easy to change.
[12:31] <wgrant> But it is intended that the FTP upload mechanism will be replaced soonish, I believe.
[12:38] <MacSlow> Does anybody know this sort of bug with VirtualBox 3.0.4 and recent Karmic -> http://people.canonical.com/~mmueller/VirtualBox-3.0.4_bug.png
[12:38] <MacSlow> Initial install went fine
[12:39] <MacSlow> Updating to Guest-Additions worked fine
[12:39] <MacSlow> then updated to the latest packages I got this garbage once gdm starts
[12:40] <MacSlow> it's with Karmic using kernel 2.6.31-5-generic
[12:54]  * cjwatson debugs root-on-iSCSI into existence. Woo
[13:05] <YokoZar> liw: dput is at default, the issue is my comcastic internet connection that likes to forge reset packets
[13:43] <cjwatson> soren: do these tasks look plausible to you? http://paste.ubuntu.com/251338/
[13:44] <cjwatson> soren: hmm, perhaps openssh-server on the node too
[13:45] <soren> cjwatson: The node controller shouldn't need a dhcp server.
[13:46] <soren> Err..
[13:46] <soren> I must admit, though, that the current packaging seems to suggest otherwise.
[13:46] <soren> Now I'm confused. :)
[13:48] <soren> cjwatson: I'll check up on that. It looks odd. Other than that, it looks reaonable.
[13:49] <Ng> I'm pretty sure dhcp3-server is unnecessary at best on a node controller
[13:49] <cjwatson> soren: it doesn't actually seem to use it, so seems like a packaging bug
[13:50] <soren> I wonder why a) it ended up there to begin with and b) why noone has complained :)
[13:50] <cjwatson> soren: eucalyptus-cc needs it though, doesn't it?
[13:50] <soren> cjwatson: I believe so.
[13:50] <Ng> yes
[13:50] <cjwatson> and it doesn't seem to be listed among its dependencies ...
[13:51] <soren> No. That's why I'm wondering why noone complained.
[13:51] <cjwatson> I'll bung it into the eucalyptus-simple-cluster task for now then
[13:51] <Ng> hmm, you could argue it's not a hard dependency though, the default networking mode just needs a dhcp server to be present on your network
[13:51] <soren> Ng: The default networking mode in Jaunty, yes.
[13:51] <soren> Ng: Karmic will default to MANAGED.
[13:51] <Ng> soren: bold :)
[13:52] <cjwatson> how about I take it out of the task for now then since we don't have the new euca yet
[13:54] <Laney> anyone fancy looking at the cdbs ftbfs? bug 409863
[13:54] <soren> cjwatson: Makes sense.
[13:55] <soren> cjwatson: At least we're consistent in our buggy dependencies then :)
[13:56] <Ng> soren: hrm, shouldn't -cc depend on bridge-utils too?
[13:56] <soren> Ng: I would have thought so, yes.
[14:13] <ScottK> cjwatson: I'm looking at updating kubuntu-meta and you've TIL.  It appears you updated it using the Sid deboostrap because I get "/usr/bin/germinate-update-metapackage: Installed debootstrap is older than in the previous version! (1.0.13 < 1.0.15)".  What's the best way to proceed from here?
[14:14] <ScottK> Imagine I spelled debootstrap correctly in the last line please.
[14:21] <cjwatson> ScottK: oh, bah, good catch. I don't want to sync that into Karmic right now for various reasons - how about you just manually edit the debootstrap-version file?
[14:22] <ScottK> cjwatson: I can do that, just thought I should check with you first in case there was a reason  not to.
[14:22] <ScottK> Thanks.
[14:23] <cjwatson> no, it should be ok
[14:23] <cjwatson> in this case anyway
[14:24] <ScottK> It's running.  Thanks again.
[15:09] <ogra> seb128, gah, you are to fast ... (/me wanted to ask if all of sbalneavs ubuntu fixed went into sabayon before that gets uploaded)
[15:10] <ogra> (i didnt see his name mentioned in the changelog, but i know all edubuntu users use his ppa packages nowadays)
[15:11] <seb128> not sure if his changes are in the new version I didn't know there was a ppa
[15:11] <ogra> i know he did the xephyr transition and sent that upstream
[15:11] <ogra> but i'm not sure all of his patches are in, i'll ask him to check if i see him around
[15:12] <ogra> i only follow edu stuff with half an eye nowadays
[16:27] <ogra> StevenK, poke, can i ask for de-NEWing linux-meta-fsl-imx51 ?
[16:39]  * ogra assumes StevenK went to bed (which would be valid at nearly 2am :) )
[16:39] <ogra> could any archive adimn take a look at linux-meta-fsl-imx51 and wave it through the NEW queue ?
[16:39] <ogra> *admin
[16:48]  * ogra jumps up and down waving his arms to get archive admin attention
[16:49] <amitk> no #archive ?
[16:50] <ogra> nope
[16:50] <ogra> i know colin would help immediately if i pinged him directly, but i want the load being shared
[16:53] <hyperair> didn't you just ping him directly?
[16:53] <ogra> nope
[16:53] <ogra> i doubt he highlights on his real name :)
[16:55] <hyperair> ahaha
[16:59]  * ogra starts to glow in rotating colors to get some more attention, jumping and waving doesnt seem to help ...
[17:03] <Laney> so ping someone else directly?
[17:07] <highvoltage> Not sure if you guys saw this yet:  http://lwn.net/Articles/346400/ (etch and feisty comparison in terms of common packages)
[17:10] <ogra> 1079 Ubuntu has Vebian bersion with ubuntuXX patch
[17:10] <ogra> ????
[17:10] <ogra> funny typoing :)
[17:18] <ScottK> Two of those updates only make sense if you update clamav to a newer version in Etch, which Debian won't do.
[17:19] <ScottK> Oddly the analysis misses a bunch of the other clamav rdepends.
[17:19] <ogra> ScottK, you dont feel like taking a look at linux-meta-fsl-imx51 ? (since you made the mistake to speak here *and* are archive admin :) )
[17:20] <ScottK> ogra: There is specialness about kernel packages that the LP U/I can't handle.
[17:20] <ScottK> Sorry.
[17:20] <ogra> it will stay in universe and vanish after alpha
[17:20] <ogra> oh, its only meta though
[17:30] <ogra> seb128, you dont happen to have some spare minutes to let linux-meta-fsl-imx51 out of NEW ? (its only a metapackage)
[17:31] <seb128> no
[17:31] <seb128> we have a meeting starting right now
[17:34]  * amitk is reminded of Scrat and his acorn from Ice Age when seeing ogra and his linux-meta-fsl-imx51 package :)
[17:34] <ogra> heh
[17:35] <ogra> amitk, well, if nothing helps i'll ping cjwatson but he does so much already that i wanted to put the load on someone else
[17:35] <amitk> you just did :-p
[17:35] <ogra> though a meta review is really trivial i think
[17:35] <ogra> amitk, yes, deliberately :)
[17:36] <ogra> since all the other archive admins are busy or not around
[17:36] <slytherin> ogra: is it usually easy the bug the archive admin who is assigned for the day.
[17:37] <kenvandine> slangasek, ping
[17:38] <ogra> slytherin, meh, i forgot to look at the schedule on the wikipage, thanks for reminding
[17:38] <ogra> Riddell, poke, can you unleash linux-meta-fsl-imx51 from NEW ?
[17:41] <slangasek> kenvandine: hi
[17:41] <kenvandine> slangasek, so can you get xsplash on the desktop seed?
[17:42] <slangasek> kenvandine: working on some other critical-path stuff at the moment, but I'll have a look at it later this morning
[17:42] <kenvandine> ok
[17:42] <kenvandine> please do
[17:42] <ogra> kenvandine, is there artwork already ?
[17:42] <kenvandine> pitti had verbally approved it
[17:42] <kenvandine> ogra, there is better temp artwork
[17:42] <ogra> (if i install it do i get the shiny stuff ?)
[17:43] <kenvandine> right now it is the default wallpaper
[17:43] <kenvandine> :)
[17:43]  * ogra would love to test it
[17:43] <ogra> ah
[17:43] <kenvandine> there are a couple of flickers and gdm needs to start sooner
[17:43] <kenvandine> so it isn't the final experience of course
[17:44] <kenvandine> but it is important that we get it on alpha4 :)
[17:44] <ogra> yeah, i wasnt expecting anything final :)
[17:44] <kenvandine> we really want bug reports, et
[17:44] <kenvandine> +c
[17:45] <slytherin> what is xsplash?
[17:45] <james_w> ogra: I don't think there's a need for it to explain the history of linux in debian/copyright given that it's just a metapackage
[17:45] <ccheney> so we still have a splash, no < 3s to gdm? :-\
[17:45] <james_w> plus, Vcs-Git is invalid
[17:46] <ogra> james_w, i'll tell rtg, the package will vanish after A4 again anyway
[17:46] <ccheney> kenvandine: or is the < 3s to gdm still expected once it has moved?
[17:46] <james_w> ogra: ok, thanks
[17:46] <ogra> james_w, no, thanks to you for unleashing it :)
[17:46] <kenvandine> ccheney, not sure how fast it will be
[17:47] <ccheney> kenvandine: ok
[17:47] <ccheney> iirc the plan was to not show splash if gdm came up in ~ 3s
[17:47] <kenvandine> slytherin, the new boot experience stuff for karmic
[17:47] <slytherin> ccheney: isn't 3s overly optmistic?
[17:47] <ogra> ccheney, it is covering the black screen X had by default on startup
[17:47] <kenvandine> ccheney, well you shouldn't see usplash
[17:47] <kenvandine> but you should see xsplash
[17:47] <slytherin> kenvandine: using kms?
[17:47]  * ccheney wasn't at the sprint though so plans might have changed
[17:47] <kenvandine> the idea is xsplash start with gdm and fades out when gdm is completely ready for you to login
[17:48] <kenvandine> then when you login, xsplash raises again until the desktop is completely loaded and fades out
[17:48] <kenvandine> so a nice smooth experience
[17:48] <ccheney> kenvandine: ah ok, i think that was a change from uds, but sounds more realistic anyway :)
[17:48] <kenvandine> it is a change
[17:48] <slytherin> ahh ,good
[17:48] <slytherin> i thought it was something like plymouth
[17:49] <kenvandine> no... no point
[17:49] <kenvandine> our boot will be so fast :)
[17:49] <ogra> pfft
[17:49] <ogra> my laptop still takes 25sec
[17:49] <superm1> kenvandine, so usplash remains seeded/installed right?
[17:49] <kenvandine> yes
[17:50] <kenvandine> ogra, mine too... but people have great goals
[17:50] <superm1> will it actually show up before xsplash takes over, or is the intention to not even run usplash when xsplash is available to be used?
[17:51] <ogra> kenvandine, well, for me modprobe hangs in a 10sec loop, i doubt that will be fixed (hw doesnt respond) so i'll always have +10sec
[17:51] <kenvandine> superm1, you shouldn't see usplash at all
[17:51] <kenvandine> unless it fails to start X or something
[17:51] <kenvandine> basically usplash should only be seen if something is wrong :)
[17:52] <kenvandine> right now you will still see usplash
[17:52] <superm1> kenvandine, ah okay
[17:52] <kenvandine> until gdm gets moved to the beginning of the boot sequence
[17:52] <kenvandine> that will happen post alpha4
[17:52] <kenvandine> it is incremental :)
[17:52] <kenvandine> we just want to get it out there now so we can get bug reports, etc
[17:53] <ogra> james_w, can i get a binary NEW as well from you ? (yes it already built :) )
[17:55] <james_w> ogra: for main?
[17:55] <ogra> no, universe
[17:55] <ogra> that package will never enter main
[17:56] <ogra> it is only temporary for A4
[17:56] <ogra> (we build the arm image from universe atm)
[17:57] <ogra> the arm kernel naming is still being discussed, its likely to change right after A4
[17:58]  * slytherin wonders if any archive admin can review jmeter (arch all).
[18:07] <slangasek> ogra: eh, why are the kernel names changing again
[18:07] <slangasek> ?
[18:08] <ogra> slangasek, bug 411968
[18:09] <ogra> slangasek, in our (mobile team) opinion the naming is wrong, but we postponed the discussion until after A4 to get the image out for now
[18:10] <slangasek> I had already spoken to rtg about that last week, and he says the hardware that worked with the jaunty kernel doesn't work with the karmic kernel and vice versa
[18:10] <slangasek> so there would be no reason to provide a direct upgrade path
[18:10] <ogra> thats not true
[18:10] <ogra> thats not true either
[18:10] <slangasek> then I suppose you should make that clear to rtg in the bug
[18:10] <ogra> the HW that worked in jaunty will go on working
[18:10] <ogra> plus there will be two more iterations of the SoC that will work with it
[18:11] <ogra> and we would like to have the ability to add two additional ones the oem team cares for later (karmic+1 probably)
[18:12] <ogra> so the SoC name should be the name of the image/metapackage as it was in jaunty
[18:12] <ogra> but we'll discuss that *after* A4 as i said
[18:20] <crimsun> kklimonda: see my audio-fixes branch ubuntu-karmic.git branch if you want to test-compile
[18:20] <crimsun> wow, completely screwed that one
[18:30] <lool> slangasek: I noted that in the bug report
[18:32] <lool> slangasek: IMO it's wrong to name the kernel flavour after the board instead of the soc because we might want to support multiple boards with the same kernel flavour; I also believe that Babbage 1 (supported in jaunty) will work in karmic albeit I don't think that's a hard requirement -- the bootloaders are incompatible though
[18:32] <ogra> well, we already have one bootloader that clearly supports 2 boards ... so you never know :)
[18:32] <ogra> (babbage 2.0 and 2.5)
[18:37] <lool> ogra: But we know for sure b1 and b2.x bootloaders are incompatible just like lange versus babbage bootloaders
[18:38] <ogra> yes
[18:38] <lool> So I _do_ know
[18:38] <lool> ;)
[18:38] <ogra> but who knows, b3 might use the same as b2 and 2.5
[18:38] <lool> Yeah but b1 wont
[18:38] <ogra> indeed
[19:49] <directhex>  f-spot (<IP_ADDRESS>-1) unstable; urgency=low
[19:53] <seb128> directhex, right was uploaded to karmic before as a fake sync
[19:55] <directhex> it was? :o
[19:57] <sebner> directhex: f-spot (<IP_ADDRESS>-1~ubuntu1) karmic; urgency=low
[19:57] <sebner> directhex: https://edge.launchpad.net/ubuntu/+source/f-spot ;)
[19:57] <directhex> hax!
[19:58] <seb128> directhex, I did sync the new mono too today
[19:59] <sebner> seb128: still archive admin? then sync cli-common too please, directhex didn't need a main ACK, I got one :P
[19:59] <seb128> sebner, bug number?
[20:00] <sebner> seb128: 410744
[20:00] <sebner> seb128: bug #410744
[20:03] <seb128> sebner, done
[20:04] <sebner> seb128: my hero \o/, thanks :)
[20:04] <seb128> you're welcome
[20:05] <directhex> yay for seb128
[20:06] <directhex> seb128, barring bugs, i think that should be it for mono in karmic... although i'm leaning on meebey to make a small change which should save us 200k
[20:07] <seb128> directhex, sebner: could one of you look if gnome-desktop-sharp2 can be synced?
[20:07] <seb128> the diff seems to be non ubuntu specific
[20:07] <seb128> ie could be fixed in debian now
[20:19] <Jukada> hey
[20:20] <Jukada> k
[20:28] <slangasek> ogra: so why is arm being built from universe?  that's not a good thing, and I don't think we should be propagating that further by putting the kernels in the wrong place
[20:30] <slangasek> kenvandine: should xsplash replace usplash in the platform desktop-common seed, or is there a reason this needs to be Ubuntu-only right now?
[20:30] <kenvandine> slangasek, it doesn't replace
[20:30] <slangasek> hmm?
[20:30] <kenvandine> it is desktop specific though, needs X and gdm
[20:30] <kenvandine> if all is good you won't see usplash
[20:30] <kenvandine> but we want usplash to be there if something goes wrong
[20:31] <slangasek> usplash is only in the desktop-common seed, that already implies X (but doesn't imply gdm in the case of kubuntu)
[20:31] <slangasek> ok
[20:31] <kenvandine> ok
[20:31] <slangasek> alright, seeded & promoted
[20:31] <kenvandine> woot
[20:32] <kenvandine> thanks slangasek!
[20:32] <slangasek> now I just need to get eglibc vetted, and we can start building us some ISOs
[21:21] <ScottK> mcasadevall: Can you look at dbus on ia64?  Looks like a missing include to me, but I've got no way to test.
[21:23] <mcasadevall> ScottK, *groan* that's a linker error
[21:23] <mcasadevall> ScottK, I'll put it on my TODO list, but it probably won't get looked at until post-A4
[21:24] <ScottK> mcasadevall: That's fine.
[21:24] <mcasadevall> ScottK, anyway, its possible qt4-x11/lzma weirdness might be fixed
[21:24] <ScottK> mcasadevall: Excellent.  With the one that's building right now perhaps?
[21:24] <mcasadevall> ScottK, that's our test
[21:24] <ScottK> err .... was last I looked.
[21:25] <mcasadevall> ScottK, its still going
[21:25] <mcasadevall> No idea if it will finish or not
[21:26] <mcasadevall> ScottK, if it works, woo, if not, then common sense has been let go on this bug
[22:22] <infinity> mcasadevall: qt4-x11 seems to have finished successfully, BTW.
[22:25] <billisnice> I have a request?
[22:26] <billisnice> When you are updating and it say to run  sudo dpkg --configure     Have the update manager run it automatically without telling you to...
[22:28] <billisnice> sudo dpkg --configure -a
[22:48] <docelic> Hey folks, any idea why "passwd/make-user= false" question during preseed would be ignored? It's delivered in the http preseed file, but the system still asks to create the user (name, username, password etc..)
[22:51] <cjwatson> docelic: you'll have to create a root user; user-setup won't allow you to install with no user at all
[22:52] <cjwatson> so 'd-i passwd/root-login boolean true' 'd-i passwd/root-password password blah' 'd-i passwd/root-password-again password blah'
[22:52] <cjwatson> (or passwd/root-password-crypted. see the guide)
[22:53] <docelic> ah! many thanks, root-login was the thing I missed
[22:54] <docelic> also, the example-preseed.txt file (in the docs from 9.04) has a mistake in one field, let me tell you which one
[22:55] <docelic> Question clock-setup/ntp-server
[22:55] <docelic> the third field (type = string) is missing
[23:08] <cjwatson> docelic: thanks; that was fixed a little while back in Debian and is fixed in Karmic, although unfortunately we overlooked the fix for 9.04
[23:18] <crimsun> just as a sanity-check, karmic won't update to automake 1.11, will it?  pulseaudio git now requires 1.11.
[23:19] <slangasek> didrocks: are there source changes needed to gir-repository to transition it to clutter-gtk 0.10?
[23:19] <cjwatson> last I checked we were waiting for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512704 to be fixed
[23:19] <cjwatson> rather than doing it ourselves
[23:20] <mcasadevall> infinity, !\o/!
[23:23] <crimsun> cjwatson: thanks
[23:31] <slangasek> StevenK: gir-repository was recently MIRed, it build-depends on goocanvas which hasn't been; is that something that should be done, or is gir-repository sufficiently "temporary" that we should be getting rid of it, instead?
[23:32] <tkamppeter> superm1: hi
[23:35] <seb128> slangasek, gir-repository is not really "temporary" enough
[23:35] <slangasek> alas
[23:35] <seb128> ie it will not be solved this cycle
[23:35] <slangasek> so there's a bunch of MIRs which would be needed for its build-deps, then
[23:35] <seb128> that's a collection of things that each library should build
[23:35] <slangasek> (clutter-cairo, goocanvas, ...)
[23:35] <seb128> but since upstream didn't start on this move yet ...
[23:37] <seb128> the whole gir-repository thing sucks
[23:38] <slangasek> yes, I can tell by looking at it :)
[23:38] <seb128> it's just a workaround to have gir working without doing thing properly
[23:39] <seb128> ie it's fine for early testing etc but things should be move to proper libs
[23:45] <StevenK> But should we promote goocanvas.
[23:46] <StevenK> I guess promoting it for completeness would be nice, and if we need to actually rebuild/sync gir, but ...
[23:52] <TheMuso> Could someone possibly get the latest binaries for linux-rt out of new? They've been there for a few days, and are needed for the next studio alpha.
[23:53] <maxb> A mostly trivial merge of Subversion 1.6.3 (we currently have 1.6.1) from Debian is currently blocked owing to Debian's version now pulling in Serf as a builddep and hence requiring a new MIR. Serf is an optional builddep for Subversion which Debian just happened to enable now. There are important bugfixes in Subversion 1.6.3. Given the proximity of FeatureFreeze, would it be sensible for me to prepare an adjusted merge that drops the Serf
[23:53] <maxb>  builddep?
[23:58] <lifeless> maxb: 'yes'
[23:58] <maxb> :-)


[21:57] <bdmurray> bryce: did you see bug 87661 was updated?
[21:58] <bryce> no, thanks.
[21:58] <bryce> I've re-upped -evdev
[21:58] <bdmurray> it looks like its fixed upstream now
[22:09] <bryce> yep
[22:23] <bdmurray> bryce: did anybody ask about bug 277452?
[22:38] <bryce> bdmurray: no not so far
[22:39] <bryce> erf, log.rar??  /me dislikes it when people archive up their logs
[22:40] <bdmurray> let alone a rar
[22:41] <bdmurray> there's another nv bug that might be related but the pci id is different
[22:41] <bryce> yeah and there's just a single file in it, so it's not even a workaround of lp's one-attachment-at-a-time issue
[22:56] <bdmurray> bryce: they said alpha 6 worked for them though...
[22:59] <bryce> hmm
[23:00] <bryce> well I'm pretty sure we didn't rev -nv between alpha6 and now
[23:00] <bdmurray> I've found another bug 277473, with pci id 10de:0531
[23:02] <bryce> hmm
[23:03] <bryce> well, that's certainly true, but the error messages on both bugs indicate an unsupported chip.  odd
[23:10] <bdmurray> I think there are a few more lying around too
[23:19] <bryce> bdmurray: are they all the same chipset?
[23:20] <bdmurray> no they are not exactly the same
[23:20] <bryce> hmm, well -nv hasn't changed since July
[23:20] <bdmurray> Yeah, I see that
[23:21] <bdmurray> Is there a list of devices supported by a driver somewhere?
[23:22] <bryce> yeah looking for that now
[23:22] <bryce> it's in nv_driver.c
[23:23] <bryce> ok, regarding bug #277452, which has 0x10de07e3, that''s not listed in nv_driver.c
[23:24] <bryce> lemme look in git
[23:25] <bryce> there's a 2.1.12 of the driver
[23:25] <bryce> although 0x10de07e3 still is not listed
[23:26] <bdmurray> hmm, is there just a lot of hardware that isn't supported yet?
[23:27] <bryce> same thing with 277473
[23:27] <bryce> probably
[23:27] <bryce> -nv development is sloooowww
[23:28] <bryce> so, bdmurray, basically you can just get either the pci id like 10de07e3, or the model name like 7150M, and do a grep -sir in the -nv source tree, and if nothing prints, then it's unsupported hardware
[23:31] <bryce> 2.1.12 only adds one new supported chip
[23:31] <bryce> +  { 0x10DE0640, "GeForce 9500 GT" },
[23:31] <bryce> er wait
[23:32] <bryce> my bad, there's a bunch actually
[23:33] <bryce> http://pastebin.ubuntu.com/53566/
[23:33] <bryce> bdmurray: if you spot bug reports for any of those, let me know and I can fix them
[23:33] <bryce> for any other than that, we'll just have to suggest they use -vesa or -nvidia for now
[23:34] <bdmurray> Should the Live CD fallback to -vesa?
[23:35] <bryce> yeah I think so
[23:41] <bdmurray> a lot of these are Live CD problems...


[00:00] <GridCube> it happens
[00:00] <xubuntu27w> Quick question - has anyone encountered a problem with the onscreen keyboard at login/resume? It doesn't seem to pass input to the user/pass text fields. Problem clears up once you get logged in, but if you NEED the on screen keyboard to get logged in, it can be sort of problematic. ; )
[00:00] <GridCube> oh
[00:00] <GridCube> i havent
[00:00] <GridCube> but please report it
[00:00] <xubuntu27w> Gridcube: Naw, that's a GOOD thing. More people, more experience.  = )
[00:01] <xubuntu27w> Already did. I submitted it as an onboard bug.
[00:02] <xubuntu27w> As a followup question, is there any simple way to swap the onscreen keyboard to a different  virtual keyboard program, to test if it's actually an onboard problem, or if it's actually a desktop/screenlocker issue?
[00:02] <GridCube> i would not know, sorry
[00:02] <xubuntu27w> I googled it, but as you can imagine, there's not a lot of people clamoring for a different keyboard on the login screen.
[00:03] <GridCube> well the people who implemented our greeter is arround here, so they might now, you might have to wait for them to read :)
[00:03] <xubuntu27w> No worries. I'll lurk for a while to see if the question piques anyone else's interest, but I appreciate you chatting to me as I popped in. = )
[00:07] <xubuntu27w> Hehe, I'm not in any huge hurry.  The thing works almost perfectly aside from that (Vivid is AWESOME). And I own an IT company. I can pop a keyboard or 30 on it if I forget and let it suspend.  It's an Aspire Switch 11 - one of those tablet/laptop hybrids.  Vivid Vervet is the only OS other than Win8 that actually seems to get along with the thing, and I HATE Win 8. Tried 7 (decent O/S) but the touchscreen has no driver. And Tru
[00:13] <xubuntu74w> Hello all. I need some help. I'm running 15.04 on a Dell latitude e7440. Battery preformance hasn't been great (when doing basic web browsing). How can I improve the battery life on my machine?
[00:16] <xubuntu74w> Could this mean that my hardware is not optimized to run xubuntu?
[00:17] <xubuntu27w> If the battery performance was good before you installed 15.04, you might want to check and see if there's any GPU-/CPU-heavy processes running in the background, and if they can be done away with.
[00:18] <xubuntu74w> Was running win 8.1 before with better preformance
[00:19] <xubuntu74w> (the default OS on this laptop)
[00:19] <xubuntu27w> Of course. = ) Win 8.1 that came with that laptop probably had its software carefully optimized for the OEM distribution of it specific to that laptop. You'll prolly wanna tweak it similarly in Xubuntu.
[00:21] <xubuntu74w> Being new to linux in general, what system software can I use to tweak such settings?
[00:21] <xubuntu74w> I do not yet have the knowledge to work out of the terminal
[00:22] <xubuntu27w> Weeell, I'm more used to SuSE than Ubuntu variants, but I'd check the stuff n the autostart first and foremost, then the desktop environment settings. Scale back on any GPU-heavy stuff, make sure deamons that are constantly polling stuff that doesn't need to be polled are turned off, and, of course, if you're not using the bluetooth/IR/WiMAX/whatever radios, be sure to turn them off.
[00:23] <xubuntu74w> Great, thanks for the tips
[00:24] <xubuntu27w> No probs! (To be honest, I'm actually here for help too. There's a quirk in 15 with the on-screen keyboard, but only during login/resume. Was hoping someone could help me out. heheh)
[08:05] <oiu> When the Ubuntu installer asks for 'Your name', are you supposed to enter just your given name, your given name and surname, your full name (including middle names), or what?
[08:34] <Unit193> oiu: Whatever you want to show up as your name.
[08:35] <Unit193> Mine is 'Unit 193'
[11:28] <xubuntu46w> hi all
[11:30] <xubuntu46w> there is some one that can help me with xubuntu "loading" splash screen?
[11:32] <xubuntu46w> is a animated screen with a little tourning circle that meke my monitor over frequency
[15:08] <xubuntu53w> Hi, can I get some help. Just got the iso of Xubuntu and I want to install it on a old acer via flash drive, how do I do it?
[15:08] <xubuntu53w> Anyone?
[15:08] <cfhowlett> !usb | xubuntu27w,
[15:09] <xubuntu53w> Thanks!
[17:57] <NewUser> hello, i have xubuntu 14.04 32bit, can you help me choose the right skype 4.3 version?
[18:04] <Essetee>  sudo add-apt-repository "deb http://archive.canonical.com/ $(lsb_release -sc) partner"
[18:05] <Essetee> sudo apt-get update && sudo apt-get install skype
[21:22] <ibouvousaime> Hello guys can I deny internet access to some game I have  installed with playonlinux?
[21:22] <knome> it's possible to block traffic on certain ports at least
[23:27] <ibouvousaime> pencilandpaper, btw man I forgot to tell you lool the windows install worked well thanks for the help xD


 (Photo, 1023x766) https://i.imgur.com/Wkr0NOp.jpg Hmm :D
 H mm can I take a piece of LXQt on my Lubuntu soon...  It really sound a eso me.  Greetings from Cuba
 LD
 *:D
 I try to write awesome but the corrector play me a bad joke ;)
 :)
 @Hyuuga_Neji, Best regards from the another continent
[14:04] <lubot10> Judista1510 was added by: Judista1510
 (Document) http://vps.tsimonq2.net:9090//file_757.mp4
 Lol
[17:47] <lubot10> David was added by: David
 Hi
 o/
 (Sticker, 512x512) http://vps.tsimonq2.net:9090//file_760.webp
 (Sticker, 512x499) http://vps.tsimonq2.net:9090//file_761.webp
 XD
 Hahahahahahahahahahahaha
 I'm a noob
 Will apt alongside apt-get cause problems?
 @David, Nope
 In fact, it's preferred to only use apt, not apt-get
 I read about that, but lubuntu has both
 @tsimonq2, I thought it was preferred to use apt-get because apt is kinda experimental, and for compatability reasons?
 Shall I just ditch apt-get
 @AceHW, Nope. apt is fully functional now and upstream has told me directly that apt is the way to go
 @David, Yes
 All Ubuntu and Debian distros have both
 apt-get is for backends and scripts. apt is for user interaction. Use apt. :)
 Thanks