[01:55] <Tm_T> hmm, where's newest koffice packages for breezy?
[02:06] <freeflying_> Tm_T: kubuntu.org/packages
[02:07] <Tm_T> humm
[02:07] <Tm_T> so newest packages are with 3.5 then I presume
[02:40] <JRe> http://kde-apps.org/content/show.php?content=32984
[07:14] <Burgwork> do any programs in Kubuntu default to the arts backend?
[07:15] <\sh> Burgwork: not that I know of..normally default is gstreamer
[07:15] <Burgwork> \sh, do is akode-mpeg a sane thing to tell people to install, or should they just install gstreamer-mad?
[07:15] <apokryphos> akode-mpeg too
[07:16] <Burgwork> apokryphos, they need both?
[07:16] <apokryphos> I think the hover-over for playback affect uses arts
[07:16] <Burgwork> ah
[07:16] <apokryphos> or effect, even
[07:17] <apokryphos> Riddell's faq on kubuntu.org says both, as well
[07:17] <Burgwork> someone was playing with RestrictedFormats, so I figured I would come and ask
[07:17] <apokryphos> Burgwork: me =)
[07:18] <Burgwork> apokryphos, I fixed your note so it made more sense in English
[07:18] <apokryphos> sure, either way
[07:19] <Burgwork> thanks for adding the information
[08:25] <Tonio_> hi all
[08:25] <Tonio_> \sh: hi, sorry for disturbing you...
[08:25] <Tonio_> \sh: I found a little problem using kdenetworkconf
[08:25] <Tonio_> bluez config doesn't match the kdenetworkconf requirements
[08:26] <Tonio_> should I send the diff file directly to Riddell-awa , or creating a bug report on launchpad ?
[08:26] <Tonio_> that's not really a bug, but a parameter that should be set within kubuntu-default-settings
[08:27] <\sh> Tonio_: kdenetworkconf is in main? file a bugzilla bug with the fix
[08:27] <Tonio_> \sh: okay ;)
[08:28] <Tonio_> \sh: yes, it's in main
[09:10] <JRe> Tonio_: motiv du package ?
[09:10] <JRe> oups wrong window
[09:13] <Burgwork> \sh, thanks for the wine work


[00:02] <cody-somerville> NCommander, okay, I advocated it.
[00:02] <NCommander> finally!
[00:03]  * cody-somerville rolls eyes. :P
[00:03] <cody-somerville> The package isn't debian perfect (I wish I could review like some of the debian folk can) but I don't think we'll have too much trouble getting it into the archive and soon into Debian.
[00:04] <coppro> cody can you go over mine then? please?
[00:05] <cody-somerville> coppro, ermmm... I guess. I've probably missed my bus already anyhow.,
[00:05] <cody-somerville> coppro, link?
[00:05] <coppro> http://revu.ubuntuwire.com/details.py?package=libmk4
[00:05] <coppro> thanks
[00:45] <nxvl> ScottK: ping
[00:46] <coppro> any MOTUs around?
[00:46] <cody-somerville> I am.
[00:47] <coppro> oh
[01:18] <cody-somerville> coppro, http://revu.tauware.de/details.py?package=libmk4
[01:22] <cody-somerville> nxvl, hey
[01:25] <nxvl> cody-somerville: hi!
[01:25] <cody-somerville> nxvl, want to do me a favour? :)
[01:26] <nxvl> yup
[01:26] <nxvl> shot
[01:30] <coppro> thanks cody
[01:31] <nxvl> cody-somerville: yes, sure
[01:32] <cody-somerville> nxvl, I've been assisting NCommander over the last 24 hours to get  his codeblocks package on revu in shape.
[01:32] <cody-somerville> nxvl, I was wondering if maybe you could take a look to see if you'd be able to provide a second advocate so we can get it uploaded?
[01:33] <nxvl> it takes an eternity to build
[01:33] <cody-somerville> nxvl, hehe. It isn't so bad if you upload it to a PPA.
[01:33] <nxvl> cody-somerville: i'm not a MOTU yet
[01:33] <cody-somerville> nxvl, no?
[01:33] <nxvl> nope
[01:33] <cody-somerville> Sorry to bother you then.
[01:33] <nxvl> np
[01:54] <coppro> okay, upstream includes an outdated config.guess, what do I do?
[01:54] <nxvl> ask upstream to update it
[01:54] <coppro> in the meanwhile?
[01:55] <nxvl> try to build it
[01:56] <nxvl> sometime it includes some .in file or something that updates it
[01:57] <coppro> lintian gives an error :(
[01:57] <coppro> and apparently I can't just replace it
[01:58] <nxvl> well
[01:58] <nxvl> actually in that particular case i would:
[01:59] <nxvl> a) ask upstream to include it and wait
[01:59] <coppro> done
[01:59] <nxvl> b) patch it, and send the patch to upstream
[02:03] <jmarsden> I'm having a dependency issue building iriverter using pbuilder, can anyone help please?  It builds fine under 8.0.4 (x86) but not in pbuilder.
[02:04] <coppro> how do I download the stuff necessary to pbuilder?
[02:04] <nxvl> apt-get?
[02:05] <nxvl> i don't understand the question
[02:05] <jmarsden> copro... stuff like??  sudo apt-get install pbuilder installs it for me.
[02:05] <coppro> not that, one moment
[02:05] <cody-somerville> coppro, just copy over the config stuff over at build time and delete it in your clean statement.
[02:05] <coppro> ok ty
[02:06] <coppro> oh, it's just pbuilder completion being stupid
[02:06] <coppro> nvm
[02:07] <coppro> hmm... error is in satisfying the build dependencies
[02:07] <coppro> don't have any problems with hardy...
[02:11] <coppro> someone name a random universe package
[02:11] <crimsun_> exfalso
[02:12] <wgrant> Very random.
[02:13] <wgrant> coppro: Have you enabled universe in your pbuilder?
[02:13] <coppro> no
[02:13] <coppro> which is likely the case
[02:13] <coppro> *issue
[02:17] <coppro> jmarsden: something about depending on a virtual package I think
[02:18] <jmarsden> coppro: Yes, there's supposedly a table specifying how to satisfy such virtua dependencies... but man pbuilder doesn't seem to tell me where that table is... ?
[02:19] <coppro> it's a problem with the package source I think then
[02:22] <jmarsden> coppro: Well, iriverter is already packaged and so at some point I presume it must have built OK with pbuilder?  I'm fixing a minor bug... bug fix is fine, but pbuilder won't build it, which irks me.
[02:23] <jmarsden> I wonder if the new openjdk stuff in Hardy changed something about Java package build depends?
[02:23] <coppro> try the --extra-packages option
[02:23] <jmarsden> OK, will do.
[02:23] <coppro> i don't know if it will really help but
[02:23] <coppro> its worth a try
[02:29] <cody-somerville> coppro, I followed up
[02:29] <coppro> ok ty
[02:30]  * NCommander inhales
[02:31]  * NCommander begins hacking apart revu
[02:31] <coppro> thx for the feedback
[02:36] <coppro> can someone help me set up CDBS please?
[02:37] <NCommander> coppro, what do you need to setup?
[02:37] <coppro> the whole thing
[02:37] <NCommander> Run dh_make, and select CDBS
[02:37] <NCommander> If its something that works via make/make install, it's pretty much done ;-)
[02:38] <coppro> hmm
[02:39] <NCommander> damn it, brb
[02:44] <NCommander> Would anyone like to be the second advocate of codeblocks?
[02:45] <coppro> I would like to be, but I'm not a MOTU :(
[02:45] <NCommander> heh, its appericated
[02:45]  * NCommander watches keys get imported from launchpad
[02:46] <wgrant> NCommander: You might want to try a smaller team.
[02:46] <coppro> what's the format for 00list?
[02:46] <NCommander> wgrant, yeah, I discovered that the hard way
[02:46] <NCommander> coppro, its just the patch names
[02:46] <coppro> ok
[02:47]  * NCommander has it pulls the keys from my personal launchpad team
[02:47] <NCommander> it appears fetch-launchpad-keys ignores the config file
[02:47] <wgrant> Quite possibly.
[02:47] <NCommander> SOmewhat anonying
[02:47] <NCommander> I don't like the hardcoded paths either :-/
[02:48] <jmarsden> coppro: I think dpatch or whatever patch creation tool you are using should update 00list automagically?
[02:49] <coppro> I was converting from diff patches
[02:49] <jmarsden> OK.
[02:50]  * NCommander makes a test team
[02:50] <NCommander> ahah
[02:51] <NCommander> Cool, I can just use my username and get that one specific key :-)
[02:52] <NCommander> yeah, it appears most/all of the scripts ignore the config file
[02:52] <NCommander> (aside from the webpage)
[02:56] <coppro> great
[02:56] <coppro> I now have a random failure
[02:57] <coppro> oh, I know why
[02:57] <coppro> insidious
[03:02] <coppro> is there any way to change the name my packages are signed with by default?
[03:02] <NCommander> coppro, define the env variables DEBNAME and DEBEMAIL
[03:02] <coppro> ok ty
[03:10]  * NCommander has a fully functional revu at <IP_ADDRESS> ^_^
[03:10] <coppro> debuild should always be passed --lintian-opts -i
[03:10] <coppro> it should be a law or something
[03:11] <wgrant> NCommander: Make sure you have it turn off email, though.
[03:11] <wgrant> NCommander: I've spammed a few people with it once when I forgot to disable things.
[03:11] <NCommander> Is there a handy disable switch?
[03:11] <wgrant> Since my changes last week, I belive that altering the email address in the config will get everything to respect it, but I'd grep to make sure.
[03:17] <coppro> yay lintian-complaint-free!
[03:23] <foxmike> Good evening! Is there an f-spot expert around? I have a little compilation/packaging problem to sort out with f-spot 0.4.4 for hardy...
[03:24] <nxvl> RoAkSoAx: ping
[03:25] <coppro> just ask anyway
[03:26] <coppro> worst-case-scenario: no one can help
[03:27] <coppro> foxmike: ping
[03:27] <foxmike> Here is the thing: f-spot seems to try to install upon compilation some data-hooks under /usr/lib, and that makes the compilation crash since it is done via debuild, with user permissions.  I've located where in the Makefile it happens, but I don't know how to fix such thing...
[03:27] <coppro> ok
[03:28] <coppro> one moment, installing build-deps
[03:28] <foxmike> ok thanks
[03:29] <coppro> odds are the makefile just needs to be changed to install to $(PREFIX)/usr/lib
[03:31] <foxmike> ok, check I'll try this... I guess $(PREFIX) will be something like (put working directory here)/f-spot-0.4.4/debian/tmp or something? (sorry for the noob question, I'm fairly new to all this...)
[03:32] <coppro> it should be substituted in by the build system, but I'm not sure
[03:32] <coppro> so you're trying to compile 0.4.4 right?
[03:33] <coppro> where did you get the source from?
[03:35] <coppro> foxmike: I need a copy of the 0.4.4 source, may I ask where you got it?
[03:35] <foxmike> Well, I got it from f-spot website I've copied the debian directory from 0.4.3...
[03:35] <coppro> ok
[03:35] <coppro> ty
[03:35] <foxmike> thanks to you!:)
[03:42] <foxmike> coppro: have you got it?  If not, I can send you a copy...
[03:42] <coppro> yeah I've got it, and I think I have a better solution
[03:43] <foxmike> go ahead
[03:43] <coppro> 0.4.4 is already in intrepid
[03:44] <coppro> http://mirrors.kernel.org/ubuntu/pool/main/f/f-spot/f-spot_0.4.2-1ubuntu3_i386.deb
[03:44] <foxmike> geez, I'm looking almost every day if it is there (I'm working on the package to learn, mostly...) and I didn't check today... anyway, I try to compile like this if it doesn't, well, I'll backport from intrepid!;)
[03:44] <foxmike> thanks for the link
[03:44] <coppro> ok
[03:49] <foxmike> It's still listed as f-spot0.4.2 on packages.ubuntu.com/f-spot ...:~
[03:52] <foxmike> thanks again coppro, I got to go!
[03:56] <RoAkSoAx> nxvl, here!
[03:56] <marnanel> Is this the wrong place for asking a question about packaging even if it's not a MOTU thing, or is there a better place for that?
[03:56] <RoAkSoAx> nxvl, had to run for a while
[03:57] <marnanel> (it is an Ubuntu thing, but not a MOTU thing.)
[03:57] <coppro> you can probably ask anyway
[03:59] <marnanel> okay.  What if I have a .deb I didn't make and I want to unpack it so I can make changes?  I have lots of guides from various places telling me how to build them, but I haven't found how to unbuild them.
[03:59] <nxvl> RoAkSoAx: ok
[03:59] <nxvl> RoAkSoAx: stay here
[03:59] <nxvl> vorian: ping
[04:00] <RoAkSoAx> nxvl, k ;)
[04:00] <coppro> where did you get it from?
[04:00] <coppro> ideally, you want the source package
[04:01] <vorian> yo!
[04:01] <nxvl> ok
[04:01] <nxvl> vorian: this is RoAkSoAx, you mentee
[04:01] <nxvl> RoAkSoAx: this is vorian, your mentor
[04:01] <nxvl> :D
[04:01] <nxvl> i hope you 2 the best on the mentoring program
[04:01] <vorian> howdy RoAkSoAx
[04:01] <nxvl> make me proud!
[04:01] <RoAkSoAx> vorian, master!! :D
[04:01] <RoAkSoAx> hahaha
[04:02] <RoAkSoAx> vorian, i'm ready to role xD
[04:02] <vorian> excellent
[04:03] <marnanel> coppro: ah, that makes sense.  I'll get that, then.
[04:03]  * marnanel used to know how to do this (at least to some extent), but it's been years...
[04:03] <coppro> well, the source package isn't necessarily the source code, it's the .diff.gz, .orig.gz, and .dsc
[04:04] <marnanel> right
[04:04]  * marnanel has it now.  yay
[04:06] <marnanel> thanks.  I will try this and see how it goes...
[04:14] <ScottK> nxvl: Pong
[04:16] <nxvl> ScottK: i was looking for you to mention my application, but you already replied, so nm
[04:16] <nxvl> ScottK: and Thanks for the support
[04:22] <coppro> ScottK: you up for a REVU?
[04:25] <ScottK> nxvl: You're welcome, you deserve it.
[04:34] <LucidFox> !seen
[04:34] <coppro> any MOTUs willing to do a REVU?
[04:39] <LucidFox> coppro> What package?
[04:39] <coppro> http://revu.ubuntuwire.com/details.py?package=libmk4
[04:39] <coppro> thanks
[04:42]  * LucidFox looks
[04:51] <LucidFox> coppro> commented
[04:51] <coppro> ty
[04:51] <coppro> one question
[04:51] <coppro> how do I get dh_install to install do a different name?
[04:52] <cody-somerville> coppro, you can't
[04:52] <coppro> that's why I used regular install for lintian-overrides
[04:52] <LucidFox> Ah.
[04:52] <LucidFox> Then it's fine.
[04:53] <cody-somerville> coppro, all the debhelper scripts have pretty comprehensive man pages.
[04:53] <coppro> yeah, that's what I thought
[04:53] <coppro> which is why I was pretty sure I was doing the right thing (as I understand it, intrepid has dh_lintian)
[04:54] <LucidFox> Isn't dh_lintian part of debhelper 7?
[04:54] <LucidFox> and you use 5
[04:58] <coppro> I should use binary-indep for Python stuff, right?
[05:03] <LucidFox> binary-indep is for arch:all packages
[05:04] <coppro> oh, ok
[05:04] <coppro> wait, but Python is arch:all
[05:06] <LucidFox> cody-somerville, would you like the honor of sponsoring codeblocks, or should I do it? :)
[05:07] <coppro> ok, dumb question
[05:07] <coppro> how do you put a paragraph break in a long package description
[05:07] <LucidFox>  .
[05:07] <cody-somerville> LucidFox, what would you do differently?
[05:07] <LucidFox> a space, followed by a dot
[05:08] <coppro> ok ty
[05:08] <LucidFox> for example, I'd use install instead of cp
[05:08] <LucidFox> like coppro just did :)
[05:09] <coppro> great, now dpkg-source is complaining
[05:09] <LucidFox> and I'd remove the upstream debian from the orig.tar.gz rather than diffing against it
[05:09] <coppro> apparently the +x mode on my patchfiles won't get through to the diff... that's a problem
[05:09] <LucidFox> coppro> Python is arch:all, but your _own_ package should be arch:all to use -indep
[05:10] <coppro> yeah, my source package has a python component. I just haven't gotten around to packing it
[05:10] <coppro> along with the docs and the tcl
[05:10] <LucidFox> ah
[05:10] <coppro> I was making sure that went into -indep, which is what I figured
[05:10] <LucidFox> well, if it's a binding for a C library, then the C library will typically be arch:any and the binding will be arch:all
[05:10] <coppro> how do I deal with 'warning: executable mode 0755 of 'debian/patches/disable-test-cleanup.dpatch' will not be represented in diff'
[05:11] <LucidFox> Ignore it.
[05:11] <coppro> ok
[05:14] <coppro> ok, new version on REVU
[05:14] <coppro> and now that it's gotta be perfect i can get to the docs :P
[05:16] <coppro> should -dev recommend or suggest -doc?
[05:20] <nxvl> jcastro: around?
[05:22] <cody-somerville> NCommander, congratz.
[05:23] <coppro> yeah, congrats
[05:23] <NCommander> on what? cody-somerville?
[05:23] <coppro> (I hope to enjoy your new package once 8.10 comes out)
[05:23] <cody-somerville> NCommander, I just uploaded codeblocks.
[05:23]  * NCommander faints from shock
[05:23] <NCommander> cody-somerville, why'd you feel the package didn't mean Debian expectations?
[05:24] <coppro> pretty good time from "decides to make package" to package
[05:24] <NCommander> coppro, not really ...
[05:24] <cody-somerville> NCommander, I don't think I said that.
[05:24] <NCommander> Er, I thought someone did
[05:24] <NCommander> But my memory is about as reliable as a Windows Vista workstation
[05:25] <gnomefreak> can anyone point me in right direction to fix this issue in my intrepid chroot? next post will be error
[05:25] <gnomefreak> debconf: delaying package configuration, since apt-utils is not installed
[05:25] <gnomefreak> Can not write log, openpty() failed (/dev/pts not mounted?)
[05:25] <gnomefreak> dpkg: syntax error: unknown group `Debian-exim' in statoverride file
[05:25] <gnomefreak> E: Sub-process /usr/bin/dpkg returned an error code (2)
[05:25] <gnomefreak> E: Failed to process build dependencies
[05:25] <gnomefreak> oops way too many lines
[05:26] <NCommander> gnomefreak, in your chroot, type: mount -t devpts none /dev/pts
[05:26] <NCommander> And you probably need to manually add the Debian-exim group
[05:26] <NCommander> (groupadd -s Debian-exim)
[05:27] <gnomefreak> there is not option -s
[05:27] <coppro> what compression does .deb use? I thought it was .tar.gz, but that doesn't seem to be the case
[05:28] <gnomefreak> isnt it zip?
[05:28] <NCommander> cody-somerville, who was the other advocate?
[05:28] <coppro> LucidFoz
[05:28] <coppro> s/z/x/
[05:28] <NCommander> sweeeet
[05:28] <coppro> he advocated it when I asked him to check my package
[05:28] <coppro> I think
[05:28] <NCommander> So he did it by mistake?
[05:28] <NCommander> ...
[05:28] <coppro> no
[05:29] <NCommander> Eh, if that what it takes ;-)
[05:29]  * NCommander watches Ubuntu suddenly explode in an amazing display of colors and Debian swirls
[05:30] <coppro> anyone know what compression format a .deb is?
[05:30] <NCommander> ar archive
[05:30] <NCommander> use ar x to extract
[05:30] <NCommander> and the man page to determine how to compress
[05:30] <coppro> oh ok ty
[05:30] <coppro> ar r isn't it?
[05:31] <gnomefreak> what is [--gid ID]
[05:31] <NCommander> gnomefreak, the GID of the group you are creating
[05:31] <gnomefreak> assuming group id
[05:31] <NCommander> coppro, don't know off hand
[05:31] <gnomefreak> how would i know what it is :(
[05:32] <coppro> make one up that isn't taken I guess
[05:33]  * NCommander loves looking at codeblocks in the archive
[05:33] <NCommander> It's like
[05:33] <NCommander> wow
[05:33] <NCommander> I did that
[05:34] <gnomefreak> is there a way to list all gids?
[05:34] <NCommander> cat /etc/group
[05:34] <NCommander> THe first number is the gid
[05:34] <NCommander> Just pick an unusued one
[05:34] <gnomefreak> thanks
[05:34] <NCommander> cody-somerville, so now my package is in the NEW queue, right?
[05:35] <cody-somerville> NCommander, correct.
[05:35] <NCommander> So in seven days, I'll get the email notification about REJECT(ed) ;-)
[05:36] <cody-somerville> NCommander, :)
[05:36] <gnomefreak> it seems i cant use a number that isnt used already. error message addgroup: The user `125' does not exist.
[05:37] <NCommander> gnomefreak, just do "groupadd -s Debian-exim"
[05:37] <NCommander> Or loose the -s if it doesn't work
[05:37] <gnomefreak> NCommander: cant -s isnt an option
[05:37] <NCommander> then just groupadd Debian-exim
[05:38] <gnomefreak> ok i did and got no output im gonna say this is good and i will try dpkg again thanks
[05:38] <LucidFox> Will version 1.7.dfsg be considered bigger than 1.7?
[05:39] <gnomefreak> NCommander: it worked ;)
[05:40] <NCommander> LucidFox, Well, if I remember how dpkg works, the string gets turned into numbers (its a char I think), and the greater sum is the higher package version. THat's why x86suse > ubuntu
[05:40] <NCommander> Sadly :-/
[05:40] <NCommander> *char cast
[05:46] <NCommander> http://thedailywtf.com/Articles/Which-Internet.aspx - lol
[05:48] <coppro> ok, new confusion
[05:48] <coppro> upstream puts all the documentation in doc/
[05:48]  * NCommander apt-get gets your confusion
[05:49] <coppro> all this needs to be put in /usr/share/doc/package/html
[05:49] <coppro> can I specify that somehow in package.docs?
[05:49] <coppro> it gets seriously confused if I just try doc/*
[05:51] <NCommander> Can't you just list the path to the docs folder and it will recursively do the rest?
[05:51]  * NCommander admits its been awhile since he had such fuck
[05:51] <NCommander> ... fun
[05:51] <NCommander> damn it
[05:51] <NCommander> Two thoughts crashed at extactly the same time; my pager going off, and that statement
[05:52] <coppro> it puts them all into the /usr/share/doc/package/
[05:52] <coppro> how do I get it to go another level down
[05:52] <NCommander> ,,?
[05:52] <NCommander> er ..
[05:52] <coppro> I need it to be in /usr/share/doc/package/html/
[05:53] <NCommander> I'd just manually create the doc package with some fancy dh_install rules then ...
[05:53] <coppro> or I could just cp -a doc debian/tmp/html
[05:53] <coppro> and put debian/tmp/html into the .docs file
[05:53] <NCommander> go for it
[05:56] <coppro> ok ill say you told me to do it lol
[05:56] <coppro> or you know what
[05:56] <coppro> 'doc' is an okay folder name
[05:58] <NCommander> ack
[05:59] <coppro> what?
[06:00] <NCommander> nm
[06:00]  * NCommander sends a rst packet into the channel
[06:01]  * coppro /clears
[06:02] <gnomefreak> do we know status of ruby1.8?
[06:03]  * NCommander throws more rst packets and an x-mas tree too
[06:04]  * coppro clears multiple times
[06:04] <coppro> ow
[06:09] <coppro> I just came up with a new warning lintian should check
[06:10] <coppro> if there exists a debian/patches/*.dpatch and you don't build-depend dpatch, something is probably wrong
[06:16] <coppro> gaah! what options are there for Section: in a doc-base file?
[06:17] <coppro> found it
[06:17] <coppro> but the examples in the doc-base docs are invalid :(
[06:19] <coppro> wait, no
[06:19] <coppro> stupid lintian
[06:22] <gnomefreak> its funny how chroot doesnt install apt
[06:23] <coppro> it doesn't?
[06:23] <gnomefreak> nope
[06:23] <coppro> you used debootstrap right?
[06:23] <gnomefreak> yes
[06:24] <coppro> well, my chroot has apt
[06:24] <gnomefreak> i have 5 chroots set up intrepid is only one that doesnt install apt
[06:24] <coppro> not really much else, but it definitely has apt
[06:24] <gnomefreak> root@Development:/# apt-get update
[06:24] <gnomefreak> bash: apt-get: command not found
[06:25] <coppro> O.o
[06:25] <coppro> try reinstalling your chroot then?
[06:25] <gnomefreak> coppro: 2 times
[06:25] <coppro> sudo chroot /chroot/intrepid
[06:25] <coppro> apt-get update
[06:25] <coppro> <bunch of crap>
[06:25] <gnomefreak> ending up downloading it from p.u.c moving it to /var/chroot/intrepid/home and installing it with dpkg
[06:27] <gnomefreak> this breakage is recent
[06:27] <gnomefreak> last 7 days or so
[06:28] <coppro> I made my chroot yesterday
[06:28] <coppro> or the day before, I forget
[06:31] <gnomefreak> i had one set up last week but i had broken it so im setting it up again. last week apt was installible
[06:31] <gnomefreak> -i +a
[06:32] <coppro> I just made another one:
[06:32] <coppro> I: Retrieving Release
[06:32] <coppro> I: Retrieving Packages
[06:32] <coppro> I: Validating Packages
[06:32] <coppro> I: Resolving dependencies of required packages...
[06:32] <coppro> I: Resolving dependencies of base packages...
[06:32] <coppro> I: Found additional base dependencies: libgnutls26
[06:32] <coppro> I: Checking component main on http://archive.ubuntu.com/ubuntu...
[06:32] <coppro> I: Retrieving adduser
[06:32] <coppro> I: Validating adduser
[06:32] <coppro> I: Retrieving apt
[06:32] <coppro> so there
[06:32]  * coppro ducks from the spam police
[06:33] <coppro> is /usr/bin in your $PATH?
[06:36] <gnomefreak> coppro: it is
[06:36] <coppro> wow something is messed up on your end then
[06:37] <gnomefreak> yep fixing it as we speak
[06:39] <gnomefreak> how in gods name am i gonna get a root/sudo dhell to install sudo
[06:40] <coppro> from a chroot?
[06:40] <coppro> or does your system not have sudo installed?
[06:40] <coppro> if the latter, and if root has no password (the default on ubuntu), you have to boot into single-user-mode
[06:41] <gnomefreak> from a chroot but sudo never got installed in the chroot
[06:41] <coppro> you start with a root shell in a chroot
[06:41] <gnomefreak> su doesnt work
[06:41] <coppro> doesn't need to
[06:41] <coppro> you are root
[06:41] <coppro> just apt-get install sudo
[06:42] <gnomefreak> (intrepid)gnomefreak@Development:~/downloads$ apt-get install sudo
[06:42] <gnomefreak> E: Could not open lock file /var/lib/dpkg/lock - open (13 Permission denied)
[06:42] <gnomefreak> E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
[06:42] <gnomefreak> i downloaded it but cant use sudo dpkg
[06:42] <coppro> you have chrooted in?
[06:42] <gnomefreak> yes (intrepid)gnomefreak@Development:~/downloads$
[06:42] <coppro> that's not right
[06:42] <gnomefreak> sure it is
[06:42] <coppro> why isn't it a root shell
[06:43] <coppro> chroot can only be run as root and gives a root shell
[06:43] <gnomefreak> none of mine are
[06:43] <gnomefreak> coppro: nope it runs fine without root shell
[06:43] <coppro> I have never heard of chroot not giving a root shell
[06:43] <gnomefreak> shares ~/
[06:44] <coppro> ok wait close out of everything
[06:44] <coppro> go back to your normal shell
[06:44] <gnomefreak> coppro: https://wiki.ubuntu.com/DebootstrapChroot?highlight=(chroot)
[06:44] <coppro> and 'sudo chroot /var/chroot/intrepid'
[06:44] <gnomefreak> and that gives me the same tht i was in
[06:45] <coppro> that should be a root shell
[06:45] <gnomefreak> the chroot is set up already but somehow the packages didnt install
[06:45] <gnomefreak> coppro: no its not Setting up a dchroot (non-root) environment
[06:46] <coppro> oh
[06:46] <gnomefreak> on the link i gave you
[06:46] <coppro> you are supposed to install sudo first, before you mess with the other stuff
[06:47] <gnomefreak> coppro: yeah hence the screw up
[06:47] <coppro> can't you still chroot in normally?
[06:47] <gnomefreak> coppro: not to root
[06:48] <coppro> why not?
[06:48] <coppro> wait there might be a way
[06:48] <coppro> try 'sudo chroot /var/chroot/intrepid apt-get install sudo'
[06:48] <gnomefreak> coppro: because i set it up with nonroot
[06:49] <gnomefreak> coppro: i think that worked but give me a minute and ill let you know
[06:49] <gnomefreak> coppro: it worked thank you
[06:50] <coppro> manpages are your friend :)
[06:51] <gnomefreak> they were already downloaded but didnt get configured due to apt not being installed so i could have just dpkg --configure -a :(
[06:51] <gnomefreak> thats what i get for working at 2am
[06:52] <coppro> lol
[06:53] <gnomefreak> someone broke ruby1.8 so i see if i can fix it locally most likely just a respin
[07:09] <gnomefreak> does ruby build like python or normal package using dpkg-buildpackage
[08:05] <wgrant> gnomefreak: It is a package, so yes.
[08:06] <gnomefreak> wgrant: thanks now i have to figure out the error its 3:05 am atm so im not sure if im gonna continue or not i have bad feeling its *-buildpackage
[08:06] <wgrant> Ruby is rather temperamental. It will sometimes build.
[08:16] <gnomefreak> 2
[08:17] <gnomefreak> it may be ruby since it runs -b after i run dpkg-buildpackage keystuff -i.bzr
[08:43] <slytherin> LucidFox: Hi
[08:44] <LucidFox> slytherin> Are you sure that the TIFF and JPEG transcoders don't build with openjdk?
[08:44] <slytherin> LucidFox: Let me check.
[08:45] <LucidFox> as I mentioned in the bug, they did build for me
[08:45] <LucidFox> same for xmlgraphics-commons
[08:46] <slytherin> LucidFox: Ihaven't looked much into oenjdk but do you if com.sun.image.codec.jpeg.JPEGCodec is available in openjdk?
[08:46] <LucidFox> Yes, Ubuntu's openjdk-6 the contains com.sun.image.* APIs
[08:47] <slytherin> LucidFox: meanwhile check line 164 in build.xml
[08:47] <LucidFox> yes
[08:47] <LucidFox> and for openjdk, that check succeeds
[08:48] <LucidFox> javac does warn that these APIs are deprecated, but the dependent classes still build
[08:49] <slytherin> LucidFox: That is cool then.
[08:50] <slytherin> Now what we can do is add debain/ant.properties file and add properties ant.build.javac.source=1.5 and ant.build.javac.target=1.5 to the file. Also include ant-vars.mk in rules file.
[08:58] <slytherin> LucidFox: and whom do I bug now to clear batik from 'NEW'?
[08:59] <geser> slytherin: batik got uploaded?
[08:59] <slytherin> geser: LucidFox did.
[09:00] <slytherin> geser: and as he is saying it is built with openjdk without loss of cuntionality.
[09:00] <geser> even better then
[09:00] <slytherin> s/cunctionality/functionality
[09:01] <slytherin> Now I have to apply for motu-contributors membership. :-D
[09:02] <geser> slytherin: the NEW queue gets usually processed on the archive days
[09:03] <slytherin> geser: yes I know. I am just too eager to look into other depwait/ftbfs that depended on batik
[09:03] <geser> :)
[09:14] <gnomefreak> can someone point me to wher ei can figure out what the following error is.
[09:14] <gnomefreak> error is: dpkg-buildpackage: failure: dpkg-source -b ruby1.8-<IP_ADDRESS> gave error exit status 255
[09:16] <wgrant> gnomefreak: It would generally indicate that the build failed somewhere. You must look for the source of failure yourself.
[09:16] <gnomefreak> wgrant: its ruby that failed?
[09:17] <gnomefreak> wasnt sure if it was ruby or dpkg
[09:17] <slytherin> gnomefreak: read the complete build output not just the last error. You will surely find the cause.
[09:18] <gnomefreak> slytherin: i have read it and doing it again atm
[09:19] <gnomefreak> just about everything in output has to do with cdbs
[09:19] <slytherin> gnomefreak: can you paste the log somewhere?
[09:19] <gnomefreak> but as for the failure im not sure since it deapplied patches than cdbs starts
[09:19] <gnomefreak> slytherin: yeah
[09:21] <gnomefreak> http://gnomefreak.pastebin.ca/1076441  this maybe why ruby is broken(atleast i heard it was thats why im working on it i need it for an app
[09:22] <gnomefreak> was gonna say make file but it was ablet o continue
[09:22] <slytherin> gnomefreak: line 64 in your pastebin
[09:23] <gnomefreak> that wont make it fail would it?
[09:23]  * gnomefreak thought ive had apps sontinue but ill try it
[09:23] <slytherin> gnomefreak: I don't know. But you have to fix it anyway.
[09:24] <wgrant> It says 'dpkg-source: error'. That looks like an error. Errors make things fail.
[09:25] <slytherin> :-)
[09:27] <gnomefreak> what do i change the maintainer to (the one that is in there now so i can add me to maintainer
[09:28] <gnomefreak> xbdc or something like that?
[09:28] <slytherin> gnomefreak: XSBC-Original-Maintainer. I suggest you use update-maintainer script
[09:29] <gnomefreak> didnt know there was one
[09:29] <slytherin> And don't add yourself as maintainer, it is either<EMAIL_ADDRESS>or<EMAIL_ADDRESS>[09:29] <slytherin> gnomefreak: the script is in ubuntu-dev-tools ackage
[09:34] <gnomefreak> slytherin: wgrant thanks i havenever seen build fail due to no ubuntu maintianer because of the ubuntu version
[09:35] <gnomefreak> all this for alexandria book app
[09:41] <jscinoz> hey guys
[09:42] <jscinoz> Im having an issue with dh_shlibdeps finding a library in a different binary package built by the same source package.. debian/rules: http://pastebin.com/f5ee3112a debian/control: http://pastebin.com/f7068ed9c   buildlog: http://pastebin.com/f6581008e Any ideas why dh_shlibdeps cant find the lib it needs from the same source package even though dh_makeshlibs is run before dh_shlibdeps?
[09:54] <laga> awesome, the buildlog doesn't load here
[09:54] <slytherin> same here
[09:55] <laga> i'd be really interested because i might be suffering from the same problem
[10:03] <Iulian> cody-somerville: Hi, I just uploaded a new debdiff for salasaga, hope it's ok now.
[10:11] <k0p> hi all
[10:12] <k0p> someone can review my package, please? http://revu.tauware.de/details.py?package=umit
[10:37] <elmargol> Has someone seen a pywebkitgtk package?
[10:39] <Iulian> k0p: Call dh_desktop in debian/rules. It's better just to say "Please report bugs at http://trac.umitproject.org" in your manpage and don't forget to mention the authors of the package.
[10:41] <k0p> Iulian, about dh_desktop is it necessary? yesterday a guy in the channel told me that it is useless. do you know something about that?
[10:43] <k0p> Iulian, where I can set authors of the package?
[10:43] <jscinoz> laga, oh didnt notice, one moment ill psate again
[10:45] <jscinoz> laga, http://pastebin.com/f3427fb96
[10:46] <k0p> Iulian, now no warnings and I fix the bug text on manpage.
[10:46] <k0p> lack the authors of package.
[10:46] <LucidFox> Blimey, slytherin left
[10:46] <Iulian> k0p: It seems that lintian complains about dh_desktop, not sure if it's necessary.
[10:46] <k0p> Iulian, yeap
[10:46] <k0p> and about authors
[10:47] <k0p> are you talk about manpage?
[10:47] <Iulian> k0p: Well, if someone from here told you that it's not necessary, don't add it.
[10:47] <Jazzva> k0p, as far as I know, only if you have a .desktop file in your package, then you should call dh_desktop.
[10:47] <k0p> Jazzva, yeah I have
[10:47] <k0p> so I'll call.
[10:47] <k0p> :)
[10:48] <k0p> dh_desktop debian/umit.desktop
[10:48] <k0p> something like that?
[10:48] <Iulian> k0p: Add the authors of the package in AUTHORS section in your man page.
[10:48] <k0p> Iulian, so.. replace AUTHOR by AUTHORS?
[10:49] <Iulian> Exactly
[10:49] <Jazzva> k0p, manpage for dh_desktop says it can't install .desktop files. It takes care of adding maintainer script fragments to call update-desktop-database (copied from manpage).
[10:49] <Iulian> k0p: If it has more than one author, yes.
[10:49] <k0p> Jazzva, really nice. :)
[10:50] <Jazzva> k0p, and if .desktop file does not contain MimeType field it will be ignored. So, if your desktop doesn't have that field, than maybe you don't need to call it :)
[10:50] <k0p> Iulian, nop. don't have..
[10:50] <k0p> Iulian, is it authors of package or of project?
[10:50] <k0p> Jazzva, sure :)
[10:51] <Iulian> k0p: Yes, upstream authors.
[10:51] <k0p> ok
[10:52] <k0p> Iulian, and can I mantain the author of manpage?
[10:53] <Iulian> Yup
[10:54] <k0p> done
[10:55] <k0p> Iulian, what I can do to my package be added on ubuntu repositorys? only wait?
[10:58] <Iulian> k0p: You'll need two advocates from two MOTUs.
[10:59] <k0p> advocates? is it like a approvation?
[11:01]  * directhex is still waiting for sponsorship on a couple of syncs to make some packages actually work
[11:02] <k0p> directhex, syncs?
[11:03] <directhex> syncs. as in "take debian package, place in ubuntu"
[11:03] <k0p> hmm sure
[11:04] <directhex> considering i updated the debian packages, specifically so they could easily be synced to ubuntu, it's kinda annoying
[11:04] <k0p> directhex, only debian package can be added on ubuntu?
[11:04] <directhex> k0p, no, but it's the best way
[11:05] <k0p> :S
[11:05] <directhex> it's designed straight into the ubuntu package numbering process, after all
[11:05] <k0p> I don't added my package in debian yet
[11:05] <k0p> I need to prepare debian package and send to debian-mentors
[11:05] <directhex> non-debian packages need to have "0ubuntu" in the version, e.g. 1.0-0ubuntu1
[11:06] <k0p> sure
[11:06] <directhex> the idea being that if/when debian uses the package, they start at 1.0-1, which is higher-versioned
[11:07] <k0p> yeah
[11:07] <k0p> I understand
[11:08] <k0p> directhex, I would like that my package will be available on 8.10. But I don't have debian package in repository.  :D
[11:39] <LucidFox> directhex> Yes, I saw that page. Some people even mistook it for official policy.
[11:40] <directhex> i'm busy adding my $0.02
[13:10] <porthose> I'm looking at the changelog of a package and it is written with a mixture of english and german, is this acceptable?
[13:25] <jscinoz> elmargol, but evolution is awesome.
[13:47] <RainCT> porthose: for Debian/Ubuntu, no
[13:48] <porthose> RainCT: they should be in english correct?
[13:50] <RainCT> porthose: Yes. Imagine what would happend if everyone would write changelog entries in their native language...
[13:50] <porthose> RainCT: that's what I was thinking thx:)
[13:51] <directhex> genius idea: put debian/changelog under the control of pofiles! put out a request for translations with every package update, to keep the changelog translated!
[13:53] <Iulian> Haha
[15:03] <CyberCod> anyone in here available to help with (what looks to me to be) a bug?
[15:04] <CyberCod> I can't seem to start audacious (and play a playlist) by using crontab
[15:04] <CyberCod> spent like 3 hours on it in #ubuntu last night
[15:05] <CyberCod> there seems to be some block on crontab using the display
[15:05] <CyberCod> even if you stipulate what it is
[15:06] <CyberCod> and I tried stipulating it 3 different ways.   New line variable, inline variable, and audacious switch
[15:09] <CyberCod> the command is embedded in a script, and the script is being run
[15:09] <CyberCod> echos to a log file lemme know start and finish of the script
[15:10] <CyberCod> and 2>/blah/logfile is appended to the end of the line that calls audacious
[15:11] <CyberCod> output from that is "audacious: cannot open display"
[15:11] <Kopfgeldjaeger> better join #ubuntu
[15:11] <Kopfgeldjaeger> and I think you have to specify the display
[15:12] <CyberCod> tried stipulating it 3 different ways.   New line variable, inline variable, and audacious switch
[15:12] <CyberCod> which is why this feels like a bug
[15:12] <Kopfgeldjaeger> try:
[15:12] <CyberCod> none of those ways work
[15:12] <Kopfgeldjaeger> DISPLAY=:0.0 yourapp
[15:12] <Kopfgeldjaeger> as command in crontab
[15:12] <CyberCod> IN crontab?
[15:12] <CyberCod> so
[15:13] <CyberCod> DISPLAY=:0.0 /path/to/script
[15:13] <Kopfgeldjaeger> hm.. yes. or in your script
[15:13] <CyberCod> tried in the script
[15:13] <CyberCod> will try in crontab
[15:13] <CyberCod> thanks for the suggestion
[15:13] <CyberCod> this is for the wife
[15:14] <CyberCod> wake to music
[15:14] <CyberCod> originally used mpg321 but she couldn't easly kill it
[15:15] <Kopfgeldjaeger> hm - i would use "mplayer /media/music/wake_up.mp3" and make a big button that executes "killall mplayer"
[15:16] <CyberCod> mplayer doesn't rely on display?
[15:16] <Kopfgeldjaeger> no
[15:16] <CyberCod> does it handle .pls playlists?
[15:16] <Kopfgeldjaeger> probably
[15:16] <CyberCod> k
[15:16] <CyberCod> thanks
[15:16] <CyberCod> I tried using xmms instead and that wouldn't work either
[15:17] <Kopfgeldjaeger> mplayer isnt graphical  (at least as long as you dont watch a video in non-aalib mode)
[15:17] <CyberCod> someone suggested this last night right when I was giving up.  I couldn't keep my eyes open any longer
[15:18] <Laibsch> Hi, I wonder how I can get debuild to ignore the debian/.bzr directory "pdebuild -i.bzr" does not work.  Any ideas?
[15:24] <CyberCod> DISPLAY=:0.0 /path/to/script doesn't work
[15:24] <CyberCod> got output
[15:24] <CyberCod> No protocol specified
[15:24] <CyberCod> audacious: cannot open display:
[15:24] <CyberCod> attempting with mplayer
[15:24] <Kopfgeldjaeger> then specify DISPLAY=:0.0 audacious in your script (alternatively)
[15:25] <Kopfgeldjaeger> i mean, start audac* with DISPLAY=:0.0 before it
[15:25] <Laibsch> looks like "pdebuild --debbuildopts -i.bzr" is what I was searching for
[15:27] <CyberCod> mplayer didn't work, but there's more output
[15:28] <Kopfgeldjaeger> oO(i think he's doing something wrong)
[15:29] <CyberCod> http://pastebin.com/d23874861
[15:30] <Kopfgeldjaeger> No such file or directory
[15:30] <Kopfgeldjaeger> what do you specify in your crontab?
[15:30] <Kopfgeldjaeger> hm
[15:30] <Kopfgeldjaeger> XOpenDisplay() failed
[15:30] <Kopfgeldjaeger> ok, show your crontab
[15:30] <CyberCod> yeah
[15:30] <CyberCod> just a sec
[15:32] <CyberCod> 27 9 * * * DISPLAY=:0.0 /home/fayte/MorningPlayer/morningmusic.sh
[15:32] <Kopfgeldjaeger> and show morningmusic.sh ?
[15:32] <Kopfgeldjaeger> s/show/your/
[15:33] <CyberCod> hang on a sec... will jump in from that machine, it keeps droppin my ssh session
[15:33] <Kopfgeldjaeger> ehm
[15:33] <Kopfgeldjaeger> a x server is running?
[15:34] <Kopfgeldjaeger> +n
[15:34] <CyberCo1> k
[15:34] <CyberCo1> just a sec
[15:34] <CyberCo1> mplayer -playlist /home/fayte/Desktop/Playlists/MorningMusic.pls 2> /home/fayte/MorningPlayer/MP.log
[15:35] <CyberCo1> thats the line from the script
[15:35] <CyberCo1> everything else has been commented out
[15:35] <Kopfgeldjaeger> ok
[15:35] <Kopfgeldjaeger> mplayer -playlist /home/fayte/Desktop/Playlists/MorningMusic.pls
[15:35] <Kopfgeldjaeger> this works when you start it by hand?
[15:36] <CyberCo1> http://pastebin.com/m5d3fa1b1
[15:36] <CyberCo1> works just fine from nautilus and from CLI
[15:36] <Kopfgeldjaeger> ok
[15:36] <CyberCo1> wait
[15:36] <CyberCo1> no
[15:36] <CyberCo1> haven't tried it in either since changing to mplayer
[15:37] <CyberCo1> but it worked fine from CLI and nautilus when it was audacious
[15:37] <CyberCo1> gimme a sec, will check it agian
[15:37] <Kopfgeldjaeger> remove the -playlist argument
[15:37] <Kopfgeldjaeger> try it without it from CLI first I mean
[15:38] <CyberCo1> its working from CLI
[15:38] <CyberCo1> with -playlist option
[15:39] <Kopfgeldjaeger> ok
[15:40] <Kopfgeldjaeger> http://pastebin.com/m50ed90
[15:40] <Kopfgeldjaeger> does this work in cli?
[15:40] <CyberCo1> http://pastebin.com/d8cc086d
[15:40] <Kopfgeldjaeger> with my command?
[15:41] <CyberCo1> yep
[15:41] <Kopfgeldjaeger> try the command that works for you and mine, and then paste the _WHOLE_ prompt
[15:41] <CyberCo1> no CLI output
[15:41] <CyberCo1> but its playing
[15:42] <Kopfgeldjaeger> try your command and mine, and then paste the _WHOLE_ prompt
[15:42] <CyberCo1> not sure what you mean
[15:43] <Kopfgeldjaeger> youve opened a terminal, right?
[15:43] <CyberCo1> yep
[15:44] <Kopfgeldjaeger> then open a new one and enter and cancel both commands. then copy everything you see (everything!) and paste it
[15:46] <CyberCo1> http://pastebin.com/d22cb5347
[15:46] <CyberCo1> thats from your command
[15:46] <CyberCo1> output from the log
[15:46] <CyberCo1> there was no output in the terminal
[15:47] <CyberCo1> Ctrl-C just went to the next line
[15:47] <Kopfgeldjaeger> ok
[15:47] <Kopfgeldjaeger> do the same without the > and 2> stuff at the end
[15:47] <CyberCo1> k
[15:47] <Kopfgeldjaeger> so that the messages appear in the terminal
[15:48] <CyberCo1> http://pastebin.com/d1502845c
[15:49] <CyberCo1> its playing
[15:49] <Kopfgeldjaeger> also remove the > /home/blabla stuff at the end
[15:49] <CyberCo1> k
[15:50] <CyberCo1> http://pastebin.com/m5151e133
[15:51] <Kopfgeldjaeger> it played?
[15:51] <CyberCo1> yep
[15:51] <CyberCo1> the "no such file or directory" bit must be referring to something internal
[15:52] <Kopfgeldjaeger> ok, fine. now put DISPLAY=:0.0 mplayer -playlist /home/fayte/Desktop/Playlists/MorningMusic.pls in your crontab
[15:52] <Kopfgeldjaeger> not the script
[15:52] <Kopfgeldjaeger> ehm
[15:52] <Kopfgeldjaeger> but add the log stuff
[15:53] <Kopfgeldjaeger> DISPLAY=:0.0 mplayer -playlist /home/fayte/Desktop/Playlists/MorningMusic.pls > /home/fayte/mpl.log 2>&1
[15:53] <StevenK> You know cron has a different environment to the logged in user.
[15:53] <StevenK> Which means you probably can't run X programs from cron
[15:53] <Kopfgeldjaeger> well, but audio should work without x?
[15:54] <Kopfgeldjaeger> and there's the DISPLAY var
[15:54] <leleobhz> tried? xhost +localhost from inside X?
[15:54] <StevenK> xhost +localhost is a horrid hack
[15:54] <StevenK> As long as the user has permissions to open the sound device, it should be fine.
[15:54] <leleobhz> StevenK: only to know if X is the problem :]
[15:54] <Kopfgeldjaeger> if it runs as root he shouldnt need xhost
[15:54] <CyberCo1> k
[15:54] <Kopfgeldjaeger> IIRC
[15:54] <CyberCo1> 1 min
[15:54] <leleobhz> hmmmm
[15:55] <leleobhz> Kopfgeldjaeger: correct
[15:55] <CyberCo1> been trying as root crontab
[15:55] <leleobhz> ls -lah /dev/dsp
[15:55] <tacone> where do I download the nightly iso of intrepid ?
[15:55] <CyberCo1> fayte@faytal:~/MorningPlayer$ ls -lah /dev/dsp
[15:55] <CyberCo1> crw-rw----+ 1 root audio 14, 3 2008-07-15 22:28 /dev/dsp
[15:56] <CyberCo1> time has past
[15:56] <leleobhz> hmmm
[15:56] <CyberCo1> will check the log
[15:56] <leleobhz> syslog?
[15:57] <CyberCo1> http://pastebin.com/m18e4efcf
[15:57] <CyberCo1> no, a log output from the command
[15:58] <Kopfgeldjaeger> maybe try it with the user-crontab or use sth. like sudo -u fayte
[15:58] <CyberCo1> is it supposed to be this hard?
[15:59] <CyberCo1> have any of you tried it on your systems? is it just my install?
[15:59] <leleobhz> WOP: try put into crontab: echo $UID > /tmp/test
[15:59] <CyberCo1> is this a bug? is there another way to do cron jobs?
[16:00] <Kopfgeldjaeger> http://www.getdeb.net/app/AlarmClockApp
[16:01] <CyberCo1> I'd have to set 10 of those to play the album :-/
[16:01] <CyberCo1> but thanks, I'll use that app on my machine I'm sure
[16:02] <CyberCo1> echo $UID > /tmp/test     whats that do?
[16:04] <CyberCo1> I'm just not sure what the $UID is
[16:04] <leleobhz> CyberCo1: may be cron set the uid environment
[16:04] <leleobhz> so can you see the user crontab uses
[16:04] <CyberCo1> ah
[16:05] <CyberCo1> I get you
[16:05] <CyberCo1> k
[16:05] <CyberCo1> will try it
[16:06] <CyberCo1> 1 min
[16:07] <CyberCo1> no output
[16:08] <leleobhz> hmmmmm
[16:08] <CyberCo1> -  /tmp/test was created, but it was blank
[16:08] <leleobhz> CyberCo1:
[16:09] <leleobhz> cat /proc/self/status > /tmp/test
[16:11] <CyberCo1> you want that in a crontab?
[16:11] <CyberCo1> or run from term
[16:11] <leleobhz> yep :]
[16:11] <leleobhz> on cron
[16:11] <CyberCo1> k
[16:11] <leleobhz> i think this is empty-environment proof :]
[16:13] <CyberCo1> http://pastebin.com/m6512d10d
[16:15] <CyberCo1> I understand the need for the empty environment, but there's an obvious need for a scheduler with the ability to output to display
[16:16] <leleobhz> Uid:    1001    1001    1001    1001
[16:16] <leleobhz> Gid:    1001    1001    1001    1001
[16:16] <leleobhz> o.0
[16:16] <leleobhz> suid?!?
[16:16] <CyberCo1> lost me
[16:16] <CyberCo1> I dont know what any of that means
[16:16] <leleobhz> well
[16:17] <leleobhz> if you ran that line from crontab
[16:17] <leleobhz> nah
[16:17] <CyberCo1> it was a user's crontab
[16:17] <leleobhz> dont make sense
[16:17] <leleobhz> hmm
[16:17] <leleobhz> no makes sense :]
[16:17] <leleobhz> *now
[16:18] <leleobhz> well, it uses you own user to run crontab
[16:18] <CyberCo1> should I do it again from root crontab?
[16:19] <leleobhz> you need to test this script from crontab you get the problem :]
[16:20] <leleobhz> CyberCo1: try create a script i some place
[16:20] <leleobhz> /home/cyberco/WakeupMachine.sh
[16:21] <CyberCo1> and within the script ?
[16:21] <leleobhz> and inside tuse #!/bin/bash (newline) mplayer somethingyouwant
[16:21] <leleobhz> *use
[16:21] <CyberCo1> that is how I've been doing it
[16:21] <CyberCo1> still get display errors
[16:21] <CyberCo1> even if I specify display
[16:22] <leleobhz> try
[16:22] <leleobhz> mplayer -vo null
[16:22] <CyberCo1> k
[16:22]  * leleobhz dont see another way
[16:24] <CyberCo1> set 1 min
[16:25] <CyberCo1> http://pastebin.com/m137ba1f4
[16:26] <CyberCo1> thats what was > log
[16:28] <CyberCo1> whats crazy is that this is a new problem... worked fine in feisty
[16:28] <leleobhz> hmmm
[16:29] <leleobhz> try add -v -v -v
[16:29] <CyberCo1> verbose?
[16:29] <leleobhz> yep
[16:29] <CyberCo1> keep the -vo null ?
[16:29] <leleobhz> keep
[16:30] <CyberCo1> mplayer -v -v -v -vo null -playlist /home/fayte/Desktop/Playlists/MorningMusic.pls 2> /home/fayte/MorningPlayer/MP_.log
[16:30] <CyberCo1> thats the line in the script
[16:30] <CyberCo1> any changes before I cron it?
[16:32] <leleobhz> nop
[16:32] <CyberCo1> 1.5 min
[16:34] <CyberCo1> http://pastebin.com/m693eb8b6
[16:34] <leleobhz> o.0
[16:34] <CyberCo1> yeah
[16:35] <CyberCo1> module unknown
[16:35] <CyberCo1> wtf?
[16:35] <CyberCo1> I think this is bug worthy
[16:35] <CyberCo1> shouldn't be this hard to get cron to open something to display
[16:36] <leleobhz> well
[16:36] <leleobhz> another
[16:36] <leleobhz> remove -vo and -v's
[16:37] <leleobhz> add --novideo
[16:37] <CyberCo1> k
[16:37] <leleobhz> or
[16:37] <leleobhz> (if dont work)
[16:37] <leleobhz> like manpage say
[16:37] <leleobhz>        -novideo
[16:37] <leleobhz>               Do not play/encode video.  In many cases this will not work, use -vc  null  -vo  null
[16:37] <leleobhz>               instead.
[16:39] <CyberCo1> 1 min
[16:41] <CyberCo1> http://pastebin.com/m4dc2fcee
[16:41] <CyberCo1> I think I'm going to have to go deeper down the rabbit hole
[16:42] <CyberCo1> need to find out why cron is blocked from using display and how it is done
[16:42] <CyberCo1> but right now I have to cook some breakfast
[16:42] <CyberCo1> :)
[16:42] <CyberCo1> thanks for trying folks
[16:42] <leleobhz> i think the problem isnt X
[16:42] <leleobhz> CyberCo1: ok
[16:42] <Kopfgeldjaeger> or just use that applet from getdeb
[16:42] <CyberCo1> Kopfgeldjaeger: if it will play a playlist, I'm all over it
[16:42] <CyberCo1> but this still bugs me
[16:42] <Kopfgeldjaeger> and maybe write a script that shuffles the song in the configuration of the applet
[16:42] <CyberCo1> and I'm stubborn
[16:43] <CyberCo1> I will get to the bottom of this
[16:43] <CyberCo1> eventually
[16:43] <CyberCo1> I just figured it'd be a no-brainer for the Motu's
[16:43] <leleobhz> CyberCo1: may you try #mplayer
[16:44] <CyberCo1> its not just mplayer though
[16:44] <CyberCo1> its also audacious
[16:44] <CyberCo1> and xmms
[16:44] <CyberCo1> I'm beginning to think cron can't run any graphical apps at all, and I'll test that theory after breakfast
[16:44] <Kopfgeldjaeger> CyberCo1: where are you from?
[16:49] <CyberCo1> kentucky
[16:50] <gnomefreak> is anyone else being bit by ruby1.8: symbol lookup error: /usr/lib/ruby/1.8/i486-linux/gtk2.so: undefined symbol: gtk_file_system_error_quark   when trying to run an app?
[16:50] <gnomefreak> ^^ intrepid
[16:51] <gnomefreak> CyberCo1: it should beable to but not reall sure why you would want it to. it will end up being very slow
[16:52] <CyberCo1> to have the option would be nice
[16:52] <CyberCo1> not by default
[16:53] <gnomefreak> CyberCo1: ive never tried but i dont see why it cant
[17:09] <CyberCo1> gnomefreak: I don't see why it can't either, but it's not
[17:11] <CyberCod> no matter how you stipulate the display, it won't take it
[17:11] <CyberCod> at least not in hardy
[17:11] <CyberCod> not a problem in feisty
[17:11] <CyberCod> dunno about gutsy
[17:27] <k0p> how make a non native package?
[17:28] <leleobhz> ?
[17:28] <leleobhz> non native?
[17:29] <k0p> well.. i'm in trouble because it not create a diff file
[17:29] <k0p> it create only a tar.gz
[17:29] <jpds> k0p: Rename the .tar.gz to packageName_version.orig.tar.gz
[17:30] <k0p> jpds, does work ..
[17:30] <k0p> umit (0.9.5RC2-0ubuntu1)
[17:30] <k0p> is 0.9.5RC2 version?
[17:31] <jpds> I think you should rename it to umit (0.9.5~rc2-0ubuntu1)
[17:31] <jpds> And call the tarball: umit_0.9.5~rc2.orig.tar.gz
[17:33] <k0p> jpds, it's of course temporary
[17:33] <k0p> but we're working on stable right now
[17:33] <k0p> but we can't release yet
[17:37] <RoAkSoAx> does anyone of you has the Debian New Maintainer's Guide in one single document?
[17:42] <nxvl> RoAkSoAx: there is a PDF version of it
[17:42]  * nxvl seaarches
[17:44] <RoAkSoAx> didn't know :
[17:44] <nxvl> RoAkSoAx: sudo apt-get install maint-guide
[17:45] <nxvl> comes with the html, pdf, txt, ps and smgl version of it
[17:45] <RoAkSoAx> nxvl: ok cool, i found the pdf too
[17:45] <coppro> ok, I have a question
[17:45] <coppro> what are the allowable doc-base ssections?
[17:45] <nxvl> as in?
[17:46] <coppro> on package.doc-base
[17:46] <coppro> there is a field called Section:
[17:46] <coppro> no matter what I put there, lintian complains
[17:47] <nxvl> Section?
[17:47] <nxvl> no
[17:47] <nxvl> the package.extension files under debian/ directory only show the path to the files which needs to install
[17:47] <nxvl> not any Sections
[17:47] <nxvl> that i remember at least
[17:49] <coppro> not doc-base
[18:20] <ScottK> Dear fellow motu-sru members: Do the reports in Bug 246301 amount to a regression that needs to be reverted?
[18:20]  * ScottK is inclined to say yes, but I haven't followed it closely.
[18:20] <ScottK> tseliot: What do you think?
[18:22] <tseliot> ScottK: there is little we can do if a driver breaks some cards and solves problems for others
[18:23] <coppro> ScottK: what are valid Section entries in doc-base files?
[18:23] <coppro> lintian complains at me!
[18:23] <tseliot> ScottK: other users added a comment on my blog to say that their ATI cards work well with the new driver
[18:24] <ScottK> tseliot: This is why I'm not sure if it's truly a regression.
[18:24] <ScottK> coppro: Run lintian with -I and see if it gives you enough detail to figure it out.
[18:24] <coppro> my experiences with fglrx can only be described as bad
[18:24] <coppro> -I?
[18:25] <ScottK> tseliot: Would you please at least comment in the bug and at least tell him how to get back to the previous version then.
[18:25] <ScottK> coppro: lintian -I filename.dsc or .deb
[18:26] <coppro> W: libmk4-doc: doc-base-unknown-section libmk4-cpp:6 Apps/Programming
[18:26] <ScottK> coppro:  That's a capital i if it's ambiguous with small l
[18:26] <coppro> yeah, that's what I see
[18:26] <tseliot> ScottK: it's what I suggested in comment 23. I can post step-by-step instructions. What do you think?
[18:26] <ScottK> With -I it should spit out additional explanaition.
[18:26] <coppro> lower-case i gives the complet information
[18:26] <ScottK> tseliot: I think that's what'
[18:26] <ScottK> what's needed.
[18:27] <ScottK> coppro: Try -Ii
[18:27] <coppro> but that just says "the possible values are similar but different from the menu values" or something like that
[18:27] <tseliot> ScottK: ok, thanks for the notification
[18:27] <coppro> but I can't find the list of valid doc-base sections
[18:27] <ScottK> coppro: It should also give you a Debian standards paragraph reference.
[18:27] <coppro> furthermore, there are packages already installed that use this section
[18:27] <coppro> I've looked at that reference it says nothing
[18:27] <ScottK> Not sure then.
[18:28] <coppro> :(
[18:28] <coppro> I'm thinking I have to look into lintian's source package to see what it'll accept
[18:29] <ScottK> That's one way to do it.  IIRC it's written in Perl.
[18:29] <coppro> having just downloaded it, I can confirm that
[18:30] <StevenK> Mostly Perl. Some shell is sprinkled around it.
[18:30] <ScottK> You might also file a bug with a patch suggesting a more useful long explanation in Debian.
[18:30] <ScottK> Hello StevenK.
[18:31] <coppro> I think the lintian check is busted, actually
[18:31] <ScottK> coppro: Make sure you have the lintian from Intrepid.
[18:31] <coppro> I don't, that could be it
[18:32]  * StevenK waves to ScottK
[18:32] <ScottK> coppro: I've asked for it to be put in hardy-backports, but it hasn't yet.
[18:32] <coppro> ok, it's in
[18:33] <coppro> nope same error
[18:33] <ScottK> OK.  Well at least you've tried the latest so no one can complain.
[18:34] <coppro> ok well it seems the section I want is Programming
[18:34] <coppro> yet the reference guide lintian quotes and a bunch of installed packages use Apps/Programming
[18:35] <coppro> does Ubuntu have different menu sections than Debian?
[18:35] <ScottK> Ubuntu doesn't use Debian Menu.
[18:36] <coppro> well doc-base sections then
[18:36] <coppro> (which are supposed to basically be Debian Menu sections)
[18:36] <ScottK> Not AFAIK.
[18:36]  * ScottK looks over at StevenK and wonders what he knows about it.
[18:36]  * StevenK tries to figure out how to travel around Boston
[18:37] <StevenK> I don't think doc-base is used much in Ubuntu.
[18:38] <tseliot> ScottK: was this package removed from hardy-updates? I can find it only on launchpad: https://launchpad.net/ubuntu/hardy/i386/xorg-driver-fglrx-envy/1:7.1.0-8-4+<IP_ADDRESS>1-501.30
[18:38]  * ScottK looks.
[18:40] <ScottK> tseliot: It's marked Superseded, so it was replaced by the later upload.
[18:40] <ScottK> I'd suggest have him wget the .deb from Launchpad and then install it using dpkg.
[18:40] <coppro> ok, now I have an irritating issue
[18:41] <tseliot> ScottK: yes, that's the only solution. Thanks again :-)
[18:41] <coppro> my pacakge needs separate -arch and -indep targets
[18:41] <coppro> is there any way to invoke the dh_install* scripts to only install for the appropriate packages/
[18:43] <coppro> hello?
[18:43] <coppro> ScottK?
[18:46] <ScottK> coppro: Sorry.  I need to focus on some $WORK right now.  Generally you're better off asking questions of the channel in general as others may be better positioned to answer.
[18:46] <coppro> ok
[18:46] <ScottK> coppro: My short suggestion is find another similar package and use it for an example.
[18:47] <coppro> or I could just ingore -arch and -indep...
[18:47] <coppro> no wait, I was misreading policy
[18:55] <warp10> Hi all
[18:55] <jpds> hi warp10
[18:56] <warp10> hey jpds
[18:56] <coppro> hey, does anyone know how to get debhelper to install only arch:all or arch:any packages?
[18:58] <slytherin> coppro: what do you mean exactly?
[18:58] <coppro> well, I'm writing a library, so the binary packages are arch:any and the docs package is arch:all
[18:58] <coppro> policy requires that the binary-indep target make all the architecture-indep packages
[18:59] <coppro> but debhelper will try to install even the binary-arch targets if binary-indep is called
[18:59] <slytherin> coppro: paste your rules file to pastebin
[19:01] <coppro> http://rafb.net/p/z0fNlW18.html
[19:01] <tuxmaniac> slytherin: did you try building electric?
[19:02] <slytherin> tuxmaniac: No. Didn't find time. Will do latest by Monday.
[19:04] <slytherin> coppro: Sorry, not able to figure out the problem.
[19:04]  * slytherin has to restart
[19:35] <NCommander> morning ScottK
[19:44] <coppro> NCommander, I have a tricky one for you
[19:44] <NCommander> ok
[19:44] <coppro> how do I tell dh_install to only install some packages' files?
[19:45] <coppro> same with the rest of debhelper
[19:45] <coppro> I need to be able to split up the -indep and -arch files, so I need to tell debhelper to only install ome
[19:48] <NCommander> coppro, create package.install files, and list the files that need to go into each package
[19:48] <NCommander> (take a look at codeblocks to see how its done)
[19:48] <coppro> I know that
[19:48] <NCommander> ok
[19:48] <coppro> but how do I tell debhelper to only install files from a certain package
[19:48] <NCommander> I don't understand the question (sorry, I'm a litlte out of it)
[19:49] <coppro> well, policy says that the binary-arch target builds all the architecture-specific packages
[19:49] <NCommander> Right
[19:49] <coppro> and binary-indep makes the independent ones
[19:49] <NCommander> and binary-indep builds any all arch packages
[19:49] <coppro> but debhelper will try to install all the packages
[19:50] <NCommander> debhelper doesn't install the package ... your make install rule does
[19:50] <coppro> install isn't part of policy
[19:50] <NCommander> Where's your rules file
[19:50] <coppro> my point is that if i run binary-arch, I'm only allowed to make the arch-dependent packages
[19:50] <NCommander> I think I get what your saying, but I need some point of reference to work form
[19:50] <coppro> http://rafb.net/p/z0fNlW18.html
[19:51] <NCommander> Are you splitting your package into multiple ones, one of which is arch all?
[19:51] <coppro> no, I'm trying to package the python component into another package
[19:51] <coppro> so you could say yes, I guess
[19:52] <coppro> (and the docs are arch all as well)
[19:52] <NCommander> So you have one python package, and one that is arch all
[19:52] <coppro> currently i have 2 library packages (regular and -dev), both arch any. I also have a docs package, arch all
[19:52] <NCommander> Oh, I get it
[19:53] <NCommander> Does the documentation need to be built or somethign (i.e. pod2man, or something else)
[19:53] <coppro> no
[19:53] <coppro> but it needs to be packaged by binary-indep, as I understand it
[19:53] <NCommander> then build-indep is a no-op;
[19:53] <NCommander> Unless I'm very much mistaken
[19:53] <coppro> build-indep, yes
[19:53] <coppro> binary-indep, no
[19:53] <coppro> (build-indep will be used by the python component anyway)
[19:54] <NCommander> Oh, OH!
[19:54] <NCommander> Ok
[19:54] <NCommander> Finally I got it
[19:54] <NCommander> I haven't played with an arch all package in quite awhile
[19:54] <coppro> so my question is how do I get debhelper to not bother with the ones that aren't necessarily built?
[19:56] <NCommander> Give me a sec to think
[19:59] <NCommander> List the docs under the *package*.docs file, and move the dh_installdocs rule to binary-indep
[20:00] <coppro> doy!
[20:00] <k0p> hi all.
[20:00] <coppro> thanks, I'm stupid
[20:00] <NCommander> coppro, you may also need to copy the dh_compress, and everything below it (expect shlibdeps) to the indep file
[20:00] <NCommander> ; rule
[20:00] <coppro> yeah
[20:01] <NCommander> You threw me through a loop on that one
[20:01] <NCommander> Most packages that just move documentation do it as part of the binary-arch step
[20:01] <NCommander> I've seen it even if it generates an all package
[20:02] <k0p> packages like umit-locale-pt-pt is used on python applications?
[20:02] <coppro> yeah, the problem was I thought the python was arch-indep, which I just realized it isn't
[20:02] <coppro> so it doesn't matter
[20:02]  * NCommander hits coppro
[20:03] <NCommander> There
[20:03] <NCommander> Now you'll remember ;-)
[20:03] <coppro> but if it was, it would be a headache to deal with
[20:03] <NCommander> python kinda weird because you can get both arch-dep and indep-dep python packages
[20:03] <coppro> (it's a python library so it has to actually get compiled)
[20:03] <NCommander> yeah
[20:03] <NCommander> pyscho is another one like that
[20:05] <coppro> but if, say, there was a perl module in the source package, that would be tough with debhelper
[20:05] <NCommander> coppro, why, it would just use build-indep for everything since the module would be arch all ...
[20:06] <coppro> yes, but what if there was an arch-dep package in the source package? How do you get debhelper not to explode if it finds that the -dep stuff isn't ready to install when you try and install the -indep stuff?
[20:10] <NCommander> coppro, you lost me
[20:10] <coppro> nvm I know what to do
[20:10] <coppro> don't have separate build-arch and build-indep targets
[20:11] <NCommander> coppro, they're required ;-)
[20:12] <NCommander> But you can alias them to build
[20:12] <coppro> no they aren't
[20:12] <coppro> they are clearly listed as optional in policy
[20:13] <coppro> then all you need to is, rather than call dh_builddeb at the end, use dpkg-deb yourself for the packages you want
[20:16] <coppro> thus, I conform to policy, even though it's a bit of a cop-out
[20:17] <jmarsden> REVU help wanted getting started: I uploaded a package last night using dput, but today trying to log in to it, REVU still says I don't have an account...?
[20:17] <jpds> jmarsden: Which package?
[20:18] <jmarsden> iriverter.  I fixed LP #91237
[20:18] <jpds> jmarsden: Have you added yourself to https://launchpad.net/~revu-uploaders?
[20:18] <coppro> and asked for a key update here?
[20:18] <jmarsden> OK, neat.  I added myself... didn't ask for a key update.  Key udpate, please :-)
[20:19] <coppro> it should happen overnight, so try now
[20:19] <jpds> jmarsden: One moment please.-
[20:19] <jmarsden> I thought that since it let me dput it must haev already recognized my key?
[20:20] <coppro> try dputting again
[20:20] <jpds> coppro: No need.
[20:20] <jpds> jmarsden: I've moved your upload from the rejected packages. It should appear soon.
[20:20] <jmarsden> Thanks... what caused it to be rejected??
[20:21] <jpds> jmarsden: Your key was not in the keyring.
[20:21] <jmarsden> OK.  But dput doesn't tell you that at time of upload?  Would be nice if it did.
[20:21] <StevenK> jmarsden: dput can't usually check that.
[20:22] <jpds> jmarsden: dput just checks if the sigature is correct.
[20:22] <jmarsden> OK, thanks.  Makes sense.
[20:24] <jpds> siretart: Is the move_uploads scripts suppose to have root as owner? I cannot do: sudo -u revu1 ./move_uploads.sh
[20:28] <jpds> jmarsden: Et voila, your upload has been successfully processed: http://revu.ubuntuwire.com/details.py?package=iriverter
[20:29] <jmarsden> jpds: Thanks!  Now I need people to review it :-)  BTW, Would it be reasonable to file a wishlist bug against REVU suggesting that when it rejects an upload for lack of key in keyring, it emails the signer?
[20:31] <jpds> jmarsden: That would be an idea, the place is https://bugs.edge.launchpad.net/revu
[20:32] <jmarsden> Thanks.  OK... now I have another new packager question: I ran debuild and lintian on Ubuntu 8.04 and they said the latest standards version was 3.7.3, so I updated to that.  Now REVU lintian says the current number is 3.8.0 -- how do I get a "more up to date" development environment to avoid this kind of thing?
[20:32] <jpds> jmarsden: Current Standards-Version is 3.8.0.
[20:33] <jpds> And I think that the issue may be fixed by installing lintian from hardy-backports
[20:33] <stgraber> 1.24.1~hardy1 is in hardy-backports so using it should work fine
[20:34] <jmarsden> jpds: OK, will do, thanks.
[20:34] <stgraber> another way of testing that is to use an Intrepid chroot but that's a little more work to create and maintain
[20:34] <stgraber> (running Intrepid is another way but probably not the recommended one if you need a stable system)
[20:34] <jmarsden> stgraber: Is there a document describing hwo to set that up you can point me to?  Yes, I'm not ready to run Intrepid yet!
[20:36] <stgraber> https://wiki.ubuntu.com/DebootstrapChroot should be a good starting point
[20:36] <jpds> stgraber: Using http://people.ubuntu.com/~pitti/scripts/makechroot makes chroot creating easier.
[20:37] <stgraber> jpds: oh, nice
[20:37] <jmarsden> Thanks, I'll try it out.
[20:38]  * jpds personally comments out the bind mounts but they may be useful.
[20:40] <jpds> evening norsetto
[20:41] <norsetto> hi jpds
[20:41] <coppro> what debhelper script is supposed to add ldconfig to postinst and postrm scripts
[20:46] <norsetto> coppro: dh_makeshlibs
[20:46] <coppro> yeah, it was my fault, I did a patch wrong and seriuosly confused it
[20:47] <highvoltage> norsetto: hey there
[20:47] <norsetto> highvoltage!
[20:47] <highvoltage> :)
[20:47] <norsetto> highvoltage: how is it mate?
[20:48] <highvoltage> norsetto: it's going well, I was wondering if you could answer a question I have... do merges only happen during the beginning of the development cycle, or does it sometimes happen during it as well?
[20:48] <highvoltage> I'm just wondering if I'll get a chance to learn how to do it during this cycle still, or if I'd have to wait for the next one.
[20:48] <norsetto> highvoltage: well, we can merge up until final freeze, but its more and more stricter
[20:49] <highvoltage> norsetto: aah
[20:49] <norsetto> highvoltage: right now its ok, the merge has to be justified though
[20:49] <highvoltage> norsetto: hmm, I see. is there a place where I can find out if there's something that needs to be merged?
[20:50] <norsetto> highvoltage: mon and dad are the right places
[20:51] <norsetto> highvoltage: well, obviously you won't know if it will be just a sync or a merge, you will have to check
[20:52] <emgent> norsetto: o/
[20:52] <norsetto> emgent: a noi o/!
[20:53] <highvoltage> norsetto: how are things your side?
[20:53] <norsetto> highvoltage: ecticts, but keeps an old carcass like me young :-)
[20:54] <norsetto> highvoltage: and today I discovered that watermelon comes from south africa, man, you have paradise there
[20:55]  * highvoltage thought that they make watermelons everywhere :)
[20:56] <norsetto> highvoltage: yeah they do, but it originates from there
[20:56] <emgent> norsetto: -.-
[20:56] <highvoltage> heh, now I'm learning food/geography in this channel too. bonus!
[20:56] <bdrung_> yeah, i have filed three bugs in series with nobody reporting a bug between.
[20:57]  * norsetto hands over new spectacles to emgent
[20:59] <coppro> I have a package which will only work with python 2.5, but any version of 2.5 will do
[20:59] <coppro> how do I express this in my relationship?
[21:00] <coppro> nvm, didn't realize python2.5 is a package :/
[21:01] <bdrung_> coppro: either let your package depend on "python2.5" or better on "python (>= 2.5)"
[21:01] <coppro> can't go with python 2.6 though (if and when it comes out
[21:02] <bdrung_> you know that it will not work with python 2.6?
[21:06] <coppro> yes, it's a build-dep and the makefile has 2.5 hard-coded in
[21:12] <warp10> ScottK: sorry for opening all the tasks for the mayavi2 backport, I really thought it was necessary.
[21:13] <norsetto> heilá warpie
[21:14] <warp10> ciao norsetto, good to see you around!
[21:14]  * norsetto wonders how warp10 correctly guessed it was him warpie
[21:15]  * norsetto thinks that medical doctors know more than the devil ...
[21:16]  * warp10 guessed it because he didn't see any other *warp* in the channel
[21:17] <emgent> lol
[21:18] <norsetto> warp10: I have a strange problem actually, whenever I drink coffee, I get a sore eye
[21:19] <warp10> norsetto: well, try not drinking it :)
[21:21] <norsetto> warp10: ah, I discovered you!  :D
[21:29] <jmarsden> Is anyone willing to review my first ever Ubuntu packaging attempt: http://revu.ubuntuwire.com/details.py?package=iriverter
[21:29] <kaminix> https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate <--  I'm trying to package a new edict version, could anyone help me? I'm not really sure how to apply this information to packaging a dictionary file.
[21:30] <kaminix> The current edict version is almost a year old
[21:33] <kaminix> Pretty please? :)
[21:34] <jmarsden> kaminix: I'm a newcomer to Ubuntu packaging, but I can try to help... what is the issue you are trying to solve exactly?
[21:35] <kaminix> Okay, so the edict file is pretty much just a long text file (japanese<->english dictionary file) in /usr/share/edict, I'm just trying to update the package but I don't know how.
[21:35] <jmarsden> kaminix: which step of that recipe did you get 'stuck' at?
[21:35] <kaminix> 3
[21:36] <jmarsden> kaminix: So the issue is that the new edict file you want to package doesn't come in an upstream tarball??
[21:37] <kaminix> It came with a gz file, which I've unpacked. It doesn't have it's own directory which I can cd in to.
[21:39] <jmarsden> If you apt-get source edict and then untar the .orig.tar.gz that gives you you'll see how the original package was back then.
[21:39] <jmarsden> Then you need to try and find the new edict in a similar form, I would think?
[21:40] <kaminix> I have the new edict, and it's just a text file by default when you untar it.
[21:42] <jmarsden> kaminix: So where did the packager of the current Ubuntu edict package find that orig.tar.gz file?  I don't know, but finding out would help you.  I suppose you could try creating such an orig.tar.gz yourself???  But I'm pretty sure that breaks the rules...
[21:44] <kaminix> I think the old packager must've created it himself, because on the official page they only give .gz I think.
[21:44]  * kaminix opens up official page again
[21:45] <jmarsden> Then I'd suggest you do the same, and email the old packager asking about it.
[21:50] <kaminix> The original packager was Maintainer: Ubuntu MOTU Developers<EMAIL_ADDRESS>should I mail the list?
[21:55] <kaminix> Strange. This file contains enamdict which is not installed by the edict package but kept in it's own enamdict package
[22:06] <kaminix> I've sent a message to the mailing list now, will I get answers or do I need to register somehow?
[22:10] <jmarsden> kaminix: If you're doing packaging work, I'd subscribe to that list.
[22:10] <kaminix> I'm subscribed now. I don't know if I'll be packaging a lot though.
[22:11] <kaminix> Do I want MIME digests if I use KMail?
[22:26] <siretart> jpds: yes. it has do be run as root in order to fix the permissions and owner of the files it moves
[23:11] <NCommander> I be back
[23:14] <Iulian> cody-somerville: It won't even build if I add the upstream's clean rule.
[23:24] <NCommander> So whats up world
[23:26] <Iulian> Well, enjoying the week-end.
[23:52] <k0p> is now revu slow? :S
[23:52] <k0p> I make dput and nothing appears yet
[23:52] <wgrant> kirkland: Did you upload it before XX:50?
[23:54] <k0p> yeap
[23:55] <k0p> http://revu.tauware.de/details.py?package=umit what's last chance?
[23:55] <k0p> may be cache
[23:55] <k0p> but I think no
[23:56] <k0p> i'll upload again
[23:56] <wgrant> Don't.
[23:56] <wgrant> If it's not there, I'll poke the server and work out what went wrong.
[23:56] <wgrant> July 19 12:00... that's old.
[23:57]  * NCommander works out how old it is
[23:58] <k0p> wgrant, ok.. but may be it's my mistake
[23:58] <wgrant> It's Europe/Berlin.
[23:58] <k0p> yeah UTC+2
[23:58] <wgrant> Your upload is still sitting in the incoming dir :(
[23:59] <wgrant> k0p: Ah, you upload the i386.changes, not the source.changes.


[05:19] <chieta> how to show the firefox on the desktop number 3 and 4 only?
 on openbox... afaik only all desktop or specific desktop
[10:34] <mistar_fresh> hello people,,, i wanna ask : Will there be a 32bit release of Lubuntu/Xubuntu 20.04 LTS???
[10:36] <tomreyn> mistar_fresh: hi. there won't be. there'll be 64-bit releases only, those will support some 32-bit libraries.
[10:37] <mistar_fresh> tomreyn : are the system requirements going to increase if i install 64-bit version?
[10:38] <tomreyn> you'll need a 64-bit compatible CPU and other than that your system will need to match the system requirements, which i assume are documented on lubuntu.me
[10:39] <mistar_fresh> tomreyn : whatever man ,,, thanks for help :) I will wait until it is released...
[19:08] <mr_fresh> can someone tell me the minimum system requirements for lubuntu 19.10 64-bit ???
[19:14] <mr_fresh> nobody knows :D
 64bit and 500mram will make it boot
 But won't be able to do much things, for example, surf the web
[19:28] <kc2bez> I think they left @HMollerCl
 Not sure, but Telegram seemed to indicate that I had managed to unpin that post, thus I pinned it again just in case.


[06:23] <Delvien> How much space would you say i need for ubuntu server? 10gigs ?
[06:23] <Delvien> for /
[07:18] <Kamping_Kaiser> to install?
[07:19] <Kamping_Kaiser> 1~gb for a base(ish) install+software
[18:51] <Delvien> Is there a difference in kernels for AMD vs intel ? Does it really matter?
[18:52] <Delvien> for ubuntu-server that is. (7.10)
[19:15] <Delvien> nm found it out
[19:18] <antdedyet> Delvien: what is the answer?
[19:18] <antdedyet> !kernel
[19:18] <ubotu> The core of the Ubuntu Operating System is the Linux kernel: see https://help.ubuntu.com/community/Kernel - You shouldn't have to compile your own, but if you're convinced you do, see https://help.ubuntu.com/community/Kernel/Compile - For more: /msg ubotu stages
[19:18] <Delvien> antdedyet there are only 2 "install" versions, 32 bit and 64 bit
[19:20] <Delvien> antdedyet that means that the instlal will automatically pick up what processor you have and install all the nec stuff for you


[03:41] <duflu> RAOF: When I sleep the phone clients correctly scale down to 10Hz. Do we have sleep/resume messages yet?
[03:42] <duflu> ... because obviously clients should be told to sleep properly
[03:42] <RAOF> I believe so?
[03:43] <duflu> RAOF: I don't see any Mir*Event
[03:44] <duflu> Oh hang on
[03:45] <duflu> No, can't see it
[03:51] <duflu> RAOF: Were we planning on utilizing any GL error codes?
[03:51] <RAOF> No
[03:51] <duflu> Or does that require Khronos changes/blessing?
[03:51] <RAOF> We could absolutely do it, but I think we ended up deciding that it's not an EGL thing.
[03:52] <duflu> OK. What I do remember is that argument being complex enough I don't want to remember it right now
[04:57] <RAOF> Man, this is going to provoke conflicts with _everything_
[05:16] <RAOF> Oh, _arse_
[05:16] <RAOF> We can't hide anything.
[05:19] <RAOF> Because we expect (server) clients to subclass DefaultConfiguration, which means they need to be able to resolve everything that DefaultConfiguration includes.
[05:39] <RAOF> Hm.
[05:39] <RAOF> Doesn't that make much of the headers in src/ implicitly ABI?
[05:40] <RAOF> (The _best form_ of ABI)
[07:12] <duflu> RAOF: Hey it looks like Android-input drops/deduplicates events when we're not keeping up
[07:12] <duflu> That's good... we don't have to do anything
[07:12] <RAOF> Huzzah!
[07:15] <RAOF> Sweet. So, I very nearly have a libmirclient with an ABI equal to the ABI we expect to expose..
[07:42] <alf_> RAOF: @break-out-rpc-transport, so ancillary socket data are queued separately from normal socket data?
[07:42] <RAOF> alf_: Correct.
[07:42] <RAOF> It's all very complicated.
[07:43] <RAOF> If you sendmsg(300 bytes, 1 fd), send(300 bytes) and recvmsg(600 bytes, <some fds>, MSG_WAITALL) your recvmsg will read 300 bytes and 1 fd.
[07:43] <RAOF> If you sendmsg(300 bytes, 1 fd), send(300 bytes) and then recv(301 bytes), you'll (a) receive 301 bytes, and (b) never be able to get at that fd.
[07:44] <RAOF> For added annoyance, if you recvmsg(300 bytes, <some fds>, MSG_WAITALL) *and get interrupted* you'll receive some data < 300 bytes and an fd, and your next recvmsg will receive the fd again.
[07:45] <RAOF> That seems likely to be a bug, though.
[07:48] <alf_> RAOF: What about MSG_TRUNC ? Is this when we sendmsg(300,2) and recvmsg(300,1) ?
[07:48] <RAOF> MSG_CTRUNC, yeah.
[07:49] <RAOF> Well, as long as you haven't run into CMSG_SPACE aliasing :)
[07:51] <alf_> RAOF: (trying to understand how queuing ancillary data works), if we sendmsg(300,1) and recv(299) is the fd lost?
[07:52] <RAOF> I don't think so, no.
[07:52] <alf_> RAOF: or do we need to move on reading to a subsequent message for the fds to be discarded
[07:52] <RAOF> We need to move on to reading a subsequent message.
[07:53] <RAOF> I don't think there's a test for that behaviour in the unit tests, though.
[07:54] <alf_> RAOF: I wonder how the fd-data association is maintained since we are using a stream socket, so no strict message boundaries
[07:55] <RAOF> alf_: There are message boundaries in the kernel.
[07:55] <alf_> RAOF: true
[07:55] <RAOF> Internally it's got a bunch of skbs, and SOCK_STREAM just reads on to the next one when the current one's done.
[08:01] <alan_g> RAOF: I don't need to keep you late, but if you have time to help with packaging...
[08:01] <RAOF> alan_g: Just commenting now :)
[08:09] <RAOF> alan_g: Oh, and other than the CI failure bit, the packaging seems fine.
[08:09] <alan_g> RAOF: thanks for looking.
[08:14] <RAOF> alan_g: By the way, I've stripped all those symbols out of libmirclient locally by way of symbol visibility; we could probably do the same for libmirplatform..
[08:15] <alan_g> RAOF: but what about client code that needs the symbols?
[08:15] <alf_> RAOF: how does that work with testing (where we may need access to some of the internal symbols)?
[08:15] <RAOF> alf_: I build a couple of things twice.
[08:16] <RAOF> alan_g: What client code would need those symbols?
[08:18] <alan_g> RAOF: Hmm. I was assuming that as the headers were published they were already needed in our public API
[08:18] <RAOF> Right, but not from libmirclient.so
[08:19] <alan_g> And we do use them in examples of "how to use Mir"
[08:20] <RAOF> But, again, not from libmirclient.so
[08:20] <RAOF> These symbols aren't being hidden from libmirserver.so, but we were *also* exporting them from libmirclient.so.
[08:23] <alan_g> Hmm. So we could put them all into libmirplatform (and export then) and also put the ones used into libmirclient that it uses (internally). That could avoid the new lib
[08:24] <alan_g> Could we also remove mircommon-dev from libmirclient-dev?
[08:24] <RAOF> Possibly?
[08:24] <RAOF> EOD for me today though, sorry.
[08:25] <RAOF> I'll push the branch
[08:25] <RAOF> You're looking for lp:~raof/mir/symbols-file. It's still a little WIP.
[08:29] <alan_g> RAOF: ak
[08:31] <alf_> RAOF: scenario sendmsg(300, 1) sendmsg(300,1) recvmsg(300, 0) recvmsg(0, $Y) Y == ?
[08:33] <alf_> RAOF: i.e. if we ask for Y=1 fd will we get MSG_CTRUNC, or do we need to read at least one more byte to get into the next msg in order to get access to the second message's fd?
[08:33] <alf_> RAOF: I guess we need to experiment
[13:19] <alan_g> mterry: After emailing you I removed the "Conficts:" to see if CI would then work.
[13:19] <mterry> alan_g, ah ok
[13:21] <alan_g> AFACS the build script is using dpkg directly. BUt I don't know much about it
[13:44] <alf_> anpok: You mentioned something about showing the previous frame instead of current?
[14:00] <alan_g> mterry: I need advice. Removing "Conficts:" seems to satisfy CI (but is probably lying), and some documentation suggests "Break:" as a possible alternative.
[14:04] <mterry> alan_g, yeah...  Breaks is I think generally recommended over Conflicts except in some cases I can't remember. But the documentation I was looking at used Conflicts so I recommended that on to you
[14:04] <mterry> I'm honestly not super clear on the difference
[14:05] <alan_g> mterry: how bad is it to have neither?
[14:06] <mterry> alan_g, if they share files, it is bad but I don't quite know in which circumstances it will break
[14:07] <mterry> alan_g, one of those things I've never gone against recommendations for :)
[14:08] <alan_g> I'll try "Breaks" and see if CI breaks. If it works I know what to do. If it fails... I'll consult another expert (RAOF)
[14:19] <anpok> alf_: yes
[14:19] <anpok> it was best to notice inside the pin entry dialog
[14:20] <anpok> I had a devel-proposed image + qt comp silo, removed the silo then upgraded
[14:20] <anpok> i mean I upgraded the image..
[14:21] <anpok> and it was easy to reproduce in the pin entry
[14:21] <anpok> after another round of flashing devel-proposed the issue is gone
[14:43] <camako> mterry, once upon a time you asked for nested lifecycle event support :
[14:43] <camako> https://code.launchpad.net/~cemil-azizoglu/mir/nested_lifecycle_events/+merge/224426
[14:54] <kgunn> in a galaxy far far away
[15:36] <tedg> dednick, So I thought when we were talking with mdeslaur that we wanted the second socket AND a list of people to connect.
[15:36] <tedg> The second socket takes care of the connection restriction aspect.
[15:36] <tedg> But we still want to know who is connecting and if they're someone we expect.
[15:37] <tedg> That being said, that was my understanding, if mdeslaur is willing to sign off on not having the list, I'm happy not having to make it. :-)
[15:37] <mdeslaur> there's not way of validating the list
[15:37] <mdeslaur> we assume whatever is connecting there is trusted
[15:38] <dednick> tedg: ^ yeah. no point if you can get around it...
[15:38] <mdeslaur> tyhicks could confirm
[15:41] <tedg> K
[15:41] <tedg> It seems a bit odd to me.
[15:42] <tedg> I guess in the future we'll restrict that socket to only being able to make trusted prompt sessions.
[16:06] <racarr__> Morning


[16:00] <steinex> Hi, we have a weird problem with an ubuntu precise preseed install using latest installer als kernel from proposed. The problem is that crypto-modules in /lib/modules/<kernel>/crypto are missing in the installer, thus the installer is unable to create a LUKS partition
[16:01] <steinex> there is no additional "installer component" to get these modules. the weird thing is: this worked 14 days ago
[16:01] <steinex> *any* hints?
[16:01] <xnox> steinex: please use 12.04.4 installer. or wait for the updated kernel (the fix for the missing crypto kernel module will be in the proposed  kernel after current one, eg. 1-3 weeks)
[16:01] <xnox> steinex: if you are doing pxeboot, you need to update it.
[16:02] <steinex> ok, will have a look
[16:02] <xnox> steinex: http://cdimage.ubuntu.com/netboot/12.04/ quantal, raring, saucy stack netboot images work.
[16:03] <xnox> steinex: the one with precise 3.2 kernel does not at the moment. It has been release noted at 12.04.4 release, and fix for this will be in the next kernel SRU cadence.
[16:03] <xnox> (it was too late to be included in the current one about to be released)
[16:05] <xnox> steinex: we could publish a partman-crypto revert / check for the kernel module, but such an SRU would only arrive after the fixed kernel will be available from proposed =(
[16:20] <infinity> xnox: A previous build of the 3.2 d-i would work.
[16:21] <infinity> xnox: Assuming those modules just got dropped recently...
[16:21] <infinity> xnox: Or was it userspace that changed and needed the kernel fixed?
[16:22] <xnox> infinity: userspace started to use it. So one needs older partma-crypto udeb.
[16:23] <infinity> Ahh, that's a bit tougher, except with an ISO install.
[16:23] <xnox> infinity: i've checked d-i sources, and i don't see a way to disable -security -updates pockets for udebs.
[16:23] <xnox> infinity: one can opt-in into -proposed, but not opt-out from -security -updates =(
[16:24] <xnox> infinity: are the current SRU kernels released and new ones building? cause the fix is committed for the next 3.2 kernel sru and as soon as that hits proposed, we can direct people at enabling -proposed for udebs only.
[16:25] <infinity> xnox: That won't work until there's a new d-i too, but yeah, new SRU kernels are on their way soon.
[16:27] <xnox> infinity: i think it would. i only need crypto-modules udeb be in -proposed, which is not in the d-i image for pxeboot and fetched over the network.... or all of them get renamed and get fetched by strict versioned name?
[16:28] <infinity> xnox: Uhm, it's a kernel module, dude.
[16:28] <infinity> xnox: You kinda need it to match your kernel.
[16:28] <infinity> Hence need a new d-i image with matching kernel and other modules.
[16:29] <xnox> infinity: ok.
[17:01] <bdmurray> cjwatson: Could you have a look at bug 1277436 which has a patch?
[17:01] <ubot2`> Launchpad bug 1277436 in biosdevname (Ubuntu) "biosdevname renaming rule not present in initramfs, leads to unpredictable names" [High,Triaged] https://launchpad.net/bugs/1277436
[18:07] <xnox> bdmurray: that seems solid reasoning, and clean implementation. I might just sponsor that.
[18:20] <steinex> xnox: that has helped, thank you again
[18:20] <steinex> raring kernel/installer is working
[18:25] <xnox> steinex: i'm glad I've helped you.
[18:31] <xnox> steinex: the 3.2 kernel bug is tracked as bug 1276739 and is scheduled to be fixed as part of next kernel sru cadence. As a result, from now on the installed machines will use xts IV algorithm, and thus will be resilient to a malleability attack which worked against cbc algorithm. If you concerned about it, it may be a good idea to reprovision / reinstall all LUKS encrypted machines which were installed with pre-12.04.4 partman-crypto. More infor
[18:31] <xnox> mation about the potential attack vector is here: http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/
[18:31] <ubot2`> Launchpad bug 1276739 in linux (Ubuntu Precise) "partman-crypto uses xts by default, yet xts.ko kernel module is not present in 3.2 (original-point-zero stack) crypto-modules-udeb" [High,Fix committed] https://launchpad.net/bugs/1276739
[22:51] <darien> I'm testing migrating our automated installation from 10.04 to 14.04, and I'm having some difficulty trying to figure out where, exactly, to make it stop loading the graphical installer. I was wondering if the new (to 14.04?) install process is documented somewhere so I can figure out how it all works.
[22:54] <darien> (the graphical installer seems to ignore the preseed file, which is where I'm currently stuck)


[01:53] <mruffell> bdmurray: I asked Trevinho to reupload gnome-shell/bionic with the patches for bug 1886592 that were also present in todays gnome-shell/focal build you accepted into -proposed. Could you please review the bionic upload? No rush, tomorrow or later is fine, since its late for you.
[05:57] <cpaelzer> rbalint: if you are still around - how realistic is an upload for 1908259 today? (it is ok if the answer is "won't happen", but I have things blocked on it so I need to ask to know what to expect)
[08:02] <rbalint> cpaelzer, actually it is, i'm close to finishing 247.1
[08:03] <rbalint> cpaelzer, i'm picking your patch
[08:04] <cpaelzer> rbalint: awesome
[08:05] <cpaelzer> rbalint: could I ask you to retrigger qemu on amd64 and ppc64 against it once that new systemd is in proposed?
[08:16] <rbalint> sure
[08:19] <rbalint> cpaelzer, i get doft lockups when running systemd 247.1 autopkgtest with qemu -c 4 on focal host: https://pastebin.ubuntu.com/p/D45r9qKYgM/
[08:20] <rbalint> cpaelzer, i guess it is kernel, but qemu with multiple cores is also suspicious
[08:21] <rbalint> cpaelzer, it does not occur on autopkgtest runners, so it does not hold back the systemd upload
[08:29] <cpaelzer> I haven't seen those before
[08:29] <cpaelzer> I'll keep it in mind to ring a bell if it comes more often
[08:29] <cpaelzer> thanks rbalint
[18:04] <ItzSwirlz> Andddd now it's official, GTK 4 is out -_-
[18:04] <ItzSwirlz> Lets be honest we knew the day would come soon.
[18:05] <Unit193> ...Is there anything left of the API or did they strip it all out?
[18:56] <sarnold> Unit193: I think they plan on stripping out the API a little bit with each point release afterwards
[18:58] <Unit193> :D


[15:55] <milobit_> https://www.youtube.com/watch?v=_f_aZx03adM
[16:47] <Laza_> Cao
[16:47] <Laza_> ima nekog
[16:47] <Laza_> ?
[20:30] <lajka> [21:27] [474] Phazeus_tux- #lugons Cannot join channel (+b) - you are banned