[00:00] <LaserJock> yeah
[00:00] <pochu> ouch
[00:00] <hongli> has gtk switched to git?
[00:00] <pochu> err
[00:00] <pochu> 44 changelog lines for one fix???
[00:00] <hongli> it was using svn last time I checked
[00:00] <pochu> hongli: it still uses svn
[00:00] <LaserJock> it's svn still I think
[00:00] <directhex> fails to apply to intrepid package
[00:00] <LaserJock> the "fix" includes new gconf keys, etc.
[00:00] <directhex> this is non-trivial
[00:01] <LaserJock> that's probably like a $200 fix ;-)
[00:01] <hongli> urgh. I wonder whether removing that one liner that was mentioned earlier will fix it
[00:02] <hongli> LaserJock: you know I'm almost willing to pay the $200 if this costs me significantly more time :)
[00:03] <hongli> I'm not a teenager anymore so I can't affort all-week-hacking-sessions like I used to
[00:03] <hongli> in the mean time I'm trying to fix what seems to be a bug in gnome-power-manager...
[00:09] <directhex> jms@destiny:/tmp/gtk+2.0-2.14.4.orig$ patch -p1 < ../part2.patch
[00:09] <directhex> patching file gtk/gtkfilechooserdefault.c
[00:09] <directhex> patching file gtk/gtkfilechooserdialog.c
[00:09] <directhex> patching file gtk/gtkfilechoosersettings.c
[00:09] <directhex> patching file gtk/gtkfilechoosersettings.h
[00:22] <directhex> jms@destiny:/tmp$ diffstat debdiffy.diff
[00:22] <directhex>  debian/patches/099_fix_small_filechooserdialog.patch |  398 +++++++++++++++++++
[00:22] <directhex>  gtk+2.0-2.14.4/debian/changelog                      |    7
[00:22] <directhex>  gtk+2.0-2.14.4/debian/patches/series                 |    1
[00:22] <directhex> big patch
[00:24] <pochu> indeed
[00:26] <directhex> build build build
[00:27] <pochu> PPA!
[00:28] <hongli> I've heard of the PPA. how does it work?
[00:28] <directhex> pochu, i'm not cluttering my own PPA with things like gtk
[00:28] <directhex> hongli, upload source package, get repository.
[00:28] <hongli> is it just a repository that happens to be maintained by a random person that has a launchpad account?
[00:29] <directhex> yes
[00:29] <hongli> hm you say *source* package
[00:29] <pochu> hongli: it's a Launchpad service for every user or team
[00:29] <hongli> so launchpad builds packages for different distro versions for you?
[00:29] <pochu> right
[00:29] <pochu> for the one you upload it
[00:29] <directhex> only different ubuntu versions, but yet
[00:29] <hongli> so how do you deal with differences between distro versions?
[00:29] <pochu> you can upload to hardy, intrepid, jaunty, etc
[00:30] <directhex> stupid crappy slow c
[00:30] <hongli> for example, suppose that you're packaging git which depends on git, but ubuntu 8.04 comes with libsome_dependency1.2 while 8.10 comes with libsome_dependency1.4
[00:30] <hongli> the package names are different in both distro versions
[00:31] <directhex> you upload once per target release
[00:31] <hongli> so you have to upload one source package per ubuntu release?
[00:31] <directhex> it can handle multiple versions of the same package (but not multiple copies with the same version number)
[00:32] <directhex> so yes, you'd upload 1.0-1~intrepid~ppa1 and 1.0-1~hardy~ppa1 separately
[00:34] <maxb> though you can save yourself bandwidth by only including the .orig.tar.gz once
[00:35] <directhex> if you remember the right debuild flags to do so
[00:36] <pochu> does it?
[00:37] <LaserJock> as long as the .orig.tar.gz is in either Ubuntu or your PPA you don't need to include it
[00:38] <directhex> hurry up, pbuilder
[00:42] <pochu> and I was always uploading the orig tarballs...
[00:42] <directhex> pochu, well, it's only a problem when you're an OOo packager :)
[00:43] <pochu> well, eclipse is *huge* too ;)
[00:44] <directhex> yes
[00:45] <directhex> and has elite java powers meaning it eats ram for fun
[00:46] <pochu> heh
[00:46] <pochu> so does wxwidgets2.8
[00:46] <directhex> no really, i worked on ikvm packaging, and the ikvm build process involves compiling openjdk
[00:46] <directhex> i thought there was a terrible memory leak, but no! the memory leak is called "javac"
[00:46] <directhex> 1.3 gig of ram later, it finishes
[00:47] <pochu> heh
[00:48] <directhex> dpkg-deb: building package `libgtk2.0-0' in `../libgtk2.0-0_2.14.4-0ubuntu2_amd64.deb'.
[00:48] <directhex> hongli!
[00:49] <hongli> nice, thanks :) I appreciate it
[00:49] <hongli> let me test
[00:49] <hongli> oh, I'm on x86 :/
[00:50] <pochu> PPA!!
[00:50] <pochu> :P
[00:58] <TheMuso> 8/c
[00:58] <hongli> this one, right? https://launchpad.net/~directhex/+ppa-packages
[00:58] <pochu> nice split
[00:59] <pochu> good night folks
[00:59] <pochu> hongli: good luck!
[00:59] <hongli> thanks pochu
[00:59] <hongli> gnight
[01:01] <hongli> how do I install a PPA's gpg key? there doesn't seem to be any instructions
[01:01] <hongli> or a download link to a gpg file
[01:02] <hongli> ok never mind, I figured it out. :) just not as easy as the one-liners I'm used to
[01:02] <LaserJock> yeah, I think they're working on that
[01:03] <LaserJock> they just started really rolling out the package signing
[01:04] <hongli> directhex: I don't see libgtk in the package list
[01:16] <hongli> time to sleep, bye
[01:28] <calc> if i you rename a folder in evolution does it not really rename it?
[01:28] <calc> i tried renaming my old folder for the mailing list to the new name and then changing my filter but it claims the new name doesn't actually exist
[01:30]  * calc is going to brute force fix it by moving all messages deleting the folder then recreating it (maybe that will work?) :)
[01:31]  * ScottK considers trying to seduce calc back to the dark ways of KDE ...
[01:32] <calc> ScottK: does kmail not eat mail anymore, back when i maintained people were always complaining about how crap it was ;-)
[01:32] <calc> back then i just used mutt
[01:32]  * calc is beginning to think he should go back to mutt with imap
[01:33] <ScottK> For pop3, no it does not in my experience.
[01:33] <ScottK> No idea about imap, although I understand it's way better than it used to be.
[01:34] <calc> ScottK: ok
[01:35] <ScottK> calc: I've also heard it got substantially better in KDE 4.2 (haven't tried it yet).
[01:35] <calc> if thunderbird wasn't so bad i would have stayed with it
[01:35] <calc> ScottK: ok
[01:36] <calc> whenever they fix sorting based on imap headers i will probably switch back to thunderbird
[01:37] <calc> that bug has been open for ~ 6 years though so i doubt it will be anytime soon
[01:37] <calc> wow evolution just crashed on me while moving messages
[01:37] <calc> lovely
[01:38] <calc> and now it won't start back up
[01:38] <calc> f*ck bus error from less i need to reboot
[01:39]  * ScottK has bugs filed on mozilla (seamonkey) prior to 1.0 still open.
[01:39] <calc> bbl
[01:40] <calc> actually i'm on irc from a stable machine, just via ssh :)
[02:29] <calc> even deleting and remaking the folder in evolution doesn't work
[02:56] <raof> directhex: Do you have any idea why libmono-cairo2.0-cil doesn't ship a pkgconfig file?
[02:56] <raof> Also, I'd like to stab f-spot's autofoo maintainer for putting all of the pkg-config dependencies in a single call.
[04:12] <ScottK> On the off chance that there's an archive admin awake, paying attention, and with a moment to do something (and an associated willingness), would you please accept kdebase-workspace into intrepid-proposed.  This is part one of the bluetooth fix for KDE and part two has to build against it.
[04:14]  * StevenK mumbles
[04:20] <Junowat> hi everyone
[04:22] <ScottK> StevenK: Thank you.
[04:22] <StevenK> ScottK: Oh, you saw?
[04:22] <ScottK> Got that accepted.
[04:22] <ScottK> that/the
[04:23] <Junowat> I was hoping to find out more about Ubuntu Developer Week.
[04:25] <Junowat> is this an active room?
[04:26] <ScottK> Not so much this time of day.  Try #ubuntu-classroom later in the day (not sure how much).
[04:27] <Junowat> unfortunately that was on Monday
[04:27] <Junowat> https://wiki.ubuntu.com/UbuntuDeveloperWeek/
[04:28] <Junowat> I was hoping that there would be an overview of the different development teams somewhere
[04:28] <Junowat> I am a developer
[04:28] <Junowat> and I wanted to see which teams needed people and where I would fit in based on my skills
[04:29] <ScottK> What are you interested in?
[04:29] <ScottK> The Ubuntu Developer Week presentations go on all week.
[04:30] <Junowat> I'm interested in doing programming work (as well as build/packaging)
[04:30] <ScottK> Are you interested in KDE/Gnome/Server stuff ....
[04:33] <Junowat> why not?  =)
[04:33] <Junowat> I am open to all of them.
[04:34] <Junowat> though I have only used Gnome (not KDE)
[04:34] <ScottK> It's generally better in the long run if you focus where your interests are.
[04:34] <Junowat> right
[04:34] <ScottK> Then I'd suggest #ubuntu-desktop, but it'll probably be quiet this time of day.
[04:34] <Junowat> I agree
[04:35] <Junowat> well that is why I am trying to find out what the different areas are
[04:35] <Junowat> in other words, what are the choices (and then pick out of a,b,c, ... etc)
[04:36] <ScottK> There are really as many choices as all the stuff in the Ubuntu archive.
[04:36] <ScottK> In #ubuntu-motu we package and maintain the Universe repository.  We also teach people about packaging.
[04:36] <ScottK> It might be best to start there.
[04:36] <Junowat> OIC that makes sense
[04:37] <Junowat> I'd need to know that process in order to work with any of the teams
[04:37] <Junowat> I looked on the Ubuntu developer wiki here: https://wiki.ubuntu.com/UbuntuDevelopment
[04:38] <Junowat> and it seemed like there are only 2 different groups: ubuntu core developers and MOTU
[04:39] <Junowat> that seemed a bit simplistic and I was hoping for more
[04:40] <ScottK> The archive is divided into two main parts and those teams follow those.
[04:40] <ScottK> But there are also people who focus on Gnome, KDE, and Server things.
[04:40] <ScottK> Also language specific areas too.
[04:41] <ScottK> For example, #ubuntu-java
[04:42] <Junowat> you seem to know a lot about this ScottK
[04:42] <Junowat> thanks!
[04:43] <Junowat> Is there any resource online that I can use to find out more
[04:43] <Junowat> (I don't want to pepper you with all my questions)
[04:44] <ScottK> https://wiki.ubuntu.com/UbuntuDevelopment pretty well will lead you everywhere eventually.
[04:44] <ScottK> Which you already started with.
[04:48] <Junowat> thanks ScottK
[04:48] <Junowat> appreciate the info
[04:49] <ScottK> Junowat: You're welcome.
[04:49] <Junowat> From what you're telling me as well as what I read on the dev wiki, it looks like the motu team is where I should start (plus they offer mentoring)
[04:49] <Junowat> cheers!
[04:54] <lamont> WTH did booting an intrepid dhcp host result in resolv.conf having both search and domain directives?  I mean, this isn't 1992
[05:14] <calc> wow it took 26m to install jaunty, seems a bit slow
[05:14] <raof> Is that from livecd?
[05:14] <calc> from alt cd
[05:15] <bluesmoke> dude I wish mine were 26m
[05:15] <raof> That's closer to expected, but still a while.
[05:15] <raof> I'd be concerned if that was the livecd!
[05:15] <bluesmoke> my LiveCD installs have always taken like 30-40 minutes
[05:15] <bluesmoke> except for maybe the very first one I did when we first started doing LiveCD installs
[05:18] <raof> What sort of hardware are you installing on, and are you including time to do the configuration?
[05:19] <raof> This install took longer to select keymap, language, partition, username, etc than it did to actually install.
[05:19] <LaserJock> holy smokes
[05:19] <calc> raof: 26m c2d laptop and did selections as fast as possible, already pre-partitioned so just selected manual and told it what to format as
[05:19] <LaserJock> I think mine always take at least 30 min.
[05:20] <raof> Again, we're talking the livecd?  Strange!
[05:20] <LaserJock> both
[05:20] <calc> raof: my 26m was amd64 alternate cd (not live cd)
[05:20] <calc> raof: and was timed from the time it booted until it rebooted
[05:21] <raof> Right.  26m isn't too bad for the alternate cd.
[05:21] <raof> That's probably about what mine takes.  The live cd was much, much faster.
[05:21] <calc> livecd is too slow, heh
[05:21] <calc> raof: the livecd installs faster for you than alternate cd?
[05:22] <raof> Yes.
[05:22] <calc> hmm ok
[05:22]  * calc thought it would have been slower due to having to boot into gnome
[05:23] <raof> Oh.  I was calculating from "Start the installer", not "boot the CD".
[05:24] <raof> It might be longer from that.  But I was testing the live session, anyway.
[05:24] <calc> oh ok
[05:24] <LaserJock> 95% of the time I do Alternate installs so I might be wrong on my LiveCD timings
[05:27] <raof> But blitting the files to disc & formatting was ~5min, or so.
[05:27] <calc> ah thats not too bad
[05:27] <calc> i formatted 160gb which seemed to take almost that long itself
[05:38]  * calc is wondering why he installed jaunty after seeing gnome panel not start
[05:38] <calc> oh it finally started it just took forever, omg
[05:40] <calc> wow something is really wrong with this its dragging badly
[05:42] <calc> and my cursor is jumping all over the place
[05:42] <calc> and xorg is sitting at 50% cpu usage doing nothing
[05:42]  * calc thinks he will reinstall intrepid
[06:20] <glick> hey is a squashfs red error usually a sign of a bad cd-room when booting a live cd?
[06:29] <liw> glick, yes
[07:19] <savvas> will ubuntu have support for apt pdiff?
[07:20] <LaserJock> at some point maybe
[07:22] <savvas> LaserJock: do you know how it works? is it a binary diff or does it work with source packages?
[07:24] <LaserJock> savvas: well, pdiffs just give you deltas for the Packages or Sources index files
[07:25] <LaserJock> makes apt-get update faster for often-updating systems
[07:27] <dholbach> good morning
[07:31]  * slangasek waves
[07:31] <dholbach> hiya slangasek
[07:51] <tjaalton> TheMuso: it's still busted here
[08:12] <pitti> Good morning
[08:12] <pitti> apw: I didn't get an email about a merge request; which branch?
[08:42] <directhex> pitti, is the debhelper version jaunty ships with finalised?
[08:42] <pitti> directhex: we can update it if necessary, but without a particular reason it is yes
[08:45] <directhex> hm. joeyh made some lovely changes to 7.1 which broke mono-related things to death. they've been worked around, but now it's either dh7.1 in jaunty, or merges rather than syncs needed to revert those workarounds in some key packages (including mono itself)
[08:45] <apw> pitti, https://code.launchpad.net/~apw/apport/suspend-resume-report-stress-log
[08:45] <directhex> my gut says merging is safer at this stage in the release
[08:45] <directhex> my gut also says merges freaking suck
[08:46] <pitti> directhex: yes, if we can sync a lot of packages with that and avoid merges, it's definitively preferable
[08:47] <directhex> pitti, to sync things, i need dh7.1. the minor irony being i think dh generally needs merging, not syncing ;)
[08:47] <directhex> pitti, let me know which you prefer to do. i need to go and see a power meter about some watts
[08:48] <pitti> directhex: oh hang on, 7.1 is experimental; I hope that's just because testing is frozen, not because it breaks stuff
[08:51] <directhex> pitti, so do i :/
[08:51] <directhex> pitti, experimental is the new unstable. we need a new repo for experimental things too experimental for experimental!
[08:52] <seb128> we need to get lenny available and start using unstable again rather ;-)
[08:54] <directhex> seb128, well, the problem with releasing on the same day as duke nukem forever is...
[09:52] <dholbach> are there any reports of sound not working in jaunty?
[09:53] <DktrKranz> dholbach: I had some issues, I worked-around it with alsamixer
[09:54] <DktrKranz> they're related to bug #315971
[09:57] <dholbach> DktrKranz: ahhh, thanks
[09:57] <dholbach> that made it work again :)
[09:58] <tjaalton> unfortunately alsamixer fails to work here :/
[09:58] <tjaalton> but that's already on lp
[09:59] <DktrKranz> dholbach: you have to redo it every reboot, saving settings is not enough, but at least it works :)
[10:03] <dholbach> DktrKranz: narf!
[10:10] <dholbach> DktrKranz, tjaalton: do you know if there's a way to set "sound profiles"? what I'd love to do is set specific values for mic and mic boost (depeding on if I use skype or record a mixtape)?
[10:11] <tjaalton> dholbach: sorry, no idea
[10:12] <dholbach> TheMuso: ^ do you know if such a thing exists?
[10:13] <dholbach> or maybe set the mic settings with a script or some such?
[10:15] <broonie> dholbach: That's not there yet.
[10:16] <broonie> There's some in progress work on ALSA scenario support (the embedded world *really* wants it) but there's nothing standard ATM.
[10:16] <dholbach> broonie: do you know if there's a hackish way to mess with the settings via a script?
[10:17] <broonie> alsactl store -f <filename>
[10:17] <broonie> alsactl restore -f <filename>
[10:17] <dholbach> ahhhhhhhh!
[10:17]  * dholbach hugs broonie
[10:17] <broonie> will save and restore all the settings.
[10:17] <dholbach> that sounds like rock and roll to me
[10:18] <broonie> The core of teh scenario stuff is being able to do that automatically and only adjust some controls.
[10:22] <directhex> know what would be nice? if soft-pin-based chips like ALC888 could gain hardware support from a userland file rather than from a compiled-into-kernel list of per-model pin maps
[10:22] <directhex> even better, the ability to read pin maps from windows .inf files
[10:25] <broonie> AIUI half the problem is that the data you're supposed to be able to read from H/W is often full of lies.
[10:26] <broonie> There are already some facilities for reconfiguring HDA stuff from user space, it'd be more front end work than anything else doing what you want.
[10:27] <broonie> (AIUI, I've not worked much on HDA.)
[10:28] <directhex> it took 3 years for this mac to get audio support in ubuntu, despite having a "supported" chip, due to a lack of valid pin map in the kernel module
[10:54] <broonie> directhex: The ALSA people (mostly Takashi for that) are very quick to turn that stuff around, sounds like an issue getting the issue upstream to them :(
[11:38] <_max> Anyone happen to have a deeper understanding of how the ubuntu-netinstall works? im trying to modify it to instead of executing the installer, execute a script (a backup script).
[11:43] <kwwii> pitti: heads up, some issues with internationalization, naming and freaky problems with the emblem interface were found by an artwork member...I pointed him your (and seb's) way as I have no idea what is going on
[11:44] <kwwii> just so you know why you are being subscribed to human-icon-theme bugs :-)
[11:44] <pitti> kwwii: okay
[12:03] <cjwatson> _max: yes - have you read the preseeding documentation?
[12:03] <cjwatson> _max: you can't really not execute the installer *at all* though.
[12:04] <cjwatson> but you might perhaps want to run the bits of it that do hardware detection?
[12:11] <_max> cjwatson, well what im trying to do is replace a very expensive product we use with something simple, since we only use like 2% of the product anyway =/
[12:11] <_max> my intention is to netboot a kernel (ubuntu is usually able to detect just about everything)
[12:12] <_max> then load a script that determines mac address + time, and dd's an image through tar.gz onto a nfs drive.
[12:12] <cjwatson> some hardware detection happens in userspace, remember
[12:12] <_max> i thought il create a netboot image for save and one for restore.
[12:12] <_max> Yes thats true.
[12:13] <cjwatson> _max: so have you tried using preseed/early_command? You could have it run a script and then reboot.
[12:13] <_max> we basicly only have one type of server though, and its just smudged with linux friendly intel chips.
[12:13] <cjwatson> (see https://help.ubuntu.com/8.10/installation-guide/i386/appendix-preseed.html)
[12:13] <_max> cjwatson, i have not, i will now, thank you :)
[12:13] <cjwatson> and https://help.ubuntu.com/8.10/installation-guide/i386/preseed-advanced.html#preseed-hooks
[12:14] <directhex> mmm... d-i preseed...
[12:51] <cjwatson> I don't suppose anyone could translate https://answers.launchpad.net/ubuntu/+source/ubiquity/+question/57470 for me?
[12:53] <cjwatson> ogasawara: http://qa.ubuntu.com/reports/ogasawara/jaunty-buglist.html seems to return HTTP 403 all of a sudden
[12:54] <StevenK> cjwatson: Google translate does a fairly decent job of translating it
[12:54] <cjwatson> thanks
[13:03] <primes2h> pitti: Hi :-)
[13:04] <primes2h> pitti: kwwii told me to contact you...
[13:04] <primes2h> pitti: I know he told you about emblems issues...
[13:10] <primes2h> pitti: I just need to ask you something about internationalization...
[13:53] <\sh> doko_: looks like that our (and obviously others) sun-java6-jdk/jre is heavily broken :( (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6755573) and I can reproduce this quite easily
[13:54] <pitti> primes2h: sure, what's up? (sorry for delay, was at lunch)
[13:55] <pitti> primes2h: ah, you sub'ed me to a bug; will look at it soon
[13:56] <primes2h> That's nice.. I would like to ask you another thing about human-icon-theme....
[13:56] <primes2h> I made a patch for this bug #172353
[13:57] <primes2h> (I faced the other bug working on this one)
[13:58] <primes2h> Is it normal that I have to launch make update-po manually from eithin /po directory in human-icon-theme to regenerate .po files?
[13:58] <primes2h> from within
[13:59] <primes2h> If I build the package (e.g. ./autogen.sh and make, or debuild) it doesn't regenerate new .po files.
[13:59] <pitti> primes2h: regenerate> you mean merge to an updated pot? yes
[13:59] <pitti> it really shouldn't
[13:59] <pitti> packages which always merge po files on build are a pain in the butt
[14:00] <pitti> (cause constant stream of diff noise, etc.)
[14:00] <primes2h> ah, ok...
[14:00] <pitti> and usually a dev knows when he changed a string, and wants to update the languages he knows about
[14:00] <primes2h> so, before building the package I need to launch make update-po.
[14:01] <primes2h> That's what I needed to know.
[14:01] <primes2h> Thank you very much!
[14:01] <pitti> primes2h: hang on
[14:01] <primes2h> ok
[14:01] <pitti> primes2h: *why* do you need to update them so often?
[14:02] <pitti> primes2h: this bug doesn't sound like needing to update actual translations?
[14:03] <primes2h> no, I nedd this just with the patch i made, because it set up emblems translation.
[14:03] <pitti> primes2h: right, but that still doesn't need merging the .po files
[14:03] <primes2h> There isn't in the original package.
[14:04] <primes2h> I'll let you show...
[14:04] <pitti> primes2h: let's take a step back
[14:05] <pitti> primes2h: do you know what msgmerge is and when to use it?
[14:09] <primes2h> in fact no :-). but please follow me for 1 moment. :)
[14:11] <primes2h> compare po in gnome-icon-theme with po in human-icon-theme.
[14:12] <primes2h> in gnome-icon-theme you find emblems strings
[14:12] <primes2h> in human-icon-theme no.
[14:13] <hwilde> is there a roadmap for the future of nm and /etc/network/interfaces ?
[14:13] <primes2h> I had a look at human-icon-theme source and I find there is a lack of translation infrastructure for emblems (.icon.in files etc...)
[14:14] <pitti> primes2h: right, msgunfmt /usr/share/locale-langpack/de/LC_MESSAGES/human-icon-theme.mo just has one string (the theme name)
[14:14] <primes2h> in gnome-icon-theme instead you can translate them
[14:14] <pitti> right
[14:14] <primes2h> because it has the correct infrastucture.
[14:15] <primes2h> That's the issue of bug #172353
[14:15] <pitti> so the strings aren't marked as translatable in the Code then?
[14:15] <primes2h> and that's what my patch does.
[14:16] <primes2h> yes, because in the code there are just the icon files, but not the .icon.in files.
[14:16] <primes2h> (and you need to change Makefile.am and POTFILES.in  too obviously)
[14:17] <primes2h> but when I build the package I found that .po files remain the same (one string)
[14:18] <primes2h> it's not "updated"
[14:18] <pitti> primes2h: right, then you need to do update-po exactly once
[14:18] <primes2h> Correct!
[14:18] <pitti> (not with every build)
[14:19] <primes2h> yes, my question was if it's normal, I don't know about it
[14:20] <primes2h> if it's normal for this kind of patch
[14:20] <primes2h> have a look http://pastebin.ubuntu.com/108177/
[14:20] <pitti> primes2h: yes, that's the purpose of update-po; if you change strings in the source, you need to call it once to provide translators with an updated 'template'
[14:21] <primes2h> this is my first patch, could you please have a look if it's correct?
[14:21] <pitti> primes2h: please don't use debian/patches/
[14:22] <pitti> human-icon-theme is an ubuntu native package, please just change it inline
[14:22] <pitti> primes2h: it is maintained in bzr instead, so please feel free to make a branch and mention the branch on the bug
[14:22] <pitti> primes2h: if you don't want to use bzr, just make a normal debdiff
[14:22] <pitti> but please no patch system
[14:23] <pitti> primes2h: I don't understand why we need a separate .icon.in file? shouldn't the string be extractable from the actual .icon file? or .icon.in be generated from .icon?
[14:23] <pitti> how does gnome-icon-theme do that?
[14:24] <primes2h> I think .icon is generated from icon.in. if you llok at gnomne-icon-theme source you'll find .icon.in file in scalable/emblems/
[14:25] <primes2h> and .icon files are generated during building.
[14:25] <pitti> primes2h: ah, ok; then the source package shouldn't ship .icon any more
[14:25] <savvas> pitti: do you have a minute to spare?
[14:25] <primes2h> in human-icon-theme source there no .icon or .icon.in files at all.
[14:26] <primes2h> just .svg files
[14:26] <pitti> !ask | savvas
[14:26] <savvas> pitti: Bug #23568, bug #140934 and bug #304767 link to upstream http://bugzilla.gnome.org/show_bug.cgi?id=354661 - one of them is private, can you choose one "master" from them?
[14:26] <savvas> I don't know if the private one is duplicate though
[14:27] <pitti> savvas: I can't read the private one either
[14:27] <primes2h> pitti: I'll do a simple debdiif and I'll show you later, ok?
[14:27] <pitti> savvas: I guess the first ones are really dupes, but I can't be 100% sure without testing the upstream fix
[14:27] <pitti> primes2h: cheers
[14:28] <primes2h> pitti: Thank you very much...
[14:28] <savvas> pitti: I'll see if I can create a patch for debian and ubuntu packages
[14:31] <hwilde> anybody on lm-sensors:   sensors-detect could modprobe the modules it suggests adding to /etc/modules, would be helpful
[14:37] <Karnaugh> hrm
[14:38] <Karnaugh> is there a specific channel for the ubuntu livecd
[14:38] <Karnaugh> trying to figure out how to remaster it to have a maximum screen resolution
[14:52]  * calc wonders how linux can md5sum a 700mb file in 1.7s off a hd
[14:52] <pitti> Penguin Power!
[14:53] <pitti> calc: maybe it was still in the cache?
[14:53] <cjwatson> Karnaugh: the Ubuntu live CD just uses X's automatic configuration, so if you're having trouble with that, you would be best off talking to the X people
[14:54] <doko_> \sh: 6u12 isn't released yet
[14:54] <ScottK> doko_: Are we going to get python 2.6 soon?
[14:54] <Karnaugh> cjwatson: well, when I replace the empty /etc/X11/xorg.conf with the same basic one dexconf creates but with some mode lines
[14:54] <Karnaugh> cjwatson: it gets overwritten at boot
[14:54] <doko_> ScottK: yes
[14:54] <Karnaugh> cjwatson: so I would assume something from Ubuntu changes is forcing dexconf to run
[14:55] <ScottK> doko_: Great.  I'm also looking forward to Python 3 support in pycentral.
[14:55] <ScottK> I've got one module to package that supports it upstream already.
[14:55] <cjwatson> Karnaugh: that would be /scripts/casper-bottom/20xconfig in the initramfs, which runs dpkg-reconfigure xserver-xorg
[14:56] <calc> pitti: hmm i guess so, it seemed to spit out real info
[14:56] <cjwatson> Karnaugh: if you have already configured X in the squashfs, then you can remove that script from the initramfs (with the caveat that that means it will probably only work well on similar systems to yours)
[14:57] <Karnaugh> cjwatson: ok thanks
[14:57] <Karnaugh> cjwatson: the config it seems to create is bland enough that the rest of X auto config stuff should just happen
[14:57] <Karnaugh> cjwatson: problem I have is often it decides to use resolutions way higher than the screen is really usable on
[14:58] <cjwatson> Karnaugh: that's an X bug, and we'd appreciate it if you could report it so that we can make it work
[14:58] <Karnaugh> cjwatson: righto
[14:58] <cjwatson> (cf. http://wiki.ubuntu.com/X/Reporting)
[14:59] <Karnaugh> cjwatson: got 3 of the same IBM boxes here which do it - I think the LCD is crap though so DPMS doesn't work
[15:05] <calc> Karnaugh: what size lcd and what resolution was it attempting?
[15:09] <Karnaugh> calc: 17" LCD and I don't know what res it tried, the LCD just spazzed outand turned off but X was starting fine behind it
[15:09] <calc> Karnaugh: oh ok
[15:11] <tkamppeter> pitti, when will you do your next SRU/-proposed run?
[15:11] <pitti> tkamppeter: tomorrow morning
[15:12] <tkamppeter> OK, I asked because of letting CUPS and foomatic-filters go into -proposed.
[15:16] <tkamppeter> pitti, in bug 308817 I have proposed a simple patch backported from GS 8.64 to solve the problem for at least a part of the reporters (with the others probably bitten by bug 299918). We could SRU it, too. I could make a GS package for Intrepid which you could move to -proposed tomorrow, too.
[15:19] <pitti> tkamppeter: a gs patch backported to cups?
[15:21] <tkamppeter> pitti, the bug has a ghostscript task which I have nominated for Intrepid. The CUPS task I will mark invalid.
[15:22] <tkamppeter> And ubottu will still consider this a CUPS bug: bug 308817
[15:22] <tkamppeter> ubottu has improved!
[15:41] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek - Day 4 to kick off in #ubuntu-classroom in 19m. :-)
[15:46] <calc> umm if you aren't hooked up to a network when installing via alternate cd it comments out the security lines in sources.list ?!
[15:51] <cjwatson> calc: fixed in jaunty
[15:51] <calc> cjwatson: great :)
[15:51] <ogra> calc, else it would hang in apt-get update
[15:51] <cjwatson> ogra: not true any more
[15:51] <ogra> right
[15:51] <calc> ogra: it doesn't verify all the other lines in the sources.list though and doesn't comment them out, it just comments out the security ones
[15:52] <cjwatson> hasn't been true for a long time. It was just a mistake in apt-setup that it behaved this way
[15:52] <cjwatson> I'd really prefer people not to say "it's meant to be that way" about installer bugs, especially when I've already answered them :)
[15:52] <calc> heh :)
[15:53] <calc> i tried going to jaunty last night after intrepid blew up on me but it was too broken to use
[15:53] <calc> xorg was sitting at 50% cpu and cursor was jumping all over the place :-\
[15:57] <pitti> calc: might be bug 307306
[15:57] <pitti> calc: did you check Xorg.0.log for thousands of randr calls?
[15:58] <calc> pitti: no, it was so slow i barely could get it to shut down
[15:58] <tkamppeter> pitti, bug 308817 is now ready for an SRU. New Ghostscript uploaded into -proposed.
[15:58] <pitti> calc: that is the case for me as well when running on battery or changing anythign power related
[15:59]  * ogra curses qemu 
[15:59] <calc> pitti: i have the same video as listed in that bug so its most likely the same bug
[15:59] <calc> pitti: i was running on AC when i was seeing the problem
[15:59] <ogra> why does it offer me a mode that redirects stdio if it doesnt accept ctrl-c on stdio then :/
[15:59] <ogra> silly thing
[16:01] <cjwatson> I recently applied Peter Clifton's patches, but haven't been running for long enough to be certain that they fix the problem for me
[16:01] <ogasawara> cjwatson: hrm, I'll investigate why the jaunty-buglist is broken.  Feel free to use http://qa.ubuntu.com/reports/ogasawara/qa-jaunty-buglist.html as an alternate view for now
[16:02] <cjwatson> it feels a bit smoother, but we'll see
[16:02] <cjwatson> ogasawara: thanks
[16:26] <ogasawara> cjwatson: http://qa.ubuntu.com/reports/ogasawara/jaunty-buglist.html is back up
[16:26] <cjwatson> thanks!
[16:46] <cjwatson> asac: threw an ancient bug over to you, bug 8980
[16:47] <cjwatson> asac: I'm changing the tag from qa-jaunty-foundations to qa-jaunty-desktop; if you reassign it back for whatever reason, could you set the tag appropriately too?
[16:47] <asac> sure
[16:49] <ScottK> cjwatson: I'm not sure how that got pushed to network-manager.  I've seen that on servers with no NM at all.
[16:51] <cjwatson> ScottK: Well, read my last comment, as there is definitely a network-manager bug
[16:51] <cjwatson> ScottK: if you think there is an issue with *current* installations, I need the full /etc/hosts file
[16:51] <cjwatson> in which case it should not be reassigned back from network-manager, but an extra task should be added on netcfg
[16:52] <ScottK> OK.  Let me check and see if if I stil have it anywhere.
[16:53] <asac> cjwatson: nm doesnt touch /etc/hosts if you have ifupdown plugin in use. there were times when NM did this during intrepid cycle though.
[16:53] <asac> anyway, its still a bug
[16:54] <asac> nm seems to behave not properly for debian when you enable the "update host" feature
[16:54] <cjwatson> asac: That explains why I can't trigger it now, certainly; but we should bring that code into line with current practices just in case
[16:54] <asac> which isnt the default hough
[16:54] <ScottK> cjwatson: Does a hardy box count as a 'current' installation?
[16:54] <cjwatson> ScottK: yes
[16:54] <cjwatson> current enough to be interesting, anyway
[16:54] <asac> cjwatson: you should be able to reproduce by disabling ifupdown in /etc/NetworkManager/nm-system-settings.conf
[16:54] <asac> and killall nm-system-settings afterwards
[16:54] <cjwatson> ScottK: (reload the bug and look at my last comment)
[16:54]  * ScottK looks
[17:07] <calc> is there a way to restore evolution backup on a new install without having to 'setup' evolution again first?
[17:07] <ScottK> cjwatson: Added to the bug.
[17:07] <calc> i have the backup but it won't let me get to the point to restore it without setting it up first afaict
[17:08]  * calc thinks this was a bit of a oversight by developers
[17:08] <calc> doh i see it is there
[17:08] <calc> nevermind
[17:09] <calc> you just have to go past the first page to get to it :)
[17:09]  * calc doesn't recall seeing that page the last time he had to do a restore
[17:33] <cjwatson> ScottK: that log shows, from postfix configuration:
[17:33] <cjwatson> Jan 26 16:41:46 in-target: setting destinations: mailout02.controlledmail.com, mailout02, localhost.localdomain, localhost
[17:34] <cjwatson> ScottK: which sort of suggests that hostname --fqdn worked at installation time - where else would it get that?
[17:34] <ScottK> Interesting.
[17:34] <cjwatson> ScottK: is it possible that anything else could have deleted the FQDN from /etc/hosts?
[17:35]  * cjwatson goes to have a poke at netcfg
[17:35] <ScottK> I don't have any non-packaged software on that box except a few scripts that definitely aren't doing that.
[17:36]  * ScottK can't think of anything unusual installed there.
[17:36] <cjwatson> it *is* possible for netcfg to write it that way, admittedly
[17:36] <cjwatson> I'm just wondering how postfix got it
[17:37] <ScottK> I think it may come up in a debconf question for postfix
[17:37]  * ScottK tries to remember
[17:37] <cjwatson> ScottK: it looks like static networking; can you confirm?
[17:37] <ScottK> Yes. It's static
[17:38] <lamont> --fqdn comes from resolv.conf comes from dhcp...
[17:38] <cjwatson> ScottK: OK - and can you attach /etc/resolv.conf?
[17:38] <cjwatson> lamont: no DHCP
[17:38]  * lamont is in meeting
[17:39] <ScottK> cjwatson: Sure.  Getting.
[17:49] <azimutt> buenas
[17:49] <apw> jerone, about?
[17:55] <ScottK> cjwatson: Added resolv.conf to the bug.
[18:09] <ogra> dpkg-preconfigure: unable to re-open stdin:
[18:09]  * ogra wonders if that should worry him
[18:10] <ScottK> cjwatson: I did confirm that there's s debconf question in the postfix setup that might explain it having that information.
[18:18] <cjwatson> ScottK: looks like the domain wasn't set at netcfg time. Final question, I hope; /var/log/installer/cdebconf/questions.dat?
[18:32] <ScottK> cjwatson: Attached.
[18:34]  * calc notes 8.10 is now not working for him either stupid iwl3945 isn't connecting anymore
[18:35]  * calc hopes 9.04 ends up being more reliable than 8.10 wifi
[18:35]  * calc has had trouble with 8.10 wifi many times and didn't need it to happen again today
[18:37] <ScottK> calc: Did you try the kernel in -proposed?
[18:39] <calc> ScottK: i think evolution in proposed ate my system so i was trying to avoid using proposed anymore
[18:39] <ScottK> Generally a good rule, but IIRC there are some 3945 fixes in it.
[18:40] <calc> hmm ok i'll see if i can somehow selectively upgrade just the kernel
[18:40] <LordMetroid> Does Evolution need to be installed?
[18:40] <calc> LordMetroid: if i want decent imap support, well in this case just slightly more decent than thunderbird
[18:40] <LordMetroid> I've never found such an application relevant to my interests...
[18:40] <ScottK> calc: Enable proposed and then apt-get install the appropriate kernel metapackage
[18:41] <LordMetroid> But if I try to remove it, the package manager wants to remove whole gnome...
[18:41] <LordMetroid> Is this a bug?
[18:41]  * calc is going to test -7 first then maybe upgrade to the one in proposed
[18:41] <calc> LordMetroid: hmm did you try removing evolution or evolution-data-server?
[18:42] <calc> LordMetroid: e-d-s is used by gnome in general but i think you probably should be able to remove evolution the app
[18:47] <lool> cjwatson: When starting a vm with init=/bin/sh and a rootfs created with debootstrap --foreign, if I launch debootstrap's second state directly it fails installing base-files and base-passwd because dpkg insists on PATH being set
[18:48] <lool> cjwatson: Simply typing export PATH in such a shell is enough to allow installation; do you think this should a) be done in debootstrap b) be allowed in dpkg or c) left to the end-user?
[18:48] <cjwatson> how come PATH isn't set?
[18:48] <lool> cjwatson: The shell sets it, but it's not exported by default
[18:48] <lool> the default value of PATH is sane BTW
[18:48] <cjwatson> even the kernel sets PATH when invoking processes
[18:49] <calc> is all that i need installed via apt-get install linux-generic to go to the proposed kernel?
[18:49] <cjwatson> ah, although not while invoking pid 1
[18:49] <lool> Eh
[18:49] <cjwatson> lool: I think it should be exported by default in the shell
[18:49] <lool> cjwatson: So it's a /bin/sh issue?
[18:49] <lool> I think that makes sense
[18:50] <cjwatson> yes, it sounds like a dash bug to me. It's the sort of thing you don't normally notice
[18:50] <cjwatson> because almost every process gets PATH from its parent, and thus already exported
[18:51]  * lool tries to find out how to fix this in dash
[18:54] <ogra> cjwatson, lool, unlikely to be a dash bug, i know the mojo guys had the same issue (and they explicitly excluded dash in debootstrap)
[18:55] <calc> grr same issue with -11
[18:55] <lool> It's unlikely to be a dash bug but they excluded dash?
[18:55]  * calc kicks 8.10 kernel :-\
[18:56] <ogra> lool, they had the same issue even dash wasnt installed in the target
[18:57] <ogra> lool, so it's either dash and bash or something lower level
[18:58] <ogra> lool, http://www.handhelds.org/hypermail/mojo/0/0011.html
[18:59] <ogra> > export PATH=/bin:/sbin:/usr/bin:/usr/sbin #VERY IMPORTANT otherwise dpkg
[18:59] <ogra> > fails.
[18:59] <ogra> and they run sudo debootstrap --verbose --arch arm --foreign --exclude=dash
[19:00] <lool> Hmm doesn't seem too hard to fix fortunately
[19:02] <calc> i keep getting wlan0: link timed out in the daemon.log
[19:02] <calc> and it never connects to my AP
[19:03] <ogra> remove the tinfoil wrap :)
[19:04] <calc> it worked fine until 8.10 started acting up yesterday then it was fine with 9.04 but 9.04 had issues with xorg
[19:04] <calc> hmm maybe i can carefully install the 9.04 kernel
[19:04] <calc> any danger in using it?
[19:04]  * ScottK knows at least one person who's done that.
[19:04]  * ScottK waves to milli.
[19:04]  * milli looks up ...
[19:05] <ScottK> Aren't you running Intrepid with 2.6.28?
[19:05] <calc> milli: did jaunty kernel help you?
[19:05] <milli> I'm running 2.6.28.4 linux-image with Intrepid...  only real trick is you have to bring over the source of glibc and recompile and install
[19:06] <calc> eh?
[19:06] <calc> you have to recompile glibc?
[19:06] <lool> Keybuk: I see that dash mentions Vcs-Git: http://smarden.org/git/dash.git/; couldn't find an Ubuntu branch in there though; should I strip it?
[19:06] <milli> Jaunty kernel fixed all my network file system issues...  I had been having problems since 2.6.22
[19:06] <lool> or s/Vcs-Git/Original-&/
[19:07] <milli> glibc and the kernel are pretty tightly intertwined... unfortunately.  It's not very hard tho
[19:07] <Keybuk> lool: dunno, I tend to leave those alone
[19:07] <Keybuk> XSBC-Original-* isn't it?
[19:07] <lool> XS- for sure, don't think we need B and C
[19:07] <savvas> let
[19:08] <lool> Keybuk: Problem with leaving them is when people use debcheckout or apt-get source
[19:08] <savvas> *let's hope they fix the problems with atheros wireless cards as well :P
[19:08] <lool> The latter will warn and the former will do the wrong thing
[19:08] <Keybuk> lool: I guess
[19:09] <Keybuk> shouldn't there be an update-maintainer a like that sorts this out?
[19:09] <Keybuk> indeed, shouldn't update-maintainer do it? :p
[19:09] <milli> calc: do you need sepcific instructions on how to do it?
[19:09] <lool> It should, I even thought of fixing that script, but it slipped my mind as I don't use it
[19:10] <milli> specific even
[19:10] <calc> milli: no, hmm it seemed to work here without needing a glibc recompile, what happens without updating glibc?
[19:10] <calc> and immediate connect without problem on jaunty kernel, yipee
[19:10] <milli> you may get random crashes or hangs is all  ;-)
[19:10] <calc> milli: sounds like 8.10 already to me ;-)
[19:11] <LaserJock> Keybuk: how would update-maintainer be able to do it in any automated way?
[19:11] <milli> I've never tried backporting a more recent kernel without re-compiling glibc
[19:11] <LaserJock> Ubuntu bzr branches are sort of spread around
[19:11] <Keybuk> LaserJock: if it's not bzr, on /ubuntu/ and on lp - move it out of the way ;)
[19:11] <milli> but it may be "good enough" w.r.t. changes between 2.6.27 and 2.6.28 that you'll be fine.
[19:12] <calc> milli: i used to run dev kernels all the time without doing glibc backports (back in 2.5 timeframe)
[19:12] <pochu> bryce, tjaalton: hi folks, could you have a quick look at bug 287542 and tell me if it's an application bug or an X one?
[19:12] <LaserJock> Keybuk: but we don't yet have a complete standard for VCS, unlike for the maintainer field
[19:12] <bryce> pochu: ok
[19:12] <Keybuk> LaserJock: we do
[19:13] <Keybuk> Bzr, Launchpad-hosted, owned by ~ubuntu-core-dev for main, ~ubuntu-dev for universe, against the package name and /ubuntu as the branch name
[19:13] <LaserJock> I don't think that's actually right though
[19:13] <Keybuk> lp:~ubuntu{-core,}-dev/$PACKGE/ubuntu
[19:13] <bryce> pochu: application error
[19:13] <LaserJock> it's mostly right
[19:13] <pochu> bryce: ok, thank you!
[19:13] <bryce> pochu: like it says in the error message, "This probably reflects a bug in the program."
[19:13] <Keybuk> LaserJock: that's the standard, and what we're pushing towards
[19:13] <milli> calc: I just like machines where uptime shows 3 digit figures and the word "days"...  ;-)
[19:13] <pochu> bryce: ah, right
[19:14] <pochu> bryce: unfortunately it seems to be in a library :/
[19:14] <LaserJock> Keybuk: but I believe KDE for instance, doesn't use ~ubuntu{-core,}-dev
[19:14] <pochu> libgtk-vnc
[19:14] <Keybuk> milli: security experts like them too, they're good places to break into for the latest virus
[19:14] <Keybuk> LaserJock: that's wrong then
[19:14] <calc> milli: heh well i generally reinstall every 6 months anyway so i don't get uptime that long
[19:14] <LaserJock> Keybuk: why?
[19:14] <Keybuk> LaserJock: because it means a member of ubuntu-core-dev cannot change kde packages
[19:14] <LaserJock> right
[19:14] <Keybuk> which is wrong
[19:14] <Keybuk> we don't have maintainership in Ubuntu in that way
[19:14] <LaserJock> but it means that none ubuntu-dev can change packages
[19:15] <Keybuk> (though it's worth noting that with archive reorg, the team part gets wider)
[19:15] <Keybuk>  so I wouldn't check the team bit either for nwo
[19:15] <LaserJock> Edubuntu will likely do the same thing
[19:15] <LaserJock> I think Xubuntu does the same
[19:16] <bryce> pochu: probably the lib is making an X call that the driver doesn't actually support
[19:16] <milli> Keybuk: good point... although kernel security issues still aren't all that frequent
[19:16] <Keybuk> LaserJock: it's certainly true that they don't use git though ;)
[19:16] <milli> I don't count ssh upgrades or apache upgrades in machine uptime ;-)
[19:16] <jdstrand> milli: they are nearly monthly :P
[19:16] <Keybuk> so we could move non-Vcs-Bzr-on-lp out of the way <g>
[19:17] <Keybuk> milli: by my count, there's been roughly one kernel security update a month over the past year
[19:17] <milli> jdong: I guess I need to pay more attention then
[19:18] <milli> jdstrand: oops
[19:18]  * milli raises eyebrows, wonders what mailing he's not on and should be on
[19:18] <Keybuk> milli: ubuntu-security-announce
[19:18] <jdstrand> ubuntu-security-announce
[19:18] <milli> ty
[19:19] <Keybuk> also ubuntu-uptime-is-not-a-dicksize-measurement ;)
[19:20] <RainCT> lol
[19:20] <directhex> woo, mono session in classroom soon :o
[19:21] <milli> how's this for scary...
[19:21] <milli>  12:20:45 up 281 days, 23:18,  1 user,  load average: 0.40, 0.14, 0.10
[19:21] <RainCT> arr those mono transitions are starting to become annoying
[19:21]  * milli is a slacker
[19:22] <directhex> RainCT, the gnome# one was an unexpected problem
[19:24] <calc> milli: when i installed the headers it automatically upgraded libc6 as well
[19:26] <milli> calc: you should be good then
[19:27] <milli> I just wanted to make sure to avoid pulling in other packages from jaunty...  I pulled in 2.6.28 back in December
[19:48] <cjwatson> ogra: more likely to be a bug common to both dash and bash
[19:48] <lool> Yeah it is
[19:48] <ogra> probably ... just wanted to point out that they have it in bash
[19:48] <lool> I just fixed it for dash
[19:48] <lool> It took me a while because for some reason init=/bin/sh spawns a bash despite /bin/sh being a symling to dash
[19:48] <ogra> heh, my build-arm-rootfs script shrinks every day by a line :)
[19:49] <ogra> yesterday i dropped mknod, today i can drop the PATH setting :)
[19:51] <lool> cjwatson: http://paste.ubuntu.com/108351/ I'm going to reboot before uploading though
[19:51] <cjwatson> lool: makes sense
[19:52] <lool> Now if I could understand why init=/bin/sh launches bash...
[19:53] <ogra> lool, filesystem issue ?
[19:53] <ogra> what do you use in your image ?
[19:53] <lool> ogra: ext3
[19:53] <ogra> hmm, not then ...
[19:53] <lool> ogra: Even running the system if I ls -l /bin/sh I see dash
[19:53] <ogra> indeed
[19:55] <lool> After the debootstrap it now runs dash instead of bash
[19:56] <ogra> is e2fstools installed in the first or second run ?
[19:56] <ogra> the only thing i can imagine is that it has to do with the filesystem ...
[19:58] <cjwatson> e2fsprogs is Priority: required and thus installed in the first stage. (It has nothing to do with how the kernel interprets filesystems anyway ...)
[19:59] <lool> Perhaps I misread /bin/sh -> /bin/dash which was really /bin/bash; /me redoes a bootstrap
[20:00] <lool> Right
[20:00] <lool> lrwxrwxrwx 1 root root 4 2009-01-22 21:00 rootfs2/bin/sh -> bash
[20:00] <ogra> ah
[20:00] <lool> I probably wanted to read dash but it was bash
[20:00] <lool> So when you run second stage it's in bash
[20:01] <cjwatson> oh, because of the complex way the symlink is handled
[20:01] <cjwatson> nothing much to worry about I think
[20:03] <lool> cjwatson: Yeah I was just confused and wanted to find out, but I found out that it was just me :)
[20:03] <directhex> mono session now on! gogogo :p
[20:04] <superm1> Keybuk, what's your opinion about applications calling 'udevadm trigger'?  I'm looking over an old bug (bug 262974), and remembering that one of the cases that causes it is because dkms calls 'udevadm trigger' to replay devices in case one of  the devices is now supported by a newly built kernel module
[20:04] <apw> jerone, ping
[20:06] <Keybuk> superm1: NEVER EVER DO IT
[20:08] <Keybuk> in fact, you could be responsible for a major upgrade bug for jaunty
[20:10] <Keybuk> minor effects of trigger:
[20:10] <Keybuk>  - network manager showing multiple copies of the devices
[20:11] <Keybuk> major effects of trigger:
[20:11] <Keybuk>  - mounted disk drives being "corrupted" until a reboot
[20:11] <Keybuk> upgrade issues:
[20:11] <Keybuk>  - if you trigger during an intrepid->jaunty upgrade, your entire /dev will become root:root/0660
[20:11] <ScottK> Is any of this in Intrepid?
[20:12] <Keybuk> yes
[20:12] <Keybuk> you can demonstrate this quite effectively
[20:12] <Keybuk> if you have more then just / mounted
[20:12]  * ScottK is having something very much like "mounted disk drives being "corrupted" until a reboot" recently
[20:12] <Keybuk> run udevadm trigger a few times and peek in one of your mounted disks
[20:12] <Keybuk> like /usr /var or something
[20:12] <Keybuk> at some point, it'll declare data error or something
[20:13] <Keybuk> superm1: *please* get rid of that udevadm trigger asap
[20:13] <Keybuk> superm1: I would even declare this an SRU candidate
[20:13] <Keybuk> you can simply modprobe the module, you know? :)
[20:14] <cjwatson> so what about the installer's uses of udevadm trigger to make sure that the device is actually available before continuing? I still have never seen a good replacement for that
[20:14] <Keybuk> cjwatson: e.g.?
[20:14]  * ScottK admits to being in over his head and hopes for some fixoring.
[20:14] <cjwatson> partitioning: wait for devices to be available before we try to mount them
[20:14] <cjwatson> or mkfs them
[20:14] <Keybuk> how does udevadm trigger help you there?
[20:14] <Keybuk> trigger doesn't wait for anything
[20:14] <cjwatson> trigger+settle
[20:14] <Keybuk> you mean settle, don't you? :)
[20:15] <Keybuk> well, the settle is quite correct in the installer case
[20:15] <Keybuk> the trigger isn't
[20:15] <Keybuk> but the installer is cut down enough that the trigger probably doesn't do any damage - just slows things up
[20:15] <cjwatson> so if I take that trigger out and it breaks, you'll help me debug it? :-)
[20:15] <cjwatson> in the context of ubiquity, the trigger might well run with mounted filesystems
[20:15] <Keybuk> always ;)
[20:16] <Keybuk> yeah, trigger on mounted filesystems is bad
[20:16] <cjwatson> ok, changed it in my local tree and will test later
[20:16] <Keybuk> we run a whole bunch of things on the filesystem, and if the filesystem changes under it, we can end up unmounting it or declaring it corrupt ;)
[20:16] <cjwatson> how does udev manage to declare a filesystem corrupt in such a way that the kernel notices?
[20:16] <Keybuk> not udev, devmapper
[20:16] <cjwatson> interesting
[20:16] <Keybuk> it does something inside the kernel
[20:16] <Keybuk> I didn't debug much further admittedly
[20:17] <Keybuk> trigger is a one-time only boot-time tool
[20:17] <Keybuk> if you really must hammer your system
[20:17] <Keybuk> udevadm trigger --action=change
[20:17] <Keybuk> is safe
[20:18] <Keybuk> the default (action=add) is _not_ safe, you're adding duplicate devices for everything
[20:18] <cjwatson> are uevents guaranteed to be in udev's queue after modprobe?
[20:18] <ogra> and settle will now work without explicitly triggering ?
[20:19] <Keybuk> ogra: settle always works
[20:19] <ogra> i remember you had to call trigger first before
[20:19] <cjwatson> I mean, can the following happen? modprobe; udevadm settle "nothing to do"; "oh hey, an event arrived"
[20:19] <Keybuk> ogra: you've never had to call trigger first
[20:19] <ogra> oh
[20:19] <Keybuk> cjwatson: at least one uevent is guaranteed to be in udev's queue
[20:19] <Keybuk> but it's probably not the one you're after
[20:19] <cjwatson> you know, I'm going to go and search logs at some point, because I swear you advised me to use trigger; settle originally
[20:19] <Keybuk> modprobe <entire subsytem>; udevadm settle
[20:19] <Keybuk> won't usually wait for devices on that subsystem
[20:19] <cjwatson> so we *do* need udevadm trigger --action=change to make sure?
[20:20] <Keybuk> cjwatson: no, you shouldn't need trigger at all, ever
[20:20] <Keybuk> if udev is running, trigger is only telling it what it already knows
[20:20] <cjwatson> let us say that we want to wait for devices on that subsystem
[20:20] <cjwatson> for example, d-i's hardware detection loads subsystems and then wants to check whether you actually have any disks
[20:20] <cjwatson> (so it can produce a useful error message rather than a blank partitioner)
[20:20] <Keybuk> how many devices are you waiting for?
[20:21] <cjwatson> completion; I'd like the kernel to be finished probing the bug
[20:21] <cjwatson> bus
[20:21] <Keybuk> err
[20:21] <Keybuk> which bus are you thinking of? :)
[20:21] <cjwatson> whatever it's currently looking at
[20:21] <Keybuk> there's no such concept for most of them
[20:22] <cjwatson> I suppose this is why the initramfs has that crappy sleep 300
[20:22] <Keybuk> "probing" USB for example is just raising a voltage on the cable
[20:22] <Keybuk> at some point, whatever devices are connected will draw some of that power and start asking for some more
[20:22] <cjwatson> ok
[20:22] <Keybuk> and at that point, you go "oh look, a device"
[20:23] <Keybuk> there's no "and all devices that are connected are up" type event
[20:23] <cjwatson> I'll probably have to rewrite disk-detect's check at some point
[20:23] <cjwatson> can I just double-check the partitioning case with you? that's very important
[20:23] <kees> (any reason eSATA drives don't auto-mount?)
[20:23] <cjwatson> we already have the disk device, by definition
[20:23] <Keybuk> sure
[20:23] <cjwatson> we do whatever the block device ioctl is to get the kernel to reload the partition table
[20:23] <Keybuk> yup
[20:24] <Keybuk> and the kernel will change the partition table
[20:24] <Keybuk> (or fail the ioctl)
[20:24] <cjwatson> when that ioctl returns, will there be a uevent in the queue for the new partition devices?
[20:24] <Keybuk> that reorganises /sys for that device
[20:24] <Keybuk> and issues "remove", "add" and "change" uevents to udev for the partitions
[20:24] <Keybuk> which udev grabs, and runs things like vol_id on
[20:24] <cjwatson> right - I just need to know whether those uevents are issued (over netlink?) before the ioctl returns
[20:24] <cjwatson> so that the settle is correct as a sequence point
[20:25] <Keybuk> one moment
[20:25] <lool> Riddell: I see you have split libwmf in two; did you seed it?
[20:25] <Keybuk> BLKRRPART has a BKL around it, so there's a reasonable chance
[20:25] <lool> Riddell: Cause otherwise we'll lose wmf support in Gtk+
[20:25] <cjwatson> (maybe you can show me at the sprint how to check this; I have no problem grovelling around in the kernel but don't know the driver core well)
[20:26] <cjwatson> Keybuk: I think we actually use BLKPG_ADD_PARTITION
[20:26] <lool> Riddell: Don't know how widespread it is, but it's something which refrained me from doing the split :)
[20:26] <cjwatson> (rather, remove* add*)
[20:27] <Keybuk> really? fdisk doesn't
[20:27] <cjwatson> parted does
[20:27] <cjwatson> potentially also DM_DEVICE_CREATE for devmapper devices, whatever that turns into in ioctl terms
[20:27] <Keybuk> ok
[20:27] <Keybuk> well
[20:28] <Keybuk> BLKRRPART, BLKPG_ADD_PARTITION and BLKPG_DEL_PARTITION are all deliberately safe
[20:28] <Keybuk> the uevent will be in the queue and the /sys nodes updated when the ioctl returns
[20:28] <Keybuk> DM_* are also safe
[20:28] <cjwatson> ok, excellent
[20:29] <Keybuk> you may obviously want to use udevadm settle to make sure
[20:29] <Keybuk> a) udev has taken the event and made the device
[20:29] <Keybuk> b) and isn't running vol_id or anything on it right now ;)
[20:29] <cjwatson> indeed
[20:29] <cjwatson> BTW, is this a change I should be pushing to Debian, if you know the udev/kernel differences well enough to say?
[20:29] <Keybuk> yes
[20:30] <Keybuk> this should be completely compatible ;)
[20:30] <cjwatson> I'll have to do some detailed checks of update-dev uses
[20:30] <Keybuk> there were some fixes in "recent" kernel history
[20:30] <Keybuk> (around the .22 mark)
[20:30] <cjwatson> but at least I only need to change one place
[20:30] <cjwatson> Debian's on 2.6.26 now
[20:31] <Keybuk> but those fixes look like they were limited to making sure that the partitions of a disk were also available before the disk event
[20:31] <Keybuk> you actually get the uevents in the order
[20:31] <Keybuk>  sda1, sda2, sda3, sda
[20:31] <Keybuk> which seems backwards, but is in practice exactly what you want
[20:31] <Keybuk> (so you can get the disk event and check for partitions)
[20:32] <Keybuk> with most modules
[20:33] <Keybuk> when the modprobe returns, the core objects of the module should be available in /sys and uevents queued
[20:33] <lool> cjwatson: And that'd be the bash patch http://paste.ubuntu.com/108362/
[20:33] <Keybuk> if the module claims a device, that should have been updated
[20:33] <Keybuk> (but it may be waiting on firmware before things like class devices show up)
[20:33] <Keybuk> if the module is a subsystem, /sys/bus/nnn should exist, but devices may not
[20:33] <cjwatson> lool: it is suspicious that it's #if 0-ed out in bash
[20:34] <cjwatson> lool: it might be worth chasing down why
[20:34] <Keybuk> \o/
[20:34] <Keybuk> from mdz's upgrade log
[20:34] <Keybuk> Examining /etc/kernel/postinst.d.
[20:34] <Keybuk> run-parts: executing /etc/kernel/postinst.d/dkms
[20:34] <Keybuk>  * Running DKMS auto installation service for kernel 2.6.28-4-generic       [80G
[20:34] <Keybuk>  *  nvidia ()...       [80G nvidia (): AUTOINSTALL not set in its dkms.conf.
[20:34] <Keybuk> ...
[20:35] <Keybuk> superm1: I'm so beating you into a pulp next time I see you ;-)
[20:36] <lool> cjwatson: I see the change mentionned in CHANGES, but no rationale:
[20:36] <lool> w.  Bash no longer auto-exports HOME, PATH, SHELL, or TERM, even though it gives them default values if they don't appear in the initial environment.
[20:36] <lool> (bash-2.05a-rc1)
[20:37] <cjwatson> lool: Chet Ramey's usually pretty responsive if you mail him, I think
[20:37] <lool> cjwatson: thanks for the hint
[20:44] <cjwatson> ScottK: it looks very much as if you simply didn't tell netcfg your hostname at installation time, but only told postfix
[20:45] <cjwatson> the only match for "controlledmail.com" in questions.dat is for postfix
[20:52] <superm1> Keybuk, OK i'll change that behavior.  I'll do an SRU for just that change too in Intrepid.
[20:53] <Keybuk> superm1: bug #320200 btw
[20:53] <superm1> Keybuk, yeah just saw it in bug mail.  i'm doing another DKMS release with a handful of other stuff, and will fit it in there
[20:54] <superm1> Keybuk, where  is mdz's upgrade log?  I have a suspicion what happened there but would like to verify
[20:54] <kees> whoa.  I'd never seen this C convention before:   argv[0] ?: "unknown"     I thought you always had to have stuff between ? and :
[20:54] <Keybuk> kees: gcc extension
[20:54] <kees> Keybuk: ah-ha.
[20:56] <Keybuk> kees:
[20:56] <Keybuk> The middle operand in a conditional expression may be omitted.  Then if
[20:56] <Keybuk> the first operand is nonzero, its value is the value of the conditional
[20:56] <Keybuk> expression.
[20:56] <Keybuk> superm1: bug #317944
[20:56] <superm1> Keybuk, okay thanks
[21:08] <TheMuso> tjaalton: hrm I'll have to update my jaunty install and try again. Failing that, I'll do a fresh install and try again as well.
[21:10] <maxb> The jaunty-added "Recommends: gnome-dbg" in bug-buddy means that a lot of -dbg packages get installed on upgrade. More interestingly, I've uninstalled evolution - but this Recommends chain pulls it back in on upgrade. Are these things that I should be reporting, and if so where, since they are general dependency mesh issues rather than relating to a particular package
[21:15] <Keybuk> cjwatson: kernelwise, I guess I'm starting to understand kernel source fairly well these days ;)
[21:18] <calc> bbl, seagate finally released a firmware for the 7200.11 that won't brick it
[21:18] <calc> time to update my drive before it dies
[21:19] <directhex> good luck
[21:21] <mar77i> maybe somebody can give me a hint here: http://pastebin.com/m54d87294
[21:21] <ScottK> cjwatson: I'm pretty sure if I didn't tell it the domain, I didn't get asked.  I have a vague recollection of it working with some combinations of network/no-network, dhcp/no-dhcp, and rDNS or no rDNS, but not which.
[21:29] <tjaalton> TheMuso: ok, thanks
[21:30] <cjwatson> ScottK: I believe you're meant to type in the FQDN at the hostname prompt
[21:30] <cjwatson> maybe it isn't as clear as it might be
[21:40] <calc> my drive now won't die well immediately anyway :)
[21:41] <directhex> you hope
[21:41]  * directhex hugs his samsung
[21:42] <calc> directhex: there are ways to revive them if they do die but it involves hooking up to the drives serial port (not sata port)
[21:42] <primes2h> pitti: Hello.
[21:43] <primes2h> pitti: I have the correct debdiff
[21:43] <directhex> calc, yay for 38k baud!
[21:43] <primes2h> Could you have a look please? http://pastebin.ubuntu.com/108387/
[21:43] <calc> directhex: heh, yea you just have to type a few commands into the drive to reset it
[21:44] <TheMuso> Drives have a serial port? THis is new to me.
[21:44]  * TheMuso doesn't think he's see it.
[21:44] <calc> TheMuso: there are a few pins next to the sata port its rx/tx for a serial connection at least on seagate drives
[21:44] <TheMuso> ah ok.
[21:45] <calc> TheMuso: 'undocumented' pins ;-)
[21:45] <TheMuso> ah
[21:47] <calc> TheMuso: you can do some interesting things in there if you find the manual, including wiping the smart sector
[21:47] <TheMuso> ouch
[22:01] <calc> er what happened to gweather in jaunty, you can't select which weather station to use in a city anymore
[22:01] <calc> is this considered 'improvement'?
[22:01] <slangasek> haha
[22:02] <slangasek> gweather, a comedy of errors in three acts
[22:02] <calc> a place like houston is ~ 1000 sq.mi. and only having 'Houston' as an option isn't particularly useful
[23:10] <ScottK> cjwatson: I'll try and carve out some time to dig back into it.
[23:24] <dtchen> bryce: does 315971 persist in current jaunty?
[23:25]  * bryce looks
[23:26] <bryce> dtchen: I'll need to update to latest first; I'll do that and report findings on that bug
[23:28] <dtchen> bryce: thanks