[04:42] <RenatoSilva> are you ubuntu developers???
[04:42] <Hobbsee> RenatoSilva: no.  we just sit here and pretend.  duh
[04:42] <Burgundavia> some of us are, some of us aren't
[04:42] <Burgundavia> Hobbsee: ;)
[04:42] <Hobbsee> hiya Burgundavia, how's it going?
[04:43] <Burgundavia> back from Texas and sick
[04:43] <Hobbsee> awww
[04:43] <RenatoSilva> and sapdfl, where does he is?
[04:43] <Burgundavia> umm?
[04:43] <Hobbsee> RenatoSilva: what did you want?
[04:44] <RenatoSilva> Hobbsee: do I incomodate you, because I'm not ubuntu developer, what kind of talk may I have here??
[04:45] <Burgundavia> RenatoSilva: yes, you can talk here, as long it is on topic
[04:45] <RenatoSilva> i'm bad in elglish, sorry
[04:45] <Burgundavia> if you have a bug report, please file it on Launchpad
[04:45] <Burgundavia> a suggestions for a new feature is a spec
[04:45] <Hobbsee> ah.  didnt know that word.
[04:45] <bhale> you might get more help in #ubuntu-br
[04:46] <RenatoSilva> to "incomodate" is to make something that make someone unconfortable, something non-suitable 
[04:46] <RenatoSilva> i dunno the correct verb
[04:46] <RenatoSilva> Burgundavia: about what can i talk?
[04:46] <Burgundavia> see the topic
[04:46] <Hobbsee> RenatoSilva: see the /topic
[04:47] <RenatoSilva> Hobbsee: it's unclear
[04:47] <Hobbsee> RenatoSilva: right, what did you want to talk about?
[04:47] <Hobbsee> this channel is for the development of ubuntu, not support
[04:47] <RenatoSilva> Hobbsee: let's test if my talk is or not on topic
[04:48] <RenatoSilva> Hobbsee: i want to talk about winmodem support (but don't give me wiki pages, launchpad etc. i'm not a dummy user!!!!!)
[04:48] <RenatoSilva> Hobbsee: may I?
[04:50] <bhale> the topic is very clear on this not being for support
[04:50] <_ion> This discussion has already been 30 lines. :-)
[04:50] <jdong> _ion: the discussion about discussing?
[04:50] <_ion> Yeah, that.
[04:51] <_ion> Metadiscussion
[04:51] <bhale> if you want to develop more support for winmodems you want to specify it in wiki/launchpad
[04:51] <jdong> premetadiscussional planning
[04:51] <bhale> no one called you a dummy
[04:51] <Hobbsee> RenatoSilva: people here are concentrating on releasing feisty.  winmodem support will not change for feisty, at this point.  i suspect you're out of luck, at least for the next couple of weeks.  what you really want to do is see the ubuntu-devel mailing list, as the dialogue goes on there
[04:51] <RenatoSilva> _ion: metadiscussion? rsss!!!
[04:52] <RenatoSilva> Hobbsee: ok, but can you let me make about 2 paragraph-comment about it?
[04:53] <Hobbsee> if you like, but it probably wont do much, seeing as the devs you're looking for arent ehre, and everyone's busy working on feisty, bug fixing...
[04:54] <_ion> One could find it humorous that his screen is 75% full of discussion pretty much about can i please make a two line comment about something. :-)
[04:54] <RenatoSilva> Hobbsee: Jesus! Just let me say, I don't want support, neither to relate a bug
[04:54] <Hobbsee> RenatoSilva: i realise that...
[04:55] <RenatoSilva> _ion: ok, so let's go!!! I'll tell you right before you kick me off :D
[04:55] <bhale> please don't yell.
[04:55] <jdong> go ahead and say what you want to say....
[04:56] <RenatoSilva> Fortunately most of I want to say is in this page I've found right today:
[04:56] <RenatoSilva> https://wiki.ubuntu.com/OutoftheboxWinmodem
[04:56] <RenatoSilva> I dunno if you fully know that content
[04:57] <RenatoSilva> Additionaly I want to say that
[04:58] <RenatoSilva> Here in Brazil, which on the countrary of most of you can think, it's not that whom Buenos Aires is capital...
[04:58] <RenatoSilva> Well, here...
[04:58] <RenatoSilva> it's a very important issue, considering the resolution of bug #1
[04:58] <ubotu> Malone bug 1 in jl "Microsoft has a majority market share" [Critical,Confirmed]  https://launchpad.net/bugs/1
[04:59] <Hobbsee> RenatoSilva: winmodem support so far has not been done, not because of lack of interest, but lack of active developers.  if you're interested in coding it, or finding a team of people to code it, then that would be great.
[04:59] <RenatoSilva> there's here a GREAT demand for this support, and it will certaintly spread even more the use of ubuntu around our *million* of windows users
[05:00] <Hobbsee> RenatoSilva: but waving the magic wand and hoping that it'll be done for you doesnt always work
[05:00] <Hobbsee> seeing as there are limited resources, and lots of worthy projects that the ubuntu developers want to work on
[05:00] <RenatoSilva> Hobbsee: this is what i wanted to say
[05:00] <Hobbsee> RenatoSilva: great
[05:01] <RenatoSilva> Hobbsee: I want to know I what I say, including Brazil's scenario, is something new to you
[05:02] <jdong> RenatoSilva: I think most of us are aware that many many countries still run primarily dial-up
[05:02] <RenatoSilva> Hobbsee: if it's new, only to make you know this, so that you can use it as strategic information, is enough to me
[05:03] <Hobbsee> RenatoSilva: it's not new.  like i say, it's not a lack of interest in the project - it's a lack of developers.  seeing as most of them arent paid, we cant force them to do particular stuff, unless they're interested.
[05:03] <RenatoSilva> jdong: what do you mean by aware? volunteerly aware?
[05:03] <RenatoSilva> Hobbsee: great!!
[05:03] <jdong> RenatoSilva: aware, as in most of us already knew what you claim. there is nothing earth-shattering
[05:04] <RenatoSilva> Hobbsee: thank you for useful information, i didn't noticed that!
[05:04] <jdong> RenatoSilva: winmodem support is indeed important but there do not appear to be a massive rush of developers interested in getting it coded
[05:04] <Hobbsee> wow, there's even a bounty for doing it, it looks like
[05:04] <jdong> and work is indeed going into it....
[05:04] <jdong> https://wiki.ubuntu.com/MainInclusionReportSlModem
[05:04] <jdong> there are MIR's filed for SmartLink modem support
[05:04] <RenatoSilva> jdong: sorry for the bad English
[05:05] <jdong> no sweat :)
[05:05] <RenatoSilva> jdong: so, are you very interested on it, but limited, is that?
[05:05] <RenatoSilva> Hobbsee: what about the page I've passed?
[05:06] <Hobbsee> RenatoSilva: looks good. same answer as above, though
[05:06] <jdong> RenatoSilva: I would be interested in doing it, if I have (1) the time (2) A variety of softmodems to test on
[05:06] <RenatoSilva> Hobbsee: it's related to a blueprint, it's a official concern, but the limitation is missing of developers? right?
[05:07] <ajmitch> jdong: how about hardware documentation?
[05:07] <Hobbsee> RenatoSilva: pretty much
[05:07] <jdong> ajmitch: well there are already several drivers out there that are just not preconfigured by default :-/
[05:07] <RenatoSilva> Hobbsee: thank you very much!!!!
[05:08] <jdong> ajmitch: I think Ubuntu _can_ do better integrating currently available softmodem drivers....
[05:08] <jdong> but yeah, it is work
[05:08] <jdong> and going to be full of hardware black magic
[05:08] <RenatoSilva> Hobbsee: so if you want, think in Brazil when considering the importance assigned to this "bug", maybe becoming more mainstream makes more developers to be interested on it
[05:09] <Hobbsee> RenatoSilva: maybe, yes.
[05:09] <RenatoSilva> Hobbsee: I'm very sad of not being able to help, I thought it was missing of attention with us, but missing is of programmers, and I did not knew taht
[05:10] <jdong> most missing functionality is due to a lack of infinite developer resources :)
[05:10] <RenatoSilva> Hobbsee: i think I could make some work onto Martian driver, because I've installed it on my PC and am using it right now
[05:11] <RenatoSilva> jdong: I did not know
[05:12] <RenatoSilva> Hobbsee: I've wrote a Portuguese tutorial, and I think I could build a .deb package for an installation out of the box for Lucent/Agere modems, but the problem is exactly time!!!!
[05:13] <_ion> and the amount of exclamation points.
[05:13] <RenatoSilva> Hobbsee: unfortunately, my contributtions can be only spporadic, little-time tasks, such as this tutorial I've wrote
[05:13] <_ion> They probably should go to linux-image or linux-restricted-modules.
[05:13] <jdong> yeah, there are a lot of time issues involved. Time it takes to put together a high-quality support for hardware ina a distro, and also the time and dedication it takes for years after to make sure it is kept maintained
[05:13] <RenatoSilva> _ion: sorry!!!!!!!!!!!!!!!
[05:13] <RenatoSilva> _ion: :D
[05:13] <jdong> it's little good if it's just put in there and the author disappears
[05:14] <RenatoSilva> jdong: put what? code or docs?
[05:15] <RenatoSilva> jdong: should exists 'maintainers'
[05:15] <jdong> RenatoSilva: code and docs....
[05:15] <jdong> but the question is _who_ are these maintainers?
[05:15] <jdong> they do not magically appear out of nowhere
[05:16] <jdong> it's a major responsibility to undertake
[05:18] <RenatoSilva> jdong: it should exist maintaners separated specifically to maintainin stuff
[05:19] <RenatoSilva> jdong: good code dispends the original programmers!!!!
[05:19] <RenatoSilva> but...
[05:19] <RenatoSilva> next page
[05:19] <RenatoSilva> do you know MArtian driver??
[05:20] <jdong> You mean the Lucent/Agere Mars chipset? (1648)
[05:20] <RenatoSilva> jdong: no, the driver for it
[05:21] <RenatoSilva> jdong: i think it's easy to package it as a .deb and put it into hardware detection in the install process
[05:21] <jdong> ltmodem, right?
[05:22] <jdong> linux-restricted-modules-2.6.20-12-386: lib/linux-restricted-modules/2.6.20-12-386/ltmodem/ltmodem.mod.o
[05:22] <jdong> it seems to be in the -386 kernel
[05:22] <RenatoSilva> i forgot, also I'd like to help with gnome-ppp that is still too simple
[05:22] <jdong> but not in the -generic kernel
[05:22] <jdong> I have no idea why...
[05:22] <RenatoSilva> jdong: it's an alternative driver
[05:22] <ajmitch> jdong: binary-only driver that can't handle SMP, iirc
[05:23] <jdong> ajmitch: ah, ok, didn't know that :)
[05:23] <ajmitch> there's at least 1 or 2 like that
[05:23] <RenatoSilva> jdong: is that a thing to verify?
[05:23] <jdong> RenatoSilva: no, I am not familiar with that driver...
[05:23] <jdong> I have seen ltmodem before
[05:23] <RenatoSilva> jdong: a moment
[05:24] <desrt> what is a "validation bug"?
[05:24] <jdong> "It is known that there sometimes are behaviours such as the one which
[05:24] <jdong> you observe with ltmodem and smp. Therefore the logical step is to keep
[05:24] <jdong> ltmodem and temporarily use the single p (UP) kernel, just to make sure if
[05:24] <jdong> the problem is the ltmodem-smp conflict."
[05:24] <jdong> but that is dated information
[05:26] <RenatoSilva> jdong: i don't undertand nothing of what you just said :D
[05:26] <RenatoSilva> jdong: http://martian.barrelsoutofbond.org/
[05:26] <RenatoSilva> jdong: del.icio.us it
[05:27] <jdong> (alpha) Testing. Volunteers are invited. There's no official release yet.
[05:27] <jdong> it seems to be an alpha driver
[05:27] <RenatoSilva> jdong: i think it's easy to take martian and embed it in the instalaltion
[05:28] <jdong> RenatoSilva: if it is shown that martian is more stable or reliable than the existing ltmodem driver, then yes, it could very well go into the kernel
[05:28] <RenatoSilva> jdong: the martian? sure, but it is working here, except of some strange screws from the device :D
[05:29] <jdong> that doesn't sound like a great success report
[05:29] <RenatoSilva> jdong: so it was useful to tell you about it? will you keep it in mind?
[05:29] <jdong> for something you want included as a part of the Ubuntu kernel
[05:29] <RenatoSilva> jdong: or it's another place i have to go??
[05:29] <jdong> I have no decision making power around here
[05:29] <jdong> you should try the mailing list as a way to get more developers involved
[05:30] <jdong> and if you can state your findings with the martian driver on the wiki page you linked to, that will help too
[05:30] <RenatoSilva> jdong: about the screws: was a joking, sometimes when connecting there's strange sounds, but only sometimes, my PC never had frozen because of such driver for example...
[05:31] <jdong> still... this is a driver... that inserts itself into the kernel
[05:31] <jdong> it needs to be of a certain quality level before it's wise to ship it by default
[05:32] <RenatoSilva> jdong: anyway the quality may be verified by inspecting the code
[05:33] <RenatoSilva> jdong: i don't remeber it I've tried ltmodem, I think I had trouble with it, so that I've tried martian
[05:33] <jdong> which takes developer resources
[05:33] <RenatoSilva> jdong: :D
[05:33] <jdong> :)
[05:34] <jdong> but yes, RenatoSilva, we aren't going to completely forget about winmodem support...
[05:34] <RenatoSilva> jdong: a question: what's the difference between ltmodem and sl-modem?
[05:34] <jdong> RenatoSilva: the situation will naturally get better as these better drivers emerge
[05:34] <jdong> RenatoSilva: ltmodem is for the Agere Mars 1648C chipset, while sl-modem is for the SmartLink Intel HDA modems
[05:34] <jdong> different chipsets
[05:35] <jdong> this of course does not solve the problem with the Conexant HDA HSF modems
[05:35] <jdong> by far the most popular modems
[05:35] <jdong> for which no half-open drivers exist.
[05:35] <RenatoSilva> jdong: I hope very much, for all that I've said, that it become true fast
[05:35] <RenatoSilva> jdong: wow, great
[05:36] <RenatoSilva> jdong: btw, I guess I remember why i did not used ltmodem!!!
[05:36] <RenatoSilva> jdong: it's because it's a hard modem driver, right??? or no??
[05:36] <jdong> no
[05:37] <jdong> it is also a driver for the Mars chipset
[05:37] <jdong> martian seems to be a rewrite of it
[05:37] <jdong> it also uses the same ltmodem binary blob
[05:37] <jdong> just a different 'wrapper' around it
[05:37] <RenatoSilva> jdong: i would try it to see if it works, but i don't want to have re-work in case of re-installin martian
[05:37] <RenatoSilva> jdong: does ltmodem is installable by apt?
[05:38] <RenatoSilva> jdong: wow, i 'm not such a low-level programmer
[05:39] <jdong> it is installable by apt, but only on the linux-386 kernel
[05:39] <jdong> if you install and boot the -386 kernel, ltmodem should be enabled automatically
[05:39] <jdong> that is already in Ubuntu :)
[05:40] <RenatoSilva> jdong: if someday it would be possible, I think it would be interesting to connect statistics in Brazil and world-wide about the most-used modems, I use Agere here but i'm not sure if it's the most-used
[05:40] <jdong> I used to be a dial-up modem guru/fanatic....
[05:41] <jdong> I will tell you off the bat the most popular by far are Conexant HSF/HSP's
[05:41] <jdong> today, in the form of Conexant HDA modems
[05:41] <RenatoSilva> jdong: so that's why the network > modem item did not worked when i first installed my Edgy, because I'm in a Core 2 Duo
[05:41] <jdong> second most popular are Agere Mars 1648C
[05:41] <jdong> and then it's SmartLink
[05:41] <jdong> the order there between 2 and 3 may be flipped
[05:42] <RenatoSilva> jdong: also in Brazil?
[05:42] <jdong> I'd expect so
[05:43] <jdong> (the main motivation is that Conexant HDA is dirt cheap)
[05:43] <jdong> it's quite literally connecting the telephone wire to two input leads on the sound card :)
[05:48] <RenatoSilva> jdong: are you a genuine developer of ubuntu right?  so let me make a question
[05:49] <jdong> no, I am actually not a developer
[05:49] <jdong> I actually do, as Hobbsee suggested, hang around and act as one :D
[05:50] <jdong> (I have several other responsibilities in the Ubuntu community that keep me well busy)
[05:50] <RenatoSilva> here in Brazil we have a grear virtual community called GUJ (.com.br) in which forum we discuss about Java technology, and currently by these  days we're talking about the importance of Tests in software (junit.org, unit tests, TDD etc.)
[05:50] <Hobbsee> jdong: and being the master of backports..
[05:50] <Hobbsee> jdong: that counts as a developer
[05:50] <jdong> :)
[05:50] <jdong> ok
[05:51] <RenatoSilva> some were saying that sofwtare without tests are to put in trash
[05:51] <jdong> Hobbsee: I promise I'll get a MOTU badge before the summer is over :D
[05:51] <bhale> you could get one, if you wanted.
[05:51] <jdong> RenatoSilva: a comprehensive yet accurate test suite is indeed a great thing to have for any piece of software
[05:51] <Hobbsee> jdong: yay!
[05:51] <jdong> bhale: I think I still need to put in some packaging work before I qualify :)
[05:51] <RenatoSilva> so I wondered if this culture of Unit Tests, TDD etc. was particular of Java or if it is used in Linux kernel and distros, for example
[05:52] <RenatoSilva> does the Linux kernel have Unit Tests?????
[05:52] <jdong> RenatoSilva: many kernel developers I'm sure have a regression testing suite...
[05:52] <jdong> RenatoSilva: it is very hard to define unit tests for every subsystem of the kernel
[05:52] <RenatoSilva> is there something like JUnit for C, such as "CUnit"??
[05:53] <jdong> RenatoSilva: but I know for sure filesystem developers have a very full testing suite
[05:53] <bhale> this is drifting further from the topic
[05:54] <bhale> google says: http://cutest.sourceforge.net/
[05:54] <RenatoSilva> and Debian too, they test its software for years before release it, which kind of tests they do, I wondered
[05:54] <jdong> users test and report bugs, bugs are fixed
[05:54] <jdong> the standard way of testing
[05:55] <jdong> you can't practically unit test an entire distribution :)
[05:55] <jdong> try writing a unit test for burning a DVD :)
[05:55] <RenatoSilva> I told them, If tests are so important that you reject non-testable software, then we shoudn't trust in linux kernel, because they haven't tests
[05:56] <RenatoSilva> jdong: it would be difficult???
[05:56] <jdong> yes
[05:56] <bhale> ubuntu releases go through a documented testing plan
[05:57] <RenatoSilva> jdong: it's strange, in Java we have not this culture of "hey, it's a beta, help us testing it"
[05:57] <bhale> can i persuade you to join #ubuntu-offtopic
[05:57] <RenatoSilva> jdong: we pratically have not "betas", but milestones
[05:57] <RenatoSilva> bhale: sorry
[05:57] <RenatoSilva> bhale: I'll stop
[05:58] <wowow> hey guys
[05:58] <wowow> anyone here from the installer team?
[05:58] <Hobbsee> wowow: #ubuntu-installer but there's probably no one awake
[05:58] <wowow> installing dapper on intel chipset systems is a problem, screen goes all black 3/4'rs of the way through 
[05:58] <RenatoSilva> bhale: but if was a great information, in offtopic we woudn't find developers (they would ask me what is unit testing :D )
[05:58] <wowow> ah! well i'll try anyway
[05:59] <bhale> RenatoSilva: you must understand, it is pretty slow right now.. if we started letting people ask anything, there would be no time to work
[06:00] <RenatoSilva> jdong: tahnk you for all information, remember of me, softmodems and Brazil, and good luck with Ubuntu development! Thank you everybody!
[06:00] <wowow> well posted there
[06:00] <RenatoSilva> bhale: sorry, I finished :D
[06:00] <Hobbsee> bhale: exactly.
[06:00] <wowow> just in case no one is awake, would anyone have a clue why on intel chipset mobos the dapepr installer goes blank on all terminals 3/4'rs of the way through? or how to fix this problem?
[06:00] <wowow> or get around it even?
[06:01] <RenatoSilva> thank you everybody, see you later!
[06:01] <Hobbsee> wowow: might be better to run edgy/feisty on that, if it's a core duo
[06:01] <Hobbsee> or later
[06:01] <wowow> can't 
[06:01] <wowow> this is for work
[06:01] <wowow> we can only run lts
[06:01] <jdong> wowow: what kind of Intel system?
[06:02] <wowow> well two separate systems
[06:02] <wowow> this one is an asus z95f with a core duo cpu indeed
[06:02] <_ion> wowow: Have you posted a bug report?
[06:03] <wowow> the others are an asrock mobo with ... *hmm* with core 2 duos on them
[06:03] <wowow> i would but i'm flying out in about 3 hours
[06:03] <Hobbsee> wowow: that kernell seems to be a bit old to support the core duo's well - i had the same problem, with graphics
[06:03] <wowow> looking for wiggle room, then will post 
[06:03] <jdong> wowow: please do file a bug report....
[06:03] <wowow> yeah later, i don't have time
[06:03] <jdong> sure.
[06:03] <wowow> Hobbsee, ah, *hmm*
[06:04] <wowow> damnit might not have any choice but to do edgy feisty
[06:04] <wowow> *grr*
[06:05] <Hobbsee> wowow: unfortunately, yes.  feisty should be fairly well supported by now
[06:06] <wowow> lots and lots of updates still, kinda shitty to have regular users have a box like that.  when is feisty due for release?
[06:06] <Hobbsee> 19th
[06:06] <Hobbsee> true, but a new kernel has the potential to break a lot of other things.
[06:06] <Hobbsee> which is unacceptable for a LTS, obviously
[06:06] <RenatoSilva> next wednesday? nice!
[06:06] <wowow> ah, *hmm* well maybe we could squeak by
[06:07] <wowow> Hobbsee, yeah true, i have a canonical support account but its fior 9x5
[06:07] <wowow> i'll bug them in about a week to see if there is anything that can be backported
[06:07] <_ion> There shouldnt be many updates for feisty before release.
[06:07] <wowow> maybe not
[06:07] <Hobbsee> wowow: you could always upgrade that support if you needed it, too.  *shrug*
[06:07] <Hobbsee> or make sure you only do the upgrades between 9-5
[06:08] <wowow> not without my bosses cc and not before i fly out
[06:08] <Hobbsee> good point
[06:08] <wowow> Hobbsee, so you say youve seen this before?
[06:08] <wowow> intel chipset too?
[06:09] <Hobbsee> wowow: not exactly that - but had heaps of X problems when trying to run dapper on this core duo
[06:09] <wowow> well i actually have like two installs on core duo laptops ... but those installed magically even with this issue
[06:09] <jdong> Dapper ran fine on my core duo (centrino) laptop.... but I have too seen many reports of issues
[06:10] <Hobbsee> wowow: intel 965 graphics chipset
[06:10] <wowow> i think thats what it is here
[06:10] <kapputu> hi, have some problems installing cpan modules in feisty
[06:10] <kapputu> http://paste.ubuntu-nl.org/15900/
[06:10] <Hobbsee> kapputu: see the /topic
[06:11] <kapputu> k
[06:11] <wowow> well on the upside, with feisty the power use on the laptop should improve, right?
[06:11] <Hobbsee> should do, yes
[06:11] <Hobbsee> booting's a lot faster too
[06:11] <wowow> cuz this mofo cpu fan is spinning at 100% right now for no reason
[06:11] <wowow> heh
[06:11] <jdong> performance will also be better on the core duos
[06:11] <jdong> and any other shared-cache CPU designs
[06:11] <wowow> oh i heard that, so the new bootloader is working wonders eh?
[06:12] <wowow> jdong, nifty
[06:12] <jdong> lol not really... just optimized boot scripts
[06:12] <wowow> so what you guys are saying is take a chance, lots of upside
[06:12] <Hobbsee> wowow: yes.
[06:12] <jdong> I think Feisty is a good choice :)
[06:12] <jdong> once it releases
[06:12] <Hobbsee> wowow: particularly if you've got the canonical support anyway
[06:12] <wowow> allright, blast it, i was hoping for keeping lts around and doing a company wide upgrade
[06:13] <wowow> cool, thx for the input, that clears up a few things
[06:14] <Hobbsee> presumably with the next one you could
[06:15] <wowow> actually i'm starting to doubt it
[06:15] <wowow> chipset and cpu designs evolve so quickly, it's impossible to keep a 2 year old kernel current
[06:15] <Hobbsee> wowow: true, but are you going to upgrade all your machines again after this?
[06:16] <wowow> not until the next lts is available
[06:16] <Hobbsee> ie, it'll still support all the old ones - but will you be adding more that you need the later support for?
[06:16] <Hobbsee> sorry, i meant hardware-wise
[06:16] <wowow> unfortunately yeah we do every year and in unplanned ways
[06:16] <wowow> we run stuff for the gov't so they randomly give us dollars to spend or we loose them
[06:16] <wowow> makes planning VERY difficult
[06:17] <Hobbsee> ahh
[06:17] <wowow> albeit linux still makes it easier than dealing with vista
[06:17] <Hobbsee> true
[06:17] <Hobbsee> which means you'd have exactly the same problem with any distro, presumably
[06:17] <wowow> oh totally
[06:17] <wowow> not complaining about ubuntu at all
[06:17] <Hobbsee> if you needed the latest kernels each time to support the computers you were buying
[06:18] <wowow> just a kink in the deployment strategy i guess
[06:18] <Hobbsee> in that case, i'd guess that you'd want to pick a distro which is good at dist-upgrading, and officially supports that
[06:18] <wowow> there is only two bro 
[06:18] <wowow> :)
[06:18] <wowow> debian
[06:18] <wowow> and debian + (i.e. ubuntu)
[06:18] <wowow> :)
[06:18] <Hobbsee> ie, it sounds like you're not looking for LTS at all - but a good way to dist-upgrade
[06:19] <Burgundavia> wowow: lts --> lts will certain be supported
[06:19] <Hobbsee> well, yeah :)
[06:19] <Burgundavia> certainly, rather
[06:19] <wowow> no i'm really only looking for lts, i'm being forced to alter my assumptions :)
[06:19] <wowow> *nod*
[06:19] <Treenaks> (because of the hardware support thing)
[06:19] <Burgundavia> wowow: the next lts will likely be feisty+1
[06:19] <Treenaks> Burgundavia: +1 or +2?
[06:19] <Hobbsee> Burgundavia: uh, +2 was the plan
[06:19] <wowow> really?
[06:20] <Treenaks> (because +2 was the last I heard)
[06:20] <Hobbsee> wowow: no.  +2.  
[06:20] <wowow> ah okay
[06:20] <Hobbsee> Burgundavia: you've misread the release annoucement or something
[06:20] <Burgundavia> Hobbsee: which one?
[06:20] <Treenaks> (that means 2 years between LTS)
[06:20] <Hobbsee> Burgundavia: the one for gusty
[06:20] <Burgundavia> ah
[06:20] <wowow> Hobbsee, well thats a good point.  i guess using festy now in a limited way isn't too bad considering a 12 month wait
[06:20] <jdong> Hobbsee: gushy.
[06:20] <Hobbsee> wowow: keep in mind that feisty's still supported - just that it'll only be supported for 18 months.
[06:21] <Treenaks> jdong: gusty
[06:21] <wowow> Burgundavia, btw, its me holycow
[06:21] <wowow> lol
[06:21] <wowow> i got your email
[06:21] <jdong> Treenaks: no, gushy. gushy giblets...
[06:21] <Burgundavia> Hobbsee: you are right, I failed to read the announcement closely
[06:21] <Hobbsee> wowow: but by the sound of things, you'd need to upgrade way before that anyway, if you're getting new hardware every year
[06:21] <jdong> :)
[06:21] <wowow> are you available for a pm a bit?
[06:21] <Burgundavia> wowow: excellent
[06:21] <Burgundavia> yep
[06:21] <wowow> Hobbsee, it's going to be interesting indeed
[06:21] <Hobbsee> wowow: indeed.
[07:36] <kylem> morning
[07:38] <Hobbsee> hi Mithrandir, kylem 
[07:38] <Mithrandir> hiya Kyle, Sarah
[07:39] <wowow> looks like you guys might be right
[07:39] <wowow> feisty hasn't thrown a fit yet
[07:41] <wowow> hope i haven't spoken too soon
[07:41] <wowow> heh
[07:41] <Hobbsee> lol
[07:43] <fabbione> morning Mirv 
[07:43] <fabbione> bah
[07:43] <fabbione> morning Mithrandir 
[07:43] <Mithrandir> morning Fabio
[07:48] <evand> Good morning fabbione and Mithrandir 
[07:48] <fabbione> hi evand 
[07:48] <tepsipakki> good morning everyone
[07:50] <_ion> Hi all.
[07:52] <tepsipakki> :)
[07:53] <Hobbsee> one of the girls at work seems to like singing randomly...
[07:56] <tepsipakki> I guess she's not that good :)
[07:57] <tepsipakki> at it
[07:57] <Hobbsee> oh she might be, but i need her to do some work, dammit :P
[07:57] <tepsipakki> hah
[07:57] <Hobbsee> they're either wandering around, singing, chatting...
[07:58] <Hobbsee> when you want to do that a bit, that's fine...but to only do that, adn not actually do the work that needs to be done...grrr...
[07:58] <wowow> i agree with you
[07:58] <wowow> it can make one go postal
[07:58] <wowow> i too can't ignore patterns
[07:59] <Hobbsee> Mithrandir: how'd the RC go?  do we have more images to test?
[07:59] <wowow> lol
[07:59] <wowow> no beatings no respect
[07:59] <wowow> i submit there is a 1:1 correleation
[07:59] <wowow> -_-
[07:59] <Hobbsee> heh.  i'm not *that* old :P
[07:59] <Mithrandir> Hobbsee: current images are, well, current.  I believe they are good.
[07:59] <Hobbsee> Mithrandir: great
[08:00] <Mithrandir> DVDs are being rebuilt since I forgot about them yesterday.
[08:01] <Hobbsee> right
[08:01] <ajmitch> morning Mithrandir 
[08:02] <Mithrandir> morning ajmitch, evand
[08:03] <mneptok> oy Tollef
[08:03] <fabbione> mneptok: you are not supposed to be around.. go away
[08:05] <mneptok> si padrone.
[08:07] <wowow> damn, this canadian mirror is soooo slow
[08:07] <wowow> its gonna take forever for feisty to install
[08:14] <Hobbsee> Mithrandir: any chance you could tell me why this was rejected?  https://launchpad.net/ubuntu/feisty/+queue?queue_state=4&queue_text=tutos2
[08:14] <dholbach> good morning
[08:14] <Mithrandir> hiya Daniel
[08:14] <dholbach> hey Tollef
[08:14] <Hobbsee> hiya dholbach 
[08:14] <Mithrandir> Hobbsee: looking
[08:15] <dholbach> hey Hobbsee
[08:24] <pitti> Good morning
[08:25] <Hobbsee> pitti: heya
[08:26] <Hobbsee> BenC: any plans to fix https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/106028 ?  or pointers on how to?
[08:26] <ubotu> Malone bug 106028 in linux-source-2.6.20 "Kvm not installable in feisty" [Undecided,Confirmed]  
[08:27] <dholbach> Hobbsee: shouldn't the last upload fix that?
[08:28] <Hobbsee> dholbach: it's not installable now...
[08:28] <fabbione> it can be fixed in kvm too
[08:28] <Hobbsee> fabbione: how, though?
[08:28] <fabbione> Hobbsee: drop the Depends: or change it to a linux-$image
[08:29] <Treenaks> linux-image-2.6.20-14 Provides: kvm-modules-2.. maybe use that?
[08:29] <Hobbsee> fabbione: what's the syntax for the latter?
[08:29] <dholbach> kvm (1:16-1ubuntu2) feisty; urgency=low
[08:29] <dholbach>  .
[08:29] <dholbach>    * Revert to kvm-16 to match released kernel.
[08:29] <dholbach>    * Add epoch.
[08:29] <Hobbsee> dholbach: we're on .18 now...
[08:29] <dholbach> Date: Sun, 15 Apr 2007 17:52:01 -0400
[08:29] <dholbach> epoch
[08:30] <Hobbsee> oh, i see
[08:30] <dholbach> http://www.mail-archive.com/feisty-changes@lists.ubuntu.com/msg08215.html
[08:32] <Treenaks> good.. that means my new server will run Feisty ;)
[08:32] <Treenaks> ~ 4 times
[08:32] <Treenaks> at once.
[08:36] <Hobbsee> Mithrandir: thanks
[08:38] <Mithrandir> Hobbsee: looks like a manual reject; was it your upload?
[08:38] <Hobbsee> Mithrandir: wasnt mine.  was on u-u-s
[08:39] <Hobbsee> Mithrandir: oh. i'd say it's because it was uploaded twice
[08:48] <wowow> feisty does indeed boot fast
[08:48] <wowow> neato
[09:42] <heno> Mithrandir: please PM me the latest md5sums
[09:43] <dholbach> heno: he updated Testing/md5sums already
[09:43] <heno> ah, coolie
[09:43] <dholbach> cd testing - yoohoo :)
[09:43] <heno> woooooo!
[09:44] <heno> btw, we have an archive view of the previous testing FWIW https://www.stgraber.org/ubuntu/isotesting/archive
[10:11] <dholbach> hey mvo
[10:11] <mvo> good morning
[10:11] <mvo> hey dholbach
[10:14] <ajmitch> morning mvo 
[10:14] <mvo> hey ajmitch
[10:23] <fabbione> Keybuk, iwj: ping?
[10:23] <Keybuk> morning
[10:23] <fabbione> Keybuk: hey dude
[10:24] <fabbione> bad news
[10:24] <fabbione> root on lvm on raid is still racy.. i have a machine that can boot this one time yes and two no
[10:24] <fabbione> i can see the raids are formed properly
[10:25] <fabbione> but lvm is not started
[10:26] <Keybuk> please investigate yourself, and see what you can find out
[10:26] <fabbione> _ion: use at least 2 raids in the setup
[10:26] <Keybuk> fabbione: you have the fixes for the mdadm race installed, I assume?
[10:27] <Keybuk> raid definitely did used to be racy
[10:27] <fabbione> Keybuk: fresh install as this morning
[10:27] <fabbione> _ion: one raid1 for /boot, one raid1 for lvm -> lvm with 2 lv -> root and swap
[10:27] <fabbione> but i am sure it's just yet another race somewhere
[10:27] <fabbione> so you might not see at all
[10:28] <Keybuk> in theory, there shouldn't be any races
[10:28] <Keybuk> since lvm is called when the mdadm is assembled
[10:28] <Keybuk> it could be something like lvm locking out
[10:28] <Keybuk> and failing rather than waiting
[10:28] <_ion> fabbione: Sorry, i was only joking. I interpreted the investigate yourself part literally. :-)
[10:28] <tepsipakki> does anyone know what is the status of UDS sponsorship?
[10:29] <fabbione> Keybuk: it's possible... it's possible that we need to use the same trick to check the raid status before attempting to enable lvm
[10:29] <Keybuk> we don't have a trick to check the raid status ...
[10:29] <Keybuk> in theory, we should just be able to call lvm repeatedly until it works; likewise with mdadm
[10:30] <fabbione> we added that call to mdadm --$cantremember
[10:30] <Keybuk> no we didn't
[10:30] <Keybuk> we added a call to vol_id
[10:31] <fabbione> oh right.. yeah
[10:31] <Keybuk> since that works for all volume types
[10:31] <Keybuk> are there any useful messages on the screen?
[10:31] <fabbione> nope
[10:31] <Keybuk> or does it just hit the "try to mount the root disk" without it being there?
[10:31] <fabbione> checking slowly.. step by step
[10:32] <Keybuk> is there a three minute timeout?
[10:32] <fabbione> yes
[10:32] <fabbione> the timeout is there and i get dropped to busybox
[10:32] <fabbione> that's where i can see raids are up but lvm isn't
[10:32] <fabbione> problem is that it doesn't happen always
[10:33] <fabbione> so it takes a few reboots to trigger stuff
[10:34] <fabbione> ah there.. reproduced
[10:34] <fabbione> no errors.. raids are started fine.. lvm isn't
[10:34] <Keybuk> ok, interesting
[10:34] <fabbione> waiting to be dropped to busybox
[10:34] <Keybuk> the fact you hit the timeout is useful
[10:34] <Keybuk> that means that we're not mistakenly believing the root filesystem is ready
[10:34] <Keybuk> (which was the mdadm and lilo problems
[10:34] <fabbione> yeah if i do manually lvm vgchange -a y and ctrl+d it's all good
[10:34] <Keybuk> the problem is that vgchange isn't working
[10:35] <fabbione> seems like sometimes it does...
[10:35] <Keybuk> SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="lvm*|LVM*", RUN+="wa
[10:35] <Keybuk> tershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'"
[10:35] <Keybuk> -- 
[10:35] <Keybuk> so there's a few possibilities
[10:35] <Keybuk> 1) the add/change event isn't getting emitted when the md is assembled (probably false)
[10:36] <Keybuk> 2) vol_id on the md is failing (probably also false)
[10:36] <Keybuk> 3) vol_id is working, but not detecting an LVM volume group (this would fail every time)
[10:36] <Keybuk> 4) either vgscan or vgchange aren't picking up the new PV
[10:37] <fabbione> it's not 3) (just checked)
[10:37] <fabbione> (initramfs) /lib/udev/vol_id /dev/md1 
[10:37] <fabbione> ID_FS_USAGE=raid
[10:37] <fabbione> ID_FS_TYPE=LVM2_member
[10:37] <fabbione> ID_FS_VERSION=LVM2 001
[10:37] <fabbione> it's also good for the other raid
[10:38] <fabbione> if 1 is true, in theory the machine would never boot
[10:38] <fabbione> but it does once in a while
[10:39] <Keybuk> http?//wiki.ubuntu.com/DebuggingLvm
[10:39] <Keybuk> err, fixed a typo on there
[10:39] <Keybuk> (supress -> suppress_
[10:39] <fabbione> yeps.. noticed
[10:40] <fabbione> brb
[10:41] <keyes> hello
[10:48] <doko> dholbach, seb128: gnome-terminal started to translate mouse-wheel events into history scrolling, which doesn't work well when there's not a command prompt (another command running). is there a way to disable this?
[10:49] <seb128> doko: not that I know
[10:50] <doko> bad ...
[10:52] <fabbione> Keybuk: are you sure that's the right debugging sequence?
[10:52] <fabbione> more udevd.log 
[10:52] <fabbione> another udev daemon already running
[10:52] <fabbione> init_udevd_socket: bind failed: Address already in use
[10:52] <fabbione> main: another udev daemon already running
[10:52] <Keybuk> did you remove the script?
[10:52] <fabbione> (doing that makes the machine booting)
[10:52] <fabbione> yes
[10:52] <keyes> I'm a student for Google Summer Of Code, where can I find my mentor ?
[10:52] <Keybuk> err
[10:53] <Keybuk> what gave those error messages?
[10:53] <doko> keyes: what's your real name?
[10:53] <fabbione> i mean i did copy/paste what's in the page and vgchange has been executed (i could see that)
[10:53] <keyes> doko, K?vin Dunglas
[10:53] <fabbione> Keybuk: whatever wrote in udev.log
[10:53] <Keybuk> oh, hmm
[10:53] <Keybuk> so there's a udevd already running when you break?
[10:53] <fabbione> ahhhhh crap
[10:53] <Keybuk> and you did break=premount, not break=mount ?
[10:53] <fabbione> forgot the break
[10:55] <doko> keyes: please add your first name for the SoC/gmail account 
[10:55] <keyes> doko, OK, where can I do that ?
[10:56] <doko> keyes: well, you did apply, so it should be found at the same place
[10:56] <keyes> ok !
[10:58] <Riddell> Mithrandir: I take it we're not planning a herd 6?
[10:59] <Mithrandir> Riddell: that is correct.
[11:00] <Mithrandir> cjwatson: http://paste.ubuntu-nl.org/15947/ ; reminded as you asked me to.
[11:00] <cjwatson> Mithrandir: thanks
[11:02] <fabbione> Keybuk: http://people.ubuntu.com/~fabbione/udevd.log.bz2
[11:02] <fabbione> Keybuk: running this way did not trigger the race.. lvm was activated
[11:02] <fabbione> Keybuk: i noticed tons of stuff scrolling on console coming from vol_id
[11:03] <Mithrandir> fabbione: if there is a workaround for this race, please make sure that gets into the release notes.
[11:03] <fabbione> Mithrandir: we are still looking at it... once we know what it is, i will file a proper bug
[11:03] <Mithrandir> goodie
[11:05] <Keybuk> fabbione: the log without the race isn't very useful
[11:06] <Keybuk> please keep trying until you cause the race
[11:06] <fabbione> Keybuk: ok....
[11:06] <Keybuk> actually, that's not true; the log without the race is useful to compare with a log with the race
[11:06] <fabbione> tho it might not happen at all with all this manual mangling
[11:06] <Keybuk> :)
[11:06] <Keybuk> it should happen
[11:06] <Keybuk> the only difference is the logging
[11:06] <fabbione> yeps
[11:06] <fabbione> ok
[11:07] <Keybuk> I'd be surprised if it's a sub-second race
[11:11] <sladen> Keybuk: I haven't debugged it yet;  hibernate here is failing because the swap device is not being linked in  /dev/.../by-uuid/
[11:12] <sladen> Keybuk: is the uuid of the swap partition ever regenerated, eg. after a failed hibernate, leading to the entry in /etc/fstab and the on-disk UUID not matching?
[11:13] <cjwatson> Mithrandir: is there a wiki page where I can dump text about that?
[11:13] <sladen> Keybuk: tried quickly changing   .../65-persistent-naming.sh  to also accept   filesystem|other|swap  though that didn't cure it
[11:13] <Mithrandir> cjwatson: https://wiki.ubuntu.com/FeistyKnownIssues ?
[11:13] <cjwatson> thanks
[11:15] <cjwatson> Mithrandir: done
[11:16] <ogra> mumble ... why isd my dvd oversized again ?
[11:16] <dholbach> heno: can we get dvd images on the iso testing page?
[11:16] <fabbione> Keybuk: i can't reproduce the race with the debugging procedure.... 
[11:16] <ogra> Riddell, which linux-* package did you drop to free up space ?
[11:17] <ogra> highvoltage, i could need a macro :P
[11:17] <heno> dholbach: yep, 1 min.
[11:17] <ogra> but at least i dont have to say CD anymore :)
[11:17] <cjwatson> ogra: I fixed that
[11:17] <ogra> cjwatson, oh, thanks :)
[11:17] <cjwatson> ogra: it just needs a DVD rebuild; the health checks are regarding images from before my fix
[11:17] <cjwatson> ogra: (I dropped kdepim-dbg and kdepim-doc)
[11:17] <ogra> ok
[11:19] <heno> done
[11:19] <Mithrandir> ogra: it's good now anyway.
[11:19] <ogra> Mithrandir, ok
[11:20] <ogra> ahuman, yes, i should look at the webpage before judging by the mail i get :)
[11:20] <ogra> err
[11:20] <ogra> s/ahuman/ah/
[11:30] <pitti> tepsipakki: when I let xserver-xorg-video-intel in, I assume I can remove both -i810 and -i810-modesetting?
[11:30] <pitti> tepsipakki: it Conflicts/Replaces: both, but only provides a transisional package for -i810
[11:31] <Keybuk> sladen: yes, many things seem to change the UUID
[11:31] <Keybuk> fabbione: interesting, that implies a sub-microsecond race !!
[11:32] <fabbione> Keybuk: score... so ... what do i do now to check?
[11:32] <Keybuk> err, need to find out what is racing what
[11:33] <Mithrandir> pitti: uh, no.
[11:33] <Mithrandir> pitti: don't remove -i810.
[11:33] <fabbione> Keybuk: can you try to ssh keybuk@trider-g7.fabbione.net ?
[11:33] <fabbione> Keybuk: you should get console on the machine directly..
[11:33] <pitti> Mithrandir: erm, not that one, of course; sorry
[11:33] <Keybuk> fabbione: I don't have any time to help you debug this week I'm afraid
[11:33] <Keybuk> I can look at it next week
[11:33] <fabbione> Keybuk: yes i understand you are busy but we need at least to file a proper bug to add to the release note...
[11:34] <Keybuk> fabbione: things you can try: does adding a rule like RUN+="/bin/sleep 1" in 00-init.rules fix it?
[11:35] <doko> Mithrandir: please could you consider/review http://people.ubuntu.com/~doko/tmp/updates25.diff ? Reversal of two changes on the python2.5 branch. I checked with mvo (using pickling in update-manager) that the update code is not affected. 
[11:35] <fabbione> Keybuk: checking
[11:35] <Keybuk> if so, does moving that sleep to just in the mdadm call path, or just the lvm call path, or just the vol_id call path, etc. fix it
[11:35] <Keybuk> fabbione: also so far I've not heard any further reports on this race, so it may be something with your underlying hardware perhaps?  is this using multipath?
[11:36] <Mithrandir> doko: does it fix any critical bugs?  If not, -updates.
[11:36] <fabbione> no multipath involved.. it's just  a plain fresh install.. the disks are local 
[11:37] <fabbione> the SAN is not connected to this machine
[11:37] <Keybuk> ok
[11:38] <doko> Mithrandir: I don't know that it's reported as a bug in a package; it's a behaviour change compared to the 2.5 release. I certainly can move it -updates (maybe together with the 2.5.1 final release, there shouldn't be more changes)
[11:39] <Mithrandir> doko: yes, please.
[11:39] <doko> heno: no lrm updates required for iso testing after the kernel updates from the weekend?
[11:39] <cjwatson> no, l-r-m for 2.6.20-15 is already there
[11:40] <cjwatson> why do you ask? is something going wrong?
[11:41] <doko> cjwatson: no, didn't see that there was no abi bump
[12:02] <fabbione> Keybuk: nope.. sleep doesn't help anywhere
[12:02] <fabbione> it's like the lvm rule is not invoked at all
[12:02] <fabbione> but it is at random
[12:15] <heno> iwj, kylem, mvo, bdmurray, mikebro, cburg, Riddell, kwwii, rtg, pkl, Keybuk, pitti, seb128: Just a mass-ping to make sure everyone is aware the 20070415 CDs are published (20070416 for DVDs). Please test.  emails have gone out with links and instructions
[12:15] <pitti> heno: acknowledged, I'm 80% done already
[12:15] <iwj> heno: Thanks.  My rsync is running.
[12:16] <iwj> heno: BTW, might it be worth swapping over some of the test cases ?
[12:16] <pitti> heno: I'll also test cli, for the fun of it (it's fast)
[12:16] <iwj> Your earlier mail suggested I should look at the isotesting/ page, which I did, so now I'm downloading the d-i cd instead of the livecd.
[12:16] <iwj> Since it seemed to need more attention.
[12:18] <fabbione> iwj: hey.. if you have a second do you mind to read the scrollback for the conversation between me and Keybuk about lvm/raid etc?
[12:18] <heno> iwj: great, thanks. please improvise as you find it best. 
[12:18] <fabbione> iwj: it seems i found another race
[12:19] <fabbione> iwj: if you need i can easily give you access to the box console
[12:19] <iwj> fabbione: Sure.  I sort of skimmed it hoping Keybuk would handle it :-).
[12:19] <iwj> Let me read it properly.
[12:19] <fabbione> iwj: ehhe
[12:19] <fabbione> iwj: i just need to be able to file a proper bug at this point to add to the release note.. i don't think we can get a fix in at this point in time
[12:20] <Mithrandir> fabbione: not if you can find a workaround, at least.  And not unless this can be shown to affect more people.  (Sorry. :-/)
[12:21] <fabbione> Mithrandir: well whatever we can get out.. 
[12:21] <fabbione> Mithrandir: well clearly.. but i seriously doubt it affects only me.. tho if it's a race it might trigger at random to anybody..
[12:23] <iwj> The difficulty is knowing how common it is.
[12:24] <iwj> So at a guess what's happening is that the kernel generates its last change event for the md device before the device is ready for IO.
[12:25] <Mithrandir> in that case, a kernel bug, then?
[12:25] <iwj> Yes.
[12:25] <iwj> But I could be casting aspersions.
[12:25] <iwj> It's very difficult to say for sure from the information we have right now.
[12:26] <iwj> Oh, hold on, Fabio says adding `sleep' didn't help.
[12:26] <fabbione> cat /etc/udev/rules.d/85-lvm.rules 
[12:26] <fabbione> # This file causes block devices with LVM signatures to be automatically
[12:26] <fabbione> # added to their volume group.
[12:26] <fabbione> # See udev(8) for syntax
[12:26] <fabbione> SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="lvm*|LVM*", RUN+="watershed sh -c 'mkdir -p /dev/debugging/ && touch /dev/debugging/lvm.%k'"
[12:26] <fabbione> iwj: ^^ this doesn't work either.. it's like lvm rule is ignored
[12:26] <fabbione> no sleep doesn't help
[12:27] <iwj> Sleep where ?
[12:27] <iwj> ENV{ID_FS_TYPE} comes from the vol_id in persistent-storage.rules.
[12:27] <fabbione> i did try both in 00-init and 85-lvm 
[12:27] <fabbione> i added a sleep 1 before invoking pvscan; vgchange...
[12:32] <iwj> fabbione: Can you try this: in persistent-storage.rules just before   IMPORT{program}="vol_id --export $tempnode"
[12:32] <iwj> do something like this
[12:32] <iwj> Err, actually let me just check the syntax.
[12:32] <fabbione> sure
[12:32] <fabbione> take your time
[12:33] <fabbione> iwj: as i said.. if it's easier for you to get access, i can set it up in a few seconds
[12:33] <fabbione> iwj: it's one of those sandboxes you can beat up to death
[12:35] <iwj> udev--
[12:35] <iwj> run_program: '/lib/udev/sh' (stdout) 'run_program: program '/lib/udev/sh' not found'
[12:35] <iwj> Gets me every time, that one.
[12:38] <iwj> PROGRAM="/bin/sh -c 'vol_id --export $tempnode >/tmp/volid.%k.$$$$'"
[12:38] <iwj> Just before IMPORT{program}="vol_id --export $tempnode"
[12:38] <iwj> Oh, sorry, instead:
[12:38] <iwj> PROGRAM="/bin/sh -c 'vol_id --export $tempnode >/tmp/volid.%k.$$$$ 2>&1'"
[12:39] <fabbione> # by-label/by-uuid (filesystem properties)
[12:39] <fabbione> KERNEL=="*[!0-9] ", ATTR{removable}=="1", GOTO="persistent_storage_end"
[12:39] <fabbione> PROGRAM="/bin/sh -c 'vol_id --export $tempnode >/tmp/volid.%k.$$$$ 2>&1'
[12:39] <fabbione> IMPORT{program}="vol_id --export $tempnode"
[12:39] <fabbione> ok ?
[12:40] <iwj> Right.
[12:40] <iwj> With luck it will still fail.
[12:40] <iwj> If it doesn't it might still produce some useful info.
[12:40] <fabbione> ok
[12:40] <iwj> We'll need copies of all of those /tmp files it makes ...
[12:40] <fabbione> yeps
[12:40] <fabbione> easy enough
[12:41] <mvo> heno: server is done, upgrade testing is runing (take a bit)
[12:41] <heno> mvo: woo! thanks
[12:45] <fabbione> iwj: it's still failing.. waiting for the timeout
[12:45] <iwj> Yay.
[12:45] <iwj> Don't vgchange straight away.
[12:45] <fabbione> nope
[12:45] <iwj> We need to know which device it failed to find the volumes on.
[12:45] <fabbione> yeps
[12:48] <fabbione> iwj: /tmp is emptu
[12:48] <fabbione> empty
[12:49] <Mithrandir> I'm wondering if just entering "5" as the size in partman should select 5GB and not 5MB
[12:51] <iwj> fabbione: Freaky.
[12:51] <fabbione> iwj: i wonder if the bug is exactly in vol_id
[12:52] <iwj> We would expect a bunch of empty files then .
[12:54] <iwj> Did you regenerate your initramfs ?
[12:55] <Keybuk> should be /lib/udev/vol_id too
[12:55] <iwj> Oh, so it should.
[12:55] <iwj> vol_id is in the path in the real system so I didn't notice.
[12:55] <fabbione> iwj: yes i did regenerated it
[12:56] <Keybuk> (still should've had an empty file)
[12:56] <Keybuk> or one with an error
[12:56] <Keybuk> I think
[12:56] <Keybuk> no, maybe not
[12:57] <fabbione> hmm it makes no sense
[12:57] <fabbione> if i have to specify the path.. how would this work
[12:57] <fabbione> IMPORT{program}="vol_id --export $tempnode"
[12:58] <iwj> fabbione: udev prepends /lib/udev to the program name in "..."
[12:58] <fabbione> iwj: ok
[12:58] <cjwatson> Mithrandir: one of those annoying finger-macro-compatibility things, I think. TBH I reckon it should probably just reject plain numbers altogether
[12:58] <iwj> There surely should have been an empty file.  sh would have tried to execute vol_id from the path.
[12:58] <iwj> So we still don't know why no files at all.
[12:59] <fabbione> i noticed that udev was telling me that there was a bad rule....
[12:59] <fabbione> but i couldn't see which one
[12:59] <cjwatson> Mithrandir: the more common confusion is AFAICT not megabytes with gigabytes but megabytes with bytes - people type in "2147483648" and wonder why it tells them their disk is too small
[12:59] <iwj> Oh, you have dropped the trailing "
[12:59] <Mithrandir> cjwatson: heh, true.
[12:59] <tarzeau> can i help with $105996 ?
[12:59] <iwj> fabbione: syntax error ^
[12:59] <tarzeau> i mean # not $
[12:59] <fabbione> iwj: good catch
[01:00] <iwj> This installer lvm wedge is deeply annoying.
[01:01] <iwj> I mean, the 3 minute pause.
[01:01] <tarzeau> i've got http://gnu.ethz.ch/debian/libfreebasic/libfreebasic_0.16b-1.dsc for #105996 someone feel like adding quilt/dpatch to it?
[01:01] <fabbione> iwj: yeah.. i agree
[01:03] <Keybuk> iwj: it's three minutes in which people might think about what they're about to do with their root filesystem, and realise that they're silly :p
[01:06] <iwj> fabbione: You can bypass it with mknod in VC2 :-).
[01:06] <fabbione> there.... now we have files in /tmp
[01:06] <iwj> And it has failed ?
[01:07] <iwj> When you copy the files, use cp -a just in case the timestamps are at all useful.
[01:08] <fabbione> iwj: http://people.ubuntu.com/~fabbione/crap.log
[01:08] <fabbione> so it did fail on md*
[01:09] <Keybuk> fabbione: can you re-order that so that it's in pid order
[01:09] <Keybuk> but yes, it's failing on all md*
[01:09] <fabbione> Keybuk: i guess so...
[01:09] <iwj> fabbione:   egrep . *
[01:09] <Keybuk> actually, no need to reorder, it's in order anyway
[01:10] <Keybuk> what's on sda1?
[01:10] <fabbione> sda1 is unused partition
[01:10] <Keybuk> likewise sdb1?
[01:10] <fabbione> same
[01:10] <Keybuk> ok
[01:10] <fabbione> it's a 8MB padding partition
[01:10] <Keybuk> it looks like the md0 change event happens too early then
[01:10] <fabbione> you mean my machine is too fast?
[01:11] <Keybuk> no, I mean that there's a bug in the kernel
[01:11] <Keybuk> the whole point of the change event is to say that the md is ready for use
[01:11] <iwj> `unknown volume type' can mean the size is zero.
[01:12] <iwj> But not that it couldn't be opened.
[01:12] <iwj> Unfortunately I don't have a /dev/eio here.
[01:12] <fabbione> iwj: my offer for access is still valid
[01:13] <iwj> Oh, now I know why sleep didn't help.
[01:14] <iwj> Keybuk said RUN+= but vol_id is in PROGRAM.
[01:14] <iwj> OK, here's a workaround: when we get an add or change event for an md* device, we poll it with vol_id for (say) 5s until vol_id works, before letting the rest of persistent-storage continue.
[01:15] <fabbione> iwj: ok.. sure i can test that...
[01:15] <iwj> This md stuff is all such crap!
[01:15] <fabbione> iwj: can you give me the rule you would like in there?
[01:15] <iwj> My test box is doing a cd install test so I can't test my own script.
[01:15] <iwj> How about I draft you a script and you debug it ? :-)
[01:15] <fabbione> i am ok to test it for you..
[01:17] <Keybuk> iwj: yeah, I keep making that mistake
[01:17] <Keybuk> iwj: workaround = fix the kernel
[01:18] <iwj> Uh ?  You think we should patch the kernel for this at this stage ?
[01:19] <Keybuk> no
[01:19] <Keybuk> I think we should do nothing at this stage
[01:19] <iwj> fabbione: Install http://www.chiark.greenend.org.uk/~ijackson/d/t as /scripts/wait-for-crappy-md and then something like
[01:20] <iwj> KERNEL=="md*", PROGRAM="/scripts/wait-for-crappy-md $tempnode"
[01:20] <iwj> just before the vol_id >tmp we had before.
[01:20] <iwj> Keybuk: Sure, but I want to know that we understand the problem before I say we should ignore it for the release.
[01:22] <fabbione> iwj: won't I need some changes in hooks/ to get that script in the initramfs?
[01:22] <iwj> fabbione: You could just edit the initramfs manually.
[01:22] <fabbione> iwj: ok
[01:23] <iwj> Or whatever you like really.
[01:23] <iwj> You'd best run that script in your real system first to check it for syntax errors.
[01:23] <iwj> I haven't executed it at all.
[01:24] <Nafallo> fabbione: btw. /dev/md2 wasn't the degraded array. /dev/md3 was :-P.
[01:25] <fabbione> iwj: seems to work fine
[01:25] <iwj> Right, good.
[01:26] <iwj> But see what Keybuk said.  I don't think we want to ship this.
[01:27] <Keybuk> fabbione: random question
[01:27] <Keybuk> does booting, waiting for timeout, initramfs shell, then run "udevtrigger" work to make the lvm appear
[01:28] <fabbione> Keybuk: i will check it if it fails at the next reboot
[01:28] <iwj> You're thinking of your while sleep 10 do udevtrigger aren't you ?
[01:31] <fabbione> iwj: your workaround did the trick
[01:31] <fabbione> machine is booting
[01:32] <Keybuk> iwj: moi? :p
[01:32] <Keybuk> it's a simple change, with understood results <g>
[01:32] <iwj> I think it's a good idea and can we have it in feisty ?
[01:32] <iwj> *snort*
[01:33] <Mithrandir> fabbione: so  http://www.chiark.greenend.org.uk/~ijackson/d/t makes it all happy for you?
[01:33] <fabbione> Mithrandir: yes. of course that requires a few extra changes.. like 65-persistent-rules changes and installing the script in initramfs
[01:34] <Mithrandir> ok, but this can be worked around from the command line, or just fixed by retrying the boot a few times?
[01:34] <fabbione> it can be worked around from cmdline for me
[01:34] <fabbione> i have to issue a lvm vgchange -a y manually
[01:34] <iwj> Mithrandir: I was referring to Keybuk's insane repeated udevtrigger idea.
[01:34] <fabbione> and it works
[01:35] <fabbione> last test with udevtrigger then i need to grab some food.
[01:35] <Mithrandir> fabbione: ok, then I think we should put something about it into "known issues" and put something into -updates to fix this.
[01:36] <iwj> Mithrandir: Proper fix is a kernel change.
[01:36] <Mithrandir> I didn't say proper fix. ;-)
[01:36] <Mithrandir> I just said "fix".
[01:36] <iwj> Riight.
[01:37] <fabbione> we can for sure fix it in an update
[01:38] <fabbione> the problem are only those people (like this poor bastard) that are affected at first reboot
[01:38] <fabbione> so i hope  a small amount
[01:40] <Keybuk> stop overclocking your scsi card ;)
[01:46] <Nafallo> http://home.nafallo.info/bugs/udev.txt
[01:46] <fabbione> Keybuk: calling udevtrigger a few times help
[01:46] <fabbione> Keybuk: hehehe
[01:47] <Keybuk> "a few times" ?
[01:48] <fabbione> let me try once...
[01:48] <fabbione> it did exit too quickly and i did run it 3/4 times.. then realized that i had to wait
[01:49] <Mithrandir> or just udevtrigger and udevsettle, I suspect.
[01:51] <Nafallo> iwj: wat do you think?
[01:51] <Nafallo> what even
[01:53] <fabbione> Mithrandir: that works too.. one udevtrigger, one udevsettle wait...
[01:58] <Nafallo> hmm
[01:59] <iwj> Nafallo: That log looks like a transcript of successful device discovery to me.
[01:59] <Nafallo> iwj: you do see the places were I've killed mdadm?
[01:59] <iwj> Nafallo: Err, no.
[02:00] <Nafallo> search for died or something :-)
[02:00] <Nafallo> pretty close to the end
[02:00] <Nafallo> I've killed it two times
[02:02] <Nafallo> mdadm: SET_ARRAY_INFO failed for /dev/md/2: Device or resource busy
[02:04] <iwj> Nafallo: Hmm, I'm afraid I've never seen this one before.
[02:04] <Nafallo> I see it everytime I boot :-)
[02:05] <Nafallo> always the same array...
[02:05] <Nafallo> I should see if man mdadm has anything to say about it :-)
[02:06] <iwj> What mdadm has to say about it is `mdadm: SET_ARRAY_INFO failed for /dev/md/2: Device or resource busy' which AFAICT is a form of `You appear to be using Linux software RAID.  Back luck.'
[02:06] <Nafallo> :-P
[02:07] <Nafallo> I start to think something might be wrong with the array. so I'm looking for something to try to repair it ;-)
[02:08] <iwj> `Something wrong with it' ought not to cause these symptoms so I'm sure there's a bug.
[02:08] <iwj> Well, I was already sure there was at least one bug.
[02:08] <iwj> But I mean I'm sure you're experiencing one of the many bugs.
[02:09] <Nafallo> okey :-)
[02:10] <Nafallo> I'll try to help you solve it the best I can anyway.
[02:10] <iwj> At a guess the md* device is wedged in such a way that (a) vgchange hangs trying to read it and (b) mdadm can't fix it because vgchange has it open.
[02:10] <Nafallo> so a race? :-/
[02:10] <iwj> Well, I imagine a race is involved, yes.
[02:10] <Nafallo> that array HAS lvm on it...
[02:10] <iwj> Almost every bug in this area only happens if you lose some race.
[02:11] <Nafallo> and it haven't happened to the other /dev/md1 on the same disk with no LVM...
[02:11] <iwj> If my guess is right then it's a kernel bug and it's far from clear how it might be even worked around.
[02:11] <iwj> Races happen sometimes.  It's what they do.
[02:11] <Nafallo> also, sometimes I have to kill it once and sometimes twice...
[02:11] <Nafallo> I think that might support your theory.
[02:12] <Nafallo> hmm
[02:12] <Nafallo> should we find a good place to set a sleep? ;-)
[02:12] <fabbione> iwj: should we add a bug for my raid thingy and prepare a release note? (hounestly i am counting on your better english than my itaglish ;))
[02:13] <ogra> Keybuk, how hard is it to siplit bootchart into a raw data collecting piece and a image generator ? we wont be able to do ltsp profiling on low level HW (300Mhz/64MB) with the current package it takes to long on such systems to create the png ... i'd like to copy the raw data to the ltsp server and run the generating part there
[02:13] <iwj> fabbione: Yes, probably.
[02:13] <iwj> But I seem to be becoming grumpy and should obviously go and have something to eat.  BIAB.
[02:13] <ogra> Keybuk, (we plan to do a lot of ltsp profiling in spain)
[02:13] <fabbione> iwj: enjoy
[02:13] <Nafallo> iwj: I like you anyway :-)
[02:36] <seb128> cjwatson: I just had a non-working installation due to "no boot flag set" after manual partitioning is that still bug #14244 or should I open a new one?
[02:36] <ubotu> Malone bug 14244 in partman-auto "Automatic partitioning reset boot flag in DOS partition table?" [Medium,Confirmed]  https://launchpad.net/bugs/14244
[02:39] <cjwatson> seb128: probably the same thing
[02:39] <seb128> ok, I was sure with the new partitionner
[02:39] <seb128> not
[02:42] <cjwatson> benefit of the new partitioner is that we get roughly the same set of bugs as the old one rather than a new and exciting set :)
[02:42] <seb128> ah, ok ;)
[02:51] <Keybuk> ogra: relatively easy
[02:51] <ogra> great
[02:52] <ogra> thanks, i'll look at it before sevilla then :)
[02:52] <Keybuk> before sevilla?
[02:52] <ogra> yeah, i want to have a binary ready for the profiling sessions 
[02:52] <ogra> so we can do our measuring :)
[02:54] <Keybuk> fair enough
[02:54] <Keybuk> split the profiling bit into a separate package that readahead can depend on
[02:54] <Keybuk> e.g. readahead-profiler
[02:54] <ogra> oh, i was only referring to bootchart for now
[02:54] <Keybuk> err
[02:55] <Keybuk> s/readahead/bootchart/
[02:55] <Keybuk> sorry
[02:55] <ogra> not sure readahead will be so happy about nfs root
[02:55] <ogra> yeah :)
[02:55] <Keybuk> for some reason, my brain always switches those two words
[02:55] <ogra> heh
[02:55] <iwj> Nafallo: Thanks :-).
[02:55] <Keybuk> (so then we can still tell people to "install bootchart" and have generated pngs)
[02:55] <ogra> right
[02:55] <iwj> Nafallo: You may find that putting sleep 1 in front of the vol_id in persistent-storage.rules helps.
[02:55] <ogra> i dont want to mangle the current package 
[02:55] <bddebian> Heya
[02:56] <ogra> but have a switch or something so i dont have to wait 10-15 mins on these machines until i can log in 
[02:56] <Mithrandir> ogra: I have a SoC student who wants to work on profiling and such.
[02:56] <iwj> TBH I don't think we know enough atm to even propose a coherent workaround for -updates.
[02:57] <ogra> Mithrandir, the ltsp profiling will rather target a small new kernel flavour and very low spec HW ... not sure he wants to take such special cases into account 
[02:57] <Mithrandir> ogra: you might want to chat with him, at least.
[02:58] <ogra> (and we need to have found the drawbacks after seville to make the results flow into development for gutsy ) 
[02:58] <ogra> Mithrandir, yep, will do
[03:04] <hunger> Is the -15-generic kernel more crashprone than the -13-generic version?
[03:05] <mc44> it shouldnt be
[03:05] <mc44> but then the -13 wasnt either for me
[03:05] <cjwatson> hunger: it is not intended to be; please report bugs speedily if you encounter them
[03:05] <hunger> cjwatson: How do I report random crashes that might be my hardware failing or whatnot:-(
[03:13] <phaidros> where is configured which entries are made into menu.lst when installing new kernel?
[03:13] <phaidros> I'm getting always (hd0,0) instead of (hd2,0), which was working in edgy.
[03:45] <dany_21> phaidros: look at this section in /boot/grub/menu.lst: ## default grub root device
[03:45] <dany_21> ## e.g. groot=(hd0,0)
[03:45] <dany_21> # groot=(hd0,1)
[03:46] <dany_21> phaidros: the line with one "#" is the default option (but it should stay commented (#)) - its only read by a script - not by grub
[04:04] <phaidros> thanx dany_21 
[05:04] <iwj> These 50-75% translated documents are surprisingly hard to read.
[05:05] <pitti> and look totally hilarious, on top of it
[05:19] <iwj> cjwatson: I trust that bug 107023 isn't anything to worry about ?
[05:19] <ubotu> Malone bug 107023 in partman-auto "cfdisk complains about auto-resize generated setup" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107023
[05:27] <iwj> Woah!  What does  `_pSLsys_getkey: EIO error'  mean ?
[05:29] <pitti> iwj: ah, testing rescue mode :)
[05:29] <iwj> Oh, bug 60423.  WTF
[05:29] <ubotu> Malone bug 60423 in rescue "freeze after exiting rescue shell" [Undecided,Confirmed]  https://launchpad.net/bugs/60423
[05:30] <iwj> `Rescue a broken system' aka `crash leaving my root fs dirty'.
[05:37] <cjwatson> it's an error message from slang
[05:37] <cjwatson> I have NFI what it means
[05:37] <cjwatson> help welcome
[05:39] <cjwatson> iwj: partitions not being in disk order seems like an intrinsic property of resizing a big partition near the start and adding multiple partitions in the middle, unless you think it's a good idea to renumber existing partitions. I'm therefore not concerned about the fdisk error
[05:39] <cjwatson> iwj: not sure what the cfdisk error means. It doesn't obviously seem to be borne out by the output from the other tools
[05:41] <cjwatson> hmm, comments in the bug instead
[05:41] <cjwatson> either way I don't think it's cause for panic unless it causes systems to fail to bot
[05:41] <cjwatson> boot
[05:41] <iwj> cjwatson: No, that's the only symptom.
[05:42] <iwj> Feel free to declare it a bug in cfdisk.
[05:42] <iwj> cfdisk has a tendency to renumber things and it's one of its worst features.
[05:42] <iwj> So please don't change partman to do that :-).
[05:43] <cjwatson> I'm not even sure how. :-)
[05:43] <cjwatson> cfdisk source says:
[05:43] <cjwatson>               /* the enlarged logical partition starts at the
[05:43] <cjwatson>                  partition table sector that defines it */
[05:43] <cjwatson>               *errmsg = _("enlarged logical partitions overlap");
[05:44] <cjwatson> do we think it maybe means that the logical partition starts at the same sector as the extended partition?
[05:46] <cjwatson> I must admit I am finding the cfdisk source a bit inscrutable around there
[05:49] <asac> i installed server cd, tested that exim4 works, then replaced by sendmail and got during install
[05:49] <asac> http://pastebin.ubuntu-nl.org/15976/
[05:49] <asac> anyway, sendmail is running ... not yet tried if basic things work
[05:50] <cjwatson> asac: I think that's clearly a sendmail bug although not RC
[05:50] <ogra> sendmail is in main ? 
[05:50] <ogra> nah, isnt ...
[05:50] <cjwatson> over pitti's dead body, I expect
[05:50] <ogra> heh
[05:50] <ogra> asac, file a bug for motu :)
[05:50] <kylem> sendmail is a perfectly reasonable piece of software.
[05:50] <pitti> *shudder*
[05:50] <asac> dunno just thought might be good to know that it works for server flavour
[05:50] <iwj> cjwatson: But in this case the logical partition starts strictly inside the extended one.  (I don't know what an `enlarged logical partition' is)
[05:50] <ogra> kylem, but nothing we support 
[05:51] <kylem> pitti, :P
[05:51] <Keybuk> qmail rocks
[05:51] <fabbione> kylem: yes.. it is.. printed on 4 layers toitel paper
[05:51] <asac> any sendmail expert here?
[05:51] <ogra> kylem, eek
[05:51] <kylem> haha.
[05:51] <cjwatson> iwj: oh, is that what "9354+" means from sfdisk? OK.
[05:51] <pitti> asac: our cat can probably configure it well by randomly walking on the keyboard with caps lock turned on
[05:52] <asac> rofl
[05:52] <iwj> cjwatson: I assume so.
[05:52] <cjwatson> iwj: enlarged> that's the bit I'm finding inscrutable.
[05:52] <pitti> oh, we install exim4 by default in server? why do we bother with maintaining the deltas to debian which change the prefered mailer to postfix? 
[05:52] <iwj> I still have the setup here so if you want me to ask it anything let me know.
[05:52] <elmo> I never understood why we bother maintaining that default anymore anyway
[05:53] <bhale> my server doesnt have exim
[05:53] <elmo> when we installed an MTA by default it made sense, now we don't, it just seems like busywork
[05:53] <pitti> Keybuk: erk @nonfree :) what does it do so much better than postfix? (genuine question)
[05:53] <Keybuk> propose a spec for Sevilla
[05:53] <asac> pitti: no not by default .... but should work right?
[05:53] <Keybuk> pitti: be understood by me
[05:53] <pitti> asac: of course; I was just curious
[05:53] <poningru> working on the 7.04 'feature tour'
[05:53] <pitti> Keybuk: point :)
[05:53] <poningru> https://wiki.ubuntu.com/FeistyFawn/RC
[05:53] <asac> pitti: no we don't ship it ... at least for LAMP
[05:54] <poningru> anyone have any topic suggestions?
[05:54] <Keybuk> pitti: in this company, "I'm shutting my e-mail server down for two weeks to learn a new one from scratch" ain't exactly easy
[05:54] <asac> s/ship/install by default/ of course
[05:54] <poningru> that I can writeup?
[05:54] <pitti> asac: oh, LAMP doesn't install an MTA either?
[05:54] <asac> pitti: no
[05:54] <poningru> pitti: no
[05:54] <pitti> Keybuk: so, mainly hysterical raisins then?
[05:54] <cjwatson> pitti: which of those deltas still exist?
[05:55] <asac> but exim4 worked well for me with smarthost setup ... heaven't tried things like tls et al
[05:55] <Keybuk> pitti: entirely hysterical raisins;  I have a qmail config that's survived for ~7 years, it would take me too long to learn another MTA and work out how to deliver e-mail how I'm used to with that
[05:55] <pitti> cjwatson: ugh, ask me again when we are merging again; I don't remember the particular packages any more, but there are some where this is the only delta
[05:55] <Keybuk> (OR) get used to a new method of delivering e-mail
[05:56] <asac> in fact LAMP doesn't even install an example app
[05:56] <asac> wonder if that is intentional
[05:56] <pitti> cjwatson: mutt is one example
[05:57] <jsgotangco> asac: why should it, a person running ubuntu server is supposed to know how to configure it in the first place right
[05:58] <asac> yeah ... but you could argue the same for lamp things
[05:59] <jsgotangco> a little phpinfo could help but beyond that would need a spec for future release
[06:23] <elmo> is universe frozen yet?
[06:23] <ogra> i dont think so
[06:23] <elmo> anyone know for sure?
[06:24] <crimsun> it's not.
[06:24] <ogra> ajmitch, dholbach, crimsun someone else  ? ^^^
[06:24] <jdong> try uploading a CVS snapshot of ffmpeg and see if it goes through :D
[06:24] <jdong> lol
[06:24] <elmo> crimsun: thanks - when does it freeze?  release?
[06:24] <crimsun> elmo: pretty much.
[06:24] <elmo> crimsun: k, thanks
[06:29] <cjwatson> release minus a bit to let the buildds quiesce
[06:38] <habeeb> Greetings, good gentlemen.
[06:39] <habeeb> I created a thread in the forums, but well, I got no answers so I'll just ask here too. Why is there not a dual-boot auto-partitioner by default?
[06:39] <habeeb> I mean.. it seems like such an easy thing to develop and I bet that it would really help Window to Linux switching.
[06:39] <cjwatson> err ... there is?
[06:39] <cjwatson> "Resize <Windows partition> and use freed space"
[06:40] <cjwatson> it depends on whether automatic resizing is actually possible, which it isn't in all situations, though
[06:40] <habeeb> I see... You know I asked in the other irc room too, and the guys who answered told me about the manual way..
[06:41] <cjwatson> e.g. if you have too many primary partitions already, or not enough free space on a resizable partition, then auto-resize won't be offered
[06:41] <habeeb> I see.
[06:41] <cjwatson> pre-feisty, if you had more than a couple of GB of free disk space, it wouldn't be offered either; in feisty I decided that that was a mistake and removed that check
[06:44] <cjwatson> mdz: do you still have the installation from bug 106971 lying around?
[06:44] <ubotu> Malone bug 106971 in oem-config "Keyboard layout test doesn't seem to work in firstboot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106971
[06:44] <habeeb> And tell me something else... Because it's been some time since I last used Ubuntu. If I, like, download the Feisty release tomorrow or whenever it comes out, will I have Beryl/Compiz by default in my _ATI_ card?
[06:45] <cjwatson> we don't have beryl/compiz by default on anything (yet); we ship System -> Preferences -> Desktop Effects to let you turn it on
[06:45] <cjwatson> depends on the vintage of your ATI card, of course; r500 support isn't in yet
[06:46] <cjwatson> (for example)
[06:46] <habeeb> and that will download/setup the fglrx drivers, and also install Beryl/Compiz?
[06:46] <habeeb> I see...
[06:46] <habeeb> No well, I'm saying that, because last time I used Ubuntu was in the start of the Edgy era, and I remember many many threads on the forums of people unable to setup DRI and their card correctly, and I'm wondering if the problem is fixed.
[06:46] <cjwatson> System -> Administration -> Restricted Drivers Manager for fglrx
[06:46] <habeeb> "problem"
[06:47] <habeeb> Interesting!
[06:47] <habeeb> Also, the kubuntu live-cd installer is the same as the ubuntu one?
[06:47] <cjwatson> same codebase although a different frontend
[06:47] <habeeb> ye..
[06:47] <habeeb> ok
[06:48] <habeeb> and right now, which is the default "desktop effects manager"? compiz or beryl? I think compiz, right?
[06:48] <cjwatson> compiz
[06:49] <cjwatson> I would really suggest #ubuntu+1 for more, though
[06:49] <habeeb> Ye, ye, that was my last question anyway...
[06:49] <habeeb> Thank you very much, sir.
[06:49] <cjwatson> np
[06:56] <pitti> tepsipakki: did you see that the intel driver FTBFSed across the board?
[07:05] <iwj> cjwatson: And finally, I was wondering about your opinion of bug 107042.
[07:05] <ubotu> Malone bug 107042 in debian-installer "expert install produced passwordless root account" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107042
[07:08] <pitti> Mithrandir: http://pastebin.ca/443097 -> ok to upload?
[07:10] <pitti> cjwatson: ^ Mithrandir seems to be afk, can you have a look at it, please? it does not affect the CDs
[07:10] <Mithrandir> no, I'm not afk
[07:11] <Mithrandir> I'm merely not staring at my irc client all the time
[07:11] <Mithrandir> pitti: please upload.
[07:11] <pitti> Mithrandir: oh, sorry, then ubotu lied
[07:11] <pitti> ubuntoid, even
[07:11] <pitti> Mithrandir: thanks
[07:12] <pitti> done
[07:12] <shawarma> ubuntoid?
[07:13] <fabbione> shawarma: bot
[07:13] <shawarma> 19:13 -!- ubuntoid: No such nick/channel
[07:13] <seb128> Mithrandir: could you accept the slab upload? It's broken at the moment due to a gnome-control-center libslab ABI change, the update makes it build staticly with the copy they ship, that's the easier way at the moment, we will clean it up next cycle
[07:14] <Mithrandir> seb128: sure
[07:16] <seb128> Mithrandir: thank you
[07:16] <cjwatson> iwj: could I get /var/log/installer/cdebconf/questions.dat please?
[07:17] <Mithrandir> mvo: I think I'll ask you to put your gnome-app-install upload in for -updates.
[07:18] <mvo> Mithrandir: the changes are pretty trivial, could they be accepted if we have to re-spin the CD and rejected if not maybe?
[07:20] <Mithrandir> mvo: it's not a critical bug so, no, I don't think that is a good idea.
[07:20] <Mithrandir> mvo: about the update-manager crash; how common is this?
[07:20] <mvo> Mithrandir: not very common, the user has to close totem while the codec search starts up to trigger it
[07:21] <mvo> Mithrandir: so yeah, -updates is fine
[07:21] <Mithrandir> uh, the update-manager one is a KDE related thingy so that's probably not related to totem?
[07:21] <cjwatson> iwj: hmm, did you notice that the debconf priority wasn't actually set to low from the start?
[07:21] <Mithrandir> bug 106863
[07:21] <ubotu> Malone bug 106863 in update-manager "[kde]  Upgrade tool crashed" [Medium,Fix committed]  https://launchpad.net/bugs/106863
[07:22] <mvo> Mithrandir: oh, sorry. I was thinking about the crash in g-a-i that got fixed 
[07:22] <mvo> Mithrandir: the kde one seems to be happening more often, I would rather want to see it in
[07:22] <mvo> if at all possible
[07:22] <iwj> cjwatson: No, I didn't.
[07:23] <cjwatson> at least it doesn't seem to have been
[07:23] <cjwatson> Mithrandir: ^-- do you care about that? fix is a one-liner in gfxboot-theme-ubuuntu
[07:23] <cjwatson> gfxboot-theme-ubuntu
[07:23] <cjwatson> -    /dimode.option "DEBCONF_PRIORITY=low" def
[07:23] <cjwatson> +    /dimode.option "priority=low" def
[07:23] <Mithrandir> cjwatson: what does it require a respin of?
[07:23] <cjwatson> syntax changed a while back; I updated everything else but not that :-/
[07:23] <cjwatson> Mithrandir: alternate/server ISOs
[07:24] <iwj> cjwatson: No, you can't have that file.  d-i didn't put it on my usb stick and it doesn't exist in the installed system AFAICT.
[07:24] <iwj> But must go.
[07:24] <cjwatson> mm, ok, I'll have to try reproducing it myself
[07:24] <cjwatson> /var/log/installer/cdebconf/questions.dat should *definitely* be on the installed system
[07:24] <mvo> Mithrandir: it seems to be triggered on a dpkg error, so we may move it into -updates on the ground that dpkg errors are rare (hopefully!)
[07:25] <Mithrandir> mvo: trying to make up my mind.  It's on all the CDs so it'll require a full respin.
[07:25] <iwj> ls: /var/log/installer: [enoent] 
[07:26] <cjwatson> merp, weird
[07:26] <cjwatson> that should never happen
[07:26] <cjwatson> oh but you saved to a USB stick
[07:26] <cjwatson> ok, I'm not familiar with that mode, will look later
[07:28] <mvo> Mithrandir: it affects only kde, it will let Riddell decide
[07:29] <mvo> Mithrandir: I need to run now, hockey
[07:29] <Mithrandir> mvo: see you around.
[07:29] <mvo> bye
[08:04] <vciaglia> guys, firefox on amd64 crashes really a lot of times. To me causes the X restart too! Is there any fix? :/
[08:04] <vciaglia> (i'm using the feisty fawn 7.04-beta)
[08:48] <mako> who fixes planet ubuntu when it, for example, becomes planet mako
[08:49] <cjwatson> wow, you got the full set
[08:49] <kylem> you say that like it's a bad thing
[08:49] <jdong> AAAHHH I SEE MAKO EVERYWHERE :D
[08:50] <_ion> Haha
[08:50] <mako> ALL MAKO ALL THE TIME
[08:50] <mako> i prevented this on planet debian because i can clear the cache
[08:51] <sn0> mako that is a lot of posts O_o
[08:51] <mako> sn0: it's my entire rss feed, in fact
[08:51] <jdong> mako: now all you need is an ALL YOUR BASE post and that'll top it all off :D
[08:52] <sn0> excellent, maybe you can get planet.mako.net forwarded by dns oo planet.ubuntu.com too ;] 
[08:52] <cjwatson> anyway, it's Canonical sysadmin for planet.u.n
[08:52] <cjwatson> u.c
[08:54] <Kmos> someone check this out.. LOL
[08:54] <Kmos> bug 107062
[08:54] <ubotu> Malone bug 107062 in kubuntu-docs "Linux.org is hurting Linux; don't recommend it" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107062
[09:01] <mako> cjwatson: thanks, i sent a mail
[09:01] <mako> the cache file for mako.cc just needs to be deleted or nuked, oh well :)
[09:02] <Kmos> mako: if you change the date of the posts for yesterday they don't appear in the next refresh
[09:03] <mako> Kmos: unfortunately, the dates *are* dated back.. but the feed they are using rss, not atom, so that trick doesn't work
[09:04] <Kmos> mako: you can't change in the atom? <updated>2007-04-10T18:26:08Z</updated>
[09:04] <mako> Kmos: sure i can, and i have, but planet.ubuntu.com isn't look at my atom feed at all
[09:05] <Kmos> strange.
[09:05] <mako> Kmos: it only knows about my rss feed
[09:05] <mako> Kmos: it's not that strange, the feed was added before warty released and i think before i eve had atom support in my blog :)
[09:23] <robertj> jdub: I enjoy the new all-jdub  all-the-time format of planet ubuntu
[09:25] <mako> robertj: that's not jdub, that's me
[09:25] <Treenaks> robertj: that's mako
[09:25] <mako> robertj: but i'm glad you enjoy it
[09:25] <robertj> doh ;)
[09:26] <mako> i've filed a request to have it fixed :)
[09:26] <robertj> got my nicks crossed
[09:26] <jdong> well it's phanatic to the rescue :)
[09:27] <phanatic> jdong: :)
[09:53] <Mithrandir> janimo: system-config-printer> rejected; do it as an SRU.
[09:53] <janimo> Mithrandir: ok
[10:17] <Chriss_> tag
[10:17] <Chriss_> und wie?
[10:17] <Chriss_> fewefwe
[10:17] <Chriss_> fwefwe
[10:17] <Chriss_> kack
[10:18] <bhale> phew.
[11:11] <Arby> cjwatson: bug 99908
[11:11] <ubotu> Malone bug 99908 in ubiquity "The ext3 file system creation in partition #1 of SCSI1 (0,0,0) (sda) failed." [Undecided,Needs info]  https://launchpad.net/bugs/99908
[11:11] <Arby> is it worth me testing manual partitioning
[11:11] <Arby> to see if I can reproduce what jerry reports?
[11:14] <cjwatson> Arby: sure, though as I said it looks like your problem is due to running out of memory and that's not his prroblem
[11:14] <cjwatson> honestly, you need more memory in that box to run ubiquity right now
[11:14] <Arby> I know I know :)
[11:14] <cjwatson> which is a bit annoying as you have 256MB
[11:14] <cjwatson> maybe it's just Kubuntu ...
[11:15] <cjwatson> Xubuntu at least has lower memory requirements and should definitely work, Ubuntu may
[11:15] <cjwatson> there were also definitely CD read errors in some of your syslogs
[11:15] <Arby> it's fine with auto-resize partitioning, it's just erase disk that struggles
[11:15] <cjwatson> I have a feeling that's luck
[11:15] <Arby> Xubuntu is fine, not tried ubuntu in a while
[11:16] <Arby> I must be consistently lucky then :)
[11:16] <cjwatson> I would love to figure out what's really going on, but CD read errors and out-of-memory are showstoppers and I can't get anywhere until those are eliminated
[11:16] <Arby> OK we'll I'll try manual partition on my testbox
[11:16] <Arby> then on a spare partition on my main box
[11:17] <Arby> which has more ram :)
[11:17] <Arby> and a much newer cd drive :)
[11:17] <cjwatson> could just be dirty rather than old
[11:17] <Arby> also possibly true
[11:17] <cjwatson> I've had excellent luck with CD drive cleaners to revitalise drives
[11:17] <Arby> I should get one of those
[11:18] <cjwatson> in gutsy we'll have a version of squashfs that will fail much more abruptly on CD read errors, which will make this kind of thing easier to diagnose
[11:18] <cjwatson> thanks to pkl
[11:19] <Arby> shiny :)
[11:19] <Arby> I'm happy to help out debugging ubiquity if you want me to try stuff.
[11:20] <cjwatson> I'm absolutely keen to investigate if you can reproduce it on a system that has enough memory and isn't thrrowing squashfs errors
[11:21] <Arby> my other laptop has 512MB so that should be enough
[11:21] <cjwatson> one reason I was interested in getting info from Jerry - he has 512MB RAM
[11:21] <cjwatson> that would be lovely
[11:21] <Arby> it also has a spare partition :)
[11:21] <Arby> well it has edgy on it but I can live without that
[11:24] <cjwatson> Arby: if I didn't mention it, btw, that update-dev thing I suggested was a red herring
[11:24] <cjwatson> I forgot that there's a script immediately after the one I had you editing that already calls update-dev
[11:24] <cjwatson> sorry about that
[11:24] <Arby> yes you did say
[11:24] <Arby> np
[11:24] <cjwatson> ok
[11:24] <cjwatson> but that does mean I have no explanation for why the device node isn't appearing, short of a kernel bug
[11:25] <ajmitch> morning
[11:25] <Arby> anything I can do? besides get more ram :)
[11:25] <cjwatson> or an outside chance of libparted lying when it says it's committed the partition table changes
[11:25] <cjwatson> I suppose it might also be possible to kill optional parts of the desktop, if possible - I don't know KDE
[11:26] <Arby> np
[11:27] <cjwatson> working on avoiding the CD read errors would be a good thing to try though - make sure to run the integrity check before booting
[11:27] <cjwatson> it's not cast-iron, but it can help find problems earlier
[11:29] <Arby> I always do
[11:29] <Arby> it always passes
[11:49] <keescook> hiya pitti.
[11:50] <pitti> hi keescook, how are you?
[11:50] <ajmitch> hey keescook 
[11:50] <keescook> pitti: good! mostly done (finally) reviewing all the MOPB stuff with jmm and seanius
[11:50] <keescook> hiya ajmitch!