[00:23] 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] StFS: Have you considered installinv via OEM mode? [00:24] installing [00:24] TheMuso: hmm... not quite sure what you mean by that? [00:25] 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] StFS: I think you activate it by pressing F4 at the CD boot menu to choose OEM installer. [00:25] WHich brings up a menu with that as one of the options. [00:26] 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] TheMuso: ok... well I'll definately take a look at this :) thanks so much! [00:26] You're welcome, hope it helps. [00:27] oh I'm sure it will [00:38] how do i pack something in .deb? === RAOF_ is now known as RAOF [02:01] Hi [02:11] Hi astro76 === shadowxp2 is now known as shadowxp === gnomefre1k is now known as gnomefreak [03:21] hm. === happinessturtle is now known as nenolod === thegodfather is now known as fabbione [05:44] Hello [05:44] i need some help [06:22] Good morning [06:23] good morning [06:27] morning [07:08] hey thekorn [07:13] 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] Launchpad bug 220187 in five-a-day "add gettext support to the applet" [Undecided,In progress] https://launchpad.net/bugs/220187 [07:18] good morning dholbach, [07:18] no, I think I will not work on it for the next two or three days, so please go on:) [07:19] thekorn: ok great - will let you know how it goes [07:20] Riddell, slangasek: can either of you please peer-review/ack my hardy-proposed hal upload? (in the queue already, and bug 25931) [07:20] Launchpad bug 25931 in hal "Failed to initalize HAL." [High,In progress] https://launchpad.net/bugs/25931 [07:20] hi pitti [07:20] * pitti hugs dholbachq [07:20] and dholbach, too [07:20] :) [07:23] dholbach, do you know why I don't get notification emails when you subscribe me to a five-a-day bugreport [07:23] hello pitti [07:24] thekorn: that's because of a LP bug :-/ [07:24] hey thekorn, wie gehts? [07:25] pitti, Alles super! [07:26] dholbach, I see [07:45] dholbach, recompiling files in /usr/lib/python2.5/site-packages/fiveadayapplet/ fixes bug 222829, the .pyc files are old [07:45] 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] I don't know if this is a packaging issue and how to fix this [07:47] thekorn: that's really weird [07:47] doko: what do you think about the bug mentioned above? [08:23] seb128: do you know anything about rarian? I wonder if it is in a fit state to replace scrollkeeper for intrepid? [08:24] thekorn, dholbach: can't find a fiveadayapplet directory [08:24] 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] 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] seb128: I'll have a chat with Don. Scrollkeeper is a real pain [08:26] mdke: why? because you need to list locales? [08:26] hey seb128 [08:27] guten tag pitti ;-) [08:27] thekorn: I merged your translation changes and did a huge bunch of changes but it doesn't quite work yet :) [08:27] 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] seb128: afaik yelp doesn't use scrollkeeper now, so I think it is superfluous [08:28] 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] mdke: I'm not sure that the rarian compat tools are faster though [08:29] 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] seb128: perhaps I'll send him an email with copy to you, would that be ok? [08:29] sure [08:29] thanks [08:30] * Hobbsee waves [08:30] 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] hey Hobbsee! [08:30] mdke: I think the omf need to be changed to rarian indexes or something in the source [08:30] pitti [08:30] * Hobbsee hugs pitti [08:32] seb128: ok [08:39] thekorn: what to you mean by "old"? [08:40] doko, they are outdated, from the last version of the package [08:40] 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] thekorn: are the timestamps older? [08:42] doko, let me check this with a fresh install of the package [08:44] mvo: I've been meaning to look into that anyway, milestoned [08:44] mvo: I just cannot reproduce it on my production systems, but it seems to work on a live CD [08:45] pitti: ok, thanks === stdin_ is now known as stdin [09:08] seb128: any reason for the assignment of #223449? [09:12] doko: python segfault in the log [09:12] doko, the timestamp seems to be ok, http://paste.ubuntu.com/8466/ [09:12] doko: ah, I typed "python" as product, should have use python2.5 I guess, right? [09:13] seb128: did you look at ProcMaps? [09:14] thekorn: what does ls -lL say? [09:14] doko: the guy ran apport on gnome-system-log apparently so the apport datas are for this one [09:14] doko: which is not revelant since the issue is describe is gdesklet crashing due to a python segfault [09:15] doko, http://paste.ubuntu.com/8471/ [09:17] seb128: I'm a bit unsure how to further debug bug 211625; any idea? [09:17] Launchpad bug 211625 in gnome-vfs2 "Disk mounter lists internal hard disk partitions" [Undecided,Incomplete] https://launchpad.net/bugs/211625 [09:18] thekorn: hmm, this looks good as well [09:21] 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] 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] 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] heya tseliot [09:25] emgent: hi ;) [09:29] 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] pitti: gnomevfs-ls computer: should list the same things [09:33] seb128: ok, thanks; let's call it a feature for now :), I don't think it's actually wrong [09:34] right === spacey is now known as hbos [09:37] 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] ogra: could you make sure that cmpc is picking up the new kernel in the PPA? [09:44] 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] 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? === azeem_ is now known as azeem [09:51] Robot101: Thanks. I'll bother you gous later. [09:51] Robot101: When I learn to type properly. [09:52] amitk, oh, cool, did i386 build ? (i went to bed when lpia was there :) ) === smarter_ is now known as smarte === smarte is now known as smarter === hunger_t is now known as hunger [10:56] * cjwatson runs the necessary Big Scary Commands to publish intrepid [10:57] yooohoo [10:57] argh! [10:57] it's going to break on you. [10:58] :D [10:58] no evidence of breakage so far, touch wood [10:58] is that intrepid trepidation? ;) [10:58] hah [11:00] i guess it had it's share of breakage over the weekend. [11:00] pity [11:01] ... what broke over the weekend? [11:01] mvo: hm, bug 222182 -- isn't that supposed to have a DpkgTerminalLog attachment? [11:01] Launchpad bug 222182 in apport "package apport 0.108 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/222182 [11:01] cjwatson: when do people upload bits of the toolchain, which bits, and when, can be accepted? [11:01] cjwatson: oh, last weekend, sorry. LP went down for 14+ hours. [11:01] 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] so don't get too excited just yet :) [11:01] ah [11:02] 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] calc: NO NEW OO.O FOR YOU! [11:02] :) [11:02] OOo 3.0 Beta, yea! ;-) [11:02] accept> err, in what release? [11:02] * Hobbsee beats calc with a big stick [11:02] if it is released on time it will be on wed [11:02] cjwatson: whichever. [11:02] cjwatson: i was assuming intrepid [11:02] gcc-4.3 is likely to be first, but doko is more authoritative than I [11:03] of course then i start actually working on packaging which will probably take a little while [11:03] there'll probably be an early base-files upload which is fairly safe [11:03] * Hobbsee nods [11:03] it'll be accepting multiple uploads in tandem, i think [11:03] seeing as that was the problem lsat time [11:03] it would be better to wait for that kind of test until the toolchain is sorted, I think [11:04] 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] ahh, java-gcj-compat missing, and gcc-defaults [11:04] so you mean simultaneously accepting >1 package through the web UI? [11:04] doko: aha, thanks [11:04] cjwatson: perhaps. the worst that will happen is LP times out, and someone else has to accept the package. [11:04] cjwatson: yes [11:04] the toolchain probably needs to go in strict order, or at least it's often safer to do so [11:05] are we moving openjdk into main as well? 8-) [11:05] mvo: is that log still present anywhere, so that I could ask for it? [11:05] cjwatson: oh, i thought bits of toolchain happened in tandem, in a strict order. [11:05] so I wouldn't be comfortable with simultaneous accepts there, unless they're ones that doko says are OK to build simultaneously [11:05] fair enough [11:05] yeah, of course [11:05] Hobbsee: accept what? [11:05] but we can leave the archive frozen for a bit after the toolchain's done, to allow testing [11:05] cjwatson: that would be good, thanks [11:06] doko: NEW CRACK! [11:06] doko: (packages for intrepid) [11:06] calc: it's certainly a good possibility [11:06] calc: (you're up early) [11:07] pitti: yeah, that log should be available in /var/log/apt/term.log [11:07] why is there a zero-width no-break space in the topic? [11:08] mvo: ah, thanks [11:08] ln-: where? [11:09] cjwatson: couldn't sleep :\ [11:09] * calc thinks he managed to sleep ~ 1hr last night :\ [11:14] calc: ugh, why not? [11:16] Hobbsee: in the very begin. [11:17] does that help? I couldn't see where it was === chand is now known as chand[aw] [11:34] .win 10 [11:34] Damn. [11:52] Keybuk: could you point merge-o-matic at intrepid, please? it will exist on archive.ubuntu.com after the next publisher run [11:54] Woo! [11:55] :) [11:56] 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] oops === cjwatson changed the topic of #ubuntu-devel to: Intrepid created, frozen for toolchain | 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] * soren goes to dist-upgrade :) [11:56] There. All done :) [11:56] it'll 404 right now [11:57] like I say, needs a publisher run to trigger the mirrors. :) [11:57] cjwatson: will the publisher run in 6 minutes? [11:57] there are still several zero-width spaces in the topic. [11:57] pitti: as usual [11:57] * pitti eagerly waits for all the -proposed changes to actually turn up [11:57] ln-: where exactly? [11:57] my client doesn't show them so it's tedious to check [11:58] ln-: actually, you can change the topic yourself, why not just do it [11:58] oh, i didn't notice there's no mode +t here. === ln- changed the topic of #ubuntu-devel to: Intrepid created, frozen for toolchain | Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not 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 [12:00] now the spaces are gone. [12:00] Er... [12:01] Yeah, and a lot of other stuff, too. [12:01] that's as may be, but you deleted a big chunk === cjwatson changed the topic of #ubuntu-devel to: Intrepid created, frozen for toolchain | 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 [12:01] should be better now [12:04] sorry, had to copy-paste manually because the spaces-or-whatever-characters were confusing irssi. missed a line. [12:09] this is what happens when non-critical bugs are fixed. [12:11] Keybuk: I'd love it if patches.ubuntu.com started updating again as well, I find it invaluable during merging. Thanks. [12:14] 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] cjwatson: nevermind, I missed it :/ [12:14] pitti: thanks for fixing hardy-proposed :) [12:14] https://lists.ubuntu.com/mailman/listinfo/Intrepid-changes [12:14] ./win 52 [12:14] gar [12:15] (should work lower-case too) [12:15] sistpoty|work: wasn't me, thank cprov; now the publisher actually needs to run, then we shuold be ready to go [12:15] thanks cprov ^^ :) [12:15] pochu: the -changes list is a prerequisite for getting the distroseries created properly in Launchpad, so it's always there first, FYI [12:29] pitti: sorry was away [12:30] pitti: family matters were bothering me which has since been mostly resolved :) [12:30] combined with the fact that i have been feeling ill for the past several days [12:31] not sure why i have been having trouble sleeping the past week though, before sat i wasn't feeling sick [12:31] maybe due to the weird hours getting ready for the release, heh [12:32] * calc bbiab going to get breakfast === Tonio__ is now known as Tonio_ === davmor2 is now known as davmor2_lunch [13:23] * pitti hugs calc, all the best then! [13:24] 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] yummy that was good :) [13:25] cprov: argh, apparently pinging you helped -- after that very second it worked [13:26] cprov: i. e. the indexes are now non-empty, but packages themselves are still 404 [13:26] pitti: in drescher ? [13:26] cprov: but I guess that's just the normal mirroring delay (although they could really mirror /pool first, and then /dists) [13:26] cprov: no, on archive.u.c. [13:26] cprov: drescher was ok since Friday [13:27] aah, it caught up now [13:27] happy hardy-proposed upgrading, everyone! [13:27] pitti: :) [13:29] <\sh> good bye edgy-changes , welcome intrepid-changes [13:31] :) === chand[aw] is now known as chand [13:52] slangasek: so, why is there no obvious way to get a dvd version of ubuntu? [13:52] Hobbsee: because bandwidth is expensive. [13:53] Mithrandir: i realise that, but i would have expected it to be listed in a corner somewhere, or something. [13:53] Hobbsee: or you could go for the alternative that we hate freedom. [13:54] I think it goes with bug 122229; added a comment [13:54] 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] (http://cdimage.ubuntu.com/releases/8.04/release/ FWIW) [13:57] cjwatson: ah, thanks === davmor2_lunch is now known as davmor2 === asac_ is now known as asac [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] never! [14:51] at least, for those who actually drink. [14:51] 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] 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] 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 === greeneggsnospam is now known as jsgotangco === Tonio__ is now known as Tonio_ [15:29] do we ask users for disk labels when creating filesystems during install? [15:30] er not disk labels, but names for the filesystems [15:30] calc: not by default, no [15:30] cjwatson: ok [15:30] you can set them in the alternate installer if you work at it [15:30] ubiquity doesn't expose UI for that at the moment [15:30] that might be useful in that it displays the label instead of the "XX.X GB Media" if you do label it [15:31] i noticed that and then saw reference to it in that install report on the mailing list from earlier today [15:31] aye [15:31] 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] synaptic doesn't remove users dotfiles does it? [15:36] no [15:36] ok wanted to make sure before i told a user that [15:37] * calc never uses synaptic [15:37] packagemanagers generally dont do that :) [15:37] If a package ever touches anything in ~ the packager needs to be shot :) [15:37] ++ [15:37] calc: its just a fancy apt frontend, it behaves pretty much like apt [15:37] Amaranth: yep :) [15:37] mvo: thats what i thought :) [15:37] 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] :) [15:38] mvo: a user was claiming a complete uninstall via synaptic would remove the dotfiles and so i told him it does not [15:38] if it were in the control metadata then you could write a UI that did it [15:38] I have wished a few times I could wipe out some compiz settings :) [15:38] though it might have to declare things like gconf paths as well as simple $HOME-relative dotfiles [15:39] Amaranth: indeed :) [15:39] 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] then just rm -rf ~/.config [15:39] 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] 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] 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] ogra: that's what the "." is for [15:40] 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] Amaranth: I think we should get some user configuration cleaner for updates [15:41] Keybuk, well, but it contains stuff that would otherwise sit in ~ [15:41] I have no objection to .cache or whatever it was, but (as argued before at length) I think .config is silly [15:41] so configuration pertinent to accounts would not be under .config [15:41] Keybuk, it just moves them down one level [15:41] calc: there is a blueprint about allowing renaming volumes in nautilus which would update the label [15:41] calc: pitti didn't manage to work on that this cycle but maybe next one [15:42] 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] seb128: ah ok :) [15:42] calc: that's a bizarre definition of configuration [15:42] upstream has also some discussion about allowing the customize the display name [15:42] seb128: that would be better than being in the installer anyway [15:42] ie, having a field in the .mount for that [15:42] "configuration is data, other stuff goes into .config" eh? [15:42] heh [15:43] cjwatson: account specific configuration would be considered data, iirc it was discussed in the evolution xdg bug upstream already [15:43] I think this just goes to show how broken the xdg home directory specification is [15:43] everything not specific to the way the account was setup would go under .config === ogasawara__ is now known as ogasawara [15:44] 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] most apps configuration can be blow away without any long term consequence, blowing away email account setup information is different [15:44] I don't even understand _why_ we need the xdg home directory specification [15:45] 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] we go to such lengths to preserve it [15:45] we didn't really need FHS either, but it made things a lot cleaner and easier to deal with [15:45] things like OOo still don't care about FHS (argh) [15:45] calc: FHS documented existing practice [15:45] Keybuk: /srv ? [15:45] whereas the XDG thingy invents something totally new and contrary [15:45] there are bits of FHS that were invented [15:45] calc: 99% of the FHS concerns things like /usr [15:45] and Windows like (xdg) [15:45] /srv being a prime example [15:46] rm -rf .config is little different from rm -rf ~/.[A-Za-z]*; nothing in one's dotfiles is more valuable than configuration [15:46] imagine if the FHS suddenly, one day, said we needed /Programs and /Libraries [15:46] instead of /usr [15:46] (cached data, for example, is less valuable) [15:46] that's the level of change the XDG stuff introduces [15:46] for less discernible benefit [15:46] cjwatson: all email in evolution is in a dotdir [15:46] I think that is also a bug :-) [15:46] cjwatson: unless you use imap (like me) [15:46] (and a world-readable dotdir by default) [15:46] my mail lives in ~/mail [15:47] Keybuk: it said we need lib32 on ia64 and lib64 on amd64, equally insane things ;-) [15:47] calc: no, the LSB said that [15:47] oh yea i got the two confused, sorry [15:47] the FHS makes it easier to share files among machines, at least in theory (hence the /usr/share thing) [15:47] and I have quite negative feelings towards the LSB :) [15:47] but I get told off for sharing them [15:48] ok :) [15:48] * calc thinks we should get multiarch done and into LSB [15:48] cjwatson: though we have no arch indep configuration dir :\ [15:48] 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] 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] it really isn't difficult [15:49] 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] ok [15:50] 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] 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] 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] most applications do not suffer from this problem, in my experience [15:51] 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] 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] 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] heh :) [15:54] 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] 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] if they properly support upgrades it shouldn't be an issue(?) [15:56] "they"? [15:56] where they use the old files if they exist otherwise create new ones in the xdg location? [15:56] they being whatever app transitions to xdg [15:56] 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] usually it is completely infeasible to do so [15:56] assuming the file exists in the home dir it would not get recreated/removed unless the user deleted the dotfiles? [15:57] now suddenly you have to keep two versions of the file in sync [15:57] there wouldn't be two versions of the file in the NFS homedir case, afaict [15:57] why not? [15:57] indeed you want your settings to be the same on all machines you mount your home on :) [15:58] also, this is fairly complex code that you have to introduce into every application with a dotfile [15:58] 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] more lines of code == more bugs [15:58] calc, but both apps should have the same settings [15:58] it would at minimum have to move the file to be upgradable though, so not too much more code [15:58] meaning that "new app" needs to maintain duplication [15:58] ogra: they would be using the same file so would be [15:58] unacceptable new code [15:58] seriously [15:59] moving the file would break old versions of the application [15:59] cjwatson: code to check what path to use for the configuration, thats a couple lines at most [15:59] calc, that doesnt guarantee that a setting i change in "new app" is used by "old app" [15:59] calc: why put the effort in to add that code to thousands of different applications? [15:59] 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] if you're talking about this at an operating system level, that's what's involved [15:59] the new one needs to adjust the old settings in the dotfile as well as the xdg config to achieve that [15:59] it's a completely unacceptable amount of work to invest across the board [16:00] 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] 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] 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] there has to be a serious benefit that's more than just aesthetic [16:02] now, that cache directory tagging standard was good [16:02] 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] http://www.brynosaurus.com/cachedir/ [16:02] oh btw do you happen to know if we are going to be supporting the new deb source formats soon? [16:03] apparently they now (or will soon?) support different source formats than just diff.gz [16:03] I'd like to, but haven't spoken with the Soyuz guys yet [16:03] I don't think we should dive in straight away though, they're still explicitly experimental [16:03] we probably need Soyuz support by the time lenny ships [16:03] since aiui dd's will be allowed to use them at that point [16:03] for 9.04 then ? [16:03] I don't think the Debian archive will permit them for lenny; have you heard something to the contrary? [16:04] cjwatson: lenny+1 which will be later this year(?) [16:04] the Debian archive team aren't usually notably neophilic :) [16:05] 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] oh, I see [16:05] so if we sync from sid after lenny we will need to support the new format [16:05] right [16:05] I don't think the Soyuz changes are likely to be particularly hard [16:05] though I suspect it would involve database changes [16:05] 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] (there's an enum type in there that has .dsc, .diff.gz, etc.) [16:06] I don't think it's stable yet, no [16:06] (I wrote the 3.0 (bzr) format and have been vaguely keeping an eye on it) [16:06] ok [16:07] though I know buxy is pushing 3.0 (quilt) pretty hard [16:07] 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] there's no answer for that yet [16:08] it depends on ftpmasters [16:09] ajt wanted to allow multiple formats (he's fond of the git one in particular) but he's no more ftpmasters [16:09] yea i saw that :-\ [16:09] I would prefer if we started by only allowing the quilt (which is really wig&pen enhanced) + native [16:09] ones [16:10] I'd obviously prefer to be able to use any of them (eventually) ;-) === Sebast1an is now known as Sebastian [16:11] 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] is there a page that explains how the new formats work? [16:11] where we can release just by pointing to a tag or something like that [16:12] calc: man dpkg-source with a recent dpkg-dev [16:12] (1.14.17/18) [16:12] http://people.debian.org/~hertzog/dpkg-source.html [16:12] ah hardy is too old [16:12] buxy: certainly what we'd like to have in Ubuntu, by way of active importing of the world into bzr [16:12] thanks for the url [16:15] 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] there's no .diff in 3.0 [16:16] oh [16:16]