[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.    #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 <IP_ADDRESS> downloader core and putting it on the <IP_ADDRESS> 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.  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.   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.    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.   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<EMAIL_ADDRESS>and use XSBC-Original-Maintainer for your name.
[10:07] <imbrandon><EMAIL_ADDRESS>[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.  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 ==<EMAIL_ADDRESS>, 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<EMAIL_ADDRESS>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<EMAIL_ADDRESS>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.