[00:00] <_cooper_> Hi. [00:02] <_cooper_> I'm about to generate an ubuntu package and found in the PackagingGuide how to name the package. [00:02] <_cooper_> The guide says: [00:02] <_cooper_> "If a Debian package has been changed in Ubuntu, it has ubuntuX (where X is the Ubuntu revision number) appended to the end of the Debian version. So if the Debian hello 2.1.1-1 package was changed by Ubuntu, the version string would be 2.1.1-1ubuntu1. If a package for the application does not exist in Debian, then the Debian revision is 0 (e.g., 2.1.1-0ubuntu1)." [00:03] _cooper_: I think this is more of a #ubuntu-motu question :) [00:03] (when you ask the question, that is :P) [00:05] <_cooper_> 'kay, thanks for the pointer. [00:30] hi there, is jaunty going to have a new theme? has that been decided? [00:32] who's on archive admin duty? [00:32] directhex, https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days [00:33] Riddell, did you just slash the NEW queue to ribbons? [00:33] I think you hit a gap, as it's no longer Tuesday in UTC+0, but it's not yet Wednesday in UTC-6 [00:34] persia, looking for context on a contextless REJECT [00:35] Ah, that's the if uploader == directhex check ... [00:35] * StevenK hides [00:35] StevenK, damn, i thought only the debian cabal had that [00:36] well, they say a true genius is never appreciated in his own time... [00:36] Unfortunately the ubuntu-archive list archive is lagging badly. [00:36] I suspect it's the abovementioned slowness of the list server. I'm not seeing context for REJECTs that I *know* were sent (because I received other copies). [00:36] Yes. I know because I don't see one I sent. [00:37] ... and you were sent a copy of ... [00:37] directhex: Exercise patience, I doubt it was contextless [00:37] And that is 9 hours old. [00:37] Yep. [00:38] StevenK, james_w got the reject message, and was asking ME if i knew context, so unless there's a follow-up lagging someplace === asac_ is now known as asac [01:02] slangasek: what do I need to get an UI freeze exception for bug 328606? :) [01:03] Launchpad bug 328606 in liferea "Liferea shouldn't include actions if notification server doesn't accept them" [Low,Triaged] https://launchpad.net/bugs/328606 [01:13] pochu: how is that a UI freeze exception? [01:13] pochu: you have to get an exception to fix "the UI accidentally broke"? [01:14] Amaranth: don't ask me, I'm the one who thinks it's a bug fix [01:14] but some people seem to disagree [01:15] c === mneptok_ is now known as mneptok [01:36] Amaranth: It's more U/I doesn't work so well because someone changed the rules without much notice. [01:37] Pretty well amounts to the same thing, but there's no accident involved. [01:43] pochu: doesn't look to me like anything that needs a UI exception. [01:43] pochu: who was saying otherwise? [02:00] slangasek: Does U/I freeze actually apply to Universe (or at least the unseeded parts of Universe)? [02:00] Since the docs/translations teams don't (AFAIK) support those packages, I'm not sure what point it would serve. [02:01] ScottK: I don't think it should apply, and wasn't considering it to apply [02:02] Right, I just don't think our docs actually say that. [02:02] (that it doesn't apply) [02:02] * ScottK looks [02:04] slangasek: https://wiki.ubuntu.com/UserInterfaceFreeze includes "all user-visible strings in applications", which one might well think inludes Universe. [02:05] ScottK: I'm happy to have that amended, though perhaps we should check with the doc team (mdke?) first to make sure that's consistent with their expectations [02:06] mdke: Would adding "... which are installed by default" to that cause any issues for you? [02:06] It uses that construction earlier in the page. === rgreening_ is now known as rgreening [04:35] persia: Do you happen to be around now? [04:37] slangasek: Got an install problem with studio disks, testing on amd64 but will likely affect i386 since its arch independant, a weird conflict issue with ubuntustudio-sounds and gnome-audio, working out how to address this, but likely enough a seed addition to blacklist gnome-audio will be enough. [04:42] persia: never mind, worked around it. [04:43] slangasek: If you could respin studio when you get a chance, that would be appreciated, fixed the problem in our seeds, which doesn't require an ubuntustudio-meta upload. [05:09] 666/ [05:12] yikes [05:12] * LaserJock wonders what window TheMuso was heading to :-) [05:14] TheMuso: respinning [05:14] slangasek: thanks [05:15] LaserJock: lol [05:16] LaserJock: The channel which must not be named, of course [05:22] TheMuso: and build done [05:23] slangasek: thanks again. [05:37] TheMuso, just back. You know that germinate doesn't enforce blacklisting for tasks or meta, right? I'm not sure just blacklisting will work without either adding a Provides: to ubuntustudio-sounds, or extending the Recommends for pulseaudio-module-x11 [05:37] persia: well gnome-audio is no longer on the disk so... [05:39] Hrm. Odd. I remember a similar issue with xfce-panel and MID where it kept showing up. Anyway, if it works, it works. [05:39] yeah [06:19] persia: well the seed change I made fixed the problem to the point where the disk is installing. [06:20] Excellent. That's enough for alpha. It's probably worth trying a Desktop -> Studio crossgrade at some point to make sure that still works. I'll see if I can do that this evening. [06:21] ok [07:06] good morning [07:17] ScottK2, slangasek: that sounds like it should be ok although I think we do have some documentation for the occasional universe package which would be affected if UI strings were changed late, From a quick review it's quite rare though [07:17] Good morning [07:51] $ ls -lh /var/log/syslog [07:51] -rw-r----- 1 syslog adm 329M 2009-03-11 02:50 /var/log/syslog [07:51] can we make pulseaudio shutup already? :/ [08:12] Amaranth: can you please file a bug against pulseaudio for that, with some excerpts from the log?} [08:12] and maybe discuss with TheMuso [08:13] yeah, doing that now [08:13] certainly sounds worth fixing [08:13] Mar 10 10:33:32 ronin pulseaudio[3715]: alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally large: 13835058055252444064 bytes (418293347931 ms) Most likely this is a Linux bug. Please report this issue to the ALSA developers. [08:13] oops, didn't mean to paste that here [08:14] well, it's fine, just one line :) [08:14] it's that over and over and I though crimsun uploaded a fix for it already [08:18] ah, it's actually bug 340784 [08:18] Launchpad bug 340784 in pulseaudio "[Jaunty] Pulseaudio fills my logfiles." [Undecided,New] https://launchpad.net/bugs/340784 [08:18] * Amaranth adds a comment === tkamppeter__ is now known as tkamppeter [08:21] looks like this actually may have already been fixed, the messages stopped right around the time I remember pulseaudio dying and having to restart it [08:22] TheMuso: Thank you for making pulseaudio shutup about alsa :) [08:22] or whoever did it [08:22] * Amaranth & [08:23] pitti, there is still a CUPS SRU for Intrepid which you did not put into -proposed [08:25] slomo: are you there? [08:36] seb128: yes [08:39] slomo: see #ubuntu-desktop log ;-) [08:49] tkamppeter: oh, I see; added to my TODO list, thanks for the poke [08:50] pitti, thanks, this is already waiting for 6 weeks. [08:50] ..am I the only one, who needs to give gconf a kick from time to time? [09:03] lool: it didn't so much as drop it [09:03] it was an Ubuntu patch that upstream rejected [09:03] just use -q/--quiet instead, that's fixed now [09:07] mvo: I like the current update-manager version number [09:07] 1:0.100.1, is that really still decimal? :-) [09:08] pitti, that version number sucks. there's only one awesome version number in ubuntu, and it's 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2 [09:09] mvo: will the next version be 1:0.101.0? [09:09] directhex: yeah, "how to encode the changelog into a version number" [09:09] slangasek: is now still a good time to do uploads? ;-) [09:09] AKA "epochs hurt" [09:10] I hope they don't change their mind again, it can be hard to manage 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2+reallyreally9.0.120.0ubuntu1 [09:13] * pitti eyes at stgraber .. MirrorKit.. [09:19] pitti: I like it too and your idea as well, I think I will switch to this schema [09:25] Keybuk: Problem is that it breaks packages which used that [09:25] Keybuk: Like powernowd -- which is still installed on most systems [09:25] lool: powernowd isn't seeded anymore? [09:25] you just need to merge the seeds [09:26] I have "remove powernowd from the archive" on my todo list [09:26] Keybuk: It's not seeded but it remains installed on upgrades... [09:26] lool: didn't you use update-manager? :p [09:26] also the modules powernowd tries to load are all compiled into the kernel now [09:26] Keybuk: Would update-manager have removed it? [09:26] lool: should have done [09:27] I used aptitude [09:27] I've been grepping the archive to make sure nothing uses -Q [09:27] only a few ubuntu-specific things did [09:27] Ok, and these are fixed but you missed powernowd? [09:29] I deliberately ignored powernowd, since it's going away ;) [09:29] Keybuk: Did you also use the occasion to grep for /sbin/lsmod. [09:29] lool: no, that one's a simple packaging error [09:30] Keybuk: powernowd and acpid -- which we want to get rid off too -- are using it [09:30] it should be in /bin [09:30] Keybuk: Some programs hardcode it [09:30] lool: I couldn't find any reference to modprobe in acpid? [09:30] Keybuk: /sbin/lsmod [09:30] oh [09:30] like I said [09:30] that's just a packaging error [09:30] lsmod's always been in /bin in Debian/Ubuntu [09:30] I hadn't noticed it was in sbin upstream [09:31] Keybuk: The other way around I think [09:31] ? [09:31] I think it was moved intentionally in Debian since /sbin isn't on the default path there [09:31] Keybuk: What I'm saying is that packages are hardcoding /sbin/lsmod and they break with the move [09:31] We want to get rid of acpi? [09:31] acpid, I mean? [09:31] but in any case packages should not hardcode the paths to executables [09:31] soren: Yes, do you need it? [09:31] lool: Err.. yes? [09:31] lool: yes [09:31] lool: and I'm saying the move was an accident [09:31] lool: and I've already got a package to fix that [09:31] Keybuk: Oh it's an accident in the last upload which you'll revert [09:32] like I said [09:32] that's just a packaging error [09:32] ;) [09:32] lool: Unless you've got something else that will shut down my system when it receives and acpi shutdown event? [09:32] Keybuk: I thought it was an ancient packaging error which you corrected in the last upload [09:32] oh, no ;) [09:32] soren: Well on the desktop we have hal-hooked-up stuff [09:32] lool: Good for you :) [09:33] * mvo is deeply anoyed by pycentral telling him there is no Python-Versions field in the package when there clerly is one [09:33] Keybuk: Ok, good too hear lsmod will move back after A6 then, [09:33] lool: I decided to go with a symlink [09:34] on the basis that since /sbin/lsmod is the upstream locations, other things might be hard-coding that [09:34] Keybuk: That's what I'd have suggested too [09:34] lool: Oh, so by "get rid of" you just mean "stop seeding on the desktop"? [09:35] lool: Not as in "removing from the archive", which seems to be what Keybuk meant wrt. powernowd. [09:35] soren: Actually yes, after discussing it with you I remembered it's only for desktops that it was question of droppin git [09:35] lool: I have that backwards, don't I :) [09:35] /sbin/lsmod is the traditional Debian/Ubuntu location [09:35] /lib/udev/rules.d/85-regulatory.rules:KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/sbin/" [09:35] but /bin/lsmod is the upstream location [09:35] hmpf :-( [09:36] lool: Ok, no worries then :) [09:36] lool: ? [09:36] lool: be careful what you write -"droppin git" will cause you many enemies in the kernel team :-p [09:37] soren: I'm actually happy that we'll keep it somewhere cause I spent some time cleaning it up and was sad that this was being dropped and hence my work wouldn't be that useful :-) [09:37] amitk: Yeah, I almost wrote a joke about git after it [09:38] bryce: So 60x11-localhost broke login for me [09:38] bryce: startx returns me to the console; if I move the file away it doesn't anymore [09:38] lool: :) [09:38] lool: update to u15 [09:38] wel [09:38] bryce: Ok, sorry and thanks [09:39] why don't we just run gnome-power-manager on servers? [09:39] lool: we're not affected by git jokes, we just point to bzr vs. speed :) [09:39] or a headless equivalent? [09:39] lool: no prob, we can blame redhat (bashism vs. dashism) [09:39] Keybuk: There was no headless equivalent until recently; devicekitpower might change that though [09:39] lool: DK-power only replaces the HAL bit [09:39] you need a policy agent to make the decisions [09:40] could someone with knowledge about initramfs-tools please review my patch for #338563 ? [09:40] mvo: looks sensible [09:41] thanks Keybuk [09:43] night [09:44] bryce: morning [09:48] Guys I just completed a 64bit Ubuntu install from netboot mini.iso and am greeted with a nice little window that says.... Kerneloops-ui Your system had a kernel failure [09:51] Archive admins: python-protobuf disappeared from the archive: it used to be in universe and was being promoted to main, then disappeared [09:52] I don't see it in rmadison in jaunty anymore [09:53] slangasek: I think the dx team thought they needed UI freeze exceptions, but I may be wrong [09:54] slangasek: at least they tagged the bugs with 'uif-jaunty' === mdz_ is now known as mdz === ScottK2 is now known as ScottK [10:10] Any Python expert here? It is about bugs like bug 335543, a Python app does not find a certain Python library (saying "ImportError in ()") but the library is installed. Reinstalling the library helps. This does not only happen to Jockey but also to hal_lpadmin, the system-config-printer tray applet, ... What is the problem here? [10:10] Launchpad bug 335543 in jockey "jockey-gtk crashed with ImportError in ()" [Undecided,New] https://launchpad.net/bugs/335543 [10:13] tkamppeter: it's probably not transitioned for Python 2.6, a rebuild could fix it. [10:15] tkamppeter: I mean x-kit [10:18] DktrKranz: In the mentioned case a reinstall of the existing library package even helps (no rebuild of the package). Can it be that the postinstall scripts of all Python libraries need to get re-run after Python 2.6 installation? This should be automated in the update process. [10:19] mvo is looking to similar issues [10:19] tkamppeter: it looks like bug(s) in python-central [10:20] tkamppeter: seb128 has a similar issue with bzrtools [10:20] tkamppeter: python-central has some links, probably new python version modified them a bit, so it can't find Python module anymore until a new installation is performed. [10:21] I got things screwed after cleaning python2.4 yesterday [10:25] mvo, DktrKranz, perhaps you should move bug 335543 to python-central then. [10:25] Launchpad bug 335543 in jockey "jockey-gtk crashed with ImportError in ()" [Undecided,New] https://launchpad.net/bugs/335543 [10:30] ara: are the "move files around" changes in ldtp in debian already? [10:30] slangasek: for planning, gnome-themes-ubuntu_0.1_all.deb (which we need to add) is 279 kB [10:31] dholbach: no, but I talked with the debian maintainer and he's going to accept the changes [10:31] slangasek: that's about the size I recently removed from gnome-themes, so I don't need to have a too bad conscience === jussio1 is now known as jussi01 [10:32] ara: is that going to be part of 1.5.1-1? [10:32] the thing is: if files move from one package to the other, we need a conflicts/replaces (<< old version) - if we want syncability it'd be nice if we'd have the same versions in the conflicts/replaces [10:34] dholbach: I wanted to mention that I think your idea about more, short MOTU training sessions is a good one. [10:35] ScottK: excellent - I was planning to wait a bit longer until everybody had read the proposal and then send a mail to all the people who said "sounds good - count me in" to get planning [10:36] dholbach: Please note there was a distinct lack of 'count me in'. My Ubuntu time is getting somewhat more limited, so I really can't take on new tasks currently. [10:36] ScottK: that's completely fine :) [10:37] I was happy with the feedback I got on the blog post - sounds like this is a more sustainable model. :) [10:37] dholbach: then, you could accept michael's debdiff, that does not include that change, I will send my changes to debian instead. those are not as urgent, but the new upstream version is :) [10:38] dholbach: the only change i do not agree with michael is that he changed site-packages to dist-packages, I would put *-packages, as ldtp can work with python2.5 as well [10:39] ara: OK, if Kartik makes those changes in 1.5.1-1 and uses a Conflicts/Replaces: ldtp (<< 1.5.1-1) I guess we should be fine with our changes in 1.5.1-0ubuntu1 [10:40] ara: I personally am fine with both, you decide [10:42] dholbach: OK, then you can go ahead, as he already accepted the changes (informally). thanks for your help :) [10:44] ara: hum... does he have that package available somewhere? it'd be nice if we could just sync it instead of me guessing and hoping that the changes are going to be equivalent. my concern is the versioned conflicts/replaces - if we pick different version numbers there, we'll have to maintain that diff for another few releases [10:46] dholbach: :-) then, again, just use the michael's version, really (with the python2*/*-packages changes...) [10:46] dholbach: really, the other changes are not that urgent [10:46] dholbach: we can wait for debian [10:47] ara: can you please talk to Kartik and make sure that he uses (<< 1.5.1-1) in the conflicts/replaces? :-) [10:47] dholbach: if they are not in jaunty... that's not a problem [10:47] dholbach: sure, will do :) [10:47] ara: gracias [10:47] dholbach: danke to you :D [10:47] mvo: hm, the task <-> assignee mapping in bug 35876 looks backwards to me [10:47] Launchpad bug 35876 in update-manager "'Downloading package information' and 'building dependency tree' progress dialogs request focus too often" [Low,Confirmed] https://launchpad.net/bugs/35876 [10:49] ara: de nada :) [10:49] mvo: realistically I don't think we'll be able to generally fix this in metacity; I just corrected the upstream bug link for metacity [10:49] mvo: for a local solution, do you think the progress window should just never receive focus? or at least focus_on_map false or so? [10:57] ara: done [10:58] dholbach: danke! [11:01] pitti: can we promote icedtea-6-jre-cacao to main? I'd like to have it for arm and powerpc. [11:02] infinity: hi, do you know how often the chroots are cleaned up on buildd? [11:12] doko: sure; done [11:12] pitti: thanks [11:12] doko: btw, is the cacao source still relevant with this? [11:13] doko: it's already in main [11:13] (icedtea-6-jre-cacao I mean) [11:13] pitti: no, not exactly, because openjdk has a copy of the cacao source again (cacao is still in universe) [11:13] doko: right, I meant if the cacao-oj6 is now redundant and should be removed [11:13] pitti: but now we can remove the cacao-oj6 package [11:14] doko: lp-remove-package.py -u pitti -m 'cacao now built from openjdk-6 source' cacao-oj6 [11:14] doko: does that sound correct? [11:14] doko: as a rationale? [11:15] pitti: sounds ok [11:15] * pitti makes a flushing noise [11:17] tkamppeter: it doesn't make sense to refer to a discussion on irc without including or summarizing it ... [11:22] doko, added. [11:27] bigon: how do you mean "cleaned up"? the chroot is freshly unpacked from a clean tarball every build, and dist-upgraded. the tarball is freshened "from time to time" (manually) [11:28] lamont: he's asking about the latter, because python2.5-minimal is still there and can go away now [11:28] a dist-upgrade won't do that [11:28] cjwatson: right [11:28] tkamppeter: why should it be a python-central error, if the usb module cannot be imported, which is managed by python-support? [11:29] DktrKranz: ^^^ [11:29] mvo: ^^^ [11:30] doko: speaking about python error apt-get autoremove cleaning python2.4 yesterday on my install and since bzrtools is broken [11:30] doko: ie [11:30] LC_ALL=C ls /usr/lib/python2.6/dist-packages/bzrlib/plugins/bzr* [11:30] ls: cannot access /usr/lib/python2.6/dist-packages/bzrlib/plugins/bzr*: No such file or directory [11:31] seb128: bug report? [11:31] doko: pitti: python-protobuf seems to have disappeared from Jaunty. Could this be related to the MIR for protobuf that got promoted yesterday? [11:31] doko, see IRC discussion, bug 335543 [11:31] Launchpad bug 335543 in python-central "jockey-gtk crashed with ImportError in ()" [Undecided,New] https://launchpad.net/bugs/335543 [11:32] doko: what would be useful as extra infos in a bug report? [11:32] doko: I think mvo was investigating but I will open a bug if he doesn't [11:32] I've filed an RT ticket to have the buildd chroots refreshed, at lamont's suggestion [11:32] lamont: well there are some package left behind (like python2.5-minimal) that make some pkg FTBFS [11:36] tkamppeter: what does this have to do with 291035? [11:37] doko: I was refering to the problems that tkamppeter described and a issues that seb128 had with bzrtools. I don't know about usb modules [11:38] bug 291035 is also an ImportError which was reported recently (not very well done by the reporter, he hijacked an old, closed bug) and is also an ImportError, looks like his problem was also triggered by Python 2.6. [11:38] Launchpad bug 291035 in python-central "hal_lpadmin crashed with ImportError in ()" [Undecided,Incomplete] https://launchpad.net/bugs/291035 [11:39] It has nothing to do with hal-cups-utils (the package correctly requires python-usb) and also not with the case that python-usb is a USB library. [11:42] bigon: if packages break with it, they probably ought to use Build-Conflicts? [11:43] cjwatson: actually the pkg will ftbfs with all python*-minimal as it need the std lib [11:43] and the minimal doesn't provide that [11:44] bigon: err, surely that means that it needs to build-depend on the appropriate extra packages, not that -minimal breaks it [11:44] sounds like your package is just broken [11:47] cjwatson: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474053 << actually it's that problem [11:47] Debian bug 474053 in python2.5-minimal "python2.5-minimal: looks like Python 2.5, but isn't" [Normal,Open] [11:48] bigon: but that bug does not affect build-dependencies. You should build-depend on what you need [11:49] that bug is about where the executable is located (and is a bit debatable anyway; I would be inclined to say that we should not change that in Ubuntu, although it's up to doko) and that cannot possibly affect build-dependencies [11:50] the thing it's that the configure takes the smaller version of python, py2.6 is actually pulled but like py2.5 from python minimal is already there it takes that one [11:52] bigon: renaming doesn't make much sense. both are pulled, because the -minimal packages recommend the "complete" one [11:53] seb128: I think I fixed the bootchart bug [11:53] at least, it's far more reliable for me now [11:55] seb128, hey there [11:56] seb128, today is actually allocated to squash some bugs on notify-osd :) [11:56] seb128, I'll see how much I can fix [11:57] MacSlow: crashers first! [11:57] :-) [11:57] dholbach, I know :) [11:57] bigon: "takes the least version of python" seems like a rather odd thing to do ... [12:03] I don't know why it's done like that.. [12:03] pitti: looking at the bug now [12:04] doko: recommended pkg are not pulled on buildd [12:05] bigon: is python2.5-minimal still installed on the buildd? [12:05] doko: yep [12:06] infinity: ^^^ could this be fixed/removed please? [12:07] doko: I filed an RT ticket for this already [12:07] ok, thanks [12:08] cjwatson: do you have the url of that ticket? [12:08] the relevant RT system is internal so it won't help you [12:09] I'll let you know when it's done [12:09] ok thx [12:11] Keybuk, is it normal that i dont have any hwclock initscripts at all anymore ? (i still think the babbage passwd thing is related to clock issues, especially since my hwclock is at 01-01-1970) [12:16] ogra: the kernel is supposed to sync the system clock from the hardware clock itself nowadays. If this isn't working here, that could well be the sort of thing that's quite architecture-specific [12:16] right [12:16] ogra: though if the hardware clock is wrong, then the hwclock init scripts wouldn't have made any difference anyway :) [12:16] and i see on my x86 laptop that pw expiry is set to 13979 [12:16] days [12:17] is it possible that you have multiple rtc devices, only some of which actually work? [12:17] ogra: my hardware clock looks generally right to me [12:17] no, only one and that works if i call hwclock manually [12:17] ogra: run /sbin/hwclock --show [12:17] Keybuk, i ran sudo hwclock [12:17] and now ran sudo hwclock --systohc and rebooted [12:18] which makes everything function correctly [12:18] i have ttys [12:18] the kernel's supposed to sync it on shutdown too ... [12:18] cjwatson: no it's not [12:18] and it depends [12:18] do I misremember? [12:18] ok [12:18] from where would it sync it [12:18] there was an init script on shutdown to do that [12:18] i.e. if i dont have network attached ... [12:19] it wouldnt getr a correct time at all [12:19] well, the obvious answer is "the system clock". but if I've misremembered and it doesn't, then the question is moot. [12:19] hah [12:20] in any case 13979 days from 01 01 1970 definately is expired :) [12:20] presence of the network is a red herring here; that is only relevant for setting the system clock, usually rather later [12:20] right [12:20] system clock set from hardware clock on power on [12:20] system clock set from network on ifup [12:20] hardware clock set from system clock on shutdown [12:20] except I note that the init script is missing here ;) [12:20] but if the system clock is set from the network relative to a completely broken hardware clock, that would certainly break stuff first time round [12:20] right, but if you need a correct time on first boot and the board only has 01 01 1970 in the hwclock [12:20] where would a correct time come from without net [12:21] so does this mean network -> system clock needs to adjust password expiry too? [12:21] * cjwatson vomits [12:21] ogra: where would a correct time come from at all? [12:21] cjwatson: I don't see what this has to do with password expiry? [12:21] Keybuk: ok, I think this is the sequence of events [12:22] 1) system boots; hardware clock says 1970 so system clock is initialised to that [12:22] Keybuk, if your clock is at 01 01 1970 ... the default expiry value in /etc/shadow seems to be 13979 [12:22] 2) casper runs in the initramfs, and among other things it runs adduser and sets some kind of default expiry time [12:22] 13979/365=38 years [12:22] 3) network comes up and ntp runs [12:22] which means its expired :) [12:23] ogra: I have 99999 in my expiry field [12:23] wrong field ? := [12:23] :) [12:23] no... [12:23] ubuntu:...:0:0:99999:7::: [12:23] * ogra thought it was the second field [12:23] second field is days *before* password may be changed [12:24] third field is days *after which* password must be changed [12:24] days since Jan 1, 1970 that password was last changed [12:24] fields after that [12:24] ie. username = ubuntu, pass = ..., last changed = 0, may be changed = 0, must be changed = 99999 [12:25] 99999 days == ~ 27 years [12:25] yeah [12:25] cjwatson: 273 years [12:25] oh [12:25] so while we will be bitten by this bug, I'm not going to worry about it too much ;) [12:25] Keybuk: one of us can't divide [12:25] I'll leave a note about it in my will [12:25] 99999/365 [12:25] 27.39452054794520547945 [12:25] cjwatson: math 101, if you have ~100,000 and your dividing by order of 100-1000 your answer is going to be >100 and <1000 [12:26] so it's you :p [12:26] 99999/365 [12:26] 273 [12:26] Keybuk, is right [12:26] oh, grr [12:26] my system is under load and there was a leading 9 to bc's input as a result [12:26] which showed up rather earlier so I didn't notice ... [12:27] fair point on maths 101 :) [12:27] anyway, setting the hwclock manually solves my tty prob and gives me a different /etc/shadow [12:27] so I agree that this problem looks like it's caused by the system clock being 1970 when adduser is run [12:27] In that case, the result should have been 2739. :-P [12:27] but I don't see why login is behaving that way at all [12:27] the password still should not be expired [12:27] if it was set in 1970, and is not due to expire until 2243 ... [12:29] well, so we might hit a bug somewhere ... all i can say that a proper clock fixes all issues [12:30] if (spent->sp_lstchg == 0) { [12:30] D(("need a new password")); [12:30] *daysleft = 0; [12:30] return PAM_NEW_AUTHTOK_REQD; [12:30] } [12:30] hah [12:30] hah [12:30] hah [12:30] someone special-cased 0 to mean "must change immediately" [12:30] OH !!! and on a sidenote a fixed clock fixes https://bugs.launchpad.net/gnome-keyring/+bug/328167 [12:30] Ubuntu bug 328167 in gnome-keyring "gnome-keyring-daemon eating 100% CPU at login in Jaunty" [Medium,Triaged] [12:30] seb128, ^^^^ [12:31] ogra: does the hardware clock keep time over a power off? [12:31] apparently, yes [12:31] it did for me right now [12:31]