[00:00] ScottK: thats my problem :-) i've seen breakage in both ocaml and haskell libs. [00:01] What we need is someone who can tell us what needs to be done and in what order since none of use really know about those things. [00:01] If someone can do the analysis, we can probably make it happen. [00:02] i think what it needs more than anything is process; testing that the complete set o libs does work. === asomething_ is now known as asomething [00:04] ScottK: does ubuntu pull from debian testing or from debian unstable? [00:04] m3ga: This discussion if probably better on #ubuntu-motu since the packages are all in Universe. [00:04] m3ga: Mostly unstable. [00:10] ScottK: just joined -motu [00:10] OK. [00:11] laprice: Correct, .ex just means "example" - though those files, even when renamed are not really "built into the package" so much as "used to build the package". Please direct similar future questions to #ubuntu-motu, which is a more on-topic forum for guidance on learning packaging. [00:12] sorry, i didn't realize this was not the correct channel. [00:12] slangasek: When you get a minute, I think we will need studio disks rebuilt, due to include the fixed apt-setup package. One of our testers ran into bug 316618. [00:12] Launchpad bug 316618 in apt-setup "jaunty alternate cd media change error" [High,Fix released] https://launchpad.net/bugs/316618 [00:13] slangasek: Thanks in advance. [00:13] heh, just making that comment on #ubuntu-tsting [00:13] or on #ubuntu-testing, rather [00:14] he ok. [00:14] s/eh/heh/ [00:29] superm1: (addressed Matt Domsch's mail now) [00:38] cjwatson: who is in charge of reviewing SRUs currently? [00:39] ah i found the group :) === baytes is now known as eights [01:27] (roughly) how many days should I wait for ubuntu-devel@ moderation before seeking a kindly moderator here to expedite matters? === asomething_ is now known as asomething [01:48] maxb, eventually nvidia with have an open libvdpau library and those packages that were provided right now will go away. they're named the way they're named right now in case that doesn't happen by the time nvidia-185-graphics-drivers is out [01:48] nvidia didn't really provide a time frame for when libvdpau will be open [01:48] bryce,^ if you are interested too [01:49] So, if 185 shows up in the meantime, it will just need to conflict with 180 explicitly? And if additional versions, then the conflicts lines just grow longer, and hopefully nvidia gets around to doing it properly before it gets silly? [01:50] maxb, exactly [01:50] gg, makes sense [01:51] once libvdpau is open it will be installed by default likely too since ffmpeg will likely be linking to it.. [01:56] calc: pong [02:07] ArneGoetje: heh nevermind slangasek and I worked out what he wanted to do for alpha 3, he had been thinking about rerolling langpacks but decided against it [02:27] bryce, i updated one bit on there, but otherwise looks right [02:28] superm1: great thanks [02:29] calc: is there anything we need to change in the language-support packages for oo.o3? [02:44] ArneGoetje: i don't think so [02:45] i just found out the main drive in my computer is subject to sudden death at ~ 3mo of use [02:45] * calc is going to back all his data up onto an external drive asap [02:49] calc: 3 months? [02:49] yea the lovely Seagate 7200.11 1TB drives [02:50] geeze, and 1TB too :( [02:50] http://forums.seagate.com/stx/board/message?board.id=ata_drives&thread.id=3668&view=by_date_ascending&page=1 [02:50] calc: too many OO.o builds? :-) [02:51] the 1.5TB had the problem which was revealed over a month ago and apparently they now know the 1TB are affected too but no solution yet [02:56] calc: I avoid to buy Seagate and WD for exactly that reason. Too much bad experience. [02:56] calc: the last WD I bought failed after 2 weeks. :( [02:56] go Maxtor! ;-) [02:57] um didn't seagate buy maxtor? [02:58] eg http://www.seagate.com/maxtor/ existing [02:58] ah [02:58] well, there you go [02:58] craaap. I've got 2 of those drives. [02:58] I've never had problems with Hitachi [03:08] Hm. Alpha-3 freeze means shephearding f-spot and tomboy through the gnome-sharp2 transition so I can get the new version of smuxi is... unlikely :) [03:08] didn't hitachi make the notorious deskstar (aka deathstar)? [03:09] * kees is currently backing up everything to is handy 1TB usb drive.... [03:09] cjwatson: that was IBM (before taken over by Hitachi), yes. But despite the name, I've never had any problems with them... maybe I was just lucky... ;) [03:12] it's amazing how half the web forum posts I read castigate Ubuntu for doing nothing but changing the desktop background, and the other half complain about how we haven't changed the theme much for several releases [03:12] but since my last encounter with WD (which costed me 20000 NT$ to get the data recovered by a profesional data rescue company, I have invested in a hardware raid 5 solution. :) [03:12] (obviously both missing the point rather substantially) [03:14] * kees needs eSATA. usb is slow [03:16] Urgh. The new volume control notification applet is really annoying. [03:17] the way it's horizontal and semi-offscreen? [03:17] No, that's the new panel applet. [03:17] That's also more than moderately annoying. [03:17] RAOF: are the gnome-sharp2 bits in place in the archive? we didn't have gnome-desktop-sharp2 yet, last I was looking at that [03:17] I'm talking about the notification icon that only pops up when something's playing a stream. [03:18] Meaning that it's impossible to change the volume before something starts playing, and the volume icon is always in a different spot. Score! [03:19] slangasek: Looks all done to me. [03:19] https://edge.launchpad.net/ubuntu/+source/gnome-desktop-sharp2/2.20.1-2ubuntu7/+build/831357 [03:19] Urgh, wrong page. [03:20] RAOF: ooh, ok. Well, maybe we can transition f-spot and tomboy if we desperately need more CD space for alpha-3. :) [03:20] RAOF: you've confirmed that they build ok now against the new versions? [03:20] No, not tomboy or f-spot. [03:21] Did it for banshee, because that was something I could fix ;) [03:21] heh [03:22] I'll do it for the others now if you like [03:22] it would be useful to have that done so that we can transition them at the best opportunity [03:24] I'll check & attach debdiffs to the transition bug, I guess. [03:25] RAOF: awesome, thanks [03:26] backing up 1TB over USB is going to be slowww [03:26] should take ~ 14hr or so i guess [03:29] * RAOF should get >=4GB of ram on his next purchase. Building things on a tmpfs is just too nice. [03:33] RAOF: i'm thinking of buying another 4GB for my system to bring it up to 8GB (max for my chipset) [03:34] Well, that's not gone well. Apparently no package in the archive contains gnome-panel-sharp-2.24.pc [03:34] RAOF: ah, that's what I meant earlier wrt gnome-desktop-sharp2 [03:35] we need gd#2 2.24 [03:35] Why did the -0ubunt1 build succeed then? [03:36] of which? [03:36] Of tomboy. [03:36] The upstream version doesn't seem to have changed. [03:36] because it was built against the older gnome-sharp2 that still had gnome-panel-sharp, I think [03:37] er, no; maybe it was that tomboy had code that, *if* it detected g# 2.24 or better at build time, it requires this new .pc [03:37] anyway, if gd#2 isn't updated yet, that's definitely the first step [03:39] Ah, yes. There it is, conditional on gnome-sharp being >= 2.23.99 [03:39] Right. New gd#2.24! [03:39] * RAOF goes and checks pkg-cli-libs [03:45] Ah, so no quick joy there. [03:45] And you made the last, unuploaded checkin to svn. Score. [04:07] Any core devs willing to sponsor uploads into {hardy,intrepid}-proposed for LP #216761? [04:07] Launchpad bug 216761 in xen-3.3 "errors in xendomains init script" [Undecided,Confirmed] https://launchpad.net/bugs/216761 [04:17] ebroder: We're in the middle of a freeze for Alpha 3, so no. [04:17] Unless it fixes something critical for Alpha 3 [04:17] ScottK: It's not Jaunty - it's for Hardy and Intrepid [04:17] Oh. [04:43] ebroder: Since pitti asked bryce to sponsor it, I think I'll let him do it. Otherwise you might ask zul. [04:45] Ok. Did bryce actually get that request? He wasn't subbed to the bug [04:48] Dunno, but I just highlighted him. [04:48] It's late here, but I imagine he'll get it eventually. [04:49] Ok, thanks [04:54] bryce: http://paste.ubuntu.com/105046/ [04:55] there are a few of us witnessing this right now with kde4 in jaunty...any ideas? [04:56] calc: um, that's disturbing, OOo finished both i386 and amd64 in < 6h? [04:56] slangasek: maybe database didn't build or something [04:56] calc: huh, but 2ubuntu3 took the same time, so I guess things got faster in 3.0? [04:57] or maybe the buildds got an upgrade and I hadn't noticed until now :) [05:43] nixternal: weird, never seen that [05:44] actually... [05:44] exaCopyDirty sounds familiar [05:44] bryce: ya, we noticed that tonight, however it seems to not be the root of our issue actually...there are one of two things going on that are kde4 related..but I thought I would pass that by you [06:04] When I upload a new package to that replaces an older one (the name of the package changed, what can I do to ensure that an aptitude upgrade will upgrade the package), I tried putting "Replaces: X" in the control file, but it isnt working. [06:07] you would want to create a "dummy" package under the old name to ensure upgrading [06:07] but why did the package name change? [06:09] It is in a PPA, and the old maintainer gave it a confusing name. [06:09] ok [06:09] creating a dummy package is the only way to ensure an upgrade [06:09] ok, thanks [06:10] I think I have another solution, actually. [06:10] There is 1 metal package that people install to bring in all the packages, so I just added a conflict on the old package in the meta package [06:10] meta* [06:11] and changed the depend on the new package [06:11] right, if you have a top-level package whose name will stay the same, that's a better solution :) [06:12] Btw, what is the best way to ensure that a hardy package has an lesser version number than an intrepid package [06:12] Is there any kind of established naming scheme ? [06:13] Right now I am using "XXX-0ubuntu1~ppa2" for intrepid and "XXX-0ubuntu1~ppa1" for hardy [06:13] It would be nice to number then independently somehow [06:14] XXX-0ubuntu1~ppaX and XXX-0ubuntu2~ppaX maybe ? [06:14] I tend to use foo-0~intrepid~ppa1, foo-0~hardy~ppa1, etc. [06:14] RAOF, does that only work because I > H ? [06:16] yes [06:17] I would lean towards foo-0~ppa1~{hardy,intrepid} or foo-0~ppa1{hardy,intrepid}or foo-0~ppa1.8.{04,10}; that way the release it's built for is the least significant part of the version [06:18] btw, how do "-" and "~" differ ? [06:19] ~ sorts earlier than anything, including end-of-string [06:20] - has a special meaning, in that the last occurence of it in a version number is taken to be the delimiter between the upstream version and the Debian revision [06:20] slangasek: But that won't sort below official backports? [06:20] btw, why use "-0", I was told to use "-0ubuntu1", but I dont understand the rational for either [06:20] RAOF: well, true; I wasn't worrying about those [06:21] det: if Debian hasn't packaged that upstream version yet, we use "-0" so that our versions sort earlier than an eventual "-1" [06:22] in theory the Debian maintainer could release a -1 version that includes all of our changes, and we want to ensure we'll be able to sync that version from Debian [06:22] Ok, thanks [06:22] why the 1 on the end then ? [06:22] det: because we might want to update the packaging or add patches later too [06:23] so it might be 0ubuntu2, 0ubuntu3 and so on [06:23] XXX-0~0hardy~ppaX and XXX-0~1intrepid~ppaX, does that seem like a reasonable scheme ? [06:24] basically, RA0F's scheme, except prepend a number to the codename [06:24] why would you do that? [06:25] seems like a bad idea to depend on the sort order of the codename [06:25] that's why the codenames sort [06:25] better use the release version, then. [06:25] for now :-) [06:25] they cant do that forever [06:25] and they didnt always sort in the past [06:25] since breezy [06:25] release version is a good idea, thanks [06:26] XXX-0~8.04~ppaX and XXX-0~8.10~ppaX it is [06:26] guaranteed to work until the year 3000 [06:27] Anyways, after Zany Zebra, this sorting system breaks down [06:27] and I dont like to use things that are fundamentally broken [06:27] and not until year 3000 [06:27] Amaranth: Further, since we only minus 2000 [06:28] we are on j very soon, so 16 letters left, aka 8 years [06:28] StevenK: I guess if you want 100.4 :P [06:28] Thanks for the help guys [06:28] err, that'd be 2100 [06:29] * StevenK laughs [06:29] so, good until then [06:29] might need a new scheme if it makes it that long [06:29] spring: Depends: spring-lobby which is a virtual package. [06:29] argh [06:30] I made the metal package conflict with the old package, and depend on the virtual package that the new package provides [06:30] but aptitude is complaining [06:30] meta* [06:32] $ apt-cache show springlobby | grep Provides [06:32] Provides: spring-lobby [06:32] $ apt-cache show spring | grep Depends [06:32] Depends: spring-engine, spring-lobby, spring-installer, ca-installer [06:32] Am I doing something that is not allowed ? === thekorn_ is now known as thekorn === asac_ is now known as asac [07:39] good morning [07:40] Howdy === warp10_ is now known as warp10 === tkamppeter__ is now known as tkamppeter [08:27] could you please give us your opinion on the jack issue? my last update to the mailing list was on monday, but the issue is open since mid december [08:27] -ECHAN, sorry [08:29] siretart: is that JACK in Main? [08:29] LaserJock: no. I currently don't see jack suitable for main [08:30] but that's just my personal humble opinion [08:30] darn [08:30] all the music apps that would be nice to include in Edubuntu require JACK [08:31] however we are working on some Universe metapackages that would make it less of an issue I think [09:23] siretart: what happened to the glorious iceowl/experimental upload ;)? [09:39] asac: ah, on my harddisk, not uploaded yet. just a sec [09:39] LaserJock: do you know someone actively working on jack in ubuntu? [09:40] siretart: there was discussion for Intrepid with Ubuntu Studio folks [09:40] siretart: I think bigon perhaps was looking at it [09:41] LaserJock: at jack? [09:42] LaserJock: ping! [09:42] bigon: maybe my memory is failing me, it's almost 2am :-) [09:42] Baby: yeah? [09:42] LaserJock: are you looking at KDE4 as a foundation for an educational desktop for kids? (ref: http://laserjock.wordpress.com/2009/01/13/why-we-need-edubuntu-to-succeed/ ) [09:42] LaserJock: I dont remember I've work on jack [09:43] asac: uploaded [09:43] bigon: hmm, were you looking at freebob? [09:44] siretart: thanks [09:44] Baby: Edubuntu is currently "adding on" to both Gnome and KDE4, however I'm currently interested in what KDE4 can offer [09:45] Baby: maybe pop over to #edubuntu and we can chat about what Debian's doing [09:46] I'm very interested in KDE4 as a foundation for a desktop targeted at kids (Debian Jr project). I've just talked to Aaron about it, even though it doesn't have direct educational purposes, I think it would be good to collaborate [09:46] yup :) [10:31] det: you mentioned using Replaces earlier; it doesn't mean quite how you described it, and you should probably read the policy manual carefully because this is an area where people often get confused === asac_ is now known as asac [10:31] det: A Replaces: B on its own actually just means that A contains some files also contained by B (so B here is usually "foo (<< some-version)") [10:32] I went the dummy package route [10:33] A Replaces B; A Conflicts with B; New dummy package of B that depends on A [10:33] for a single package with no complicating dependencies from elsewhere, Conflicts+Replaces+Provides should do it; the Provides may not always be necessary [10:33] slangasek is right that there are cases that can only be solved by a dummy package, though - apt doesn't always work it out [10:34] (Conflicts+Replaces means something completely different from Replaces alone) === thekorn_ is now known as thekorn === ziroday` is now known as ziroday === StevenK is now known as MootBot === MootBot is now known as StevenK [12:08] mvo: have you seen bug 312092? It seems to break upgrades from intrepid to jaunty [12:08] Launchpad bug 312092 in update-manager "Failed to update to jaunty via update-manager " [High,Triaged] https://launchpad.net/bugs/312092 [12:10] mdz: checking it now, thanks - I think its a side-effect of new code that tries to ensure that if one component is enabled it should be used consistently (in -updates and -security as well) - looks like partner somehow entered this [12:10] mvo: yes, that's what the log messages seem to indicate [12:10] mvo: I have a system ready to upgrade to jaunty if you want a tester [12:11] mdz: thanks, I will ping you when its fixed === mcasadevall is now known as NCommander === mcasadevall is now known as NCommander [12:31] tkamppeter: milestone freeze is still in effect, please don't upload new upstream versions of packages that are on the CDs right now [12:41] A regression has been found in acpi-support released yesterday: apm of desktop disks is set to 128 instead of 254 [12:41] -> https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695 [12:41] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/59695/+text) [12:42] The regression is in acpi-support (0.109-0hardy1) [12:42] jakon: have you suspended and resumed? [12:43] slangasek: ^- [12:43] This has nothing to do with that i guess [12:43] There are two bugs in the scripts [12:43] They don't handle the case of on_ac_power returning 255. [12:44] hmm [12:45] I attached two patches that should fix this to the bug tracker (last 2 comments) [12:46] the second is a patch to the resume script; I see the bug, but how does that change anything on a non-laptop system? [12:46] or do you mean for it to be applied to all four copies of the script? [12:47] Oh yes [12:49] The script in resume.d is irrelevant (the whole folder is) [12:49] not entirely [12:49] it just isn't used by default [12:49] ;) ok [12:56] sigh; there's nothing about acpi-support that doesn't make me weep [13:16] slanagsek, sorry, but changes are small, as we already had Foomatic 4.0 development snapshots in Intrepid. So all these packages are only bug fixes (for the last bugs fixed before Foomatic 4.0 official release). [13:16] tkamppeter: doesn't matter, they're not supposed to be uploaded during the freeze. [13:17] cjwatson: acpi-support 0.109-0hardy2 uploaded to hardy-proposed, please review [13:18] slangasek: will do, can you mail the TB (CC me) as per standard procedure for regressions? [13:18] yes [13:21] accepted [13:22] gar, bug #59695 is way too unwieldly [13:22] tkamppeter: the reason not to upload these things despite the small changes is that they can cause other builds to be delayed, which causes a problem for the release manager getting things out on time especially when he's already been up for too many hours [13:22] Launchpad bug 59695 in dell "High frequency of load/unload cycles on some hard disks may shorten lifetime" [Low,Confirmed] https://launchpad.net/bugs/59695 [13:22] I'm getting repeated timeouts :( [13:22] slangasek: try edge.launchpad.net [13:22] hrm. it's falling over on that too, it seems. [13:23] I got it to load at last, so I'm good now [13:25] if Ralph and Jakob confirm the fix, and somebody on a laptop confirms that it doesn't regress for them, I think we can push this on through to -updates [13:25] do we need to block downloads of 0.109-0hardy1 and 0.114-0intrepid1? [13:26] jakon: can you test the 0.109-0hardy2 package once it's built and available in hardy-proposed? [13:27] cjwatson: the impact of the regression is to cause decreased drive performance on systems with acpi-support installed and without batteries; I'm not sure the user-facing disruption of blocking the downloads is warranted [13:27] Yes, can test that [13:27] it's only decreased performance, not damage? [13:27] I guess [13:28] I don't know, I was asking [13:28] cjwatson: until we roll out the new update, affected systems will have a greater rate of increase in load cycle count as well [13:28] There won't be any immediate damage [13:28] but nothing that should be damaging if we're rolling out a new update shortly [13:29] could a core-dev please approve the Intrepid task in bug 295490? TIA. [13:29] Launchpad bug 295490 in liferea "Liferea doesn't start with "Aborted" error." [Medium,Fix released] https://launchpad.net/bugs/295490 [13:29] I don't know if there are (old? strange?)disk that will hang when set to apm 128 [13:30] jakon: well, I don't think we should take precipitous action based only on speculation that some drives might fail under standard conditions [13:33] There is certainly no need to act precipitately, but this should be fixed sometime soon. [13:33] The "hanging" ide led reported in launchpad frightened me a little [13:34] yes, working as fast as I can to get it fixed [13:34] slangasek: I just noticed that I declared "layers" to be the Name in archive-reorg and that you objected to it on the grounds that they weren't layered. Can I convince you on the grounds that they're partially layered? :-) [13:34] haha [13:34] I don't think you can cnvince me, but you can make the declaration anyway and I'll live with it [13:34] (I figured I'd just take the blame) [13:35] actually I was sort of also thinking of them as something that a user could layer onto their minimal system [13:36] but mostly as "oh my god we have spent hours on this name" [13:38] snowflakes! :P [13:43] I'm noticing an amazing similarity between this IRC log and the log of the one coinciding with that UDS session that I happen to have open ... [13:43] oops [13:46] Just a note for testing acpi-support: I don't have desktop pc, i faked one by replacing on_ac_power with a "exit 255" shell script. But that should do i think. [13:46] cjwatson: 0intrepid2 accepted [13:47] cjwatson: er, no it wasn't [13:47] * slangasek reads the whole subject line [13:50] cjwatson: ok, there - /now/ 0intrepid2 is in unapproved [13:58] slangasek: accepted === robbiew-away is now known as robbiew [14:00] thanks [14:08] How long should I wait for ubuntu-devel@ moderation before it becomes reasonable to ask on IRC for a kindly moderator to expedite matters? [14:19] mvo: ping [14:23] calc: I see the openoffice source has patches for KDE 4, have you tried them? [14:30] emgent: pong [15:14] slangasek: acpi-support 0.109-0hardy2 looks good, just tested it [15:15] jakon: great, thanks. Could you follow up to the bug report as well? [15:17] Will as soon as launchpad is up again [15:17] Ok, that is now. [15:23] Commented in launchpad [15:29] slangasek: Do you plan to use the pm-utils script i posted? ( http://launchpadlibrarian.net/21210580/95hdparm-apm ) Because it also contains this bug. If yes, i will update it. [15:35] jakon: hadn't looked at it in detail yet === Ursinha is now known as Jorjao [16:07] Riddell: yes they don't work [16:08] Riddell: i'm going to be talking to some people to see about why soon [16:08] Riddell: i used them in the previous build from a few weeks ago and got lots of bug reports about it not working at all === dendrobates- is now known as dendrobates [16:19] calc: a shame, do you know who was working on them? [16:24] Riddell: i think Kendy of Novell [16:24] but i haven't pinged him about the KDE issue yet [16:25] Riddell: just asked him but i am not sure if he is online right now [16:30] quit("Bye") [16:30] Whatever. [16:39] Riddell: kendy says it is pretty much completely broken and he hasn't had time to work on it [17:00] siretart: Do you have any commit on upstream xine-lib? I'd love it if you could merge the two "%s" additions upstream [17:00] calc: a shame that [17:01] Riddell: it will work better with kde3 support than it does in alpha3, aiui the file picker is missing currently [17:01] Riddell: but it won't have full kde4 integration unfortunately :( [17:02] Riddell: gio support doesn't work right either but it is being worked on luckily [17:09] superm1: wrt bug #317270, can you clarify which kernel version? I assume its Jaunty. [17:09] Launchpad bug 317270 in linux "Dell Studio XPS 16 touchpad doesn't return from resume" [Undecided,New] https://launchpad.net/bugs/317270 [17:10] rtg, yes that was with jaunty [17:10] superm1: thanks [17:18] hi [17:19] anyone familiar with ext4? may I use ext4 as logical drive? [17:20] mib_uo1mgbbs: ext4 is independent of whether you're using primary or logical partitions (so "yes") [17:22] the funny thing is while i'm installing xubuntu 9.04, I choose ext4 as logical drive cos my primary drive is winxp, the partioner dunno for what reason is showing ext3 [17:25] can anyone enlighten me? [17:25] ugh my laptop just died i think [17:26] mib_uo1mgbbs: ext4 can be misinterpreted as ext3 by things which don't know about ext4 properly [17:28] calc: hard drive? [17:28] LaserJock: no it just went black showed a bunch of blue crap on the screen then didn't respond, its rebooting ok though [17:28] LaserJock: i'm still working on backing up my desktop though [17:29] is there a way I can confirm wheteher I'm currently using ext4 or not? [17:29] mib_uo1mgbbs: mount? [17:31] i need to restart my computer to boot xubuntu [17:35] mib_uo1mgbbs: there was a known partitioner bug that may have caused that kind of symptom; make sure you're running an absolutely current daily build [17:35] maxb: really shouldn't be relevant in the installer, I believe I've caught everything [17:37] mib_uo1mgbbs: if you're encountering this with a current daily build, please don't ... reboot [17:37] bah in excelsis [17:42] i think the fuse ntfs support is a bit buggy, my drive claimed to be full when i used around half of it [17:42] so i reformatted it as ext3 [17:43] well didn't really claim to be full but refused to allow me to write any more to it in any case [17:43] calc, that could be due to an error causing it to remount as ro [17:43] got a bunch of cp: cannot create regular file "foo" Operation not supported messages [17:44] hmm maybe it remounted during the middle of the copy, not certain [17:44] it copied about 390GB of 500 to do when it showed those [17:47] EOPNOTSUPP is rather unusual and does *not* mean "disk full" [17:48] ntfs-3g appears to return it basically when it gets garbage requests [17:48] hmm ok [17:48] it did that for cp and mkdir, etc [17:57] Ng: I'm trying to work out what's happening in this bug of yours - it seems that there may be multiple problems [17:57] Ng: can you tell me what you did at the ignore/cancel prompt? [18:00] lool: err, how comes that the translations are THAT broken? [18:00] cjwatson: I tried both, neither took me to any kind of disk selection thing, they'd just bounce me to the menu (I assumed that Ignore was thinking I just had a strange disk and I'd fix it up with partman, but partman clearly didn't want to run) [18:00] anybody knows what means "unexpectedly too meny pseudo-links" from aufs? i'm using kubuntu intrepid in live mode with persistence file (with both -7 and -9 kernel) [18:00] lool: and does this also happens with the translations provided by upstream? [18:00] siretart: separate bug we're investigating [18:00] nevertheless it is still a xine bug (and probably a security flaw) [18:01] gettext and gcc provide facilities to test for this, which for some reason didn't manage to fire in this case [18:01] gcc handles it under -Wformat-security [18:01] users can override the paths gettext uses? [18:01] translations should not be considered fully trusted anyway; show me a maintainer who reads every line of every translation they merge [18:01] mdz: a fixed upgrader is now availabe (for the bug you mentioned earlier [18:02] cjwatson: I think my suggestion would be that if partman fails to run and there are other disks in the system, offer to choose one, or maybe add that as a third option in Ignore/Cancel [18:02] sure. I'm just wondering about the severity of the issue. and if that would warrant updating released versions of xine-lib [18:02] Ng: Ignore should do just that [18:02] siretart: I don't think so [18:02] hrm [18:02] it doesn't need a third option which basically just means Ignore [18:02] siretart: No [18:03] cjwatson: perhaps it's something special about the disks being under /dev/cciss/ that confuses it? [18:03] Ng: I doubt it [18:04] siretart: I was under the impression that TEXTDOMAINDIR overrode such things [18:04] though I have not checked; but in any case I don't think that's relevant [18:04] cjwatson: hmm, ok. well I've pulled the unused card out of the machine so I could actually install it, so we do have the card floating about and could probably drop it into similar hardware to reproduce it again [18:04] Ng: I expect there are multiple bugs here really, I'm just trying to break it down [18:04] mvo: I will test, thanks [18:06] Ng: in particular there seems to be a bug in partman's error handling, which is why I asked what you selected [18:06] I may have introduced that recently [18:07] Ng: after that, partman will have been completely buggered which probably explains the later problems [18:07] ah :) [18:07] also, casper seem to boot only if i unplug & replug the pendrive first, otherwise i got dropped to a shell... i'm at 4th trial... [18:14] what is casper-snapshot for? i'm reading the man page but still i don't understand :P [18:17] it's used to enable the home persistence? or i can simply put a home-rw named empty image to the pendrive and boot? [18:22] lool: 19:18:30 < _ds_> ISTM that the second half of the patch is broken anyway: looks like the wrong xine_log is patched. [18:23] lool: perhaps you could join #xine/oftc and discuss it directly with darren? [18:31] cjwatson: huh, looks like the next machine on my list has the same hardware. Is there anything I can do RightNow to provide more information? otherwise I need to yank that card too ;) [18:33] siretart: sure === RainCT_ is now known as RainCT [18:46] kirkland: after selecting the encrypted home option, I'm curious why I still have a .Private ecryptfs mount. Is this expected behavior? [18:47] rtg: that's where your encrypted data goes [18:47] rtg: /home/rtg/.Private gets mounted on /home/rtg [18:48] kirkland: What does encrypted home mean? I thought it would supersede .Private [18:48] rtg: yes [18:49] rtg: ALL of /home/rtg will be mounted on /home/rtg/.Private [18:49] rtg: we just need a place to put your encrypted data [18:49] rtg: and that place is /home/rtg/.Private (for lack of a better place to put it) [18:49] kirkland: that makes my head hurt. how can I mount on a directory that is within the filesystem being mounted? [18:50] rtg: easily. by just doing it. [18:50] ugh. [18:50] rtg: where would you prefer this data? [18:50] rtg: alternatively, we could mount /home/rtg on top of /home/rtg [18:51] kirkland: no preference, I'm just confused. [18:51] rtg: but i found that even more confusing [18:51] perhaps my understanding of file name spaces is insufficient. [18:51] rtg: sorry, am i being to terse? [18:52]