| arpu | hi all | 00:12 |
|---|---|---|
| arpu | can someone help me with this bug ? https://bugs.launchpad.net/ubuntu/+bug/223843 | 00:12 |
| arpu | i found out it have nothing to do with the xrdb error messages in .xsession-errors | 00:13 |
| arpu | but the bootchart shows me xrdb -> zombie | 00:13 |
| arpu | is this the right channel to ask ? | 00:14 |
| === shadowxp2 is now known as shadowxp | ||
| pwnguin | i wish open week would publish required readings for talks instead of just duplicating the wiki over IRC | 00:42 |
| * lamont wonders what xivulon wanted | 01:10 | |
| jdong | lamont: now you'll *never* know | 01:11 |
| === golddragon24_ is now known as golddragon24 | ||
| ion_ | To ask your hand in marriage. | 01:11 |
| jdong | lamont: the inquisition will haunt you for the REST of your life | 01:11 |
| lamont | jdong: nah | 01:11 |
| lamont | he didn't care enough to just ask the question, so... meh | 01:11 |
| jdong | deep down you really do care. you are dying to know | 01:11 |
| jdong | and it will only become apparent in your mid-life crisis :) | 01:11 |
| * jdong was told not to go into medical science for some reason :) | 01:12 | |
| ion_ | May I inquire whether I am allowed to ask whether it's okay to ask whether i can ask to ask a metaquestion? | 01:12 |
| lamont | jdong: I already sold my midlife-crisis car | 01:12 |
| lamont | ion_: not without asking first. | 01:13 |
| lamont | :-) | 01:13 |
| toresbe | one of the more interesting bugs I've encountered when upgrading to feisty is that my left monitor has become intermittent | 01:13 |
| lamont | feisty??? | 01:13 |
| wgrant | Well, it's probably fixed in Gutsy or Hardy. | 01:13 |
| lamont | dear me, why? | 01:13 |
| toresbe | uh, sorry. Hardy! | 01:13 |
| arpu | no on an idea ? | 01:13 |
| toresbe | It's 2AM, and I'm doing schoolwork. :) | 01:13 |
| arpu | or help to find the problem ? | 01:13 |
| lamont | <ion_> am I allowed to ask whether it's okay to ask whether i can ask to ask a metaquestion? | 01:13 |
| toresbe | Well, I'm on IRC, pretending to myself that I'm really doing schoolwork. It's complicated. | 01:14 |
| lamont | toresbe: I know that issue far too well. | 01:14 |
| toresbe | :) | 01:14 |
| lamont | OTOH, it's 6PM here, and I'm about to head off to bed - exhausting afternoon | 01:14 |
| toresbe | after upgrading, monitor 0 while using the evil unfree nVidia driver... | 01:14 |
| jdong | pfft bed at 6PM? | 01:14 |
| lamont | jdong: I roll out of bed at 5AM weekdays | 01:14 |
| lamont | and this afternoon I kinda played on an antenna tower for a while.. | 01:15 |
| jdong | lamont: that's typically when I roll into bed to prepare for 9AM classes :) | 01:15 |
| lamont | total of ~ 200 feet of vertical climb, up and down | 01:15 |
| lamont | max height above ground? 40 feet | 01:15 |
| lamont | lots of trips | 01:15 |
| lamont | oh, and manhandling a 70 pound section into place at the top of two of those climbs | 01:15 |
| * ion_ does % units 200feet m | 01:16 | |
| lamont | ion_: 66m | 01:16 |
| lamont | and max height of ~13m | 01:16 |
| ion_ | 60.96 :-) | 01:16 |
| lamont | iz wag | 01:16 |
| lamont | you only get 2 sigfigs | 01:16 |
| lamont | too tired to actually count what I climbed | 01:16 |
| lamont | we were short one person, so I climbed to do the upstairs prep, then down to help haul it up, then up to place it, then up/down/up 10 feet to migrate the pole to the top of the newly installed section, then down to do it all over again | 01:17 |
| lamont | fortunately only adding 2 sections to the tower | 01:17 |
| ion_ | Heh | 01:18 |
| jdong | lamont: this sounds like the problem used to kick start our math discussion on recursive generator functions | 01:18 |
| lamont | so now my arms are starting to feel it. | 01:18 |
| jdong | I think you're supposed to move the bigger disc to pole 3 first | 01:18 |
| jdong | then move the next one to poll 2, then bring 3->2 | 01:18 |
| lamont | jdong: oh, it's definitely at least iterative, recursion would involve not coming down until it was done. | 01:18 |
| jdong | *ducks* | 01:18 |
| lamont | lol | 01:18 |
| lamont | just one stick | 01:19 |
| lamont | although if we grow it again, we'll have to take the top section down to put the new not-top section on before we can put the top back on... so it starts to feel like the tower of hanoi all over again | 01:19 |
| ion_ | What's the difference between a recursive function and a recursive generator function? 'foo = 1 + foo' vs. 'foo = 1 : [ a+1 | a <- foo ]' (haskell)? | 01:20 |
| lamont | I may put the 20 foot mast (which would top out at 62' )long story), and slap a flag on that so that I can call it a flag pole. then light it from below so I don't have to take the flag down - because that'd suck | 01:20 |
| jdong | ion_: generator functions track state for you lazily, it's not your job to manage the state of the generator | 01:21 |
| jdong | ion_: which is useful for more complex generators | 01:21 |
| jdong | where you can just "yield" values at arbitrary points in execution | 01:22 |
| jdong | and the next time you need to generate a value the function "resumes" at that spot | 01:22 |
| ion_ | Alright | 01:22 |
| ion_ | So a recursive generator function is just that, but happens to be recursive. :-) That is, the latter example is precisely that. | 01:23 |
| ion_ | s/recursive generator/generator function/ | 01:23 |
| ion_ | Uh, scratch that. Too sleepy. | 01:23 |
| jdong | ion_: well a generator function in CS is different than a generator function in mathematical theory | 01:24 |
| pwnguin | a generating function in math theory is stupid ;) | 01:24 |
| jdong | pwnguin: but it's on the test next week! | 01:24 |
| pwnguin | heh | 01:24 |
| jdong | pwnguin: so I'm kinda out of options :) | 01:24 |
| pwnguin | i really cant see the utility in them versus learning more graph theory | 01:25 |
| * lamont takes a drive to go restart openvpn from the far end. sigh | 01:25 | |
| ScottK | Heya lamont. sgran has me using git now (on clamav), so there's hope for me yet. | 01:45 |
| LaserJock | oh my! | 01:46 |
| lamont | ScottK: heh. cool | 02:19 |
| lamont | ScottK: I bounce between git and bzr these days | 02:19 |
| ScottK | So far I've encountered bzr nowhere outside of Ubuntu (I know it's used elsewhere, I just haven't run into it). Learning yet another VCS special for Ubuntu is low on my list. | 02:20 |
| LaserJock | ScottK: so you just need to get a git-bzr ;-) | 02:22 |
| calc | mjg59: http://www.advogato.org/person/mjg59/diary/82.html <- the firmware bug is what exactly? that it defaults to parking at too low an idle time? | 02:57 |
| Hobbsee | good morning | 02:57 |
| lamont | ScottK: likewise until I kinda picked up a business need to learn another one... | 03:06 |
| lamont | and I see benefits to both of them. and insufficient reason to switch between them for things that are already in one or the other | 03:06 |
| lamont | cvs/svn? definitely shoot it in the head and move to bzr or git. kthx | 03:07 |
| lamont | I wonder if I'd get shot for uploading to intrepid, or if it'll just wait until everything is ready for it | 03:07 |
| lamont | g'morning Hobbsee | 03:10 |
| ScottK | I think we've proven recently that it's impossible to be fired from being a volunteer for Ubuntu, so no reason not to go for it. | 03:10 |
| persia | It being frozen, the upload will likely sit in approved | 03:12 |
| persia | s/approved/unapproved/ | 03:12 |
| ScottK | persia: Did you see the message to debian-devel about README.Debian.source? | 03:15 |
| persia | ScottK: Yes. I'm all in favor | 03:16 |
| calc | got a question, anyone know how to use blktrace? | 03:16 |
| persia | With luck, there will be defined rules in debian/rules in the future to for things like "edit-patch", "patch", etc. | 03:17 |
| ScottK | persia: I'd suggest some updating of our documentation then so we can start pointing REVU victims at it. | 03:17 |
| calc | "blktrace -d /dev/sda -o -" says "/sys/kernel/debug does not appear to be a debug filesystem" | 03:17 |
| StevenK | ScottK: s/victims/users/ | 03:17 |
| calc | anyone know how to make it work? | 03:17 |
| persia | ScottK: Sounds like a good idea. You might want to write the suggestion to a mailing list | 03:17 |
| lamont | and util-linux_2.14~rc2-0ubuntu1 heads for intrepid | 03:17 |
| ScottK | StevenK: There's a difference (It's Debian makes you care about the users, not Ubuntu)? | 03:17 |
| ScottK | persia: Sure. | 03:18 |
| calc | oh nm README.Debian tells me what to do :) | 03:19 |
| ScottK | persia: Done. | 03:19 |
| * lamont really afk | 03:23 | |
| * TheMuso is in favour of the README.source file as well. | 03:42 | |
| ScottK | For odd stuff, sure, but I don't see a point in a file that says "This package uses dpatch" and then goes on to explain using dpatch-edit-patch. | 03:43 |
| ScottK | As with many things, it seems like a decent idea way overdone. | 03:43 |
| persia | ScottK: As it says in that email, for a dpatch using package, it would likely just point to the dpatch info somewhere in /usr/share/doc/dpatch. On the other hand, it makes answering the question "How do I tell what patch system to use" as easy as "read README.source" | 03:53 |
| * ScottK doesn't see that as a significant improvment over looking at the build-deps and then reading man dpatch-edit-patch, but OK. | 03:56 | |
| persia | ScottK: For the case of an enumerable set of patch systems, I agree. In order to specifically support an arbitrary set of patch systems, it'd be nice to not have to explain how to check both debian/control, debian/rules, and possibly some random included makefile snippet from somewhere when someone wants to prepare a patch. | 03:58 |
| ScottK | Right, but I think a "Don't bother if it uses dpatch, simple-patchsys, or quilt" rule would make sense. | 03:59 |
| === dmb_ is now known as dmb | ||
| persia | Well, also, as the set grows unboundedly, it becomes less clear if people would reliably remain familiar with those patch systems. | 04:00 |
| ScottK | But keep in mind the described purpose of this is for the security team. | 04:01 |
| ScottK | It's not meant for random developer wanna be's. | 04:01 |
| persia | Well, it's useful for them. Anyway, even for the security team, consider the case where someone encounters one of the packages that has patches both applied to the source in diff.gz and stored in debian/patches for reference: these are annoying to update without documentation. As the set of systems grows, this becomes more of a problem. | 04:05 |
| persia | At some point in the future, new entrants into the security team may rely on packages being in git or bzr tarballs as a regular course, and be somewhat stumped by someone's specialty dpatch that executes some logical analysis rather than just applying a simple patch. | 04:05 |
| ScottK | Sure someday. | 04:06 |
| persia | Right. For the common cases, it's just a "This package uses simple-patchsys: see /usr/share/doc/cdbs/simple-patchsys." in README.source. Not very difficult, yet future-proof. | 04:08 |
| === greeneggsnospam is now known as jsgotangco | ||
| kees | I'd prefer a machine-readable README.source, honestly. | 04:16 |
| kees | better yet, common build rules. | 04:16 |
| kees | but README.source is certainly a good first step. :) | 04:16 |
| persia | kees: If you'd be up for documenting a model, it could be encouraged for use in REVU as a proving ground. | 04:30 |
| kees | persia: I worry any attempt at this would just result in cdbs-edit-patch. ;) | 04:32 |
| persia | kees: Maybe, but I'd agree with you that having more defined build rules is the way to go. I'd like to see "patch", "unpatch", and "edit-patch" be standards. Let the packager control how the rule is implemented, rather than trying to have some system that does the right thing (e.g. cdbs-edit-patch). | 04:35 |
| persia | Set some standards, like "edit-patch must leave the user in a subshell, and save changes when complete", and it makes it easy for the updater. | 04:36 |
| ScottK | persia: Perhaps we should define some kind of common debian build system? | 04:37 |
| ScottK | ;-) | 04:37 |
| kees | persia: yeah -- I would love that. :) | 04:37 |
| kees | ScottK: sssh! ;) | 04:37 |
| ScottK | I guess I don't know how hard this really is. | 04:37 |
| persia | ScottK: We've had two. I'd rather have a defined interface, than defined code. This allows flexibility and change, without imposing behavious | 04:37 |
| persia | s/s$/r/ | 04:37 |
| ScottK | I fixed on one of manoj's packages just before release and even that wasn't that hard. | 04:37 |
| ScottK | In case you don't know, manoj doesn't even use debhelper. | 04:38 |
| * ScottK goes to bed (really this time). | 04:39 | |
| persia | That's fine. I'm not even especially concerned if people don't use make (although I'm a big fan of make). I'd just like to see more required rules implemented, so that more standard package manipulation procedures could be automated. | 04:40 |
| persia | I don't want to have to think about what to do when I want to a) check a new upstream, b) verify the patchset applied, c) apply patches, d) edit patches, 4) package a new upstream, 5) verify rebuild of generated files, etc. | 04:41 |
| persia | Every package should have the same interface: `debian/rules foo`. Ideally, there should be different sets of deps in debian/control so I can always verify that I have the right environment in which to run the rule. | 04:41 |
| wgrant | persia: I think we should start shipping packages with binary debian/rules, without source. | 04:55 |
| === RAOF_ is now known as RAOF | ||
| * Hobbsee clubs wgrant | 04:58 | |
| pwnguin | you spelled hugs wrong | 04:58 |
| * RAOF gives hugs | 04:59 | |
| pwnguin | hey RAOF | 04:59 |
| RAOF | Hey pwnguin. | 04:59 |
| pwnguin | random question: is the drm stuff nouveau needs going to be in mainline kernel any time soon? | 05:01 |
| RAOF | Once they're reasonably certain they'll not need to change any interfaces, yes. | 05:01 |
| pwnguin | so still no firm date | 05:01 |
| pwnguin | or even soft date | 05:01 |
| RAOF | That's one of the reasons why testing the randr12 codepath is being pushed right now. | 05:01 |
| RAOF | No, AFAIK. | 05:02 |
| persia | wgrant: That's a little extreme. I think we only have a couple binary debian/rules, but without source gets messy. | 05:02 |
| pwnguin | heh, progressQuest | 05:02 |
| RAOF | Once there are no randr12 blocker bugs it gets enabled by default, then pushed to kernelspace, then pushed to mainline IIUC. | 05:02 |
| pwnguin | so what else uses that besides nouveau? intel? | 05:03 |
| === dmb_ is now known as dmb | ||
| RAOF | pwnguin: Yup. Intel will, but not quite yet I think. | 05:03 |
| RAOF | pwnguin: Everything _will_, eventually. | 05:03 |
| wgrant | Is TTM part of the new DRM, or not? | 05:06 |
| pwnguin | donno about that. | 05:08 |
| RAOF | I think this depends on what you mean by "new DRM" :). I don't think that nouveau uses TTM yet, and I'm not sure whether intel does either, outside of git branches. | 05:08 |
| RAOF | I _think_ that with a bunch of git builds you can get DRI2 on (what will be) Xserver 1.5 with Intel, and I'm pretty sure that requires TTM. So... | 05:11 |
| a7x | i wrote a patch to fix a bug (LP: #221661). would someone be willing to review it and tell me if it's OK? | 05:13 |
| jdong | bug 221661 | 05:14 |
| jdong | oh that's right. no more bots. | 05:14 |
| jdong | pfft | 05:14 |
| TheMuso | huh? | 05:14 |
| jdong | TheMuso: more IRC politics than you want to ever know about... | 05:14 |
| TheMuso | jdong: Whats this? | 05:14 |
| jdong | trust me. | 05:14 |
| Hobbsee | TheMuso: you don't want to know. | 05:14 |
| * TheMuso sighs. So it is to our detriment then. | 05:15 | |
| gnomefreak | jdong: we have bots just none have that plugin or are as smart as ubotu | 05:15 |
| RAOF | What? Why no ubotu? | 05:16 |
| jdong | a7x: I looked at the patch, I can't say much about it, I'm not conviinced that it's right or wrong | 05:16 |
| gnomefreak | RAOF: nope no more | 05:17 |
| RAOF | _!!!_ | 05:17 |
| gnomefreak | ill brb my screen just went really small | 05:18 |
| a7x | thanks. what should my next step be? just let it sit until the package maintainer finds it? | 05:18 |
| warp10 | Good morning | 06:13 |
| === MacSlow_ is now known as MacSlow | ||
| pitti | Good morning | 07:23 |
| lucent | greetings | 07:23 |
| stgraber | morning | 07:31 |
| Silicium | ReiserFS: For when you need to partition your wife. :D | 07:32 |
| jscinoz | Nice silicium | 07:40 |
| === carlos_ is now known as carlos | ||
| emgent | morning | 08:43 |
| pitti | Keybuk: hm, MoM seems to be out of date. e. g. it shows debhelper as 6.0.10 in Debian; that was from March | 09:32 |
| PecisDarbs | hmmmm, why translation import queue is so long, is there any hope for it to change? | 09:54 |
| calc | yipee intrepid is now open for abuse :) | 09:54 |
| pwnguin | PecisDarbs: if intrepid is open, i imagine there's a whole ton of upstream translations being pulled in now? | 09:55 |
| PecisDarbs | ahhh I see | 09:55 |
| wgrant | I doubt the autosyncer would have run yet. | 09:55 |
| wgrant | As we have no new toolchain quite yet. | 09:56 |
| calc | basefiles, binutils is there already and a few other things | 09:56 |
| wgrant | I'll wait a few more days before I upgrade. | 09:57 |
| cjwatson | calc: will be a little while yet before it's open open | 10:12 |
| pitti | doko, cjwatson: FYI, debhelper merged, tested, fixed (sent to Debian), and uploaded, waiting in unapproved now | 10:12 |
| cjwatson | pwnguin: I rather doubt that intrepid is open for translations yet | 10:12 |
| cjwatson | pitti: do we want that in before gcc's done? I was thinking let the C toolchain build first | 10:13 |
| doko | I don't mind | 10:13 |
| pitti | cjwatson: yes, that's fine; just mentioning to avoid double work | 10:13 |
| pitti | cjwatson: it's arch:all, so it doesn't matter, but I thought it would be good to have it readily available in the queue | 10:13 |
| * pitti merges cdbs now | 10:14 | |
| persia | pitti: Please either reference the changelogs bit in the changelog or drop it | 10:15 |
| pitti | persia: ECONTEXT? | 10:15 |
| persia | pitti: For hardy, we carried a patch on CDBS that wasn't in the changelogs, which didn't autoinclude upstream changelogs in the binary package. | 10:16 |
| persia | For intrepid, it would be my preference to either explicitly document this patch, or not carry it. | 10:16 |
| pitti | persia: oh, sure; I'll walk through the entire delta again anyway | 10:16 |
| persia | pitti: Great. Just wanted to make sure that didn't get missed again: it wasn't worth a patch to fix the changelog, but confused a lot of REVU'ers | 10:17 |
| pitti | right | 10:17 |
| seb128 | persia: why do REVU people look at cdbs changes? | 10:18 |
| persia | seb128: Because people were getting the warning that they weren't including the upstream changelog from linda, and the CDBS documentation explicitly states that it should be autoincluded by CDBS. Without the reference in the changelog, several people spent time tracking down the cause to separately answer the question "Why doesn't it work they way it says it should". | 10:19 |
| seb128 | ah, ok | 10:19 |
| persia | Of course, more generally, there is the class of users who use apt-listchanges :) | 10:20 |
| wgrant | Do we really need that patch anyway? It can't save that much space, and there's no longer an easy way to look for upstream changes. | 10:22 |
| persia | There's also a heap of packages that work around it in one way or another | 10:22 |
| pitti | wgrant: oh, it saves a lot of space; upstream changelogs are often incredibly huge | 10:22 |
| pitti | they could go into libfoo-dev, but they shouldn't really be in all binaries | 10:23 |
| seb128 | wgrant: the space doesn't matter that much on an install but it does on the cd for example | 10:23 |
| persia | Given that only a subset of packages are on the CD, and not all of those use CDBS, might it make sense to patch those packages? | 10:23 |
| pitti | Xubuntu folks: do we still need cdbs' xfce.mk? AFAIK it's being phased out? | 10:24 |
| wgrant | persia: That would appear to make the most sense. | 10:24 |
| seb128 | no it doesn't | 10:24 |
| pitti | persia: it's still a waste of bandwidth and HD space for users | 10:24 |
| seb128 | persia: we don't want to have the whole cd content carying ubuntu specific change for no good reason | 10:25 |
| persia | pitti: I guess, but I've seen a lot of packages that work around it. Then again, I'm not in a good position to take an opinion based on bandwidth or disk space constraints. | 10:25 |
| seb128 | bah, they should not | 10:26 |
| wgrant | ... why not? | 10:26 |
| persia | If we really want to strip them, it would make more sense to me to have a hook in the build system that pulled them at build-time, to hit all packages, rather than just CDBS packages. | 10:26 |
| seb128 | we should fix those and explain to whoever does the change there is no reason | 10:26 |
| wgrant | Upstream changelogs are a good thing. | 10:26 |
| seb128 | they are not an user thing | 10:26 |
| wgrant | seb128: We ship the Debian changelog why? | 10:27 |
| persia | Why not? Users have to deal with the mnigration between versions when the upgrade. This is especially a concern for server-type packages. | 10:27 |
| wgrant | Surely that's going to have even fewer user-visible changes. | 10:27 |
| * cjwatson hopes the REVU process isn't suggesting people use linda any more, BTW | 10:27 | |
| cjwatson | it's officially phased out in Debian now | 10:27 |
| persia | cjwatson: It does, but there's no linda. It will likely be dropped when the documentation is next refreshed. | 10:27 |
| seb128 | persia: informations which should be displayed on upgrade should go in the README.Debian, not rely on users reading the upstream changelog for each package they update | 10:28 |
| broonie | seb128: YM NEWS.Debian? | 10:28 |
| seb128 | or that ;-) | 10:28 |
| persia | seb128: Do you mean NEWS.Debian? In that case, I have to echo wgrant's question: why do we ship any changelogs? | 10:28 |
| * persia reads every changelog for every package installed, but understands this is not a typical level of paranoia | 10:29 | |
| broonie | persia: They're useful if something breaks or you're interested; they just shouldn't be essential reading for everyone. | 10:29 |
| seb128 | persia: waouh, so when upgrading a box from dapper to hardy you read over 1000 changelog, I'm impressed ;-) | 10:29 |
| persia | broonie: That makes sense to me. What doesn't make sense is specifically stripping changelogs from only CDBS packages that don't use the DEB_CHANGELOGS_ALL variable. | 10:30 |
| persia | seb128: Well, I did it in stages, but yes. | 10:30 |
| seb128 | persia: nobody said this change was perfect, it was required to win CD space and easy to do | 10:30 |
| persia | seb128: Understood. Note my lack of complaint about it during the hardy cycle, and further that my request was that it was either dropped or documented. | 10:31 |
| seb128 | persia: or you are welcome to suggest a better way which doesn't imply adding ubuntu specific changes to every packages on the CD | 10:31 |
| lool | doko: #224110 for the java issue I mentionned yesterday | 10:31 |
| lool | It's due to unionfs | 10:31 |
| persia | Personally, I think a build-system hook is a better way to do it | 10:31 |
| seb128 | what do you call "build-system hook"? | 10:32 |
| lool | I agree with persia, but I fail to reconcile that maintainers want the changelogs shipped on the installed system and that the installed system is copied from the live CD | 10:32 |
| persia | seb128: As an example, there could be a package that overrides dpkg-deb to strip /usr/share/doc/*changelog*/ when building binaries. | 10:33 |
| lool | It would require network to e.g. reinstall the missing changelog files after a live CD install | 10:33 |
| seb128 | persia: I though you didn't want to strip changelogs and now you want to do it for the whole archive, | 10:33 |
| seb128 | ? | 10:33 |
| lool | seb128: Only for CD builds I guess, as this is where we want to save space | 10:33 |
| persia | seb128: I personally like changelogs. I understand they don't make sense for the CD. The current implementation of stripping in CDBS seems like a suboptimal solution to me. | 10:34 |
| seb128 | persia: it is, as said it was easy and did the job | 10:34 |
| persia | seb128: Sure. I'm not arguing the past decision. Only commenting as we're starting a new cycle, and this would be the time for such changes, if we wanted them. My main concern was that if we wanted to keep the changelog stripping in CDBS, it be documented in the CDBS changelog. | 10:35 |
| seb128 | nobody argued against that and pitti said the he will do the change | 10:36 |
| seb128 | I had the impression you were arguing against the change rather than asking to get it documented though | 10:36 |
| pitti | persia: already happened | 10:36 |
| cjwatson | pitti: have you seen http://liorkaplan.wordpress.com/2008/04/27/why-does-ubuntu-puts-firefox-transalation-in-gnomes-language-pack/#comments ? | 10:45 |
| cjwatson | (err, - #comments) | 10:45 |
| pitti | cjwatson: I didn't, looking | 10:47 |
| pitti | cjwatson: -gnome was actually a deliberate choice, since Riddell didn't want them on the Kubuntu CDs by default; the package description is indeed wrong, though; fixing in langpack-o-matic | 10:48 |
| cjwatson | there's a comment about upgrade path problems | 10:49 |
| pitti | it seems that we wanted the old m-f-locale-* packages to stick around for ffox2, instead of becoming transitional packages pointing to language-pack-gnome-XX | 10:51 |
| james_w | pitti: I can't speak officialy for Xubuntu, but a number of recent uploads have resynchronised on the Debian packaging, so it may well be on the way out. | 10:52 |
| pitti | james_w: I left it in for now | 10:53 |
| cjwatson | pitti: maybe they should depend on language-pack-gnome-XX as well | 10:53 |
| cjwatson | it's a bit ugly, but ... | 10:53 |
| pitti | at least it does upgrades 'more' correctly | 10:53 |
| pitti | asac: ^ WDYT? could be worth an SRU | 10:53 |
| asac | pitti: whats the proposal? | 10:54 |
| asac | Id love to move the translations to the real langpacks | 10:54 |
| pitti | asac: have m-f-locale-XX depend: on l-pack-gnome-XX | 10:54 |
| pitti | asac: to get an upgrade path | 10:54 |
| asac | pitti: that would help upgraders, but not kubuntu users ... firefox is surely used by most kubuntu users as well. | 10:56 |
| pitti | asac: but that would DTRT for them? | 10:56 |
| pitti | cjwatson: I commented on the blog, thanks for the pointer | 10:57 |
| soren | cjwatson: Did we enable the edd magic in the kernel by default for hardy? | 10:57 |
| pitti | asac: s/most/some/, but either way, if they install m-f-locale-XX on Kubuntu, they should get the langpack on upgrade to retain translations | 10:57 |
| pitti | cjwatson, doko: FYI, cdbs merged, tested, uploaded | 10:58 |
| pitti | any other quasi-toolchain packages which come to your mind? | 10:58 |
| pitti | make isn't significantly newer in Debian, that can go through auto-syncs | 10:58 |
| === davmor2 is now known as davmor2_away | ||
| doko | maybe autoconf/automake, I'll prepare python2.5 as well | 10:59 |
| pitti | ah, good point | 10:59 |
| pitti | both are syncs, though | 10:59 |
| pitti | so we can't hold them in unapproved; they should be synced after your toolchain bits built | 10:59 |
| cjwatson | soren: can't do so by default, but you can boot with edd=on to get it | 11:02 |
| cjwatson | soren: (it causes some machines to hang for a few minutes on boot, and I think may even cause some machines to fail to boot altogether) | 11:02 |
| soren | cjwatson: Ok. I just noticed something about EDD fly by when I booted one of my machines. | 11:02 |
| asac | pitti: yes that should do the right thing for upgraders. but given that most users likely indirectly installed m-f-locale-XX through language-support-XX i still think that the real bug is the -gnome demotion here. | 11:03 |
| lool | pitti: Would it make sense to offer ddebs for ppas? | 11:07 |
| lool | We use a ppa for ubuntu-mobile and I guess many development/testing happens in ppa; could be cool to have ddebs there too | 11:08 |
| pitti | lool: would certainly be nice, but it's (a) a question of storage space, and (2) a question where to process them | 11:08 |
| pitti | lool: I'd really like soyuz to support ddebs; the current hack is very brittle | 11:08 |
| pitti | and it's going to get much worse with more ddebs | 11:08 |
| * pitti sighs at apt-ftparchive being so ridiculously slooooooooow | 11:09 | |
| pitti | macaroni.ubuntu.com is busy all day with updating the archive :/ (three runs a day) | 11:09 |
| lool | pitti: apport doesn't work for me on mobile after I enabled it and rebooted it; I wondered whether amitk could check which bits wouldn't be enabled in the kernel, but he doesn't know which these are | 11:10 |
| lool | pitti: Do you have the CONFIG_ flags in mind? Or perhaps we lack something | 11:10 |
| wgrant | pitti: Let me guess - they're going to implement it post-2.0? | 11:10 |
| pitti | lool: it doesn't need anything particular from the kernel since 2.6.23 | 11:11 |
| lool | amitk: ^ | 11:11 |
| pitti | wgrant: I don't know | 11:11 |
| lool | amitk: So nevermind | 11:11 |
| lool | pitti: What could explain that it doesn't save a crash on sigsegv? | 11:11 |
| pitti | lool: is apport set in /proc/sys/kernel/core_pattern ? | 11:11 |
| lool | Yes | 11:12 |
| amitk | lool: I had no idea it ever required kernel support :) Learnt something new | 11:12 |
| pitti | lool: what does "/usr/share/apport/testsuite/test-apport kernel" say? | 11:12 |
| pitti | amitk: it did until feisty | 11:12 |
| lool | * Check that empty core dumps do not generate a report | 11:12 |
| lool | Traceback (most recent call last): | 11:12 |
| lool | File "/usr/share/apport/testsuite/test-apport", line 174, in <module> | 11:12 |
| lool | assert app.wait() == 0, app.stderr.read() | 11:12 |
| lool | AssertionError | 11:12 |
| lool | /proc/sys/kernel/crashdump-size doesn't exist | 11:13 |
| lool | Nor does it on my desktop though | 11:13 |
| pitti | lool: why should it exist? that's from edgy or feisty's Ubuntu kernel patch | 11:15 |
| pitti | lool: can you remove /var/log/apport.log, run the test again, and pastebin apport.log? | 11:15 |
| lool | pitti: Nothing in apport.log | 11:16 |
| lool | pitti: I just told you about /proc/sys/kernel/crashdump-size as I saw it pass while set -x-ing the apport init script; didn't know whether it was relevant or not | 11:17 |
| pitti | hm | 11:17 |
| pitti | lool: the init script just sets core_pattern | 11:17 |
| pitti | but the test suite complains if it isn't set, so that's fine | 11:17 |
| pitti | lool: what does this say? echo foo | sudo /usr/share/apport/apport $$ 42 0 | 11:21 |
| pitti | lool: erm, you can drop the sudo, sorry | 11:22 |
| lool | apport (pid 5753) Tue Apr 29 10:23:06 2008: cannot create lock file (uid 1000): | 11:23 |
| lool | pitti: Ok, owner/group issue with our user | 11:23 |
| lool | pitti: thanks | 11:23 |
| lool | pitti: Hmm actually the only difference in groups between my desktop user and the ume mobile user are powerdev and netdev | 11:25 |
| lool | Hmm for some reason I see crashes in /var/crash now | 11:25 |
| lool | pitti: Probably where you expected me to grab the log file I guess | 11:26 |
| pitti | lool: the log file is in /var/log | 11:26 |
| pitti | lool: ah, /var/crash was unwritable? | 11:26 |
| pitti | lool: powerdev/netdev are irrelevant, yes | 11:26 |
| lool | pitti: I don't see a log file | 11:26 |
| pitti | lool: the command I gave you from above writes to stderr, not to a log | 11:27 |
| lool | pitti: All it gave was that permission error | 11:27 |
| pitti | lool: right, so /var/crash/ is unwritable for you | 11:27 |
| pitti | lool: drwxrwxrwt 2 root root 4096 2008-04-29 12:22 /var/crash/ | 11:27 |
| pitti | ^ default in Ubuntu | 11:27 |
| pitti | (1777) | 11:28 |
| lool | drwxrwxrwt 2 root root 4096 Apr 29 10:23 /var/crash/ | 11:28 |
| lool | pitti: It's set by the init script | 11:28 |
| lool | So should be ok here too | 11:28 |
| lool | pitti: This is on unionfs | 11:28 |
| lool | Should be similar to the live CD | 11:28 |
| pitti | lool: hm, what's wrong with /var/crash/.lock? | 11:28 |
| lool | That one is root | 11:29 |
| lool | -rwxr-xr-x 1 root root 0 Apr 29 09:59 /var/crash/.lock | 11:29 |
| Keybuk | pitti: it's rebuilding atm | 11:29 |
| pitti | lool: ah; please try to remove it | 11:29 |
| lool | pitti: Shall I wipe it? | 11:29 |
| lool | Sure | 11:29 |
| pitti | lool: otherwise the test suite and above command need to run as root | 11:29 |
| pitti | Keybuk: yay | 11:29 |
| lool | apport (pid 6242) Tue Apr 29 10:30:23 2008: executable: /persistmnt/bin/cat (command line "/bin/cat") | 11:30 |
| lool | apport (pid 6242) Tue Apr 29 10:30:23 2008: executable does not belong to a package, ignoring | 11:30 |
| lool | pitti: Looks like an unionfs issue | 11:30 |
| lool | pitti: Pathname is guessed wrong | 11:30 |
| lool | Just like in #224110 | 11:30 |
| pitti | ah | 11:30 |
| lool | I guess it's read from /proc | 11:30 |
| pitti | /proc/$$/exe symlink wrong then? | 11:31 |
| lool | Is it working from Ubuntu live CDs? | 11:31 |
| pitti | lool: not 100% sure TBH | 11:31 |
| lool | /proc/6231/exe: symbolic link to `/persistmnt/bin/bash' | 11:31 |
| lool | Yes | 11:31 |
| pitti | lool: aah, it doesn't, but apport has a hack for this | 11:31 |
| pitti | if self['ExecutablePath'].startswith('/rofs/'): | 11:31 |
| pitti | self['ExecutablePath'] = self['ExecutablePath'][5:] | 11:31 |
| pitti | apport/report.py ^ | 11:32 |
| lool | pitti: Too bad we don't use the same name for the mountpoint :-/ | 11:32 |
| pitti | lool: you can try changing report.py locally for the /persistmnt/ prefix | 11:32 |
| lool | pitti: Also, packages which be installed afterwards, you should also allow the casper / rw one perhaps | 11:32 |
| Keybuk | pitti: it was killed by the debian ftp-master problems a while back | 11:32 |
| Keybuk | and it takes a while for bad data to leave it's head | 11:32 |
| cjwatson | apostrophe! | 11:33 |
| Keybuk | cjwatson: coffee! | 11:34 |
| lool | pitti: So what would you think of apport parsing /proc/mounts looking whether / is unionfs and extracting the dirs= attribute from there as a list of prefixes to optionally strip? | 11:36 |
| pitti | lool: I think it'd be a nasty workaround for an unionfs bug :/ | 11:37 |
| lool | I agree unionfs shall be fixed; I added a tasklet to this effect on the bug I mentionned earlier but TBH I'm not holding my breath | 11:38 |
| pitti | right; in the meantime, it's less intrusive and more robust to add particular prefix special cases to report.py IMHO | 11:39 |
| pitti | especially if we want to SRU this | 11:39 |
| lool | What's the read-write partition on live CDs? /rwfs? | 11:41 |
| pitti | seb128: hm, re gphoto fs etc, why don't we get a fuse mount for gvfs virtual file systems like gphoto? eog, gthumb, CLI etc. could use that fuse mount then | 11:45 |
| pitti | seb128: (context: gnome bug 530371) | 11:46 |
| ubot5 | Gnome bug 530371 in general "fails to open pictures on gphotofs" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=530371 | 11:46 |
| cjwatson | lool: /rofs | 11:46 |
| cjwatson | err | 11:46 |
| cjwatson | sorry, misread. it's /cow but in practice not usually accessible as such from outside the initramfs | 11:46 |
| cjwatson | unless you boot with showmounts | 11:46 |
| lool | cjwatson: Wont programs installed from the live CD return pathnames below /cow in /proc/self/exe? | 11:47 |
| cjwatson | maaaaaaybe | 11:48 |
| * cjwatson would not like to make bets without testing | 11:48 | |
| lool | I think so, as it happened to us in the UME unionfs | 11:48 |
| cjwatson | in any case I meant not usually visible as a mount point in the filesystem; I wasn't arguing with the /proc/self/exe problem | 11:48 |
| lool | Thanks for the pathname | 11:49 |
| lool | pitti: Could you check lp:~lool/apport/ubuntu from an apport upstream perspective and then as a SRU candidate? It now passes the kernel testsuite for me | 11:54 |
| lool | (still pushing though) | 11:54 |
| ogra | cjwatson, depends .... | 11:54 |
| pitti | lool: can you also run the entire test suite? | 11:55 |
| pitti | /usr/share/apport/testsuite/run-tests | 11:55 |
| lool | (pushed now) | 11:55 |
| cjwatson | ogra: casper's default is not to expose it | 11:55 |
| cjwatson | 11:46 <cjwatson> unless you boot with showmounts | 11:55 |
| ogra | cjwatson, depends .... gvfs lists the devices in "places" if certain conditions arent fulfilled that makes it ignore them | 11:56 |
| lool | pitti: http://paste.ubuntu.com/8707/ | 11:56 |
| lool | One failure; looks unrelated to the change | 11:56 |
| ogra | cjwatson, reading from /proc/mounts | 11:56 |
| pitti | lool: hm, might be a problem with unionfs' handling of mtime | 11:56 |
| lool | Indeed | 11:56 |
| pitti | lool: could you please comment out that assertNotEqual and run it again? | 11:57 |
| pitti | lool: if it's the only failure, it should be ok | 11:57 |
| pitti | lool: (reason: the following tests are not run any more after a failure) | 11:57 |
| seb128 | pitti: we do get a fuse mount for those, nautilus just pass the uri and not the fuse path to those applications | 11:58 |
| pitti | seb128: oh, that would be the problem then | 11:58 |
| seb128 | pitti: http://bugzilla.gnome.org/show_bug.cgi?id=528670 is the patch fedora is using | 11:59 |
| ubot5 | Gnome bug 528670 in gio "Only pass gio uri's to applications known to use gio" [Normal,Unconfirmed] | 11:59 |
| ogra | cjwatson, i realize that ume is different though | 11:59 |
| seb128 | pitti: the add a special tag to the .desktop to say what application support gio and pass the fuse path when they don't | 11:59 |
| lool | pitti: http://paste.ubuntu.com/8709/ | 11:59 |
| lool | (I had to set LANG) | 11:59 |
| seb128 | pitti: they did the change late to get it in hardy though, but I would like to get that in 8.04.1 if possible | 11:59 |
| pitti | lool: you have to clean up /var/crash/ before, as it says | 12:00 |
| pitti | lool: I just wonder what's wrong with the python crashes | 12:00 |
| lool | I remain with that crash after removing the other crashes | 12:01 |
| lool | (The crash to remove was the one from the other testsuite run) | 12:01 |
| lool | pitti: I get other errors when running the testsuite on my amd64 desktop with the hardy version; could you perhaps run the testsuite with the two versions and see whether it regresses? | 12:06 |
| lool | You're better qualified than me to decide which tests to ignore and which not :) | 12:07 |
| pitti | lool: two versions? you mean from your branch? | 12:07 |
| lool | Yes | 12:07 |
| pitti | lool: does it regress? or is the hardy final one producing the same? | 12:07 |
| * pitti checks out the branch | 12:07 | |
| lool | I don't know whether it regresses; I'd have to disabled all the failing hardy tests to run it in full | 12:07 |
| pitti | ok | 12:08 |
| * lool lunch & | 12:09 | |
| pitti | lool: that change looks ok to me, FWIW | 12:09 |
| pitti | lool: running tests now | 12:09 |
| lool | (I also confirm it also made my crashing app create a crash file \o/ -- had to empty the battery to reproduce the bug) | 12:11 |
| pitti | lool: btw, the easiest (known to me) way to test this is: bash -c 'kill -SEGV $$' | 12:12 |
| sistpoty|work | can an archive admin please copy xmms-crossfade from hardy-proposed to hardy-updates? (bug #208666) | 12:14 |
| pitti | sistpoty|work: this is barely a day old; we usually let them mature a little longer? | 12:15 |
| pitti | sistpoty|work: for this bug 7 days are probably too long, though | 12:16 |
| sistpoty|work | pitti: I've talked to jdong and DktrKranz2 yesterday, they were ok with it | 12:16 |
| sistpoty|work | (and it's a rebuild only :) | 12:16 |
| pitti | sistpoty|work: ok, done | 12:17 |
| sistpoty|work | pitti: oh, btw.: the 7 day delay is no longer in the StableReleaseUpdates wiki. maybe it should be added again? | 12:17 |
| sistpoty|work | thanks pitti! | 12:17 |
| emgent | heya | 12:17 |
| pitti | sistpoty|work: ugh, yes | 12:17 |
| pitti | sistpoty|work: it's on https://wiki.ubuntu.com/ArchiveAdministration#head-1f27dc12ab1558ec21b31ac44e4c86a87a4cd053 | 12:18 |
| pitti | sistpoty|work: since it doesn't belong to the steps that the uploading developer has to do | 12:18 |
| sistpoty|work | pitti: ah, thanks for clarification :) | 12:19 |
| pitti | lool: merged into ubuntu branch and pushed; thanks! | 12:27 |
| * Hobbsee pokes dholbach | 12:48 | |
| dholbach | hi Hobbsee | 12:48 |
| Hobbsee | dholbach: heya. query? | 12:49 |
| === ryu2 is now known as ryu | ||
| dholbach | Hobbsee: sure | 12:49 |
| lool | pitti: Thanks; let me know if you want me to upload it | 12:57 |
| lool | During lunch, I realized this is also probably the explanation for services failing to stop on mobile | 12:57 |
| lool | Like acpid and hal | 12:57 |
| lool | I'd bet on start-stop-daemon being hit by this too | 12:57 |
| pitti | lool: please prepare an SRU bug for it | 12:57 |
| pitti | lool: you should upload it as 7.1, since I have an ubuntu8 UNRELEASED in trunk (with another change) | 12:58 |
| wgrant | (and 7.1 is proper, recognisable SRU versioning...) | 12:59 |
| emgent | heya wgrant | 13:01 |
| seb128 | wgrant: .1 is a debian NMU versionning rather | 13:01 |
| wgrant | seb128: Not if it's after ubuntu, like it would be here. | 13:02 |
| seb128 | wgrant: still, if we want a SRU naming policy we should not get one and not rely on NMU numbers or not | 13:05 |
| seb128 | wgrant: I usually just do ubuntu<n+1> | 13:05 |
| wgrant | seb128: Everybody else uses ubuntuN.1 | 13:06 |
| ogra | isnt that security versioning ? | 13:06 |
| wgrant | ogra: It is. | 13:06 |
| ogra | and is it a security update or a SRU bugfix ? | 13:06 |
| wgrant | The schemes in common use are identical. | 13:07 |
| seb128 | wgrant: that's wrong, there is uploads from 5 people using "n+1" which have been accepted to hardy this morning | 13:07 |
| ogra | wgrant, nope | 13:08 |
| wgrant | ANd I've got no idea why. That's release versioning. | 13:08 |
| seb128 | wgrant: you are inventing a rule there | 13:08 |
| cjwatson | the reason to use ubuntuN.1 is if you aren't sure whether ubuntu<N+1> will be in use in the next release, or know that it is | 13:09 |
| seb128 | wgrant: the only condition is that the hardy upload version has to be smaller than the intrepid one | 13:09 |
| cjwatson | if you know that ubuntu<N+1> won't be used in the next release, it's OK to use it | 13:09 |
| cjwatson | seb128: versions also have to be unique, so the hardy version has to have never been used in intrepid | 13:09 |
| wgrant | Why don't we have an official standard? | 13:10 |
| cjwatson | it's not necessary | 13:10 |
| seb128 | right | 13:10 |
| cjwatson | the standard is "don't reuse version numbers" | 13:10 |
| cjwatson | (and obviously the stuff about "ubuntu" inhibiting autosync) | 13:10 |
| cjwatson | exactly how you choose to achieve that is up to you | 13:10 |
| ogra | given that we merge at every release cycle begin it is very likely that a package switches to -Xubuntu1 again with a new debian version for most of the packages | 13:11 |
| ogra | i think the case for having a higher ubuntuX in -updates is qute rarely possible thourgh that | 13:11 |
| cjwatson | I think it's quite reasonable to default to ubuntuN.1 since it's almost always safe (NOTE NOT ALWAYS) but there's no reason to complain about ubuntu<N+1> either | 13:12 |
| stgraber | soren: Hi, I'm playing with kvm and the socket nic. I have a LTSP server listening to a local port and another qemu connecting to it as client. Everything seems extremely slow (I would say <1Mbit/s). Is that normal, do you know how fast is the socket nic supposed to be ? | 13:13 |
| cjwatson | the caveat to the above is that if you're e.g. doing simultaneous SRUs to gutsy and hardy and they have the same base version number then you need to choose different version numbers for each | 13:13 |
| cjwatson | so the simple policy is "don't reuse version numbers" and let developers sort it out | 13:13 |
| ogra | well, its also getting more tricky to tell security updates from normal <release>-updates | 13:14 |
| ogra | if you use ubuntuX.1 in SRUs | 13:14 |
| cjwatson | you tell security updates from normal updates by looking at the index files | 13:14 |
| cjwatson | any attempt to do so by version numbers is doomed to unreliability | 13:15 |
| soren | stgraber: I've never actually used that, actually. | 13:15 |
| lool | pitti: You mean 0.108.1? | 13:15 |
| soren | stgraber: <1Mbit/s sounds insane, though. | 13:15 |
| pitti | lool: right, sorry | 13:15 |
| lool | Why do we use .1 and not ~hardy1? | 13:15 |
| cjwatson | X.Y~hardy1 < X.Y | 13:16 |
| seb128 | because your suggestion version is smaller? | 13:16 |
| cjwatson | we loosely reserve that for backport versioning | 13:16 |
| seb128 | suggested | 13:16 |
| lool | cjwatson: Yeah 109~hardy1 or 108+hardy1 | 13:16 |
| cjwatson | then you have to predict the next version number | 13:16 |
| cjwatson | you can do that if you like, but it's generally much easier to do it by appending something without ~ | 13:16 |
| seb128 | ogra: did you read the comments on http://bugzilla.gnome.org/show_bug.cgi?id=526320? | 13:17 |
| ubot5 | Gnome bug 526320 in gio "should not list mounts that the user doesn't have permission to use" [Normal,Resolved: fixed] | 13:17 |
| lool | Well I would like to use the same versioning scheme in all cases | 13:17 |
| lool | So +hardy1 for instance | 13:17 |
| ogra | seb128, i wont switch ltspfs (which is also widely used in telnet sessions without gui) to mount a hidden dir anywhere ... and i'm also not fond of mounting anywhere in users home dirs (i still wonder how that got past the debian devs for gvfs, i always thought its a general rule to not muck around with homedirs) | 13:18 |
| ogra | seb128, /media is defined as the point to mount user accessible stuff on system level, so ltspfs will go on using it, there is not only gnome in this world :) | 13:19 |
| lool | Ok; no particular reason I guess, just no specification and no desire to define this | 13:19 |
| cjwatson | I do worry that schemes involving the release name will break just after Ubuntu 17.04 and we'll have to figure something out for that | 13:20 |
| seb128 | ogra: hum, are those comment in reaction to something written in the bug I pointed right now? | 13:20 |
| cjwatson | unfortunately we (I think mistakenly) selected ~name1 rather than ~version.1 as the usual backports scheme | 13:20 |
| lool | cjwatson: We do have time, but faced with the same issue I opted for ~804 and +804 version numbers for ume | 13:20 |
| lool | For backports and branches respectively | 13:20 |
| cjwatson | yeah, no rush, it just needs to be sorted out at some point. FWIW I believe that the security team has appended .8.04.1 in similar circumstances. | 13:21 |
| lool | Well ~804um1 etc. to be precice | 13:21 |
| ogra | seb128, err, sorry wrong bug number, i didnt look and assumed you mean the duplicate from yesterday | 13:21 |
| lool | *precise | 13:21 |
| ogra | seb128, (where david suggested to use ~/.ltspfs | 13:21 |
| ogra | ) | 13:21 |
| ogra | seb128, err ... why did david make all this fuss about "omg we cant use access() it will break everything" ?? | 13:23 |
| ogra | seb128, that 0750 change warren did is moot | 13:23 |
| ogra | once its mounted ltspfs will refuse acces even to root | 13:23 |
| seb128 | because he says that access() can block in case of broken nfs configs, etc | 13:23 |
| ogra | only the ownler can look inside | 13:23 |
| ogra | seb128, but his last attachment uses it | 13:24 |
| seb128 | ogra: right, I don't really understand what he did, the comment before the patch was going one level down | 13:24 |
| ogra | seb128, the gvfs patch looks ine to me, i can adjust the one line in ltspfs if needed (i really doubt it is for us though) | 13:25 |
| ogra | *fine | 13:25 |
| lool | pitti: https://bugs.launchpad.net/ubuntu/hardy/+source/apport/+bug/224168 | 13:25 |
| ubot5 | Launchpad bug 224168 in apport "Breaks in more unionfs use cases" [Undecided,Fix committed] | 13:26 |
| lool | pitti: (uploaded) | 13:26 |
| seb128 | ogra: that's a glib patch, but good ;-) | 13:26 |
| ogra | seb128, whatever helps :) | 13:26 |
| seb128 | ogra: I'll sru that | 13:26 |
| ogra | thanks :) | 13:26 |
| ogra | i'll test and act accordingly | 13:26 |
| seb128 | ogra: arg, it goes down one level | 13:28 |
| ogra | ? | 13:28 |
| seb128 | ogra: for /media/ltsp it'll g_access /media | 13:28 |
| seb128 | g_path_get_dirname() does that | 13:28 |
| ogra | there is no /media/ltsp | 13:28 |
| ogra | oh | 13:29 |
| seb128 | that was a mountpoint example | 13:29 |
| ogra | it us /media/$USER/<devicename> | 13:29 |
| seb128 | so that's what he commented before | 13:29 |
| ogra | at least in the ltspfs we use | 13:29 |
| seb128 | you use that naming? | 13:29 |
| ogra | yes, since ltspfs exists | 13:29 |
| seb128 | ok, so it'll stat /media/$USER, does that work for you? | 13:29 |
| ogra | yup | 13:29 |
| seb128 | ok, still it doesn't fix the original bug | 13:29 |
| ogra | /media/$USER also wont exist if ther is no device | 13:30 |
| seb128 | does using access() on /media/something where /media/something is a nfs mount can block? | 13:30 |
| ogra | its created dynamically during the ltspfs mount | 13:30 |
| ogra | i doubt that | 13:30 |
| seb128 | ie, does it look at the local directory permissions or does it try accessing the nfs? | 13:30 |
| ogra | we had many nfs home users in feisty edgy and gutsy | 13:30 |
| ogra | nobody ever complained that gnome-vfs was any issue | 13:30 |
| ogra | the access patch was there since edgy | 13:31 |
| seb128 | that's what I commented upstream | 13:31 |
| stgraber | soren: and a ping to the other computer returns 5 DUPS :) something seems to be wrong with that socket thing | 13:31 |
| stgraber | (or me using it not correctly) | 13:31 |
| seb128 | "It's surely an issue for networked mounts (nfs, autofs, some fuse based stuff) | 13:31 |
| seb128 | that times out. Then we hang calling access() and as a result GNOME logins etc. | 13:31 |
| seb128 | will fail when a mount times out because we hang in the volume monitor instance | 13:31 |
| seb128 | of every process (panel, nautilus, settings daemon all instantiate a volume | 13:31 |
| seb128 | monitor)." | 13:31 |
| seb128 | hum | 13:32 |
| seb128 | I don't know enough about those to know if that's true or not | 13:32 |
| seb128 | anybody here who has a clue if an access() call on a nfs mountpoint can hang? | 13:32 |
| ogra | seb128, we did access() calls with the old patch | 13:33 |
| ogra | it didnt hang for three releases | 13:33 |
| ogra | i dont think it will just start hanging now | 13:33 |
| seb128 | maybe you didn't have nfs server timeout or other similar issues? | 13:33 |
| seb128 | and in case you did that's enough to break ltsp anyway no? | 13:33 |
| ogra | seb128, many of my ltsp/edubuntu users use nfs or samba mounted homedirs | 13:33 |
| seb128 | right, in which case nfs being broken screw your session | 13:34 |
| ogra | and the access() call was issued for *every* mount in gnome-vfs with pittis patch | 13:34 |
| seb128 | would be interesting to test when you have a secondary nfs mount, ie something you don't rely on to use your computer | 13:34 |
| seb128 | right, but I'm not sure nobody had issues with that | 13:35 |
| ogra | all your nfs mounts would always have caused issues | 13:35 |
| ogra | if access() really would cause hangs | 13:35 |
| ogra | you would have seen it all over the board | 13:35 |
| seb128 | ogra: ok, what I though but I'm just guessing from the feedback we got and I don't know the topic well enough to argue upstream about that | 13:37 |
| ogra | i'm just relying on experience ... LP would drown in nfs bugs if upstream were right | 13:37 |
| ogra | since years | 13:37 |
| === davmor2_away is now known as davmor2 | ||
| ogra | seb128, i'm not sure how gvfs changed here though that it could start becoming an issue through the new design | 13:39 |
| ogra | it definately didnt cause issues in gnome-vfs to use access() on nfs mounts | 13:39 |
| seb128 | well, my question was really "can an access() call on a nfs mountpoint block" | 13:40 |
| seb128 | what I would like is to know that, not to guess based on the fact that gnome-vfs might have been handling a blocking call correctly | 13:40 |
| === danielm_ is now known as danielm | ||
| ogra | seb128, right, i cant judge the gvfs setup here, i can only judge by experience with gnome-vfs | 13:45 |
| ogra | (which has proven that access() alone wont do harm, but the way you use it certainly has influence here) | 13:46 |
| seb128 | ogra: the question is really about the access() system call, not about gvfs ;-) | 13:46 |
| ogra | well, david (proxied through warren) told me that gvfs works differently and gnome-vfs used a separate thread to get the access info for example ... if gvfs is doing it from the main thread and there is a block it might have issues | 13:47 |
| seb128 | ogra: right, that's what I said | 13:48 |
| ogra | seb128, but according to the bug david has checked it in anyway upstream | 13:49 |
| seb128 | what? the patch? | 13:49 |
| seb128 | yes, it fixes your ltsp case | 13:49 |
| ogra | "Which, for reasons explained above, is the best we can do. So I'm closing this | 13:49 |
| ogra | bug as FIXED. | 13:49 |
| ogra | " | 13:49 |
| ogra | and above comment has a checkin message | 13:50 |
| seb128 | but it doesn't fix the case from the bug description | 13:50 |
| ogra | did you try ? | 13:50 |
| seb128 | /media/usbkey-uid1000 should not be listed for other users | 13:50 |
| seb128 | no, I don't need to | 13:50 |
| ogra | right | 13:50 |
| seb128 | the patch call g_access() on /media in this case | 13:50 |
| seb128 | it'll only work in the /media/$USER/mount ltsp case | 13:51 |
| ogra | seb128, why cant the access() call just get a timeount added | 13:53 |
| ogra | he just needs to wrap it in a g_timeout ... | 13:54 |
| seb128 | because the mount listing has to be something fast | 13:54 |
| ogra | for access() ? | 13:54 |
| seb128 | the whole thing | 13:54 |
| ogra | well, i mean to avoid a constant blocking | 13:55 |
| seb128 | you want an async api, but that would complicate things a lot | 13:55 |
| seb128 | right now you can do a sync call to get the mounts list | 13:55 |
| ogra | you call access() anyway .... david says that would block if there is a stale montpoint so just return after a timeout ad gve back "False" | 13:55 |
| seb128 | and be sure it'll return quickly | 13:55 |
| seb128 | you don't want nautilus and the panel waiting 30s on a nfs timeout because they refresh the mounts list | 13:56 |
| seb128 | and doing async operations make things much harder | 13:56 |
| ogra | so it either will return quickly or in case of a stale mount wait a second to give it a chance to react and then return false | 13:56 |
| ogra | stale nfs mounts are not the regular thing usually | 13:57 |
| seb128 | right, but now you are turning some clean code to workarounds and they want to avoid that | 13:57 |
| ogra | hmm | 13:58 |
| * ogra wonders if there isnt a way to determine the owner of a dir without using access() | 14:04 | |
| seb128 | there is no magically way, if you try to stat a nfs mounted directory you will hand the same way | 14:05 |
| seb128 | what we need is a way to know what is local and only try on those | 14:05 |
| ogra | well, but you said they want to avoid workarounds, th epatch i see now being added operates on the amount of direcory layers ? thats a workaround as well (and less asne imho) | 14:06 |
| ogra | *sane | 14:06 |
| seb128 | I don't say I consider the patch a good idea ;-) | 14:07 |
| ogra | unless you have /media on nfs there is no possibility to make it non local with ltspfs | 14:07 |
| === asac_ is now known as asac | ||
| ogra | ltspfs mounts will always be local for the user POV | 14:07 |
| seb128 | right, the thing is that we can iter over the media mountpoints | 14:08 |
| seb128 | you can have | 14:08 |
| seb128 | usbkey | 14:08 |
| seb128 | ltspdir | 14:08 |
| ogra | and yes, it doesnzt fix the initial issue at all | 14:08 |
| seb128 | nfs | 14:08 |
| seb128 | anyway I'll think about it | 14:08 |
| ogra | can you check for filesystems of mounts ? | 14:08 |
| seb128 | the current change will work for ltsp at least | 14:08 |
| ogra | ltspfs identifies itself as ltspfs | 14:08 |
| seb128 | that will not work for fuse mounts for example | 14:09 |
| ogra | so special casing is possible at least | 14:09 |
| ogra | ltspfs is fuse :) | 14:09 |
| ogra | its just a kind of autofs wrapper around it | 14:09 |
| dneary | mjg59: Ping? | 14:10 |
| dneary | Suspend/resume worked fine with the LiveCD | 14:10 |
| cody-somerville | dneary, What about hibernate? :P | 14:11 |
| ogra | cody-somerville, is disabled dleiberately | 14:12 |
| ogra | (you dont have the button in the ui at least) | 14:13 |
| * cody-somerville winks. | 14:13 | |
| ogra | it could work with enough swapspace and some hacking in casper i bet :) | 14:13 |
| cody-somerville | If it wasn't such a useless feature, I'd think about adding support to hibernate to NTFS drives. | 14:13 |
| mjg59 | dneary: Ok, interesting | 14:22 |
| mjg59 | dneary: How are you triggering the suspend? | 14:22 |
| dneary | I followed the suggestion of someone yesterday who pointed me at a bug report, and created a WORKAROUND file into which I put a suspend line | 14:22 |
| dneary | Can't find the exact command now - the link to the bug is in my blog | 14:23 |
| dneary | mjg59: Either manually with Fn-Veille, or by shutting the lid | 14:23 |
| dneary | With the LiveCD, I tried both | 14:23 |
| dneary | Both worked, once I'd configure gnome-power-manager to suspend when shutting the lid | 14:24 |
| dneary | There's that thing I tried (deleting the WORKAROUND file now, since the problem's still there): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/211572 | 14:28 |
| ubot5 | Launchpad bug 211572 in linux "[Hardy] [regression] ehci_hcd.ko breaks suspend-to-ram" [Undecided,Confirmed] | 14:28 |
| mjg59 | dneary: As root, does pm-suspend work and resume correctly? | 14:28 |
| mjg59 | dneary: Oh, and you said you had some sort of upgrade issue - are you running the 2.6.24 kernel? | 14:29 |
| dneary | dneary@sligo:/etc/pm/config.d$ uname -a | 14:29 |
| dneary | Linux sligo 2.6.24-16-386 #1 Thu Apr 10 12:50:06 UTC 2008 i686 GNU/Linux | 14:29 |
| mjg59 | Yeah, looks right | 14:29 |
| dneary | let me try pm-suspend | 14:29 |
| dneary | I'll join on IRC on a different machine in 2 secs. | 14:30 |
| mjg59 | Ok | 14:30 |
| ogra | 2.6.25 has the usb persistent patch i heard ... | 14:31 |
| bolsh | Hi all | 14:31 |
| bolsh | mjg59: I'm ready to try pm-suspend now | 14:31 |
| dneary | I just run it, right? | 14:31 |
| dneary | Yes, that works | 14:32 |
| dneary | So it's starting to look like I have some acpi hang-over from previous releases? | 14:32 |
| dneary | And NM is making funny faces at me - it's showing that I've got a wired connection, the wifi indicator light is off | 14:33 |
| dneary | but I obviously have wifi, since I can see myself talking | 14:33 |
| ion_ | Sorry, you're just having a psychotic episode; we're not real. | 14:34 |
| mjg59 | dneary: Yeah, that's sounding kind of weird | 14:35 |
| mjg59 | dneary: Try deleting /etc/acpi/sleep.sh and seeing what happens when you select sleep in g-p-m | 14:35 |
| dneary | mjg59: I'd send you my laptop, but you probably don't want it, and I kind of need it :) | 14:36 |
| mjg59 | dneary: Not really my problem as much any more, anyway :) | 14:36 |
| dneary | If I did a dpkg -l *acpi*, would you be able to tell me if there were stuff there that shouldn't be? | 14:37 |
| mjg59 | Nope | 14:37 |
| mjg59 | Only thing I can remotely think of is to make sure you don't have an s2ram binary installed somehow | 14:38 |
| pitti | Riddell, any KDE user: can you confirm bug 212551? apport setu/gids to SUDO_UID and SUDO_GID for opening the browser | 14:38 |
| ubot5 | Launchpad bug 212551 in apport "Kubuntu Adept [Report Bug] launches Konqueror as root" [Undecided,New] https://launchpad.net/bugs/212551 | 14:38 |
| Riddell | pitti: I'm not sure that's being run through apport | 14:42 |
| Riddell | could be just the update tool's crash handler | 14:42 |
| pitti | oh | 14:43 |
| dneary | mjg59: I have acpi-support installed, which installed the sleep.sh script | 14:43 |
| mjg59 | dneary: Yeah, that's correct | 14:45 |
| mjg59 | dneary: My concern is that something's still calling that, which shouldn't happen | 14:45 |
| dneary | So is that to be removed? | 14:45 |
| dneary | ah | 14:45 |
| mjg59 | acpi-support is still needed, but the sleep script is legacy | 14:46 |
| pitti | seb128: hm, do you have any idea what takes so long in the bootchart of bug 184977? | 14:58 |
| ogra | seb128, i wonder if open() would behave differently than stat or access() | 14:58 |
| ubot5 | Launchpad bug 184977 in gnome-volume-manager "session start takes very long" [Medium,Incomplete] https://launchpad.net/bugs/184977 | 14:58 |
| johanbr | mjg59: Isn't there a difference in that the HAL scripts run pm-suspend with some quirks? | 15:01 |
| mjg59 | johanbr: The quirks are all ignored on i915 and higher | 15:02 |
| seb128 | pitti: urg, no, usually those are "loopback is not correctly configured" bugs or "one program registered in the session is buggy" (though the buggy registering should not block everything) | 15:02 |
| seb128 | pitti: I would ask him to try if "ping localhost" is working and maybe to try with an another user account on the same box | 15:02 |
| ogra | there is a lot xfce in that bootchart | 15:03 |
| cody-somerville | ogra, hmm? | 15:11 |
| ogra | seb128, pitti, i would ask him to get away from this desktop mishmash first :) | 15:12 |
| dneary | sorry - was away | 15:19 |
| dneary | Lots to do today | 15:20 |
| pitti | ogra: mishmash? | 15:33 |
| pitti | seb128: thanks! | 15:33 |
| ogra | pitti, it uses xscreensave, xfwm4 and some xfce-mcs processes in that chart | 15:33 |
| ogra | alongside with gnome | 15:34 |
| ogra | pitti, i thik its well possible that he for example added xfwm to a .xsession script instead of setting it in gconf so compiz will still kick in and check if it can run to find another WM is running | 15:35 |
| ogra | (or via the gnome session dialog, which still leaves gconf pointing to compiz) | 15:36 |
| jcwinnie | irc chat for Hardy Heron support is ? | 16:29 |
| ScottK | #ubuntu | 16:29 |
| jcwinnie | no | 16:30 |
| ScottK | Yes | 16:30 |
| jcwinnie | nothing there | 16:30 |
| ScottK | That's it. | 16:30 |
| jcwinnie | just reference to archives | 16:30 |
| jcwinnie | Docs say go there, but nothing there | 16:30 |
| ScottK | Then you didn't actually go there (check your spelling). | 16:30 |
| ScottK | There are 1463 people there right now. | 16:31 |
| norsetto | all of which talking at the same time | 16:31 |
| jcwinnie | k | 16:31 |
| jcwinnie | now I am there | 16:31 |
| jcwinnie | sorry for the interruption | 16:31 |
| ScottK | No problem. | 16:31 |
| norsetto | what do you expect from a kubuntu's user ... | 16:32 |
| persia | A desire to join #kubuntu? | 16:32 |
| norsetto | persia: nice to see you are still alive | 16:33 |
| === toresbe_ is now known as toresbe | ||
| === CarlF1 is now known as CarlFK | ||
| soren | What on earth does ${*-*} mean in bash? | 16:45 |
| seb128 | soren: it's a smiley? ;-) | 16:45 |
| persia | soren: A list of files containing the '-' character in the current directory | 16:46 |
| soren | persia: That's *-*, isn't it? | 16:46 |
| persia | Hmm... Right. | 16:46 |
| persia | But ${...} should only deliminate a reference, so... | 16:47 |
| persia | Err. delineate | 16:47 |
| persia | Err. Nevermind. I can't spell. That thing with lines and separation and stuff. | 16:47 |
| soren | I'll ask the author. It looks quite strange. | 16:48 |
| persia | And this is in bash, and not embedded somewhere, like in a makefile? | 16:49 |
| cjwatson | soren: literally ${*-*}, or ${foo-bar}? | 16:58 |
| cjwatson | ${parameter:-word} | 16:58 |
| cjwatson | Use Default Values. If parameter is unset or null, the expansion of word is substituted. Otherwise, the value of parameter is substituted. | 16:58 |
| cjwatson | could be that (if you omit the colon, you get a test for a parameter being just unset, rather than unset or null) | 16:59 |
| cjwatson | $* expands to all the parameters to the current function or script | 16:59 |
| dneary | cjwatson: You need the : for that | 16:59 |
| cjwatson | no you don't | 16:59 |
| cjwatson | "omitting the colon results in a test only for a parameter that is unset" | 16:59 |
| cjwatson | soren: so ${*-*} would mean "$*, or if $* is unset then the expansion of *" | 17:00 |
| dneary | you learn something new almost every day | 17:00 |
| cjwatson | soren: but it's pretty odd and possibly a mistake | 17:00 |
| dneary | Or obfuscation | 17:00 |
| MitchM | soren, http://wooledge.org:8000/BashFAQ/073 #this is a good reference. | 17:00 |
| cjwatson | note that $* is unset if there are no positional parameters. Try e.g.: | 17:01 |
| cjwatson | foo () { echo ${*-a}; }; foo; foo 1 2 3 | 17:01 |
| cjwatson | so it might actually be a reasonable thing to do if the function within which ${*-*} is used takes filename arguments | 17:02 |
| cjwatson | persia: delimit. :-) | 17:03 |
| persia | cjwatson: Yes. Thank you :) | 17:03 |
| soren | cjwatson: Ah.. Thanks! I didn't know you could leave the colon out. | 17:08 |
| soren | cjwatson: Is that a bash thing or posix sh thing? | 17:08 |
| soren | A bash thing, it seems. | 17:10 |
| cjwatson | soren: POSIX sh | 17:11 |
| soren | Oh, yes, so it is. | 17:12 |
| cjwatson | http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02 "In the parameter expansions shown previously, use of the colon in the format shall result in a test for a parameter that is unset or null; omission of the colon shall result in a test for a parameter that is only unset." | 17:12 |
| soren | Ah, yes, there it is. | 17:15 |
| dneary | So - anyone know what happens when I do a suspend in 8.04? Which commands execute which hooks? | 17:17 |
| dneary | That is, I've configured power management so that when I shut the lid I suspend, but that's apparently doing rather more than just running pm-suspend - I seem to be pulling in acpi scripts too | 17:21 |
| dneary | and they are not playing nively together | 17:21 |
| dneary | So I'd like to try & figure out what's calling what to fix it. | 17:22 |
| mjg59 | dneary: g-p-m calls hal, which executes hal-system-power-suspend-linux | 17:29 |
| dneary | mjg59: and hal-system-power-suspend-linux is a script? | 17:29 |
| mjg59 | Yes | 17:29 |
| dneary | Is it possible for two scripts to be subscribed to the same dbus message? | 17:30 |
| mjg59 | No | 17:30 |
| dneary | (assuming g-p-m goes over dbus) | 17:30 |
| dneary | OK - so there can be only one HAL script executed, then? | 17:31 |
| mjg59 | Yeah | 17:31 |
| dneary | There's also suspend-hybrid-linux in there | 17:31 |
| dneary | what's the difference? | 17:31 |
| mjg59 | That saves state to disk, then puts the system in suspend to ram | 17:31 |
| mjg59 | We don't use it | 17:31 |
| dneary | 'kay | 17:31 |
| ted1 | mjg59: Does HAL pull the info out of the FDI files or does hal-system-power-suspend-linux? | 17:53 |
| mjg59 | hal does | 17:53 |
| ted1 | So if I add a new FDI file, or change one, I need to restart HAL? | 17:54 |
| sjoerd | ted1: hal watches the fdi dirs with inotify | 17:56 |
| ted1 | Ah, cool. | 17:56 |
| sjoerd | ted1: but afaik it doesn't reapply the rules, so i'm not sure if it'll help in your case | 17:56 |
| ted1 | What do you mean by "reapply the rules"? | 17:58 |
| === slangase` is now known as slangasek | ||
| davmor2 | Amaranth: are the Questions in classroom-chat transferred manually (we doing a talk tomorrow for the first time) | 18:34 |
| === fta_ is now known as fta | ||
| hwilde | anybody seen ubotu ? | 20:06 |
| cjwatson | yow, devscripts merge => complicated | 20:18 |
| cjwatson | hwilde: see drama on ubuntu-irc@ | 20:18 |
| bdmurray | pitti: is bug 206921 SRU worthy? I believe it is but want to confirm | 20:19 |
| ubot5 | Launchpad bug 206921 in hal "MacBook brightness adjustment does not work in Hardy" [Undecided,Confirmed] https://launchpad.net/bugs/206921 | 20:19 |
| hwilde | cjwatson, see what where? | 20:20 |
| cjwatson | hwilde: http://lists.ubuntu.com/archives/ubuntu-irc/ | 20:23 |
| cjwatson | specifically the "Goodbye" thread | 20:23 |
| ompaul | !ubotu | 20:24 |
| ubot5 | I am ubotu, all-knowing infobot. You can browse my brain at http://ubotu.ubuntu-nl.org/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots | 20:24 |
| hwilde | oh its ubot5 now! | 20:24 |
| ompaul | ubot5 is getting an education - not all factoids are in there yet | 20:24 |
| ubot5 | ompaul: Error: "is" is not a valid command. | 20:24 |
| ubot5 | ompaul: Error: I am only a bot, please don't think I'm intelligent :) | 20:24 |
| * ompaul chuckles - case in point | 20:25 | |
| hwilde | wtf is this nonsense I want ubotu back | 20:25 |
| hwilde | somebody owns him and threw a hissy fit ? | 20:25 |
| ion_ | ubot5: You're in violation of an RFC. Please NOTICE any automatic messages instead of PRIVMSGing them. Kthxbye. | 20:26 |
| ubot5 | ion_: Error: "You're" is not a valid command. | 20:26 |
| ubot5 | ion_: Error: I am only a bot, please don't think I'm intelligent :) | 20:26 |
| * cjwatson takes a lock on the devscripts merge, BTW; I'm partway through but it will take a while | 20:27 | |
| cjwatson | I'm making some tidy-up changes in the process | 20:27 |
| hwilde | I wish somebody would have told me :/ | 20:28 |
| ompaul | hwilde, you currently the code is being parsed and uploaded to new bot - it should be okay in a few hours | 20:28 |
| hwilde | I could have brute force siphoned all of ubotu's knowledge | 20:28 |
| * ompaul reads the you and gives up | 20:29 | |
| hwilde | hehe | 20:29 |
| hwilde | it's almost wednesday, don't give up yet | 20:29 |
| ompaul | hmm about three and a half hours to go and I have no preparations done for tomorrow where is this week gone argh | 20:31 |
| ompaul | woops | 20:32 |
| hwilde | ok so if X11 requires gksu instead of sudo, and sudo can cause problems with X11 apps, why isn't that handled automagically ? | 20:32 |
| pitti | bdmurray: confirmed; it's a very confined patch to the hw specific backend | 20:40 |
| bdmurray | pitti: right, it looked pretty minimal. should I do anything to move it along? | 20:41 |
| pitti | bdmurray: I already modified the bug accordingly, currently applying the patch | 20:45 |
| pitti | bdmurray: I have a pending hal SRU, and it wasn't accepted yet, so I'll slip it in | 20:46 |
| bdmurray | pitti: great, thanks! | 20:46 |
| pitti | bdmurray: committed and uploaded to hardy-proposed, waiting for someone to accept it now | 20:56 |
| === cprov is now known as cprov-afk | ||
| outworlder | the Chicken Scheme package available in the repositories is too old. What is the procedure that must be followed to get a newer version into the repositories? | 21:34 |
| Peter_Hoffmann | Hello everybody. Is there anyone remembering a change in "gio" (part of glib) which is in charge of showing icons for mounts on the desktop - in hardy? | 21:34 |
| === ryu2 is now known as ryu | ||
| Peter_Hoffmann | Is it possible, that someone changed that gio-thing (mentioned above) and now it shos every mount that ist not in fstab or not mounted by using UUID? | 22:01 |
| seb128_ | re | 22:17 |
| seb128_ | Peter_Hoffmann: what is your gio issue? | 22:17 |
| Peter_Hoffmann | I do see mounts that are mounted in my homedirectory | 22:19 |
| === seb128_ is now known as seb128 | ||
| Peter_Hoffmann | see = Icons on my desktop | 22:20 |
| seb128 | that's how it's supposed to work when using gvfs | 22:20 |
| seb128 | the mount in your user directory and in media are listed | 22:20 |
| Peter_Hoffmann | I discovered that about 1min ago that it's not only /media (that is what everybody tells you) but also /home/$user | 22:21 |
| seb128 | did you read what I just wrote? | 22:21 |
| Peter_Hoffmann | But that changed from 7.10 to 8.04 | 22:21 |
| seb128 | yes, 7.10 was using gnome-vfs | 22:21 |
| seb128 | GNOME switched to the new gvfs this cycle | 22:21 |
| seb128 | and 8.04 is using gvfs too | 22:21 |
| Peter_Hoffmann | I even asked in #gnome but nobody there thougt of that | 22:22 |
| Peter_Hoffmann | so you finaly are the first person that is telling me something supportive :-) Thanks! | 22:22 |
| Peter_Hoffmann | I didn't recognice that little detail when I updated | 22:22 |
| Nafallo | seb128 rocks :-) | 22:22 |
| Peter_Hoffmann | +lol+ | 22:23 |
| Peter_Hoffmann | Everybody was like: If you don't want to see the icons you have to mount it somewhere else then /media/ and I was like: I do have that but finaly. Another successful day *g* | 22:25 |
| === ubot5 is now known as ubottu | ||
| LaserJock | seb128: is there then a way to not have specific mounts not show up on the desktop? | 22:29 |
| seb128 | LaserJock: mount thoses not in your user directory or media, otherwise no | 22:30 |
| LaserJock | seb128: but how do you have them not mounted in your user directory? | 22:31 |
| seb128 | LaserJock: dunno what you are mounting, but "man mount" and read how to change the mount point there? | 22:32 |
| LaserJock | seb128: that doesn't help you with removable media does it? | 22:33 |
| LaserJock | or automatically mounted stuff in any case | 22:33 |
| seb128 | LaserJock: removable medias are mounted in media usually | 22:34 |
| seb128 | you can change the gnome-mount options I guess | 22:34 |
| mathiaz | seb128: Bugs file against samba tend to deal with "cannot browse/transfer file to Windows since I've updated to Hardy" these days | 22:35 |
| mathiaz | seb128: how should these be handled/marked ? | 22:35 |
| mathiaz | seb128: should I open a new task for the nautilus-package ? | 22:35 |
| seb128 | mathiaz: we have a zillion of those, reject those as duplicates or reassign to gvfs and let us do that for you | 22:36 |
| mathiaz | seb128: ok - so I'll reassign to gvfs then | 22:36 |
| seb128 | you like to give me extra work? ;-) | 22:37 |
| mathiaz | seb128: well - I'm not sure they're not completly unrelated to samba | 22:37 |
| mathiaz | seb128: some people are using cifs mount in fstab | 22:37 |
| seb128 | mathiaz: if you want to help figure what is wrong you can ask them those questions: | 22:37 |
| seb128 | - does it work using smbclient | 22:37 |
| seb128 | - do you have access to '/' on the server | 22:38 |
| seb128 | - do you need extra credentials to browse the share, and is it accessible anonymously too | 22:38 |
| seb128 | if that's a connect to server issue | 22:38 |
| seb128 | another issue is that you can't enter a password to browse a network | 22:39 |
| seb128 | the most common issues otherwise is that you can't change your credential if something is accessible anonymously | 22:39 |
| seb128 | and that the mounting doesn't work when '/' is not available to the user on the server | 22:39 |
| mathiaz | seb128: browse a network shouldn't require credential | 22:39 |
| seb128 | mathiaz: it does sometimes, in case of active directory, etc apparently | 22:40 |
| mathiaz | seb128: hum - I should also ask if the issue is on a desktop acting as a client or on a server | 22:40 |
| mathiaz | seb128: mmmm - AD.. and browsing ? | 22:41 |
| seb128 | mathiaz: https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/207072 | 22:41 |
| ubottu | Launchpad bug 207072 in nautilus "nautilus does not display samba shares for machines inside an ADS network." [Low,Invalid] | 22:41 |
| seb128 | mathiaz: read that for details | 22:42 |
| mathiaz | seb128: right - I was confused by your usage of browsing | 22:44 |
| seb128 | ah, sorry | 22:44 |
| seb128 | how do you call that? | 22:44 |
| mathiaz | seb128: to me browsing is when you want to get a list of machines in the same workgroup | 22:44 |
| seb128 | I use if for list of machines or list of shares on a box | 22:45 |
| mathiaz | seb128: you're using browsing as listing the shares available on one machine | 22:45 |
| seb128 | I use it for both because that's basically "list whatever is available" in both cases | 22:45 |
| mathiaz | seb128: right - list of machines is different than list of shares on a machine | 22:45 |
| seb128 | anyway this bug is one of the known annoying issue | 22:45 |
| mathiaz | seb128: right - from the windows networking point of view, the protocal are totally different | 22:45 |
| seb128 | https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/223372 is an another one | 22:46 |
| ubottu | Launchpad bug 223372 in gvfs "gvfsd-smb mounting requires / to be accessible to the user and should not" [High,Triaged] | 22:46 |
| seb128 | and we have https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/209520 but that is a collection of different issues | 22:46 |
| ubottu | Launchpad bug 209520 in nautilus "SMB error: Unable to mount location" [Undecided,Confirmed] | 22:46 |
| mathiaz | seb128: ok - I see that you already have loads of bug reports | 22:48 |
| mathiaz | seb128: for the bugs filed against samba, I'll ask if smbclient works or not | 22:48 |
| seb128 | yes | 22:48 |
| seb128 | I've reassigned some to samba where smbclient was not working | 22:48 |
| mathiaz | seb128: if smbclient works correctly, I'll assume it's a problem with gvfs | 22:48 |
| seb128 | let me know if that's wrong | 22:49 |
| mathiaz | seb128: if smbclient doesn't work then I'll keep it open in samba | 22:49 |
| seb128 | ok | 22:49 |
| mathiaz | seb128: I don't think it's wrong - smbclient is a good test to rule out issues with gvfs | 22:49 |
| mathiaz | seb128: if smbclient fails, it may be a problem on the server | 22:50 |
| mathiaz | seb128: so if smbclient is successfull, which bug number should I use as a duplicate ? | 22:50 |
| seb128 | right, usually I ask if they can use the share from an another OS or version of ubuntu too | 22:50 |
| seb128 | mathiaz: as said, either you ask for details or just reassign and I'll do that | 22:51 |
| seb128 | mathiaz: it's likely one of the issues I listed before | 22:51 |
| mathiaz | seb128: ok - thanks | 22:53 |
| seb128 | mathiaz: np, and you are welcome to look at the gvfs issues if you want ;-) | 22:54 |
| seb128_ | re | 22:56 |
| seb128_ | dsl disconnected again | 22:56 |
| seb128_ | mathiaz: what did you get before? | 22:56 |
| mathiaz | seb128_: 17:54 < seb128> mathiaz: np, and you are welcome to look at the gvfs issues if you want ;-) | 22:57 |
| seb128_ | ok | 22:57 |
| seb128_ | mathiaz: btw do you now if an access() call on a nfs mountpoint can hang is some cases? or is it only accessing the local directory? | 22:57 |
| seb128_ | you didn't get this one then ;-) | 22:58 |
| mathiaz | seb128_: access() may hang if the nfs server went away | 22:58 |
| mathiaz | seb128_: the problem with nfs IIRC is that timeouts are reallly long | 22:59 |
| seb128_ | doh, ok | 22:59 |
| mathiaz | seb128_: like 10 or 15 minutes | 22:59 |
| seb128_ | that sucks | 22:59 |
| mathiaz | seb128_: so it doesn't hang - it just takes a looong time to time out | 22:59 |
| seb128_ | another gvfs issue | 22:59 |
| seb128_ | we got a request to not list the mounts not accessible to the user | 22:59 |
| seb128_ | an easy way is to call access() on the mountpoint | 23:00 |
| seb128_ | but the current code is not async | 23:00 |
| seb128_ | so upstream is right, that would not work | 23:01 |
| === ember_ is now known as ember | ||
| Riddell | pitti: kdebase upload to hardy-proposed needing approval for bug 194474 | 23:52 |
| ubottu | Launchpad bug 194474 in kdelibs "[hardy] kded in loop (100%CPU) when using 'mount automatically'" [Undecided,Confirmed] https://launchpad.net/bugs/194474 | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!