=== nisshh_linux is now known as nisshh === nisshh is now known as Guest76709 === Guest76709 is now known as nisshh === asac_ is now known as asac === almaisan-away is now known as al-maisan [08:47] Good morning [08:48] Guten Morgen pitti, how are you? [08:49] I'm great, thanks! Slept quite long :/ [08:49] pitti: it means that you needed it :) [08:54] didrocks: an old friend of mine visited me yesterday, and we talked until 0:30 [08:54] pitti: ok, that explains it then! [08:54] * didrocks asked for a rebuild of libcompizconfig at 0:30 yesterday :) [08:55] morning [08:55] (epic battle with cmake which decides "ohhh no glib-2.0.pc"? Let's give it a chance… But I'll forget all the other CFLAGS just for you!) [08:56] didrocks: with autotools you wouldn't have this problem! ;) [08:56] good morning [08:56] I scratches my head to see why -I beetwen the first and second build (without any change) disappeared [08:56] hey rodrigo_ [08:56] hey rodrigo_ :) [08:56] kklimonda: I know, tell that to upstream :) [08:57] oh, nice - I've just somehow managed to link my application against both gtk+ 2.0 and 3.0.. [08:58] kklimonda, heh, and no crashes? [08:58] rodrigo_: it didn't even start ;) [08:58] :) [08:58] it prints a nice error message and quits.. === Nafallo_ is now known as Nafallo [09:47] pitti: did you try to enable "gnomecompat" extension in ccsm? [09:47] pitti: just to know if it pulls all your shortcuts :) [09:47] didrocks: should I? I never really used ccsm or changed compiz effects/plugins [09:47] pitti: I'll change the default if you confirm it works [09:48] didrocks: is that the simple-ccsm package? [09:48] or compizconfig-settings-manager? [09:49] pitti: no, compizconfig-settings-manager [09:49] didrocks: do I need to run compiz while using ccsm? [09:49] simple-ccsm, we should maybe remove it, it's not ported to 0.9, will see [09:49] pitti: no, you don't need to [09:49] didrocks: say the word, and I'll kill it :) [09:50] pitti: let's wait for next week (unity release unity release unity release…) so that I can search over the compiz forum to see if something is working on porting it [09:50] ok, activated, starting compiz [09:51] (alt + F2 at least, should work) [09:51] didrocks: Alt+F2 works again, but none of the others, like ctrl+alt+2 to switch workspaces, or Ctrl+Alt+T for terminal [09:51] pitti: ok, that was my gut feeling [09:51] ctrl + alt + T? [09:51] it's working there [09:52] oh no, it's not [09:52] * didrocks shouldn't fallback to metacity because of nvidia :) [10:04] hey didrocks - i noticed you work on the gsetting conversion for update-notifier, is there a eta? I want to do a upload soonish and it would be nice to coordindate [10:06] mvo: I think I'll have some time next week to work on that, is that ok with you (like eta eow)? [10:06] mvo: sorry, but compiz + unity delayed a lot my others tasks :) [10:06] didrocks: no worries, just wanted to ensure that we don't stomp each others foots [10:06] didrocks: again, no problem :) [10:07] didrocks: I have some vague memories that compiz can do this to people ;) [10:07] * mvo hugs didrocks [10:07] * didrocks hugs mvo [10:07] mvo: after that, you're never the same, isn't it? :) [10:08] hey mvo, good morning; feeling better? [10:11] pitti: yeah, I got some medicine now (the paper says a sideeffect of taking it might be euphoria - I look forward to this ;) [10:12] lol [10:12] mvo: take care :) [10:15] thanks didrocks [10:31] bl8: ping ping === al-maisan is now known as almaisan-away === MacSlow is now known as MacSlow|lunch [11:39] yerterday I've added ubuntu-desktop ppa to my sources.list and after that compiz started giving me some headaches I have not expected [11:40] now I've been trying to triage all the packages installed, so that I can go back to my old configuration, but I couldn't manage it yet =( [11:41] I already have the "old" compiz, compiz-core, compiz-fusion-pligins-main and compiz-fusion-plugins-extra [11:42] but I just can't figure out which other packages I have to reinstall =( [11:43] panaggio: look at https://launchpad.net/~ubuntu-desktop/+archive/ppa/+packages if you click on the package arrows, you will see the binary package list [11:43] panaggio: and keep in mind that ppa are not officially supported :) [11:44] I know :) I just like to test things and report bugs when possible [11:45] panaggio: did you report bugs on compiz? [11:45] but my desktop got kinda useless after I've tried to get things right =( [11:45] panaggio: I see that the ppa is working for some people :) [11:45] weird [11:45] not yet [11:46] I broke everything in here. That's not ppa's fault =P [11:46] panaggio: oh ok [11:53] it seems I've missed libdecoration. Restarting to see if it was just this one [11:55] omg. It wasn't even necessary :D [11:55] good morning crowd! [11:58] hey didrocks, were you able to take a look to the new package I linked yesterday? [11:59] nessita: I don't have access to your branch [11:59] nessita: hey :) [11:59] didrocks: oh [12:00] didrocks: how can I make it public? [12:00] nessita: I have no idea about how launchpad is dealing with private branch TBH [12:00] nessita: maybe ask on #launchpad ? [12:01] right [12:02] didrocks: thanks for the help! :) [12:02] panaggio: yw :) === MacSlow|lunch is now known as MacSlow [12:08] didrocks: I'm not getting any answer yet, so in the mean time I'll push to lp:~nataliabidart/+junk/ubuntuone-control-panel_natty-release [12:12] didrocks: can you access that one? [12:13] nessita: yes, I can access that one. I will do the review once we push unity to the ppa [12:13] nessita: but it can take more time than expected, so maybe Monday at the latest :) [12:13] sorry for the delay [12:13] didrocks: no rush, I need to run some errands [12:13] didrocks: thanks a lot! [12:13] nessita: you're welcome! [12:22] no seb128 today? [12:28] chrisccoulson: nothing on the holiday calendar - perhaps a yet unapproved swap day [12:30] pitti - ah, ok. i'm having a bit of difficulty with my nearly-gconf-free firefox, and i think it's because of shared-mime-info [12:36] pitti, if seb128 is out, could you mayhaps upload https://code.launchpad.net/~mterry/launchpad-integration/gtk3/+merge/40486 for me? [12:37] rodrigo_, I looked at libsocial and the .27 tarball has gtk-doc.make in the toplevel. Are you working from git? [12:37] mterry, no, a tarball, but I took the package from universe, which was getting the code from git, so maybe I left something [12:38] rodrigo_, http://ftp.gnome.org/pub/GNOME/sources/libsocialweb/0.25/ -- has gtk-doc.make in it [12:38] mterry, yes [12:38] mterry, can you have a look at the debian/rules, to see if there's some get-from-git leftover? [12:39] * mterry looks [12:40] rodrigo_, there's certainly a get-orig-source target in the universe debian/rules... [12:41] mterry, yes, I removed that [12:42] rodrigo_, and your tarball has gtk-doc.make in it? [12:42] hmm, I think so, got it from http://ftp.gnome.org/pub/GNOME/sources/libsocialweb/0.25/, but let me recheck [12:43] pitti: he is having a swap day, right [12:43] mterry, yes, it does [12:43] rodrigo_, so something is deleting it? (unless it's in the toplevel and you're *still* getting the error) [12:44] rodrigo_, if it's been deleted, I'd start over with a fresh untarring and copy the debian directory over [12:44] ok === zyga is now known as zyga-food [12:48] mterry, hmm, in fact, build-area/libsocial...../ also has no configure, so dh_auto_clean is removing them? [12:49] rodrigo_, possibly, but if you're starting from a tarball, you actually probably don't need to autoreconf, do you? was there a specific reason to do so (i know you had to when it was a git tarball...) [12:50] mterry, no, just because the configure was removed, it seems by dh_auto_clean [12:50] ok, so I'll clean all those rules [12:51] rodrigo_, dh_auto_clean may have cleaned it via dh_autoreconf_clean if you had that rule going [12:51] possibly, yes === didrocks1 is now known as didrocks [12:55] mterry, ah, there's a debian/clean file, listing all stuff to clean [12:56] rodrigo_, oh! Huh. [12:56] rodrigo_, including gtk-doc.make :) [12:57] rodrigo_, that whole file can be dropped. It's a manual version of dh_autoreconf_clean (which you aren't even using now) [12:57] ok [12:58] mterry, ok, but there's still a patch that touches configure.ac, so what should I do? [12:58] rodrigo_, oh there is? then use dh-autoreconf [12:58] rodrigo_, but you still don't want that debian/clean file [12:58] in which rule? [12:59] rodrigo_, you converted it to dh7, right? then use dh --with autoreconf $@ in the main rule [12:59] yeah, removed debian/clean [12:59] ok [13:00] aclocal: couldn't open directory `m4': No such file or directory === almaisan-away is now known as al-maisan [13:03] mterry, without the --with asutoreconf it works [13:03] rodrigo_, guh, bad upstream package [13:03] rodrigo_, is the configure.ac patch intrusive? It could just patch configure directly if it's a small change [13:04] hmm, yeah, it would probably expand to a lot of code in configure that you'd have to add in. not impossible, but less clean [13:05] not much -> http://pastebin.ubuntu.com/530682/ [13:05] but yeah, it expands to a lot of code [13:07] rodrigo_, what if... you put the following near the top of debian/rules: [13:07] export ACLOCAL = true [13:07] to skip it... [13:07] ok, trying [13:08] it complains about the invalid argument the patch adds [13:08] ok, what I'm going to do is to prepare the patch for upstream [13:09] rodrigo_, invalid argument? [13:09] yes, the patch adds a new configure argument, and debian/rules uses it, so ./confiogure complains about it not being valid [13:10] rodrigo_, interesting. so sounds like configure didn't get regenerated... [13:10] yes [13:10] I wouldn't think ACLOCAL would skip that [13:12] rodrigo_, i wonder if you couldn't just 'mkdir m4' in debian/rules [13:12] rodrigo_, if it's a simple error-check for the existence of the directory [13:13] like in override_dh_auto_configure or something [13:14] no, same thing [13:14] but I'm looking at the patch, and really not sure we need it [13:14] it says m4 directory doesn't exist? [13:14] mterry, no, wrong argument to configure [13:14] (you should get rid of the ACLOCAL = true bit) [13:15] that was just to skip aclocal, but hopefully the m4 directory existing will also let aclocal continue [13:15] yes, done [13:15] all works if I enable the ./autogen.sh bit [13:15] pitti: do you have some time for a puzzling build issue? === zyga-food is now known as zyga [13:17] rodrigo_, dh-autoreconf wasn't enough? [13:17] hmm [13:17] rodrigo_, because their tarball doesn't even have an autogen.sh [13:18] didrocks: re; what's up? [13:18] pitti: njpatel and I are fighting for quite some time on the FTBFS on Nux in the ppa [13:18] pitti: http://launchpadlibrarian.net/59036593/buildlog_ubuntu-natty-i386.nux_0.9.2-0ubuntu1_FAILEDTOBUILD.txt.gz [13:19] (look for re/NSystemGNU.h:37:18: fatal error: glib.h: No such file or directory) [13:19] pitti: obviously, it misses -I/usr/lib/glib-2.0/include [13:19] didrocks: because of the missing -Is? [13:19] right [13:19] however NuxGraphics/Makefile.am has the right cflags [13:20] and it's working fine locally [13:20] hm, nux doesn't even seem to exist, is that a PPA? [13:20] also, libglib*-dev is included as you can see in the previous lines [13:20] pitti: yeah, it's a new toolkit for unity [13:20] pitti: lp:~unity-team/nux/packaging [13:20] pitti: I checked on the local build, and I have the -I… njpatel too [13:21] (NUX_GRAPHICS_CFLAGS is the flag you are looking for) [13:21] and in PKG_CHECK_MODULES, it has glib-2.0 [13:24] didrocks: did you check building the actually uploaded source, or just from the branch? [13:24] pitti: I tried dpkg-source -x .dsc and build it, right [13:24] and it worked as well :/ [13:25] building here; for some reason it ignores -j4 [13:26] weird… I don't think last time I checked the source there was something for that [13:26] can I install Compiz on Unity now? :P [13:27] Sir_Konrad: will depend when we get nux building, see ^ [13:27] didrocks, the topic? [13:28] didrocks: the Makefile.am looks a bit strange to me, but I'll let this build first [13:28] Sir_Konrad: no, I ignore the join/quit, so not sure if you followed the conversation [13:28] libnux_graphics_@NUX_API_VERSION@_la_SOURCES = \ [13:28] didrocks, yeah I just joined about 15 seconds ago. [13:28] $(source_cpp) \ [13:28] $(source_h) [13:28] ah, I missed that one [13:29] didrocks: hm, indeed it builds fine here as well [13:30] pitti: and we are building a .ccp, so it's not an issue with CPPFLAGS [13:30] pitti: I've updated and tried to build as well (even if I didn't see anything which can be interfering from yesterday) [13:30] and it built :/ [13:31] pitti: you tried the package as well, not the bzr branch? [13:31] didrocks: building from branch [13:31] I don't know where the .dsc is :) [13:31] pitti: ok, but in any case, I still have the terminal opened with the build from .dsc [13:31] can still have a try to confirm I'm not crazy (or just a little bit) [13:32] ok, even erasing my dsc there and taking them from the ppa :) [13:32] let's ensure I get everything like the ppa [13:33] ./NuxGraphics/Makefile:NUX_GRAPHICS_CFLAGS = -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 [13:33] looks fine to me [13:33] yeah, that's what I checked too :/ [13:33] didrocks: did you try rebuilding this? [13:33] pitti: "this"? [13:33] just to rule out a silly glitch somewhere? [13:33] didrocks: the PPA build [13:34] pitti: yeah, I tried 20 minutes ago [13:34] pitti: first build was at 11AM [13:34] and it failed in both i386 and amd64 [13:34] I just try rebuilding on i386 though, but well… [13:34] didrocks: hm, perhaps a pbuilder is in order then [13:34] for reproducing the issue [13:34] it's obviously not helpful to stare at local Makefiles which work [13:34] my pbuilder was broken the other day, but I can see if pbuilder update works today [13:35] I see no autoreconfiscation in the log [13:35] no, we don't do that :) [13:36] most of the time, I patch upstream and make a new tarball, much easier and less error-prone [13:36] (for unity & co) [13:36] and the MAINTAINER_CFLAGS are present as well, so it's not a shortcut in the substitution [13:36] $(NUX_GRAPHICS_CFLAGS) is just empty [13:36] didrocks: right, but sometimes it happens when you have weird time stamps, and you b-dep on autotools-dev [13:36] waiting the end of the local build with .dsc and *tar redowloaded and then… will try pbuilder [13:37] pitti: oh right, but I think I tweaked MAINTAINER_CFLAGS to do the right thing there [13:40] didrocks: configure.ac has PKG_CHECK_MODULES ... xxf86vm [13:40] didrocks: but /usr/lib/pkgconfig/xxf86vm.pc has Name: Xxf86vm [13:41] I suppose that's not the reason? [13:41] pitti: hum, maybe that can infer to it [13:41] pitti: do you remembered I blame CMake this morning? [13:41] blamed* [13:41] no, I didn't see that [13:42] didrocks: configure.ac looks fine otherwise, the various NUX_* substitutions all look the smae [13:42] didrocks: just that the thing that's different from NUX_GRAPHICS is this xxf86vm thingy [13:42] one sec, l2010-11-12 09:55:53 didrocks (epic battle with cmake which decides "o [13:42] hhh no glib-2.0.pc"? Let's give it a chance… But I'll forget all the other CFLAG [13:42] S just for you!) [13:42] maybe it's related to that ^ [13:42] like "I can't find one, let's forget the CFLAGS" [13:42] didrocks: oh, nux -> c'est la cmake? [13:43] I don't see a cmake file anywhere [13:43] pitti: no, but it looks it's the same symptom [13:43] I was blaming CMake, but the cause is maybe something else [13:43] mterry, yay, seems to work [13:43] like pkgconfig or whatever [13:43] didrocks: so, I have no idea about this I'm afraid; perhaps just try a build with using Xxf86vm? [13:43] rodrigo_, yay! [13:43] mterry, mkdir'in the m4 dir though === jorge__ is now known as jcastro [13:43] pitti: yeah, I'll try that and push it there [13:44] rodrigo_, eh, that's a forgivable grossness, as it *should* be in upstream tarball [13:44] didrocks: let me know if you need score bumping or so [13:44] pitti: sure, one sec :) [13:45] mterry, yes [13:51] pitti: it's already building, no need to score then :) [14:00] * rodrigo_ -> lunch [14:00] pitti: it failed… but in any case: libxxf86vm-dev: /usr/lib/pkgconfig/xxf86vm.pc [14:00] (I should have checked before) [14:00] didrocks: yes, but the "Name:" in the file is capitalized [14:01] pitti, didrocks: can one of you sponsor lp:~ken-vandine/ubuntu/maverick/x264/maverick-proposed [14:01] i had asked seb128 back when i pushed this... but i guess he forgot :) [14:01] didrocks, i suspect you are busy :) [14:01] kenvandine: can do [14:01] pitti, thx [14:01] pitti: right, but configure fails with the capital letter [14:03] didrocks: oh, interesting; so perhaps it doesn't like the inconsistency there [14:03] PKG_CHECK_MODULES should look for lowercase, and it should add -lXxf86vm from that [14:03] pitti: but why only on buildd and not locally? [14:04] didrocks: NFC :( [14:04] need all panel applets need porting to libpanel-applet-3-0 to show up on the panel again? [14:11] pitti: do you get your pbuilder working? it's still broken here [14:11] I have a bunch of: ind: File system loop detected; `./proc/1/task/1/cwd/sys/devices/platform/reg-dummy/subsystem/devices/i8042/serio0/subsystem/devices/serio1/input/input8/subsystem/input0/device/subsystem/devices/LNXSYSTM:00/device:00/PNP0A03:00/device:01/physical_node/sub [14:12] didrocks: I don't have a pbuilder [14:12] I have that only for natty, my maverick pbuilder is working fine… [14:16] didrocks, pitti is it possible to get the build dir off LP where the build failed? [14:16] didrocks, pitti I think inspecting the produced makefiles is the only way to figure out that's going on [14:17] getting the Makefile on it can be useful [14:17] njpatel: we checked the local one is ok, but yeah, getting the one on the buildd will be helpful, maybe [14:18] njpatel: certainly; but that needs lamont [14:18] makefile and the configure [14:18] njpatel: I agree [14:18] ok, I'm trying to recreate a natty pbuilder, the maverick one worked there… [14:20] oh oh, can reproduce \o/ [14:20] NUX_GRAPHICS_CFLAGS = [14:20] NUX_GRAPHICS_LIBS = -pthread -lgdk_pixbuf-2.0 -lm -lgobject-2.0 -lgmodule-2.0 -lpng12 -lgthread-2.0 -lrt -lglib-2.0 -lGL -lGLEW -lGLEWmx -lXxf86vm [14:20] what's the… !!! [14:21] didrocks, wow [14:21] in every Makefile, btw [14:21] all the other CFLAGS is ok [14:22] how the hell can that happen? [14:22] so, there is a missing dep that empty the CFLAGS [14:22] didrocks: pkg-config failure theN? [14:22] pitti: seems that [14:22] pitti, that's what I thought, but it would happen on normal natty too? [14:22] let me try pkg-config on that manually in the chroot [14:22] didrocks, missing depend causing it? [14:22] njpatel: if that's a missing .pc dep, maybe not [14:22] right [14:22] same idea :) [14:22] njpatel: but not direct one, one from an install -dev package [14:23] njpatel: I check nux build-dep, all is correct [14:24] http://paste.ubuntu.com/530720/ \o/ [14:24] pitti: njpatel ^^ [14:24] so missing dep on libgl*-dev it seems [14:24] didrocks: libxext? [14:24] pitti, also... just a reminder, please don't forget the gwibber maverick SRU [14:24] oh beat me to it [14:25] I install libxext-dev in the chroot and try to rebuild [14:25] didrocks, oh god :) [14:25] njpatel: not his fault for that :) [14:26] NuxGraphics/Makefile:NUX_GRAPHICS_CFLAGS = -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 [14:26] sounds better :) [14:28] yes! [14:28] Sarvatt: you mean, libxext missing dep is already known? === tkamppeter_ is now known as tkamppeter [14:33] didrocks: hey, a quick quesiton/bugreport. it appears that if oneconf is instaled on s-c launch people will get a "please log into u1" dialog. can we make this a bit more subtle? [14:33] test: System-->Administration-->Time and Date try to unlock it to make changes (I can not) [14:33] didrocks: I'm happy to submit a bugreport if you are busy currently [14:33] mvo: at start? [14:33] I saw it as Requires.private in the .pc and I just started shipping the generated gl.pc from the dri build instead of from the swrast build recently (since thats where that libGL is from), will fix up the libgl1-mesa-dev deps for the next upload [14:33] didrocks: yes [14:33] mvo: yeah, a bug report, so that I can check, thanks :) [14:33] 2010-11-12 15:28:39,984 - root - DEBUG - oneconf: refresh hosts [14:34] mvo: oh yes, in the terminal, that will change as I'll use u1sso (it was the binding from u1preferences which made that) [14:34] mvo: but a bug report will be fine :) [14:34] Sarvatt: ok, I'm making a quick fix in ubuntu for building nux then [14:35] didrocks: the message is not the problem, the dialog is ;) i.e. it should not pop it up unless the user requests the feature explicitely [14:36] hey tremolux [14:36] tremolux, where in Boston? [14:36] didrocks: bug #674537 (just fyi) [14:36] Launchpad bug 674537 in oneconf (Ubuntu) "triggers u1 login dialog on fresh install (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/674537 [14:36] hey mvo! [14:36] didrocks: and not urgent (at all) :) [14:37] mvo: thanks :) [14:37] bcurtiswx: I'm in Action, about 20 miles outside of Boston [14:38] tremolux, hmm, idk where that is.. my bro lives in Malden [14:38] bcurtiswx: sorry, Acton :) [14:39] tremolux, i was just up there for Halloween. I have relatives in Northboro and Malden [14:39] bcurtiswx: ah yeah, I know Northboro well [14:40] bcurtiswx: pretty around here at Halloween-time, isn't it? it's been a great autumn [14:41] tremolux, absolutely. I love fall.. and winter. I grew up in Rochester, NY. so winters anywhere else aren't that extreme :) [14:42] mvo: I think the dialog popup is related to a recent change in u1preferences api, last time I check, it didn't :) but well, as I'll move to u1 sso, the issue won't be there [14:42] can anyone test the following please: system-->admin-->time and date and try unlocking it to change it [14:42] i can't for some reason [14:46] bcurtiswx: confirmed in natty [14:47] thanks didrocks [14:47] pitti, OK thx. What package should a bug for that be filed under? Would anyone want to be assigned to that? [14:48] bcurtiswx: gnome-system-tools; but it's going to go away in natty [14:48] pitti, hmm. I can just wait for that to go away then. What's replacing it? [14:49] bcurtiswx: time and date will just be dropped, you can change it in the panel applet [14:49] user & groups has a replacement in gnome-control-center 3 [14:49] (so I heard) [14:49] for time and date, the alternative is system-config-date [14:50] pitti, how do I change it in panel applet? this may be my dumb question of the half hour [14:50] I packaged that during maverick for an OEM project, and it's a lot smaller than g-s-t [14:50] bcurtiswx: hm, it used to be possible, anyway [14:50] bcurtiswx: so, you can set the time zones and locations there [14:51] yup [14:51] I guess I never actually set the time, since ntpdate is doing that [14:51] pitti, OK then my issue is my times an hour behind what it should be.. [14:51] but my location is set correctly [14:51] wrong time zone? [14:52] didrocks: sorry about that, I fixed up the libgl1-mesa-dev depends in debian experimental and it'll be in the next upload in a few days after we do a merge [14:52] bcurtiswx: what does "date" say? [14:52] in terminal? [14:52] yes [14:52] Fri Nov 12 08:52:39 EST 2010 [14:52] should be EDT [14:52] were in daylight savings [14:53] bcurtiswx: what's /etc/timezone for you? [14:53] Sarvatt: no worry. I was just puzzled by the issue and as my natty pbuilder is broken, debugging was just horrible :) fix pushed to natty and look forward to your next merge :) [14:53] America/New_York [14:53] bcurtiswx: indeed, DST ended this Sunday, right? [14:53] yes, this past sunday [14:53] $ TZ=America/New_York date [14:53] Fr 12. Nov 09:53:45 EST 2010 [14:54] looks like tzdata bug [14:54] tremolux: ^ did you happen to hear about that? [14:55] looks like America/ has eternal summer time now [14:55] bcurtiswx: would you mind filing a bug about this, please? seems we need to fix that in all stable releases [14:55] bcurtiswx: (against tzdata) [14:55] pitti: oh, nope, I didn't [14:56] OK, anyone to be assigned? [14:56] tremolux: could you look into that? [14:57] pitti: yep [14:57] zdump -c 2011 -v America/New_York [14:57] that looks entirely backwards [14:57] America/New_York Sun Nov 7 05:59:59 2010 UTC = Sun Nov 7 01:59:59 2010 EDT isdst=1 gmtoff=-14400 [14:57] America/New_York Sun Nov 7 06:00:00 2010 UTC = Sun Nov 7 01:00:00 2010 EST isdst=0 gmtoff=-18000 [14:57] $ TZ=America/New_York date -d 'now - 2 weeks' [14:57] Fr 29. Okt 10:57:30 EDT 2010 [14:57] $ TZ=America/New_York date [14:57] Fr 12. Nov 09:57:39 EST 2010 [14:58] hm, wait [14:58] does the "D" mean "daylight saving" or does the "S" mean "summer time"? [14:58] yeah, we lose an hour.. not gain one [14:58] pitti: yeah, it's fine isn't it? (scratching my head) [14:58] maybe I'm just misinterpreting the abbreviations here [14:58] tremolux: so the gmtoff looks correct [14:59] seems I'm just misinterpeting the meaning of EST vs. EDT [14:59] right, so it's "S"tandard vs. "D"aylight [14:59] so zdump is correct [15:00] pitti: http://wwp.greenwichmeantime.com/time-zone/usa/eastern-time/ [15:00] pitti: yep, it's correct [15:00] bcurtiswx: according to http://www.timeanddate.com/worldclock/city.html?n=179 it _is_ 10 am for you.. [15:00] pitti, this is correct [15:00]