#ubuntu-devel 2005-03-01 <tseng> seb128: have you heard anything of f-spot? <seb128> rocking image viewer according to some comments <seb128> why ? <tseng> seb128: nah we talked about updating it <seb128> oh <seb128> noh, I was thinking to do it seems noboby seems to care <tseng> heard anything on the debian side i wondered <tseng> hrm. <seb128> does it work with the current bindings version in debian ? <tseng> yes, they reverted to gtk-sharp1 <seb128> the maintainer is a gnome-pkg maintainers so I guess I could push an upload <tseng> there is a 0.0.8 anounced just now. <tseng> libgphoto2 support <seb128> yep, I've read the mail <tseng> of course :) <seb128> do you have a package for it ? <tseng> nope. <seb128> I can probably upload/get it uploaded in debian <tseng> lets see how gross the current source looks <seb128> but I'm pretty busy and I don't know a lot about gtk-sharp stuff packaging <tseng> seb128: ill get back to you in a bit. <seb128> k, thanks <seb128> the version in debian is really outdated and has some RC <seb128> would be nice to fix that soon :) * mako waves <mako> lwce has been pretty productive <ogra> hey mako <tseng> seb128: this is going to take some futzing to get the internal libgphoto2-sharp into the debian mandated paths <mako> ogra: hey there <mako> i think we might get a couple more ubuntu derivs out of this.. :) <seb128> tseng: k <daniels> amu: which language did you select? <amu> daniels: german <daniels> amu: wwwwwweeeeeiiiiirrrrrrrdddddddddddddddd <amu> daniels: :-) <ogra> daniels: oh, your keyboard has the sam bug as mine ? <ogra> same even <T-Bone> daniels: i've been told to report X-stuff to you: <daniels> *"DE"* ) LAYOUT="de" XKBOPTIONS="" ;; <daniels> ogra: $LANG is de_DE.UTF-8? <daniels> T-Bone: sure <ogra> yup <T-Bone> daniels: on recent intall ISOs, X setups at 60Hz VertRefresh (as it's been reported on the m-l). That does kill eyes :) <daniels> ogra: argh <T-Bone> especially on big (19"+) screens :) <daniels> T-Bone: is you need to put in horizsync/vertrefresh, then either you're using the i810 driver and it's a bug there, or your monitor's lying to us <amu> daniels: same here, LANG is de_DE.UTF-8 <T-Bone> daniels: changing HorizSync and VertRefresh to more coherent values in xorg.conf fixes that <T-Bone> daniels: none of the above <ogra> daniels: not to be mistaken, i meant the key repitition <T-Bone> daniels: it worked (tm) and it's no longer working since a couple of daily rolls <amu> n8 all <mvo> n8 <daniels> ogra: ah, heh :) <daniels> T-Bone: that's bizzare; i haven't touched x in like two weeks <ogra> daniels: which is a kernel bug i think.... <T-Bone> daniels: two weeks is probably the last time i noticed it was working :) <daniels> T-Bone: weird <T-Bone> daniels: heh ;) <Kamion> schweeb: right, what thom said <schweeb> Kamion: heh, if I had a proper internet connection at home, I'd already have had the CD burned before you replied :p <Kamion> T-Bone: hm, I'm thinking that any hand-written hotplug pci map probably needs to be kernel version specific; otherwise we're going to run into problems with module names changing between kernel versions and stuff <tseng> seb128: got it :) <Kamion> T-Bone: would you guys be amenable to having the kernel package ship such a file, if I supplied the initial contents? <T-Bone> Kamion: certainly <T-Bone> Kamion: we'll have to figure out how to integrate it in the kernel package, but i guess it won't be difficult to handle * T-Bone has to call it a night. Will be back at 13CET <tseng> erm, we lost seb =/ <ogra> no, he likes core dumps.... <tseng> heh, but he was about to upload my package <ogra> ouch <sivang> tseng: probaly went to do another "patch fo the boog" ;-)) <tseng> sivang: EZ GTK BOOG! <sivang> tseng: heheheh <ogra> tseng: do you think it was your package that crashed him ? :) <sivang> tseng: him and jdub just ROTFLed me heavily this week with their cross mutual accusations :) <tseng> ogra: nope, hadnt even posted it yet <tseng> just finished rsync <ogra> :) <sivang> tseng: I think seb should be considered for the most hilarious changlog entries ever contest :) <tseng> hah <tseng> I've made some pretty bogus ones to Gentoo <Evaso> hi guys is there any ubuntu devel here? <lamont> Evaso: nah, we're all over in #ubuntu. :-) <sivang> Evaso: what are you looking for? <ogra> heh <Evaso> i'm thinkig to close dehs.alioth.debian.org serice, with al the upstream changelog info getted from internet, is any ubuntu developer interessed on this data? <lamont> lifeless?? <lifeless> dude, midnight, sleep tgime <lamont> lifeless: what evaso said <lifeless> so as long as we're quick... <lifeless> what did he say? <lamont> <Evaso> i'm thinkig to close dehs.alioth.debian.org serice, with al the upstream changelog info getted from internet, is any ubuntu developer interessed on this data? <lamont> for some reason, I thought of maybe you. <lamont> and it's not midnight in .au... <lifeless> I'm in London <lamont> you jet-setter you <lifeless> yeah, kindof interesting though we don't have a scific use for it <lifeless> *specific* <lifeless> night <lamont> g'night then <sivang> lamont: hrm, what is dehs.a.d.o ? <lamont> sivang: I imagine it's something alioth-ish... <lamont> Evaso: ?? <sivang> lamont: heh ok <Evaso> dehs is an info system about debian situation against upstream version with upstream changelog where the upstream version is noth in sync with debian one <Kamion> it uses information from debian/watch <Kamion> sounds like something that could live in launchpad, I guess <Kamion> but I suspect Evaso is annoyed because many Debian people who are also upstream or have upstreams that don't release code in conventional ways don't find debian/watch very useful <Kamion> so we shouldn't expect 100% coverage or anything <Evaso> kamion: dehs had also generetad already 1588 watch file (for packages that no had one) and has passed uscan test <Kamion> sure, I should probably add some to a few of my packages <Evaso> kamion: it must only be puttend in the debian directory of their own packages <Kamion> yes, I am aware of what the debian/watch file does <Evaso> and actually i doesn't know any internet service that retrive upstream changelog other than dehs * Kamion wanders off to dehs to see what it says for him <jvw> Evaso: I already asked you to not close down the site, I think it's useful for QA purposes in Debian. If the load on alioth is too high, I'm sure some admin will mail you about it, don't worry as long as you don't hear anything <jvw> I also told you that I'm very likely going to include an 'outdated w.r.t. upstream' warning in the PTS's "todo" based on dehs... <Evaso> jvw: is PTS more popular that developer.php? <jvw> Evaso: they are both popular, different use cases <Evaso> jvw: do u know some lintian developer? * lamont uses pts, but can't recall using developer.php <jvw> Evaso: erm, you're talking with one, check the changelog :) <sivang> Evaso: would appriciate pointer on how to make my package my pkgs dehs compliant :) <jvw> Evaso: I also nowadays maintain PTS, with still occasional help from the original author <Kamion> sivang: man uscan <Evaso> jvw: i doesn't know litian source code but i think fixing this #234202 require 30 sec for a guy that know the source code <Kamion> ah, uscan --pasv helps <jvw> Evaso: I agree it'd be easy to fix <Kamion> #234202 should only be applied to non-native packages at most <zul> hey <Kamion> no point in warning for dpkg, say :-) <jvw> Kamion: what do you think for non-native packages? <jvw> ppl can override it... <jvw> I'm a tad unsure <jvw> Evaso: that's why that isn't yet implemented <Kamion> jvw: *shrug* - I think a warning's reasonable enough, I guess, not sure <jvw> my estimate is that it's useful for well over 95% or so, probably more, of the packages <jvw> non-native ones, that is <Evaso> dehs already exlude debian native packages: they are not archived/processed in dehs <jvw> Evaso: this is about the lintian warning, which cannot be aware of dehs <jvw> Evaso: Kamion is also a lintian maintainer <Kamion> some of my non-native packages just can't have dehs files, though, db1-compat comes to mind immediately <Kamion> er, watch files <lexhider> Having a problem with eject command from right on CD icon, what package do I report a bug against? <elmo> the last time I looked at the QA pages, the "new upstream version" stuff was a bit crackful for my packages <jvw> elmo: PTS of DDPO? <elmo> probably because some of them pre-date the birth of the sun <jvw> or <Kamion> it's not native because it wasn't written for Debian, but its source was picked out of an old version of glibc by hand <elmo> jvw: not sure - the fun one, with a huge table and lots of info ;) <jvw> elmo: heh, DDPO :) <Kamion> which is, er, not exactly easily encodable in debian/watch :) <lexhider> right-click <jvw> Kamion: there surely are a significant number of valid cases to not have one <Evaso> Kamion: if there isn't a clear upstream release version watch info had no sense <Kamion> Evaso: yeah, but we keep appearing on your statistics and you keep sending mails to Debian lists saying how lazy we are :) <Kamion> maybe there could be some way to say "yes, I have checked and I can't produce a watch file for this package, it's not just that I'm lazy" <jvw> I'm just a bit uncertain whether there are few enough valid non-watch-possible packages to still warn, and have those people override <elmo> kamion: echo "WHATEVER" > debian/watch <elmo> ;) <jvw> Kamion: or that, yeah <Kamion> elmo: tempting <Kamion> jvw: would dehs be able to parse lintian overrides though? <daniels> elmo: if anyone ever did that, I would hope a large fist came and punched them in the goolies for stupid use of quotes :) <jvw> Kamion: of course it can be made, but then StevenK needs to start parsing lintian overrides when he catches up copy-catting lintian :) <Evaso> jvw: nload is genereted and tested from dehs <jvw> 5611 N Feb18 01 Planet Debian (0.6K) Marco d'Itri: Closing bugs feels good! <Kamion> jvw: yeah, that's kind of why I don't feel that a lintian override is the right place to put that information <jvw> Kamion: ack <Kamion> how about a present but empty watch file? <Kamion> what does that do? <jvw> Evaso: suggestion for a way to have maintainers say "No, there is no watch file, and it makes sense to not have one"? <jvw> dunno, could be made to do the right thing of course <Kamion> daniels: that's rich coming from Mr. '[ "x$RET" = "xtrue" ] ' <jvw> but, seems a bit ugly to me <Evaso> we could talk to Jdg (actually the defacto maintaier of the watch file format) about introduce antoher state in the watch file <Evaso> so we colud intoduce status <Evaso> like <Kamion> de facto? de jure :-) <dholbach> sleep tight everyone <Evaso> for example: <Evaso> status=1 <jdub> goooooood morning freedom lovers <jvw> Evaso: is he responsive, Jdg? <sivang> jdub: morning :) <Kamion> jvw: fairly <jvw> oh, ok, seemed to recall some issues, but be outdated on that <daniels> Kamion: :) <Evaso> jvw: http://lists.debian.org/debian-policy/2005/02/msg00078.html <dholbach> hai jdub <daniels> jdub: try waking up earlier, hippy <Kamion> I wonder what that bug fix is <Kamion> daniels: (the x thing definitely isn't needed in busybox sh, and I don't think POSIX sh requires it either, BTW) <dholbach> jdub: just have a look at the end of http://wiki.ubuntu.com/UniversePythonTransitionTODO - i think it speaks for the ubuntu-love ;-) <jvw> as nobody (AFAIK) uses uscan itself anyway... maybe we just shouldn't care <daniels> Kamion: yeah, istr something about "" invalidating need for x <Kamion> hey, I do use uscan from time to time <jvw> well, but those that don't, it doesn't matter how their watch file works with uscan like as long as it works for the QA scripts :) <Evaso> jvw: i had a badly hacked version of uscan for dehs, we want to define own format and rewrite an application on it? <jvw> err, no, rather not :) <Kamion> no reason to fork the format, Julian is not that unresponsive; last upload of devscripts 13 January 2005 <jvw> I already looked it up, he used to have key issues <Evaso> I think that we must to work with Julian, for integrate a dehs command line option in uscan and to expand the uscan format with new features <jvw> Evaso: I think you're by far the most suited to do so, I think the most important thing is to there be a good way to say "no upstream available" <Kamion> jvw: fixed a while back I think <jvw> Kamion: eh, how then? <jvw> oh, you mean his key issues? <Kamion> yeah <jdub> daniels: i am so dead to the world, was up for... 48hrs? :) <jvw> must be, as he isn't in the official MIA db about that, but was merely in my private list of those, which is quite old by now :) <daniels> jdub: heh :) i slept most of yesterday after I got back <jdub> dholbach: :D awesome! <daniels> /m jdub so, like ... you still have legoness on your table <daniels> ah, bleh <jdub> haha <jdub> yes, i noticed that yesterday <jdub> everyone, daniels bought lots of lego for me :) <daniels> went to grab them before I left, but only realised just then that they were only tied, and couldn't find any duct tape; maybe not so good for checked luggage ;) <sivang> jdub: leog? <sivang> lego? <sivang> can I also have some? ;-) <daniels> sivang: mindstorm, even <jdub> daniels: yeah <daniels> jdub: so yeah, if you want to get them down at some stage, that would be awesome ;) <sivang> daniels: ah!!!!!1 <sivang> daniels: I'm hooked on mindstorm, I had to previous "version" of these and build a couple of circular motion based vechicles :) <Evaso> well, there is no relevant news, i tink to leave <daniels> jdub: and I can pay you for the postage <Evaso> bye guys <ogra> bye <mjg59> Suspend/resume situation is looking quite massively pleasing <azeem> which reminds me <lamont> Errors were encountered while processing: <lamont> mozilla-firefox <lamont> mozilla-firefox-gnome-support <lamont> yelp <lamont> ubuntu-desktop <lamont> mozilla-firefox-locale-en-gb <lamont> E * lamont kicks libbonobo <lamont> Kamion: you have a copy of the "current" livecd-rootfs for ia64, and I'll put it back in the right spot for you to keep fetching it * azeem updates HoaryPMResults to confirm Suspend-to-Disk works fine on R51 <lamont> Kamion: the alternative is to make the ia64 livecd be just ubuntu-base for the moment.. :-( <mjg59> azeem: Rock <mjg59> Suspend to disk ought to work on any machine with enough swap now <Kamion> lamont: I do? <tritium> how much is enough swap? >= memory size? <lamont> Kamion: sorry - that was an 'if you do' <lamont> I guess I could just grab it from the last daily, eh>? <Kamion> I suppose I could pick it out of something, yeah <lamont> Kamion: I can grab it if you don't have it lying naked somewhere <lamont> what all do you fetch? cloop and manifest? <Kamion> yeah. I can pick out both, one sec <lamont> if you have it trivially, that'd be great <Kamion> isoinfo is my friend * lamont feeds horses while he waits <Kamion> lamont: chinstrap:~cjwatson/casper-ia64/ <bob2> hm, I should try suspend-to-disk again <Kamion> will need to be renamed to livecd-current.* of course <tritium> mjg59, what's the minimum requirement on swap size for suspend to disk? <lamont> Kamion: wget, or scp? <lamont> nm <mjg59> tritium: Larger than RAM <tritium> thanks <mjg59> tritium: The technical requirement is that everything current used must fit in RAM, and that must then fit in your swap partition <tritium> mjg59, that's what I thought. The automatic partitioner sometimes makes a swap slightly smaller than the amount of RAM. <smurfix> mjg59: does suspend-to-disk turn of swap entirely, or just the swap partition you're suspending to? <mjg59> smurfix: Mm? <mjg59> tritium: Yeah, should be fixed on laptop installs in Hoary <azeem> smurfix: the swap partition is used to write the memory content to, and gets reused as swap once Ubuntu is resumed <tritium> mjg59, great! <smurfix> Mmh, but the stuff that's already swpped out needs to be swapped in forst, right? <smurfix> first <mjg59> smurfix: Good question. No idea. <mjg59> (I try not to read the swsusp code too much, it scares me) <lamont> Kamion: you're golden <tritium> I guess I'll reinstall to get enough swap space for suspend to disk <mjg59> Kamion: Does the installer make big swap partitions on laptops for suspend? <smurfix> because then it'd actually make sense to have two appropriately-prioritized swap partitions, one for actual swapping and one for suspend. <smurfix> I'll investigate then <ogra> argh,my-space-key-stopped-working-in-x...works-on-console-though <hawke> ogra: lol <ogra> grrrrrr <ogra> hmm, gnome keyboard selector seems to fix it <ogra> actually switching layouts.... * dredg beds while there's still a chance he'll wake up in the morning <dredg> nightol <ogra> night dredg, nice first package, thanks <sivang> night all! <ogra> night <Kamion> mjg59: not especially, no <Kamion> lamont: thanks <Kamion> lamont: http://weddell.buildd/%7Ebuildd/livecd/livecd-current.cloop: <Kamion> 01:55:18 ERROR 403: Forbidden. <lamont> doih <lamont> EOWNER <lamont> try it now <mjg59> Kamion: Hrm. I can't remember who I discussed this with now. <mjg59> Kamion: We certainly need larger swap by default if we want hibernation support * mjg59 heads for bed <Kamion> mjg59: oh, it tries for up to 3 times RAM though <Kamion> mjg59: it depends what fits, but I think it should be OK by default <Kamion> lamont: could you give daily-live 20050218.1 ia64 a go, please? it should work without weird boot arguments now <bob2> oh, wow <lamont> Kamion: it'll take a while, fetching shortly <Kamion> np <lamont> is there a way to tell rsync that if it dies during the middle of the rsync, that it shouldn't truncate the target file? <Kamion> one option is not to use --partial, but that has other problems ... <maswan> lamont: as far as I know, only "not use --partial" <zul> lamont: ping <zul> doh unping <YokoZar> http://homepages.paradise.net.nz/dazjw/img_0121.jpg <tseng> YokoZar: hah, thats cute <YokoZar> That picture has good public relations written all over it <jdub> elmo: ping <mxpxpod> is anyone else having problems with icons on their desktop not showing up properly? <ari> YokoZar: wow <mxpxpod> I get the generic icon <jdub> YokoZar: haha <jdub> YokoZar: post to sounder :) <YokoZar> Heh, maybe <mxpxpod> hmm, seems to be something with the new gnome-icon-theme <schweeb> Kamion: all went well so far, cept for the bootloader (I'm using XFS /) <Safari_Al> jdub, around <Safari_Al> ? <jdub> yo! <Safari_Al> Hi there! Just wondering what that status is of that info you were going to pass along to me? <jdub> shoulda got it on wednesday <jdub> is slackzone the most useful address to use? <Safari_Al> In this case, probably @commander is better. <jdub> mmm, didn't have that address :) <jdub> tim.riley? <Safari_Al> woah <Safari_Al> I thought I had been using that address for our previous correspondence. <jdub> whoa is me (haw haw) <jdub> you had too <jdub> n/m <jdub> triley <Safari_Al> haha <Safari_Al> That's it. <Safari_Al> Anyway, slackzone is no problem either. Whichever you remember first :P <jdub> i get lbdb to do my remembering <Safari_Al> with mutt? <jdub> yeah <Safari_Al> Nice. <jdub> so my lbdb database was updated today <jdub> and i have records going back to 2002 <jdub> 2001 even <jdub> but no tim riley, corporate style <Safari_Al> Well, now you've got corporate-tim :) <jdub> i resent, let me know when you get it <Safari_Al> Thanks. I don't remember getting this @slackzone.org. <jdub> ! <jdub> that is because it is not slackzone.rg! <Safari_Al> ah! <jdub> argh <jdub> sorry <jdub> not that anyone would get a bounce out of it <jdub> because they're patently useless now <Safari_Al> jdub, passing along the appropriate information and my recommendations now. I'll get back to you once I have something. <Safari_Al> Thanks again. <schweeb> thom: you awake? <ficusplanet> Hey everyone. Will dbus-0.23.1 make it into hoary anytime soon? I noticed that the latest beagle requires it? Also, do the latest hoary kernels have inotify-0.18? <schweeb> they have inotify, dunno which version <pitti> Morning <Mitario> morning! <dholbach> hai <d3vic3> hi <dholbach> morning d3vic3, how are you? <d3vic3> lo dholbach, me is ok and you ? <dholbach> should be sitting in the train already *hectic* <amu> moins <dholbach> have a nice weekend <dholbach> see you on sunday <amu> daniels: sended debug <daniels> amu: thanks a lot <amu> daniels: it was a T41 if you want another test letme know <daniels> amu: ah sorry, could you please put the -x on .config.in, rather than .postinst.in? <amu> daniels: iso was 20050217 <amu> daniels: do you want the test with the current iso, rsync just finished <daniels> amu: whichever is easiest for you -- xorg hasn't changed in a while <rburton> Kamion: so i've a copy of syslog with debugging if you want it <YokoZar> good morning again: http://homepages.paradise.net.nz/dazjw/img_0121.jpg <Treenaks> YokoZar: cool <seb128> elmo: here ? <smurfix> seb128: not yet, apparently <pitti> mvo: ping <mvo> pitti: pong <pitti> mvo: in Synaptic's progress dialog, would it be possible to first display the package name and then the URL? <mvo> pitti: when the details are opened? <pitti> mvo: currently I only see a long list of "http://archive.ubuntu.com/u..." (unless I resize the dialog) <pitti> mvo: yes <mvo> pitti: it's stuff I get from apt that way, I can change it <pitti> mvo: another thing <pitti> mvo: if I open a Ubuntu CD and upgrade, then I still get a Nautilus window <pitti> mvo: you currently have a HAL script, right? <pitti> mvo: maybe it would be better to integrate this stuff into gnome-volume-manager <mvo> pitti: no, it's part of the C code in update-notifier <pitti> mvo: huh, you detect Ubuntu CDs in u-n? <pitti> I thought you have a hal callout? <mvo> pitti: I link against libhal <pitti> ah <pitti> hm, somehow we should teach gvm not to open Ubuntu CDs when upgrading from them <pitti> what do you think? <mvo> is there a way to tell hal to stop processing the event when I handled it? <pitti> mvo: no, because it will be executed asynchronously and in parallel <pitti> mvo: whoever is faster handles it first :-) <pitti> mvo: that's why I think a gvm integration would be nice <pitti> mvo: gvm is meant for stuff like that <Kamion> rburton: yes please <mvo> pitti: I agree that it's ugly that a nautilus window is opened. but I'm not sure about the integration into g-v-m. <seb128> pitti: dunno if that's due to inotify/gamin, but I've a DVD in my drive and totem starts some minutes after the login ... which is kind of weird :p <rburton> Kamion: email? <Kamion> zstrickland@example.net <rburton> Kamion: sent <mvo> pitti: we could add it to gvm_device_autorun() <pitti> mvo: yes, that was the idea <elmo> seb128: ? <elmo> jdub: ? <seb128> elmo: need an ia64 access with the libbonobo build-dep installed to track a ftbfs is that's possible <pitti> seb128: #6002 ? <seb128> pitti: kind of, happens just on the system start/login <seb128> not every single 5 mins <pitti> seb128: oh, ok. can you please add that to the bug? <seb128> k <pitti> thanks <Mithrandir> Kamion: why does now tar (for instance) get SIGPIPE when piping stuff through ssh? <pitti> seb128: removable devices automatically get mounted at login <jdub> elmo: yo <pitti> seb128: probably this erroneously causes the device to autostart, too <Kamion> damn, the installer's memory footprint is huge; minimum in lowmem 1 is like 52MB <Kamion> Mithrandir: dunno <elmo> seb128: halley.ubuntu.com <Kamion> don't think anything that might affect that has changed recently <Mithrandir> Kamion: up-to-date hoary, I see it on both amd64 and i386. <Mithrandir> Kamion: been that way for a while, probably a few weeks <elmo> jdub: you pinged 10 hours or so ago? <Kamion> weird <seb128> elmo: thanks <Kamion> Mithrandir: could be the shell or the terminal rather than ssh; that's happened in the past <jdub> elmo: didn't note down why :) <Mithrandir> I'm using pterm <Kamion> Mithrandir: IIRC either the shell or the terminal conventionally ignores SIGPIPE <Mithrandir> hmm, right, seems to be zsh's fault <seb128> jdub: hey, do you know what happened to gtk2-engines-dev ? <mvo> grrr. my system was frozen again :( <jdub> seb128: it was a new binary package in my upload * mvo blames gtk^Winotify <Kamion> damnit, I can't get the installer's memory footprint below 32MB <seb128> mvo: boot with "noinotify" :) <seb128> jdub: ie ? <Kamion> even in lowmem mode 2 it's fractionally over that on i386 <seb128> jdub: is gtk-engines-2.pc somewhere atm ? <Kamion> (and doesn't work properly then 'cos I'm missing the module for my network card) <jdub> seb128: it should be in gtk2-engines-dev <jdub> seb128: (gar! so stupid!) <jdub> $ dpkg -L gtk2-engines-dev | grep pc$ <jdub> /usr/lib/pkgconfig/gtk-engines-2.pc <seb128> grumpf <seb128> apparently something screwed my cache <seb128> jdub: sorry for the noise :) <seb128> elmo: libglib2.0-0-dbg on halley please :) <elmo> seb128: done <seb128> thanks <bob2> Mithrandir: tell me if you figure out which zsh option is it <bob2> I get (I think) the same problem with piping stuff to patch <seb128> jdub: I'm not going to put an epoch on yelp :p <jdub> seb128: haha :-) <jdub> seb128: can you check the rawhide panel patches <seb128> looking for something special ? <jdub> seb128: they've done the desktop menu changes <seb128> admin/pref order ? <jdub> yeah <seb128> k, thanks <jdub> and s/Administration/System Settings/ <jdub> etc. <seb128> do <seb128> all these strings changes suck <seb128> (on the translation plan) <jdub> yes <jdub> they have them, though ;) <seb128> s/do/doh/ <jdub> they're also not renaming desktop <jdub> i'll talk to mark about desktop/system * seb128 reading the howl thread (the whole discussion just arrived in one shoot in bugzilla) <jdub> yeah * HiddenWolf howls <jdub> seb128: what do you think about that? <jdub> seb128: i don't really want to ship/support mdnsresponder <seb128> still reading :) <HiddenWolf> link? <seb128> BTW a bug which sucks: debian #295815 <seb128> the gtk icon cache seems to have endian issue, we have updated a gnome-icon-theme using it yesterday and already get 3 bug today saying that all the icons are broken <HiddenWolf> yuk <seb128> jdub: hum, we so just drop it ? <sivang> morning all <mjg59> thom: Ping? <thom> mjg59: ack <pitti> Hi sivang <mjg59> thom: We need to work out what we're doing about swap sizes in the installer <mjg59> At the moment, people may end up with swap partitions that are slightly smaller than RAM, which won't work too well with swsusp <thom> right <thom> what's the best solution? just add n MB to the size of ram to get the ideal swap size? <sivang> hey pitti :) <mjg59> thom: Something like that. Do we have any idea what Suse 9.2 defaults to for swap size? <jdub> seb128: well, i need your thoughts on that (and the debian gnome team's). <thom> mjg59: i've not looked at suse at all, tbh <seb128> jdub: I don't really care about it, removing it in fine for me <jdub> seb128: even in debian? <jdub> seb128: that's a fair amount of uploads, thanks to libtool mess <seb128> yeah, but there is no real choice <Kamion> mjg59: did you see my comment last night? <seb128> jdub: move that to #gnome-debian <mjg59> Kamion: Nope <Kamion> 02:05 < Kamion> mjg59: oh, it tries for up to 3 times RAM though <Kamion> 02:05 < Kamion> mjg59: it depends what fits, but I think it should be OK by default <elmo> 3 times RAM? that'd rock on emperor <thom> yay 36GB swap <mjg59> Kamion: Is this a change since Warty? <Kamion> it doesn't force it up to 3x RAM :P <daniels> elmo: speaking of RAM, when do I get to build xorg in a RAM disk on concordia? <daniels> that would kick arse <daniels> disks are slow :P <Kamion> that's the maximum; minimum 64MB; "priority" (which kind of skews size calculations relative to other partitions) 512MB <mjg59> Kamion: So given a reasonably sized disk, it'll tend to be larger than RAM? <Kamion> mjg59: yes, warty had "64 512 512" rather than "64 512 300%" <Kamion> mjg59: I believe so, though checking wouldn't hurt <mjg59> Ok, cool <Kamion> partman-auto (31) unstable; urgency=low <Kamion> - limit the maximum size of the swap to 3 times the available RAM but <Kamion> not less than 64 MB. Thanks to Margarita Manterola, closes: #254935 <mjg59> Ah, hang on. My sysadmin's a Suse bigot. <bradb> Does Ubuntu's Bugzilla grant editbugs to every new user account? I don't want to spam our Bugzilla to verify this. :) <mjg59> The machine with 4GB of RAM has 4GB of swap <elmo> bradb: yes <sivang> does someone know how do I view the channel topic in irssi? (the topic and the top bottom of the screen get's cut due to window width limitations) <bradb> wow, ok <elmo> sivang: /topic <elmo> bradb: dude, Debian doesn't even require accounts; it's entirely wide open for all write access to anyone <bradb> cool! <elmo> which would seem insane, but AFAIK hasn't been abused in the last 10-15 years <elmo> well, seriously abused. some would say folks like Dan Jacobson are a failing of the Debian system * bradb takes this into consideration in massively simplifying one of his specs <daniels> well, it's wide open for everyone who hasn't been blacklisted <sivang> elmo: tnx :) <elmo> daniels: the only blacklisting is of control@ access <Kamion> the only abuse that's happened is spam <elmo> well, excluding the spam filtering <Kamion> to my knowledge <Kamion> there's been some open/close wars and things, but the people involved would've had accounts anyway if it worked that way; no randoms going through and closing all bugs or anything <Kamion> the system's designed so that all actions are recorded and reversible anyway <mjg59> Kamion: elmo: With luck, the next kernel ought to suspend to RAM on recent Mac hardware, so would you be willing to test it once it's out? <elmo> mjg59: sure <Kamion> mjg59: absolutely <mjg59> And if that works, then we can try suspend to disk as well... <mjg59> I think lamont was aiming for Monday <elmo> oh, I may have < swap than mem.. lemme check <elmo> Mem: 514308 <elmo> Swap: 500312 <elmo> duh <elmo> I'm sure that was what warty chose for me too <Kamion> hm, I have 512MB RAM and like 64MB swap <sivang> mjg59: I will check my swap partition now, on the dell craptop <mjg59> elmo: May work anyway * sivang is really happy with the speed the laptop is booting now. <sivang> mjg59: how can I know for sure if I am using a swap partitoin at all? something is strange here on this laptop.. <Kamion> 'free' will tell you <sivang> Kamion: tnx <sivang> Mem: 256620 168028 88592 0 8868 44792 <sivang> -/+ buffers/cache: 114368 142252 <sivang> Swap: 0 0 0 <mjg59> sivang: You have no swap partition enabled, which is odd <mjg59> Does /etc/fstab have one mentioned? <sivang> mjg59: yes, that's why I thought I had <sivang> mjg59: /dev/hda5 none swap sw 0 0 * sivang is surprised this machine copes with 3 instances of OOo docs and a couple of moz's without a swap partitoin <mjg59> sivang: mkswap /dev/hda5; swapon -a <mjg59> Then try hibernate again <Kamion> rburton: ok, I think I have a vaguely plausible fix <sivang> mjg59: ok, thanks <sivang> mjg59: will try that now <sivang> mjg59: ok, it worked :-) now let's see how good the machine comes back <rburton> Kamion: excellent <sivang> mjg59: well, the resume from hibernate is a regular boot :-/ (slow as a regular boot and looks the same) <mjg59> sivang: Ok. Is RESUME set in mkinitrd.conf? <sivang> mjg59: I did RESUME=/dev/hda5 and hibernated again, takes the same time and apart a big delay in boot up (before saying "creating udev entries") nothing changed. <T-Bone> lamont: ping (for when you're around) <sivang> guess I'll be using the sleep :-) <mjg59> sivang: Did you generate a new initrd? <Kamion> incidentally DEBCONF_DEBUG traces rock <daniels> Kamion: unless they crap all over your db_progress and just make everything unreadable :P <T-Bone> Kamion: good you're here! Time to sort out the pci.handmap stuff? :) <T-Bone> daniels: if i can provide anything that'd help fixing the '60Hz' issue, let me know. FWIW i tested on ia64, but according to the m-l, it's arch-indep <sivang> mjg59: hrm, no O:-) also it's very strange I my swap partition is not mounted nither set up correctly . <daniels> T-Bone: if you can solve it, that'd be great ... <T-Bone> heh <Kamion> daniels: they're syslogged as standard <Kamion> T-Bone: yeah, after I've done this netcfg fix <T-Bone> daniels: actually, why is there a need to add VertRefresh/HorizSync in the default xorg.conf? Can't the driver figure those by itself? <mjg59> sivang: Yes, that's because it didn't attempt to resume <mjg59> You'll need to mkswap it again <T-Bone> Kamion: ok. I'll do some parisc stuff in the meantime. Ping me when you're ready :) <mjg59> sivang: mkinitrd -o /boot/initrd-whatever and then suspend again <sivang> mjg59: I wonder how I can fix the non operating swap partiton <daniels> T-Bone: it shouldn't be adding them unless it really has to ... <T-Bone> daniels: it did <daniels> T-Bone: although it will decide that it really has to on amd64 and ia64 <sivang> mjg59: and use this initred for booting the currently booting kernel? <T-Bone> daniels: they were there when i booted <mjg59> sivang: Yes <daniels> T-Bone: since we can't probe the monitor from userspace on either of those two architectures <T-Bone> daniels: and they were obviously the cause of the mis-setting <mjg59> sivang: Once you've done that, swap shouldn't be an issue <daniels> T-Bone: if you can reproduce it on i386 or powerpc, I'm interested; else, it's not solveable for Hoary :\ <sivang> mjg59: ok, so I'll have to replace the current on in menu.lst right? <T-Bone> daniels: damn. How comes it worked before? <daniels> T-Bone: because of an accident that broke a whole lot of other crap :) <mjg59> sivang: No - just do mkinitrd -o (name of your initrd) <T-Bone> daniels: if the livecd uses the same detection method, i can easily boot one on any of my ppc boxes <daniels> T-Bone: yep <T-Bone> daniels: lol :) <T-Bone> daniels: ok will do * T-Bone starts downloading the ISO <Kamion> daniels: is there anything I can help with for xresprobe/amd64? if you give me hints what might be needed, I can do the work <sivang> mjg59: done, now re enable swap and hibernate <Kamion> oh, I suppose it's scary evil real mode crap? <mjg59> sivang: Yup <T-Bone> hmm. cdimage doesn't perform that well. 440kB/s avg is mean :^) * T-Bone ducks <daniels> Kamion: basically, move ddcprobe's real-mode code to vbetool, and then move vbetool from using lrmi to x86emu <daniels> Kamion: unfortunately this is not hoaryable; i asked about a fortnight ago <sivang> mjg59: hrm, no go , boot was the same, say, maybe the fact I am using LVM breaks the hibernation? <Kamion> daniels: ah :( <Kamion> -m32 doesn't help? <mjg59> sivang: Argh. Yes, that's quite possible. Are you using LVM for swap? <sivang> mjg59: no <mjg59> Hmm. Ought to work, then. <mjg59> It used the initrd you generated? <mjg59> sivang: Can you cat /sys/power/resume ? <sivang> I named it the same and assumed it goes to the right place :) checking again <daniels> Kamion: nope; vm86.h simply doesn't exist, and the kernel doesn't provide vm86() <sivang> mjg59: 0:0 <mjg59> amd64 kernels have no vm86 support whatsoever <mjg59> sivang: Ok, so either the wrong initrd was used, or something is very broken <sivang> mjg59: retrying... <mjg59> sivang: The timestamp on /boot/initrd-2.6.10-3-686 (or whatever) ought to be updated after the mkinitrd <sivang> mjg59: bah, then I suspect it didn't. looked odd me after the second time I created the initrd , but I thought it was neglectable. <sivang> mjg59: shall I rm -rf it and recreate? <mjg59> sivang: What command line are you using <mjg59> You don't need to remove it <sivang> mjg59: mkinitrd -o initrd.img-2.6.10-3-686 <Kamion> daniels: ah, d'oh <mjg59> sivang: /boot/initrd.img-2.6.10-3-686 <mjg59> (assuming you're using a 686 kernel) <sivang> mjg59: well yeah, I was in the /boot dir so I omitted the location prefix <mjg59> sivang: Ah, right <mjg59> I've no idea what it does in that situation <smurfix> mjg59: should work, actually -- check by "ls -l" <sivang> mkinitrd -o /boot/initrd.img-2.6.10-3-686 <sivang> File descriptor 3 left open <sivang> File descriptor 4 left open <sivang> File descriptor 5 left open <sivang> File descriptor 6 left open <sivang> File descriptor 7 left open <sivang> Finding all volume groups <sivang> Finding volume group "mainpart" * mjg59 goes off to a meeting <sivang> mjg59: ok, laterz! :) <mjg59> sivang: If it still doesn't work, you probably want to hassle jbailey for a bit <sivang> mjg59: ok, I will :) <mjg59> And if it /still/ doesn't work, it'll be a kernel issue and I'll produce one with more debugging <sivang> mjg59: sure, thanks alot * jbailey scrolls up. <sivang> mjg59: it worked!!! <sivang> mjg59: I rm -rf the initrd, then recreated with your command line, and it workd! RAWK <Kamion> I should work out what that "File descriptor <n> left open" thing is coming from <sivang> Kamion: oh yes, this has been botherting for quite some time :) <jbailey> mjg59: For testing, I also added support for it over the command line. <Kamion> sivang: it seems to be harmless <jbailey> mjg59: Of course you have to have at least regenerated it one with that initrd-tools, but after that resume= will override whatever is set in the config file. <jbailey> Kamion: It's only on lvm support, right? <sivang> jbailey: strange thing, mkinitrd didn't work untill I told it /boot/initrd.img-blah <jbailey> sivang: Eh? <sivang> jbailey: I suspect it working had nothing to do with my rm -rf'ing the old one. <Kamion> jbailey: yeah, just checked and it's coming from lvm2 <Kamion> ./tools/lvmcmdline.c:990: fprintf(stderr, "File descriptor %d left open\n", fd); <Kamion> the question is whether I care enough to fix it :) I bet those fds are held open by debconf. <jbailey> Kamion: No, by initrd. <jbailey> Kamion: Xu likes to play with random file descriptors. <sivang> anyone has an idea why the swap partiton automagically stopped being created and mounted? how can I put it back to be created automaticall upon each boot? <Kamion> jbailey: well, no, I see it in d-i. <jbailey> Kamion: For some reason ">>" isn't good enough. <Kamion> jbailey: in code that is not descended from anything Xuish :) <jbailey> A'ight. <jbailey> sivang's issue is definetly that, though. <Kamion> ok <jbailey> I should learn enough about lvm to install one. <sivang> (the swap partitoin is not on th lvm) <sivang> jbailey: when I tried the fix my non suspending kernel, it appeared that when using mkinitrd -o initrdfilename it didn't work <sivang> jbailey: whant I prefixed it with /boot it was ok <jbailey> sivang: Oh, like it only worked with a fully qualified path? <sivang> jbailey: that is, mkinitrd -o <sivang> jbailey: yes <sivang> jbailey: I also did an rm -rf for the old one, but I hardly think this voodoo had anything to do with fixing the problem . (though I do that just for good feeling) <Kamion> elmo: would you mind delaying processing the new debian-installer BYHAND, if possible? <elmo> Kamion: err, too late, sorry <Kamion> damn <Kamion> ok, will work around in cdimage somehow * sivang would like to note to another interesting fact - when hibernatig the laptop from an ssh login, when the system is in hibernate mode the ssh loging becomes frozen, when I power on the system back - I even get to see the lease happening back on the ssh login after which I can continue working on through it. (!!!) <Kamion> smurfix: could you please remove all the BitKeeper gunk from the kbd-chooser source package? <Kamion> I don't want to have to merge that every time :) <smurfix> Kamion: Sorry -- will do ASAP. <Kamion> thanks <Kamion> smurfix: I don't think #6706 should be target milestone hoary? <Kamion> Indic fonts are apparently really hard to get right <Kamion> bubulle thinks it'll require a graphical installer <smurfix> Kamion: Hmm, target milestone => noticed in version, it seems. <Kamion> yeah, we don't have a field for that in bugzilla AFAIK :/ <smurfix> ah. food. back in a bit. <T-Bone> daniels: X autodetect works fine on ppc. I was wondering: if autodetect doesn't work on ia64, how comes it works on my box anyway? :) <Kamion> I bet it asks you a resolution question <T-Bone> Kamion: correct <Kamion> that would be autodetection failing <T-Bone> strangely enough it works afterwards <daniels> so it asked you a question on powerpc, or on ia64? <daniels> if it asks you no questions, then autodetection succeeded <daniels> if it asks you about your resolution, autodetection failed, but we can infer all we need (for 60Hz) from the resolution, so that's all we ask <HiddenWolf> daniels: How about someone trading monitors, is there any likelyhood of of blowing up a monitor due to an existing x conf? <T-Bone> daniels: it asked on ia64 <T-Bone> daniels: what i'm saying is that if i increase the value range for vertrefresh and horizsync in xorg.conf, it finds the right freq anyway. I can try completely removing the fields if you want <sivang> bah, suspend and hibernate won't work with the evil nvidia module. <sivang> oh well :) <elmo> HiddenWolf: how's that any more of an issue with or without auto-detect? <T-Bone> daniels: so i'm asking why not simply either 1) not specify default refresh for ia64. or 2) define a large enough range? <HiddenWolf> elmo: I have no idea, but it something to think about either way. <daniels> HiddenWolf: no <tritium> sivang, I've had pretty good success with nvidia, both suspend and hibernate <mantiena> Hi all <daniels> T-Bone: because we have to work out when we configure X if X is capable of working out the monitor's sync ranges by itself <daniels> T-Bone: our current way of determining this only works for i386/powerpc, and the solution cannot go into hoary this late, apparently <sivang> tritium: where you using the proprierity nvidia module? <daniels> T-Bone: so we have to assume that X can't work it out for itself and write out the sync ranges on amd64 and ia64 <tritium> sivang, yes <daniels> T-Bone: i know this is crap <Mitario_> hi everyone <sivang> tritium: did you add it to the modules list in /etc/default/acpi-support ? <mantiena> amu, tonight I installed ubuntu live CD with my installer module ;) <tritium> sivang, no, but I did have to comment out video posting <T-Bone> daniels: what would make X unable to figure out its sync freq? <sivang> tritium: video posting? ok I'll try that. <T-Bone> daniels: because the video hardware range on ia64 is pretty much restrained, afaik <tritium> sivang, yeah, the line that says POST_VIDEO=true. I commented that out. <daniels> T-Bone: the monitor can't do DDC, the driver is crap and doesn't do mode validation right on laptops, the video card is incapable of DDC ... <T-Bone> daniels: you can already skip the last two <T-Bone> no ia64 laptops ;) <T-Bone> and all boxes come with ATI cards, or nvidia in some cases <daniels> T-Bone: i might consider making an exception for ia64, but honestly, the real, real problem we have is amd64 <daniels> and that's unfixable for hoary <sivang> tritium: thanks, I did that, now let's see if it works. <T-Bone> daniels: heh. If making an exception for ia64 is easily feasible, it might improve end user's experience :) <daniels> T-Bone: yeah, but as I said, this kills us badly on amd64, which sucks horribly, but eh, what can you do <tritium> sivang, hope so... <T-Bone> daniels: besides, i doubt one would hook a pre-DCC capable monitor to an ia64 machine ;) <daniels> T-Bone: you'd be surprised <mantiena> Kamion, are you online ? <T-Bone> daniels: not much i guess. I don't have amd64 hardware. If you want to sponsor me, you're welcome :^)) <elmo> yeah, I did at my previous job * daniels looks at the pre-DDC monitor currently hooked up to his amd64. <T-Bone> daniels: people doing so usually know how to setup X :) <elmo> to both an RX-2600 and an i2k <daniels> T-Bone: i have an amd64, and I'm capable of fixing it, but by the time I got to it, feature freeze had slipped, and I had other stuff distracting me for a week, so I couldn't get it in beforehand <T-Bone> but heh, that's subjective. <T-Bone> daniels: heh ok <daniels> so the issue is not people-to-do-it, but people-to-do-it-four-months-ago <T-Bone> lol <elmo> sabdfl really needs to get his act together, both the cloning and time machine projects are still showing no signs of any real progress <T-Bone> rotfl <daniels> elmo: i hope you're not talking about cloning me; one of me is enough pain inflicted on the world <amu> mantiena: well done! <sivang> elmo: wasn't the time machine already done? <Kamion> *groan* <azeem> sivang: there were spurious tachyon emmission AFAIK, so it had to be dumped and redoe from scratch <T-Bone> sivang: well, if it's done in the future, then it's *already* done. Paradox of the time-machine :) <mantiena> amu, but some other d-i modules should be modified a little for working with live-installer <amu> mantiena: did you put infos to the wiki? <sivang> azeem: hehe <mantiena> amu, still not, was pretty simple to write live-installer, I used a lot of functions (like check-target or initrd generating) from base-installer ;) <sivang> tritium: didn't work. any more then just commeting out the VIDEO_POST is it? <mantiena> Kamion, to which udeb belongs apt-install from d-i ? <tritium> sivang, no, the only other thing I did was uncomment the line at the top: ACPI_SLEEP=true to actually enable suspend to ram <Kamion> mantiena: di-utils <Kamion> why does apt-install need to be changed? <azeem> when doing suspend-to-disk, does the network on resume get reconfigured based on the state at suspend, or on what's in /etc/network/interfaces? <sivang> tritium: commented out the line or set POST_VIDEO=false? <tritium> I commented it out. <mantiena> Kamion, some d-i modules (for example grub-installer) uses apt-install to install software, for example grub or initrd-tools, but apt-install does not check if this software is already installed and this couses an error :( <sivang> tritium: well, doens't work for me. crappi dell :) <tritium> sivang, How is it behaving? On my Dell (C840), the only thing I haven't resolved is that I have to press the power button 2X to resume. <pitti> elmo: ping <Kamion> mantiena: apt-install just calls apt-get install, which should exit without an error if the package is already installed. <elmo> pitti: ? <pitti> elmo: is there something like arch.ubuntu.com? <pitti> elmo: i. e a publicly http/sftp accessible place <pitti> elmo: where we can store our arch repos and work on them with non-canonical people? <elmo> pitti: mirror them to rookery is what most people do <pitti> elmo: currently we use to host our repos on chinstrap <mantiena> Kamion, problem is, than during live CD install there are no sources.list and no deb packages (if there are no internet access) and apt-get install produces an error <pitti> elmo: right, but that has to happen manually, right? <mantiena> s/than/that <pitti> elmo: since you cannot/should not ssh from chinstrap to rookery without a password <elmo> Kamion: how do you mirror the seeds? <mantiena> Kamion, I can patch apt-install for checking if package isn't already installed on /target <tritium> sivang, I'm using NvAGP, and nvidia module parameters NVreg_EnableAGPFW=1 NVreg_EnableAGPSBA=1 <pitti> elmo: sabdfl seems to like the idea of arch.u.c <elmo> pitti: IIRC rookery has unrestricted http access to chinstrap <pitti> elmo: ah, that way round :-) <elmo> or https or whatever <pitti> elmo: okay, that's fine <elmo> the name 'arch.ubuntu.com' is already in use <elmo> for an entirely different service <pitti> elmo: would it be possible to update to baz 1.1.1 on rookery? <elmo> done <elmo> tho I hope it doesn't break anyone using 1.0 specific stuff <pitti> huh, thanks :-) <pitti> elmo: no, I'm just afraid that 1.0 could break when mirroring an 1.1 archive <Kamion> mantiena: well the former should be fixed, not the latter <elmo> <random>why do people who are downloading ISOs prefer ftp so much? <Kamion> mantiena: fix the cause, not the symptoms <Kamion> elmo: crappy rsync cron job on chinstrap <Kamion> mantiena: (making apt-install check first would slow regular installs down quite a lot - dpkg -l is not very fast <Kamion> ) <rcaskey_> does anyone know if the hardware database has been specced out? <mantiena> Kamion, maybe, then we can fix at least grub-installer <Kamion> mantiena: huh? <Kamion> mantiena: no <Kamion> mantiena: hmm, the no-network case is awkward, but I don't think any of these proposed solutions are quite correct <mantiena> Kamion, no network case is very usual, especially with live CD <Kamion> sure <mantiena> Kamion, it's one line fix in grub installer <Kamion> but breaking installer error handling is not the answer <Kamion> it's the wrong place <mantiena> Kamion, and it doesn't break an install <Kamion> I am not going to maintain a
{'channel': 'ubuntu-devel', 'month': 3}