[00:00] <ajmitch> people generally aren't sponsored to go to developer sprints, it's more of a distro team thing, iirc
[00:01] <nxvl> mmm
[00:01] <Fujitsu> AllHands is Canonical-only.
[00:01] <Fujitsu> And I think that one in January is the same.
[00:01] <nxvl> so, the canonical employes are the only one sponsored?
[00:01] <persia> nxvl: Don't worry about the sprint.  If, at some point in the future, you need to be there, you will be clearly told to come.
[00:02] <ajmitch> nxvl: I wouldn't say 'sponsored' so much as it's part of their job
[00:02] <persia> Fujitsu: Are you sure?  I know AllHands is limited, but I thought the sprints sometimes included others, when they were very active with targeted components.
[00:02] <somerville32> I wish I worked for Canonical.
[00:02] <persia> somerville32: There is an employment page...
[00:02] <cbx33> somerville32, heheh
[00:03] <cbx33> somerville32, what makes you say that?
[00:03] <Fujitsu> persia: Well, they're nothing like UDS.
[00:03] <cbx33> Hey Fujitsu
[00:03] <cbx33> hi all
[00:03] <somerville32> I want one of the magical employment opportunities some people seem to get - like Mark asking you personally to join Canonical.
[00:03] <Fujitsu> Hi cbx33.
[00:03] <persia> Fujitsu: No.  Nothing like UDS.  It's only people who need to be there for the target features.
[00:03] <nxvl> persia: i'm sure of it, but i want to know everything about ubuntu developing, i'm only curious
[00:03] <nxvl> :D
[00:04] <nxvl> so, the spring is like a debconf
[00:04] <nxvl> more or less
[00:05] <somerville32> Spring is a magical time but it isn't quite like a debconf
[00:05] <persia> nxvl: Well, again no.  Debconf has talks, and lots of people.  The sprint is small, has no presentations, and is just hacking on the targets.
[00:06] <nxvl> mmm, but UDS + Sprint is like a debconf
[00:06] <nxvl> :D
[00:06] <persia> nxvl: Well, there's hacking at UDS, but maybe.
[00:07]  * nxvl need to get some sleep, to much non-sense speaking :D
[00:10] <nxvl> it isn't a good thing being so workaholic
[00:11]  * jdong looks into some docs on how to write manpages
[00:11]  * jdong is being a good boy and writing some manpages for prevu to shut up lintian
[00:12] <persia> jdong: You're listening to lintian when fixing prevu to fix lintian?
[00:12] <jdong> persia: lol, yes :)
[00:12] <persia> jdong: Just remember to repeat the cycle with the new lintian :)
[00:12] <jdong> persia: today's been a circular kinda day
[00:13] <jdong> persia: it felt quite weird to type prevu prevu :)
[00:13] <persia> heh
[00:13] <somerville32> : }
[00:17] <imbrandon> someone should write a book for lulu "Ubuntu: The Making of" hehe
[00:18] <bddebian> heh
[00:19] <imbrandon> persia, btw when i was tlaking aobut poking someone it was more of a joke as I'm on that list as well as others that come in here
[00:19] <persia> imbrandon: Ah.  I should have looked.  Are you fixing my bug?
[00:20] <imbrandon> persia, hehe well i only have access to *some* parts of the domain, unfortunately that is not one of them
[00:21] <imbrandon> but i did poke nuzum about it
[00:21] <persia> imbrandon: Oh well.  We'll leave it for someone with the appropriate pixie dust then.
[00:21] <persia> Thanks.
[00:21] <somerville32> How can I tell what version of linux I'm running?
[00:21] <imbrandon> uname -a
[00:21] <imbrandon> is the linux kernel version
[00:21] <persia> somerville32: /etc/lsb-release is easy to parse
[00:22] <persia> Err.  For "which version of ubuntu am I running"
[00:22] <imbrandon> if you mean what "distro/release" then `lsb_release -a`
[00:22] <persia> uname -r also spits just a string, which is handy for scripts.
[00:22] <somerville32> Can I fix this?
[00:22] <somerville32> https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/137439
[00:22] <ubotu> Launchpad bug 137439 in linux-source-2.6.22 "Dell XPS-Z irq problems: 2.6.22 kernel won't boot without 'irqpoll' option" [Medium,Triaged]
[00:23] <imbrandon> somerville32, sure you can fix any bug you feel you are qualified to do so, but that particualr one since it has to do with the kernel i would cordinate with #ubuntu-kernel and BenC
[00:24] <imbrandon> BenC == lead ubuntu kernel guy
[00:24] <somerville32> It is tagged with bitesize
[00:24] <persia> somerville32: I don't see the tag...
[00:25] <somerville32> At the top?
[00:25] <jdong> somerville32: the kernel stuff is all managed in git too, best either prepare a patch for them to look over it
[00:25] <imbrandon> right, as i said, i dont discourage you from doing so but not all "bitesize" bugs are nessesarly MOTU ones, this case its a -kernel one
[00:25] <persia> somerville32: Ah.  It moved.  Thanks.
[00:25] <somerville32> There isn't really any way I can test the fix :/
[00:25] <persia> somerville32: Well, you could order some hardware :)
[00:26] <somerville32> lol
[00:26] <somerville32> Will ubuntu pay for it? :P
[00:26] <imbrandon> yea kernel hacking is quite hardware specific at times
[00:26] <persia> somerville32: I doubt it.  You might also check to see if the bug exists on the Dell bugtracker: there may be someone chasing it there, or someone willing to test.
[00:26] <imbrandon> somerville32, for an un-experinced kernel developer? i doubt it, but i've seen stranger things
[00:27] <Fujitsu> Most of the Dell bugs are private.
[00:27] <imbrandon> also you could try to fix it and have the person reporting the bug test it
[00:27] <persia> Fujitsu: The dell bugtracker bugs?
[00:27] <Fujitsu> persia: On launchpad.net/dell, yeah.
[00:27] <somerville32> Hmm... I'm only getting 600kb/s :(
[00:27] <imbrandon> only?
[00:27] <somerville32> Well, close to 700kb/s
[00:28] <persia> somerville32: From where to where?
[00:28] <somerville32> launchpad to Canada
[00:28] <imbrandon> lately i've been happy to get 100kb/s
[00:28] <persia> somerville32: Ah.  That seems about normal.  I usually can't pull more than about 500 (but my latency is higher)
[00:29] <somerville32> Maybe I should upgrade to ultra
[00:30] <somerville32> What should I be getting with 7mb/s and 8mb/s?
[00:30] <persia> somerville32: 7MB/s maxes out at around 700 (11 bits/byte with CRC checking)
[00:31] <somerville32> So that is about right
[00:31] <persia> somerville32: http://www.dellcommunity.com/supportforums/board?board.id=sw_linux might also be a place to check.
[00:32] <pwnguin> man, soulfu is pretty deep
[00:32] <pwnguin> it even has pets...
[00:32] <persia> pwnguin: So, when can I apt-get it?
[00:32] <pwnguin> persia: when the copyright holder clarifies the license
[00:32] <Fujitsu> pwnguin: You got it built?
[00:33] <pwnguin> yea
[00:33] <Fujitsu> Nice.
[00:33] <imbrandon> what is it ?
[00:33] <pwnguin> nethack / zelda / cartoon rendering
[00:33] <pwnguin> 3d
[00:33] <somerville32> Ooo
[00:33] <Fujitsu> It looks very nice.
[00:33] <imbrandon> nice
[00:33] <pwnguin> theres a debian itp
[00:33] <pwnguin> 60 days ago
[00:34] <somerville32> Any jave programmers in here?
[00:34] <somerville32> erm... java
[00:35]  * pwnguin has written compiler rules to translate into java bytecode
[00:35] <pwnguin> but java's pretty huge
[00:35] <persia> somerville32: There are usually several.  What's the question?
[00:36] <somerville32> I was wondering what the Java team does.
[00:37] <pwnguin> well, icedtea is out, i imagine they're working on getting that in shape for hardy
[00:38] <persia> somerville32: It's not very noisy, they tend to coordinate through the regular communication channels.  Just a group of people who try to keep Java in a sane state, and maintain VM compatibility (if possible)
[00:38] <persia> pwnguin: icedtea shipped in gutsy :)
[00:39] <jdong> persia: on i386 :)
[00:40] <persia> jdong: Well, it shipped for lots of archs.  I'm not saying anything about how it works.
[00:40] <pwnguin> "into shape"
[00:40] <pwnguin> err, "in shape for hardy"
[00:40] <jdong> persia: it shipped for i386 and amd64
[00:40] <jdong> persia: and only works in i386 :)
[00:40]  * persia retreats in the face of overwhelming knowledge and correct speech
[00:41] <jdong> persia: haha :D
[00:41] <somerville32> Hmm...
[00:41] <somerville32> This is a bit more difficult then I thought
[00:47] <pwnguin> im reading the dh_installdocs man page, and it isnt clear: does it read debian/docs and install those in /usr/share/doc/<pkgname>?
[00:47] <StevenK> pwnguin: Right
[00:49] <somerville32> Does anyone know where in the linux source package they have a nice easy config file that I just have to append irqpoll to a line?
[00:49] <pwnguin> imbrandon: do you even have access to an openGL capable box anymore?
[00:50] <imbrandon> pwnguin, not currently, i will very soon, looking at buying a new MBP
[00:50] <imbrandon> in the next 2 weeks
[00:50] <StevenK> Didn't you say that two weeks ago?
[00:50] <imbrandon> StevenK, nah
[00:51] <imbrandon> StevenK, 2 weeks ago i have my core2duo working perfect hehe
[00:51] <imbrandon> wasent in the market for a new box
[00:51] <StevenK> And then what happened?
[00:52] <imbrandon> heh well i dident have the "shutdown at X temp" on in the bios and a poer cord decided to stop the cpu fan spinage, frying the chip/board and ram
[00:52] <imbrandon> power*
[00:52] <imbrandon> in other words , my own dumb ass fault
[00:53] <StevenK> Self-assembled?
[00:53] <StevenK> Ahh
[00:53] <imbrandon> yea, i built it about a year ago
[00:53] <StevenK> You know, I check for things like that before putting the case back on. :-)
[00:53] <imbrandon> hehe well NORMALY i do too
[00:54] <somerville32> Did you mean poer or poor?
[00:54] <imbrandon> power*
[00:54] <imbrandon> e.g. a molex connector cable from the PSU
[00:55] <somerville32> Okay. I fail.
[00:55] <somerville32> rm -rf linux
[00:55] <pwnguin> i think that was more than two weeks ago
[00:57] <imbrandon> well about 3 or so
[00:57] <imbrandon> now
[01:00] <persia> So, for the xine-lib transition, I'm looking at python-pyxine.  From what I can tell, it's just library bindings, so it's hard to identify as console or X.  Any opinions on using "libxine1-console | libxine1-x | libxine1 (<< 1.1.8-2)" as the frontend dependency, or does it perhaps not need one?
[01:01] <imbrandon> hrm the frontend dep i would default to the -x one but seems sane
[01:02] <persia> imbrandon: I'm actually fairly tempted by not adding a front-end dep, as presumably the program depending on python-pyxine would have a dependency on the appropriate front-end, but I'm not sure if that would tend to break things.
[01:03] <persia> e.g. perhaps lsongs should depend on libxine1-console | libxine1 (<< 1.1.8-2)
[01:04] <imbrandon> hrm true
[01:07] <pwnguin> hey, whats the build dep for open gl?
[01:08] <pwnguin> libgl1-mesa-dev?
[01:09] <Fujitsu> !find GL.h
[01:09] <ubotu> Found: glchess
[01:09] <Fujitsu> Wrong.
[01:10] <pwnguin> heh
[01:10] <pwnguin> maybe if i knew the command to just list the build deps of a package
[01:11] <Fujitsu> !find GL/gl.h
[01:11] <pwnguin> apt-cache showsrc
[01:11] <persia> pwnguin: grep-dctrl
[01:11] <ubotu> Package/file gl/gl.h does not exist in gutsy
[01:11] <pwnguin> libgl1-mesa-dev | libgl-dev shows up in a few ive found
[01:12]  * persia is annoyed that someone decided the GL transition was complete, and deleted the excellent Wiki page explaining what to do, and why
[01:12] <LaserJock> I wondered about that as well
[01:13] <LaserJock> we should archive the transition instructions
[01:14] <pwnguin> why would you ever delete a page?
[01:14] <LaserJock> because we get too much junk
[01:15] <LaserJock> and people get confused
[01:15] <somerville32> Is this a page on w.u.c?
[01:15] <LaserJock> it was
[01:15] <persia> somerville32: It was about a year ago, but it's not now
[01:15] <somerville32> Just get them to undelete it?
[01:15] <Fujitsu> Isn't a deleted page deleted on Mon?
[01:15] <Fujitsu> *Moin
[01:15] <somerville32> Thats not what Cory told me.
[01:15] <LaserJock> I think that'd take sysadmin power if it's even still around
[01:16] <Fujitsu> archive.org?
[01:17] <imbrandon> yea the wayback machine rocks, as well as google cache
[01:17] <pwnguin> really if a page was ever useful, it shouldnt be deleted, but annotated at best
[01:17] <LaserJock> pwnguin: well obviously somebody didn't think it was useful ;-)
[01:17] <pwnguin> "<!> this page contains outdated technical information"
[01:19] <LaserJock> persia: it is odd that you'd find a package that hasn't transitioned
[01:19] <nenolod> Fujitsu, pwnguin, -- in libprojectM i have libgl1-dev | libgl-dev
[01:19] <pwnguin> the package exist yet
[01:19] <Fujitsu> That sounds wrong.
[01:19] <nenolod> oh, wait, no
[01:19] <persia> pwnguin: There was an effort about 6 or 7 months ago to clean up all the library transition pages: we used to list all the packages on the wiki, and use that to claim / report done.  Most of it was useless, as Debian has caught up.  This case is special.
[01:19] <nenolod> libgl1-mesa-dev | libgl-dev
[01:19] <nenolod> sorry.
[01:20] <Fujitsu> Yeah, that sounds better.
[01:20] <pwnguin> nenolod: thats what i went with
[01:20] <nenolod> pwnguin, yeah, it seems to be correct
[01:20] <nenolod> pwnguin, same for libglu
[01:21] <LaserJock> we should have some sort of archive page/namespace
[01:21] <Fujitsu> You'd think so.
[01:21]  * persia wonders why libGL isn't listed on http://wiki.debian.org/OngoingTransitions, even in the "Completed" section
[01:21] <pwnguin> dont need libglu
[01:21] <Fujitsu> persia: Ongoing and completed sound mutually exclusive.
[01:22] <persia> Fujitsu: You're not familiar with Debian then.
[01:23] <LaserJock> ah bugger, the lack of script hosting comes up again :/
[01:23] <persia> Fujitsu: Rather, because of the nature of the release management process, and because of the release cycle, nothing gets removed from that page until every affected package is fixed in stable, even if there's nothing to do.
[01:26] <Fujitsu> persia: Ah, right.
[01:27]  * somerville32 wonders what it would be like to develop Ubuntu with a dial-up modem.
[01:27] <LaserJock> painful
[01:27] <persia> somerville32: If you had someone shipping you daily update CDs, not so bad.  If not, you're restricted to only a couple packages, as otherwise the dependencies will ruin you.
[01:28]  * somerville32 hugs his cable modem.
[01:29] <minghua> persia: I seriously doubt that wiki.d.o page is still the main source, it seems abandoned to me.
[01:29] <somerville32> LaserJock, Are you a core-dev?
[01:29] <LaserJock> yep
[01:30] <somerville32> Splendid.
[01:30] <persia> minghua: Ah.  Do you have a better site?
[01:30]  * imbrandon hides
[01:30] <LaserJock> heh
[01:30] <minghua> persia: No.  Maybe ask on #debian-release (on OFTC)?
[01:31]  * persia suggests pwnguin might get a real answer by following minghua's suggestion
[01:34] <pwnguin> what was my question?
[01:34] <minghua> persia, pwnguin: In case of mesa, it may be also a good idea to ask on #debian-x (or whatever the Xorg team's channel is).
[01:34] <persia> #xorg-devel?
[01:35] <pwnguin> if debian wanted to talk to me they wouldnt have run away to OFTC
[01:36] <persia> Anyone have a spare close-brace?
[01:36] <minghua> I meant Debian's Xorg packaging team, of course.
[01:36]  * Fujitsu hands persia a }
[01:36]  * persia thanks Fujitse
[01:37]  * Fujitsu wonders why his trailing 'u' has been substituted on a couple of occasions, and why persia didn't have a }
[01:37] <persia> Fujitsu: Because
[01:38] <minghua> persia: Actually, I just remembered that you can get your "}" from scim. :-)
[01:38] <persia> Fujitsu: Because 1) My fingers confuse 'u' and 'e' (both center digit), and I'm lousy at using <TAB>, and 2) Because Ubuntu X doesn't like jp106
[01:38] <persia> minghua: Really?  How?
[01:38] <Fujitsu> Ah.
[01:39] <minghua> persia: It requires you to remember that }'s unicode is U+007D, then you can use the "Rawcode" IM engine.
[01:39] <persia> minghua: Thanks.  7D shouldn't be that hard to remember.
[01:40] <minghua> Alternatively you can get it from gucharmap, which requires you to remember its unicode description "closing curly bracket".
[01:40] <minghua> However it seems you have plenty of } supply on IRC. :-)
[01:41]  * persia celebrates an endless supply of }}}}}}}}}}}}...
[01:43] <persia> minghua: Usually by prompting.  join/parts feeds me lots of ']'.
[01:44] <minghua> persia: I meant "whenever you ask for a }, someone will give it to you".
[01:44] <somerville32> soren, for https://bugs.edge.launchpad.net/ubuntu/+source/abiword/+bug/117064 I would just patch abiword to ensure that directory exists and if not create it on start-up?
[01:44] <ubotu> Launchpad bug 117064 in abiword "~/.Abisuite/AbiWord-2.4/plugins not created during install" [Unknown,Confirmed]
[01:44] <somerville32> stupid auto-nick
[01:48] <pwnguin> irssi has a c0ders theme
[01:49] <pwnguin> turns irc into C/java-ish looking code ^_^
[01:49] <joejaxx> lol
[01:49] <joejaxx> pwnguin: screenshot?
[01:51] <pwnguin> http://irssi.org/themefiles/c0ders.png
[01:53] <imbrandon> eclipse? heh
[01:53] <pwnguin> i wish
[01:53] <_16aR_> back
[01:53] <pwnguin> eclipse terminals dont do color
[01:53] <_16aR_> question : what is th differences between .files and .install ?
[01:53] <_16aR_> .install are used by dh_install ?
[01:54] <persia> _16aR_: Yes.  .files should only be used secretly during the build, and you should never see it.
[01:55] <_16aR_> oh
[01:55] <_16aR_> I've just opened the source package of libgdal1 and I found .files in the debian/ dir
[01:55] <_16aR_> is it correct ?
[01:55] <_16aR_> It seems it is not
[01:55] <persia> _16aR_: Usually not, but I'm not familiar with the libgda1 packaging.
[01:56] <_16aR_> from what I've understood of this package: instead of using a .install, it uses .files which references which files should be in archive. (it was like usr/lib/libgdal1.4.0.so)
[01:58] <imbrandon> i'm guessing CPC's cant be purchased ?
[01:59] <joejaxx> cpc's?
[01:59] <LaserJock> imbrandon: I don't think so, at least not yet if you aren't a 3rd world country
[01:59] <imbrandon> classmate pc's
[01:59] <minghua> The only CPC I know is Communist Party of China...
[01:59] <LaserJock> imbrandon: we call them CMPCs
[01:59] <LaserJock> that might help minghua out ;-)
[01:59] <imbrandon> LaserJock, :( that sucks
[02:00] <LaserJock> imbrandon: it's pretty similar to OLPC, they haven't had them for sale for long
[02:00] <minghua> I thought you can buy OLPC now?
[02:01] <minghua> You'll have to buy two and get one, but still.
[02:03] <imbrandon> CMPC running a full OS seems better imho
[02:04] <LaserJock> minghua: now yes
[02:05] <LaserJock> imbrandon: well, yes they run Windows XP
[02:05] <LaserJock> but the RAM and hard drive space are a bit tricky
[02:05] <imbrandon> i was thinking a Real OS like *nix
[02:05] <joejaxx> LaserJock: i think you can get linux as an option
[02:05] <LaserJock> well, thats tricky too
[02:05] <imbrandon> or edubuntu like orga is pictured with at UDS :)
[02:05] <LaserJock> joejaxx: yes, I know, I'm developing it ;-)
[02:05]  * Fujitsu was sure he saw some CMPC specs for UDS.
[02:05] <joejaxx> LaserJock: :D
[02:05] <LaserJock> helping anyway
[02:06] <LaserJock> right now edubuntu on them is a bit sketchy
[02:06] <LaserJock> ogra's done a lot of cool work on them
[02:06] <LaserJock> xchat is sure a  bugger on them
[02:06] <imbrandon> http://photos.jonathancarter.co.za/album/uds-gutsy/PICT0422web.jpg.html?g2_imageViewsIndex=1
[02:07] <joejaxx> that reminds me i need to email RichEd
[02:07] <LaserJock> I can't change any of the preferences
[02:07] <LaserJock> becuase I can't hit the "OK" button
[02:07] <LaserJock> it's off screen
[02:07] <joejaxx> the crazy thing is
[02:07] <joejaxx> compiz runs on that
[02:07] <joejaxx> LOL
[02:07] <somerville32> Hit alt and click it and drag?
[02:07] <LaserJock> imbrandon: oli had them running compiz via LTSP in 1 day at Sevilla
[02:07] <LaserJock> joejaxx: yeah, it works fine
[02:08] <joejaxx> LaserJock: that is crazy :P
[02:08] <imbrandon> joejaxx, is KDrive in xorg tree or only xserver tree ?
[02:08] <LaserJock> somerville32: doesn't work
[02:08] <LaserJock> joejaxx: why?
[02:08] <imbrandon> LaserJock, hahaha rockin
[02:08] <LaserJock> it's just a fairly normal laptop, except it doesn't have a hard drive
[02:08] <Fujitsu> How much flash does it have?
[02:09] <LaserJock> 256MB RAM and 2GB drive
[02:09] <LaserJock> and an SD slot
[02:09] <Fujitsu> Ah.
[02:09] <LaserJock> there's no swap
[02:09] <Fujitsu> What does it have in the way of connectivity?
[02:09] <LaserJock> which really makes XP bite on 256MB of RAM
[02:09] <LaserJock> Fujitsu: ralink wireless
[02:10] <pwnguin> psh
[02:10] <LaserJock> and an ethernet port
[02:10] <pwnguin> i can run linux on a nintendo ds
[02:10] <imbrandon> i can on my ipod too that dosent mean its useable as a lappy ;)
[02:10] <somerville32> You can run linux on a DS?
[02:10] <LaserJock> the specs are no problem for linux
[02:11] <LaserJock> it's things like not having a hard drive
[02:11] <pwnguin> somerville32: yes. dslinux.org
[02:11] <pwnguin> #dslinux on freenode
[02:11] <joejaxx> imbrandon: xserver
[02:11] <persia> pwnguin: What do you use as a keyboard for the DS?  Do both screens work as a single display, or are they considered dual?
[02:11] <imbrandon> ugh and we dont even build xserver on debian/ubuntu yet do we
[02:11] <pwnguin> the bottom screen is a touchpad
[02:11] <joejaxx> imbrandon: i think we do partially for Xephyr
[02:11] <pwnguin> they hacked together a touchscreen driver and on screen keyboard display
[02:12] <persia> LaserJock: No hard drive isn't that bad, as long as you have > 256MB Flash.  It's just slow (I have a 64MB RAM 128MB Flash laptop laying around somewhere)
[02:12] <LaserJock> persia: well yes, but there's a lot of work to get everything to work right
[02:12] <persia> pwnguin: Cool.
[02:13] <persia> LaserJock: Especially starting from the fairly massive Ubuntu base :)
[02:13] <LaserJock> yes
[02:13] <pwnguin> persia: fairly. if i had a different cart i could probably ssh with it
[02:13] <LaserJock> we stuck Edubuntu on it
[02:13] <joejaxx> imbrandon: http://packages.ubuntu.com/gutsy/x11/xserver-xephyr
[02:13] <LaserJock> so we had OO.o, Firefox, compiz, etc.
[02:13] <LaserJock> but we're gonna have adjust some things
[02:14]  * persia imagines the OOM being less then entirely pleased
[02:14] <LaserJock> OO.o takes *forever* to load
[02:14] <LaserJock> but MS Office starts fine
[02:14]  * ogra looks up (slightly drunk)
[02:14] <LaserJock> seemed kinda weird
[02:14] <Fujitsu> LaserJock: Why would you run OOo on there? That's just silly.
[02:14] <LaserJock> ogra: go back to bed/drinking
[02:14] <LaserJock> Fujitsu: because it's there and you need office software
[02:15] <imbrandon> google docs ftw
[02:15] <LaserJock> it works pretty ok
[02:15] <Fujitsu> LaserJock: Right, but it runs badly on anything.
[02:15] <LaserJock> nah
[02:15] <Fujitsu> I wonder how Abiword/Gnumeric would go.
[02:15] <LaserJock> well, that's the next step ;-)
[02:15] <LaserJock> and perhaps ditching Firefox
[02:15] <LaserJock> ogra: imbrandon wants a couple CMPCs :-)
[02:16] <imbrandon> joejaxx, hrm that seems to be part of xorg-server package
[02:16] <Fujitsu> LaserJock: That sounds good.
[02:16] <LaserJock> Fujitsu: first step is to get a working OS on there ;-)
[02:16] <imbrandon> ogra, how can i convince canonical i need to help with the CMPC's :P
[02:17] <LaserJock> imbrandon: go get a couple of the $200 walmart computers ;-)
[02:17] <joejaxx> LaserJock: their site is down
[02:17] <joejaxx> lol
[02:17] <imbrandon> LaserJock, i have one on order :)
[02:17] <joejaxx> thinkgos.something that is
[02:17] <LaserJock> why oh why?!?
[02:18] <joejaxx> i have no idea
[02:18] <joejaxx> but i have the iso mirrored
[02:18] <LaserJock> I don't think I'd waste a penny on that stuff
[02:18] <imbrandon> LaserJock, i already have a few C7 based systems, i really like VIA Proc's
[02:18] <joejaxx> a via 1.5 with 2gb is not bad
[02:19] <imbrandon> imbrandon.com runs off a 1.5ghz C7 with 512 MB ram :)
[02:19] <imbrandon> http://www.imbrandon.com/phpsysinfo/
[02:20] <imbrandon> ( Could use a bit more ram for it though )
[02:20]  * LaserJock wanders away to drool over some macs
[02:20] <imbrandon> heh
[02:21] <davidam> hi!
[02:21] <somerville32> Hi! :)
[02:21] <davidam> I'm writing my first debian package and I've a question:
[02:22] <davidam> what copyright must I write in the copyright debian/copyright?
[02:22] <davidam> the package copyright or the software to be packaged copyright?
[02:22] <somerville32> The copyright for the software you are packaging as well as the copyright for the package.
[02:22] <LaserJock> davidam: both is good
[02:22] <davidam> mmm
[02:23] <davidam> but I don't understand how
[02:23] <minghua> davidam: You must have the package's copyright there.  It's strongly encouraged to have the debian packaging's copyright there, too.
[02:24] <davidam> for instance in lua-mode
[02:24] <davidam> apt-get source lua-mode
[02:24] <davidam>  cd lua-mode-20061208/debian/
[02:25] <davidam> more copyright
[02:26] <davidam> I can see that it's licensed under gpl, but I'm not sure if we're speaking about the package or about the software
[02:27] <somerville32> Both
[02:28] <davidam> can you show me some example where there are one license to the software and another one to the package?
[02:28] <somerville32> Sure thing.
[02:28] <somerville32> Check out PyNeighborhood
[02:28] <somerville32> or Catfish
[02:29] <davidam> ok, thank you very much :-)
[02:30] <somerville32> No problem.
[02:32] <_16aR_> Hello
[02:32] <_16aR_> herm ... back
[02:32] <_16aR_> I've got a library which can be splitted into 5 parts
[02:32] <minghua> There is always http://wiki.debian.org/Proposals/CopyrightFormat in case of uncertainty.
[02:32] <_16aR_> but each parts use a shared header file...
[02:33] <_16aR_> if I put this header in each package, they will conflicts
[02:33] <_16aR_> and if I let it, it won't work ...
[02:34] <_16aR_> I've thought about creating 1 package for this file, and make each "independant" package depends on this one
[02:34] <_16aR_> does it seem correct ?
[02:35] <minghua> _16aR_: How exactly "won't work"?
[02:36] <_16aR_> compilation with the -dev package will fail
[02:36] <davidam> minghua: thanks :)
[02:36] <_16aR_> since the header will be missing
[02:36] <davidam> _16aR_: hello
[02:36] <_16aR_> hello davidam
[02:37] <_16aR_> minghua: if I put all in 1 package, the issue is solved ... But we lose the versatility
[02:38] <_16aR_> minghua: did you understand my problem ? Or weren't I clear ? I may have explained it bad
[02:43] <minghua> _16aR_: Well, you can always put the header in a separate package.  I also don't see it a big versatility loss if all -dev files are put into one package.
[02:44] <_16aR_> it is since it must depends on all non -dev package
[02:44] <_16aR_> so you have to get the whole library instead of little part of it
[02:45] <minghua> Depends on how large the individual packges are, I think.
[02:46] <_16aR_> I think they shouldn't be large
[02:47] <_16aR_> less than 400 k each .so
[02:47] <minghua> Then again, my words doesn't really mean anything.  You should ask the MOTU who is mentoring you, or an archive admin (if you already have a concrete package).
[02:48] <_16aR_> I don't have any MOTU mentoring me at the moment
[02:49] <imbrandon> hrm joejaxx i think i have a patch almost ready to make Xvesa ( KDrive ) build and install , you said you had permission to do it?
[02:49] <imbrandon> from who ?
[02:49] <joejaxx> i do not remember i would have to grep logs
[02:49] <joejaxx> this was a while ago
[02:49] <joejaxx> beginning of gutsy
[02:50] <imbrandon> joejaxx, cool ok, well its just some trivial changes to the xserver-xorg package as it already builds KDrive servers, all i need to do is make the .install and .manpage files
[02:50] <persia> _16aR_: The basic rule of thumb is to try to avoid too many binary packages whilst not depending on lots of libraries users don't need.  If you have separate -kde and -gnome versions, these should be split.  If the libraries are small, and don't have a lot of dependencies, splitting isn't so important.
[02:50] <imbrandon> no idea why we dident just have them before now
[02:50] <joejaxx> imbrandon: oh ok
[02:51] <_16aR_> persia: all right
[02:51] <imbrandon> joejaxx, i'm testing now, if it works i'll make a patch and upload to a PPA
[02:51] <imbrandon> and start poking some X people
[02:51] <joejaxx> ok
[02:51] <_16aR_> damnit I was getting headache on how to manage them
[02:51] <_16aR_> because lots of .install .dirs .links etc are really a pain in the neck to manage
[02:52] <_16aR_> rm -rf * ^^
[02:52] <minghua> It's only natural to have headaches if you choose a library as your first package. :-P
[02:52] <_16aR_> minghua: that's my 5th package
[02:52] <_16aR_> 5th library
[02:52] <_16aR_> my head gonna explode :p
[02:52] <joejaxx> imbrandon: hopefully it does not build in a whole bunch of depends
[02:53] <_16aR_> Just kidding, it was a lot of work, but I've learned a lot. That's fair :D
[02:53] <persia> _16aR_: When working with libraries and annoying package splits, I tend to find it easiest to do a little each day: when I get too annoyed, I do something else for a while, and come back to it.
[02:53] <imbrandon> joejaxx, it dosent , Xeyphr already uses all the same depends, hell it even has --enable-kdrive already in the config
[02:54] <imbrandon> just no .install file for it
[02:54] <_16aR_> persia: that's what I'm doing ... I've begun packagaging delta3D for 6 month now
[02:54] <_16aR_> juste before feisty
[02:54] <persia> _16aR_: Aha.  Well, in that case you'll want to just keep at it.  Thanks for your patience.
[02:54] <joejaxx> imbrandon: ok
[02:54] <_16aR_> (and since delta3d has a bunch of deps unmet in ubuntu, I had to package it myself ^^)
[02:54] <joejaxx> well that is disappointing
[02:55] <joejaxx> lol
[02:55] <joejaxx> i thought that would be the package that would have gotten me into motu
[02:55] <joejaxx> lol
[02:55] <joejaxx> oh fun pbuilder-dist creates the folders locally that is great
[02:55] <imbrandon> joejaxx, hehe
[02:56] <_16aR_> hopefully, lots of bugs from deps already in previous ubuntu version have been corrected. But I did the job nonetheless until the bugs were fixed :p
[02:58] <joejaxx> imbrandon: care to look at a merge i did?
[02:58] <joejaxx> imbrandon: https://people.fluxbuntu.org/~joejaxx/ubuntu/merges/flwm_1.02-2ubuntu1.MERGE.debdiff
[02:59] <imbrandon> joejaxx, sure give me a moment
[02:59] <joejaxx> ok
[03:00] <minghua> I would like another MOTU's opinion to make sure I've rejected bug #159871 correctly.
[03:00] <ubotu> Launchpad bug 159871 in gdal "libgdal.so symlink is missing" [Undecided,Invalid] https://launchpad.net/bugs/159871
[03:02] <persia> minghua: I tend to investigate a bit more.  Sometimes the -dev symlink is missing because someone forgot to add it.  "There must be a reason" doesn't explain much.
[03:04] <minghua> persia: I made sure /usr/lib/libgdal1.4.0.so file exists (I assume that's a correct symlink).  Feel free to change it back to new.
[03:04] <persia> minghua: Right.  Now I have to investigate the libgdal changelogs.  Are you sure you don't want to do it?
[03:05] <minghua> persia: No I don't.  I tend not to touch too much the packages I don't use.
[03:05] <minghua> I only did it because it's a MOTU science package and I got the bugmail.
[03:05] <persia> minghua: OK.  It's just that without the investigation, the bug comment isn't useful, and _16aR_could use a fix if it is indeed wrong.
[03:05] <minghua> (and I know MOTU science lacks manpower in bug triaging)
[03:06]  * Fujitsu apologises for not having much time for working on that lately.
[03:07] <minghua> persia: Oh so that's _16aR_'s report.  My understanding is he can't use -lgdal to link, I believe that's not gdal's problem and said so.
[03:07] <persia> No, it's a real bug: "Moved to libgdal1-dev package, which allows rebuilds of dependent packages without source changes. It is currently superfluous changing the -dev package at every new release because we do not support many different versions of the gdal lib."
[03:07] <persia> (from 1.4.0-1)
[03:08] <_16aR_> minghua: yes, that's exactly the problem, delta3d used -lgdal to link, and it was missing. That's why I thought it could be a bug
[03:08] <minghua> persia: You mean the file should be named as /usr/lib/libgdal.so.1 and /usr/lib/libgdal.so instead?  What is the current SONAME?
[03:08] <persia> _16aR_: That's a fairly simple issue.  Where's the patch?
[03:08] <Fujitsu> O_o
[03:08] <Fujitsu> configure: error: "" flavoured geckos aren't tasty enough!
[03:09] <Fujitsu> Thanks Epiphany.
[03:09] <persia> heh
[03:09] <imbrandon> lpia arch on PPA's ?
[03:09] <minghua> Fujitsu: Go get some spice. :-P
[03:09] <imbrandon> when did we get those ?
[03:09] <Fujitsu> imbrandon: A couple of days ago when another 7 buildds appeared.
[03:09] <LaserJock> yesterday or the day before
[03:09] <imbrandon> nice
[03:10] <LaserJock> lamont got them fixed up
[03:10] <Fujitsu> Have they caught up yet?
[03:10] <imbrandon> Fujitsu, i dont think so
[03:10] <minghua> _16aR_: I understood what you said.  I am still not convinced by persia that there is a problem.
[03:10] <imbrandon> what is a lpia ( i know what the acronim stands for ) but i mean in real world
[03:10] <imbrandon> phones? cmpc ?
[03:10] <joejaxx> samsun q1?
[03:11] <joejaxx> samsung*
[03:11] <_16aR_> minghua: I'm not sure either
[03:11] <persia> minghua: There is an unversioned -dev library that doesn't support unversioned linking.  How is this not a problem?
[03:11] <Fujitsu> imbrandon: It's -mobile. Internet tablets and the like, I presume.
[03:11] <LaserJock> imbrandon: cmpc uses i386
[03:11] <imbrandon> now if we could just have ppc buildd's
[03:11] <joejaxx> yeah it is ubuntu-mobile
[03:11] <imbrandon> LaserJock, lpia is x86 iirc , just low power
[03:12] <persia> imbrandon: It's an artificial architecture for when you care lots about power and space.  In the future, it may be a branched architecture with better power calls, etc. (like ARM already has)
[03:12] <Fujitsu> imbrandon: Xen doesn't work properly on powerpc at the moment :(
[03:12] <LaserJock> yeah, I'm still a bit confused
[03:12] <imbrandon> low power intel arch
[03:12] <joejaxx> imbrandon: does not canonical have POWER5 buildd's?
[03:12] <minghua> persia: If it uses pkg-config (which it doesn't seem to do), I don't see what the problem is.
[03:12] <imbrandon> Fujitsu, but OpenVZ does and would probably work better than xen imho
[03:12] <LaserJock> there's mobile chips and then mobile mobile
[03:12] <persia> minghua: If it used pkg-config, I'd be more inclined to agree with you.
[03:13] <minghua> persia: You can run "pkg-config --libs gdal", and it gives you -lgdal1.4.0 (or whatever the version will be), it works fine.
[03:13] <_16aR_> how can I leave a pbuilder session without saving changes ?
[03:13] <imbrandon> exit
[03:13] <_16aR_> (I'm logged in my pbuilder session to test gdal package, but I don't want to keep it installed)
[03:13] <imbrandon> pbuilder by default dosent save it
[03:14] <imbrandon> you have to pass --save-after-login for it to save
[03:14] <_16aR_> all right
[03:14] <_16aR_> Thanks
[03:14] <imbrandon> when you run pbuilder login
[03:14] <minghua> persia: Well, it does use gdal-config (or at least ship it in libgdal-dev), so I'm still not convinced.
[03:14] <persia> minghua: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id249952 only says "should", but still...
[03:15] <minghua> Not everybody agrees with dancer's library packaging guide anyway...
[03:15] <imbrandon> wow a whole 58 karma on LP, you can tell i use it alot
[03:15] <LaserJock> heh
[03:16] <LaserJock> I've even got more than that!
[03:16] <_16aR_> minghua:  SONAME      libgdal1.4.0.so.1
[03:16] <persia> minghua: True.
[03:16] <imbrandon> heh i think i have the lowest of the MOTU / core-devs thats a non-zero number
[03:16] <imbrandon> LaserJock, ^
[03:16]  * persia likes the karma-benefits of changelog-closes-bugs
[03:16] <_16aR_> Is there another library packaging guide ?
[03:17] <bddebian> _16aR_: Hey, persia is telling me you are working on delta3d?
[03:17] <_16aR_> bddebian: yes, right
[03:17] <minghua> _16aR_: Thanks.  Then I'm quite firmly in the position that the current package gets it right.
[03:17] <_16aR_> minghua: yes, I should change -lgdal with gdal-config
[03:17] <minghua> _16aR_: You are supposed to use gdal-config, not hard-coding -lgdal.
[03:17] <_16aR_> is there any .pc for pkg-config ?
[03:17] <minghua> _16aR_: Exactly.
[03:18] <_16aR_> bddebian: don't say you're working on it too ? :p
[03:18] <bddebian> _16aR_: Nope but I'm on the Debian Games Team and thought it looked like a cool game
[03:19] <_16aR_> cool game, I don't know, cool game engine, yes, it seems :D
[03:19] <bddebian> Well aye
[03:19] <persia> _16aR_: More since you said you'd been working on it for >6 months, and didn't have a mentor, I asked for volunteers to help with the package.
[03:20] <_16aR_> All right
[03:20] <imbrandon> yea LaserJock: Architecture: Intel x86 Low Power lpia , so it is x86
[03:20] <_16aR_> for the moment, I have a _big_ problem
[03:20] <bddebian> Which is?
[03:21] <LaserJock> imbrandon: well, I have no idea what chips count, but whatever
[03:21] <imbrandon> yea me eihter, via's and intel's M line? dunno
[03:21] <imbrandon> not sure what would make them diffrent than normal x86's really
[03:21] <persia> LaserJock: I'm fairly certain that if I pulled my Stylistic (486DX) out of the closet, lpia would be the right architecture for installtion.
[03:21] <_16aR_> copyright issue
[03:22] <_16aR_> and no answer from upstream
[03:22] <bddebian> Ah, that's always bad
[03:22] <imbrandon> persia, hehe
[03:22] <LaserJock> persia: so would it work for any x86 proc?
[03:22] <_16aR_> no license/copyright file
[03:23] <persia> LaserJock: From what little I've looked at it (I use ARM for -mobile currently), it ought.
[03:23] <_16aR_> and that's 1 of the deepest dependency ....
[03:23] <imbrandon> if thats the case then whats the diffrence software side that it needs seperate buildd's
[03:23] <LaserJock> interesting
[03:23] <persia> _16aR_: Theres copyright.txt, that mentions a license, or do you mean the missing LPGL.txt?
[03:23] <_16aR_> no
[03:23] <_16aR_> no copyright.txt
[03:23] <persia> imbrandon: HInts and tricks to save space, and optimize differently.  Power is critical in a -mobile setting.
[03:24] <_16aR_> but I'm checking if every source file contains GPL header
[03:24] <Fujitsu> imbrandon: They have different chroots, and there's no facility for building multiple dpkg archs on one set of buildds at the moment.
[03:24] <imbrandon> Fujitsu, i ment more of a "if a phone has a x86 proc , why not use a normal x86 package"
[03:25] <Fujitsu> Ah.
[03:25] <LaserJock> but why wouldn't you just have a different kernel I think is the question
[03:25] <_16aR_> 3 .c files are missing the gpl header
[03:26] <persia> LaserJock: Different gcc optimization preferences
[03:26] <somerville32> LaserJock, Can you take a look at https://bugs.edge.launchpad.net/ubuntu/+source/screem/+bug/33594 ?
[03:26] <ubotu> Launchpad bug 33594 in screem ".desktop cleanup" [Wishlist,Confirmed]
[03:26] <LaserJock> persia: ahhh
[03:26]  * persia encourages people to type bug numbers rather than pasting edge URLs
[03:27] <minghua> persia: Do you want me to state my opinion in that gdal bug, or you've heard it and is going to take care of it?
[03:27] <imbrandon> persia, would just be better if edge was smart enough to redirect non beta testers to the normal page
[03:28] <persia> imbrandon: The "solution" was to give everyone public access by URL.
[03:28] <persia> (one just can't log into the wrong system)
[03:28] <LaserJock> somerville32: k, looks reasonable
[03:28] <imbrandon> lol classic
[03:28] <somerville32> LaserJock, I'm just doing bug cleanup. You're a U-M-S, aren't you?
[03:29] <LaserJock> yeah
[03:29] <LaserJock> although screem works fine right now
[03:29]  * imbrandon hides again
[03:29] <LaserJock> so it's pretty wishlist
[03:29] <Fujitsu> persia: edge has always been public.
[03:29] <Fujitsu> Only beta was ever restricted.
[03:29] <somerville32> LaserJock, So you're not willing to sponsor? :P
[03:30] <_16aR_> minghua: by the way ... Who must create .pc file for pkg-config if any ?
[03:30] <_16aR_> is it packager ? upstream ?
[03:30] <LaserJock> somerville32: well, if there's some other stuff to do
[03:30] <minghua> _16aR_: Usually upstream.
[03:30] <LaserJock> somerville32: but I don't know if it's worth an upload by itself
[03:30] <_16aR_> minghua: all right, otherwise I could have added them
[03:31] <somerville32> LaserJock, Someone went out of their way to provide that patch though :P
[03:31] <persia> Fujitsu: Not true. Initially, I couldn't see edge either.
[03:31] <somerville32> Persia infact
[03:31] <_16aR_> but I don't if I must create a dependency to pkg-config then, or the way how to do it
[03:31] <Fujitsu> persia: When was this?
[03:31] <persia> somerville32: Which patch?  If it's only a patch, it's likely crufilty old.
[03:31] <persia> Fujitsu: Months back
[03:32] <LaserJock> somerville32: it should still be done, but we should pool fixes if we can
[03:32] <Fujitsu> I was able to access it long before I was in launchpad-beta-testers, though I was one of the first people to be in it... so I guess they must have restricted it afterwards.
[03:32] <imbrandon> dont we have an X team / irc channel ?
[03:32] <LaserJock> man I hate all these stinkin' crash bugs
[03:32]  * Fujitsu points at #ubuntu-x
[03:32] <Fujitsu> LaserJock: They're better than not knowing about any crashes.
[03:32] <LaserJock> no wonder we're waay behind
[03:33] <LaserJock> Fujitsu: barely
[03:33] <LaserJock> I've got probably 20-30 crash bugs I have no idea what to do with
[03:33] <Fujitsu> And they mean we often don't have to ask for the backtrace.
[03:33] <persia> somerville32: Ignore the patch.  desktop-file-validate has been completely rewritten since then.  It needs a new patch, and really belongs upstream.
[03:34] <persia> LaserJock: Point me at one: I feel like a stacktrace
[03:34] <LaserJock> for screem 14 out of 19 bugs are crashes
[03:34]  * persia picks one
[03:34] <LaserJock> most probably with 0 triage done
[03:35] <LaserJock> I often times fail to see th point of filing bugs that nobody's gonna look at
[03:35] <LaserJock> it's just more mess
[03:36] <Fujitsu> I've fixed a few crashers, but most of my bug work just ends up being consolidation of dupes and the like.
[03:36] <persia> LaserJock: Depends on the package.  I watch about 10, and generally fix all the apport bugs within a month or two (at least for the packages where I understand the code).  There's no way to know from outside if it will be looked at.
[03:36] <imbrandon> man i dont use gentoo for one reason, i dont wanna compile everything , but then what do i do? i become a ubuntu-developer
[03:36]  * imbrandon sighs
[03:37] <Fujitsu> imbrandon: Hahah.
[03:37] <LaserJock> imbrandon: exactly
[03:37] <LaserJock> I did the same thing
[03:37] <imbrandon> :)
[03:37]  * persia points out that you only have to compile 1% of everything as an Ubuntu developer
[03:37] <LaserJock> persia: good for you
[03:38] <LaserJock> I've never had a crasher fixed
[03:38] <imbrandon> persia, true, but lately i've been picking on large packages like kde*, linux-kernel , X , etc hehe
[03:38] <LaserJock> they just sit around for a few releases
[03:38] <StevenK> LaserJock: Then talk to upstream and bug people
[03:39] <persia> LaserJock: Really?  Then I'll ignore the screem crashers for now: give me one of yours.
[03:39] <_16aR_> minghua: If you know how to use gdal-config with scons , I would be glad :p
[03:39] <LaserJock> persia: screem's good
[03:39] <LaserJock> we ship it in Edubuntu
[03:39] <persia> LaserJock: But I'm seeking to change your personal user experience, not hack Edubuntu :)
[03:40] <imbrandon> persia, he hacks on enubuntu :)
[03:40] <LaserJock> well, I'm just kinda depressed when it comes to bugs in Edubuntu
[03:40] <_16aR_> minghua: it seems every libname is in a array, and each item of the array gets a -l prefix at compile time. So if I just add `gdal-config --CXX-FLAGS` it shouldn't get cool
[03:40] <Fujitsu> LaserJock: If you implement the spec about teaching students how to code, all your problems are solved :P
[03:41] <imbrandon> hehe
[03:41] <LaserJock> Fujitsu: heh
[03:42] <minghua> _16aR_: I know neither gdal or scons, so sorry.
[03:42] <LaserJock> it seems like all I can do is paperwork (find dups, "are you still having this problem?", close invalids)
[03:42] <minghua> persia: My comment added to bug 159871, I'll leave the decision to you.
[03:42] <ubotu> Launchpad bug 159871 in gdal "libgdal.so symlink is missing" [Undecided,Confirmed] https://launchpad.net/bugs/159871
[03:42] <LaserJock> now that I think of it I don't know that I've ever actually fixed a real code bug
[03:42] <LaserJock> or had one turn out
[03:43] <LaserJock> that stinks :(
[03:43] <pwnguin> heh
[03:43] <pwnguin> i can find you several real code bugs if you want to fix one
[03:43] <LaserJock> oh, I know they're out there
[03:43] <imbrandon> pwnguin, thanks for pointing me to xeyphr (sp?) ended up being just what i needed for the solution
[03:44] <persia> minghua: Nah.  Take the decision.  I'm not invested in libgdal, and your last comment includes all the explanation and references to research one might want.
[03:44] <LaserJock> I've just never seen bugs work out all that well
[03:44] <pwnguin> imbrandon: np. i tried using it to test the ubuntu mobile stuff
[03:44] <persia> LaserJock: I can show you some examples if you like.  Most of my good ones are in torcs or hydrogen.
[03:44] <pwnguin> they seem a bit befuddled at the moment
[03:45] <LaserJock> persia: you looking at screem now?
[03:45] <pwnguin> any idea what -$(MAKE) clean would need the - for?
[03:45] <persia> LaserJock: Yep.  bug #128903 to be rprecise
[03:45] <ubotu> Bug 128903 on http://launchpad.net/bugs/128903 is private
[03:45] <pwnguin> its in the default dh_make debian/rules
[03:45] <StevenK> pwnguin: It may fail
[03:45] <persia> pwnguin: Because the packager was too lazy to find out why make was failing, or used dh_make
[03:46]  * pwnguin is the packager
[03:46] <LaserJock> "I clicked on something in preferences
[03:46] <minghua> persia: No way. :-)  I've changed the status once, you changed it back to confirmed.  I'm not touching it again.
[03:46] <LaserJock> oh so handy
[03:46] <persia> pwnguin: If you know make clean always succeeds, drop the "-".  If you know if may fail, trap on the failure condition.
[03:47] <persia> LaserJock: What the user says isn't important.  The apport data is useful.
[03:47] <minghua> pwnguin: Most of the time, it's for a clean build when no Makefile exists.
[03:47]  * pwnguin is having to write his own makefiles for this package
[03:48] <persia> minghua: OK.  It's just you should get the karma credit for the research.  I'll go adjust on your behalf...
[03:48] <LaserJock> persia: StacktraceSource.txt ?
[03:48] <minghua> Karma is overrated.  Thanks persia.
[03:48] <persia> LaserJock: That's where I start.  Do you want to do this one together, and maybe you can hit the next one?
[03:48] <LaserJock> persia: yeah
[03:49] <persia> Channel Members: Any opinions on use tracking a stacktrace in-channel?  We can also go somewhere else.
[03:50]  * Fujitsu thinks it's fine.
[03:50] <Fujitsu> Probably educational for most.
[03:50]  * somerville32 nods.
[03:50] <persia> Fujitsu: Thanks.
[03:50]  * persia checks to make it public to increase value
[03:52] <persia> OK.  We're looking at bug #128903.  Screem crashed when the user was doing something with preferences, and we're going to find out why, and fix it.
[03:52] <ubotu> Launchpad bug 128903 in screem "screem crashed with SIGSEGV" [Medium,New] https://launchpad.net/bugs/128903
[03:52] <persia> First, we grab the source code for screem in a local scratch directory, as we'll be looking through the source to understand what the programmer thought they were doing when the bug was created.
[03:53] <jdong> would it be horribly wrong to fork Azureus?
[03:53] <persia> Then, we'll start with the Stacktrace.txt to make some guesses as to what might be happening.
[03:53] <LaserJock> persia: with you
[03:54] <LaserJock> jdong: why would you do that? :)
[03:54] <Fujitsu> jdong: I don't think so.
[03:54] <Fujitsu> Probably better to rewrite it in something sane, however.
[03:54] <persia> OK.  I usually start around #3 or #4 in the stacktrace to get some context.  Sometimes one needs to go deeper, and sometimes it's more obvious.
[03:54] <imbrandon> c#
[03:55] <jdong> LaserJock / Fujitsu: I'm extremely unhappy with this Vuze videostore crap that is fused into the Azureus 3.0.3.4 GUI
[03:55] <LaserJock> ok, wait
[03:55] <LaserJock> which direction does it go
[03:55] <Fujitsu> jdong: Ahh.
[03:55] <jdong> IMO it's crap that is not needed in a torrent client
[03:55]  * Fujitsu strangles imbrandon 
[03:55] <LaserJock> it's opposite of python right?
[03:55] <jdong> I don't want my torrent client hiding the torrent interface from me to show a youtube clone.
[03:55] <Fujitsu> LaserJock: Frame 0 is the latest.
[03:55] <LaserJock> k
[03:55] <persia> LaserJock: #0 is the function at the point of the crash.  #N moves back to prgram start with increasing N
[03:55] <imbrandon> jdong, yea az 3.X is EVIL
[03:56] <jdong> I am thinking about ripping the 3.0.3.4 downloader core and putting it on the 2.5.0.4 UI
[03:56] <jdong> or otherwise neutering the Vuze video store thing
[03:56] <Fujitsu> Aha.
[03:56] <persia> So, #3 and #4 seem to indicate that we're trying to draw or refresh a page, based on the function names.
[03:56]  * minghua agrees the Vuze UI is rather useless (at least under Linux).
[03:56] <somerville32> Shhh! O
[03:57] <persia> #2 appears more specifically to be related to a link of some type, #1 to some remote connection, and #0 to a copy from the remote site (again, just based on function names)
[03:57] <jdong> I'm not sure if Az is trademarked or something
[03:57] <LaserJock> persia: do you know how #4 and #3 are related, etc.?
[03:58] <jdong> but IMO Azureus is a very nice and powerful torrent client that works GREAT when packaged correctly and run under a working Java stack....
[03:58] <persia> LaserJock: No idea at all at this point: I've never seen this code (I suggested patching a .desktop file once)
[03:58] <jdong> it's a shame upstream decided to commercialize it with a gimmick.
[03:58] <LaserJock> persia: right, I just wondered if you could tell from the trace
[03:59] <LaserJock> I mean the basic idea is #0 fails so #1 fails ... right?
[03:59] <StevenK> LaserJock: Not usually
[03:59] <LaserJock> ok fine :p
[03:59] <persia> LaserJock: Well, you can make some guesses based on the function names, and the arguments.  I'd suggest that #4 was probably trying to draw a GTK Window, and #3 was filling a panel in that window, but that's conjecture.
[03:59] <StevenK> LaserJock: It could be a bug in #1 calling the wrong function, but is usually a bug in #0
[04:00] <LaserJock> but the different "frames" are related right
[04:00] <persia> LaserJock: When #0 is in the target code, it's almost always #0.  When #0 is in libc or libgtk, etc. it's often easier to add an exception handler at #7 (or whatever) to not expose the condition.
[04:00] <StevenK> Right. When you call a function, you push onto the stack, creating another frame
[04:01] <LaserJock> k, I think I'm with you
[04:01] <StevenK> When you leave that function, you pop off the top of the stack, returning to the new top of the stack
[04:01] <LaserJock> ah, right
[04:01] <StevenK> persia: Feel free to correct me if I'm being dumb. :-)
[04:02] <StevenK> LaserJock: Then there is the heap, but I won't get into that
[04:02] <LaserJock> ok, so it looks like this has to do with the site publishing feature
[04:02] <persia> StevenK: Dumb?  You?  Contradiction.  I tend to use an onion-style explanation, but I'm not used to training qualified technical staff
[04:03] <Hobbsee> StevenK: besides, you're a canonical employee now.  you're supposed to be perfect, and we all bask in your greatness.
[04:03] <Hobbsee> or something like that.
[04:03] <persia> LaserJock: It looks that way, probably related to the FTP error handler: many upstreams expect the network connections to just work, and don't bother to check if it is failing.
[04:03] <somerville32> [01:00] <ubotu> New bug: #128903 in screem (main) "screem crashed with SIGSEGV" [Medium,New] https://launchpad.net/bugs/128903
[04:03] <ubotu> Launchpad bug 128903 in screem "screem crashed with SIGSEGV" [Medium,New]
[04:03] <StevenK> persia: It's a stack, and I daresay LaserJock is well versed in LIFO or FILO.
[04:03] <Fujitsu> Hobbsee: Only supposed to be?
[04:03] <Hobbsee> Fujitsu: granted.
[04:03] <StevenK> Hobbsee: Ah ha. Okay
[04:03] <persia> StevenK: All true.  Your explanantion is more than welcome :)
[04:04] <LaserJock> StevenK: you're an employee?
[04:04] <StevenK> LaserJock: Right.
[04:04] <LaserJock> doing what?
[04:04] <Hobbsee> LaserJock: he's joined the Evil Canonical Empire (tm), yes.
[04:04] <persia> StevenK: And you didn't even have to change your nick :)
[04:04] <Fujitsu> persia: Hahah.
[04:04] <LaserJock> lol
[04:04] <somerville32> I don't see how bug 128903 is new.
[04:04] <ubotu> Launchpad bug 128903 in screem "screem crashed with SIGSEGV" [Medium,New] https://launchpad.net/bugs/128903
[04:04] <somerville32> Is ubotu acting up again?
[04:05] <StevenK> LaserJock: Also, one thing to keep in mind is that if a function does something *really* bad, it can smash the stack, making the backtrace complete garbage.
[04:05] <persia> somerville32: maybe because lots of people are poking it?
[04:05] <LaserJock> StevenK: ouch
[04:05] <somerville32> StevenK, What do you do in that case?
[04:05] <persia> Apport usually gives up in those cases, so one doesn't have the nice traces anyway.
[04:05] <StevenK> LaserJock: And with SEGV bugs, it could be pointer corruption or using a pointer wrongly, or worse case, heap corruption.
[04:05] <Fujitsu> If the backtrace shows null addresses it's definitely corrupt, right?
[04:06] <persia> somerville32: interactive gdb can help, if you can reproduce.  Otherwise it's just annoying.
[04:06] <StevenK> Fujitsu: Not necessarily
[04:06] <persia> Fujitsu: Or someone was passing null pointers
[04:06] <StevenK> Fujitsu: The code could just be trying to play with NULL pointers since it's dumb
[04:06] <StevenK> LaserJock: I started a month ago
[04:06] <imbrandon> StevenK, ahh so what does canonical have you doing ? heh
[04:07] <persia> So, let's assume this bug is a nice straightforward coding error, and proceed.  It could be very bad, but we won't know until we get a little deeper.
[04:07] <StevenK> steven@liquified:~% head -n 2 .canonical-signature | tail -n 1
[04:07] <StevenK> Ubuntu Mobile Developer
[04:07]  * somerville32 is excited.
[04:07] <LaserJock> StevenK: awesome
[04:07] <imbrandon> StevenK, rockin
[04:07] <StevenK> LaserJock, imbrandon: It's the reason I was at UDS.
[04:08] <imbrandon> :)
[04:09] <persia> So, I suggest we review screem-linkview.c:299 first, just to build some context of variable names, and what we're expecting to pass, etc.
[04:09] <LaserJock> StevenK: I wondered
[04:09] <StevenK> LaserJock: You were welcome to ask.
[04:10] <somerville32> Seveas, there is a bug with ubotu and bugs.
[04:10]  * Fujitsu wonders if we're meant to go around polling people about Canonical employment status.
[04:11] <persia> somerville32: No, it isn't a bug.  It just became unprivate recently, and ubotu just heard it existed.
[04:11] <Hobbsee> Fujitsu: fairly obvious, when they use canonical.com in their LP profile.
[04:11] <Fujitsu> somerville32: Why?
[04:11] <StevenK> ... Like I do.
[04:11] <Hobbsee> ubotu has many bugs.
[04:11] <ubotu> Sorry, I don't know anything about has many bugs. - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[04:11] <Fujitsu> StevenK: Only after I told you didn't have it there.
[04:11]  * persia hugs ubotu
[04:11] <StevenK> Fujitsu: Yeah, well
[04:11] <LaserJock> persia: ok, so what are you looking for?
[04:11] <somerville32> persia, Oh right.
[04:12] <somerville32> Why was it private?
[04:12]  * Hobbsee likes the !forget bug, in particular.
[04:12] <Fujitsu> somerville32: Crashes are by default private.
[04:12] <somerville32> !forget hobbsee
[04:12] <Hobbsee> somerville32: all the automatically reported crashes are private
[04:12] <somerville32> okay.
[04:12] <Fujitsu> The traces or coredumps may well contain private information.
[04:12] <Hobbsee> somerville32: you lose.  it has ACL.
[04:12] <StevenK> Such as passwords
[04:12] <Fujitsu> StevenK: Right.
[04:12] <somerville32> : (
[04:13] <Fujitsu> Or, even better, GnuPG crashes.
[04:13] <persia> LaserJock: We're just trying to get an understanding of what is happening.  screem_site_sync_status is being called with the site and &priv->upload_table.  I forget the syntax, but I believe that should be a pointer to some entitlement table or something.
[04:13] <somerville32> entitlement table?
[04:13] <persia> somerville32: place where privileges are stored
[04:13] <StevenK> somerville32: Think about you. You are stracing a pop3 daemon, and you get some data from the network, which could be auth info. Bang, you've just gotten someone's account information, and all you had to do was read a bug.
[04:14] <somerville32> StevenK, Tracking.
[04:14] <somerville32> persia, And this is screem specific implementation?
[04:14] <StevenK> Er. Think about it
[04:14] <persia> somerville32: There's a comment just beneath the call referring to screem-linkview-util.h for an explanation, which is our next stop.
[04:14] <joejaxx> imbrandon: did the merge look ok? :)
[04:15] <somerville32> persia, I suppose I should download the source code.
[04:15] <persia> somerville32: That might help to follow the bugfix :)
[04:15]  * somerville32 ducks.
[04:15] <imbrandon> joejaxx, X still building localy , i dident look yet
[04:15] <somerville32> How long does X take to build?
[04:16] <joejaxx> imbrandon: oh ok
[04:16] <joejaxx> somerville32: depends on your system :P
[04:16] <imbrandon> somerville32, when your on my machine a LONG time
[04:16] <persia> OK.  We should expect to see nicely named status conditions, and it looks like the author has put in at least some hooks, or we wouldn't see _BROKEN, etc.
[04:17] <persia> LaserJock: Good so far?
[04:17] <LaserJock> persia: kinda, I'm in the .h now
[04:18] <LaserJock> I see the statuses
[04:18] <persia> LaserJock: OK.  Ask anything you like: the goal here is to get a basic grasp of what we're expecting to screem_site_sync_status to do (very basic - just universal context)
[04:18] <somerville32> What file are we in?
[04:18] <persia> somerville32: screem-linkview.c:299
[04:20] <LaserJock> persia: so it's looking at the files of the server and seeing what needs to be synced
[04:20] <persia> LaserJock: Right.  That both matches my impression and is the correct level of detail to understand the problem at this point.
[04:20] <persia> Now we want to look at the uploadwizard more directly, so we'll move to #1 (uploadWizard.c:1300)
[04:21] <persia> (in the plugins directory)
[04:23] <persia> From here, we want to peruse the entire function, not just the point at #1.  We were called by screem_site_sync_status, so we are trying to build a full context of what this function is doing, and where we are.
[04:24]  * persia notes that the alias of screem_site_sync_status to screem_site_get_sync_status really isn't usually important in this type of situation.
[04:26] <persia> So, if we hit line 1300, we know 1) it's not a fake site and  2) there is an available directory for the site.  The function as a whole is indeed processing the site update as we previously conjectured from our investigation of #2.
[04:27] <somerville32> We're at frame #2 right now, right?
[04:27] <somerville32> er.. #1
[04:27] <persia> Also, we know that we're passing a ScreemSite and a gboolean to screem_site_to_sitecopy_site
[04:27] <LaserJock> persia: k, with you
[04:28] <persia> somerville32: #1, yes.
[04:29] <persia> We haven't encountered the ScreemSite definition, so let's take a detour to review that from include/screem-site.h
[04:30] <StevenK> persia: I'd like to sleep, but I want to see this discussion. Would you mind pasting/mailing the completed logs?
[04:31] <persia> StevenK: Sure, although I generally find irc.ubuntu.com fairly trustworthy.
[04:32] <somerville32> You need a username and password for it?
[04:32] <persia> Err.   http://irclogs.ubuntu.com/
[04:33] <Fujitsu> irc.u.c was working a couple of days ago.
[04:33] <Fujitsu> In the "It works!" default manner, though.
[04:33] <persia> Fujitsu: It's still doing that...
[04:34] <LaserJock> geser: geeze, did you get anything out of screem-site.h?
[04:34] <persia> So, back to our bug investigation: the typedef for ScreemSite starts on line 46, and we can see it's just a wrapper for ScreemSitePrivate (which is where the priv we saw in #2 likely comes from)
[04:35] <somerville32> Where is ScreemSitePrivate defined?
[04:36] <persia> somerville32: line 43
[04:36] <LaserJock> persia: ah right
[04:36] <somerville32> It doesn't look like anything.
[04:37] <persia> We also have the fairly messy workaround that is GObject, and so can guess that this is likely to be somewhat obfuscated for non-GNOME coders (like us)
[04:37] <somerville32> I'm new to C/C++. Can you explain line 43? I've never seen a struct with no body like that.
[04:38] <LaserJock> is that a constructor?
[04:38] <persia> Further in the page, there are a lot of function declarations, and I believe these are somewhat like C implementations of members, but my GObject knowledge is fuzzy.  Let's just keep this file open for reference as we move to #0, in case we wonder what something does.
[04:38] <persia> LaserJock: Umm.  Sort of a constructor.  C doesn't have objects.
[04:38] <LaserJock> oh right, sorry, was thinking C++
[04:38] <somerville32> Have we been working backwards?
[04:38] <persia> somerville32: It's a special sort of GObject thing: don't worry about it.
[04:39] <persia> somerville32: Yes.  That's always easiest for stacktraces.  First, get some context and familarity with the code, then find the bug, then patch it.
[04:39]  * somerville32 nods.
[04:39] <somerville32> So #0 is the crash
[04:39] <LaserJock> persia: so we're off to #0?
[04:40] <persia> LaserJock: Sure.  That's uploadWizard.c:307, so we don't even have to change files
[04:41] <persia> (I generally debug with two windows: one for .c and one for .h: it's not infrequent one has to go back and forth, especially when upstream doesn't have good naming conventions.  screem is fairly nice to debug.
[04:41] <somerville32> I'm using tabs
[04:41] <LaserJock> I"m trying to figure out vim ;-)
[04:42] <somerville32> Have you tried the tutorial?
[04:42] <LaserJock> persia: ok, so it's checking for a ~<username> URL?
[04:42] <persia> So, in a similar way to going from #2 to #1, we want to look at the entire function, as this is where the bug lies, and we really want to know what we're doing when we hit it.  Let's start from 211, and walk through slowly
[04:42] <persia> LaserJock: maybe.  I think you're ahead of me :)
[04:42] <LaserJock> somerville32: well, I know the basics, it's just moving around fast. I've got my cheet sheet next to me
[04:42] <somerville32> persia, Can structs have member functions in C++?
[04:43] <StevenK> somerville32: If you're going to do that, use a class, for the love of everything holy.
[04:43] <persia> somerville32: I don't think they would be called structs in that case.  My language theory is weak, and my C++ more so: I'm just comfortable with stack traces and matching surrounding syntax, which makes me look good.
[04:44] <StevenK> somerville32: However, a struct can have a function pointer. This may make people hate you.
[04:44] <persia> LaserJock: I've caught up with you.  It looks like you've identified it correctly.
[04:44] <Hobbsee> StevenK: what's the difference between a struct and a class, if not to use member functions?
[04:45] <somerville32> I don't actually know C and I see that this struct we're in has member functions but I don't recall that in C++
[04:45] <persia> Annoyingly, we're seeing lots of "<value optimized out>" in the stacktrace.  Ideally, we'd see all the variable data, and would be able to think about it more easily.
[04:45] <StevenK> Hobbsee: A struct is an block of memory partitioned up into a bits, and a class is a bluepoint for an instance.
[04:45] <StevenK> s/a bits/bits/
[04:46] <persia> StevenK: Umm.  A struct is a blueprint for a block of memory partitioned into bits, no?
[04:46] <StevenK> Uh, duh
[04:46] <StevenK> It is nearly quarter to 1
[04:46] <Hobbsee> ah, right.
[04:46] <persia> Hobbsee: As I understand it, there's no real difference, except that C++ parsers complain when you put members in structs.
[04:47] <StevenK> They so don't.
[04:47] <somerville32> So a struct is a class without inheritance and other fancy OOP features?
[04:47] <StevenK> If you think of that way, you'll just confuse yourself
[04:47] <persia> somerville32: That's a good way to think about it, although putting members in structs is ugly and bad
[04:47] <StevenK> It's just a block of memory
[04:47] <LaserJock> persia: ok, so... is there anything we can do now?
[04:47]  * persia must use objects wrong: I think of them as fancy structs
[04:48] <Hobbsee> persia: right
[04:48] <persia> LaserJock: We can look in the other files in the bug, and see if we can get a better idea of the data on which this failed.
[04:48] <LaserJock> k
[04:48] <LaserJock> persia: ok, before we do that, one question
[04:48] <persia> LaserJock: Sure.
[04:48] <LaserJock> so do we actually know what happened?
[04:49] <StevenK> Well, a class is the spawn of the devil and a struct isn't. :-P
[04:49] <StevenK> A C++ class, anyway
[04:50] <somerville32> I'm a little lost. This struct looks like a function.
[04:50] <persia> LaserJock: No, and we don't really care.  If we get stuck, we will go back up the stack, find out what happened, and ask the user for more information.  If we find an error condition that could cause a SIGSEGV at uploadWizard.c:307 due to some silly missing test, we'll just patch it and call the bug closed.  apport will open another one if we're wrong, and the code will be better anyway.
[04:50] <LaserJock> like what actually happened in this crash?
[04:50] <persia> somerville32: That's the nature of GObject.
[04:50] <LaserJock> like does getting a wrong type of variable cause a SIGSEGV?
[04:51] <persia> StevenK: If you call a C++ class the spawn of the devil, what is a GObject?
[04:51] <StevenK> Worse. It uses function pointers.
[04:51] <somerville32> This is a GObject?
[04:51] <persia> LaserJock: That's one case.  Do you think that maybe the remote_isrel isn't a string, so sitecopy_site->remote_isrel has issues when we try to set it to '~'?
[04:52] <persia> somerville32: That's what screem-site.h told us.
[04:52] <LaserJock> persia: for instance
[04:53] <persia> LaserJock: My understanding is that a SIGSEGV happens when we try to access invalid memory, for nearly any reason.   Stuffing variables of the wrong type in the wrong places can easily lead to that.
[04:53] <ScottK> Adri2000 or Lutin: You might want to look at the difference between the DaD and MoM candidate merges for amavisd-new and ponder your script ...
[04:53] <somerville32> persia, What line?
[04:53] <persia> somerville32: The general messiness and constant references to GObject
[04:53] <LaserJock> persia: ok and ThreadStacktrace.txt doesn't really give anything useful for the variables
[04:54] <persia> somerville32: Plus all the objecty stuff jammed into a C program.
[04:55] <persia> LaserJock: Right, I also don't see much useful in ProcStatus or Disassembly.  Let's investigate your idea of a type mismatch a bit.
[04:55] <somerville32> What is in ProcStatus and Disassembly?
[04:56] <persia> So sitecopy_site is a New ScreemSite, but I don't see a reference to is_rel in screem-site.h
[04:56] <persia> Err.  Rather I don't see a reference to remote_isrel.
[04:57] <LaserJock> mhm
[04:57] <StevenK> But it should exist, otherwise it wouldn't build. :-)
[04:58] <persia> Let's start looking around in /src/screem-site* to see if there's anything useful there.
[04:58] <persia> StevenK: Yep.
[04:58] <LaserJock> sites.h:    unsigned int remote_isrel:1; /* is the remote root dir relative to login dir? (~/) */
[04:58] <somerville32> sitecopy_site->remote_isrel = ( string[ 0 ] == '~' );
[04:58] <somerville32> So remote_isrel is a property of sitecopy_site?
[04:58] <somerville32> or attribute or w/e you call it
[04:59] <persia> somerville32: Yes.  It seems to be defined in plugins/uploadWizard/sites.h
[05:00] <LaserJock> so what is that line doing?
[05:00] <persia> LaserJock: UploadWizard.c:307?
[05:00] <LaserJock> yeah
[05:01] <StevenK> If 307 is the line somerville32 pasted, I'm pointing the blame at 'string'
[05:01] <persia> It's setting remote_isrel to the result of ( string[ 0 ] == '~' ), which I think is "~\0", but I need to refesh my understanding os "string"
[05:01] <persia> s/os/of/
[05:01] <somerville32> It would be either true or false
[05:01] <LaserJock> ok, but remote_isrel is an int
[05:01] <somerville32> 1 or 0
[05:02] <somerville32> :1 means it defaults to 1, right?
[05:02] <persia> Since remote_isrel is an unsigned int, why don't we just set it to 176?
[05:02] <StevenK> Actually, an unsigned int -- there is a differencce
[05:02] <persia> Er..  126 (0x176)
[05:02] <somerville32> persia, Why that?
[05:02] <StevenK> ASCII code for ~
[05:03] <somerville32> Ah.
[05:03]  * persia echoes StevenK who isn't sleeping :)
[05:03] <StevenK> Shhh
[05:03] <LaserJock> ok, wait, I'm not quite there
[05:03] <ScottK> If a Debian package I'm trying to merge has a changelog that appears to have been lost in space for a while (has a record of uploads that the Debian archive knows nothing about and knows nothing about several uploads that Debian does know about) do I try and fix it or just plug my ears, say "la la la la, I can't hear you" and move on with it?
[05:03] <StevenK> ScottK: The later
[05:03] <StevenK> latter
[05:04] <LaserJock> ok if the first char of the sting is "~" then we're seting remote_isrel to 1?
[05:04] <ScottK> StevenK: Thanks.
[05:04] <persia> ScottK: Fixing it would be nice, but not fixing it would be "best practice"
[05:04] <imbrandon> woot, Xvesa seems to build and install fine joejaxx , now to test if it actualy works
[05:05]  * ScottK grumbles it'll make my fix for Gutsy look silly for fixing a really old version, but OK ...
[05:05] <persia> LaserJock: We're setting remote_isrel to the byte value of the first character of the string '~'.  I believe this should be 0x176
[05:05] <pwnguin> i donno if fixing it would be a good idea
[05:05] <somerville32> How do we do that exactly?
[05:05] <pwnguin> its possible that debian dropped an older package in favor of that one
[05:06] <StevenK> sitecopy_site->remote_isrel = chr(string[0]);
[05:06] <persia> somerville32: We comment out line 307, and add our own that sets the value explicitly rather than through string[ 0 ] == '~' , and has a comment that 0x176 == '~'.
[05:06]  * persia also likes StevenK's suggestion
[05:06] <somerville32> So we're going to recompile and attempt this?
[05:06] <LaserJock> well, how do we even test this?
[05:06] <persia> somerville32: We don't know how to reproduce it :)
[05:06] <ScottK> StevenK: is it something to file a bug against the package on in Debian?
[05:06]  * somerville32 echos LaserJock question
[05:07] <StevenK> persia: Keep in mind that may break other assumptions in the code.
[05:07] <persia> LaserJock: In this case, we can't really.  We can step back through the trace, but without the data, we'll have trouble.
[05:07] <imbrandon> err is Xorg suid root ?
[05:07] <LaserJock> persia: ok, so at this point what do we do?
[05:08] <LaserJock> time to look upstream maybe?
[05:08] <persia> LaserJock: Well, I'm looking through the function a bit more, and notice more checks below.  I'm suspecting string is actually some variable rather than a word, and we'll want to find out what it means.
[05:08] <pwnguin> imbrandon: yes?
[05:08] <LaserJock> persia: I see
[05:09] <pwnguin> imbrandon: root      6498  4.3  5.9  68048 62028 tty7     SLs+ Nov03  31:06 /usr/bin/X
[05:09] <persia> Looking at upstream can help, if they've fixed it, but I usually just chase the code for a bit.  Most are a little less confusing :(
[05:09] <somerville32> What line does it actually crash on?
[05:10] <pwnguin> imbrandon: 	gcc soulfu.c -I/usr/include/SDL/ -I/usr/include/GL/ -I../lib/jpeg-soulfu/ -L../lib/jpeg-soulfu/ -lSDL -lGL -lSDL_net -lvorbis -logg -ljpeg
[05:10] <persia> OK.  Line 304 tells us that string = screem_site_get_remote_path( ssite ), so we're really looking at a pathname, and trying to determine the structure.
[05:10] <pwnguin> doh
[05:10] <pwnguin> imbrandon: -rwsr-sr-x 1 root root 7472 2007-10-09 13:53 /usr/bin/X
[05:11] <LaserJock> persia: right, it's taking something like ~/public_html or something?
[05:11] <StevenK> persia: So now the question is, what does screem_site_get_remote_path() return?
[05:11] <LaserJock> s/taking/looking for/
[05:11] <persia> LaserJock: Right.  In line 312 it checks to see that there is a valid first character (either ~ or /)
[05:12] <persia> To test, we could try defining a screem remote site without a valid first character (or a unicode first character) and see if it breaks in an interesting way.
[05:13]  * persia installs screem
[05:16] <LaserJock> hmm, the path on the site or the URL?
[05:18] <persia> LaserJock: I suspect the "Remote Path" in Site Settings.
[05:20] <persia> Hrm.  I can't reproduce, even with funny strings: it seems to take the right decision, or complain.
[05:21] <LaserJock> so is it ok to ask the reporter if they can confirm?
[05:21] <persia> LaserJock: Perhaps, but I'm tempted to think that 0.16.1-4.1ubuntu1 might have fixed it (don't disable gtk deprecateds).
[05:22] <LaserJock> really?
[05:23] <persia> LaserJock: Well, maybe.  Changing the API can have odd effects.  Depends on the nature of the change, and I'm not sure what -DGTK_DISABLE_DEPRECATED -DGNOME_DISABLE_DEPRECATED -DGNOMEUI_DISABLE_DEPRECATED would do to a build.
[05:23] <LaserJock> mhm
[05:23] <persia> I'm looking at the build history, to see where the build failure was happening: if the earlier version was released on i386, that might be a source of issues.
[05:25]  * LaserJock has spent his weekly Ubuntu time on this bug ;-)
[05:26] <Hobbsee> you have a weekly ubuntu time now?
[05:26] <LaserJock> I *should*
[05:26] <persia> LaserJock: Sorry.  Fixing one of these takes a few hours, if not more.  I prefer it to looking at lots of bugs, because of the sense of satisfaction when a solution is found, but it's not a light task.
[05:27] <LaserJock> persia: thanks for helping me out
[05:27] <LaserJock> I'm gonna try some more
[05:27] <somerville32> persia, So what exactly do you do when you find the solution?
[05:27] <LaserJock> geeze, some of these are just so unhelpful though
[05:28] <LaserJock> "Under Feisty. Screem doesn't want to publish."
[05:28] <LaserJock> that's from March
[05:28] <persia> somerville32: Write a patch.  If it's easy to replicate, I just apply it, and then share with others.  If it's mysterious, I send it upstream, with notes from my debugging.  Sometimes I can't find the fix, and just have to send notes (I exposed a libgtk bug this way)
[05:29] <somerville32> Do you apply it locally or do you send it upstream to apply?
[05:29] <persia> somerville32: If I know it fixes it, I do it locally first, and then pass it on.  If I'm not sure, I pass it on first, and wait for it to get reviewed by others.  It all depends on my confidence level that the solution is correct.
[05:30] <LaserJock> this should at least let me figure out if any off the apport bugs are dups, etc.
[05:30] <somerville32> persia, Lets try another bug! :)
[05:30] <persia> LaserJock: Anything that has the same line in #0 is typically a dup.  This isn't always true, but for bugs with reasonable traces, a good fix for one of them usually fixes the others.
[05:31] <persia> If the traces aren't clear, it's a lot harder to tell.  if the trace is bad, and the description is bad, and I can't easily replicate, I usually call them invalid.
[05:32] <imbrandon> haha gotta love comments in debain/* files sometimes
[05:32] <persia> somerville32: I'm not done with this one.  If you want to try another apport bug, go ahead: I'm happy to answer questions about the process (and if you're lucky, you'll find one with an obvious patch: I seem to have about a 50% success rate)
[05:32] <persia> imbrandon: which?
[05:32] <imbrandon> # piss-off
[05:32] <imbrandon> xprint binary: description-starts-with-package-name
[05:32] <imbrandon> in an overides
[05:33] <StevenK> Who's the maintainer?
[05:33] <somerville32> persia, If you have any more breakthrough let me know
[05:33] <imbrandon> StevenK, core-dev ( its part of xserver-xorg-core )
[05:33] <persia> somerville32: On this bug?  Sure.  If I find a solution, I'll report it.  Subscribe to the bug if you want detailed history.
[05:34] <imbrandon> ok , me being an idiot i havent messed with having to suid a prog yet ( thankfully i guess ? ) but looking in the xorg package i cnt see where its chmod +s it
[05:34] <imbrandon> wtf am i missing
[05:34] <LaserJock> persia: could you have a quick look at whether bug #86003 is useful?
[05:34] <ubotu> Launchpad bug 86003 in screem "[apport] screem crashed with SIGSEGV" [Medium,New] https://launchpad.net/bugs/86003
[05:35] <Fujitsu> imbrandon: As far as I know it's not... doesn't *dm execute it as root?
[05:35] <Fujitsu> Oh, I see, it is..
[05:35] <imbrandon> yea
[05:35] <Fujitsu> imbrandon: Might the upstream install target set it?
[05:36] <persia> LaserJock: I just looked at that earlier.  It needs a retrace.  I added the tag, and hope apport will get to it.  If not, it's not as useful.
[05:36] <LaserJock> persia: ahh, ok
[05:36] <somerville32> Can I access apport bugs?
[05:36] <imbrandon> and building Xvesa needs to be suid also ( same source, justa new .install ) soooooo i was trying to look and see where it does it
[05:36] <Fujitsu> somerville32: We do try to unprivatise them where appropriate.
[05:37] <Fujitsu> somerville32: Search for bugs tagged apport-crash.
[05:37] <somerville32> Who has access though?
[05:37] <pwnguin> imbrandon: is -motu really a better resource for this than -devel or -x?
[05:37] <imbrandon> pwnguin, i always start here and since Xvesa likely wont be main right off , yes
[05:37] <persia> somerville32: developers and the bug control team
[05:38] <Fujitsu> somerville32: Members of ~ubuntu-crashes-universe.
[05:38] <pwnguin> phew. it'd be kinda crazy if motu knew more about x than devel or x team
[05:38] <LaserJock> persia: http://launchpadlibrarian.net/7618029/%3Cfdopen%3E looks pretty useless?
[05:38] <Fujitsu> imbrandon:
[05:38] <Fujitsu>         chmod ug+s debian/x11-common/usr/bin/X
[05:38] <Fujitsu> In debian/rules.
[05:39] <persia> LaserJock: Yep.  That's a smashed stack.
[05:39] <LaserJock> persia: is that an "Invalid"?
[05:39]  * Fujitsu invalidates them, asking them to reopen if they can get a backtrace.
[05:40] <persia> LaserJock: Depends on the user comment.  If the user provided enough information for the bug to be useful without the stacktrace, no.  If the user provided the more common "I didn't do nothing", then Yes, "Invalid"
[05:40] <LaserJock> it just says "I started it and it crashed"
[05:40] <somerville32> Oh cool, I'm already a member of ubuntu-crashes-universe
[05:40] <persia> LaserJock: That's not enough information for us to help.
[05:41] <Fujitsu> somerville32: Through ubuntu-qa or whatever it is called today?
[05:41] <somerville32> Aye.
[05:41] <somerville32> or ubuntu-bugcontrol
[05:41] <Fujitsu> That's the one.
[05:41] <persia> LaserJock: To put it differently, if either the description or the stacktrace gives you enough information to figure out the nature of the problem, then it's useful.  If not, then it's "Invalid"
[05:41] <Fujitsu> I preferred ubuntu-buglords, personally.
[05:42]  * persia was fine with QA
[05:44] <LaserJock> it's not ubuntu-qa anymore?
[05:44] <somerville32> nope
[05:45]  * persia misses QA.  How do we now assure quality?
[05:45] <LaserJock> well that's weird
[05:46] <LaserJock> I understand using something else for permissions control
[05:46] <somerville32> We weren't really doing QA :/
[05:46] <LaserJock> but we should still have a QA team
[05:46] <LaserJock> ubuntu-qa
[05:46] <somerville32> buqsquad is the new qa team
[05:47] <somerville32> What happened to the lawless guy?
[05:47] <persia> somerville32: Well, we missed for a while, but we almost reached parity between number of bugs reported per week and number of bugs closed per week recently.  The issue is that there are 35,000 open bugs, and that number hasn't gone down (nevermind that bug reporting has picked up)
[05:47] <DarkMageZ> bugsquad is for finding duplicate and invalid bugs and marking them as so. QA team should fix the critical/annoying bugs.
[05:48] <Fujitsu> QA team shouldn't be fixing.
[05:48] <somerville32> Right
[05:48] <persia> DarkMageZ: I disagree.  bugsquad can also handle lots more of triage, and lots of tagging.
[05:48] <Fujitsu> The only reason they were separate is for Importance setting.
[05:48] <persia> QA team should be reviewing major issues, and highlighting areas for Contributor focus.  Contributors (including developers) should be fixing bugs.
[05:49]  * Fujitsu notes that ~canonical-qa is now sizable.
[05:50]  * persia thinks that ~community-qa is still important
[05:50] <somerville32> That team doesn't exist.
[05:51] <Fujitsu> persia: Well, obviously, particularly as I'm sure they'll mostly focus on main.
[05:51] <persia> somerville32: It used to be ~ubuntu-qa, until the permissions issue.
[05:55] <LaserJock> ok, how about "it randomly crashes with compiz"?
[05:56] <persia> LaserJock: "random" == "invalid"
[05:56] <persia> (unless there is, by any chance, a remarkably useful stacktrace)
[05:57] <LaserJock> persia: http://launchpadlibrarian.net/9520221/ThreadStacktrace.txt
[05:57] <persia> LaserJock: Which bug?
[05:57] <LaserJock> why does that look so different from the last one?
[05:58] <LaserJock> bug #145331
[05:58] <ubotu> Launchpad bug 145331 in screem "screem just shuts with no message" [Medium,New] https://launchpad.net/bugs/145331
[05:58] <persia> LaserJock: This is a threaded stacktrace
[05:58] <LaserJock> it's got a lot of /build/buildd/glib2.0-2.14.1/glib/gslice.c
[05:59] <LaserJock> I remember there being an issue in gutsy where you'd get some sort of gslice warning
[05:59] <persia> Ah.  #40 / #41 is interesting.
[06:00] <persia> From a screem POV, this might be handled by checking for GTK failure in gtk_list_store_remove, but given the depth of the trace, I'd say this was a GTK bug.
[06:01] <persia> (I don't like to fix anything beyond #10 or so, unless the end is just running through exception handlers)
[06:03] <persia> (alternately, I'm not sure why GTK is calling back to screem for #33.  Maybe this is odd customised widget code?)
[06:07] <LaserJock> ok ...
[06:07] <LaserJock> so as the reporter says this is random is there anything to go on?
[06:11] <persia> LaserJock: Not really.  It looks like a memory allocation error, but given that it was running some random snapshot of unreleased code, which may not match any replicable environment, it's hard to say.  I'd suggest marking "Invalid", and requesting the reporter to submit a new trace if they can still replicate it in the current release.
[06:11] <LaserJock> right
[06:11] <persia> Of course, if you happen to have a GTK programmer around who can look at the issue, and tell you if it's fixed or not, that makes it easier :)
[06:12] <persia> LaserJock: If we had that stacktrace from 26 October instead of 26 September, I'd call it a valid bug, and reassign to libgtk-2.0
[06:13] <persia> (or for 26 September, if filed against 7.04
[06:16] <LaserJock> I see
[06:22] <LaserJock> oh geeze, here's one from June 06
[06:22] <persia> LaserJock: Any chance it's reported against released Dapper?
[06:23] <LaserJock> I don't know
[06:23] <LaserJock> it was 2006-06-25
[06:23] <LaserJock> what day did we release Dapper?
[06:23] <persia> Ah.  Right.  We didn7t get Apport until feisty or so, did we?
[06:24] <LaserJock> this is got a manual stack trace
[06:24] <persia> LaserJock: Doesn't matter.  I can believe a 5 day wait before upgrading.
[06:24] <persia> OOh.  Which one?
[06:24] <LaserJock> bug #50936
[06:24] <Fujitsu> persia: Edgy, but not until Feisty did it attach them multi-part and get automatic retraces.
[06:24] <ubotu> Launchpad bug 50936 in baltix "Screem freezes seemingly at random" [Undecided,Invalid] https://launchpad.net/bugs/50936
[06:24] <persia> Fujitsu: It was end-edgy that we had the manual download&retrace workflow?
[06:25]  * persia grumbles at Baltix
[06:25] <Fujitsu> I think so.
[06:25] <Fujitsu> I hate the darn Baltix tasks.
[06:25] <minghua> Hmm.  I wonder if it's worth reporting a bug if I don't use "visual effects", remove compiz, and get a GNOME with no window manager.
[06:25] <minghua> s/if I don't/that I don't/
[06:25] <persia> minghua: It's a known issue: it should be a bug, as compiz doesn't work for everyone.
[06:25] <LaserJock> oh geeze
[06:26]  * LaserJock finally sees Reno 911
[06:26] <imbrandon> LaserJock, youve never seen it before ?
[06:26] <imbrandon> heh
[06:26] <LaserJock> no
[06:26] <minghua> persia: When compiz was not removed, it was fine.
[06:27] <minghua> (although I don't think I was using compiz, it seems there was a backup plan working)
[06:27] <persia> minghua: Right.  There's something odd happening.  I don't remember why, but I believe the bug log for the issue should tell you.
[06:27] <minghua> persia: Do you by any chance remember which package that bug is against?
[06:27] <persia> minghua: No idea.  I remember discussion on IRC only
[06:28] <LaserJock> imbrandon: I didn't know it had so much Reno in it
[06:28] <persia> minghua: It's even more complicated as it's probably either Fix Released or Invalid.
[06:28]  * minghua goes digging LP.
[06:28] <minghua> Ugh.
[06:28] <Fujitsu> AFAIK, compiz is always executed, but degrades to metacity if your card is blacklisted. So if you remove compiz without disabling it in Appearance first, you lose.
[06:28] <LaserJock> geeze, that would really suck if I'm on Reno 911  :/
[06:29] <imbrandon> lol
[06:29] <LaserJock> persia: any guess on that old screem bug?
[06:30] <LaserJock> imbrandon: seriously, I saw UNR
[06:30] <imbrandon> yea, i used to watch it all the time
[06:30] <minghua> Fujitsu: It had always been disabled in "appearance" for me.  There is a hard-coded gconf key.
[06:30] <imbrandon> its funny as hell
[06:30] <persia> LaserJock: I don't know screem well enough.  I can't figure out  what "attach a file" means.
[06:30] <LaserJock> persia: I think he was saying that he was going to attach the files he was working on
[06:30] <Fujitsu> minghua: Ah.
[06:31] <persia> LaserJock: The trace is useful, and the comment usful.  I have no idea if it applies to modern screem.
[06:31] <minghua> So the blacklist Fujitsu mentioned should be the "backup plan" I was suspecting.  Something is still wrong, though.  I do realize my situation is uncommon.
[06:31] <persia> LaserJock: Right.  I can't find any "attach" menu item.
[06:31] <LaserJock> persia: I was thinking attach to the bug report
[06:32] <persia> Ah.  Excellent interpretation.  It's an "Incomplete" bug until we get the test files :)
[06:33] <LaserJock> right on
[06:34] <minghua> Aha.  Bug 157200 seems to be my problem.
[06:34] <ubotu> Launchpad bug 157200 in compiz "metacity wont start directly if compiz and xserver-xgl are removed" [Undecided,New] https://launchpad.net/bugs/157200
[06:35] <Fujitsu> minghua: Looks like it, though I would have thought there would be a dupe.
[06:35] <Fujitsu> Maybe in gnome-session.
[06:35] <persia> minghua: It's surely a duplicate of something older, but yes :)
[06:36] <minghua> Yeah, that's why I'm asking here first, but nobody seems to know for sure. :-(
[06:36] <minghua> That bug isn't exactly the same as mine though...
[06:36] <persia> minghua: You might also ask the #ubuntu-bugs people.  They see more of the bugs than we do
[06:37] <persia> (although the population there seems to be steadily dropping: I blame ubotu
[06:38] <minghua> persia: Right, I'll ask there.  Although I doubt it will be more helpful.
[06:42] <LaserJock> man
[06:42] <LaserJock> sometimes Main can be a real mess
[06:42] <Hobbsee> heh
[06:42] <Hobbsee> why is it this time?
[06:44] <LaserJock> well, it looks like these screem bugs have never been triaged
[06:44] <Fujitsu> edubuntu must be about the worst part of main to live in.
[06:44] <LaserJock> I just found one with lots of info and an upstream bug report
[06:44] <LaserJock> but there's been no triage
[06:45] <LaserJock> and it's from 2006-09-23
[06:45] <minghua> Heh.  My impression is that main has always been a mess.
[06:45] <minghua> Fujitsu: Don't forget LaTeX. :-P
[06:45] <Fujitsu> minghua: Ah, that too.
[06:45] <LaserJock> ugggggg
[06:46] <LaserJock> don't even mention TeX
[06:46]  * Fujitsu decides he should probably do a practise exam, so runs off for 1.5 hours.
[06:46] <LaserJock> at least upstream does some stuff in LP
[06:46] <LaserJock> although they're pretty disgusted about it
[06:46] <Fujitsu> LaserJock: True, he is being useful.
[06:47]  * Fujitsu will attack ~motuscience and ~ubuntu-tex bugs in a couple of weeks.
[06:47] <LaserJock> great
[06:49] <persia> Got it.  "sitecopy_site->remote_isrel = ( string[ 0 ] == (gchar) '~' );"
[06:52] <LaserJock> were you able to test it?
[06:53] <persia> LaserJock: I couldn't make it fail before, but I've just been reading the C spec again, and it reports that if the types of the operands for == are not identical, it tries a series of things, none of which seem to be ideal.  Casting makes the nature of the test we want explicit, and the gtk docs seem to indicate that gchar is better than char to avoid issues in the future.
[06:54] <warp10> Hi all!
[06:54] <persia> (I'm suspecting is has something to do with multibyte support and some strange corner case, but I'm unsure enough that I'll consider it an upstream bug, rather than uploading directly)
[06:55] <persia> (Also, I need to test and make sure I didn't break my current set of test cases)
[07:03] <LaserJock> hmm, #0  0xffffe410 in __kernel_vsyscall ()
[07:04] <persia> LaserJock: That's clearly a userspace call convention error.  Back up lots of steps.
[07:04] <persia> i.e. The program is passing the wrong data to the kernel
[07:09] <LaserJock> hmm, well it's an odd bug
[07:09] <LaserJock> the reporter says that he can't add any tags from the menu, screem becomes unresponsive
[07:09] <Zelut> does anyone know what package controls hardware volume keys in gnome?
[07:10] <LaserJock> so I'm thinking if it was a widespread bug we'd see more dups/comments
[07:10] <LaserJock> so maybe I'll just ask if it's still going on (it's from september 2006)
[07:11] <persia> Zelut: I think most bugs of that type are being filed against "control-center", but that's no guarantee it's the right package.
[07:12] <Zelut> persia: ok.  I'm going through my outstanding bugs and trying to make sure they are assigned to the right package.
[07:12]  * persia grumbles that someone stole my Debian menu and stuffed "Other" with too much stuff.
[07:13] <LaserJock> oh man, "Other" is a mess
[07:13] <LaserJock> I spent forever cleaning it out the other day
[07:13] <persia> LaserJock: There used to be a "Debian" menu which pulled out most of it, but that appears to be gone.
[07:13] <LaserJock> hmm, I still have it
[07:13] <persia> LaserJock: Also, I can insert tags for my shiny custom extra patche screem
[07:18] <LaserJock> ok, well I'm done with bugs for tonight I think
[07:18] <LaserJock> I didn't even quite get through half of screem
[07:19] <persia> LaserJock: Blame that on digging so deeply into 128903.  While we didn't end up letting you get an "Aha!" moment, I hope you're more confortable with stack traces.
[07:20] <LaserJock> yes, definately
[07:27] <somerville32> Me too
[07:28]  * persia cheers, and hopes for a wave of patches
[07:28] <imbrandon> we need this kid working for ubuntu , serouisly , http://video.google.com/videoplay?docid=4913196365903075662&hl=en
[07:31] <persia> imbrandon: savants have better things to do, no?  Much of what we do it repetitive, and, while worthwhile, not exciting.  I'd rather a savant upstream who generates intuitive frameworks to provide for a different generation of UI (and, no, this doesn't mean bling)
[07:31] <somerville32> Is that the toilet seat kid?
[07:36]  * Hobbsee plays more with compiz, and avoids the assigment
[07:40] <persia> LaserJock: Just for fun, screem upstream as removed the uploadWizard entirely : apparently it was broken :)
[07:41] <somerville32> Hmmm... why no sound with flash in Firefox :/
[07:43] <LaserJock> persia: oh really?
[07:43] <LaserJock> persia: do we have that in hardy yet?
[07:43] <persia> LaserJock: I just looked at upstream CVS, and everything under ./plugins/uploadWizard had been deleted.
[07:44] <LaserJock> k
[07:44] <persia> LaserJock: No.  hardy source has the files: I'm not sure there's been a release: I just usually check CVS before I file a bug.
[07:45]  * persia goes back to the screem site
[07:45] <persia> LaserJock: Nope.  Upstream still recommends 0.16.1 as the stable suite, whereas development (including the deletion) is in 0.17
[07:48] <somerville32> Crazy. I closed firefox but firefox-bin is still running and eatting up 40% of my memory :)
[07:53] <persia> somerville32: epiphany and konqueror are pretty good.
[07:54] <ion_> I’m enthusiastically waiting for the webkit version of epiphany.
[07:55] <somerville32> Is Emmet a guy or a girl?
[07:55] <persia> ion_: Do you really think webkit is that much better?  I find gecko epiphay renders faster than Safari, but that could be a wrapper.
[07:55] <RAOF> ion_: I'll settle for epiphany-on-xulrunner-1.9
[07:55]  * persia thinks somerville32 is asking personal questions
[07:55] <somerville32> I just like to use proper pronouns
[07:56] <ion_> I’ve been under the assumption that webkit is more lightweight than gecko.
[07:56] <RAOF> somerville32: "they" and "their" works quite nicely :)
[07:56] <LaserJock> somerville32: I know what you mean, it annoys me
[07:56] <somerville32> RAOF: They and their are plural, not singular
[07:56] <LaserJock> RAOF: I don't think that's generally considered good form in english
[07:57] <persia> ion_: It should be, and the memory footprint is smaller, but I also don7t like waiting for render.
[07:58] <persia> somerville32: There's also alternate constructions, such as "Cody wrote a blog entry, in which is it was said that ..." (rather than "$pronoun said..." in a second sentence.
[07:58] <persia> s/is it/it/
[07:58] <RAOF> LaserJock: Nah.  Only since some blokes decided to arbitrarily say that's bad grammar some time in the early 19th century :P
[07:58] <LaserJock> persia: yeah, it's just harder to write that way
[07:58] <Hobbsee> can someone poke me?
[07:59] <Hobbsee> or say my nick?
[07:59]  * persia pokes Hobbsee
[07:59] <LaserJock> RAOF: no, it is a plural form
[07:59] <elmargol> can epiphay now use webkit?
[07:59] <Hobbsee> ah, thanks
[07:59]  * Hobbsee pokes persia back
[07:59]  * LaserJock tickles Hobbsee 
[07:59]  * Hobbsee tickles LaserJock, and locks him in her cube.
[07:59] <LaserJock> hmm
[07:59]  * Hobbsee wants the aquarium plugin for the cube, though
[07:59]  * LaserJock uses his CO2 laser to cut a hole in the cube
[07:59] <persia> Lots of LaserJocks, all swimming for the biscuit?
[08:00] <somerville32> Oh wait... Persia is Emmet. :/
[08:00] <somerville32> Sorry, talking about someone in third person while they are here is kind of rude.
[08:00] <RAOF> Hobbsee: It's quite easy to build-from-git, assuming that it builds at all :)
[08:00] <Hobbsee> yeah well
[08:00] <Hobbsee> it seems like we've only got an old version of the most unofficial plugins pack
[08:00] <RAOF> What?  We have a version of that *at all*?
[08:01] <pwnguin> the problem is that third person in english lacks a singular version disctinct from the plural
[08:01] <Hobbsee> compiz-fusion-plugins-unsupported, i think
[08:01] <Hobbsee> yeah
[08:01] <persia> pwnguin: No, it has four: "he", "she", "it", and "one"
[08:01] <Hobbsee> hm, maybe it's gone now
[08:01] <pwnguin> actually, in this case, it's merely gender
[08:01] <pwnguin> it
[08:01] <somerville32> it is genderless
[08:01] <pwnguin> right
[08:01] <somerville32> But it is rather demeaning to refer to someone as an it.
[08:01] <pwnguin> a person is not genderless
[08:02] <somerville32> It is used pretty exclusively for inanimate objects or inferior species.
[08:02]  * jussi01 pokes persia
[08:02] <RAOF> Hobbsee: I'm pretty sure that's not in any of *our* archives.  It was in various 3rd party thingies.
[08:02] <persia> jussi01: Yes?
[08:02] <Hobbsee> RAOF: hm.
[08:02] <imbrandon> what about furry as a gender? or is that only in SL ?
[08:02] <imbrandon> lol
[08:02] <Hobbsee> there was something i couldnt install :)
[08:02] <pwnguin> thats kickban worthy
[08:03] <Hobbsee> heh.  chug chug chug, when rotating cube with the water going
[08:03] <RAOF> Hobbsee: p.u.c doesn't think that there's a compiz-fusion-plugins-unofficial :)
[08:03] <Hobbsee> odd.  there was definetly something.
[08:03] <persia> compiz-plugins-extra?
[08:03] <pwnguin> RAOF: hardy?
[08:04] <somerville32> I've never actually used compiz :/
[08:04] <RAOF> pwnguin: Is yet to be installed on any system that I could test stuff on?
[08:04] <somerville32> It sounds fun.
[08:05] <pwnguin> i recall hobbsee trying to upgrade to hardy
[08:05] <pwnguin> somerville32: until the fire plugin reaches stable, it's one part fun two parts frustration
[08:06]  * jussi01 doesnt like compiz
[08:06] <RAOF> Hm.  Actually, how sane would it be to take an LVM snapshot of my current gutsy-root and update that to Hardy?
[08:06] <Hobbsee> pwnguin: trying?  i suceeded.
[08:06] <RAOF> jussi01: Why not?
[08:06]  * somerville32 upgrades to giddy goose.
[08:06] <Hobbsee> pwnguin: my fire works fine - it's my annotate that crashes X!
[08:06] <pwnguin> heh
[08:06]  * RAOF never quite got the point of annotate.
[08:06] <pwnguin> its really quite handy if you have a tablet
[08:06]  * jussi01 mentions ati, slowness and general annoyingness factors to RAOF
[08:07] <pwnguin> draw on anything!
[08:07]  * Fujitsu prefers firepaint.
[08:07] <pwnguin> also nifty: drawing with fire
[08:07] <Hobbsee> Fujitsu: here too
[08:07] <RAOF> Multicoloured, smokey fire.
[08:07] <Hobbsee> RAOF: compiz-compcomm-plugins-main
[08:08] <pwnguin> im a bit sad that there isnt a Satanic Edition theme for compiz
[08:08] <pwnguin> a 5 sided workspace, fire plugin enabled, etc
[08:08] <LaserJock> it'd be appropriate
[08:09]  * RAOF feels a "please remove from archive" bug coming on
[08:09] <Hobbsee> hehe
[08:09] <Hobbsee> yes, i think so
[08:09] <LaserJock> compiz is from the devil
[08:09] <Hobbsee> hey now!  compiz is nice!
[08:09] <pwnguin> its devilicious!
[08:09] <Hobbsee> assuming it doesnt crash
[08:10] <LaserJock> ...
[08:10] <pwnguin> actually, compiz still lacks polish
[08:10] <LaserJock> that's a might big assumption
[08:10] <Fujitsu> It hasn't crashed on me in months.
[08:10] <LaserJock> it completely rendered my Firefox useless
[08:10] <Hobbsee> ouch!
[08:10] <LaserJock> other than that and the crashing it's not so bad
[08:10] <Hobbsee> LaserJock: oh, you're using kde arent you?
[08:11] <RAOF> It exposes *all sorts* of nvidia bugs.
[08:11] <LaserJock> not presently
[08:11]  * persia seconds RAOF
[08:11] <pwnguin> heh
[08:11] <pwnguin> i found a cool nvidia bug
[08:11] <LaserJock> yeah, it seems like "it works great if you have X, Y, Z"
[08:11] <pwnguin> or maybe just an X one
[08:11] <pwnguin> or totem
[08:11] <persia> pwnguin: As cool as being able to move the mouse and seeing the last frame of video during a kernel panic?
[08:12] <pwnguin> run totem fullscreen, exit fullscreen, then rotate the screen with xrandr
[08:12] <persia> pwnguin: What happens?
[08:12] <pwnguin> fullscreen again and it sorta fights over which rotation is correct
[08:14] <Fujitsu> Xv is special.
[08:14] <Hobbsee> LaserJock: it does help tha ti have the same chipset as one of the devs, i'll agree :P
[08:14] <Fujitsu> Hobbsee: What do you have?
[08:15] <Hobbsee> Fujitsu: intel 965
[08:15] <Fujitsu> Ah, 915 here, works very well. Except for lag on water + various transformations, or motion blur.
[08:16] <RAOF> Motion blur.  Possibly a plugin with *negative* point.
[08:17] <Fujitsu> It does prettify things if you have it set very low. Tab changes, and the like.
[08:17] <RAOF> Really?
[08:17] <Hobbsee> oh, ahng on
[08:17] <Fujitsu> Where low is < 0.1, IIRC.
[08:17] <Hobbsee> Fujitsu: 945, sorry.
[08:17] <Hobbsee> yeah.  i dont like the motion, so killed it
[08:17] <RAOF> I've never managed to set it low enough to (1) be visible, and (2) not induce motion sickness
[08:18] <LaserJock> my laptop is just too junkie :/
[08:19] <Fujitsu> LaserJock: Too PowerBook?
[08:19] <LaserJock> I was shocked when I reinstalled Gutsy and it started compiz
[08:19] <LaserJock> nah, Toshiba with ATI 7000
[08:19] <Fujitsu> Wow, a non-Mac.
[08:19] <LaserJock> ?
[08:20] <LaserJock> I've never owned a mac
[08:20] <Fujitsu> Don't you mostly use Macs?
[08:20] <Fujitsu> Or was that just at work?
[08:20] <LaserJock> just have an iMac at work
[08:20] <Fujitsu> Ah.
[08:20] <LaserJock> I'm not that well off ;-)
[08:20] <LaserJock> maybe next time
[08:20] <LaserJock> I have a homebuilt desktop and this toshiba
[08:27] <LaserJock> ok, I'm gone
[08:30] <somerville32> Bye
[08:33] <persia> Does anyone have a pointer to a good guide on splitting packages?  I keep hitting walls, and I'm sure there's a better solution.
[08:34] <Hobbsee> ruddy thing.
[08:34] <Hobbsee> it hardlocked my entire machine
[08:42] <Fujitsu> Yay, g-p-m seems to now be able to deal with my backlight, since I last restarted X (first time in about 3 days).
[08:47] <pwnguin> orly?
[08:47] <pwnguin> in hardy?
[08:47] <Fujitsu> Yeah.
[08:47] <pwnguin> i filed a bug on that ages ago with no response =(
[08:48] <Fujitsu> Previously it just did really odd things like increasing the brightness from 0% -> 100% over a couple of minutes.
[08:48] <pwnguin> heh
[08:48] <pwnguin> well, gutsy isnt that dumb
[08:48] <pwnguin> it just does things like paint the screen black instead of actually turning the light off
[08:48] <Fujitsu> No, that's what Gutsy did.
[08:49] <pwnguin> obviously theres about a billion ways for it to go wrong
[08:49] <Fujitsu> Yeah.
[09:10] <knights> Hi guys!
[09:12] <knights> Are there any plans to integrate the alternate installer with the desktop live feature onto one CD yet? Maybe for Hardy? I don't nderstand why Ubuntu is still a 2 CD affair when I'm sure both installers could fit on the 1 CD
[09:14] <minghua> knights: How are you sure?
[09:15] <imbrandon> knights, the cd space is very very limited, and rember its not just putting both installers on the cd, they install in totaly diffrent ways
[09:15] <imbrandon> one basicly copys the livecd to the target and then modifies from there, the other uses .debs from the cd and installs them
[09:16] <imbrandon> so it wouldnt be just copy both d-i and ubiguity to the same cd
[09:17] <imbrandon> i'm not saying it couldent be done, but your more likely looking at dvd size
[09:17] <Fujitsu> knights: They're entirely different - you'd need both the live image and the .debs. Which would be about twice the size.
[09:22] <persia> Is anyone here an Eiffel aficionado?  It appears there is a new, vastly better, smarteiffel that FTBFS in gutsy, and needs some help.
[09:22] <minghua> If it FTBFS, how is it vastly better? :-P
[09:23] <persia> minghua: Well, it's vastly better in lenny then...
[09:28] <elmargol> Is webkit going to main?
[09:28] <elmargol> Or hardy+1`
[09:29] <persia> elmargol: https://wiki.ubuntu.com/UbuntuMainInclusionQueue is where you can get that answer
[09:30] <imbrandon> i dont see an MIR for it
[09:30] <persia> Or, the first.  The second is best answered by https://launchpad.net/ubuntu/+source/webkit
[09:30] <knights> Another thing that should be added to ubuntu is a lightweight window manager like fluxbox or icewm set up with rox filer. This woukld only require a few more megabyte of space on the CD and would be very useful to many and reduce the need for separate, lightweight distros like fluxbuntu, xubuntu etc.
[09:31] <persia> knights: It's not just about the WM.  One needs to also install the applications.  Currently, there is only ~30 MB free on a 700MB CD.  It would be nice to be able to support 650MB CDs before it would be nice to add stuff.
[09:31] <imbrandon> knights, sounds like you need to have a look at wiki/IdeaPool , this really isnt the place for sugestions of that calubur
[09:32] <elmargol> just remove evolution it sucks anyway :D
[09:32] <somerville32> lol
[09:32] <knights> Can you still buy 650MB CDs?
[09:32] <imbrandon> yes
[09:33] <elmargol> Why not use dvd?
[09:33] <knights> A 700MB CD must be about 0.01 more
[09:33] <minghua> Most CD-RWs are still 650MB, if I'm not mistaken.
[09:33] <persia> knights: Yes, but I've previously grabbed the wrong kind in a convenience store, and it was annoying.
[09:33] <knights> You could fit a lot of apps into that extra 50MB
[09:33] <persia> elmargol: Those are huge, and for most people, downloading that much is a waste of bandwidth.
[09:33] <Fujitsu> We haven't supported 650MB CDs in a looong time.
[09:34] <persia> Fujitsu: No, but wouldn't it be nice :)
[09:34] <Fujitsu> There is never more than a couple of megabytes free.
[09:34] <imbrandon> wow , you guys might be better seved on the ubuntu ML archives, all these points have been beaten to death there and here it does no good to hash them again as the decisions arent made here
[09:34] <elmargol> ok 1cd basic + dvd extras
[09:34] <persia> elmargol: Still a waste of bandwidth.
[09:34] <minghua> Fujitsu: Have we ever?
[09:35]  * persia thinks Breezy fit on 650MB
[09:35] <Fujitsu> persia: I don't think so, but it's possible.
[09:35] <knights> imbrandon: So what was the reasoning behind deciding not to include a lightweight window manager with ubuntu? It can't be 'we don't have enough space' as 30MB would be more than enough for fluxbox, icewm or whatever
[09:36] <Fujitsu> persia: You're right.
[09:36] <Fujitsu> knights: We don't have 30MB.
[09:36] <persia> Fujitsu: No, you're right.  Breezy was 690MB.  Hoary was only 610 for AMD64, but that was ages ago.
[09:36] <knights> I'm sure 5MB would do it
[09:36] <minghua> knights: There is just no space at all.  We are usually 5-10MB over limit before release.
[09:36] <imbrandon> knights, because its not a "lets put everything that will fit" decesion, its more "ok why do we need more than one WM ?"
[09:36] <Fujitsu>  ubuntu-5.10-install-i386.iso         12-Oct-2005 17:25  617M
[09:37] <imbrandon> knights, and it does no good to have a light wm and heavy apps, each deritive is alot more than the wm
[09:38] <knights> GNOME= fully featured, bells and whistles, eats your memory, lightweight (fluxbox or whatever) for if GNOME goes tits up (a rescue option) and/or for improved performance. 2 very good reasons!
[09:38] <elmargol> knights: 1GB ram costs about 20€ now
[09:38] <imbrandon> again your beating a dead horse, if you wish to have more reasons i sugest you look over the ubuntu-devel mailing list
[09:39] <imbrandon> fluxbuntu is for such a case ( as is the livecd you installed with )
[09:39] <knights> elmargol: Doesn't matter how much memory costs
[09:40] <knights> fluxbox etc will perform better than GNOME on a 32TB RAM machine or a 32MB machine
[09:40] <elmargol> i think fluxbox will crash on a 32TB ram machine
[09:40] <imbrandon> knights, great , if thats what your looking for install fluxbuntu ? whats the problem?
[09:41] <knights> I just don't like like the proliferation of *buntus- its unnecessary
[09:41] <imbrandon> in your eyes maybe, thats why i sugested you educate your self
[09:41] <Fujitsu> I just don't like the proliferation of WMs on the Ubuntu CDs - it's unnecessary
[09:41] <imbrandon> anyhow this isnt the place for it
[09:41] <knights> I would love to say- 'just get ubuntu' instead of 'check this flowchart to see which ubuntu is the best for you' or whatever
[09:42] <elmargol> I still think we should have ubuntu core (on a cd) + wm on a second cd/dvd
[09:42] <jpatrick> imbrandon: do you have time for a main merge?
[09:42] <imbrandon> cool but i think your both still missing the point , we can sit here and talk till our faces are blue about it, NOTHING will get done either way, this ISNT THE PLACE
[09:43] <imbrandon> try the ubuntu-devel-* ML
[09:43] <imbrandon> jpatrick, sure
[09:43] <jpatrick> imbrandon: http://revu.tauware.de/details.py?package=kmplayer
[09:43] <knights> The diffeence between the *buntus is the choice of WM mainly, but you can basically choose between heavy (ie KDE or GNOME) or light (fluxbox, e17 or whatever). We should have both on one CD.
[09:44] <knights> ie a Heaby and a light
[09:44] <minghua> This isn't the right place to discuss this.
[09:44] <knights> fluxbox should get integrated into ubuntu and kubuntu
[09:44] <imbrandon> knights, please head what i said
[09:44] <imbrandon> please
[09:44] <knights> sorry guys. rant over
[09:45] <knights> just I was told to come here rather than in #ubuntu to discuss these y'see
[09:45] <imbrandon> ubuntu is alwasy open for ideas http://wiki.ubuntu.com/IdeaPool , specs on LP and the ML, all are great places to start, but NOT here
[09:47] <imbrandon> dget -x http://revu.tauware.de/revu1-incoming/kmplayer-0711031740/kmplayer_0.10.0a-2ubuntu1.dsc
[09:47] <imbrandon> err
[09:47] <jpatrick> in the konsole, yes :)
[09:51] <imbrandon> jpatrick, looks good, doing a quick testbuild then i'll up it, thanks
[09:52] <jpatrick> imbrandon: thank you
[09:52] <imbrandon> np, thanks for the merge
[09:53] <jpatrick> imbrandon: could you do k3b too? http://revu.tauware.de/details.py?package=k3b
[09:54] <imbrandon> jpatrick, yea lemme grab some soda and such and i'll take a look
[09:54] <jpatrick> thanks very much :)
[09:54] <imbrandon> probably be my last one for the night, X has really kicked my butt tonight
[09:54] <imbrandon> np
[09:54] <jpatrick> everyone else is trying to get kde4 to build
[09:54] <imbrandon> heh yea i noticed
[09:55] <imbrandon> tell them all to use the Debian Live KDE4 cd :)
[09:55] <imbrandon> GRRRR
[09:55] <imbrandon> this thing is ftbs on anything but i386
[09:55] <imbrandon> :(
[09:58] <Lutin> ScottK: ok, I'll have a look (regarding MoM/DaD differences)
[09:59] <imbrandon> jpatrick, hahah o wow that was lazy ( leaving the comment insead of the change ) heheh
[10:02] <nand_> yeah!
[10:02] <nand_> I'd like a review of the following upload please : http://revu.tauware.de/details.py?upid=422
[10:03] <nand_> (particulary on the why it suddently doesn't want to upload the source anymore...)
[10:03] <persia> nand_: Are you using `debuild -S -sa`?
[10:04] <nand_> I am using 'debuild -S'
[10:04] <nand_> persia: what is -sa?
[10:04] <persia> nand_: That's why.
[10:04] <nand_> persia: ok thx!
[10:05] <persia> nand_: For REVU, always use -sa.  For preparing a patch, never use -sa.
[10:05] <nand_> persia: ok! Should i reupload right now for you?
[10:05] <persia> nand_: Please
[10:06]  * persia seeks another review request
[10:06] <imbrandon> rember the maintainer must be a ubuntu address too
[10:07] <nand_> imbrandon: I don't have one. what should i put?
[10:07] <persia> nand_: You probably want to set the Maintainer to "Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>", and use XSBC-Original-Maintainer for your name.
[10:07] <imbrandon> ubuntu-motu@lists.ubuntu.com
[10:07] <imbrandon> yup as persia said
[10:07] <nand_> persia: imbrandon: ok
[10:08] <persia> imbrandon: With the lintian runs happening now, the string before the address is suddenly important.
[10:08] <Fujitsu> Yes, or I get annoyed when the reports have 20 different names for MOTU.
[10:08] <imbrandon> hrm , it is ?
[10:08] <minghua> Picky lintian. :-)
[10:09] <persia> minghua: It's hard to sort by maintainer when the spelling of the name keeps changing
[10:09] <minghua> (which reminds me that I should backport Fujitsu's lintian back to my gutsy system)
[10:09] <imbrandon> also its still complaingin about hardy it looks like
[10:10] <minghua> persia: Really?  Doesn't dd-list sort by email?
[10:10] <Fujitsu> minghua: No, it uses name as an index.
[10:10] <Fujitsu> Not email + name, just name.
[10:10] <Fujitsu> I was rather surprised too.
[10:10] <persia> imbrandon: Are you looking at a new upload, or an older one?
[10:10] <imbrandon> i thought a new one, maybe not
[10:11] <minghua> Hmm.
[10:11] <imbrandon> did i install it before  November 03 01:10
[10:11] <imbrandon> ?
[10:17] <persia> imbrandon: My logs aren't ideal, but it looks like about 11 hours ago.  I don't know what that means in comparison to your timestamp.
[10:18] <rexbron> persia: still looking for a revu request?upid 445
[10:18] <persia> rexbron: can't click that :)
[10:18] <rexbron> persia: http://revu.tauware.de/details.py?upid=445
[10:19] <rexbron> This is a completely different, and proably more troublesome package
[10:20]  * persia wonders about the progress of the official lintian backport
[10:22] <persia> rexbron: That's kinda big :)
[10:22] <rexbron> persia: err, I realized there are some errors in the rules file
[10:22] <rexbron> afaik, it works files
[10:22] <rexbron> fine
[10:22] <persia> In openlibraries?
[10:23] <rexbron> it's the dh_shlibsdeps lines
[10:23] <rexbron> should refernece python2.5
[10:23] <rexbron> or better yet, a variable
[10:23] <persia> rexbron: Quick  Upload another rev :)
[10:24] <rexbron> brb
[10:25]  * nand_ enters a electromagnetic cloud, perturbing uploading wifi waves.
[10:26] <imbrandon> persia, just waiting on ubuntu-archive to do their thing ( 2 times a week iirc ) Bug #159911
[10:26] <ubotu> Launchpad bug 159911 in gutsy-backports "backport lintian" [Undecided,In progress] https://launchpad.net/bugs/159911
[10:27] <persia> imbrandon: Thanks.  This session will be a little bumpy, but we should be good for next week.
[10:28] <rexbron> How often are revu days going to happen?
[10:28] <imbrandon> bout once a week
[10:28] <rexbron> That is a very nice thing to read
[10:29] <persia> rexbron: That only applies until Feature Freeze.  At that point, REVU gets quiet again.
[10:29] <rexbron> That is fine
[10:29] <rexbron> It is just really nice to see attention being given to new uploaders
[10:30] <rexbron> more so than before
[10:31] <persia> rexbron: Not really.  We had about 15 sessions for Gutsy as well.
[10:31] <rexbron> oh, guess I missed all of them
[10:31] <rexbron> I was not active at all that release
[10:38]  * rexbron is so glad he as a c2d and 2gigs of ram. Makes these compiles fly
[10:40]  * persia wants an updated linda, with support for the new menu hierarchy
[10:45]  * nand_ leaves the electromagnetic clould.
[10:45] <nand_> persia: here you are : http://revu.tauware.de/details.py?package=ike
[10:46] <persia> Uploaders: Please announce your uploads generally.  Targeting specific MOTUs will only slow down your reviews, and get you less comments
[10:46] <persia> nand_: Thanks.
[10:46] <persia> imbrandon: http://revu.tauware.de/revu1-incoming/ike-0711041320/lintian (so it does work)
[10:47] <imbrandon> persia, great
[10:47] <persia> imbrandon: Thanks again for backporting that so quickly
[10:48] <imbrandon> hrm the more and more i look at it why do we NOT use OpenVZ for the PPA's ( even the x86{,_64} ones ?
[10:48] <imbrandon> persia, np
[10:48] <imbrandon> it would give us PPC and Sparc PPA's also
[10:49] <persia> imbrandon: How slow is PPC/Sparc emulation (or am I misunderstanding)
[10:49] <imbrandon> no OpenVZ would run on the actual hardware just like xen on i386
[10:49] <imbrandon> no emulation
[10:50] <persia> imbrandon: Then, I'm still confused.  From where do we source the hardware, or does PPA just wait for the regular buildds to finish?
[10:50] <imbrandon> basicly OpenVZ is OS Virtualization ( e.g. all guest os's still need to be linux , just not the SAME linux ), whereas xen is paravirtualization
[10:51] <persia> nand_: FTBFS for me :(
[10:51] <imbrandon> persia, the reason PPA's arent on PPC and sparc now is xen dosent run on those archs
[10:51] <nand_> persia: FTBFS?
[10:51] <imbrandon> thats the only reason
[10:51] <ajmitch> imbrandon: security, OpenVZ has far less separation, and it was considered & dismissed as a possibility for PPAs
[10:51] <persia> Fail To Build From Source
[10:51] <imbrandon> ajmitch, ?
[10:52] <nand_> persia: ah. Damn. I have checked with pbuilder though... I check again.
[10:52] <imbrandon> from what i can see openvs has more seperation
[10:52] <imbrandon> vz*
[10:52] <ajmitch> everything running under 1 kernel?
[10:52] <persia> nand_: Might be an architecture-specific thing.  Let me know if you want a buildlog
[10:53] <nand_> persia: I'd like please.
[10:53] <imbrandon> ajmitch, proc sys etc are all still virtualized though, xen in very similar in that respect, it still has one main dom kernel
[10:54] <ajmitch> yes, 1 dom0, but accessed through the hypervisor
[10:54] <ajmitch> anyway, I'm only on to check mail before bed
[10:54] <ajmitch> good night
[10:54] <imbrandon> gnight
[10:54] <Fujitsu> Night ajmitch.
[10:55] <Fujitsu> imbrandon: Xen domUs have their own kernel, so are a lot more seperated.
[10:55] <persia> nand_: http://paste.ubuntu-nl.org/43236/
[10:56] <nand_> persia: thanks.
[10:56] <imbrandon> Fujitsu, ok and the loss vs the gain from that is ?
[10:56] <Fujitsu> imbrandon: A kernel exploit in Xen can probably not escalate to the dom0.
[10:56] <imbrandon> e.g you loose all non x86 arches and gain what? rember there is no shells this is a buildd
[10:57] <Fujitsu> imbrandon: Remember that anybody can upload arbitrary code to it.
[10:57] <imbrandon> sure and be tracked as long as they have become an unbuntuero and everythng else
[10:57] <nand_> persia: oh I know. Stupid thing. I have a empty file (which used to contains some overrides) and it was not grabbed by the diff.
[10:58] <persia> imbrandon: It's trivial to do that anonymously.
[10:58] <Fujitsu> imbrandon: Be tracked? riiight.
[10:58] <persia> nand_: Yep.
[10:58] <nand_> persia: I update quickly.
[10:58] <Fujitsu> I can generate a key and (once PPA is out of beta) upload hostile code in a matter of seconds.
[10:58] <persia> nand_: Don't be so quick as to not test the build.
[10:58] <persia> Fujitsu: Even in beta, it's only a couple days
[10:59] <Fujitsu> persia: They want a real name, but that's also trivial to fake, I guess.
[10:59] <persia> Fujitsu: Some Person's real name.
[10:59] <Fujitsu> Yeah.
[10:59] <imbrandon> ok sure but i dont see OpenVZ as being any less secure than xen at all in the real world, look how many commercial hosts there are on OpenVZ compared to Xen
[11:00] <persia> Hi.  My Name is Grant William Johnson.  I'll be your guest speaker tonight on the value of the Web-of-Trust, and we'll have a keysigning later.
[11:00] <Fujitsu> Security in PPA is absolutely critical. At least ~ubuntu-dev is vaguely trusted, and the people are known.
[11:00] <Fujitsu> persia: Haha.
[11:00] <Fujitsu> imbrandon: I trust the Canonical sysadmins.
[11:00] <Fujitsu> They really do know what they are doing.
[11:01] <imbrandon> yea but i was there for the disscussions it wasent even brought up, i trust no one blindly
[11:01] <Fujitsu> (I can imagine that some hosts probably use OpenVZ because it doesn't require static memory sizing)
[11:01] <imbrandon> xen was the first sugestion and it was run with
[11:02] <imbrandon> Fujitsu, nah most use it because of its proven track record vs a new tech like xen
[11:06] <persia> Umm.  Just in case the uploaders are around, I've updated apt-mark-sync, livemix, and easycrypt.
[11:07] <persia> Reviewers: if you complete a review, please announce it so that the uploader may respond.  If you advocate a package, please ask for a second advocate.
[11:09] <persia> imbrandon: Any ideas why I might get a 403 on http://revu.tauware.de/revu1-incoming/emelfm2-0711041320/emelfm2-0.3.5/COPYING ?
[11:10] <imbrandon> persia, strange , umm no
[11:10] <persia> imbrandon: Does it work for you?
[11:10] <imbrandon> no 403 here also
[11:10] <persia> Interesting...
[11:10] <Fujitsu> You should be able to ssh in a poke around.
[11:10] <imbrandon> i know .changes are set that way
[11:10] <imbrandon> ...
[11:11] <Fujitsu> *and
[11:11]  * rexbron really needs to beter understand why some varible substition work in rules files and other don't
[11:11]  * Fujitsu is tired, apparently.
[11:11] <persia> .changes I can understand, especially if someone in ubuntu-dev is using REVU, but without reviewing COPYING, it's a little tricky...
[11:11] <imbrandon> hehe me also, its time for bed, gnight all ( persia you should have ssh access to poke it if you like , just probably not sudo )
[11:11] <persia> rexbron: Remember that you're dealing with make variables.
[11:12] <geser> persia: COPYING is a symlink inside the orig.tar.gz
[11:12] <persia> imbrandon: It's been broken forever, but I can download the tar.gz.  Have a good night.
[11:12] <imbrandon> persia, ssh access == <lp-id>@sparky.ubuntuwire.com , using the keys on LP
[11:12] <imbrandon> ok gnight
[11:12] <Fujitsu> imbrandon: Isn't it like 6am?
[11:12] <imbrandon> yea 615
[11:12] <persia> geser: Ah.  That's it then.  Still, I'd think REVU would follow symlinks as long as they didn't point to the parent.
[11:13] <Kopfgeldjaeger> does any MOTU have time to check if my package is ready for multiverse? norsetto had a look at it some time ago
[11:13] <geser> persia: lrwxrwxrwx 1 michael michael    8 2007-11-04 12:13 COPYING -> docs/GPL
[11:13] <persia> imbrandon: "Permission denied (publickey).".  There's something odd about my home directory on sparky.  We'll look at it another time.
[11:13] <geser> the same for INSTALL, README and WARNING
[11:14] <persia> Kopfgeldjaeger: It's REVU day.  Announce your package URL, and the current status, and someone will take a look.
[11:14] <Kopfgeldjaeger> persia: cool, i didnt know that :)
[11:14] <Kopfgeldjaeger> the revu link: http://revu.tauware.de/details.py?package=avidemux
[11:15] <persia> Kopfgeldjaeger: It's in the /topic (always a good read)
[11:15] <Kmos> Please someone look at http://revu.tauware.de/details.py?upid=364 (Package: tennix)
[11:16] <jpatrick> Kopfgeldjaeger: could you remove the debian/ dir from avidemux src?
[11:16] <Kopfgeldjaeger> jpatrick: no
[11:16] <Kopfgeldjaeger> jpatrick: its in upstream
[11:16] <jpatrick> Kopfgeldjaeger: yes, inform them and remove it
[11:17] <Kmos> bug 149847
[11:17] <ubotu> Launchpad bug 149847 in ubuntu "[hardy]  [needs-packaging] Tennix 0.4.1" [Wishlist,In progress] https://launchpad.net/bugs/149847
[11:17] <Kopfgeldjaeger> jpatrick: i shall change upstream sources?
[11:17] <Kmos> startupmanager 1.9.8 hits debian archive today =)
[11:18] <jpatrick> Kopfgeldjaeger: https://wiki.kubuntu.org/MOTU/FAQ
[11:18] <jpatrick> ^point 2.5
[11:19] <persia> Kmos: From where is that tennix sourced?  The updates you made to Debian games svn are certainly not suitable.
[11:19] <Kopfgeldjaeger> yeah, i see... ok
[11:19] <geser> Kmos: have you submitted tennix also to Debian?
[11:20] <persia> geser: Debian has reverted Kmos's changes to tennix
[11:20] <Kmos> geser: yes.. to mentors, but anyone looks at it
[11:20] <Kmos> persia: i've submitted package tennix to debian games
[11:20] <persia> Kmos: Yes.  I know.
[11:21] <jpatrick> Kopfgeldjaeger: personally I rm the debian dir, retar and note in changelog
[11:21] <persia> Kmos: Is this a different tennix package, or the one you preiously submitted?
[11:21] <Kmos> persia: that's with my changes =) don't know what debian games changed their
[11:21] <persia> jpatrick: Actually, one is required to note that in debian/copyright, and provide an automated way to repack.  Otherwise it's not trusted (can't match upstream md5sum)
[11:21] <Kmos> i've it at mentors
[11:22] <persia> Kmos: Right.  I'll archive it then.  Thanks.
[11:22] <Hobbsee> persia: do you know if they've done a full reversion of everything?
[11:22] <jpatrick> persia: hmm, that's how I was told to do it :|
[11:22] <Kopfgeldjaeger> jpatrick: whats the best way to do this for me? i have a avidemux-2.4.orig folder above my working avidemux directory, how can i change the name of the source package being built?
[11:22] <persia> Hobbsee: Nobody is that motivated.  It's on a package by package basis when reviewing them for upload.
[11:22] <Hobbsee> ahh
[11:22] <Kmos> Hobbsee: no, they don't.. u're so interested..
[11:23] <Hobbsee> i hope kibi looks at pingus, and reverts anything needed, because i actually care about that one :)
[11:23] <geser> Kmos: why not get it into Debian and then sync to Ubuntu?
[11:23] <Kmos> geser: because I'm not part of debian games now
[11:23] <Hobbsee> geser: debian took away his svn commit rights.
[11:23] <persia> jpatrick: Policy changed about 6 months back, which may have something to do with the confusion (either in your mind, or the mind of the person providing you with guidance)
[11:23] <Hobbsee> Kmos: you know, you really should answer to their emails, too.
[11:23] <Kmos> so i'll remove it from mentors
[11:23] <geser> Hobbsee: ah
[11:23] <jpatrick> persia: ok, noted
[11:24] <Kmos> Hobbsee: i've made the latest patch for pingus 0.7.2 to put it working.. check changelog
[11:24] <Hobbsee> Kmos: did you test it?
[11:24] <Kmos> Hobbsee: sure
[11:24] <Kmos> =)
[11:24] <Hobbsee> Kmos: as well as all the rest of them?
[11:24] <Kmos> Hobbsee: i also release it at getdeb.net
[11:25] <persia> bddebian has a pingus in mentors closing most of the Ubuntu bugs, prepped for a sync.  Do we want to introduce more variation?
[11:25] <jpatrick> Hobbsee: could you upload a main merge for me?
[11:25] <Hobbsee> Kmos: that *doesnt* answer my question.  it's rude to sidestep questions, and to not answer to emails, you know...
[11:26] <imbrandon> jpatrick, i did the 2 you asked about btw
[11:26] <jpatrick> imbrandon: yes, I saw that, thanks again :)
[11:26] <Hobbsee> jpatrick: depending on what it is, yes
[11:26] <jpatrick> now I'm trying to get k3b-i18n in
[11:26] <Kmos> Hobbsee: first e-mail's I'm not subscribed to their ML
[11:26] <jpatrick> Hobbsee: http://revu.tauware.de/details.py?package=k3b-i18n
[11:27] <Hobbsee> Kmos: and the rest?
[11:27] <Kmos> Hobbsee: some of them i answered directly by IRC to rhonda
[11:29] <Hobbsee> Kmos: ah, so you didn't feel it was necessary to explain to the rest of the team as well, who were affected by your uplaods
[11:29] <Hobbsee> and ubuntu, by flow-on effect.
[11:29] <Kmos> Hobbsee: i need to do it, i haven't time yet
[11:30] <Kopfgeldjaeger> jpatrick: do you how to do that?
[11:30] <Hobbsee> Kmos: yet all this time to be on irc and do packages :)
[11:30] <Hobbsee> Kmos: have you realised that some of the reluctance to sponsor your changes might be due to waiting to see what you say, in regards to the mails?
[11:31] <jpatrick> Kopfgeldjaeger: rename the .orig.tar.gz to repackaged1.tar.gz?
[11:31] <Hobbsee> jpatrick: ew, i dont really want to touch that :)
[11:31] <Kopfgeldjaeger> jpatrick: ah, ok, that's a cool solution :)
[11:31]  * Hobbsee knows nothing of localisations
[11:31] <Kmos> Hobbsee: yeah, maybe.. but I've other personal things to do.. I'll answer it
[11:31]  * jpatrick neither but... it's a merge :D
[11:32] <Kmos> Hobbsee: discuss this at debian irc =)
[11:32] <jpatrick> imbrandon: it's pity, a few minutes after k3b went in, it entered Debian too :(
[11:32] <jpatrick> Kopfgeldjaeger: what it says on the wiki faq
[11:33] <geser> Kmos: how can you have the copyright on the Debian packaging when then package was debianized by someone else?
[11:33] <Kopfgeldjaeger> jpatrick: argh, sorry, then read over that
[11:33] <Kopfgeldjaeger> *then i
[11:34] <Kopfgeldjaeger> or misunderstood renaming
[11:34] <Kmos> geser: it was first debianized, and after I fixed a lot of things to put it working.. I think it was done firstly by the author
[11:34] <Hobbsee> Kmos: and since when does that give you permission to hijack the copyright?
[11:35] <Kmos> Hobbsee: in the top it was thomas perl
[11:35] <Kmos> in the bottom it's me
[11:35] <Kmos> This package was debianized by Thomas Perl <thp@perli.net> on
[11:35] <Kmos> Sat, 08 Sep 2007 18:00:18 +0200.
[11:35] <Kmos> ---
[11:35] <Kmos> The Debian packaging is (C) 2007, Marco Rodrigues <gothicx@sapo.pt> and
[11:35] <Kmos> is licensed under the GPL, see above.
[11:35] <Kmos> it's hijack ?
[11:39] <Kmos> the tennix package at debian games wasn't reverted.. it's the same when I touch it
[11:39] <nand__> persia: Ok i have checked everything. It should be fine.
[11:39] <Hobbsee> if not, it's certainly unclear.  seeing as the debianization means doing the debian packaging.
[11:40] <persia> Kmos: Well, it's been claimed as intended to be reverted.  Perhaps the person working on it isn't done trying to clean it up yet.
[11:40] <persia> nand__: Great.  Make another annoucement :)
[11:40] <Kmos> ah ok
[11:40] <Kmos> Hobbsee: i'll ask to change it
[11:41] <nand__> I request a review of the following package please : http://revu.tauware.de/details.py?package=ike
[11:42]  * Hobbsee pokes firefox
[11:42] <Hobbsee> if i want to open *.diff in firefox, what command do i need to give it?
[11:42] <Hobbsee> for some reason, it wants to ask me every timne
[11:42] <Fujitsu> Hobbsee: kate, I suppose?
[11:43] <Fujitsu> Or gedit if you're still using the abominable GNOME.
[11:43] <Hobbsee> Fujitsu: no, i want the diff actually open *in* firefox.
[11:43] <Hobbsee> like, in another tab of it
[11:43] <Fujitsu> Ah.
[11:43]  * Fujitsu isn't sure it'll like doing that.
[11:43] <Fujitsu> Try entering firefox?
[11:43] <Fujitsu> Or will it then do it again?
[11:45] <Hobbsee> Fujitsu: yeah, it does it again
[11:45] <Hobbsee> it used to do it
[11:45] <Fujitsu> Hah.
[11:45] <Hobbsee> i'm not sure if something's borked.
[11:45] <Hobbsee> hm, something's eaten my akregator settings, too
[11:46]  * Hobbsee restarts X, to see if it still starts
[11:51]  * Fujitsu takes that as a no.
[11:52] <nand__> ^^
[11:54] <persia> emelfm2 commented
[11:56] <persia> DktrKranz: About bug #103481: Does hardy need something to handle Dapper -> Hardy upgrades?
[11:56] <ubotu> Launchpad bug 103481 in strigi "[SRU] upgrade from edgy causes file overwrite error" [Undecided,Confirmed] https://launchpad.net/bugs/103481
[11:58] <rexbron> Hey everyone! Openlibraries is now up for review. http://revu.tauware.de/details.py?package=openlibraries
[11:58] <DktrKranz> persia, didn't check. I do it now
[11:58] <persia> DktrKranz: Thanks.
[11:58] <Fujitsu> Hobbsee: It didn't?
[11:59]  * persia wonders if Edgy -> Gutsy upgrades are supported
[11:59] <Fujitsu> persia: Erm, no.
[11:59] <persia> Fujitsu: Excellent.  That makes it easier.  Thanks.
[12:00] <Hobbsee> damn
[12:00] <Hobbsee> it doesnt
[12:00] <Fujitsu> Hobbsee: Mine did after I reinstalled everything... what went wrong?
[12:00] <Hobbsee> only had -intel and -synaptics.  not -keyboard, -vesa, or mouse :)
[12:01] <Fujitsu> Ah.
[12:01] <Hobbsee> which..sucks
[12:01] <Hobbsee> and it's eaten part of my akregator data.
[12:02] <Fujitsu> Oh, fun.
[12:03] <rexbron> persia: did you see my anouncement?
[12:03] <DktrKranz> persia, strigi package is available since edgy, dapper does not ship it
[12:04] <persia> DktrKranz: Excellent.  So we only have to fix it for feisty.  Thanks for the investigation.
[12:05] <DktrKranz> persia, since strigi is in main since gutsy (IIRC), can a MOTU upload to feisty?
[12:05] <DktrKranz> *feisty-proposed
[12:06] <persia> DktrKranz: Hrm.  I have no idea.  Unfortunately, my feisty chroot was eaten recently, so I'm also not in a good position to find out.
[12:06] <Hobbsee> oh dear.
[12:06] <Hobbsee> has it really been so long that i've forgotten how to chroot?
[12:06] <Fujitsu> Hobbsee: sudo chroot /path/to/mount?
[12:06] <DktrKranz> I have chroots and VM, so I can test almost every fix :)
[12:06] <Hobbsee> sarah@LongPointyStick:~/Desktop$ sudo chroot /media/develrelease/
[12:06] <Hobbsee> chroot: cannot run command `/bin/bash': No such file or directory
[12:06] <Fujitsu> Hobbsee: Wrong filesystem.
[12:06] <Hobbsee> oh!
[12:07] <persia> DktrKranz: I'm convinced of that, and I'm convinced it's the right fix, I'm just not allowed to upload without testing :)
[12:07] <DktrKranz> you do right
[12:08] <DktrKranz> but if you have questions on how to reproduce, I can easily point you to
[12:09] <persia> DktrKranz: No, the issue is that I need to go shopping for more disks, or decide to delete lots of stuff.
[12:09] <Nafallo> persia: order online :-)
[12:10] <persia> Nafallo: Cheaper in the back alleys of akihabara
[12:10]  * Nafallo blinks
[12:10]  * DktrKranz is living with a 40gb HDD only
[12:11] <persia> DktrKranz: And enough chroots to get back to Dapper?  That's impressive.
[12:12] <DktrKranz> keep in mind I do not install too many software, Default setup provides me what I need (except development tools)
[12:12] <persia> nand_: Is that a copyleft license?  I'm sure it's free, but it's a new one for me (ike)
[12:12] <DktrKranz> and I use the rest to run VM and chroots. Boring :)
[12:13] <persia> DktrKranz: Ah.  That would be it.  I have an unfortunate tendency to play games (with the associated megabytes of data)
[12:13] <Hobbsee> Fujitsu: so X still falls over if you nuke mesa.
[12:14] <Fujitsu> Hobbsee: The only stuff I touched was xserver-*.. what else did you kill?
[12:14] <persia> Shouldn't it?  I thought that none of the drivers had a complete implementation.
[12:14] <Hobbsee> Fujitsu: vesa is part of xserver-*
[12:14] <rexbron> persia: I am going to scrap the get-orig-source rule for genpo as I can not get it to work
[12:14] <Fujitsu> Hobbsee: Erm, you said mesa.
[12:15] <Hobbsee> ah. meant vesa, sorry
[12:15]  * Hobbsee tries to reboot to X
[12:15] <persia> rexbron: OK.  You'll get whining on REVU, but maybe someone can create one for you (this channel is a good place to ask for help)
[12:15] <Fujitsu> Heh, so close, and both very X-related.'
[12:15] <persia> less copyright
[12:15] <persia> Err..
[12:19] <rexbron> :)
[12:19] <rexbron> "Computer..." </startrek>
[12:20] <persia> rexbron: Maybe, but having a useful eye tracker combined with focus-follows-mouse would make me happier.
[12:20] <persia> (keystrokes go where I'm looking)
[12:20] <Fujitsu> Working better, Hobbsee?
[12:20] <rexbron> persia: that is actually a reall cool idea
[12:21]  * rexbron is not sure how it would work in FPS's though
[12:22] <Hobbsee> right.
[12:22] <Hobbsee> yup
[12:22] <Fujitsu> Hobbsee: So removing -vesa is a no-no? I almost didn't reinstall it when I redid mine.
[12:26] <rexbron> Are reviewer's going to anounce when they look at a package?
[12:26] <Hobbsee> Fujitsu: well, if your intel fails.
[12:26] <Hobbsee> Fujitsu: i think it really died over the fac that it couldnt load the mouse or keyboard
[12:26] <Hobbsee> although it loaded the touchpad
[12:27] <persia> ike commented
[12:27] <Fujitsu> Ah, yeah.
[12:28]  * rexbron does not want to spam but...
[12:28] <rexbron> Openlibraries is now up for review. http://revu.tauware.de/details.py?package=openlibrariesOpenlibraries is now up for review. http://revu.tauware.de/details.py?package=openlibraries
[12:28] <rexbron> err
[12:28] <rexbron> damn
[12:29] <persia> rexbron: You just advertised that.  Have you uploaded again (rather, do I need to download again)?
[12:29] <rexbron> persia: I recived no indication that it had been/ was going to be looked at
[12:30] <persia> rexbron: That's normal.  Eventually, someone should say they reviewed it.  Sometimes they forget.  Asking lots of times doesn't help much, although if you haven't heard anything and there aren't any comments in 3 or 4 hours, it might be worth mentioning it again, just because people are in different timezones.
[12:31] <rexbron> srue
[12:31]  * persia notes that the above rules only apply during REVU days.  3-4 hours is far too often if it's not REVU day
[12:34] <rexbron> Genpo is up for review. http://revu.tauware.de/details.py?package=genpo
[12:36] <nand_> persia: I don't really know about licensing. This one, "sleepy cat", is new to me too :) I have just checked it was OSI approved.
[12:37] <persia> nand_: No worries.  Because you licensed the packaging as GPL, it's nice to make sure that it is GPL compatible from the FSF site as well (it is).
[12:40] <nand_> can someone tell me about what is a "watch" file?
[12:44] <cyberix> Is there a REVU day coming soon?
[12:45] <nand_> cyberix: right now!
[12:46] <cyberix> wow
[12:46] <cyberix> So I'm looking for first sponsor for my pq package. I have fixed all problems that have been brought up. http://revu.tauware.de/details.py?package=pq
[12:50] <cyberix> persia: Going to rereview my pq packet now? http://revu.tauware.de/details.py?package=pq
[12:52] <cyberix> I fixed the lintian and linda problems that came up with those switches.
[12:52] <cyberix> And I'm also using debhelper for almos everything now
[12:52] <persia> cyberix: It's REVU day.  You'd do best to advertise your package for anyone to review.  It might be me, but I'm in the middle of another review right now.  Also, be warned that there's a new lintian, which will add more :)
[12:53] <cyberix> persia: I did, while you was away for 1 minute
[12:53] <cyberix> five minutes ago
[12:53] <Fujitsu> Indeed, a second after you quit.
[12:53] <persia> cyberix: Ah.  Excellent then.  Sorry for the complaint :)
[12:54]  * persia thinks Fujitsu would be an excellent reviewer
[12:54]  * Fujitsu thinks he is studying for a final maths exam tomorrow.
[12:54]  * persia revises thoughts
[12:54] <Fujitsu> So I have an excuse, nyahaha.
[12:55] <cyberix> Fujitsu: However irc is not that exact.
[12:56] <persia> cyberix: You forget: Fujitsu has the reference clock, against which all of us lag
[12:56] <cyberix> He is a Freenode admin?
[12:57] <cyberix> Ok. I give up.
[12:57] <persia> No, the master clock.  Even admins lag :)
[12:58] <Hobbsee> persia: nz is still ahead.
[12:59] <persia> Hobbsee: Yeah, well.  So's Kiribati (my reference point for starting REVU day).
[12:59] <Hobbsee> ahhh
[13:00] <persia> Amusingly enough, in the pacific, you can actually travel west and have to set the clocks forward.
[13:05] <Hobbsee> er, shit.
[13:05] <persia> !ohmy
[13:05] <ubotu> Please watch your language and topic, and keep this channel family friendly.
[13:05] <Hobbsee> now, if i were a usb drive, wher would i be?
[13:06] <persia> Hobbsee: /dev/sdX
[13:06] <persia> And maybe mounted in /media
[13:06] <Hobbsee> no, no.  physically
[13:06] <Hobbsee> ah, here it si.  i *didn't* put it thru the wash.
[13:06] <Hobbsee> with my very important physics data for this lab report :)
[13:06] <Fujitsu> Hobbsee: Mine has been through the wash on multiple occasions and survived.
[13:06]  * persia dreams of REVU preserving cookies
[13:07] <Hobbsee> Fujitsu: yeah, but i'd prefer nto to risk it, as i told the physics people that i'd done the report (done around half, actually), and it would look mighty silly to have to ask for access to my data again, when i'm supposed to have already handed in said report.
[13:07] <Fujitsu> Ah.
[13:08] <ion_> Keep this channel friendly to people who never defecetate and find the act distasteful.
[13:09] <Hobbsee> persia: yeah, i do too.  for some reasons, my hopes never turn to reality :(
[13:09] <persia> Hobbsee: One of us could learn python ...
[13:09] <zul> my wife has kept alot of things in her pockets during the wash, usb sticks, coins, candles, lighter...
[13:10] <Fujitsu> persia, Hobbsee: Isn't it just a matter of changing the cookie expiry time from 0?
[13:10]  * Fujitsu looks at the code.
[13:10]  * persia cheers Fujitsu's masterful powers of procrastination
[13:11]  * Fujitsu just finished a practice exam, so is having a bit of a break. THen perhaps sleeping.
[13:11] <Hobbsee> persia: yeah.  after the 2 assignments that were supposed to be done last week :)
[13:11] <Fujitsu> Though I am truly the master of procrastination.
[13:11] <Hobbsee> no you're not.
[13:12] <Fujitsu> Oh, I am.
[13:13] <persia> No competition now.  You can both be masters.  I've successfully deferred things for decades, so I encourage a spirit of support and encouragement.
[13:13] <Fujitsu> Heh.
[13:14] <Fujitsu> Oh, I see, it uses mod_python's Session... the cookie is set to last for 12 hours, does that sound right?
[13:15] <Hobbsee> haha
[13:15] <Hobbsee> okay, i should revise that - i procrastinate on stuff i dont want to do :P
[13:15] <persia> Fujitsu: It always kills me, even when I just crash and reboot for a few minutes (where is the new broken kernel to go with the broken X: I want a stable system again)
[13:16] <Fujitsu> Ah...
[13:16] <Fujitsu> Hmm.
[13:19] <cyberix> How does software appear in Add/Remove?
[13:20] <Fujitsu> cyberix: It provides a .desktop file, and gets picked up by a script that mvo runs regularly.
[13:21] <persia> openlibraries commented
[13:22] <rexbron> persia: you know how I was asking about how to remove a directory recursivly (in my case to get rid of .svn)? I wrote a python script to do it (but i am sure that someone else had already made something, I just could not find it)
[13:23] <persia> rexbron: There's lots of them, but I suspect you'll get greater benefit from the "svn export" command, unless you have a particularly annoying or incompetant upstream.
[13:23] <cyberix> mvo?
[13:23] <persia> cyberix: The person who manages Add/Remove, and runs the inclusion script.
[13:23] <cyberix> oh
[13:24] <cyberix> So he has a monopoly of choosing the packages?
[13:24] <persia> cyberix: They aren't chosen.  Anything that provides a valid .desktop file gets included.
[13:24]  * Hobbsee would assume teh script does
[13:26] <rexbron> persia: Thanks for the comments, but would I need to then list svn as a build-dep for the package
[13:26] <rexbron> for the get-orig-source rule?
[13:26] <persia> rexbron: No.  get-orig-source can depend on whatever it wants, as long as it's available in the regular repositories.
[13:27] <rexbron> ok
[13:27] <persia> (it's only ever called manually, either by maintainers or paranoid users)
[13:27] <rexbron> lol
[13:28] <rexbron> persia: more clarifcation, should the get-orig-source rule just export the svn check out or should it package it up into a tarball?
[13:28] <persia> rexbron: It's not all funny.  Pity the poor sysadmins who have to trace the cryptographic history of everything before installing it on their corporate systems, just because some intern thought it was a good idea when helping to draft some policies.
[13:28] <rexbron> O.o
[13:28] <rexbron> That sounds like personal experience
[13:29] <persia> rexbron: get-orig-source should produce an orig.tar.gz which matches the orig.tar.gz used to build the package.
[13:29]  * Fujitsu pokes through mod_pythons internals.
[13:30] <Fujitsu> It seems that the specified timeout isn't actually used client-side - the cookie always expires at the end of the browser session.
[13:30] <rexbron> persia: but in this case, it is an svn checkout, so would it be acceptable to pull the lastest svn?
[13:31] <persia> rexbron: Ideally, you'll know which revision you are packaging, and pull that revision.
[13:31] <Fujitsu> IIRC, I've seen some packages with a variable in debian/rules specifying the revision.
[13:31]  * rexbron has had issues with variable in debian rules not behaving
[13:32]  * cyberix hopes his desktop file is valid enought
[13:32] <cyberix> Atleast it works
[13:32] <persia> I've also seen packages that play with the changelog version to get a date, and pass the date to SVN
[13:32] <Fujitsu> cyberix: Run desktop-file-validate over it?
[13:32] <persia> cyberix: It's not.  Try desktop-file-validate
[13:32] <Fujitsu> Do we attempt to inforce HIG-compliance of .desktops?
[13:33] <Fujitsu> *enforce, damnit.
[13:34] <persia> Fujitsu: Yes, but we don't like to maintain .desktop patches enough to not push upstream and to Debian.  Consider us to be likely to complain, rather than likely to fix it (although new contributors often do)
[13:34] <Fujitsu> Right, I meant only those we already carry a delta for. Good.
[13:34] <rexbron> persia: re 5), the reason there is a hard dependancy in a python version is due to libboot-python only being available on one version of python (2.5). Is there somewhere I can document that reason?
[13:35] <cyberix> Any flags?
[13:35] <persia> rexbron: I don't know of one, but python-support has a handy mechanism to force the version without you needing to put it all over the rules file.  That way when libboost-python transitions to 2.6, it's easier to transition the package.
[13:35] <persia> cyberix: no
[13:36] <persia> cyberix: More verbosely, it's at maximum verbosity by default.
[13:37] <persia> pq commented.  Everything *must* be built from source.
[13:38] <rexbron> persia: I will look into it
[13:39] <persia> rexbron: If you can't find a solution, having the references to 2.5 won't block advocation - it's the other things that really need help.
[13:40] <rexbron> persia: again, if libboost-python was build for all supported versions of python, then this would be less of a problem
[13:41] <rexbron> also re 1) I though that --disable-rpath in the configure script was taking care of that
[13:41] <persia> rexbron: Yes, but libboost-python has internal issues that make that difficult.  I've tried, as have others, and it's just not something that works sanely.
[13:41] <persia> rexbron: It may be supposed to be doing that, but it's not working :(
[13:43] <joejaxx> imbrandon: how did the Xvesa stuff go?
[13:44] <deadwill> yo!
[13:45] <cyberix> Does the order of entries in desktop-file matter?
[13:46] <persia> cyberix: No, but convention is to have the Name near the top, and Categories near the bottom.
[13:46] <cyberix> persia: Building from source might be a bit hard because the software is freeware and I'm targetting it for Multiverse.
[13:47] <jpatrick> can someone explain to me how a package FTBFS with "dh_iconcache: Command not found" when debhelper is in the build deps?
[13:47] <Fujitsu> jpatrick: That's in Ubuntu? Or Debian?
[13:47] <cyberix> persia: An upstream change log is also not available under a free license
[13:47] <jpatrick> Fujitsu: ubuntu
[13:47] <persia> cyberix: If the source is open, you should be able to build it.  If the source is closed, it's not a good candidate for multiverse (that's restricted, and restricted is not open to new software without an approved spec)
[13:48] <StevenK> jpatrick: Change it to dh_icons
[13:48] <persia> jpatrick: dh_iconcache is deprecated.
[13:48] <jpatrick> it is done by cdbs tho...
[13:48] <cyberix> persia: Wow. Never realized software in Multiverse needs to have source available.
[13:48] <persia> StevenK: Did you still want a log?  I think you were around for all the good bits.  Also, do you want a bug about using the new menu hierarchy?
[13:49] <StevenK> persia: I'll read the log at some point, thanks. Um, bug for which package?
[13:49] <persia> jpatrick: If CDBS is using dh_iconcache, that's a bug in CDBS.  A patch would likely be very welcome.
[13:49] <persia> StevenK: linda
[13:49] <persia> (to check)
[13:49] <cyberix> persia: This implicates that there are packages in Debian non-free that aren't qualified for UBuntu at all.
[13:49] <StevenK> persia: Please
[13:49] <cyberix> right?
[13:49] <jpatrick> persia: it's cos all my knight builds failed because of that
[13:49] <persia> StevenK: OK.  I'll dig through lintian a bit, and send something to the BTS
[13:50] <StevenK> persia: Works for me, thanks
[13:50] <persia> cyberix: Can you give me an example?
[13:51] <Fujitsu> Building from source isn't a requirement for multiverse.
[13:51] <Fujitsu> Things like vmware-player and acroread didn't.
[13:51] <Fujitsu> But they were fairly important.
[13:51] <persia> Fujitsu: No?  We'd ship a .exe file without source?
[13:52] <Fujitsu> persia: Can you see Adobe distributing acroread's source?
[13:52] <persia> Fujitsu: Hrm.  Good point.  I'm confused then: I thought that everything was supposed to be built, rather than precompiled and put in multiverse.  Oh well.
[13:53] <Fujitsu> The only requirement for multiverse is, as far as I know, redistributability. However, I would be very disinclined to include further non-free binary-only sources unless they're very important to users.
[13:53] <Fujitsu> s/sources/software/
[13:53] <cyberix> Fujitsu: Is there a policy document about this somewhere?
[13:54] <Fujitsu> cyberix: I don't think it is defined properly anywhere public, no.
[13:54]  * persia isn't sure it's defined properly anywhere private either
[13:54] <cyberix> If it really isn't ok, I could go for Medibuntu, but I just don't want to be unlucky while other non-free nonessential packages are taken to Multiverse.
[13:54] <Fujitsu> persia: The archive admins probably have a secret document.
[13:55] <persia> Fujitsu: Hmmm....  I thought they operated by mind-meld consensus, but you may be right.
[13:55] <Fujitsu> cyberix: Do you have example of something that isn't from Debian and isn't rather important, but is binary-only?
[13:55] <Fujitsu> I seem to be losing articles... I must head off to bed shortly.
[13:56] <persia> cyberix: Most of the non-free nonessential stuff that goes into multiverse is at least sourceful, if non-free.  I still think Wine-doors is the solution to this specific issue.
[13:56] <cyberix> Not without searching
[13:56] <Fujitsu> Oh, it's a real PE .exe?
[13:56] <persia> Fujitsu: Yep.
[13:56] <Fujitsu> Yuck. Wine-Doors sounds good.
[13:57]  * cyberix started to do this just because he would like to apt-get do the stuff
[13:57] <cyberix> And not have to care about something like Winedoors
[13:58] <Fujitsu> I also don't like the idea of having Windows binaries in the archive because they're liable to break on Wine upgrades.
[13:58] <persia> cyberix: The advantage of wine-doors is that it works for all distributions, so everyone can benefit, not just Ubuntu.  Further, it's much easier to get software into Wine-doors.  The disadvantage is that wine-doors doesn't work properly by default in Ubuntu.
[13:59] <cyberix> Maybe one day someone will do apt-get integration for Winedoors
[13:59] <cyberix> While waiting, I'm having my package available as a deb.
[14:00] <cyberix> Fujitsu: But this is ofcourse the right model to report bugs for wine upstream
[14:00] <cyberix> from pq launchpad section to Wines bugzilla
[14:00] <cyberix> instead of having all bug reports go throught wine package
[14:01] <cyberix> This makes it also possible for the package to distinguish between wine bugs and bugs in the original software
[14:01] <cyberix> and to split the reports
[14:01] <cyberix> to both upstreams accordingly
[14:01] <cyberix> Winedoors is more like a kludge imho
[14:02] <cyberix> Pushing the problem away.
[14:05] <cyberix> I was thinking that Medibuntu is for stuff that cannot be legally distributed/used in some regions and Multiverse is for stuff that can be legally distributed/used everywhere.
[14:05] <cyberix> But of course it would make sense to discuss this publicly.
[14:05] <cyberix> "What is Multiverse for?"
[14:05] <cyberix> Should it be broad or should we try to get rid of it.
[14:05] <cyberix> Either option is ok to me
[14:06] <cyberix> I just want it to be clear.
[14:07] <cyberix> However I'm skeptic that proper Ubuntu integration is possible at Winedoors level.
[14:07] <cyberix> So there should be a repository for stuff like pq.
[14:07] <persia> cyberix: I'm not sure anyone disagrees with you about that, but I doubt anyone present is in a position to make a declarative statement that means anything.  Personally, I'm in favor of eliminating multiverse, but this would take a while.
[14:07] <cyberix> Which one, doesn't really matter.
[14:08] <persia> genpo commented
[14:09] <Fujitsu> I'd like to see multiverse eliminated too, but that's not going to happen in the near future. However, we can try to minimise it.
[14:09] <cyberix> persia: That would make sense, if Ubuntu targets to finally make FSF happy someday, as someone suggested on Gobuntu development list.
[14:09] <cyberix> I'm following that too.
[14:09]  * cyberix is holding the free software flag high, yet optional.
[14:11] <Fujitsu> I don't really want multiverse to become a dumping ground for all software which isn't free.
[14:11] <persia> cyberix: As I see it, Multiverse is mostly for software for which we can see the source, but either not everyone can use it, or not everyone can patch it.  more, open-source software that may not be DFSG-free.  Putting closed binaries there disturbs me, because it means that I no longer can find out what my system is doing.
[14:11] <Fujitsu> persia: Good point.
[14:12] <persia> Further, I'd like to avoid integration that makes it significantly easier to distribute random .exe files and expect them to work, because there's lots of software out that that might try to do things that I don't intend.
[14:12] <persia> At least with Wine-doors, the user is taking a deliberate step to make their system more Windows-compatible, and it is the wine-doors team, and not me, that they choose to trust.  if it breaks, I am unlikely to be held responsible.
[14:13]  * Fujitsu is really off to bed now.
[14:13] <Fujitsu> Night all.
[14:14] <persia> I agree there is a place for a repository of freeware, and I believe this to be especially true for games (as an avid user of dosbox and similar programs).  I'm not sure what that repository should be, but I'm fairly sure that any specific free software distribution isn't the ideal place.
[14:14] <persia> Good night Fujitsu.
[14:23]  * cyberix bows.
[14:25] <persia> cyberix: Please don't take that as an official statement: my opinions do not necessarily reflect those of the Ubuntu project.
[14:25] <cyberix> I don't, but it makes sense. Thats more important to me.
[14:25]  * cyberix hopes persia would get to decide.
[14:25] <persia> cyberix: In that case, Thanks :)
[14:26] <cyberix> But now I have to find that freeware repository and I'm going to ask Medibuntu first.
[14:26] <cyberix> Even, if it is not the correct place either.
[14:26] <cyberix> Maybe they have some usefull comments.
[14:26] <persia> cyberix: Good luck.  There's a couple random repos out there, but a nice, well managed one, with clean integration for both Windows and Wine would likely be well received.
[14:27] <cyberix> I wouldn't want to make it Windows specific
[14:27] <cyberix> I think there are some really cool Freeware NES, DOS, ... games out there.
[14:28] <persia> cyberix: Ah.  Good point.  Don't forget MAME.
[14:29] <cyberix> :-)
[14:35] <rexbron> persia: does using a versioned -dev package matter if it has a Provides: field?
[14:37] <persia> rexbron: Yes and no.  It's technically policy compliant, but I don't prefer it.  The reasoning behind my preference is that in case there's a significant change to the -dev package that doesn't break API, there's no way to have a versioned build-depends against a virtual package.
[14:37] <rexbron> ok
[14:41] <persia> annchienta commented
[14:43] <rexbron> persia: I have found where rpath is being set (m4/boost.m4) but have no idea if LD_LIBRARY_PATH is set elsewher...
[14:44] <rexbron> or if there is a drop in replacement for rpath
[14:45] <persia> rexbron: As I understand things, -rpath doesn't quite work as expected in Debian-based systems.  You could either add a patch to set $LD_LIBRARY_PATH, or just install the libraries as normal system libraries (unless you expect them to break something).
[14:57] <rexbron> persia: tbh, I do not know really what would make them normal system libraries, nor how that could break things...
[14:59] <cyberix> persia: Ok. I think I'll write a "Beerbuntu repository" blueprint.
[14:59] <persia> rexbron: For normal system libraries, just stick them in /usr/lib, set the SONAME sensibly, and call ldconfig in the postinst.  This could break things if there is a symbol collision with other libraries, but that usually requires intention.  It could also break things if there is a file conflict, but if you follow the rule that the package name matches the library name, and you don't have a package conflict, this shouldn't happen.
[14:59] <cyberix> ;-)
[15:00] <persia> cyberix: Interesting idea.  I'm not so sure about the buntu part, just for trademark reasons, but it's definitely a catchy name.
[15:18] <cyberix> I was trying to ask, if the order of _categories_ in desktop-file matter?
[15:19] <persia> cyberix: No, but the convention is to start with the Main category, and then add any Additional categories.  See the spec for details as to which is which.
[15:27] <jroes> what package provides the C standard library (stdio.h, etc.)?
[15:29] <persia> jroes: Your best tools to find that answer are dpkg -S and apt-file.  I suspect you'll find it in one of the glibc binaries
[15:29] <jroes> ah, apt-file, cool.  thanks
[15:30] <geser> jroes: libc6-dev
[15:30] <jroes> was hoping someone would tell me how to search for providers :)
[15:30] <geser> if you want to compile then install build-essential
[15:31] <geser> jroes: you can also use packages.ubuntu.com to search in which package a file is
[15:39] <calc> jroes: or download the Contents-(arch).gz file
[15:39] <calc> and grep it
[15:39] <calc> i just found a bug...
[15:39] <calc> there is no Contents file for hardy
[15:40]  * rexbron is wanting to cry over openlibs packaging....
[15:40] <rexbron> damn thing makes my head hurt
[15:43] <rexbron> is there a way to make pbuilder not have to recompile when tweaking things like install files?
[15:45] <azeem> rexbron: maybe you can send it a suspend signal during build, then chroot into the build and work there; then finally resume
[15:45] <azeem> pretty hackish though, I guess there's an official solution
[15:47] <Amaranth> or just build it without pbuilder until you get it ready then use pbuilder for the final run
[15:47] <rexbron> I may end up doing that
[15:49] <sistpoty> hi folks
[15:49] <geser> Hi sistpoty
[15:49] <persia> hey sistpoty
[15:49] <sistpoty> hi geser
[15:49] <sistpoty> hi persia
[15:50] <geser> rexbron: you can also login into pbuilder and build from there (but don't forget to save your changes also outside the pbuilder)
[15:50] <cyberix> persia:
[15:51] <cyberix> persia: Just found out that packaging most freeware is illegal.
[15:51] <cyberix> persia: Because they usually don't permit modification,.
[15:51] <persia> sistpoty: Does the clarification to the REVU order rules make sense?  I'm a bit fuzzy, and not sure if I should be formalising it in the morning, or if you've something on which you can decide on whether it is possible to implement.
[15:51] <rexbron> geser: basically, run debuild -B from inside the pbuilder?
[15:51] <cyberix> persia: Do there is no point in Beerbuntu, because pq is just an exception that allows packaging.
[15:52] <persia> cyberix: I'm not sure how it makes it illegal, as long as you don't actually modify it.  The trick is to create a structure that delivers a binary-identical upstream package, and then adds a support structure in parallel.
[15:53] <geser> rexbron: yes
[15:53] <sistpoty> persia: need to think about this myself, but I guess it is possible to implement that way
[15:53] <persia> (assuming the license permits unlimited distribution)
[15:53] <cyberix> persia: Maybe so. But I'm not sure, if you're even allowed to change the directory layout.
[15:53] <cyberix> persia: So you'd have to distribute exactly the original, say zip-file or Windows installer.
[15:53] <persia> cyberix: Interseting.  Probably needs some thought, and maybe a consultation with counsel.
[15:54] <rexbron> geser: perhaps a silly question, but where are the source packages stored in the pbuilder?
[15:54] <cyberix> I suppose you're allowed to run the installer because that seems to be intention of the publisher.
[15:55] <persia> sistpoty: OK.  Just wanted to make sure I had actually expressed my idea before I slept  Thanks for the confirmation.
[15:55] <geser> rexbron: you have to copy it by hand into the running pbuilder (usually below /var/cache/pbuilder/build/)
[15:56] <cyberix> I'm not sure, if one would by default be restricted to even distribute the archive/installer within an other installer or archive.
[15:56] <cyberix> :-/
[16:00] <cyberix> I created mime-files. How do I tell my system to reread them?
[16:02] <sistpoty> cyberix: maybe dh_installmime creates the correct postinst snippets for this, not too sure though
[16:06] <bddebian> Heya gang
[16:06] <geser> Hi bddebian
[16:06] <bddebian> Hi geser
[16:08] <sistpoty> hi bddebian
[16:09] <geser> sistpoty: how was UDS?
[16:09] <sistpoty> geser: very interesting, and pretty cool
[16:09]  * sistpoty is still recovering from jetlag *g*
[16:09] <bddebian> Heya sistpoty
[16:11] <bddebian> siretart: D00d, I cannot get Fuddl to respond about scorched3d.  Do you know if he is on holiday or something?  Or does my reputations just precede me? ;-)
[16:11] <sistpoty> hm... how can I convince gpg to export only one uid for a given key?
[16:23] <siretart> bddebian: yes, he was this weekend on a lanparty, I've seen him a few hours ago
[16:23] <bddebian> siretart: Ah, OK thx
[16:24] <siretart> hey sistpoty
[16:24] <sistpoty> hi siretart
[16:29] <bddebian> siretart: Next time you "see" him, would you mind poking him about scorched3d?  I'm happy to work on it I just want to make sure he is OK with it.  And I need to know the dfsg status.
[16:30] <siretart> bddebian: I've asked him yesterday about that
[16:30] <siretart> bddebian: he has committed some patches for the new upstream version, but it seems to be a bit crashy at least on amd64
[16:30] <bddebian> Oh, OK
[16:31] <siretart> bddebian: the apocalypse mod is under a non-dfsg license, so that part probably has to be stripped out. or packaged in a seperate source package for non-free or something
[16:31] <siretart> bddebian: but he is more than happy for help, AFAIUI
[16:36] <bddebian> siretart: If you say so.. ;-)
[16:38] <mok0> The init.d.ex being created by dh_make is not up to standards.
[16:38] <bddebian> mok0: So fix it :-)
[16:39] <mok0> sure, I will do that, I am looking for input
[16:39] <rexbron> is there a way in an install file to make it exclude files listed in other .install files?
[16:40] <mok0> rexbron: don't think so
[16:40] <siretart> mok0: please use a bugreport for collecting your thoughts
[16:40] <rexbron> or can I call dh_install -x<item> <install_file>
[16:40] <rexbron> then call dh_install for the rest of them
[16:40] <mok0> siretart:  ok
[16:41] <siretart> rexbron: sorry? dh_install will only look at package.install, AFAIUI
[16:46] <rexbron> siretart: the situation is that the python extentions and the regular lib files get installed to the same dir, but need to be in seperate packages. as the python libs are less taht the regular libs it would be nice to have a way to exclude them without having to manually list all of them
[16:49] <bddebian> rexbron: Build them in debian/tmp then use install files to put them in the right places ?
[16:52]  * jdong tries to figure out the irony in chrooting into prevu to build a prevu builder.
[16:56] <siretart> rexbron: I agree to bddebian
[16:56] <geser> sistpoty: create a temporary keyring, import there the key, delete all non-wanted uid, export the resulting key
[16:57] <sistpoty> geser: ah, thanks
[16:57] <geser> I don't know if there is a better solution for this (an old mail suggest that no (at least at that time))
[17:00] <sistpoty> I guess in the meantime, I've looked at that very mail as well *g*
[17:04] <ST47> Good morning/afternoon, folks
[17:05] <mok0> OK, folks, I've pastebin'ed my suggestion for a new init.d.ex at http://paste.ubuntu-nl.org/43275/ Comments will appreciated before I submit it in a bug report
[17:22] <imbrandon> joejaxx, i got it "working" and in my PPA , still needs a bit of refinement and some man pages etc before official upload
[17:22] <imbrandon> but its atleaste building correctly now etc
[17:22] <imbrandon> both Xvesa and Xfbdev KDrive servers
[17:23] <imbrandon> siretart, ping ( just FYI i manualy backported hardy's lintian on sparky )
[17:23] <siretart> imbrandon: thanks!
[17:23] <imbrandon> np
[17:27] <imbrandon> ohhhhhhhhhh the eeepc's are finaly available publicly ? NICE
[17:39] <warp10> Hi all!
[17:48] <ivoks> i have a question about debian policy; is it ok to change configuration file or conffile of already installed package in tasksel postinst script of some task?
[17:50] <siretart> ivoks: I'm inclined to say its not, but you might want to ask this on #debian-devel/oftc
[17:50] <mok0> !tell mok0 about #439561
[17:50] <mok0> !tell mok0 about Bug: #439561
[17:50] <RainCT> bddebian: hey
[17:50] <ivoks> siretart: i also think that, but am not sure :/
[17:51] <ivoks> siretart: what's oftc? :)
[17:51] <cyberix> I managed to define mime-types for my files. Nautilus seems to understand that.
[17:51] <cyberix> Now, how do I make the software open them?
[17:51] <siretart> ivoks: irc.debian.org CNAMEs to irc.oftc.net
[17:51] <cyberix> When they are double clicked
[17:51] <ivoks> oh, ok
[17:51] <mok0> ubotu, tell mok0 about Bug: #439561
[17:51] <mok0> Grrr
[17:52] <siretart> debian bug #439561
[17:52] <ubotu> Debian bug 439561 in dh-make "dh-make: Enhancements to provided init.d template and a new LSB-compliant init.d script" [Wishlist,Fixed] http://bugs.debian.org/439561
[17:52] <siretart> thanks mok0
[17:53] <mok0> siretart: actually, it seems the bug is fixed in hardy
[17:53] <siretart> great
[17:58] <ivoks> yeah... it looks like we would need meta package
[17:58] <ivoks> and use tasksel just to install that package
[17:58] <ivoks> or something :/
[17:58] <siretart> ivoks: I fail to see how adding another package helps you work around that policy violation
[17:59] <ivoks> siretart: Replaces
[17:59] <ivoks> siretart: if packageA replaces packageB, then conffiles of A overwrite conffiles of B
[17:59] <siretart> oh, so you want to 'hijack' conffiles from other packages? Interesting idea
[17:59] <ivoks> conffiles would be the same
[18:00] <siretart> execpt that you want to edit it, no?
[18:00] <ivoks> it's just that i need to enable some stuff, which are off by default
[18:00] <siretart> then I'd suggest modify the package so it provide a mechanism to enable stuff you need
[18:00] <ivoks> yeah... it's easy with postfix, it has postconf
[18:01] <ivoks> but dovecot... urgh :/
[18:02] <ivoks> siretart: how was your trip back?
[18:03] <siretart> ivoks: oh, horrible. but thanks for the question :)
[18:04] <ivoks> mine too :/
[18:04] <ivoks> flight was delayed for 2 hours
[18:04] <siretart> oh darn
[18:05] <ivoks> and then, when i got to milan, they didn't have time to move my baggage from one plane to the other
[18:05] <ivoks> so i camed home only with laptop :D
[18:06] <siretart> that happened to us on the way to boston
[18:06] <ivoks> :/
[18:06] <siretart> next time I will try to travel with hand luggage only, seems safer to me
[18:06] <siretart> I managed to do that for sevilla
[18:08] <ivoks> yeah...
[18:10] <ivoks> umm... desktop people around?
[18:10] <ivoks> desktop&mobile actually :)
[18:23] <sistpoty> wooohooo... exim finally does what I want it to do (sending mails over ssh to rmail)
[18:26] <bddebian> Hi RainCT, sorry , was away
[18:29] <RainCT> bddebian: np. I merged gdmap, bug 160017 if you want to have a look a it. I was thinking I could try to do some little improvements to it, is it fine to add new changes to a merge?
[18:29] <ubotu> Launchpad bug 160017 in gdmap "Please merge gdmap 0.7.5-3 from Debian unstable" [Wishlist,New] https://launchpad.net/bugs/160017
[18:29] <cyberix> What is the stuff in /usr/lib/mime/packages/
[18:30] <cyberix> Is there a specification somewhere for it?
[18:31] <bddebian> RainCT: Yep
[18:31] <lamego> cyberix, man update-mime -> provides useful info about it
[18:33] <cyberix> How are icons asigned for mime-types?
[18:34] <cyberix> Never mind
[18:36] <cyberix> Actually
[18:37] <cyberix> update-mime says you can define an xbm icon.
[18:37] <cyberix> and no software package seems to do this.
[18:38] <cyberix> Don't people usually use svg-icons?
[19:06] <rexbron> OpenLibraries has been updated, please review :) http://revu.tauware.de/details.py?package=openlibraries
[19:07] <rexbron> regarding that review, the rpath issue has _not_ been fixed
[19:33] <nxvl> is there any way to see the changelog of a package online?
[19:34] <ScottK> Yes
[19:34] <nxvl> ScottK: where?
[19:35] <ScottK> packages.ubuntu.com has a link to it.
[19:35] <ScottK> nxvl: I'm assuming you mean the Debian Changelog, not the upstream one?
[19:36] <nxvl> ScottK: yes, that's what i meant
[19:37] <nxvl> ScottK: thank you i have just found it :D
[19:45] <nxvl> which was the URL of DaD?
[19:45] <nxvl> nevermind
[19:45] <nxvl> i found it
[19:46] <RainCT> bddebian: ok, new debdiff on bug 160017
[19:46] <ubotu> Launchpad bug 160017 in gdmap "Please merge gdmap 0.7.5-3 from Debian unstable" [Wishlist,New] https://launchpad.net/bugs/160017
[19:47] <nxvl> RainCT: nice!
[19:48] <bddebian> RainCT: Cool, I'll check it out if someone doesn't beat me to it :-(
[19:48] <RainCT> ok, thanks :)
[19:58] <bddebian> RainCT: Are you expecting this to be an SRU ?
[19:58] <minghua> Oh, REVU day again.
[19:59] <RainCT> bddebian: do you think it should be? :)
[20:01]  * RainCT will brb
[20:01] <bddebian> RainCT: I typically don't do SRU's so if you don't care if it's an SRU, you need to change the distro to Hardy
[20:05] <so1> hi
[20:05] <so1> does someone plan to update secret maryo chronicles?
[20:05] <so1> atm it's at 0.99.2 which is quite old
[20:06] <so1> newest one is 1.2
[20:06] <rexbron> so1: Check to see if a bug has been filed and if not, do it :)
[20:06] <so1> ok
[20:07] <so1> and 0.99.2 doesn't work
[20:07] <rexbron> Best to mention that aswell
[20:07] <so1> crashes with a devil error
[20:07] <rexbron> ...?
[20:07] <so1> damn ... i really need that game to increase my productivity at work!
[20:07] <so1> :-)
[20:07] <so1> CEGUI Exception occurred : DynamicModule::DynamicModule - Failed to load module 'libCEGUIDevILImageCodec.so': libCEGUIDevILImageCodec.so: cannot open shared object file: No such file or directory
[20:08] <rexbron> so1: Bug report :)
[20:08] <lamego> so1, missing dependency, it needs libcegui-mk2-dev
[20:08] <ScottK> so1: The best way to get a package updated is to do it yourself.  New upstream updates are generally not exremely hard to package.
[20:08] <lamego> because of a packaging problem with libcegui-mk2
[20:08] <so1> thanks!
[20:09] <so1> https://bugs.launchpad.net/ubuntu/+source/smc/+bug/136435
[20:09] <ubotu> Launchpad bug 136435 in smc "smc - Secret Maryo Chronicles - unmet dependency in Gutsy" [Undecided,Confirmed]
[20:10] <lamego> yes, it is an old known problem :P
[20:24] <RainCT> bddebian: oh, right
[20:26] <RainCT> bddebian: done
[20:27] <bddebian> RainCT: OK, thanks, give me a bit
[20:27] <RainCT> bddebian: sure
[20:29] <pochu> When I open a terminal, and do meta-left, meta-right, meta-up or meta-down, it prints A, B, C and D. Is this a bug?
[20:32] <pwnguin> pochu: which button is meta?
[20:32] <pochu> pwnguin: alt
[20:32] <pwnguin> esc?
[20:32] <pwnguin> heh, it prints something different for me :P
[20:33] <pwnguin> ;3A
[20:33] <pochu> lol, then it looks like a bug :)
[20:33] <pwnguin> i dont think its a bug
[20:33] <pochu> that looks fine...
[20:33] <pochu> pwnguin: gutsy?
[20:33] <pwnguin> yes
[20:33] <pochu> and gnome-terminal?
[20:33] <pwnguin> yes
[20:33] <pwnguin> ABCD
[20:33] <pwnguin> probably related to ssh / screen?
[20:34] <pochu> Woops, it works now ¿?
[20:34] <pwnguin> thats what happens in my ssh+screen + irssi session
[20:34] <pochu> Yes, it happens in irssi, and (IIRC) it happened to me in gnome-terminal too...
[20:35] <pochu> So I thought it was gnome-terminal, or bash, or whatever's fault, and not irssi.
[20:35] <pochu> pwnguin: I run irssi in gnome-terminal, so ssh and screen don't affect.
[20:36] <warp10> pochu: thank you! meta-<arrow> doesn't work in my terminal like in your one, but I have just discovered that I can use it to reorder the channel list in xchat :D
[20:37] <pochu> warp10: yw :) there's a bug about them not working in irssi, bug 159587
[20:37] <ubotu> Launchpad bug 159587 in irssi "binding meta-left meta-right meta-up meta-down does not work" [Low,Confirmed] https://launchpad.net/bugs/159587
[20:38] <pwnguin> well there ya go
[20:39] <pwnguin> warp10: i wound up checking gnome-term settings and rediscovered the transparency option
[20:39] <pwnguin> it used to be really crappy fake transparencies
[20:39] <pwnguin> it now does the real thing quite nicely
[20:40] <bddebian> RainCT: I'm nitpicking but could you fix the make clean?  Just put [ ! -f Makefile ] ||  in front of make clean
[20:40] <warp10> pwnguin: I'm just playing with it... great!
[20:52] <bddebian> RainCT: Never mind, I'll just add it and upload, thanks!
[20:55] <bluekuja> which package does contain the python module keyring?
[20:56] <bluekuja> *gnomekeyring
[20:56] <pwnguin> python module?
[20:56] <bluekuja> pwnguin, yes
[20:57] <pwnguin> none?
[20:57] <bluekuja> pwnguin, that's why I asked. Actually there is no python-keyring
[20:57] <bluekuja> package
[20:57] <bluekuja> but should be included in some other gnome package
[20:57] <pwnguin> libpam-gnome-keyring is the only one i care about
[20:58] <bluekuja> I've installed python-gnome-dev
[20:58] <bluekuja> and fixed that problem
[20:58] <bluekuja> but it installs tons of package
[20:59] <bluekuja> bah
[21:02] <zul> network manager is default isnt it?
[21:03] <bddebian> RainCT: Uploaded, thanks!
[21:04] <crimsun_> zul: for all but ubuntustudio-desktop, it's a Recommends.  So, yes.
[21:04] <zul> thank you redhat for fixing it for hardy ;)
[21:04] <zul> )xen)
[21:05] <norsetto> zul: am I wrong or the description for xen-hypervisor-3.1 is outdated?
[21:11] <RainCT> bddebian: great, thanks :)
[21:22] <bddebian> RainCT: No, thank YOU :-)
[21:24] <norsetto> rainct, bddebian: heck thank *YOU* both
[21:25] <bddebian> heh
[21:26] <crimsun> yeah, thanks bddebian!
[21:26]  * LaserJock ^5s bddebian 
[21:29] <Kopfgeldjaeger> n8
[21:30] <bddebian> Uhm... :-)
[21:31] <RainCT> lol
[21:31] <RainCT> well, good night all
[21:32] <bddebian> Gnight RainCT
[21:38] <joejaxx> why do people break the mailing list chain by doing that Digest, Vol5 Issue 2 nonsense :\
[21:39] <LaserJock> haha
[21:40] <LaserJock> if somebody wrote some sort of mailman "fix" for that it'd be awesome
[21:40] <joejaxx> i wish they did
[21:40] <joejaxx> it breaks mailman and gmail's sorting
[21:40] <joejaxx> and you have no idea what the post is about
[21:41] <ScottK> Mailman is on sourceforge, IIRC, and is written in Python, so anyone can have a crack at it.
[21:41] <LaserJock> it would be a tough problem
[21:41] <LaserJock> as in some cases you have no idea what thread to attach to
[21:42] <joejaxx> yeah
[21:42] <joejaxx> which is why i do not know why people do it
[21:42] <joejaxx> lol
[21:42] <StevenHarperUK> Can someone help me: I have 4 comments on my latest submission to REVU : http://revu.tauware.de/details.py?upid=402 - and I dont understand any of them (there are 4)
[21:43] <joejaxx> anyone want to look a merge i did ? :)
[21:43] <joejaxx> https://people.fluxbuntu.org/~joejaxx/ubuntu/merges/flwm_1.02-2ubuntu1.MERGE.debdiff
[21:43] <crimsun> argh, binary?
[21:44] <joejaxx> crimsun: oh
[21:44] <joejaxx> it does not display it as text?
[21:44] <bddebian> StevenK: 1: Homepage is now supported in the control section.  Like right up under Standards Version and such
[21:44] <crimsun> joejaxx: no
[21:44] <joejaxx> grr wth
[21:44] <joejaxx> hold on
[21:44] <bddebian> Gah, that was for StevenHarperUK
[21:45] <bddebian> StevenHarperUK: 2:  You don't seem to be installing upstreams ChangeLog file.
[21:45] <StevenHarperUK> Ah I know what to do with that one
[21:45] <StevenHarperUK> its my code BTW : I am upstream
[21:46] <StevenHarperUK> The other 3 are confusing me : how do I resolve them
[21:46] <bddebian> StevenHarperUK: 3: Are you repacking your tarball?  I'm not sure I get his point on that one either unless you are just getting an svn snapshot and creating the tarball
[21:47] <crimsun> joejaxx: uploaded to hardy.
[21:47] <StevenHarperUK> I am using SVN to get the source, making the tarball then packaging from that
[21:47] <bddebian> StevenHarperUK: And for 4: Packages are supposed to include debian/watch files.  See man uscan
[21:47] <StevenHarperUK> I do it with a std build script
[21:47] <joejaxx> crimsun: ok thanks :D i need to find out why it is doing that
[21:47] <joejaxx> i rather not append .txt on my debdiffs :\
[21:49] <StevenHarperUK> What is the purpose of teh Watch file and do I install it or is it just in debian/watch?
[21:50] <sistpoty> StevenHarperUK: with the watch file, you can easily scan for new upstream versions (with uscan). it's not installed, since a new upstream version means that the maintainer has to package it
[21:50] <LaserJock> anybody got any experience with Google Code for hosting a project?
[21:51] <StevenHarperUK> So basically I include it in debian/watch and thats it?
[21:51] <StevenHarperUK> Sorry I don't really get what I do with the file once I have made it
[21:52] <bddebian> StevenHarperUK: It lets you know of new upstream releases.  I don't know that it's required
[21:52] <LaserJock> StevenHarperUK: you don't do anything
[21:52] <bddebian> If you run uscan -report-status it will tell you if the current package is up to date
[21:52] <LaserJock> StevenHarperUK: every once in a while you can run uscan to see if there's a new upstream version
[21:52] <LaserJock> like in Debichem we have like 15 upstreams
[21:52] <StevenHarperUK> Its my code I know when there is a new version
[21:53] <LaserJock> so we have a script that checks once a week via watch files for new upstream releases
[21:53] <StevenHarperUK> Right so its for an automated process
[21:53] <LaserJock> StevenHarperUK: then in that case it is helpful for other people
[21:53] <LaserJock> a watch file is really the only definitive way to know where the .orig.tar.gz came from many times
[21:54] <bddebian> But if you are never building tarballs I'm not sure how you would do it
[21:54] <StevenHarperUK> So I make  the debain/watch file and do I need to include any re fence to it Anywhere?
[21:54] <bddebian> No
[21:54] <StevenHarperUK> ok great
[21:54] <joejaxx> time for more merges
[21:54] <joejaxx> :D
[21:54] <StevenHarperUK> finally : "I’m sorry to report that dpkg behaviour has now changed, and the Homepage should be a full header, rather than in the long description" what does that mean can someone point me to the new spec
[21:55] <LaserJock> StevenHarperUK: there's just a Homepage: field in control
[21:55] <StevenHarperUK> Does it mean that I just kill the first SPACE and make it into its own section
[21:55] <StevenHarperUK> Ace I get that now
[21:55] <LaserJock> like Build-Depends, etc.
[21:56] <StevenHarperUK> Thanks
[21:56] <LaserJock> but take it out of the description
[21:56] <StevenHarperUK> I have
[21:56] <bddebian> Well there is still some debate on that one but I'll shut up
[21:56] <StevenHarperUK> Sorry to keep going on : "This appears to be a VCS checkout, but there is no get-orig-source in debian/rules, nor mention of a repack in debian/copyright " How do I resolve this?
[21:57] <bddebian> create a get-orig-source target in rules
[21:57] <StevenHarperUK> I don't understand that sentence
[21:58] <bddebian> http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz
[21:58] <bddebian> Basically it's an additional section in Debian rules that creates the orig.tar.gz
[21:58] <bddebian> Ensures that the orig.tar.gz is consistently getting created
[21:59] <StevenHarperUK> But I am making the orig tar.gz
[21:59] <StevenHarperUK> I whats the point of this?
[21:59] <joejaxx> StevenHarperUK: so we have an untouched upstream source archive
[22:00] <joejaxx> :)
[22:00] <ScottK> StevenHarperUK: If you're making your package from a proper tarball, then you shouldn't get that.  Are the .svn dirs (or equivalen) in the tarball?
[22:00] <StevenHarperUK> No
[22:00] <StevenHarperUK> I build it in its own build dir
[22:01] <StevenHarperUK> there are no .svn
[22:01] <StevenHarperUK> That seems like (another) pointless request : this REVU process is begging to get me down
[22:02] <StevenHarperUK> I get conflicting requests from MOTU
[22:02] <ScottK> StevenHarperUK: What's the fill name of your tarball?
[22:02] <joejaxx> is michael bienia geser?
[22:02] <ScottK> joejaxx: Yes
[22:02] <joejaxx> ok
[22:03] <StevenHarperUK> easycrypt_0.2.1.9+svn20071103.orig
[22:03] <StevenHarperUK> easycrypt_0.2.1.9+svn20071103.orig.tar.gz
[22:03] <StevenHarperUK> I mean
[22:04] <ScottK> So it is an svn snapshot rather than a proper release?
[22:04] <StevenHarperUK> No its what the comment further up told me to call it
[22:05] <StevenHarperUK> It is a proper release
[22:05] <StevenHarperUK> I can remove that if I want
[22:05] <StevenHarperUK> I have stopped getting ant work done on the actual package and am stuck in these packaging problems
[22:05] <StevenHarperUK> *any
[22:06] <StevenHarperUK> I want to get back to coding.....
[22:07] <StevenHarperUK> sorry : I have to go now, I will build another version soon with the WATCH file in, thanks for  the help
[22:08] <ScottK> StevenHarperUK: Thanks for working through it.  The first one is by far the toughest.
[22:09] <StevenHarperUK> ScottK: do i rename to have no +svn ?
[22:09] <StevenHarperUK> ScottK: would that be advisable?
[22:10] <ScottK> StevenHarperUK: I suspect so, but I haven't reviewed your package in detail, so I'm relucant to give you advice contrary to what you've had before.
[22:10] <ScottK> StevenHarperUK: If I were in your shoes, I'd make a proper 0.2.1.10 release and package that.
[22:11] <ScottK> StevenHarperUK: I've several packages where I'm also the upstream and it can be a bit confusing trying to separate the roles of upstream and packager in your head when you're doing both.
[22:11] <StevenHarperUK> ScottK: I think I will : will REVU let you re-upload a package or does it have to be renamed?
[22:11] <ScottK> StevenHarperUK: You can reupload it.
[22:11] <bddebian> You can just re-upload
[22:11] <StevenHarperUK> ok i will 0.2.1.10 will be next
[22:12] <StevenHarperUK> thanks for the help
[22:12] <ScottK> StevenHarperUK: So do a release like you would do if you knew nothing about Ubuntu with a regular tar.gz and then package that.
[22:12] <ScottK> No trouble.
[22:12] <StevenHarperUK> I can say that the comments left on REVU could be more helpful, may of them leave no pointers on what they actually mean
[22:12] <StevenHarperUK> *many
[22:13] <StevenHarperUK> Ok I have to go now RL issues are now screaming for my attention
[22:13] <StevenHarperUK> cya
[22:13] <ScottK> StevenHarperUK: Different people have different levels of experience.  Both reviewers and uploaders, so it can be tough to get the communication at the right level.
[22:13] <ScottK> See you.
[22:13] <StevenHarperUK> bye
[22:15] <joejaxx> is there a list of development packages that are useful during merges?
[22:15] <joejaxx> i already have all the ones listed on the debian new maintainer docs
[22:17] <norsetto> joejaxx: all you need on top of the normal dev tools is here: https://wiki.ubuntu.com/MOTU/Merging
[22:17] <joejaxx> and ok
[22:17] <joejaxx> s/and\ ok/ok/g
[22:18] <crimsun> the only tool you need is sed!
[22:18] <joejaxx> i do not see any packages listed there
[22:18] <norsetto> joejaxx: if you find something missing or not explained clearly and/or correctly let us know
[22:18] <joejaxx> crimsun: :P
[22:19] <joejaxx> norsetto: i mean package wise
[22:19] <norsetto> joejaxx: did you find any package in there?
[22:19] <joejaxx> norsetto: nope
[22:19] <joejaxx> norsetto: i do not see a list of packages there
[22:19] <norsetto> joejaxx: thats right ;-)
[22:20] <joejaxx> http://www.debian.org/doc/maint-guide/ch-start.en.html#s-needprogs
[22:20] <joejaxx> i have all of those already
[22:24] <norsetto> joejaxx: I thought you did some merges already?
[22:25] <imbrandon> joejaxx, http://ppa.launchpad.net/imbrandon/ubuntu/pool/main/x/xorg-server/xserver-xvesa_1.3.0.0.dfsg-12ubuntu8~imbrandon+xvesa4_i386.deb if you wanna mess with it , i'll probably be uploading a new version tonight sometime too
[22:25] <joejaxx> i did
[22:25] <joejaxx> norsetto: sorry if i am being confusing
[22:25] <joejaxx> imbrandon: ok great
[22:25] <ajmitch> joejaxx: you are, don't worry
[22:25] <joejaxx> ajmitch: :P
[22:26] <ajmitch> just grab the usual stuff, and things like patchutils, etc
[22:26] <joejaxx> if the ubuntu patch for a package only has the maintain change and the changelog in the patch then that means we can drop the ubuntu changes because there are not any? (ie put in a sync request)
[22:26] <imbrandon> btw moins all
[22:26] <joejaxx> ajmitch: ok
[22:26] <joejaxx> maintainer*
[22:27] <norsetto> joejaxx: if the only ubuntu change left is the maintainer field, yes, its a sync
[22:27] <joejaxx> ok nice
[22:27] <joejaxx> i just want to make sure :)
[22:28] <norsetto> joejaxx: so, you may need a package after all :-)
[22:28] <norsetto> joejaxx: for syncs you may use requestsync, which is in ubuntu-dev-tools
[22:28] <joejaxx> i like to ask questions even if i think i know the answer so i do not look like a fool later
[22:28] <joejaxx> norsetto: ok
[22:28] <joejaxx> i already have that installed :D
[22:28] <joejaxx> dholbach told me about that package at the motu uds session
[22:29] <joejaxx> pbuilder-dist is a great tool i found out about that at the session as well
[22:29] <pwnguin> oh?
[22:31] <joejaxx> pwnguin: yeah
[22:31] <pwnguin> i cant find pbuilder-dist
[22:32] <joejaxx> pwnguin: it is in ubuntu-dev-tools
[22:32] <joejaxx> it keeps track of different tarballs for ubuntu releases
[22:32] <joejaxx> so you can go pbuilder-dist hardy build
[22:32] <pwnguin> oh
[22:32] <joejaxx> or feisty build
[22:32] <joejaxx> etc
[22:33] <pwnguin> i was hoping for something more like parallel pbuilder
[22:33] <joejaxx> hmm/
[22:33] <imbrandon> there are hooks for distcc and ccache if you want
[22:34] <joejaxx> s/\///g
[22:34] <joejaxx> oh
[22:34] <joejaxx> you thought it was distributed pbuilder
[22:35] <pwnguin> i dont think pbuilder uses dual cores effectively atm
[22:35] <joejaxx> Explanation of the Ubuntu delta and why it can be dropped:
[22:36] <joejaxx> ?
[22:36] <jdong> joejaxx: you can run two pbuilders....
[22:36] <crimsun> usually the Ubuntu changes have been obviated by Debian changes.
[22:36] <pwnguin> sure, you can run multiple builds in parallel, but you need multiple packages in the queue
[22:36] <joejaxx> crimsun: i am looking at alsa-oss :P can i file a sync request for it?
[22:37] <pwnguin> i dont regularly work on multiple source packages at once
[22:37] <joejaxx> crimsun: since you are the last person :)
[22:37] <Kmos> joejaxx: it's already done
[22:37] <joejaxx> Kmos: ?
[22:37] <Kmos> bug 159496
[22:37] <ubotu> Launchpad bug 159496 in alsa-oss "Please sync alsa-oss 1.0.14-1  (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/159496
[22:37] <joejaxx> uh
[22:37] <joejaxx> no
[22:37] <crimsun> joejaxx: yes.
[22:37] <joejaxx> crimsun: ok :)
[22:37] <crimsun> that would need to be 1.0.15-1, but yes.
[22:38] <joejaxx> crimsun: yes
[22:38] <Kmos> debian is having network problems :(
[22:38] <joejaxx> crimsun: for base version i put the debia version right?
[22:38] <joejaxx> debian*
[22:39]  * sistpoty is off to bed now
[22:39] <sistpoty> gn8 everyone
[22:39] <crimsun> yes
[22:39] <crimsun> night stefan
[22:39] <norsetto> bye sistpoty
[22:41] <joejaxx> hmm
[22:41] <joejaxx> how long does requestsync take after you hit enter when putting a description
[22:41] <joejaxx> or does it need a EOF Ctrl+D
[22:42] <Kmos> joejaxx: you need a second enter
[22:42] <Kmos> for an empty line
[22:46] <cyberix> Should I create symlinks during packaging or with a command from rules?
[22:47] <bddebian> man dh_link ?
[22:47] <cyberix> Yes. Thats why ask.
[22:48] <cyberix> I
[22:53] <joejaxx> crimsun: i think i am just going to edit the vurrent requestion it just has the wrong version
[22:54] <crimsun> joejaxx: ?
[22:54] <crimsun> -EPARSE
[22:54] <joejaxx> i am sorry?
[22:54] <crimsun> oh, you mean "edit the current request"?  Sure, go ahead.
[22:54] <joejaxx> yes
[22:55] <joejaxx>  :D
[22:55] <joejaxx> wth
[22:55] <joejaxx> someone already changed it
[22:55] <norsetto> g'night all
[22:55] <crimsun> night norsetto
[22:56] <joejaxx> is there anyway to look up bug change history?
[22:56] <crimsun> Bug Activity.
[22:56] <joejaxx> hmm i do not see that
[22:57] <crimsun> "View activity log"
[22:57] <joejaxx> ahhh
[22:57]  * TheMuso waves, now safely back in australia.
[22:57] <crimsun> TheMuso: how was the return flight?
[22:58] <TheMuso> crimsun: Long. There were two of them, but yes, they were long.
[22:58] <joejaxx> who is marco rodridues?
[22:58] <Fujitsu> Hi TheMuso.
[22:58] <TheMuso> Hey Fujitsu .
[22:58] <geser> joejaxx: Kmos
[22:58]  * TheMuso changes his notebook's timezone.
[22:58] <joejaxx> Kmos: :(
[22:58] <geser> joejaxx: touched he again someone else bugs?
[22:59] <Fujitsu> joejaxx: Kmos has that effect on people.
[22:59] <Kmos> joejaxx :)
[22:59] <Kmos> joejaxx: you can check alsa-tools
[23:00] <joejaxx> Kmos: you should have left the description as is
[23:00] <Kmos> it not requested
[23:00] <joejaxx> it was signed
[23:00] <joejaxx> the message that is
[23:01] <geser> Kmos: were you not told already several times to NOT TOUCH someone else bugs?
[23:02] <Kmos> geser: i changed the description to match the debian version
[23:02] <Kmos> and title
[23:02] <Kmos> because it was correct on description, but not in the titl
[23:02] <Kmos> because it was correct on description, but not in the title
[23:03] <Kmos> i think I'm helping :(
[23:04] <ScottK> Kmos: You'd be helping more if you would do as people tell you.  Your persistent failure to do so is a serious problem.
[23:04] <Kmos> :(
[23:06]  * Kmos needs to sign it in hands.. "NOT TOUCH SYNCS EVEN IF ONLY TO CHANGE TITLE VERSION"
[23:06]  * Kmos with laser
[23:07] <LaserJock> it's an interesting question though
[23:07] <LaserJock> having signed descriptions that are editable
[23:07] <joejaxx> LaserJock: yeah
[23:07] <joejaxx> i would only change the title
[23:07] <LaserJock> comments aren't a problem, but descriptions are mutable
[23:08] <LaserJock> not that I put much of any value in signed emails
[23:08] <joejaxx> :P
[23:08] <LaserJock> but if you're going to go to the trouble I suppose it's nice for it to stay intact
[23:08] <joejaxx> yeap :D
[23:08] <TheMuso> LaserJock: I think in this case, the signing verifies that the person who sent it is who they say they are.
[23:09] <joejaxx> yeah that is my thing
[23:09] <joejaxx> if you change the signed message the original message as intended by the sender is not invalid
[23:09] <joejaxx> gah
[23:09] <joejaxx> not valid
[23:09] <joejaxx> lol
[23:09] <joejaxx> double negatives
[23:09] <joejaxx> lol
[23:10] <LaserJock> TheMuso: sure, I just don't think that's of any use. But it's annoying for those who care about such things
[23:10] <TheMuso> LaserJock: Aye.
[23:10]  * pwnguin takes notes on what not to do by watching kmos
[23:11] <Kmos> i'll put message again signed =) revert the change..
[23:11] <Kmos> pwnguin :)
[23:12] <Kmos> it's back to normal
[23:21] <joejaxx> StevenK: are you going to do the apt-rpm merge? :D
[23:26] <StevenK> joejaxx: Not right now. But probably not.
[23:26] <joejaxx> k
[23:26] <joejaxx> ok*
[23:26] <joejaxx> anyone want to look at https://people.fluxbuntu.org/~joejaxx/ubuntu/merges/apt-rpm_0.5.15lorg3.2-3ubuntu1.MERGE.debdiff ? :D
[23:29] <TheMuso> joejaxx: File a bug
[23:30] <LaserJock> man I need a new laptop
[23:30] <LaserJock> this thing is a piece of junk
[23:31] <LaserJock> or perhaps I need to strip down the apps I use on it
[23:31] <joejaxx> LaserJock: specs? :D
[23:32] <LaserJock>  Intel(R) Celeron(R) CPU 2.80GHz and 512MB RAM
[23:33] <LaserJock> my AMD 1800+ smokes it
[23:33] <ScottK> Beats the pants off my Pentium III 700 w/256MB of RAM.
[23:33]  * ScottK is considering a new laptop too.
[23:33] <LaserJock> Firefox brings it to it's knees
[23:34] <LaserJock> it's constantly running slightly under 80C
[23:34] <ScottK> As long as I'm doing one thing at a time, it doesn't seem to horrible.  I mostly use Konqueror for web browsing on it.
[23:36] <proppy> hi
[23:42] <LaserJock> hmm, maybe it's just gmail that's killing it
[23:42] <joejaxx> :P
[23:43] <joejaxx> LaserJock: run it in basic html mode :D
[23:43] <joejaxx> gmail +Ajax mode kills firefox on opensolaris :\
[23:43] <pwnguin> firefox hates that little box in the bottom corner that pops up a name
[23:43] <pwnguin> as long as its not showing gmail runs great
[23:44] <LaserJock> oh wow, that's a lot better
[23:44] <pwnguin> and now that this conversation is on irclogs, google will probably find it and fix it ;)
[23:45] <LaserJock> it's a lot faster and dropped my avg CPU temp by ~5C
[23:46] <LaserJock> joejaxx: thanks dude, that's way better
[23:48] <Kmos> what's the package name for fmod ex library ?
[23:48] <Kmos> fmodex doesn't exist
[23:50] <joejaxx> LaserJock: you are most welcome :D
[23:50] <joejaxx> someone remind me not to eat Oreos and Sprite together in the future :(
[23:51] <LaserJock> joejaxx: and here I was thinking I'd have to install fluxbuntu on this thing ;-)
[23:51] <joejaxx> LaserJock: :P
[23:55]  * joejaxx goes back to merging
[23:56] <bddebian> Gah, I have to stop this games team shit.. :-(
[23:56] <joejaxx> bddebian: why?
[23:56] <joejaxx> :\
[23:57]  * joejaxx found two more merges :D
[23:57] <LaserJock> bddebian: please don't
[23:59] <bddebian> Because it's unresponsive and frustrating