[00:23] <StFS> Hello. I'm trying to figure out a way to create an ISO with a setup for a specific laptop type. I'd like the end user only to have to supply his username and password, everything else (network, xorg.conf etc) should be configured already. Can you point me towards some reading material?
[00:23] <TheMuso> StFS: Have you considered installinv via OEM mode?
[00:24] <TheMuso> installing
[00:24] <StFS> TheMuso: hmm... not quite sure what you mean by that?
[00:25] <TheMuso> StFS: You can install Ubuntu, and when it gets booted for the first time, it will ask the user information like their username, timezone, etc.
[00:25] <TheMuso> StFS: I think you activate it by pressing F4 at the CD boot menu to choose OEM installer.
[00:25] <TheMuso> WHich brings up a menu with that as one of the options.
[00:26] <StFS> TheMuso: ok... that's pretty much what I had in mind... except it would be great if I could answer as many questions like that as I could... for example, the timezone would be the same for everyone
[00:26] <StFS> TheMuso: ok... well I'll definately take a look at this :) thanks so much!
[00:26] <TheMuso> You're welcome, hope it helps.
[00:27] <StFS> oh I'm sure it will
[00:38] <mohbana> how do i pack something in .deb?
[02:01] <emma> Hi
[02:11] <emma> Hi astro76
[03:21] <emma> hm.
[05:44] <Rigonn> Hello
[05:44] <Rigonn> i need some help
[06:22] <pitti> Good morning
[06:23] <dholbach> good morning
[06:27] <emgent> morning
[07:08] <dholbach> hey thekorn
[07:13] <dholbach> thekorn: are you planning to work on  five-a-day/gettext.applet  today? if not I'd look into fixing bug 220187 (comment 2)
[07:13] <ubotu> Launchpad bug 220187 in five-a-day "add gettext support to the applet" [Undecided,In progress] https://launchpad.net/bugs/220187
[07:18] <thekorn> good morning dholbach,
[07:18] <thekorn> no, I think I will not work on it for the next two or three days, so please go on:)
[07:19] <dholbach> thekorn: ok great - will let you know how it goes
[07:20] <pitti> Riddell, slangasek: can either of you please peer-review/ack my hardy-proposed hal upload? (in the queue already, and bug 25931)
[07:20] <ubotu> Launchpad bug 25931 in hal "Failed to initalize HAL." [High,In progress] https://launchpad.net/bugs/25931
[07:20] <dholbach> hi pitti
[07:20]  * pitti hugs dholbachq
[07:20] <pitti> and dholbach, too
[07:20] <dholbach> :)
[07:23] <thekorn> dholbach, do you know why I don't get notification emails when you subscribe me to a five-a-day bugreport
[07:23] <thekorn> hello pitti
[07:24] <dholbach> thekorn: that's because of a LP bug :-/
[07:24] <pitti> hey thekorn, wie gehts?
[07:25] <thekorn> pitti, Alles super!
[07:26] <thekorn> dholbach, I see
[07:45] <thekorn> dholbach, recompiling files in /usr/lib/python2.5/site-packages/fiveadayapplet/ fixes bug 222829, the .pyc files are old
[07:45] <ubotu> Launchpad bug 222829 in five-a-day "5-a-day-applet crashed with AttributeError in do_tags_show()" [Undecided,New] https://launchpad.net/bugs/222829
[07:46] <thekorn> I don't know if this is a packaging issue and how to fix this
[07:47] <dholbach> thekorn: that's really weird
[07:47] <dholbach> doko: what do you think about the bug mentioned above?
[08:23] <mdke> seb128: do you know anything about rarian? I wonder if it is in a fit state to replace scrollkeeper for intrepid?
[08:24] <doko> thekorn, dholbach: can't find a fiveadayapplet directory
[08:24] <seb128> mdke: upstream doesn't to be really active on it but the compat layer should be usuable instead of scrollkeeper, I didn't really try though
[08:25] <dholbach> doko: you can run   bzr branch lp:five-a-day   to get the source - or check the five-a-day-applet binary package
[08:25] <mdke> seb128: I'll have a chat with Don. Scrollkeeper is a real pain
[08:26] <seb128> mdke: why? because you need to list locales?
[08:26] <pitti> hey seb128
[08:27] <seb128> guten tag pitti ;-)
[08:27] <dholbach> thekorn: I merged your translation changes and did a huge bunch of changes but it doesn't quite work yet :)
[08:27] <mdke> seb128: well, yes; but also because it takes a long time to do the update process for each package that uses it (ubuntu-docs takes several minutes). Also most of the crash reports I see for ubuntu-docs seem to be scrollkeeper related
[08:28] <mdke> seb128: afaik yelp doesn't use scrollkeeper now, so I think it is superfluous
[08:28] <seb128> mdke: right, there is one crasher but we have difficulties to track it, would require a valgrind log from somebody having the issue
[08:28] <seb128> mdke: I'm not sure that the rarian compat tools are faster though
[08:29] <mdke> seb128: I heard that rarian doesn't require -update to be run each time a package is installed; but I don't know enough about it to talk confidentialy on the subject :)
[08:29] <mdke> seb128: perhaps I'll send him an email with copy to you, would that be ok?
[08:29] <seb128> sure
[08:29] <mdke> thanks
[08:30]  * Hobbsee waves
[08:30] <seb128> mdke: that's the goal, but all the upstream tarball always run scrollkeeper-update so I think there is still some changes required
[08:30] <pitti> hey Hobbsee!
[08:30] <seb128> mdke: I think the omf need to be changed to rarian indexes or something in the source
[08:30] <Hobbsee> pitti
[08:30]  * Hobbsee hugs pitti
[08:32] <mdke> seb128: ok
[08:39] <doko> thekorn: what to you mean by "old"?
[08:40] <thekorn> doko, they are outdated, from the last version of the package
[08:40] <mvo> pitti: should we milestone #32906 for 8.04.1? I've seen a bunch of reports that have it as a side effect
[08:40] <doko> thekorn: are the timestamps older?
[08:42] <thekorn> doko, let me check this with a fresh install of the package
[08:44] <pitti> mvo: I've been meaning to look into that anyway, milestoned
[08:44] <pitti> mvo: I just cannot reproduce it on my production systems, but it seems to work on a live CD
[08:45] <mvo> pitti: ok, thanks
[09:08] <doko> seb128: any reason for the assignment of #223449?
[09:12] <seb128> doko: python segfault in the log
[09:12] <thekorn> doko, the timestamp seems to be ok, http://paste.ubuntu.com/8466/
[09:12] <seb128> doko: ah, I typed "python" as product, should have use python2.5 I guess, right?
[09:13] <doko> seb128: did you look at ProcMaps?
[09:14] <doko> thekorn: what does ls -lL say?
[09:14] <seb128> doko: the guy ran apport on gnome-system-log apparently so the apport datas are for this one
[09:14] <seb128> doko: which is not revelant since the issue is describe is gdesklet crashing due to a python segfault
[09:15] <thekorn> doko, http://paste.ubuntu.com/8471/
[09:17] <pitti> seb128: I'm a bit unsure how to further debug bug 211625; any idea?
[09:17] <ubotu> Launchpad bug 211625 in gnome-vfs2 "Disk mounter lists internal hard disk partitions" [Undecided,Incomplete] https://launchpad.net/bugs/211625
[09:18] <doko> thekorn: hmm, this looks good as well
[09:21] <seb128> pitti: the applet has not been ported to gvfs, it's still using gnome-vfs, I would not bother spending efforts on it
[09:22] <pitti> seb128: I'm just interested in how it's supposed to behave; showing internal partitions is not a bug per se IMHO (since you can mount them)
[09:22] <seb128> pitti: that's weird though because neither gnome-vfs nor the applet really changed this cycle, maybe his fstab changed and stopped listing the partition or something
[09:24] <emgent> heya tseliot
[09:25] <tseliot> ﻿emgent: hi ;)
[09:29] <seb128> pitti: I'm not sure now, I didn't read the gnome-vfs code for a while, it was supposed to list volume which don't have an ignore property no?
[09:33] <seb128> pitti: gnomevfs-ls computer: should list the same things
[09:33] <pitti> seb128: ok, thanks; let's call it a feature for now :), I don't think it's actually wrong
[09:34] <seb128> right
[09:37] <davmor2> Hey guys I noticed something but I'm not sure if it's a bug or simply not implemented yet.  if you connect to a bluetooth device that has photo's (like most phones) you can't view the images.  However you can transfer them across and then view them.  Is this a gvfs issue or an obex one?
[09:39] <amitk> ogra: could you make sure that cmpc is picking up the new kernel in the PPA?
[09:44] <kristian42> Hi! I'm decided to get involved with tracking bugs in ubuntu. Unfortunately its more than 10 years since I touched C/C++. In the 10 years that have passed I have gotten addicted to IDE's (in java), and I need this for linux too. Any suggestions as to which ide to use?
[09:49] <Robot101> kristian42: not necessarily a devel question, but take a look at eclipse w/ the C plugin, and anjuta maybe. if you're doing c#, monodevelop?
[09:51] <kristian42> Robot101: Thanks. I'll bother you gous later.
[09:51] <kristian42> Robot101: When I learn to type properly.
[09:52] <ogra> amitk, oh, cool, did i386 build ? (i went to bed when lpia was there :) )
[10:56]  * cjwatson runs the necessary Big Scary Commands to publish intrepid
[10:57] <dholbach> yooohoo
[10:57] <Hobbsee> argh!
[10:57] <Hobbsee> it's going to break on you.
[10:58] <emgent> :D
[10:58] <cjwatson> no evidence of breakage so far, touch wood
[10:58] <Ng> is that intrepid trepidation? ;)
[10:58] <Hobbsee> hah
[11:00] <Hobbsee> i guess it had it's share of breakage over the weekend.
[11:00] <Hobbsee> pity
[11:01] <cjwatson> ... what broke over the weekend?
[11:01] <pitti> mvo: hm, bug 222182 -- isn't that supposed to have a DpkgTerminalLog attachment?
[11:01] <ubotu> Launchpad bug 222182 in apport "package apport 0.108 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/222182
[11:01] <Hobbsee> cjwatson: when do people upload bits of the toolchain, which bits, and when, can be accepted?
[11:01] <Hobbsee> cjwatson: oh, last weekend, sorry.  LP went down for 14+ hours.
[11:01] <cjwatson> Hobbsee: I have warned doko already and he's ready to go, but note that I haven't yet contacted infinity to get buildds going
[11:01]  * Hobbsee forgot that there's just been a weekend.
[11:01] <cjwatson> so don't get too excited just yet :)
[11:01] <cjwatson> ah
[11:02] <Hobbsee> cjwatson: right.  kiko just wants me to accept some packages, to test if the bugs have actually been fixed.
[11:02]  * calc holds finger over update button ;-)
[11:02] <Hobbsee> calc: NO NEW OO.O FOR YOU!
[11:02] <Hobbsee> :)
[11:02] <calc> OOo 3.0 Beta, yea! ;-)
[11:02] <cjwatson> accept> err, in what release?
[11:02]  * Hobbsee beats calc with a big stick
[11:02] <calc> if it is released on time it will be on wed
[11:02] <Hobbsee> cjwatson: whichever.
[11:02] <Hobbsee> cjwatson: i was assuming intrepid
[11:02] <cjwatson> gcc-4.3 is likely to be first, but doko is more authoritative than I
[11:03] <calc> of course then i start actually working on packaging which will probably take a little while
[11:03] <cjwatson> there'll probably be an early base-files upload which is fairly safe
[11:03]  * Hobbsee nods
[11:03] <Hobbsee> it'll be accepting multiple uploads in tandem, i think
[11:03] <Hobbsee> seeing as that was the problem lsat time
[11:03] <cjwatson> it would be better to wait for that kind of test until the toolchain is sorted, I think
[11:04] <doko> cjwatson: libffi, binutils, gcc-4.3, gcc-4.2, gcj-4.3, gcj-4.2, glibc, done
[11:04]  * calc looked a bit at the load cycle mess over the weekend, but doesn't have anything conclusive yet
[11:04] <doko> ahh, java-gcj-compat missing, and gcc-defaults
[11:04] <cjwatson> so you mean simultaneously accepting >1 package through the web UI?
[11:04] <cjwatson> doko: aha, thanks
[11:04] <Hobbsee> cjwatson: perhaps.  the worst that will happen is LP times out, and someone else has to accept the package.
[11:04] <Hobbsee> cjwatson: yes
[11:04] <cjwatson> the toolchain probably needs to go in strict order, or at least it's often safer to do so
[11:05] <calc> are we moving openjdk into main as well? 8-)
[11:05] <pitti> mvo: is that log still present anywhere, so that I could ask for it?
[11:05] <Hobbsee> cjwatson: oh, i thought bits of toolchain happened in tandem, in a strict order.
[11:05] <cjwatson> so I wouldn't be comfortable with simultaneous accepts there, unless they're ones that doko says are OK to build simultaneously
[11:05] <Hobbsee> fair enough
[11:05] <Hobbsee> yeah, of course
[11:05] <doko> Hobbsee: accept what?
[11:05] <cjwatson> but we can leave the archive frozen for a bit after the toolchain's done, to allow testing
[11:05] <Hobbsee> cjwatson: that would be good, thanks
[11:06] <Hobbsee> doko: NEW CRACK!
[11:06] <Hobbsee> doko: (packages for intrepid)
[11:06] <cjwatson> calc: it's certainly a good possibility
[11:06] <cjwatson> calc: (you're up early)
[11:07] <mvo> pitti: yeah, that log should be available in /var/log/apt/term.log
[11:07] <ln-> why is there a zero-width no-break space in the topic?
[11:08] <pitti> mvo: ah, thanks
[11:08] <Hobbsee> ln-: where?
[11:09] <calc> cjwatson: couldn't sleep :\
[11:09]  * calc thinks he managed to sleep ~ 1hr last night :\
[11:14] <pitti> calc: ugh, why not?
[11:16] <ln-> Hobbsee: in the very begin.
[11:17] <cjwatson> does that help? I couldn't see where it was
[11:34] <wgrant> .win 10
[11:34] <wgrant> Damn.
[11:52] <cjwatson> Keybuk: could you point merge-o-matic at intrepid, please? it will exist on archive.ubuntu.com after the next publisher run
[11:54] <soren> Woo!
[11:55] <emgent> :)
[11:56] <cjwatson> Intrepid created, frozen for toolchain | /topic ﻿Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/﻿feisty/gutsy/hardy﻿, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
[11:56] <cjwatson> oops
[11:56]  * soren goes to dist-upgrade :)
[11:56] <soren> There. All done :)
[11:56] <cjwatson> it'll 404 right now
[11:57] <cjwatson> like I say, needs a publisher run to trigger the mirrors. :)
[11:57] <pitti> cjwatson: will the publisher run in 6 minutes?
[11:57] <ln-> there are still several zero-width spaces in the topic.
[11:57] <cjwatson> pitti: as usual
[11:57]  * pitti eagerly waits for all the -proposed changes to actually turn up
[11:57] <cjwatson> ln-: where exactly?
[11:57] <cjwatson> my client doesn't show them so it's tedious to check
[11:58] <cjwatson> ln-: actually, you can change the topic yourself, why not just do it
[11:58] <ln-> oh, i didn't notice there's no mode +t here.
[12:00] <ln-> now the spaces are gone.
[12:00] <soren> Er...
[12:01] <soren> Yeah, and a lot of other stuff, too.
[12:01] <cjwatson> that's as may be, but you deleted a big chunk
[12:01] <cjwatson> should be better now
[12:04] <ln-> sorry, had to copy-paste manually because the spaces-or-whatever-characters were confusing irssi. missed a line.
[12:09] <ln-> this is what happens when non-critical bugs are fixed.
[12:11] <james_w> Keybuk: I'd love it if patches.ubuntu.com started updating again as well, I find it invaluable during merging. Thanks.
[12:14] <pochu> cjwatson: hi, there's no intrepid-changes list created yet, will there be one once intrepid is opened so that uploads to intrepid are recorded there?
[12:14] <pochu> cjwatson: nevermind, I missed it :/
[12:14] <sistpoty|work> pitti: thanks for fixing hardy-proposed :)
[12:14] <pochu> https://lists.ubuntu.com/mailman/listinfo/Intrepid-changes
[12:14] <Ng> ./win 52
[12:14] <Ng> gar
[12:15] <cjwatson> (should work lower-case too)
[12:15] <pitti> sistpoty|work: wasn't me, thank cprov; now the publisher actually needs to run, then we shuold be ready to go
[12:15] <sistpoty|work> thanks cprov ^^ :)
[12:15] <cjwatson> pochu: the -changes list is a prerequisite for getting the distroseries created properly in Launchpad, so it's always there first, FYI
[12:29] <calc> pitti: sorry was away
[12:30] <calc> pitti: family matters were bothering me which has since been mostly resolved :)
[12:30] <calc> combined with the fact that i have been feeling ill for the past several days
[12:31] <calc> not sure why i have been having trouble sleeping the past week though, before sat i wasn't feeling sick
[12:31] <calc> maybe due to the weird hours getting ready for the release, heh
[12:32]  * calc bbiab going to get breakfast
[13:23]  * pitti hugs calc, all the best then!
[13:24] <pitti> cprov: hm, publisher should long be done now, but http://archive.ubuntu.com/ubuntu/dists/hardy-proposed/main/binary-i386/Packages.gz is still empty :(
[13:25] <calc> yummy that was good :)
[13:25] <pitti> cprov: argh, apparently pinging you helped -- after that very second it worked
[13:26] <pitti> cprov: i. e. the indexes are now non-empty, but packages themselves are still 404
[13:26] <cprov> pitti: in drescher ?
[13:26] <pitti> cprov: but I guess that's just the normal mirroring delay (although they could really mirror /pool first, and then /dists)
[13:26] <pitti> cprov: no, on archive.u.c.
[13:26] <pitti> cprov: drescher was ok since Friday
[13:27] <pitti> aah, it caught up now
[13:27] <pitti> happy hardy-proposed upgrading, everyone!
[13:27] <cprov> pitti: :)
[13:29] <\sh> good bye edgy-changes , welcome intrepid-changes
[13:31] <emgent> :)
[13:52] <Hobbsee> slangasek: so, why is there no obvious way to get a dvd version of ubuntu?
[13:52] <Mithrandir> Hobbsee: because bandwidth is expensive.
[13:53] <Hobbsee> Mithrandir: i realise that, but i would have expected it to be listed in a corner somewhere, or something.
[13:53] <Mithrandir> Hobbsee: or you could go for the alternative that we hate freedom.
[13:54] <cjwatson> I think it goes with bug 122229; added a comment
[13:54] <ubotu> Launchpad bug 122229 in ubuntu-cdimage "add pointers on cdimage.u.c to releases.u.c" [Medium,Confirmed] https://launchpad.net/bugs/122229
[13:54] <cjwatson> (http://cdimage.ubuntu.com/releases/8.04/release/ FWIW)
[13:57] <Hobbsee> cjwatson: ah, thanks
[14:49] <_lemsx1_> I'm sure you guys are happy with the release of Hardy. I just wanted to say Thanks to all of you who make this distribution possible! Hopefully by now you are sober ;-)
[14:51] <Hobbsee> never!
[14:51] <Hobbsee> at least, for those who actually drink.
[14:51] <ScottK> Doesn't really matter.  There's nothing I'll do drunk that I won't also do sober.
[14:52] <_lemsx1_> good one! LOL ... well, after you get better, there is always work to be done ;-)
[14:52] <_lemsx1_> ScottK: not even driving?
[14:53] <ScottK> There are things I won't do drunk and there are things that I will do sober that I won't do drunk, but AFAIK there is nothing I'll do drunk that I won't also do sober.
[14:53] <ScottK> This is a challenge to live up to sometimes.
[14:53] <_lemsx1_> well, always make sure that you drink the finest and that you keep your livers healthy
[15:29] <calc> do we ask users for disk labels when creating filesystems during install?
[15:30] <calc> er not disk labels, but names for the filesystems
[15:30] <cjwatson> calc: not by default, no
[15:30] <calc> cjwatson: ok
[15:30] <cjwatson> you can set them in the alternate installer if you work at it
[15:30] <cjwatson> ubiquity doesn't expose UI for that at the moment
[15:30] <calc> that might be useful in that it displays the label instead of the "XX.X GB Media" if you do label it
[15:31] <calc> i noticed that and then saw reference to it in that install report on the mailing list from earlier today
[15:31] <cjwatson> aye
[15:31] <calc> of course that doesn't help the users who didn't label their windows partitions, but at least the linux ones will be good :)
[15:36] <calc> synaptic doesn't remove users dotfiles does it?
[15:36] <Amaranth> no
[15:36] <calc> ok wanted to make sure before i told a user that
[15:37]  * calc never uses synaptic
[15:37] <ogra> packagemanagers generally dont do that :)
[15:37] <Amaranth> If a package ever touches anything in ~ the packager needs to be shot :)
[15:37] <ogra> ++
[15:37] <mvo> calc: its just a fancy apt frontend, it behaves pretty much like apt
[15:37] <calc> Amaranth: yep :)
[15:37] <calc> mvo: thats what i thought :)
[15:37] <cjwatson> I'd actually like there to be a standard way for a package to declare which dotfiles it creates, so that it could in theory be cleaned up, although that absolutely mustn't happen without explicit acknowledgement
[15:37] <mvo> :)
[15:38] <calc> mvo: a user was claiming a complete uninstall via synaptic would remove the dotfiles and so i told him it does not
[15:38] <cjwatson> if it were in the control metadata then you could write a UI that did it
[15:38] <Amaranth> I have wished a few times I could wipe out some compiz settings :)
[15:38] <cjwatson> though it might have to declare things like gconf paths as well as simple $HOME-relative dotfiles
[15:39] <mvo> Amaranth: indeed :)
[15:39] <cjwatson> it would be very much preferable for it to be declarative rather than imperative though
[15:39]  * calc wants the awesome crack of xdg dirs to be used :-)
[15:39] <calc> then just rm -rf ~/.config
[15:39] <cjwatson> aside from it being crack, that doesn't help when you only want to clean up configuration from certain packages, rather than blowing the whole lot away
[15:40] <cjwatson> so only fulfils a very specific use case
[15:40]  * ogra thinks ~/.config is just a lame way of hiding configs from your homedir
[15:40] <cjwatson> I don't think most people want to blow away their mail configuration when their problem is just that OOo is misbehaving (for example)
[15:40] <Keybuk> ogra: that's what the "." is for
[15:40] <calc> cjwatson: it still helps in that only general config stuff would be under .config, eg things like huge .evolution dir would be more sanely split up
[15:41] <seb128> Amaranth: I think we should get some user configuration cleaner for updates
[15:41] <ogra> Keybuk, well, but it contains stuff that would otherwise sit in ~
[15:41] <cjwatson> I have no objection to .cache or whatever it was, but (as argued before at length) I think .config is silly
[15:41] <calc> so configuration pertinent to accounts would not be under .config
[15:41] <ogra> Keybuk, it just moves them down one level
[15:41] <seb128> calc: there is a blueprint about allowing renaming volumes in nautilus which would update the label
[15:41] <seb128> calc: pitti didn't manage to work on that this cycle but maybe next one
[15:42] <calc> cjwatson: actual mail account configuration would be considered data which wouldn't go under .config, but individual settings that aren't important (overall) for evolution would go under .config
[15:42] <calc> seb128: ah ok :)
[15:42] <cjwatson> calc: that's a bizarre definition of configuration
[15:42] <seb128> upstream has also some discussion about allowing the customize the display name
[15:42] <calc> seb128: that would be better than being in the installer anyway
[15:42] <seb128> ie, having a field in the .mount for that
[15:42] <cjwatson> "configuration is data, other stuff goes into .config" eh?
[15:42] <ogra> heh
[15:43] <calc> cjwatson: account specific configuration would be considered data, iirc it was discussed in the evolution xdg bug upstream already
[15:43] <cjwatson> I think this just goes to show how broken the xdg home directory specification is
[15:43] <calc> everything not specific to the way the account was setup would go under .config
[15:44] <cjwatson> the problem is that the contrary viewpoint is hard to express in a specification because it amounts to "dotfiles are fine just the way they are, please leave them alone" which doesn't make for a good XDG spec ;-)
[15:44] <calc> most apps configuration can be blow away without any long term consequence, blowing away email account setup information is different
[15:44] <Keybuk> I don't even understand _why_ we need the xdg home directory specification
[15:45] <cjwatson> it seems totally bizarre to me that configuration would be regarded as something you might want to blow away as a matter of routine
[15:45] <cjwatson> we go to such lengths to preserve it
[15:45] <calc> we didn't really need FHS either, but it made things a lot cleaner and easier to deal with
[15:45] <calc> things like OOo still don't care about FHS (argh)
[15:45] <Keybuk> calc: FHS documented existing practice
[15:45] <calc> Keybuk: /srv ?
[15:45] <Keybuk> whereas the XDG thingy invents something totally new and contrary
[15:45] <calc> there are bits of FHS that were invented
[15:45] <Keybuk> calc: 99% of the FHS concerns things like /usr
[15:45] <ScottK> and Windows like (xdg)
[15:45] <calc>  /srv being a prime example
[15:46] <cjwatson> rm -rf .config is little different from rm -rf ~/.[A-Za-z]*; nothing in one's dotfiles is more valuable than configuration
[15:46] <Keybuk> imagine if the FHS suddenly, one day, said we needed /Programs and /Libraries
[15:46] <Keybuk> instead of /usr
[15:46] <cjwatson> (cached data, for example, is less valuable)
[15:46] <Keybuk> that's the level of change the XDG stuff introduces
[15:46] <Keybuk> for less discernible benefit
[15:46] <calc> cjwatson: all email in evolution is in a dotdir
[15:46] <cjwatson> I think that is also a bug :-)
[15:46] <calc> cjwatson: unless you use imap (like me)
[15:46] <persia> (and a world-readable dotdir by default)
[15:46] <cjwatson> my mail lives in ~/mail
[15:47] <calc> Keybuk: it said we need lib32 on ia64 and lib64 on amd64, equally insane things ;-)
[15:47] <Keybuk> calc: no, the LSB said that
[15:47] <calc> oh yea i got the two confused, sorry
[15:47] <cjwatson> the FHS makes it easier to share files among machines, at least in theory (hence the /usr/share thing)
[15:47] <Keybuk> and I have quite negative feelings towards the LSB :)
[15:47] <Keybuk> but I get told off for sharing them
[15:48] <calc> ok :)
[15:48]  * calc thinks we should get multiarch done and into LSB
[15:48] <calc> cjwatson: though we have no arch indep configuration dir :\
[15:48] <cjwatson> XDG homedir makes it impossible to NFS-share your home directory among machines, because if applications ever start gradually transitioning towards XDG homedir then each application in turn will break depending on relative versions of applications between operating systems
[15:49] <cjwatson> calc: in the past, I have successfully shared home directories between wildly variant operating systems, including completely different variants of Unix and completely different architectures
[15:49] <cjwatson> it really isn't difficult
[15:49] <cjwatson> the only thing that required any work at all was .bashrc (for terminal setup) and a couple of C programs in ~/bin which could easily be dealt with by an ad-hoc architecture-dependent directory
[15:50] <calc> ok
[15:50] <cjwatson> as far as I can see, the XDG home directory specification was written by folks who had never done this or considered it valuable
[15:50] <calc> applications do change their files around (esp KDE at least used to be like this) often enough that sharing between versions was hard
[15:51] <cjwatson> and certainly there are some applications that are quite sensitive about the contents of /home, but it's easy enough to control those and generally you only run those on the machine that's running your X server and/or desktop environment
[15:51] <cjwatson> most applications do not suffer from this problem, in my experience
[15:51] <cjwatson> but XDG homedir proposes moving all their configuration files anyway, thus *forcing* them to break in order to comply, even if they've otherwise been stable for a decade
[15:52] <cjwatson> if you're sharing a home directory, many of the applications you run on the machines other than the one hosting your desktop environment are in fact ones that have been stable for years
[15:52] <cjwatson> I don't see KDE as an issue, because you don't ssh to that server over there and start a KDE program :)
[15:53] <calc> heh :)
[15:54] <cjwatson> but you do start a shell, a revision control tool, an editor, maybe a command-line mail client, etc., all of which have dotfiles
[15:55] <cjwatson> so it probably doesn't matter if the desktop environments decide to move to .config (because as you say it was hard to share things like gconf anyway), but I think we need to oppose the whole operating system following suit
[15:55] <calc> if they properly support upgrades it shouldn't be an issue(?)
[15:56] <cjwatson> "they"?
[15:56] <calc> where they use the old files if they exist otherwise create new ones in the xdg location?
[15:56] <calc> they being whatever app transitions to xdg
[15:56] <cjwatson> it is an issue because if you're sharing a home directory among lots of machines you do not upgrade them all at once
[15:56] <cjwatson> usually it is completely infeasible to do so
[15:56] <calc> assuming the file exists in the home dir it would not get recreated/removed unless the user deleted the dotfiles?
[15:57] <cjwatson> now suddenly you have to keep two versions of the file in sync
[15:57] <calc> there wouldn't be two versions of the file in the NFS homedir case, afaict
[15:57] <cjwatson> why not?
[15:57] <ogra> indeed you want your settings to be the same on all machines you mount your home on :)
[15:58] <cjwatson> also, this is fairly complex code that you have to introduce into every application with a dotfile
[15:58] <calc> old app uses old file location, new app sees old file location and uses that, doesn't write new file since it has no need
[15:58] <cjwatson> more lines of code == more bugs
[15:58] <ogra> calc, but both apps should have the same settings
[15:58] <calc> it would at minimum have to move the file to be upgradable though, so not too much more code
[15:58] <ogra> meaning that "new app" needs to maintain duplication
[15:58] <calc> ogra: they would be using the same file so would be
[15:58] <cjwatson> unacceptable new code
[15:58] <cjwatson> seriously
[15:59] <cjwatson> moving the file would break old versions of the application
[15:59] <calc> cjwatson: code to check what path to use for the configuration, thats a couple lines at most
[15:59] <ogra> calc, that doesnt guarantee that a setting i change in "new app" is used by "old app"
[15:59] <cjwatson> calc: why put the effort in to add that code to thousands of different applications?
[15:59] <calc> cjwatson: the moving bit would be assuming they would transition to xdg at all and decided not to support multiple versions using the same config file
[15:59] <cjwatson> if you're talking about this at an operating system level, that's what's involved
[15:59] <ogra> the new one needs to adjust the old settings in the dotfile as well as the xdg config to achieve that
[15:59] <cjwatson> it's a completely unacceptable amount of work to invest across the board
[16:00] <calc> cjwatson: i'm just talking about what it would take for an individual developer to port their own app, not doing at an os level
[16:00]  * calc doesn't think OS people should be doing this work themselves
[16:01] <calc> changing large amounts of code without upstream support for anything not just this is a bad idea, unless you want to maintain huge patches forever
[16:01] <cjwatson> calc: people manage to introduce security bugs due to string concatenation in C; I see no reason why checking multiple file locations (involving querying an environment variable for the location and falling back to the default, then concatenating strings) wouldn't introduce bugs
[16:02] <cjwatson> there has to be a serious benefit that's more than just aesthetic
[16:02] <cjwatson> now, that cache directory tagging standard was good
[16:02] <ScottK> So far the only benifit I've realized from the XDG changes is I have to reset a bunch of apps to point back to where I want them to point (where they were before).
[16:02] <cjwatson> http://www.brynosaurus.com/cachedir/
[16:02] <calc> oh btw do you happen to know if we are going to be supporting the new deb source formats soon?
[16:03] <calc> apparently they now (or will soon?) support different source formats than just diff.gz
[16:03] <cjwatson> I'd like to, but haven't spoken with the Soyuz guys yet
[16:03] <cjwatson> I don't think we should dive in straight away though, they're still explicitly experimental
[16:03] <calc> we probably need Soyuz support by the time lenny ships
[16:03] <calc> since aiui dd's will be allowed to use them at that point
[16:03] <ogra> for 9.04 then ?
[16:03] <cjwatson> I don't think the Debian archive will permit them for lenny; have you heard something to the contrary?
[16:04] <calc> cjwatson: lenny+1 which will be later this year(?)
[16:04] <cjwatson> the Debian archive team aren't usually notably neophilic :)
[16:05] <calc> well lenny releases later this year is what i mean, at which point i think dd's will be allowed to use the new format for lenny+1
[16:05] <cjwatson> oh, I see
[16:05] <calc> so if we sync from sid after lenny we will need to support the new format
[16:05] <cjwatson> right
[16:05] <cjwatson> I don't think the Soyuz changes are likely to be particularly hard
[16:05] <cjwatson> though I suspect it would involve database changes
[16:05] <calc> so we probably need to get soyuz people to get it working as soon as the new format is stable (if it isn't already)
[16:05] <cjwatson> (there's an enum type in there that has .dsc, .diff.gz, etc.)
[16:06] <cjwatson> I don't think it's stable yet, no
[16:06] <cjwatson> (I wrote the 3.0 (bzr) format and have been vaguely keeping an eye on it)
[16:06] <calc> ok
[16:07] <cjwatson> though I know buxy is pushing 3.0 (quilt) pretty hard
[16:07] <calc> so will there be multiple final formats (bzr/quilt/etc) or just one that will be picked?
[16:08]  * calc hasn't read that much about it yet
[16:08] <buxy> there's no answer for that yet
[16:08] <buxy> it depends on ftpmasters
[16:09] <buxy> ajt wanted to allow multiple formats (he's fond of the git one in particular) but he's no more ftpmasters
[16:09] <calc> yea i saw that :-\
[16:09] <buxy> I would prefer if we started by only allowing the quilt (which is really wig&pen enhanced) + native
[16:09] <buxy> ones
[16:10] <cjwatson> I'd obviously prefer to be able to use any of them (eventually) ;-)
[16:11] <buxy> I would prefer to keep the .dsc as a snapshot of sources, but I'd like to have official centralized repositories that can be used to maintain packages
[16:11] <calc> is there a page that explains how the new formats work?
[16:11] <buxy> where we can release just by pointing to a tag or something like that
[16:12] <buxy> calc: man dpkg-source with a recent dpkg-dev
[16:12] <buxy> (1.14.17/18)
[16:12] <buxy> http://people.debian.org/~hertzog/dpkg-source.html
[16:12] <calc> ah hardy is too old
[16:12] <cjwatson> buxy: certainly what we'd like to have in Ubuntu, by way of active importing of the world into bzr
[16:12] <calc> thanks for the url
[16:15] <calc> am i wrong in intrepeting format 3.0 as just allowing eg diff.lzma diff.bz2 and turning on the -I options for vcs?
[16:15] <buxy> there's no .diff in 3.0
[16:16] <calc> oh
[16:16] <buxy> there's a debian tarball in 3.0 (quilt)
[16:16] <calc> er 3.0 native i mean then
[16:16] <calc> sorry dropped the native part
[16:16] <calc> of native means debian native (eg 1.0 not 1.0-1)
[16:16] <calc> s/of/oh/
[16:16] <buxy> native is like native right now, a single tarball
[16:16] <calc> ok i see :)
[16:17] <buxy> but yes it's native like now except that you can use tar.bz2  and .tar.lzma
[16:17] <buxy> and that it will ignore some files by default
[16:18] <calc> so this component bit, why was it decided to extract them into subdirs based on name instead of just in the top level of the tree?
[16:18] <calc> seems component orig's have been made less useful that way
[16:19] <seb128> buxy: no diff means that you have to upload the whole source every time?
[16:19] <buxy> I simply took the wig&pen specification for that part, but I don't see it as a big problem
[16:19] <buxy> calc: what use case do you see?
[16:19] <buxy> seb128: of course not, you upload only the debian tarball (ie the content of the debian directory)
[16:20] <calc> well it probably couldn't be used for OOo anyway, but in OOo's case we have multiple tarballs that all extract into the same top level build dir
[16:20] <cjwatson> seb128: it's a diff, just not a .diff ;-)
[16:20] <seb128> ah :-)
[16:20] <calc> currently we put them all in one .orig and then unpack them during build
[16:21] <calc> i'm just not sure of what use cases having separate component origs that are named after the component is actually useful, but i'm sure there are at least use cases :)
[16:21] <buxy> calc: what do they contain those tarballs? multiple directories each?
[16:21] <calc> buxy: yes
[16:22] <calc> OOo is gross don't worry about it too much ;-)
[16:22] <calc> some of the tarballs unpack all over the place into existing dirs from other tarballs as well, eg the i18n one
[16:22] <buxy> well, not many software use multiple tarballs, if the feature doesn't work for them, it's a bit sad :)
[16:24] <calc> for git/bzr formats does that mean the tarball is the entire repository?
[16:24] <calc> "The tarball is unpacked and then the VCS is used to checkout the current branch. "
[16:24] <buxy> currently yes
[16:24] <calc> wouldn't that make really HUGE orig's ?
[16:25] <buxy> it depends on the software of course, it's one of the problems with those formats
[16:25]  * calc imagines doing this with OOo and having terabyte orig files ;-)
[16:25] <buxy> and the other problem is that you have no .orig and thus reupload everything each time
[16:26] <calc> i'm not sure if the exceedingly large size of the bzr/git tarballs would make them ever really a good idea
[16:26]  * calc probably is missing something though
[16:26] <jdong> calc: it probably shouldn't have to be completely transferred each time
[16:27] <jdong> calc: and git/bzr both are working on "partial history horizons"
[16:27] <buxy> until we have "shallow clones" in bzr (like in git)
[16:27] <Mithrandir> jdong: nuking history in git is simple enough.
[16:27] <jdong> calc: not to mention at some times the git/bzr storage format for complete history is not much larger than a full checkout
[16:27] <buxy> jdong: but nobody implemented the code in dpkg to generate such partial repositories yet
[16:28] <calc> jdong: ah very shallow history would be useful yea :)
[16:38] <sistpoty|work> any archive admin around, who could copy xmms-crossfade to hardy-updates from hardy-proposed (bug #208666)?
[16:38] <ubotu> Launchpad bug 208666 in xmms-crossfade "audacious crashed with SIGSEGV in g_type_check_instance_cast()" [Medium,Fix committed] https://launchpad.net/bugs/208666
[16:49] <xhaker> jdong: updates on transmission? it seems you haven't found the time to upload the menu fix
[16:53] <hwilde> Keybuk, time for a udev question?
[16:53] <Keybuk> hwilde: of course?
[16:54] <hwilde> Keybuk, can I do udevs for the usb inputs?  the ttyUSB?  switches every reboot    http://pastebin.com/m750bddea
[16:54] <hwilde> it's like udevinfo doesn't get enough info to make distinct rules
[16:54] <Keybuk> persistent names?
[16:54] <Keybuk> yeah you could use udev to do that
[16:54] <hwilde> on reboot it re-enumerates /dev/ttyUSB0 through USB6 to different places
[16:55] <hwilde> udevinfo only sees USB_BUS and USB_DEV and this is not persistent
[16:55] <Keybuk> what does udevinfo -a -n ttyUSB0 give you?
[16:55] <Keybuk> (nopaste)
[16:56] <hwilde> the way I do it now is I run readlink -fn and then I parse the physical mapping
[16:56] <DB42> will mono 1.9.1 get into ubuntu 8.04 ? is so, when, if not, why ?
[16:56] <Keybuk> DB42: ubuntu 8.04 is released already
[16:56] <persia> How does udev differentiate equipment with the same vendor:model string and same characteristics?
[16:56] <Keybuk> persia: example?
[16:56] <DB42> Keybuk: so it's a version freeze till 8.10 ?
[16:56] <Keybuk> DB42: exactly
[16:56] <persia> Keybuk: Two identical serial converters.
[16:57] <DB42> that totally sux :(
[16:57] <Keybuk> persia: probably no way to distinguish them then
[16:57] <hwilde> persia, Keybuk, yeah check my pastebin that is my question I guess
[16:57] <persia> Keybuk: Thanks for the confirmation.
[16:57] <Keybuk> hwilde: can you provide the output of that command?
[16:57] <Keybuk> DB42: that's the _whole_point_of a release?
[16:57] <hwilde> Keybuk, it doesn't work are you sure that is th right syntax
[16:57] <Keybuk> DB42: it represents the end of work on a particular version, and when we begin on the next
[16:57] <Keybuk> hwilde: what does it say?
[16:58] <hwilde> Keybuk, attribute walk on device chain needs path(-p) specified
[16:58] <DB42> will there be a backport or so ?
[16:58] <Keybuk> hwilde: ? which version of udev/ubuntu?
[16:58] <Keybuk> DB42: maybe, if you ask someone on the backports team
[16:58] <persia> hwilde: It worked for my serial device.  Are you sure you typed `udevinfo -a -n ttyUSB0`?
[16:58] <hwilde> ah this is an older system
[16:58] <hwilde> grub defualt :/
[16:58] <Keybuk> hwilde: try -a -p /class/tty/ttyUSB0 instead
[17:01] <hwilde> Keybuk, http://pastebin.com/m5bb726d6
[17:02] <Keybuk> hwilde: a rule to match that exact device and call it "beetroot" would look like:
[17:02] <Keybuk>   SUBSYSTEM=="tty", SUBSYSTEM=="usb", SYSFS{serial}=="FTDD9V1Q", SYMLINK+="beetroot"
[17:02] <Keybuk> or on a modern system:
[17:03] <Keybuk>   SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{serial}=="FTDD9V1Q", SYMLINK+="beetroot"
[17:03] <hwilde> oooo unique sysfs
[17:03] <hwilde> hold on i'm rebooting into 8.04
[17:04] <hwilde>   /devices/pci0000:00/0000:00:0f.5/usb2/2-2/2-2.1/  [2-2.1:1.0]  /ttyUSB0     I was doing it by parsing the readlink part in [brackets] to get the physical mapping, then making symlinks :)
[17:07] <hwilde> Keybuk, here is "udevinfo -a -n ttyUSB0-3" on 8.04   http://pastebin.com/m40b01e94
[17:08] <hwilde> ATTRS{serial} are all the same  ATTRS{serial}=="0000:00:0f.4"
[17:08] <hwilde> that's the usb hub address
[17:08] <Keybuk> right
[17:08] <Keybuk> there's no serial number on that one
[17:09] <Keybuk> so just start from the top down adding attributes until you're happy
[17:09] <Keybuk> you'll want one from the top since you want to match the ttyUSBx device
[17:09] <Keybuk>     SUBSYSTEM=="tty"
[17:09] <hwilde> it is the same device tho
[17:09] <hwilde> [   93.464265] usb 1-1: FTDI USB Serial Device converter now attached to ttyUSB0
[17:09] <Keybuk> skip down a few until you get to the actual usb device (ones in the usb subsystem)
[17:09] <Keybuk> #
[17:09] <Keybuk>     ATTRS{idVendor}=="0403"
[17:09] <Keybuk> #
[17:09] <Keybuk>     ATTRS{idProduct}=="6010"
[17:09] <Keybuk> #
[17:10] <Keybuk> those are usually good
[17:10] <Keybuk> yeah you're looking at the serial of the usb hub
[17:10] <Keybuk> for whatever reason, that device doesn't have a serial number or it isn't being picked up
[17:11] <Keybuk> hmm
[17:11] <Keybuk> your main problem is going to be that you have three identical ftdi's :p
[17:12] <hwilde> yes
[17:12] <hwilde> here is all 6
[17:12] <hwilde> http://pastebin.com/m388fc489
[17:12] <ogra> seb128, fyi http://bugzilla.gnome.org/show_bug.cgi?id=530379
[17:12] <ubotu> Gnome bug 530379 in gio "Inaccessible mount points appear on other user's desktops" [Normal,Unconfirmed]
[17:12] <seb128> ogra: thanks
[17:12] <Keybuk> ttyUSB0 and ttyUSB1 are the same _physical_ device?
[17:13] <ogra> (i was just hunted down by warren for it)
[17:13] <ogra> seb128, it seems josselin never forwarded the old patch for gnome-vfs :(
[17:13] <hwilde> Keybuk, nope there are six distinct devices
[17:13] <ogra> else it would have taken into account before already
[17:13] <Keybuk> hwilde: I'm not sure I believe you :p
[17:14] <Keybuk> #
[17:14] <hwilde> Keybuk, hold I will show you the readlinks... that's the only way I am parsing the phsyical inputs
[17:14] <Keybuk>     KERNELS=="1-1:1.0"
[17:14] <Keybuk> #
[17:14] <Keybuk>     ATTRS{bInterfaceNumber}=="00"
[17:14] <Keybuk> (^ ttyUSB0)
[17:14] <seb128> ogra: what gnomevfs is doing would not have made a difference on gvfs, they didn't try to copy gnomevfs
[17:14] <Keybuk> #
[17:14] <Keybuk>     KERNELS=="1-1:1.1"
[17:14] <Keybuk> #
[17:14] <Keybuk>     ATTRS{bInterfaceNumber}=="01"
[17:14] <Keybuk> (^ ttyUSB1)
[17:14] <Keybuk> that to me says one device, with two interfaces ;)
[17:14] <ogra> seb128, but they try to get on par with features
[17:14] <hwilde> well yeah, that one is the hub
[17:14] <hwilde> there are two hubs
[17:14] <seb128> ogra: no, they try to fix all the issues they can
[17:15] <ogra> if it would have been fixed in gnome-vfs chances would have been greater that they implemented it from the begining
[17:15] <Keybuk> hwilde: hub with a USB serial converter?
[17:16] <seb128> ogra: might be, anyway that's a detail
[17:16] <ogra> yeah
[17:16] <ogra> they just ranted at me thyt they didnt know about it
[17:16] <ogra> (davidz specifically)
[17:17] <hwilde> Keybuk, hold on hold on I can only pastebin so fast
[17:17] <hwilde> Keybuk, http://pastebin.com/m56069e04
[17:17] <hwilde> Keybuk, see the readlink outputs?  and the MAP= part?  That much is consistent so I parse it in rc.local on boot.  but the ttyUSB? are re-assigned randomly every reboot
[17:18] <hwilde> Keybuk, so back to my original question, can I use udev to do this?  It seems like udev doesn't get enough (unique) info to make rules
[17:18] <seb128> ogra: http://bugzilla.gnome.org/show_bug.cgi?id=352381, they should read bugzilla
[17:18] <ubotu> Gnome bug 352381 in Volume and drive handling "do not show inaccessible volumes" [Normal,Unconfirmed]
[17:18] <hwilde> or maybe somebody understand how the ttyUSB? are enumerated and I could fix that part ?
[17:18] <Keybuk> hwilde: right, those should be consistent
[17:18] <Keybuk> since that's the USB tree
[17:18] <ogra> seb128, yeah, just noticed you had duplicated
[17:18] <Keybuk> 6 hanging off one hub
[17:18] <ogra> heh
[17:18] <Keybuk> 1 on the other hub
[17:19] <hwilde> Keybuk, yes it's disgusting...
[17:19] <Keybuk> still looks like you have four physical devices there
[17:20] <hwilde> Keybuk, here is one with 7 http://pastebin.com/m750bddea
[17:20] <seb128> ogra: I also added a comment to point to the gnome-vfs bug
[17:20] <ogra> seb128, thanks, youre a hero
[17:20] <seb128> np
[17:20] <Keybuk> hwilde: that's the same system?
[17:20] <seb128> ogra: and if you davidz online tell him that the gnome-vfs patch is in bugzilla for some years
[17:20] <Keybuk> looks like you just added another device on the second hub
[17:20] <hwilde> Keybuk, similar but not identical...
[17:20] <hwilde> Keybuk, same idea
[17:21] <Keybuk> hwilde: match on the kernel name then
[17:21] <Keybuk>     KERNELS=="1-1:1.0"
[17:22] <ogra> seb128, i'm proxying through warren (from which i hear once a week at least that ubuntu never sends stuff upstream) thanks for giving me ammo :)
[17:22] <xhaker> jdong: I'm doing a merge from debian unstable, they use quilt in the packaging now.
[17:23] <seb128> ogra: yeah, they like to complain about that
[17:23] <hwilde> Keybuk, ATTRS{serial} plus the KERNELS woudl basically give me the mapping "mastermodule" "0000:00:0f.4/.*/1-3:1.0"
[17:23] <ogra> seb128, which is quite funny in #ltsp ... since they just steal all my stuff into fc9
[17:27] <hwilde> Keybuk, should I make this 50 because it's user defined or 60 because i'm making symlinks
[17:27] <Keybuk> whichever suits your fancy
[17:27] <Keybuk> hwilde: right
[17:28] <Keybuk> PCI name of the USB bus will be constant given no hardware change (the 0000: bit)
[17:28] <Keybuk> and the USB device name will be constant given no recabling
[17:29] <seb128> pitti: when will you update the language packs in hardy?
[17:30] <hwilde> Keybuk, so in this example http://pastebin.com/m56069e04, to match     "laser" "0000:00:0f.5/.*/2-2.2:1.0"   it would be
[17:30] <hwilde> Keybuk,    SUBSYSTEM=="tty", SUBSYSTEM=="usb",  KERNELS=="2-2:1.0",    ATTRS{serial}=="0000:00:0f.4"
[17:31] <hwilde> SYMLINK+="laser"
[17:31] <hwilde> f.4/f.5  typo
[17:32] <Keybuk> SUBSYSTEMS on the second one
[17:32] <Keybuk> actually
[17:32] <hwilde> mundane detail :)
[17:32] <Keybuk> are you writing this rule for 8.04
[17:32] <Keybuk> or some other version?
[17:32] <Keybuk> no, VERY IMPORTANT detail
[17:33] <hwilde> not an office space fan I see
[17:33] <hwilde> yes that was for the old pastebin
[17:33] <Keybuk> not sure I know what the rule for non-8.04 would look like
[17:33] <Keybuk> something like that though, yes
[17:35] <jdong> xhaker: (1) Cool that they use quilt, I will pull that in then (2) I'm not core-dev so I can't upload packaging of transmission anyway
[17:35] <hwilde> well I can still get   SYSFS{serial}=="0000:00:0f.5"
[17:35] <jdong> xhaker: I put the debdiff on the bug report in plenty of time to release with the proper teams subscribed and it failed to be noticed
[17:36] <hwilde> but it doesn't have the other half
[17:36] <jdong> I'm afraid at the time I did all that was in my ability to do :(
[17:36] <Keybuk> hwilde: don't use {serial} like that
[17:36] <Keybuk> use KERNELS
[17:37] <Keybuk>   SUBSYSTEM=="tty", SUBSYSTEMS=="usb", KERNELS=="1-1:1.0", KERNELS=="0000:00:0f.4", SYMLINK+="beetroot"
[17:38] <hwilde> Keybuk, ok in this example which is 8.04  http://pastebin.com/m56069e04    SUBSYSTEM=="tty",  SUBSYSTEMS=="usb",  KERNELS=="1-1:1.0",  ATTRS{serial}=="0000:00:0f.4"
[17:41] <hwilde> Keybuk, in this example which is 7.04 http://pastebin.com/m5bb726d6      SUBSYSTEM=="tty"   SYSFS{serial}=="0000:00:0f.5"     but I don't see how to get the last part?  I have to go through every machine and use unique SYSFS{serial}=="FTDW5K4C"  ?
[17:42] <Keybuk> hwilde: replace ATTRS{serial} in the last part with KERNEL
[17:42] <Keybuk> KERNELS, sorry
[17:42] <hwilde> oh ok then I can just use ID=="2-2.2:1.0"
[17:43] <hwilde> Keybuk,  8.04  http://pastebin.com/m56069e04    SUBSYSTEM=="tty",  SUBSYSTEMS=="usb",  KERNELS=="1-1:1.0",  KERNELS=="0000:00:0f.4"
[17:43] <hwilde> Keybuk,  7.04 http://pastebin.com/m5bb726d6      SUBSYSTEM=="tty"   SYSFS{serial}=="0000:00:0f.5",  ID=="2-2.2:1.0"
[17:45] <Keybuk> again, replace SYSFS{serial} with ID in that last one
[17:46] <hwilde> what's the difference ?
[17:46] <pitti> seb128: not sure; next week maybe? too soon doesn't make sense
[17:46] <hwilde> Keybuk,  7.04 http://pastebin.com/m5bb726d6      SUBSYSTEM=="tty"   ID=="0000:00:0f.5",  ID=="2-2.2:1.0"
[17:46] <Keybuk> right
[17:46] <hwilde> that's ok without SUBSYSTEMS=="usb"   ?
[17:46] <Keybuk> yeah
[17:46] <Keybuk> I'd still stick BUS=="usb" in there
[17:46] <Keybuk> for safet
[17:47] <seb128> pitti: ok, that's because of bug #197224, nautilus crashing in spanish locale when trying to duplicate a file or when you get a file conflict due to bad translations
[17:47] <ubotu> Launchpad bug 197224 in language-pack-gnome-es "nautilus crashed with SIGSEGV in g_file_query_info()" [Medium,Fix committed] https://launchpad.net/bugs/197224
[17:47] <hwilde> Keybuk,  7.04 http://pastebin.com/m5bb726d6      SUBSYSTEM=="tty",  BUS=="usb", ID=="0000:00:0f.5",  ID=="2-2.2:1.0"
[17:47] <pitti> seb128: tomorrow we should get daily packages in the PPA, which should be tested for that bug
[17:47] <pitti> seb128: (today's failed to build, I fixed that)
[17:47] <seb128> pitti: ok, thanks
[17:48] <Keybuk> hwilde: yup
[17:48] <pitti> seb128: and I'd wait until we fixed the Firefox translations (currently discussing with asac)
[17:48] <seb128> pitti: is that still your ppa or do you have a translations one now?
[17:48] <Keybuk> hwilde: you see that all you've done is pick lines from the udevinfo output
[17:48] <pitti> seb128: it has been ~ubuntu-langpack PPA for quite a while
[17:48] <seb128> pitti: otherwise maybe we can consider a manual sru for the spanish gnome language pack maybe?
[17:48] <pitti> seb128: if the daily one is tested successfully, we can copy just that, instead of the entire lot
[17:49] <pitti> (easier, IMHO)
[17:49] <hwilde> Keybuk,  umm all YOU did was pick lines from udevinfo :)
[17:49] <seb128> pitti: ok, thanks
[17:49] <Keybuk> hwilde: yes, but you can now pick the same lines for other devices ;)
[17:49] <hwilde> Keybuk, yes I can associate lol
[17:50] <hwilde> Keybuk, my serial finder script works, i'm sure I can handle doing it the *right* way now
[17:50] <Keybuk> hwilde: the reason I'm shying away from that {serial} thing is that I suspect it's a bug it's there at all ;)
[17:50] <hwilde> fair enough
[17:50] <Keybuk> that should be the hardware serial number
[17:50] <Keybuk> not the PCI ID :p
[17:51] <hwilde> Keybuk, I have 174 systems to test this on... i'll get back to you with the results
[17:55] <hwilde> Keybuk, just to be clear... the symlink is created like /dev/beetroot   right ?
[17:58] <Keybuk> hwilde: right
[18:00] <hwilde> Keybuk, could I change it to SYMLINK+="usb_serial/beetroot"  and it would make /dev/usb_serial/beetroot?  my programs are looking there already
[18:01] <Keybuk> yes
[18:01] <Keybuk> assumedly your programs aren't looking for beetroot though ;)
[18:11] <mathiaz> seb128: do we usually ship the latest gnome version in Beta ?
[18:12] <rod0009> bryce
[18:12] <rod0009> you there?
[18:12] <jdong> bryce: I've been working with rod0009 for a while on diagnosing an intel driver issue
[18:12] <jdong> bryce: no DRI devices seem to be created for his GMA950
[18:12] <hwilde> Keybuk, can I just make a new /etc/udev/rules.d/61-beetroot.rules     and it will run automagically?  I can't find any reference to what runs these
[18:12] <jdong> all config looks right
[18:12] <jdong> bryce: possibly manifestation of bug 204762
[18:12] <ubotu> Launchpad bug 204762 in linux "[Hardy] No DRI with Intel GMA 950 (aka 945GM)" [Unknown,Fix released] https://launchpad.net/bugs/204762
[18:13] <rod0009> :-$
[18:13] <rod0009> yeah all he said
[18:13] <rod0009> ^^
[18:13] <bryce> heya
[18:13] <rod0009> hey
[18:13]  * jdong watches suspensefully as our xserver-xorg-video-intel deity does his magic
[18:14] <rod0009> lol
[18:14] <hwilde> demideity
[18:14] <bryce> rod0009: can you post your Xorg.0.log and xorg.conf someplace?
[18:14] <jdong> bryce: http://pastebin.ca/1000561 xorg.0.log
[18:14] <Keybuk> hwilde: it will be used, yes
[18:14] <Keybuk> (next time the devices are inserted)
[18:14] <Keybuk> if you want to force them, run udevplug/udevtrigger/udevadm trigger
[18:15] <hwilde> nice
[18:15] <jdong> bryce: line 647 catches my eye, /dev/dri/* is empty
[18:15] <hwilde> what about the whitespace, does it have to be tab before SYMLINK
[18:15] <rod0009> http://pastebin.ca/1000556 there is the xorg.conf
[18:16] <bryce> ok xorg.conf looks good... still reviewing log
[18:17] <rod0009> sure take your time :)
[18:18] <bryce> hmm, well one thought is that if those devices are missing, it may be a kernel problem
[18:19] <bryce> I'm fairly sure xorg doesn't create anything under /dev...  I think that's all kernel business
[18:19] <rod0009> uhm what should ido?
[18:19] <jdong> bryce: see the bug I referenced, it seems relevant. Linked there is an upstream  linus-2.6 git changset for the DRM subsystem
[18:19] <jdong> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3bf48468fe84468a148e4f19465e0a725c0f977b
[18:19] <jdong> that commit
[18:20] <seb128> mathiaz: what do you mean in beta? we ship the current unstable GNOME as soon as it's available during the unstable cycle and then the stable one and updates
[18:20] <lool> doko: Hey, openjdk-6-jre-headless seems broken on lpia; /usr/lib/jvm/java-6-openjdk/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
[18:20] <hwilde> Keybuk, ah udev is freakin beautiful!!!  I can take my script out of rc.local ahahahaahahaaa
[18:20] <lool> doko: I think you specialized these dirs for amd64/i386; under lpia, it sees i386
[18:20] <seb128> mathiaz: hardy beta had 2.22.0 and hardy has 2.22.1
[18:20] <lool> doko: Do you want a bug?
[18:20] <bryce> jdong: yeah that looks on the right track
[18:21] <jdong> bryce: with that said I think fix released is the wrong status for the Ubuntu bug, should be reassigned to kernel and on the queue for the next kernel update
[18:22] <bryce> ogasawara_: you about?
[18:22] <jdong> rod0009: roughly stated, the kernel module responsible for 3D acceleration doesn't know about your flavor of the GMA950 chip
[18:22] <ogasawara_> bryce: yah, what's up
[18:22] <jdong> rod0009: we need to pull in a kernel change that introduces support for your card
[18:22] <rod0009> sounds ugly
[18:23] <rod0009> pulling stuff around
[18:23] <jdong> rod0009: can you pastebin a lspci -vvv?
[18:23] <rod0009> sure all will do all u want
[18:23] <rod0009> i*
[18:23] <bryce> ogasawara_: bug 204762 has been marked fixed, but I think there may still be work to do in the kernel to solve it
[18:23] <ubotu> Launchpad bug 204762 in linux "[Hardy] No DRI with Intel GMA 950 (aka 945GM)" [Unknown,Fix released] https://launchpad.net/bugs/204762
[18:23] <doko> lool: don't think so, the libjli.so not found thing seems to be something else, never did see this myself.
[18:23] <bryce> ogasawara_: the fix was identified and one guy confirmed it, however jdong and rod0009 are having the same problem still
[18:23] <doko> is this a live CD?
[18:23] <rod0009> jdong wheres that file
[18:24] <lool> doko: Happens during postinst
[18:24] <lool> doko: No, on a live system
[18:24] <jdong> rod0009: it's a command
[18:24] <lool> doko: NB: I do have the lib in this package though openjdk-6-jre-headless: /usr/lib/jvm/java-6-openjdk/jre/lib/i386/jli/libjli.so
[18:24]  * bryce rereads bug
[18:25] <bryce> ohhh, got it - it's marked fixed upstream now, but the patch hasn't been applied to Ubuntu
[18:25] <rod0009> like this? rodrigo@rodrigo-laptop:~$ lspci-vvv
[18:25] <rod0009> bash: lspci-vvv: orden no encontrada
[18:25] <jdong> rod0009: space
[18:25] <rod0009> ok will bin paste
[18:25] <bryce> ogasawara_: so I think this one may be an easy bug - if you can get the kernel team to incorporate that patch, it should solve it
[18:26] <lool> doko: + /usr/lib/jvm/java-6-openjdk/bin/java -client -Xshare:dump
[18:26] <jdong> rod0009: nvm I got it.
[18:26] <lool> Is what fails
[18:26] <jdong> from his Xorg.0.log:
[18:26] <jdong> #
[18:26] <jdong> (II) PCI: 00:02:0: chip 8086,27ae card 103c,30d5 rev 03 class 03,00,00 hdr 80
[18:26] <jdong> 0x27AE is the ID we need
[18:26] <jdong> and it *exactly* the ID that git changeset http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/char/drm/i915_drv.h;h=675d88bda066312f5092a8e9b5443b31e76910d4;hp=c10d128e34dbd08beb949eef706d3ab11cee3a71;hb=3bf48468fe84468a148e4f19465e0a725c0f977b;hpb=164fc5dcd6a1026fc713f5c63fad899aa484888c adds.
[18:26] <ogasawara_> bryce: sure, I'll milestone it for 8.04.1
[18:26] <jdong> ogasawara_: thanks, you rock! :)
[18:27] <bryce> ogasawara_: excellent thanks
[18:27] <ogasawara_> jdong: care to post a quick comment to the lp bug report
[18:27] <jdong> rod0009: I'd recommend to subscribe to that Ubuntu bug for e-mail updates
[18:27] <jdong> ogasawara_: will do
[18:27] <doko> lool: how much memory do you have?
[18:27] <lool> MemTotal:      1025840 kB
[18:27] <doko> +s swap
[18:28] <doko> and FreeMem?
[18:28] <lool> doko: -/+ buffers/cache:     211812     814028
[18:28] <rod0009> sowhat i should do now guys
[18:28] <lool> So 800 MB
[18:29] <doko> lool: can you rerun this without directing the output to /dev/null?
[18:29] <jdong> rod0009: unfortunately at this time, wait for a kernel update or see if any kernel folks would be kind enough to spin a PPA kernel for you
[18:29] <mathiaz> seb128: nv - I've found the answer
[18:30] <rod0009> what is a ppa¿?
[18:30] <jdong> rod0009: an APT repository system hosted on Launchpad
[18:31] <rod0009> :'(
[18:32] <rod0009> how long does the kernel updates take?
[18:32] <lool> doko: Same thing
[18:32] <lool> doko: You have IPv6?
[18:32] <lool> doko: I can give you access to the device
[18:33] <jdong> rod0009: well the 8.04.1 release is scheduled early june AFAIK
[18:34] <rod0009> oh so theres no way im getting visual effects lol
[18:34] <jdong> rod0009: unless you rebuild a kernel with that patch
[18:34] <rod0009> i see
[18:34] <rod0009> bad luck
[18:34] <seb128> jdong: early july rather
[18:34] <jdong> rod0009: unfortunately that's not something I have the time to do right now for you
[18:34] <rod0009> maybe i should try a older version?
[18:34] <seb128> jdong: or that's what the wiki says, you might have better informations ;-)
[18:34] <jdong> rod0009: but if you catch me some other day I might feel in the mood..
[18:34] <rod0009> 7.0?
[18:35] <jdong> seb128: I heard June today, I never checked myself :D
[18:35] <rod0009> jdong and if i change to 7.0?
[18:35] <rod0009> would it be fixed?
[18:35] <jdong> rod0009: trying 7.10 might be worth your time
[18:35] <rod0009> uhm
[18:35] <jdong> rod0009: I recall reading that this is a regression from our last release
[18:35] <jdong> "I dont know where the problem is, because in 7.10 it was allright."
[18:36] <jdong> rod0009: yeah; confirmed, it will work in the Gutsy Gibbon release
[18:37] <rod0009> can i damage any hardware working like this?
[18:37] <rod0009> i dont feel like formating again
[18:37] <jdong> rod0009: no
[18:37] <jdong> rod0009: you just lack the ability to use 3D acceleration until this bug is fixed in Hardy
[18:37] <jdong> rod0009: people have lived through worse handicaps ;-)
[18:38] <rod0009> lol
[18:38] <rod0009> this only happens to me lol
[18:39] <rod0009> me and my luck
[18:44] <lool> doko: Hmm I recall StevenK changed something with our unionfs for java now
[18:45] <lool> StevenK: Hey, is your ume-config-common change for squashfs related to the bug I'm seeing?
[18:45] <lool> StevenK: /usr/lib/jvm/java-6-openjdk/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
[18:58] <ted1> How could a python program segfault?
[19:02] <mathiaz> seb128: gah - there are 51 pages on the ubuntuforums thread "HOWTO: Setup Samba peer-to-peer with Windows"
[19:02] <persia> ted1: Any of a segfault in the underlying library, in python, or the program trying to be lower level than it ought.
[19:03] <mathiaz> seb128: actually - 58 pages
[19:05] <ted1> persia: Hmm, that's not good.  I'm using d-feet, which is basically DBUS and GTK+... not good libraries to have problems.
[19:06] <Mithrandir> the python bindings might be busted too
[19:08] <persia> By "segfault in the underlying library", I don't mean to imply a bug.  It may be that you're passing a function by reference as a callback that doesn't meet the needs of the callback in some way, etc
[19:21] <lamont> ubuntu sighting: http://xkcd.com/416/
[19:26] <ompaul> Mithrandir http://xkcd.com/413/  you said python   - you can import fix non? ;-)
[19:27] <Mithrandir> heh
[19:29] <ion_> from __future__ import ruby
[19:45] <r1ddl3r> Hello, i need to ask a question about serial I/O on Ubutu
[19:45] <r1ddl3r> can any1 help ?
[19:45] <jdong> this isn't the channel to ask random development questions
[19:46] <jdong> serial IO on Ubuntu is furthemore no different than doing so on any Linux OS
[19:46] <r1ddl3r> well oke, but i havent used I/O on Linux generaly, so i simply ask if there is some1 here to answer some of my questions or not
[19:47] <r1ddl3r> if i'm on the wrong channel sry
[19:47] <jdong> r1ddl3r: as I said, that's unfortunately off topic for this channel .This channel is for Ubuntu developers to coordinate development activity pertaining to Ubuntu itself
[19:48] <r1ddl3r> oh kk, can you point me to some other channel?
[19:49] <r1ddl3r> anyway i get the point, farewell people
[19:49] <seb128> mathiaz: what is that about?
[19:52] <dneary> Hi
[19:52] <dneary> mjg59: About?
[19:54] <tzafrir> hi, any idea where can I find a reference to the chane SYSFS -> ATTR in udev rules?
[19:54] <tzafrir> Just got bitten by it, and found nothing about it in the changelogs
[19:54] <dneary> I have a major problem with my upgraded laptop - resume doesn't work
[19:55] <dneary> I suspend fine, but the screen doesn't wake up when I resume
[19:55] <dneary> I'd love to know what causes it, and how to fix it
[19:55] <dneary> Worked fine with 7.10 and 7.04 (in fact, 7.04 was when it worked best)
[20:00] <ted1> dneary: Unfortunately things changed between all of those releases :)
[20:00] <dneary> ted1: Indeed
[20:00] <ted1> dneary: It's probably that you need some quirks that aren't configured for your laptop now.
[20:00] <dneary> I'll admit, some stuff got fixed too
[20:00] <dneary> But I've tried to stay as close as possible to vanilla
[20:01] <ted1> dneary: Do you know if there is an fdi file for your laptop?  (/usr/share/hal/fdi)
[20:01] <dneary> With 7.04 (or was it 6.10?) I had to install xrandr and get the xrandr applet working to give presentations, in 7.10 I had to reboot to windows :(
[20:01] <dneary> ted1: I'll look
[20:01] <dneary> ted1: It's a directory
[20:02] <ted1> dneary: yes, there are a bunch of files in that hierarchy.  Probably most interesting is ./information/*/*video-quirk*
[20:03] <dneary> A DTD file and three subdirectories, information, policy, preprobe
[20:03] <dneary> OK - 10freedesktop/*video-quirk
[20:05] <dneary> My model is in there
[20:05] <dneary> vbe_post and vbemode_restore are set to true
[20:06] <ted1> Hmm, then probably the quirks are wrong?
[20:06] <ted1> You can try removing your model, which goes to a default set.
[20:06] <ted1> Which is probably relatively close to what happened in previous releases.
[20:06] <ted1> It's unfortunately a little bit of trial and error right now (atleast at the level I understand it)
[20:07] <dneary> ted1: OK, thanks
[20:07] <dneary> I do know someone with the same model, maybe he's had more luch
[20:07] <dneary> luck, even
[20:08] <ted1> dneary: Steal his FDI file ;)
[20:08]  * ted1 can't wait for the day when laptop manufactures ship freedesktop.org their FDI files at design time.
[20:08] <dneary> ted1: At least now I know what the Magic File is
[20:14] <mjg59> dneary: Hi
[20:17] <Keybuk> ted1: I can't wait for the day that udev uses FDI files
[20:17] <dneary> mjg59: Hi there
[20:18] <dneary> Resume doesn't work for me, and I don't know how to find out what's wrong, or fix it :(
[20:18] <dneary> You wouldn't happen to have a Latitude D420 lying around the house, would you?
[20:18] <mjg59> dneary: Not a 420, nope
[20:18] <mjg59> dneary: But running what?
[20:18] <ScottK> dneary: I have a 430 that works fine (with Kubuntu anyway).
[20:18] <dneary> 8.04, since this afternoon
[20:19] <ted1> Keybuk: I'm transferring my e-mail over to being embedded in FDI files ;)
[20:19] <mjg59> dneary: What graphics chipset?
[20:19] <dneary> Intel
[20:19] <ted1> Joking aside, they are a good thing though.
[20:19] <dneary> i915
[20:19] <dneary> ScottK: This worked fine before upgrading :}
[20:19] <dneary> I suspect I will end up doing a fresh install, but I don't wanna...
[20:20] <mjg59> dneary: Any chance you can test from the livecd?
[20:20]  * ScottK isn't sure what the difference between a 420 and a 430 is, but it might be something to look into.
[20:20] <dneary> don't have one
[20:20] <dneary> Could start downloading it
[20:20] <dneary> Suspend/resume works from the livecd?
[20:20] <\sh> guys, the mails on post-hardy-changes ;) is it only toolchain uploads to get things for intrepid in order, or are the archives really open ?
[20:20] <mjg59> dneary: To RAM should do, yeah
[20:21] <mjg59> \sh: Topic
[20:21] <dneary> mjg59: OK - will try that tomorrow. Download underway
[20:21] <\sh> mjg59, oh well, topic handling in xchat is evil...it shows the end, but not the beginning when you join ;)
[20:21] <dneary> Your servers are getting pretty heavily battered
[20:22] <dneary> \sh: I see it all on xchat-gnome
[20:22] <mjg59> dneary: Thans
[20:22] <dneary> That contact problem's really annoying too
[20:22] <\sh> dneary, looks like I have to resize gnome to a non-readable-fontset-for-blind-people-like-me :)
[20:22] <dneary> Changing your schema between releases without a migration path... bold developers
[20:23] <dneary> I see the start with an expander
[20:24] <dneary> So let's say it works on the LiveCD, what can I do after that?
[20:28] <mario_limonciell> why are both acpi-support and pm-utils present on hardy?  are both actually used?
[20:30] <mario_limonciell> or more particularly;  why is the suspend and resume support in acpi-support still present, the other scripts for ACPI stuff clearly are still necessary
[20:40] <scorcher7> Hi, over the weekend I posted a patch to launchpad bug #173772 in atomix. The wiki said to come here and get a dev. to review the patch.
[20:40] <ubotu> Launchpad bug 173772 in atomix "about dialog won't close" [Undecided,Confirmed] https://launchpad.net/bugs/173772
[20:40] <scorcher7> This is the first patch I have ever written. Is there someone who can help me?
[20:40] <scorcher7> It is a really simple bug/patch.
[20:41] <johanbr> mario_limonciell: The suspend/resume scripts in acpi-support don't seem to be used at all.
[20:43] <mario_limonciell> johanbr, then that definitely makes for confusion
[20:43] <mario_limonciell> i personally think they shouldn't have been shipped then
[20:43] <johanbr> I noticed when I tried to make some customizations and nothing seemed to happen. :)
[20:44] <mario_limonciell> mjg59, could you comment on them at all?  Is there a reason that they are still around rather than sticking to pm-utils?
[20:44] <mario_limonciell> johanbr, so you ended up customizing in /etc/pm instead then i take it?
[20:45] <johanbr> mario_limonciell: Well, /usr/lib/pm-utils .
[20:46] <mario_limonciell> johanbr, well i suppose it depends on whether you are intending to make end system customizations or distro customizations.  /etc/pm seems like the better place to be putting them
[20:46] <johanbr> Anyway, got to go...
[20:47] <seb128> scorcher7: what wiki page says that? you should subscribe ubuntu-universe-sponsors if you have a patch, this one is not correct though
[20:49] <scorcher7> seb128: This one: https://wiki.ubuntu.com/Bugs/HowToFix
[20:50] <scorcher7> seb128: atomix is in main. do I still go to universe-sponsors?
[20:51] <seb128> scorcher7: no, ubuntu-main-sponsors in this case, still the change is not correct
[20:51] <scorcher7> seb128: my patch is incorrect? I would like to fix it. Can you tell me what is wrong?
[20:57] <seb128> scorcher7: look in gtk-demo for some example or use google maybe, I'm not sure right now but there is no reason to change the api used there, you might just need to connect a callback or something
[20:57] <mjg59> mario_limonciell: Nobody got round to deleting the
[20:58] <mjg59> m
[20:59] <mario_limonciell> considering the LTSness, perhaps doing something for the point release would be worthwhile then so this question isn't raised all the time
[21:04] <scorcher7> seb128: thank you for reading my patch and giving me advice. I had changed the api because it is what other gnome apps use (like gnome-terminal) and it made the about dialog work like the other gnome apps.
[21:05] <seb128> scorcher7: they call 10 functions rather than one? that's weird
[21:06] <scorcher7> seb128: Now I see what you mean. I made the patch in reverse by accident. Sorry.
[21:06] <scorcher7> seb128: the orginal called ten functions mine calls 1.
[21:07] <seb128> scorcher7: ah, now it makes sense then ;-) just subscribe the main sponsors then and somebody will review it, it might take some time because the archive is still frozen right now
[21:09] <scorcher7> seb128: so after I upload the correct patch I just subscribe to that mailing list and send an email to it asking for someone to sponsor the patch?
[21:09] <seb128> no
[21:09] <seb128> that's a launchpad team name, you subscribe the team and do nothing else
[21:10] <scorcher7> seb128: Okay. Thank you very much for taking the time to help me.
[21:10] <seb128> you are welcome
[21:26] <seb128> ogra: around?
[21:26] <nosrednaekim> jcastro: hey...i'm interested in doing an openweek session.
[21:27] <jcastro> nosrednaekim: I have one open session left on saturday
[21:28] <nosrednaekim> jcastro: how about a  quick tutorial on hardware debugging...how to properly use lspci, lshw, lsmod, etc.....
[21:28] <jcastro> that sounds excellent, 2000 UTC this saturday?
[21:28] <nosrednaekim> yeah...saturday's are good for me
[21:28] <jcastro> sweet, fill yourself in: https://wiki.ubuntu.com/UbuntuOpenWeek
[21:28] <jcastro> and thanks!
[21:28] <crimsun> nosrednaekim: ping me later for some notes, please.
[21:29] <nosrednaekim> crimsun: ok
[21:29] <nosrednaekim> crimsun: yeah, I don;t know the audio stuff all that well
[21:49] <rod0009> hey can anyone help me to fix a bug?
[21:51] <sladen> rod0009: yes, if you raise it https://bugs.launchpad.net/ubuntu/+filebug
[22:00] <alex-weej> seb128: got a min to chat about trackpads?
[22:02] <seb128> alex-weej: sure, though I don't know anything about those
[22:02] <alex-weej> seb128: ok so re https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/223170
[22:02] <alex-weej> basically i figure gtk has support for mouse scrolling via interpreting buttons 4 and 5 as "scroll up" and "scroll down" instructions
[22:03] <alex-weej> which are the discrete movements we already have
[22:03] <alex-weej> which are quite large
[22:04] <alex-weej> i'm thinking gtk AND xorg-input-synaptics need support for delta-based scrolling
[22:04] <seb128> ah ok, I've no idea about that
[22:04] <alex-weej> so synaptics needs to generate a hypothetical "scroll dx=16,dy=23" event kind of thing
[22:04] <alex-weej> and gtk needs to interpret it
[22:04] <seb128> for me mouse cursor movements are purely an xorg thing
[22:05] <alex-weej> yeah cursor movements are
[22:05] <alex-weej> but scrolling is different right?
[22:05] <seb128> I don't use a trackpad and I guess I don't understand the feature request
[22:05] <alex-weej> oh ok
[22:05] <seb128> well, scrolling is just a reaction to xorg events no?
[22:05] <alex-weej> yeah
[22:06] <seb128> so for me what you want there is xorg to react differently to some action
[22:06] <seb128> that will impact on events generated
[22:06] <seb128> and on how gtk will react
[22:06] <seb128> no?
[22:06] <seb128> I'm not sure what gtk hacks you want there
[22:07] <alex-weej> the code that runs when i scroll a window some amount is in gtk, not xorg, right?
[22:07] <seb128> right
[22:07] <seb128> but this code doesn't know what a trackpad is
[22:07] <seb128> it just reacts to xorg events
[22:07] <seb128> no?
[22:08] <alex-weej> so if xorg is firing these new fancy scroll dx=15,dy=-23 events
[22:08] <alex-weej> 25 times a second
[22:08] <alex-weej> gtk needs to deal with it
[22:08] <spenser> anyone know when help.ubuntu.com will be updated for hardy?
[22:09] <alex-weej> seb128: i think, i mean i have no clue. my choice of gtk and synaptics as tasks was just an educated guess
[22:09] <alex-weej> bryce: maybe you can add some info?
[22:09] <seb128> alex-weej: ok, so as said I don't know better about this so we are just both doing educated guess ;-)
[22:09] <alex-weej> ok, well i'll copy this chat onto the bug if that's OK
[22:09] <alex-weej> and chase up some more X/GTK people
[22:09] <seb128> alex-weej: might be better to take than upstream directly, maybe there is somebody reading bugzilla and knowing better ;-)
[22:10] <seb128> alex-weej: sure
[22:10] <alex-weej> seb128: thing is, it needs cooperation with xorg stuff so taking it to either X or GTK independently is gonna be pain
[22:10] <seb128> alex-weej: ok, maybe bryce has a better idea about that
[22:15] <bryce> alex-weej, seb128: sorry no better ideas offhand, but I plan on working on input devices a lot during Intrepid, so if you point me at the bug I'll add it to my todo list
[22:16] <bryce> alex-weej: fwiw, iirc synaptics is slated for being replaced by evdev in the not distant future
[22:19] <alex-weej> bryce: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/223170
[22:19] <alex-weej> keep me in the loop man, i'd like to get it working as well as it is on Mac OS
[22:19] <alex-weej> btw am i right about how cursor movement events are done?
[22:20] <alex-weej> by an update interval with deltas?
[22:22] <bryce> yup (afaik)
[22:23] <alex-weej> maybe i should hammer out a blueprint?
[22:23] <bryce> that could definitely help
[22:40] <psusi> anyone here familiar with the sysv init system?  I'm very confused because there are no corresponding K scripts to shut down services like there should be, and /etc/init.d/rc looks like it runs the kill scripts for the NEW level rather than the previous level
[22:42] <jdong> psusi: it's an "optimization" introduced like gutsy-ish?
[22:42] <jdong> psusi: where non-important K-scripts were simply removed to save shutdown time
[22:42] <jdong> edgy actually
[22:43] <psusi> well, aren't they ALL important?  I mean when you switch from runlevel 3 to say, 4, then all the daemons should be stopped no?
[22:43] <jdong> psusi: IMO yes, but apparently that's not a well-tested usecase
[22:43] <psusi> and shouldn't the K scripts for the CURRENT level ( the one being changed FROM ) be run?  not the ones for the NEW level?
[22:43] <jdong> psusi: the optimization should really only apply to runlevels 0 and 6
[22:44] <jdong> psusi: no, the K-scripts for the new level runs
[22:44] <jdong> psusi: the K-scripts are defined to run at the beginning of a runlevel
[22:44] <psusi> huh?  S should start, and K should kill no?
[22:44] <jdong> psusi: for the current runlevel
[22:44] <psusi> so if you are LEAVING a level, shouldn't those services be stopped before starting the ones for the new level?
[22:45] <jdong> psusi: S means invoke with the "start" argument, K means invoke with the "stop" argument
[22:45] <jdong> psusi: you're thinking at one level too high of logical abstraction
[22:45] <jdong> psusi: see, what your'e saying would actually make sense ;-)
[22:45] <psusi> lol
[22:45] <jdong> from an event-based runlevel switching mechanism's standpoint
[22:46] <psusi> it has been years since I looked at this stuff but I could have sworn it was supposed to run the K scripts for the current level to shut everything down, then run the S scripts for the new level to start up whatever should be running there
[22:46] <psusi> but this code I'm looking at now looks like things like sshd should continue running if I do a telinit S
[22:47] <psusi> which clearly should not occur
[22:48] <jdong> psusi: well I believe it's always been that when you switch to runlevel Y, it runs Y's K scritps, then Y's S scripts
[22:48] <jdong> I don't recall that being the case
[22:48] <jdong> not being the case rather
[22:48] <jdong> psusi: now the problem with Ubuntu cutting corners in placing K-scripts IMO is a problem.
[22:48] <psusi> I am sure that when you switch back to single user mode, sshd and X are supposed to stop ;)
[22:49] <jdong> psusi: RHEL4 here has like 30 K-scripts in runlevel S :)
[22:49] <psusi> and if sshd is only meant to run in runlevel 3, I don't recall it needing a K script in runlevel S to properly shutdown when you switch
[22:49] <psusi> hrm...
[22:49] <psusi> that totally makes my brain hurt
[22:50] <psusi> so every runlevel is responsible for killing everything that every other runlevel could have possibly left running?  wtf?
[22:50] <jdong> psusi: yeah if you literally only want it in RL3 you need to K it n RL 0,1,2,4,5,6,S
[22:50] <jdong> psusi: welcome to the world of sysvinit!
[22:50] <psusi> omg, can we please kill it?
[22:50] <psusi> ;)
[22:50] <jdong> psusi: I believe we are killing it this release cycle
[22:50] <psusi> weee!
[22:50] <jdong> sysvinit: stop on starting Intrepid ;-)
[22:51] <jdong> (I think that's my first upstart pun of the cycle)
[22:51] <psusi> well, there are no K scripts in rcS.d so that means if I do a telinit S, sshd and apache keep running then eh?  ick
[22:52] <psusi> say, I was trying to find some good syntax documentation for the upstart control files
[22:52] <psusi> could you point me to some?
[22:53] <psusi> oh wait... my bad... that's right... single user mode is rc1.d, rcS.d is system startup... looks like it does have K scripts for all the daemons
[22:53] <psusi> whew... that saves me some sanity...
[22:55] <bryce> ogasawara_: fyi - https://wiki.ubuntu.com/X/KernelWishlist
[22:57] <ogasawara_> bryce:  we'll probably want to discuss that at UDS with the kernel team
[23:22] <xivulon> lamont, ping