=== cpg|away is now known as cpg [01:31] hmmm ubuntu's switching to systemd? [01:31] http://www.markshuttleworth.com/archives/1200#comment-397370 <-- is this for real? [01:34] hyperair: not a reliable source of information [01:34] * i.e. no clear relation to the project [01:35] hyperair: I don't know why you'd get that impression. === cpg is now known as cpg|away [01:35] RAOF: i figured it would have been flamed to hell already if it wasn't true. [01:35] RAOF: so the lack of flames were a cause of concern. [01:39] hyperair: I think the lack of flames are probably due to moderated comments [01:40] Possibly also that it's basically just noise. [01:53] heh [01:59] hyperair: might as well write that there's 'no question' that unity will be rewritten in C# :) [02:04] ajmitch: good idea! [02:05] hyperair: it's probably on news sites already after commenting on it in here === ringtail is now known as vibhav === cpg|away is now known as cpg === elleuca is now known as Guest84837 [02:25] ajmitch: I'd support that! [02:25] RAOF: think of how confusing it'd be to have unity & unity3d, both in C# :) === cpg is now known as cpg|away === cpg|away is now known as cpg === cpg is now known as cpg|away === JackyAlcine is now known as jalcine [03:37] Good morning [03:37] morning pitti [03:38] ScottK: I put it into the changelog; I haven't maintained a NEWS file for postgresql so far, perhaps I should for stuff like that [03:38] pitti: I suppose that'll do, but I think NEWS is better. [03:39] slangasek: GNOME SRUs> A good indication is the version number, it should be 3.6.x for quantal; but that is indeed a bit blurry [03:39] hey ajmitch [03:41] pitti: Done. [03:41] ScottK: done what? [03:42] pitti: Accepted the SRUs. [03:42] oh, the ecpg one; thanks! [03:42] pg on precise and quantal. [03:45] pitti: ah, good point. Well, stgraber provided pointers to the upstream module definitions, which is probably good for now. [03:47] skaet, cjwatson, stgraber, infinity, release team: congrats to the final release! that was a rather difficult birth [03:56] I think it would have been a lot smoother with less last second featuritis. [03:57] TheMuso: hey, is there really any reason for us to ship libasound2-python? Debian doesn't ship the smixer plugins at all; I can't find any documentation for how this plugin is supposed to be used, and it's definitely not ported to python3 [04:29] This is probably a simple answer but can one "clone" a package from a public launchpad project and then build the project easily? [04:31] invalidopcode: You probably want #launchpad. [04:31] ScottK: okay, thanks. [04:31] I'm trying to work on the [04:31] lp:ubuntu/quantal/pidgin-libnotify project, that's why I asked here [04:34] invalidopcode: 'bzr branch lp:ubuntu/quantal/pidgin-libnotify' is the bzr equivalent of a git clone [04:35] as for building, you perhaps want 'dpkg-buildpackage' [04:35] okay, thanks! I'll try that [04:38] slangasek: it gives me "dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ..." [04:39] invalidopcode: ah - so you should probably install the bzr-builddeb package, and run 'bzr bd' instead of 'dpkg-buildpackage' [04:40] ah thanks! It seems to be going now :) === cpg|away is now known as cpg [04:43] it seems to complain about not being able to sign the package [04:43] it might be because I haven't logged into launchpad [04:43] but if I'm just doing dev, do I need to sign the package? [04:44] invalidopcode: that will be because you haven't set up your environment with a pgp key; and no, you don't need to sign the package [04:44] invalidopcode: there are some pages somewhere that talk about this initial env setup, let me see if I remember where they are [04:44] okay thanks! [04:44] yeah I don't want to keep bothering you if I don't have to [04:44] http://developer.ubuntu.com/packaging/html/getting-set-up.html [04:46] thanks [04:47] I'm new to the Ubuntu dev community... I'm more familiar with the Archlinux pkgbuild system :) [05:18] slangasek: after following all those steps it still fails with "gpg: /tmp/debsign.UclxAL3H/pidgin-libnotify_0.14-4ubuntu11.dsc: clearsign failed: secret key not available" [05:20] invalidopcode: so in order for debsign to know which key to use, either your PGP key's UID must exactly match the uploader field in debian/changelog, or you need to pass -k to tell it which key to use. (for instance, if you're signing a package that someone else prepared, you need to use this latter option) [05:20] invalidopcode: however, if you're not actually uploading this anywhere, you can use the -uc -us options instead: bzr bd -- -uc -us [05:21] ah okay [05:21] thanks [05:22] yay! it worked :) [05:26] thanks for all the help slangasek! [05:34] is the new libmessaging-menu library this http://developer.ubuntu.com/api/ubuntu-12.10/c/messaging-menu/ ? [05:36] disregard the stupid question :) [05:46] okay last question. slangasek. what does one to do fix "aborting due to unexpected upstream changes"? [05:46] invalidopcode: that depends on what those changes are... you might run dpkg-source --commit to keep them, or bzr revert to get rid of them [05:47] so for every change I make I have to do that before building? [05:47] well [05:47] or is there a better way to do quick development? [05:48] if you're testing the build, you can also pass -b to bzr bd [05:48] and skip the source package generation, which is what's failing here [05:48] okay [06:01] good morning [06:14] slangasek: so i'm playing with the debian experimental qemu git branch that's taking the place of qemu-kvm soon. working well for me. i looked at a diff to the qemu-linaro git tree, and it seems contained enough to arm stuff that it would seem fine to add as a patch, imo, to consolidate the trees. (there are other barriers of course) [06:14] something to talk about at uds if nothing else [06:16] * hallyn calls it a night === tkamppeter_ is now known as tkamppeter [06:20] Good morning [06:44] mvo, good morning [06:45] mvo, I found bug 1068389 this morning [06:45] Launchpad bug 1068389 in ubuntu-release-upgrader (Ubuntu) "P->Q - do-release-upgrade crashed with UnicodeEncodeError: 'ascii' codec can't encode character u'\xbb' in position 1: ordinal not in range(128) in DistUpgrade/DistUpgradeViewText.py", line 143, in showInPager" [Critical,Triaged] https://launchpad.net/bugs/1068389 [06:46] jibel: thanks, let me have a look === smb` is now known as smb [07:18] is there a way to disable automounting certain media/mountpoints? [07:18] tjaalton: put them into fstab (LABEL= or UUID=) and don't mark as "auto" [07:18] pitti: ah, thanks [07:18] tjaalton: 'noauto' in fstab(5) :) [07:19] yeah I thought there was a "newer" method :) [07:19] but this works too [07:28] jibel: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/revision/2581 - I will upload that now [07:52] mvo, thank you [07:56] jibel: thank you for finding it! === amitk is now known as amitk-afk [08:11] pitti, about https://code.launchpad.net/~pitti/charms/quantal/jhbuild/jhbuild_from_git/+merge/130365 [08:12] jibel: oui? [08:12] pitti, I'd rather not delete the local copy on configuration change or upgrade and preserve any change the user could have made locally [08:12] pitti, what do you think ? [08:12] jibel: you mean in the checked out jhbuild tree? [08:13] pitti, right [08:13] jibel: I can change it accordingly, yes [08:13] jibel: i. e. [ -d jhbuild ] || git clone jhbuild? [08:13] jibel: d'accord, I'll change it accordingly [08:14] this 2 lines + rm -rf jhbuild [08:14] + git clone git://git.gnome.org/jhbuild [08:14] as it can be an unpleasant surprise [08:14] jibel: right, and the ones below that for autogen and make [08:14] yes === henrix_ is now known as henrix [08:36] jibel: did they approve your charm now? [08:36] jibel: you said yesterday you wanted to wait with the merges until that happened [08:39] pitti, not yet but the fixes are safe, and xfvb something we want by default. [08:40] jibel: ah, so we'll shelve the jhbuild-from-git one for now? [08:40] jibel: good, then I'll continue with my pygobject stuff today, and get back to the charm on Monday [09:00] ev, so, what are the possible causes of a spike [09:00] jockey [09:00] (1) There's a big new bug: unlikely, since we were in Final Freeze, and the table doesn't show anything obviously new. [09:02] (2) People installing from scratch experience bugs disproportionately to pre-release testers, e.g. bugs in the installer or, yes, jockey. [09:02] A binary program crash that's suddenly appearing and not showing up on the front page because the retracers are down (thanks gnat-gps). [09:02] But the first ubiquity problem is #68, jockey #45. [09:02] ah [09:02] So there were 18187 reports for 12.10 yesterday, compared with 6320 the day before. [09:03] (3) There's something wrong with the denominator in the calculation. We're counting many fewer users than we should be. [09:03] (Or fewer machines, rather.) [09:05] hmmm, suspicious: there were 63630 unique systems for the 90 day period ending yesterday. There were 565335 for the 90 day period ending on the 17th. [09:05] That's not as big an increase as I would suspect. [09:06] UTC, right? [09:06] yes [09:07] 12.10 was out for only ~6 of those hours. [09:08] sure [09:08] so we should definitely see how much the unique system in a 90 day period count grows after today [09:09] but this still doesn't explain the big upward swing of reports [09:22] is there a way we can modify the fontconfig deprecation warning? it is not clear at all what it wants you to do. [09:23] "Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated." [09:23] it's software, so yes [09:25] jtaylor: apt-get source fontconfig && grep -r "is deprecated" fontconfig-* [09:25] I'm just looking at it [09:25] would a patch be accepted for an sru? [09:26] concentrate on fixing the next release, and think about SRU as a secondary wishlist [09:27] I believe the general tendancy is to ask/warn a user if they are able to do something about it (and tell them how), or not bother them with science if they can do nothing about them. Thus, either fixing it to a proactive comment, or disabling both make sense === yofel_ is now known as yofel === davidcalle_ is now known as davidcalle [09:51] ev: oh, sorry, I promised to deal with the gnat-gps SRU didn't I [09:52] done [09:53] Somebody else is noticing shutdown issues sometimes? [09:56] cjwatson: thanks! And no worries at all - I wasn't expecting anything to happen yesterday, given the release [09:57] mpt: responding to your PM here: yes, sorry, that should be 56335 systems in the 90 day period ending yesterday === doko_ is now known as doko [11:15] ev, another example of (2) might be the RecoverableErrors, if people install and then try to install a bunch of apps [11:16] mpt: yes, but we separate out the effect of RecoverableErrors into its own line [11:16] ev, not yet :-) [11:16] oh, I see on poppy-dev [11:16] :) [11:16] it goes up just as high [11:17] barry, ping [11:18] ev, just throwing ideas out there, but do you have something like an off-by-one error in the period you're counting users in? E.g. dividing the number of errors for yesterday by the period up to the day before? [11:18] (...by the number of computers in the period up to the day before, I mean) [11:20] I'll do a review of the code now === MacSlow is now known as MacSlow|lunch === henrix is now known as henrix_ === henrix_ is now known as henrix === mcclurmc is now known as mcclurmc_away === _salem is now known as salem_ === tdc_ is now known as tdc === MacSlow|lunch is now known as MacSlow [12:52] barry, doko: please don't add python3.3 to supported versions until python-docutils is fixed [12:52] stgraber: could you have a look at #1068614 please? probably something relatively easy to fix on the server [12:53] I would prefer to upload docutils 0.9.1 with some cherry-picked patches, but that would require uploading python-roman [12:53] and MIRing it [12:53] is that possible before the archive opens? [12:54] https://code.launchpad.net/~mitya57/ubuntu/raring/python-roman/1.4.0-1ubuntu1 [12:54] otherwise I can try to backport those patches to 0.8 [12:55] mitya57, where is the MIR? [12:55] doko: I haven't filed it because the package is not yet uploaded [12:55] should I do that? [12:55] mitya57: Given that the python3-defaults patch for 3.3/multi-version support is incomplete, I don't think we'll have it at the open in any case. [12:56] yes please, and upload the package [12:56] ScottK, ? [12:56] I think he means issues with pyqt [12:56] doko: See my last mail to -devel. I tried barry's patch and it didn't work out so well. [12:56] mitya57: Yes, but I don't think it was an issue specific to that package. [12:57] hmm, it did work for me for a simple extension. if just qt4 fails, then let it fail ... [12:57] I'll try another one. [13:32] MIR done (bug 1068630), so are we uploading new python3-defaults before the archive opening? [13:32] Launchpad bug 1068630 in Ubuntu "[MIR] python-roman" [Undecided,New] https://launchpad.net/bugs/1068630 === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [13:42] cjwatson: i was in the process of converting gnome-keyring to multiarch and noticed in the rules file it does this install -m0755 -D debian/gnome-keyring.ubiquity debian/gnome-keyring/usr/lib/ubiquity/target-config/50gkd-caps, i didnt see ubiquity as an rdepends so was wondering what implications this has [13:43] or if ubiquity will never be multi-arched i guess it wouldn't mattter [13:43] The lack of a dependency doesn't matter - it just provides a hook for ubiquity to run in case it is installed [13:44] There's no reason for ubiquity ever to be multi-arched as far as I know, so if this is in a multi-arch: same package then you just need to make sure it's identical across architectures as usual [13:44] libgnome-keyring is MA: same [13:45] so should be ok then [13:52] doko: ^ [13:59] and I'm thinking of going with an svn snapshot of docutils because it includes my patch for debian bug 677929. [13:59] Debian bug 677929 in python-docutils "python-docutils: remote copy of MathJax needed to render maths" [Serious,Open] http://bugs.debian.org/677929 [14:02] mvo: hmm, yeah, that's fixable on the server. I'll assign that one to me [14:03] stgraber: thanks [14:05] mitya57, and the docutils upload? [14:06] doko: so I should do it now? [14:07] mitya57, yes, both please [14:08] doko: OK, doing [14:25] mitya57, did you upload? [14:27] I've prepared it, will now file a bug report and upload tarballs there [14:27] I'm not a core developer :) [14:32] doko: bug 1068667 [14:32] Launchpad bug 1068667 in python-docutils (Ubuntu) "Please upload docutils 0.9.1+svn7532-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/1068667 [14:32] I'm not able to test it now thoroughly because I have to go [14:33] But I can do that tomorrow [14:34] doko: ^^ [14:35] and the branch with python-roman packaging is at 1048259 [14:35] *bug 1048259 [14:35] Launchpad bug 1048259 in Ubuntu "[needs-packaging] python-roman" [Wishlist,Confirmed] https://launchpad.net/bugs/1048259 [14:39] * mitya57 has to go offline now, sorry :( === Quintasan_ is now known as Quintasan [14:46] I'm back :) [14:57] stgraber: bzr: ERROR: Revision {stgraber@ubuntu.com-20110804202131-kd0ddqcwxmznqjw9} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))"., know anything about this? happens when doinga bzr branch lp:ubuntu/quantal/ssd [14:58] sssd* [15:00] stokachu: I suggest you file a bug on launchpad.net/udd [15:00] Laney: ok will do thanks [15:01] there's a source package called ssd? [15:01] sssd [15:02] I see 'ssd' in the pasted URL [15:02] * Laney shrugs [15:02] oh [15:02] typo [15:02] rofl [15:02] laney@quantal> bzr branch lp:ubuntu/quantal/sssd ~/temp [15:02] bzr: ERROR: Revision {stgraber@ubuntu.com-20110804202131-kd0ddqcwxmznqjw9} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))". [15:02] right :) [15:12] cjwatson: if you got a few seconds could i get appmenu-gtk and libgnomecanvas approved in the upload queue for precise? [15:19] doko: attached tested and updated tarballs to bug 1068667, will you sponsor it? [15:19] Launchpad bug 1068667 in python-docutils (Ubuntu) "Please upload docutils 0.9.1+svn7532-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/1068667 [15:27] stokachu: Won't running dpkg-query in an Xsession.d script slow down desktop startup performance? [15:28] stokachu: And shouldn't this get into a development release first? [15:28] cjwatson: is raring open for that now? [15:29] cjwatson: startup performance maybe affected by a small amount [15:30] It could be quite significant - opening the dpkg database can be expensive [15:30] I think this needs to take a file-based approach instead [15:30] Perhaps use a wildcard? [15:31] cjwatson: hmmm i could do that [15:31] all arch are basically similar in where its put right? /usr/lib//.. [15:31] i wasn't sure for arm etc [15:31] It's always one subdirectory down, yes [15:31] The name of the subdirectory isn't necessarily what you expect of course [15:32] yea i can try that approach and see [15:37] stokachu: huh, I see slangasek suggested the dpkg-query approach [15:38] cjwatson: lol i didnt want to say anything :X [15:38] slangasek: ^- did you consider the desktop startup performance implications of calling dpkg-query in Xsession? [15:38] the plot thickens :D [15:39] The question of what happens if it's missing is a bit murky anyway, because surely it depends on which architecture of libgtk is running that might try to load it [15:39] Or something === beuno is now known as beuno-lunch [15:40] cjwatson: from my tests it works either way [15:41] stokachu: so, unclear about appmenu-gtk, but libgnomecanvas is nice and simple - there were two roughly-identical copies of it in the queue, so I accepted the first and rejected the second [15:41] stokachu: conffiles can be arch-specific, I'd just generate it at build-time with the full path. [15:41] infinity: not in a multi-arch: same package [15:41] see the bug :) [15:41] cjwatson: Oh, it's in the library. Ick. [15:42] cjwatson: hrm, there was a vague tickle in the back of my head, is this actually having a noticeable startup impact? [15:42] But if it's MA:same, the dpkg-query defeats the entire purpose. [15:42] Since it's going to tell you if you have your primary-arch version installed. [15:43] Which may or may not be what you wanted to know. [15:43] it is [15:43] this config file is used to set a single environment variable that affects all versions of gtk [15:43] Yes, but. How does that relate to what I just said? [15:43] either you have some version of appmenu and you want to set it, or you don't have any and you don't set it [15:44] oh, sorry, misparsed [15:44] no, that query doesn't just return for the primary arch [15:44] try it and see [15:44] slangasek: I haven't profiled it, but it would definitely seem to me to be a concern [15:45] If we're cracking down on forks during boot, forking something that loads a substantial text database just seems unwise :) [15:46] cjwatson: i think i attempted the file based check first and slangasek mentioned that wouldnt work [15:46] i'd have to go back into the notes and see why that was [15:47] slangasek: I bed to differ. I just installed sl:i386 (so, not having the amd64 one installed at all) and, as I expect, I get "unknown ok not-installed" for sl, and "install ok installed" for sl:i386 [15:47] slangasek: So, I maintain that if your appmenu-gtk doesn't match your dpkg arch, this fails. [15:47] doko: so will you sponsor that or no? [15:47] slangasek: Which kinda seems to defeat half the point of multiarching. [15:47] infinity: that's not a multi-arch: same package [15:47] The dpkg-query call takes ~0.2s here after dropping caches [15:48] cjwatson: barely enough time to sneeze! :D [15:48] stokachu: tight budgets [15:48] It all adds up. [15:48] cjwatson: fwiw the tickle in the back of my head also said "what is this crazy design, why are we exporting variables instead of just letting gtk probe it on the filesystem" [15:48] slangasek: So for "some version of appmenu is installed", why not just glob over @moduledir@/*/libappmenu.so and test if any of the results exist? [15:49] infinity: that's not how the dpkg-query output for libc6 looks, to take an example M-A: same package [15:49] Equivalent and faster [15:49] cjwatson: yeah, that should be fine too [15:49] slangasek: That would be hard for me to test, given that it's impossible to remove the native libc6... [15:49] for x in @moduledir@/*/libappmenu.so; do if [ -e "$x" ]; then ...; break; fi; done [15:49] stokachu: ^- [15:49] maybe -f rather than -e to match the original [15:49] cjwatson: I think I didn't recommend that because of an aversion to dealing with globs in shell scripts [15:50] clearly that did not serve me well here :) [15:50] The above is my standard form, and avoids the usual no-nullglob-related bug [15:50] stokachu: cjwatson's approach is definitely better [15:50] so no immediate issues with globs then? [15:50] If the design is to test whether *any* libappmenu.so is available, then the glob approach should work [15:51] ok, cool! ill work on getting that implemented and retested [15:51] I don't know whether gtk breaks if $UBUNTU_MENUPROXY is unavailable [15:51] the original menus are used [15:51] OK, good [15:51] yea i tested that when i broke the build :D [15:52] a fs grep is faster than dpkg-query? [15:53] micahg: In that case, sure. It's not a find / [15:53] slangasek: I'm curious what you mean by libc6 output looking different. [15:54] slangasek: and do you ever hear a giggle in the back of your head? [15:54] slangasek: (Purely academic now, since he's not using this approach) [15:54] hey guys. when you view windows scaled back in the overview/spread mode in either unity or gnome shell, it seems like there's no point in drawing all the UI chrome, buttons and scrollbars and so on. it's an ambitious idea in terms of requiring toolkit/application support, but is the idea of being able to request applications draw only their "content", rather than UI chrome a realistic idea? [15:54] (and/or a useful idea) [15:56] an example would be libre office drawing only the text and hiding toolbars, gimp only drawing the image being worked on and none of the toolboxes, calculator only displaying the current result [16:04] slangasek: Just to show I'm not insane, http://paste.ubuntu.com/1289641/ [16:05] Will123456: #ubuntu-unity might be better for that kind of thing [16:05] infinity: That only shows this isn't evidence of insanity. It's not proof otherwise. [16:05] ScottK: ...? [16:06] ScottK: Oh, right. [16:06] ScottK: Yes, I'm clearly insane, we all know that, just not in regards to this. :P [16:06] insane on at least one side [16:15] cjwatson: good call, i'll ask there [16:19] cjwatson: hmm, i think im going to have to use /usr/lib/*/ rather than moduledir [16:20] moduledir expands to /usr/lib//gtk-2.0/2.10.0/menuproxies/*/libappmenu.so [16:20] and that won't even work fully [16:20] i could glob 3 spots perhaps [16:20] infinity: http://paste.ubuntu.com/1289689/ fwiw :) [16:21] slangasek: izzat quantal or precise? [16:21] infinity: quantal [16:21] slangasek: Ed zachary. His upload is to precise. [16:22] stokachu: Ah, right, I wasn't clear on the exact directory layout [16:22] stokachu: Maybe there's some other piece you can extract from the build system; or *cough* run sed over @moduledir@ [16:22] so i guess my question is that acceptable to do /usr/lib/*/*/*/menuproxies/libappmenu.so [16:22] That doesn't feel right [16:22] yea [16:23] maybe you can get hold of the gtk-2.0/2.10.0/menuproxies part separately [16:23] cjwatson: http://paste.ubuntu.com/1289701/ [16:23] line 36 starts where it handles the appmenu.in portion [16:24] but you could always use shell's text processing facilities [16:24] moduledir=@moduledir@ [16:24] moduledir_suffix="${moduledir#/usr/lib/*/}" [16:24] etc. [16:24] then you can look at /usr/lib/*/$moduledir_suffix/libappmenu.so, or something like that [16:25] ok ill dig into it some more to see what i can come up with [16:25] stokachu: What's the full path? [16:26] infinity: http://paste.ubuntu.com/1289706/ [16:26] that was with the splat in there [16:27] stokachu: No, the full path. What's that extra * expand to? [16:27] infinity: well thats all that is put into 80appmenu from the configure [16:27] only @moduledir@ is expanded to what you see there [16:27] Yeah, that certainly won't work, try my moduledir_suffix stuff instead [16:27] the splat was what i put in there [16:28] stokachu: What I mean is, where is the actual file? [16:28] infinity: oh just remove the splat [16:28] infinity: /usr/lib/*/gtk-2.0/2.10.0/menuproxies/libappmenu.so [16:28] and that would be the full path [16:28] stokachu: I'm going to assume a splat is an asterisk? ;) [16:28] yea sorry [16:28] lol [16:28] cjwatson: Right, and globbing works fine, if that is used, then. [16:29] Just a matter of picking the expansion of @moduledir@ apart in shell. [16:29] Yeah. [16:32] hi. [16:34] i opened bug with nfs-utils on launchpad two weeks ago but still didn't get any answer. [16:34] https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1062022 [16:35] Launchpad bug 1062022 in nfs-utils (Ubuntu) "exportfs crash with long path" [Undecided,New] [16:36] also I opened the same bug on Red Hat bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=863054. And the result: http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=a16f4a13677d13b0aae9327a3b9e8414470b7927;hp=b010d126bbb8265e5717e596711d754baec11e6c [16:36] bugzilla.redhat.com bug 863054 in nfs-utils "exportfs crash with long path" [Unspecified,New] [16:45] hi. i noticed some errors during an "apt-get update" and was told I should drop this here. http://33ad.org/pb/vp [16:45] this was about 15 mins ago. I tried again just now and it seemed to sync ok, so not sure what the transient issue was related to [16:47] ^ more W: Failed to fetch bzip2:/var/lib/apt/lists/partial/it.archive.ubuntu.com_ubuntu_dists_precise-updates_main_source_Sources Hash Sum mismatch [16:47] nod: it looks like there's three it.archive... mirrors; try it a few times and see if it comes back? [16:48] it's completed already now, i just thought you guys might want to know [16:48] i'm more concerned from an infrastructure standpoint and not this silly vm I'm hacking on :) === deryck is now known as deryck[lunch] [16:49] nod: It's not a mirror we directly control, so not a whole bunch we can do about it sometimes being skewed. [16:49] :) [16:50] (Except to take away their CC DNS entry, but that's probably not necessary here) [16:50] interesting. could clock skew introduce issueslike that? [16:51] i'd figure it's just a simple rsync of some flat file structure [16:52] nod: It's a flat file structure, but if the Release and Packages files need to match. [16:53] nod: Most mirror admins run scripts to try to mitigate the windows between those two being transferred to seconds (or less), some don't care and it can be minutes. [16:53] nod: Err, that first sentence took a turn when I lost context elsewhere. "if the Release and Packages files don't match, you get that error" is what I meant to say. :P [16:54] heh i grok'd. [16:54] nod: Which is, of course, a feature. The bug is that they can not match while a mirror is updating. [16:54] (Which is a bug in how we publish the archive and/or in how people mirror it, depending on where one likes to place blame on days that end in 'y') [16:54] Also web caches occasionally get unlucky and then get stuck on the mismatching versions until they expire. [16:55] cjwatson: Yeah, that can be unfortunate. [16:55] quirky. so it's not an atomic operation by moving to an alternate location, then flipping over to the new repro? [16:55] Figuring out the relevant URLs and running wget --no-cache on them can sometimes clear this for an entire office-worth of people at once. [16:55] nod: Unix doesn't have atomic directory replacement [16:55] nod: It is on our end, we don't dictate what mirrors do. [16:55] It's not even on our end [16:55] cjwatson: symlinks :) [16:55] It's just close [16:55] Well, OK, I guess [16:56] cjwatson: It is on our end on the publishing side is what I meant, as in, we don't push mirrors until ftpmaster is consistent. [16:56] nod: But even then, a client's update could straddle the symlink change [16:56] So that doesn't really solve the problem ... [16:56] other option is to rewrite httpd config to new loc then send HUP [16:56] Same problem [16:56] yeah.. good point [16:57] The problem is only solvable by subtle mangling the archive format, and we've talked about it a lot. [16:57] Some day, someone might write the code to actually make it happen. [16:57] Right, we had a plan to put everything in SHA-512-named files or similar [16:57] cjwatson: Yeah, I vaguely liked that one. Ugly to humans, simple for computers. [16:58] alright... this conversation is getting too interesting. i can't continue or i'll get distracted from paying the bills with cool stuff. [16:58] Mitigatable for humans with symlinks. [16:58] More or less. [16:58] thx all for your help. bbl when i can spare cycles [16:58] The ugly to humans bit being solvable by linking Packages to the "current" SHA. [16:58] Jinx. [16:58] And the above is necesarry to provide backward compat anyway. [16:58] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 (Quantal Quetzal) released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: hallyn === beuno-lunch is now known as beuno [17:04] neat gnome-keyring places gnome-keyring-prompt in /usr/lib/gnome-keyring [17:04] on precise [17:05] i think ill mess with that and appmenu on monday [17:18] hi! [17:18] with the release over, I wonder if someone has time [17:18] to look over this SRU of mine: https://bugs.launchpad.net/landscape-client/+bug/1053057 [17:18] Launchpad bug 1053057 in landscape-client (Ubuntu Oneiric) "Client queues up lshw calls if talking to old server" [Undecided,New] [17:18] just precise was uploaded so far [17:18] (to proposed) [17:37] ahasenack: the SRU team is a few weeks behind. thanks for your confirmation of that bug(fix) though. [17:38] hallyn: ok, thanks === henrix is now known as henrix_ [17:46] ahasenack: are you looking for upload sponsorship or SRU processing, though? [17:46] SRU processing we're getting caught up on (I'm on deck today) [17:46]