| LaserJock | asac: there is some flexibility via ~ubuntu-sru that's true, but the process seems to dissuade quite a number of people from even trying | 00:00 |
|---|---|---|
| jcastro | bryce: I think it might be a good idea to bring this up in the -devel mailing list. | 00:01 |
| LaserJock | and although i can see somewhat of a point in making it hard enough to do an SRU that people need to find a good reason for doing it, it can also have a negative effect on how upstreams look at Ubuntu, IMO | 00:01 |
| jcastro | bryce: some gnome'rs have brought up the same issues | 00:01 |
| jcastro | bryce: I am sure you're as jet lagged as I am | 00:02 |
| jcastro | so going to move on at this point... | 00:02 |
| asac | LaserJock: why do they get dissuaded? because they cannot set the right switches in launchpad, or because they don't want to provide patches that are properly documented for each individual issue? | 00:02 |
| jcastro | and I think I am sick now; here comes the ubuflu | 00:02 |
| crimsun | likely a combination. | 00:02 |
| asac | jcastro: get well soon :-P | 00:03 |
| bryce | jcastro: take some airborne; I find it really helps | 00:03 |
| LaserJock | asac: because they feel they did the responsibility of releasing a bug-fix and are being told that they now need to fill out Ubuntu paperwork | 00:03 |
| bryce | jcastro: I make it a habit of bringing a tube of it when I'm out of town and take one a day | 00:03 |
| LaserJock | I think the situation would be very much different if we had enough eyes and hands to actively keep up with upstreams | 00:03 |
| jcastro | bryce: lots of liquids seem to help | 00:03 |
| asac | LaserJock: usually the paper work is done by ubuntu devs or contributors that want to see those fixes in it. so somehow you are right that we don't have enough hands to do that. but changing the policy won't help here imo | 00:04 |
| LaserJock | well, a know that we've had problems in the past where devs and contributors were not filing SRUs because it was excessive paperwork | 00:05 |
| LaserJock | it depends on somebody actually caring enough to do it, and at present I'm not sure we have enough people to even cover Main well if it's a "well if you care so much why don't you file a SRU" kind of thing | 00:06 |
| bryce | asac: I disagree; there are many, many cases where people request an Xorg / driver fix be put out for Gutsy, that I don't do because of all the paperwork. | 00:06 |
| bryce | asac: In fact, I've pretty much given up on the idea of SRU's for Xorg driver updates, and have been working on building something on Envy | 00:08 |
| bryce | which I think is going to be a better solution all around, but it's admittedly working around the sru process, not fixing it | 00:09 |
| asac | bryce: hmm ... imo if they are not critical enough to do that paper work it might be a good indicator that they shouldn't go in imo. and drivers usually have a high risk to come with hard-impact regressions. if they break they might just break a previously working system completely. | 00:11 |
| bryce | asac, yes this is the circular logic that irritates the heck out of me - "If it's important enough, you ought to be willing to do 3 days worth of paperwork to get it in. If you're not willing to do 3 days worth of paperwork, then obviously it isn't important enough." | 00:14 |
| bryce | if you're not a terrorist, then why should you have a problem with being cavity searched each time you fly? If you have a problem, then maybe you are a terrorist? | 00:15 |
| asac | bryce: for you a driver fix takes 3 days? how many bugs do they fix? | 00:16 |
| bryce | and yes, driver changes obviously carry more significant risk than a package like inkscape. but at the same time the bugs they fix tend to be more severe as well - usually solving "I can't get Ubuntu to work on my computer anymore due to X problems" compared with "Inkscape crashes when I cross my eyes" | 00:17 |
| bryce | asac, 3 days is a best case; obviously usually a driver SRU takes much, much longer | 00:18 |
| asac | you mean it consumes 3 days of work or takes 3 or more days of your attention | 00:18 |
| bryce | asac, and "has a non-zero chance of breaking a previously working system" is why driver SRU's have proven impossible to file. | 00:19 |
| bryce | asac, packaging, building, and thoroughly testing a driver change can easily consume a day by itself. The paperwork takes additional time - maybe an afternoon, as does summarizing bug report commentary into problem descriptions and test cases, and then additional time/attention responding to review requests, usually requiring modifying the packaging and going through the rebuild/retest process a few times, then a whole bunch of | 00:23 |
| bryce | time spread over several days or weeks recruiting other people to also test the package and respond to their questions | 00:23 |
| bryce | so I would estimate 3 days of effort to be a minimum for filing a sru for a driver bug | 00:24 |
| bryce | but more likely it would take several week's of attention | 00:24 |
| bryce | and after this, it would almost always be denied. | 00:24 |
| asac | bryce: yeah ... i see. imo the process is right still. if we cannot guarantee that there is no regression, we cannot really upload drivers | 00:24 |
| bryce | asac, ah and I gather you do not see this as an issue? | 00:25 |
| asac | so it does the right thing .... under the assumptions that we follow a "stable release policy" as we currently define it. | 00:25 |
| asac | bryce: of course, but not an issue that can be easily fixed | 00:26 |
| bryce | asac, and in any case, wouldn't it save more time and angst to simply say, "Our policy is no changes to drivers in a Ubuntu release due to risk of regressions," rather than elaborating this extremely lengthy SRU process document with all this paperwork? | 00:26 |
| bryce | asac, it seems like the process is documented with the idea of handling something severe and high risk like Xorg, but is being applied even in cases like Inkscape where really there isn't such a high risk | 00:27 |
| bryce | so it ends up being inapplicable for the former, and too complicated to bother with for the latter | 00:27 |
| asac | well ... we have two big classes of regressions that we care about: 1. complete system breakage ... 2. feature breakage. | 00:39 |
| asac | if 1. can happen we cannot upload at all (as we found out for the drivers) | 00:39 |
| asac | 2. we can only prevent by thoroughly reviewing and not letting in bug fixes that are not high-impact or whose patches don't look reasonably minimal imo. | 00:40 |
| asac | maybe really raise this on ML. maybe we can really find something we can improve | 00:45 |
| bryce | well, I return to my original point - solving this by imposing a lot of paperwork to the point that people stop bothering to try doing sru's is just sweeping problems under the rug, not really solving the problem. | 00:45 |
| asac | bryce: the paparwork is done to take load from rare resources: sru reviewers | 00:46 |
| asac | you cannot expect the reviewer to figure out how to get the patches to review them et al | 00:46 |
| asac | (i don't say that all is perfect, but in general it does what we want imo) | 00:47 |
| bryce | I can understand that. What I'm saying is that pushing that workload back onto the sru requestor ends up reducing the number of sru requestors | 00:47 |
| bryce | so yes, in a way it solves the problem of the sru reviewer's workload | 00:47 |
| asac | ... which can or cannot be a bad thing ... | 00:47 |
| bryce | sigh | 00:48 |
| asac | :) | 00:48 |
| * asac hugs bryce | 00:48 | |
| asac | ok i am off going to bed. we should go ahead on ml | 00:48 |
| bryce | in any case, it feels like the process is broken, and trying to get it fixed is just wasted breath | 00:48 |
| bryce | night | 00:48 |
| bryce | well, like I said, for my own issues (both inkscape and xorg) I'm just bypassing using sru's to get the work done | 00:49 |
| bryce | I just hope that other people's complaints about the sru process get listened to and not just dismissed as "whining" | 00:50 |
| bryce | since I think long term it could hinder Ubuntu in general | 00:50 |
| asac | i think nobody declares this discussion as whining ... if we can improve things, we should improve them. but i don't see how we can lower the documentation bar because its essential for reviewers. only accepting high-impact bugs is in some way a measure to overcome that we don't have endless resources and the vague definition of high-impact already gives us enough flexibility to approach special cases imo. | 00:54 |
| theunixgeek | How do I make my own window border theme? | 01:26 |
| theunixgeek | How do I make my close button be red and the minimize button blue without writing a completely new theme? (GNOME, GTK, etc) | 01:28 |
| === kyle__ is now known as kylem | ||
| === ln-_ is now known as ln- | ||
| === bigon is now known as bigon` | ||
| pitti | Good mornign | 06:32 |
| RAOF | Afternoon, pitti | 06:33 |
| LaserJock | hi pitti! | 06:34 |
| LaserJock | back from the Sprint? | 06:34 |
| pitti | LaserJock: yeah, got home Saturday evening | 06:37 |
| * Fujitsu was wondering how jcastro got his photo of a couple of distro-teamers recovering from NM 0.7. | 06:40 | |
| pitti | well, he walked into the room and pointed his cam at us, easy :) | 07:12 |
| LaserJock | pitti: was it a pretty productive sprint? | 07:14 |
| Fujitsu | pitti: Well, yes, but I didn't realise there was a sprint. | 07:14 |
| pitti | LaserJock: I'd say so; lots of ad-hoc discussions, hands-on trainings, hacking, and clearing the TODO list | 07:16 |
| geser | good morning | 07:16 |
| pitti | hey geser | 07:16 |
| geser | Hi pitti | 07:17 |
| LaserJock | pitti: so we may get Hardy out the door after all? ;-) | 07:18 |
| pitti | possibly :) | 07:24 |
| === bigon` is now known as bigon | ||
| === hunger_t is now known as hunger | ||
| warp10 | Heya all | 08:20 |
| l0wrd | i need some help. im appear to be missing glade-2.0 | 08:20 |
| l0wrd | i keep getting a message "ld: cannot find -lglade-2.0" | 08:21 |
| l0wrd | can someone help me? | 08:21 |
| l0wrd | i have installed glade3 and done "apt-get install glade" | 08:21 |
| RAOF | l0wrd: Off topic for this channel (it's not development *of* Ubuntu). Also, you probably want libglade-dev, or somesuch package. | 08:21 |
| l0wrd | RAOF: i see your point. | 08:22 |
| l0wrd | RAOF: thank you for your help, everything is working now. | 08:24 |
| dholbach | good morning | 08:48 |
| === doko_ is now known as doko | ||
| asac | hi | 08:58 |
| pitti | hey asac, hey dholbach | 09:19 |
| dholbach | hey pitti, hey asac | 09:20 |
| * asac hugs pitti + dholbach | 09:21 | |
| === Xoff is now known as Xof | ||
| asac | pitti: have you read the SRU discussion we had from 00:00 -> 02:00 yesterday? | 09:22 |
| asac | aeh today :) | 09:22 |
| pitti | asac: no, seems my proxy had some trouble with freenode connection | 09:22 |
| asac | oh unfortunate :) ... i saw you online iirc | 09:23 |
| asac | but maybe that was at the end | 09:23 |
| asac | pitti: starts at 23:11 here: http://irclogs.ubuntu.com/2008/01/27/%23ubuntu-devel.txt ... and continues on http://irclogs.ubuntu.com/2008/01/28/%23ubuntu-devel.txt | 09:25 |
| pitti | asac: ugh, that's a lot -- what was the problem and conclusion? | 09:27 |
| pitti | and I don't agree that it's overly bureaucratic | 09:28 |
| pitti | if you can demonstrate the problem, have a patch, and someone to test the upgrade, then you can just do an upload | 09:28 |
| asac | i agree | 09:28 |
| pitti | and if you fail any of these three, then an SRU is absolutely not appropriate | 09:28 |
| asac | its bryce, jcastro and laserjock that disagreed | 09:28 |
| pitti | [23:31] <bryce> I'd never argue that testing should not be thoroughly done or that the process should be "slacker"; but that the sru process as currently written is extremely labor intensive to whomever wishes to push the sru along, and is likely resulting in people not wishing to help in the sru process, with the consequence that justifiably important sru's are not getting through. | 09:32 |
| pitti | bryce: ^ please tell me where the SRU process is labor-intensive which is not related to testing and necessary QA | 09:32 |
| pitti | bryce: attach a patch and justification to a bug, upload a fix, coordinate testing (or ask sru-verification), that's it for you | 09:33 |
| seb128 | I've to admit the wiki page is not inviting | 09:33 |
| pitti | bryce: I don't see how it could become any less bureaucratic | 09:33 |
| pitti | I saw a lot of people doing SRUs in 'fire and forget' mode | 09:33 |
| pitti | and the process is deliberately designed to not move these into -updates automatically | 09:34 |
| pitti | bryce: I'm always open to suggestions how to improve it and make it less bureaucratic, so please tell me :) | 09:34 |
| seb128 | pitti: the wiki description takes several pages, I would not say it looks easy for people who wants to contribute | 09:34 |
| asac | seb128: maybe we can polish the wiki ... like make the main document leaner and put the details in kind of a "check-list" that is kept separate. | 09:34 |
| seb128 | asac: would be nice | 09:35 |
| pitti | seb128: right, it's very detailled, since it's documentation | 09:35 |
| pitti | but people already do it incorrectly even with the current level of detail | 09:35 |
| pitti | and it's not nice to push all the work to me, to fix bug states, repeatedly bother people about "is it fixed in hardy yet?" and "please fix it in hardy first", "how can I reproduce", etc. | 09:36 |
| seb128 | do you think they read it? or they run away because that looks too complicated? | 09:37 |
| seb128 | pitti: I don't think anybody wants to push the work to you | 09:37 |
| seb128 | but the wiki description should be something like | 09:37 |
| seb128 | * describe the issues and how to trigger it easy | 09:38 |
| pitti | no, not 'want', but it ends up being me who does the work because people don't follow the documentation | 09:38 |
| seb128 | * attach your changes | 09:38 |
| pitti | so I can always point them to '2.3 of policy' etc. | 09:38 |
| seb128 | * subscribe the team and get testing | 09:38 |
| seb128 | we discussed the wiki documentation with ogra at the bar some days ago, and I sort of agree with him, we have things too complicated and that scares users away sometimes | 09:39 |
| seb128 | we should have a small and easy description | 09:39 |
| pitti | users shouldn't be concerned about this at all | 09:39 |
| seb128 | and an another page with details | 09:39 |
| pitti | we communicate to them through bug reports | 09:39 |
| pitti | i. e. 'Please test the fix in -proosed and tell us how it goes' | 09:39 |
| seb128 | users -> contributors | 09:39 |
| pitti | <blatantly candid mode>if a contributor is not able to understand this policy, we should not leave him anywhere near SRU | 09:40 |
| asac | pitti: i think one special case that was discussed and for which the process (righly) is too complex is that of pushing new upstream "bugfix-only releases" ... | 09:40 |
| pitti | those instructions are not at all difficult; they are particularly easy and detailled | 09:40 |
| asac | my comment was: ... upstream will always push to fix as many bugs as possible, so their application is perceived as prefect as possible to the majority of their users. the distro itself is more scared about regressions that might hit a minority of production deployments. | 09:40 |
| seb128 | well, I've to admit I already delayed SRUs because I didn't do some for some months and I opening the wiki page was enough to make me not want to do it | 09:41 |
| pitti | asac: I see; well, that's orthogonal to the process document, though | 09:41 |
| pitti | seb128: you delayed some SRUs because nobody bothered to do at least a single test | 09:41 |
| seb128 | I don't want to read complicated text, I just need to basic actions | 09:41 |
| pitti | seb128: i. e. the 'fire and forget' mode | 09:41 |
| pitti | which just doesn't work for SRUs | 09:41 |
| pitti | seb128: I did; I followed up with 'please test the package in -proosed' | 09:41 |
| seb128 | no, when I said delayed, it's a SRU I had to do | 09:41 |
| pitti | ah | 09:42 |
| seb128 | and honestly I find the wiki page too complicated and discouraging | 09:42 |
| pitti | so would it help to split it into a 'process' and a 'checklist for each step'? | 09:42 |
| seb128 | I just want the: do the patch, subscribe sru, add a testcase | 09:42 |
| seb128 | yes | 09:42 |
| pitti | the problem that i see is that nobody would bother to read the checklist any more | 09:43 |
| seb128 | do you really think they do now? | 09:43 |
| pitti | and the SRU team would end up with getting a lot of bad or wrong SRUs | 09:43 |
| pitti | which in the end stalls the process much more | 09:43 |
| pitti | seb128: some don't | 09:43 |
| seb128 | I think they just decide "it's too complicated, let's upload and tag" | 09:43 |
| seb128 | and some other are discouraged and run away | 09:43 |
| seb128 | some other do read it most likely too | 09:44 |
| pitti | I don't think that there's a brilliant solution to this TBH | 09:44 |
| seb128 | but I'm not sure that those who read the pages would not look at the checklist if they have a doubt | 09:44 |
| pitti | an SRU process is inherently complicated, so you cannot really come up with a trivial three-line document to describe it | 09:44 |
| seb128 | right, I'm not sure either | 09:44 |
| pitti | the current policy hasn't been invented out of thin air | 09:44 |
| seb128 | it's not really complicated | 09:45 |
| pitti | we started with a very small process, got breakage, and added checks to it to fix that breakage in the future | 09:45 |
| seb128 | it's basically: you have an easy patch which would make things nicer for lot of users, apply it to the stable package, test, write a testcase, upload | 09:45 |
| pitti | seb128: what we can do immediately is to split the process into one for the developer and one for the SRU team | 09:46 |
| pitti | seb128: right, that plus having a bug# and fixing it in hardy first | 09:46 |
| pitti | seb128: I specifically added the 'upload immediately without ack' case a few months ago | 09:46 |
| pitti | since that 'wait for SRU ack' was a discouraging delay | 09:46 |
| pitti | and it works well so far | 09:47 |
| seb128 | right, I don't think SRU are too complicates | 09:47 |
| seb128 | I think the wiki page is though | 09:47 |
| * pitti will split the process accordingly (dev vs. SRU team) | 09:47 | |
| seb128 | you have 6 sections there and up to 7 items in those | 09:48 |
| seb128 | right, would be nice to split between what the uploader has to do | 09:49 |
| seb128 | and what SRU team, etc have to do to validate | 09:49 |
| cjwatson | soren: feel free to send me a patch for the openssh host key thing you mentioned; I guess my only concern is that entropy might be scarce at init time and it could slow down boot substantially, and so it would still be better to generate them in the postinst if possible | 10:12 |
| cjwatson | \sh_away: the decision-tree stuff in console-data has been there for a while now, but you can drop it on merge if you like; we don't use console-data any more | 10:12 |
| cjwatson | CarlFK: you can if you like, but it won't make any difference since I'm already auto-notified of openssh bugs | 10:13 |
| cjwatson | CarlFK: I've followed up to your bug | 10:15 |
| soren | cjwatson: Well, the postinst invokes the init script, so they'd be generated at install time regardless. | 10:18 |
| cjwatson | soren: right | 10:21 |
| soren | cjwatson: The change just makes the process of distributing a VM with ssh installed in it much simpler. Currently, it needs to do various trickery to replace the host keys (so that not every instance of the vm shares their secret keys) on first install. With the change, you just remove the host keys as one of the last things before shutting down the vm and distributing it, and they'll get generated on boot. | 10:21 |
| cjwatson | soren: *nod* | 10:21 |
| soren | Cool. I'll whip up a patch. | 10:21 |
| cjwatson | soren: though, I still think that stands a decent chance of having the VM sit there at boot trying to gather entropy - I'd still recommend regenerating the keys before shutdown | 10:22 |
| soren | Erm.. How would that work? | 10:22 |
| soren | I mean.. In the context of a use case where you want to create a vm image with ssh installed and distribute said image while avoiding that each instance will have the same secret key installed, I don't see how you can do the generation bit at shutdown? | 10:26 |
| soren | cjwatson: ^ | 10:27 |
| cjwatson | soren: err, yeah, guess not | 10:28 |
| cjwatson | fair point | 10:28 |
| soren | Unless you freeze the vm just before shutdown and distribute that, but that would be quirky, and the entropy would be the same for anyone who fires it up, and you'd have lost anyway :) | 10:28 |
| soren | cjwatson: FWIW, I believe Fedora and RedHat have used this approach for a long time and it seems to work for them. | 10:29 |
| soren | I'll run a few tests and see if it gets stuck on entropy starvation. | 10:29 |
| pitti | asac: ffox 3.0 for hardy-4? | 10:39 |
| pitti | asac: ^ ... alpha ... | 10:40 |
| geser | soren: as you touched iptables last, would it be possible to include the patch from Debian bug #358637 to get a static library compiled with -fPIC? | 10:50 |
| ubotu | Debian bug 358637 in iptables-dev "libip* should be compiled with -fPIC; attempt to link the current libiptc.a binary into a shared library on amd64 causes an R_X86_64_32S relocation error" [Important,Open] http://bugs.debian.org/358637 | 10:50 |
| asac | pitti: i will try to do mono today ... if that works well, then yes. otherwise after alpha4 ... but ill try | 10:50 |
| pitti | asac: what does mono have to do with it? | 10:52 |
| asac | mono is in main and has a gecko binding | 10:53 |
| soren | geser: /me looks | 10:53 |
| asac | pitti: so we could not dump firefox to universe | 10:53 |
| pitti | asac: isn't that pretty independent of making ffox-3.0 the default? | 10:54 |
| pitti | asac: or you mean mono will pull in ffox to the CDs, too? | 10:54 |
| geser | soren: I see that the patch is for libiptc.a but I need a libipq.a with -fPIC. I guess a similar patch might work there too. | 10:54 |
| soren | geser: I've not worked my way through all of it yet, but the patch I'm looking at right now adds a libipq_pic.a compiled with -fPIC? | 10:55 |
| soren | geser: ...and I can't spot any other patches in it? | 10:57 |
| geser | soren: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=003-dev_lib_fPIC.patch;att=1;bug=358637 adds only libiptc_pic.a | 10:59 |
| asac | pitti: haven't looked ... i would like to have transition complete in main before replacing/conflicting firefox-3.0 on firefox. if you want it the way its now, i can do it though. | 10:59 |
| soren | geser: Ah, so it does. My mistake. | 10:59 |
| pitti | asac: I'm just concerned about doing it RSN, for testing | 10:59 |
| soren | geser: If you make a patch, I'd be happy to review and upload it. | 10:59 |
| geser | ok | 11:00 |
| soren | geser: I've got an iptables upload pending anyway. | 11:00 |
| asac | pitti: personally, i don't have much concerns about a lack of testing. the package is pretty mature and we have had a bunch of users for quite some time already. but i understand the concerns from the release-managers point of view | 11:06 |
| asac | pitti: let me try to get this mono thing done today. then we can decide | 11:06 |
| asac | ok? | 11:07 |
| pitti | souds good | 11:08 |
| _StefanS_ | BenC: you there? | 11:10 |
| _StefanS_ | BenC: I was wondering if the acpi/hal problem that reports the double number of batteries will be fixed in the final hardy ? | 11:12 |
| cjwatson | StevenK: bit early for him as yet | 11:12 |
| pitti | _StefanS_, BenC: you mean the problem that CONFIG_ACPI_PROCFS_POWER=y is enabled? | 11:12 |
| pitti | _StefanS_, BenC: (which causes hal to pick up the battery from both /proc and /sys) | 11:13 |
| _StefanS_ | pitti: yep something like that | 11:13 |
| _StefanS_ | pitti: yes thats the one. | 11:13 |
| _StefanS_ | pitti: I saw it was fixed in the final 2.6.24 kernel (atleast partially) | 11:13 |
| pitti | _StefanS_: then we'll get the fix | 11:13 |
| _StefanS_ | pitti: sweet. Thanks | 11:13 |
| crimsun | No, it's still present in 2.6.24 final. | 11:14 |
| _StefanS_ | crimsun: only on some systems, right? | 11:14 |
| _StefanS_ | crimsun: I think they patched it to just return an empty list in proc | 11:14 |
| _StefanS_ | crimsun: maybe a userspace app needs to changed (e.g. g-p-m / guidance-p-m) to make it skip the empty one (?), thats how I understood it anyways | 11:16 |
| pitti | seb128, thekorn: I found out why apport gets stuck in an endless loop, producing bug spam like bug 184306 | 11:25 |
| ubotu | Launchpad bug 184306 in totem "totem-xine-video-thumbnailer crashed with SIGSEGV in xine_list_get_value()" [Undecided,New] https://launchpad.net/bugs/184306 | 11:25 |
| pitti | seb128, thekorn: I reported it as bug 186599; any idea? | 11:25 |
| ubotu | Launchpad bug 186599 in python-launchpad-bugs "fails to remove tags sometimes" [Undecided,New] https://launchpad.net/bugs/186599 | 11:25 |
| seb128 | pitti: good | 11:25 |
| mvo | soren: is it known that the generic hardy kernel does not boot in kvm? | 11:27 |
| soren | mvo: Er... No. | 11:29 |
| soren | mvo: -v | 11:29 |
| mvo | soren: let me poke a bit more, but currently it looks like I can not boot the hardy generic kernel in my kvm (I haven't tried -virtual or -server yet) | 11:30 |
| soren | What happens? | 11:30 |
| mvo | soren: not sure, the kernel hangs and the last message is "time: pit clocksource has been installed" | 11:30 |
| soren | mvo: Kernel version? | 11:31 |
| mvo | but let me ensure that everything is up-to-date here first | 11:31 |
| soren | Cool. | 11:31 |
| pitti | Hobbsee, Riddell: do you have some minutes for checking/uploading the debdiff on bug 133944? | 11:31 |
| ubotu | Launchpad bug 133944 in kdepim "package kitchensync 4:3.5.6-0ubuntu6 failed to install/upgrade: trying to overwrite `/usr/share/apps/ksync/ksyncui.rc', which is also in package ksync" [Low,Confirmed] https://launchpad.net/bugs/133944 | 11:31 |
| emgent | keescook, ping | 11:32 |
| Riddell | pitti: the gutsy one? | 11:34 |
| pitti | Riddell: yes | 11:34 |
| thekorn | pitti: hmm, looks strange, will have a closer look in about half an hour | 11:34 |
| pitti | thekorn: awesome, thanks | 11:34 |
| Riddell | pitti: looks all good, want me to upload? | 11:39 |
| pitti | Riddell: would be great, I'll accept it right away then | 11:39 |
| Riddell | pitti: done | 11:41 |
| * Hobbsee waves | 11:41 | |
| pitti | hi Hobbsee! | 11:41 |
| Hobbsee | pitti: that fix should be fine | 11:41 |
| * Hobbsee hugs pitti | 11:41 | |
| mvo | soren: my kernel is 2.6.24-5-generic and I try to boot a 2.6.24-5-generic | 11:44 |
| * soren sighs heavily at git | 11:46 | |
| geser | soren: http://members.ping.de/~mb/tmp/iptables.debdiff is the debdiff for iptables. I've adapted the patch from the Debian bug for libipq and tested the new iptables-dev with building perlipq and nepenthes on AMD64 | 11:49 |
| mvo | soren: same problem with the virtual kernel image it seems, let me know if I can help you further (e.g. screenshot of the hang etc) | 11:53 |
| geser | pitti: the delo FTBFS looks like a bug in pkg_create_dbgsym: http://launchpadlibrarian.net/11490461/buildlog_ubuntu-hardy-i386.delo_0.8-2.2_FAILEDTOBUILD.txt.gz | 11:56 |
| geser | do you agree? | 11:56 |
| soren | mvo: I'll be all over it as soon as I manage to beat git into submission. | 11:56 |
| thekorn | pitti: it seems that removing tags does not work for bugreport which have a 'nickname' | 11:57 |
| pitti | geser: yes, I do; can you please open a bug for it? | 11:57 |
| pitti | geser: might even be the same one as we had for that ocaml package; it's again -X | 11:58 |
| pitti | thekorn: ah | 11:58 |
| geser | pitti: the file it complains about isn't -X in the dh_strip call | 12:01 |
| * Hobbsee curses the evil keyboard bug | 12:01 | |
| * Fujitsu does too, and fails to work out what triggers it. | 12:01 | |
| soren | mvo: How exactly do you invoke kvm? | 12:06 |
| mvo | soren: kvm -m 512 -hda root.qcow2 | 12:07 |
| soren | mvo: Ok, nothing fancy I can blame it on, apparantly. :) | 12:08 |
| mvo | soren: I tried -no-acpi for the fun of it, but it does not make a difference | 12:08 |
| soren | mvo: Exactly which kernel version is it? | 12:09 |
| mvo | soren: meh, I'm an idiot, ignore me. the "problem" is that the name of root changed from hda to sda in hardy (/me is hit by the plague apparently) | 12:12 |
| soren | mvo: And the UUID magic doesn't work? | 12:14 |
| geser | pitti: filed as bug 186610, looking at the meaning of dh_strip -X again it's an other incarnation of the same bug like in the ocaml package. | 12:14 |
| ubotu | Launchpad bug 186610 in pkg-create-dbgsym "pkg_create_dbgsym fails if objcopy can't recognize the file format" [Undecided,New] https://launchpad.net/bugs/186610 | 12:14 |
| geser | soren: is the debdiff for iptables enough for you or should I file a bug about it? | 12:15 |
| soren | geser: It's fine. It's compiling as we speak. | 12:16 |
| mvo | soren: yes, that seems to be the case, vol_id returns the right ID_FS_UUID number and /etc/fstab looks good too | 12:17 |
| thekorn | pitti: I committed a fix to the .main branch of py-lp-bugs | 12:20 |
| pitti | thekorn: many thanks! I'll apply that to the retracers | 12:21 |
| mvo | soren: I take a closer look after lunch | 12:23 |
| soren | mvo: Awesome. Thanks. | 12:25 |
| === asac is now known as asac_resurrected | ||
| soren | geser: Uploaded. | 12:26 |
| asac_resurrected | jcastro: there? | 12:32 |
| === asac_resurrected is now known as asac | ||
| asac | jcastro: oh i see you are on holidays ... enjoy | 12:35 |
| pitti | pedro_, seb128: FYI, p-lp-bugs fixed locally with thekorn's patch and restarted | 12:40 |
| seb128 | pitti: rock on, thanks | 12:40 |
| pedro_ | pitti: great, thanks :-) | 12:40 |
| geser | soren: thanks | 12:41 |
| === lamont` is now known as lamont | ||
| pitti | hi lamont | 12:52 |
| lamont | morning Pici | 12:54 |
| lamont | pitti, even | 12:54 |
| Pici | Morning :p | 12:54 |
| === \sh_away is now known as \sh | ||
| soren | geser: Oh, thank *you*. | 12:58 |
| pitti | StevenK, Mithrandir: hildon-fm-l10n promoted by your request, but please keep in mind that this won't actually give you anything but an useless empty package | 13:01 |
| pitti | StevenK, Mithrandir: TBH I'd much rather keep this in universe (since it doesn't make sense in main) until this is sorted out; if you prefer that, I can demote it agaih | 13:02 |
| pitti | s/h$/n/ | 13:02 |
| \sh | bryce, ping bug #17601 | 13:02 |
| ubotu | Launchpad bug 17601 in xterm "[xterm] add better charclass map" [Wishlist,Confirmed] https://launchpad.net/bugs/17601 | 13:02 |
| \sh | pitti, what do you need from me to include some more libs to ia32-libs? :) | 13:03 |
| bryce | hi \sh | 13:03 |
| \sh | hey bryce | 13:03 |
| pitti | \sh: a list of packages and a poke to do it :) | 13:03 |
| \sh | pitti, ok...I just need at least 2 or 3 more libs to have wine on amd64 working like on x86_32 | 13:04 |
| \sh | bryce, we introduced this change in xterm during breezy, now it's gone completly ... I re-added it...mind using it? :) | 13:05 |
| bryce | \sh yes it looks good | 13:07 |
| \sh | bryce, do we have something like a bzr branch for xterm? | 13:12 |
| bryce | \sh nope, not for xterm | 13:14 |
| bryce | \sh, I believe it's contained in one of the x11- packages, I can check for you, one sec... | 13:15 |
| bryce | hmm, nope, looks like it's a discrete package | 13:16 |
| bryce | so it's just a straight upload | 13:17 |
| \sh | bryce, yepp...it went from the X packages a long time ago :) | 13:18 |
| bryce | \sh actually we recently re-merged them into some collections of apps. But looks like this was retained as separate | 13:18 |
| === Hobbsee is now known as LongPointyStick | ||
| tjaalton | bryce, \sh: xterm is separate in debian as well | 13:21 |
| tjaalton | \sh: please push that change to debian as well | 13:22 |
| bryce | tjaalton: any idea on why the patch got dropped? I don't see a mention of the bug# or 'charclass' in the changelog, so wonder if it just got accidentally dropped in a sync or something? | 13:23 |
| jwendell | gdm in hardy is not playing the sound... is that an know issue? | 13:23 |
| tjaalton | bryce: don't know, I'll check | 13:23 |
| \sh | bryce, when I introduced the patch I wonder if I used the LP bug number these days | 13:24 |
| bryce | \sh ah, that could explain it too | 13:25 |
| tjaalton | bryce: seems that it was uploaded to feisty in Dec. 2006, way before me :) | 13:25 |
| \sh | bryce, ah now | 13:26 |
| tjaalton | um, "before I did anything related to X" | 13:26 |
| seb128 | jwendell: ogra mentionned it some days ago but nobody really looked at why it's broken yet | 13:26 |
| \sh | bryce, + Excluded patches: | 13:26 |
| \sh | - charClass patch is merged to upstream | 13:26 |
| \sh | xterm (208-0ubuntu1) dapper; urgency=low | 13:26 |
| \sh | upstream dropped it somehow | 13:26 |
| \sh | bah it was me too ,-) | 13:26 |
| jwendell | seb128, should I fill a bug? | 13:26 |
| seb128 | jwendell: if there is none yet feel free to open one | 13:27 |
| ogra | seb128, dint you say there would be hal involved ? | 13:27 |
| seb128 | jwendell: that's likely an upstream issue though | 13:27 |
| ogra | after looking | 13:27 |
| seb128 | ogra: that was for the login sound | 13:27 |
| _MMA_ | seb128: I think its related to the sound issues you and I had talked about. | 13:27 |
| seb128 | _MMA_: I don't think so, gdmplay just calls aplay | 13:28 |
| seb128 | it doesn't use libgnome | 13:28 |
| ogra | seb128, ah, k .... i just remembered that asac had ahl probs as well and was wondering if our hal pobably starts to late | 13:28 |
| jwendell | seb128, maybe something related to esd->pulseaudio migration? | 13:28 |
| _MMA_ | Ahh.. | 13:28 |
| seb128 | jwendell: not likely, it uses aplay directly | 13:28 |
| jwendell | seb128, ok, i'll find any related bug in upstream (when b.g.o is back) | 13:29 |
| asac | ogra: apparently hal startup has been moved back at some point ... i had 15 here ... while other users have 23 | 13:29 |
| ogra | asac, ah | 13:31 |
| asac | strange though. | 13:32 |
| jcastro | asac: I am around | 13:32 |
| asac | jcastro: good ... currently talking in #mono on irc.gnome.org | 13:34 |
| _MMA_ | ogra: Have you done a clean Edubuntu install lately? Ubuntu Studio mirrors how Edubuntu sets things up but currently gets no login/out sounds. Im wondering if its the same for you on Edubuntu. | 13:35 |
| ogra | _MMA_, the edubuntu CD is going away in that form, so i dint test ... i had the prob on my classmate image which is a very specific setup and not really comparable to a normal install | 13:37 |
| _MMA_ | Ahh... Ok. Ill have to poke around more. Maybe tie crimsun down at some point. | 13:37 |
| seb128 | pitti: there is a hal dependency issue somewhere, I did apt-get upgrade my desktop and now hal doesn't start | 13:44 |
| seb128 | pitti: hal has been put on hold by I guess something else has been updated that doesn't work with the old hal or something | 13:45 |
| seb128 | ah | 13:46 |
| seb128 | I've libpolkit 0.7 installed with policykit 0.6 | 13:46 |
| pitti | seb128: can you please give some details? it works here | 13:47 |
| pitti | seb128: maybe because I introduced the Breaks: of policykit-gnome and policykit? | 13:47 |
| seb128 | pitti: no, I think it's a lack of break | 13:47 |
| seb128 | I've libpolkit 0.7 and policykit 0.6 | 13:47 |
| seb128 | I guess the lib should not be updated without policykit | 13:48 |
| seb128 | hal error is "Could not init PolicyKit context: (null)" | 13:48 |
| seb128 | let me get libpolkit 0.6 | 13:49 |
| seb128 | pitti: bingo, downgrading libpolkit and libpolkitdbus to 0.6 fixes the issue | 13:53 |
| seb128 | pitti: either libpolkit 0.7 should Depends on policykit >= 0.7 or Breaks policykit <= 0.7 | 13:53 |
| pitti | the latter, I think | 13:53 |
| seb128 | ok | 13:53 |
| seb128 | should I file a bug about it? | 13:54 |
| pitti | it's about as fast to just fix it IMHO | 13:54 |
| seb128 | that's a partial upgrade issue so not high importance | 13:54 |
| seb128 | do you have that in bzr or should I just do the change? | 13:54 |
| pitti | seb128: already at it (no bzr) | 13:55 |
| seb128 | pitti: ok, thanks | 13:55 |
| * seb128 hugs pitti | 13:55 | |
| pitti | seb128: uploaded | 13:56 |
| seb128 | excellent ;-) | 13:56 |
| mantiena-baltix | hi all | 13:58 |
| mantiena-baltix | maybe someone knows why there are not translation templates for brasero CD/DVD burner ? brasero is in main | 13:59 |
| mantiena-baltix | see https://translations.edge.launchpad.net/ubuntu/hardy/+source/brasero | 13:59 |
| seb128 | mantiena-baltix: likely because there has been no upload building a template since it has been promoted in hardy | 13:59 |
| seb128 | mantiena-baltix: should be fixed when somebody does the 0.7.1 update | 14:00 |
| mantiena-baltix | seb128: it seems so, tnaks | 14:00 |
| mantiena-baltix | seb128: lmedinas should do that ;) | 14:00 |
| seb128 | you are welcome | 14:00 |
| mantiena-baltix | lmedinas already packaged 0.7.1 | 14:01 |
| seb128 | mantiena-baltix: so it just require sponsoring? | 14:01 |
| mantiena-baltix | maybe, if Lois isn't ubuntu developer ;) | 14:02 |
| seb128 | mantiena-baltix: bug #186443 | 14:02 |
| ubotu | Launchpad bug 186443 in brasero "New upstream version: 0.7.1" [Undecided,New] https://launchpad.net/bugs/186443 | 14:02 |
| seb128 | mantiena-baltix: should be uploaded soon I think | 14:02 |
| mantiena-baltix | seb128: I too ;) | 14:02 |
| seb128 | I meant that it'll likely been uploaded soon since dholbach already commented on the bug | 14:03 |
| mantiena-baltix | seb128: btw, ppa build daemons still removes translations from debs without universe in section ? | 14:04 |
| seb128 | mantiena-baltix: no idea about this one | 14:06 |
| seb128 | pitti: can you also backport the change from bug #184594 to the retracer? it fails retracing some bugs and just untag those due to it | 14:16 |
| ubotu | Launchpad bug 184594 in python-launchpad-bugs "AssertionError: Wrong XPath-Expr in InfoTable.parse() 'type'" [Undecided,Fix committed] https://launchpad.net/bugs/184594 | 14:16 |
| pitti | seb128: I'd love to, yes | 14:16 |
| seb128 | or tell me how to do it maybe so next time I can do it myself rather | 14:16 |
| _MMA_ | seb128: Who should I talk to about Bug 186365? | 14:19 |
| ubotu | Launchpad bug 186365 in kdelibs "Please move xdg-user-dirs depend to "recommend"" [Undecided,New] https://launchpad.net/bugs/186365 | 14:19 |
| seb128 | _MMA_: kdelibs? the kubuntu team most likely | 14:20 |
| _MMA_ | Ok. | 14:20 |
| === cjwatson_ is now known as cjwatson | ||
| Riddell | _MMA_: not having xdg-user-dirs installed does bad things to kde apps | 14:22 |
| _MMA_ | Riddell: Many apps K apps are relying on these dirs now? | 14:23 |
| Riddell | _MMA_: well kdelibs does | 14:24 |
| _MMA_ | Does xdg-user-dirs do more that stick those 5 dirs in a users home dir? | 14:25 |
| _MMA_ | s/that/than | 14:25 |
| evand | Riddell: indeed, he also posted to the whiteboard on ubiquity-slideshow and to the ubuntu-installer ML. Thanks for the heads up, I'll be following up to his post on the ML. | 14:25 |
| _MMA_ | Riddell: Does xdg-user-dirs do more that stick those 6 dirs in a users home dir? And if they rely so heavily on them, why is one allowed to remove the folders? I'm just trying to figure out what it does. | 14:32 |
| Riddell | _MMA_: that and xdg-user-dir to answer where the directories are | 14:34 |
| bryce | _MMA_ good questions; I've wondered the same | 14:34 |
| _MMA_ | Riddell: We're getting our users doing the same thinga as Bug #158146. "From what I have seen, a lot of new Ubuntu users moves half of the xdg dirs into trash right after installation." So we just decided to not take on this package from Ubuntu. Now it looks like we're forced to because our our inclusion of a K-app. | 14:35 |
| ubotu | Launchpad bug 158146 in xdg-user-dirs "xdg-user-dirs should ignore ~/.Trash" [Undecided,New] https://launchpad.net/bugs/158146 | 14:35 |
| _MMA_ | Riddell: If its moved to a "recommend" anyone installing from the repo should get it right? And xdg-user-dir is already in the kubuntu-desktop seed. Isnt this enough? | 14:39 |
| Riddell | _MMA_: maybe, looking for the bug that made me make that change | 14:42 |
| _MMA_ | Ok. | 14:42 |
| Riddell | _MMA_: https://bugs.launchpad.net/ubuntu/+bug/175982 | 14:44 |
| ubotu | Launchpad bug 175982 in ubuntu "Kdesktop in Kubuntu Hardy shows / icons rather than icons from /home/'usr'/Desktop" [Undecided,Confirmed] | 14:44 |
| * _MMA_ looks. | 14:44 | |
| \sh | pitti, do you have any clue about dh_strip and those error messages? BFD: /home/shermann/packages/hardy/wine/0.9.54/new/wine-0.9.54/debian/wine-dbgsym/usr/lib/debug/./usr/bin/wine-kthread: section `.note.ABI-tag' can't be allocated in segment 2 ? | 14:44 |
| Riddell | so it breaks kdesktop not having it installed | 14:45 |
| pitti | \sh: ergh, no; I never saw anything like that, I'm afraid | 14:45 |
| _MMA_ | Riddell: Even if set as a depend in kubuntu-desktop? (I dont know if thats how you currently have it set up for Gutsy) And this is mostly an annoying cosmetic bug. Id like a better solution if there can be one but understand your position. | 14:48 |
| Riddell | _MMA_: two options, the proper way would be to fix our xdg patches to do something sensible when xdg-user-dirs isn't installed, an easier way would be to make xdg-user-dirs a recomends on kdelibs and a depends on kdesktop (I'd just worry it would break other kde apps) | 14:49 |
| _MMA_ | Riddell: Yes. The latter is something like what I was hoping for as a quick solution but like I said, I understand your position. | 14:51 |
| Riddell | _MMA_: lets do the latter then and see what breaks | 14:52 |
| _MMA_ | Ok. Let me know after the change if you want me to test thing. If it has to revert, I understand. | 14:52 |
| _MMA_ | s/thing/something | 14:53 |
| Riddell | _MMA_: what kde app are you shipping? | 14:54 |
| _MMA_ | Rosegarden I believe. Might be another. | 14:55 |
| * _MMA_ looks. | 14:55 | |
| _MMA_ | Riddell: Rosegarden and creox. Both sound apps we've shipped for 2 releases. | 14:57 |
| * soren hugs pedro_ | 14:57 | |
| soren | pedro_: Thanks for checking the bind9 updates. | 14:57 |
| pedro_ | soren: you're welcome :-) | 14:58 |
| seb128 | pitti: retracers fixed now | 15:06 |
| pitti | seb128: yay you | 15:06 |
| seb128 | pitti: I've changed the gutsy and hardy on i386 and amd64 and verified it retraced correctly a bug which failed before | 15:06 |
| === psicus78_ is now known as psicus78 | ||
| \sh | pitti, when do you have time to work with me for the octave3.0 transition? :) | 15:17 |
| \sh | s/for/on/ | 15:17 |
| pitti | \sh: what do I need to do for that? | 15:18 |
| \sh | pitti, first, we need to sync octave3.0 from debian sid :) second, get rid of octave2.1 and octave2.9, when octave3.0 is build we need to sync some other packages, and I'll upload some more :) | 15:19 |
| \sh | pitti, and as a third point, get rid of koctave... there is a removal report pending :) | 15:20 |
| \sh | pitti, there is a reference on https://bugs.edge.launchpad.net/ubuntu/+source/octave2.9/+bug/185959 | 15:20 |
| ubotu | Launchpad bug 185959 in xmds "octave3.0 transition" [Undecided,Confirmed] | 15:20 |
| pitti | \sh: I can do that any time; just tell me what to do in IRC, and I'll do it | 15:20 |
| \sh | pitti, cool :) | 15:20 |
| \sh | pitti, so I think as a start, sync octave3.0 from debian sid (see bug #185653) | 15:24 |
| ubotu | Launchpad bug 185653 in octave3.0 "[MoM SYNC] octave3.0 3.0.0-1" [Wishlist,Confirmed] https://launchpad.net/bugs/185653 | 15:24 |
| pitti | \sh: shall I remove the older ones now? | 15:26 |
| \sh | pitti, nope...let octave3.0 build first...we have enough time to get rid of 2.1 and 2.9 | 15:26 |
| pitti | \sh: ok | 15:27 |
| \sh | pitti, thx a lot :) | 15:27 |
| pitti | you're welcome! | 15:27 |
| cjwatson | ogra: could you commit the final debian/changelog diff from livecd-rootfs 0.48, please? the changelog still says UNRELEASED | 15:30 |
| pitti | mathiaz: hi | 15:34 |
| mathiaz | pitti: hi ! | 15:35 |
| pitti | mathiaz: do you still plan to switch dhclient to an AA profile, so that we can drop the client derooting patch? | 15:35 |
| mathiaz | pitti: hum... not in the short term | 15:35 |
| * Mithrandir is unhappy about dropping derooting patches just because you can use apparmour instead. | 15:35 | |
| slangasek | seb128: you said there was a new seahorse upstream pending, right? does it fix the 64-bit issues when building with openldap 2.4 due to upstream API deprecation? | 15:37 |
| pitti | Mithrandir: I'm not talkign about droping the dhcp server side one, that's much more robust than anything you can get with AA | 15:38 |
| pitti | Mithrandir: but the client-side patch is horrible and still breaks things occasionally | 15:38 |
| seb128 | slangasek: doesn't look like so, no, do you have a bug about this issue? | 15:38 |
| pitti | Mithrandir: and besides I think the client script suid root wrapper is buggy (you can probably inject environment variables and thus circumvent the derooting) | 15:38 |
| slangasek | seb128: I have the ia64 w-b state for seahorse in Debian :/ | 15:44 |
| slangasek | well, in the build log rather - http://buildd.debian.org/fetch.cgi?pkg=seahorse&arch=ia64&ver=2.20.3-1%2Bb1&stamp=1201299907&file=log&as=raw , last line | 15:44 |
| slangasek | the issue is that ldap_init() (and many other functions) are deprecated upstream, and prototypes are only available if you specify -DLDAP_DEPRECATED | 15:45 |
| seb128 | slangasek: can you open a bug about that? I'm busy with other things right now but I can have a look and send that upstream later | 15:50 |
| slangasek | seb128: yes | 15:51 |
| seb128 | thanks | 15:51 |
| \sh | pitti, how can I say pkg_create_dbgsym to exclude some items like dh_strip -X is doing? | 16:03 |
| pitti | \sh: -X is actually meant to work; however, it currently doesn't (bug 180364) | 16:04 |
| ubotu | Launchpad bug 180364 in pkg-create-dbgsym "ocamlrpcgen no longer works on Gutsy. Probably a wrongly stripped binary" [Undecided,In progress] https://launchpad.net/bugs/180364 | 16:04 |
| \sh | pitti, well, I think wine is having a similar problem...as mentioned earlier with the ".note.ABI-tag" symbol somehow...objcopy fails and -X doesn't work ;) | 16:08 |
| vrodic | tried running latest 2.6.24 package on a Vaio VGN-N31S, got a hang on boot with ACPI: EC: acpi_ec_wait timeout, status=0, expect_event=1 | 16:10 |
| vrodic | and ACPI: EC: read timeout, command=128 | 16:10 |
| \sh | pitti, adding some libs to ia32-libs just needs to add the i386 binary packages to pkgs/ and adding the needed source packages, right? | 16:19 |
| pitti | \sh: no | 16:20 |
| pitti | \sh: just add it to the list in fetch-and-build | 16:20 |
| pitti | \sh: then run that script, add changelog, upload | 16:20 |
| pitti | \sh: I can do it on ronne in the DC, though; the source is incredibly big | 16:20 |
| \sh | pitti, yeah, I just need to test my theory first, so I need to add some libs to it to verify :) | 16:21 |
| pitti | ah | 16:21 |
| pitti | \sh: you can verify by copying the i386 libs from the i386 debs to /usr/lib32/ | 16:21 |
| \sh | pitti, right ;) just need to think about easier ways next time :) | 16:22 |
| pitti | bdmurray: can you please moderate my 'bugpatterns in bzr now' mail to -qa@? | 16:27 |
| ogra | cjwatson, thats weird ... | 16:28 |
| ogra | ogra@laptop:~/livefs/trunk$ bzr st | 16:28 |
| ogra | ogra@laptop:~/livefs/trunk$ grep hardy debian/changelog |head -1 | 16:28 |
| ogra | livecd-rootfs (0.48) hardy; urgency=low | 16:28 |
| cjwatson | ogra: have you pushed? | 16:28 |
| cjwatson | I'm at revision 160 | 16:28 |
| ogra | ogra@laptop:~/livefs/trunk$ bzr push | 16:28 |
| ogra | Using saved location: bzr+ssh://ogra@bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/ | 16:28 |
| ogra | No new revisions to push. | 16:28 |
| cjwatson | ogra: oh, er, *blush*, somehow I have a hardy -> UNRELEASED diff in my local copy | 16:29 |
| cjwatson | wonder how that happened | 16:29 |
| ogra | ah, phew | 16:29 |
| ogra | was worried alrready | 16:29 |
| bddebian | pitti: Hey, sorry to keep bugging you about plr but luk is now asking me if it is even worth keeping in the repo. Do you happen to know of any users? Do you use it? | 16:33 |
| pitti | bddebian: I know that there are quite a few users in Debian, but no idea about Ubuntu | 16:33 |
| pitti | bddebian: and I have never personally used it myself | 16:34 |
| bddebian | pitti: Hmm, OK, thanks | 16:34 |
| pitti | bddebian: I ended up being the Debian maintainer because in ancient versions plr was built from the postgresql source package | 16:34 |
| pitti | bddebian: I split it out, but I haven't found an interested maintainer so far | 16:34 |
| bddebian | Aye | 16:34 |
| === _MMA1 is now known as MetalMusicAddict | ||
| === MetalMusicAddict is now known as _MMA_ | ||
| keescook | oooh... that's fun -- recent gnome pops a file window for every automounted NFS mount I have. :) | 16:53 |
| seb128 | keescook: right, you can go to nautilus properties, media tab, and unselect the option there | 16:54 |
| seb128 | keescook: that's the "browse media when insered" | 16:54 |
| soren | It also pops up when sbuild runs :) | 16:55 |
| ion_ | And when my camera (which uses PTP) is connected, it opens an error dialog about not being able to mount it. | 16:56 |
| ion_ | I’d suggest changing the default value for that setting. | 16:56 |
| seb128 | ion_: I suggest trying to fix the bugs and making it smarter in what it mounts rather | 16:56 |
| bdmurray | pitti: done | 16:56 |
| pitti | bdmurray: cheers | 16:57 |
| keescook | heh, but I like it when CD/DVD insert. I need an "ignore NFS" option. ;) | 16:58 |
| \sh | keescook, me needs an ignore lvm snapshot mounts ;) | 17:02 |
| \sh | but this key for "browse media when inserted" set to false helps a lot | 17:03 |
| mdz | tracker is bringing my machine to its knees again | 17:12 |
| Mithrandir | I think tracker has been bestowed on us as a compensation for the work we're doing to bring power consumption down. | 17:13 |
| mdz | it apparently churned all weekend, though I didn't add anything new to my home dir | 17:15 |
| seb128 | it's buggy | 17:15 |
| mdz | 979M/home/mdz/.cache/tracker | 17:15 |
| mdz | that's >10% of my home dir :-) | 17:16 |
| seb128 | I tend to agree that it has bugs and doesn't bring a lot and should probably not be installed on hardy by default | 17:16 |
| ogra | ubuntu hardy minimal requirements for laptops: 4Gig of ram and at least a RAID0 array with 10000rpm disks :P | 17:17 |
| ogra | seb128, did we ever had that many probs with beagle ? | 17:18 |
| ogra | *have | 17:18 |
| ogra | we should probably just switch back to not lose features | 17:19 |
| ogra | (desktop searching was promoted pretty loud in gutsy, people might expect it) | 17:20 |
| seb128 | ogra: beagle is to universe, has no maintainer in ubuntu and we basically didn't test it, I would not recommend switching right now before a lts | 17:23 |
| ogra | ah, bad ... i didnt know nobody takes care for it aymore | 17:23 |
| ion_ | All things considered, i’ve always had a better experience with tracker. It also has the whole generic metadata DB thing, which will be teh awesome when programs start using it. | 17:24 |
| ogra | ion_, well, after gutsy release i had a lot of ltsp people complaining ... while we dont install it in edubuntu, there are setups out there where people use ubuntu-desktop in an ltsp setup with nfs mounted homedirs and 200 users logging in in the morning ... | 17:26 |
| ogra | i bet you can imagine what tracker does to your network in such a case | 17:26 |
| jamiemcc | ogra: its designed to ignore nfs by default however there is a bug in the index mounted option | 17:27 |
| jamiemcc | we are working on resolving all serious bugs | 17:27 |
| jamiemcc | mdz: do you have any details on your problem? | 17:28 |
| * ogra goes for dinner and caring for his cold ... | 17:29 | |
| \sh | ogra, gute besserung | 17:29 |
| ogra | \sh, danke | 17:30 |
| ogra | \sh, i'm appaernly better than the others that catched something, so i won moan :) | 17:30 |
| \sh | ogra, oh sprint flu? ;) | 17:30 |
| ogra | just a cold here | 17:30 |
| ogra | others seem to have a flu | 17:31 |
| mdz | jamiemcc: apart from this? | 17:31 |
| mdz | 24644 mdz 39 19 1049m 641m 1644 S 14.9 42.3 1915:33 trackerd | 17:31 |
| mdz | jamiemcc: I'm not sure how to determine what it's doing | 17:31 |
| mdz | jamiemcc: the applet says intermittently "indexing completed" and "indexing in progress" | 17:31 |
| Spenser309 | Can anyone tell me how to run an shell command automatically when a cd is inserted? | 17:32 |
| jamiemcc | mdz: is anything being modified file wise? | 17:32 |
| mdz | jamiemcc: I'm reading mail, which means files are being moved around within my maildirs | 17:32 |
| mdz | jamiemcc: xchat is writing to its logfiles | 17:32 |
| mdz | but the total size of the files being updated should be miniscule | 17:33 |
| jamiemcc | mdz: yeah | 17:33 |
| jamiemcc | mdz: what about cpu? | 17:33 |
| jamiemcc | is trackerd consuming tons? | 17:33 |
| mdz | jamiemcc: it seems to take a much longer time to update the index for small changes than I would expect | 17:33 |
| \sh | ogra, huehnerbruehe should be good for that, as my grandma said :) | 17:33 |
| mdz | jamiemcc: right now it's holding 15-20%, but I've seen it much higher | 17:33 |
| keescook | soren, \sh: yeah, I hadn't gotten to the snapshot mounting yet either. Heh. Maybe a "ignore paths: /var/schroot/mount, ..." option | 17:33 |
| mdz | it's consuming gobs of memory too | 17:33 |
| jamiemcc | mdz: yeah its beacuse ext3 really sucks when doing lots of small writes | 17:34 |
| mdz | jamiemcc: is the size of my index normal? | 17:34 |
| jamiemcc | mdz: 900mb? | 17:34 |
| mdz | jamiemcc: for a ~13G /home | 17:34 |
| mdz | mostly photos and music | 17:34 |
| jamiemcc | mdz: for text files (source and emails) its usually no more than 20% | 17:35 |
| jamiemcc | mdz: is file-meta.db huge? | 17:35 |
| mdz | 12K email-contents.db 293M file-contents.db 1.8M file-update-index.db | 17:35 |
| mdz | 1.2M email-index.db 489M file-index.db | 17:35 |
| mdz | 100K email-meta.db 195M file-meta.db | 17:35 |
| \sh | pitti, looks like that I need libjack, libcapi20 and unixodbc in ia32-libs...let's see when the build is finished and hopefully when wine starts | 17:35 |
| jamiemcc | 195MB seems a bit high - a file normally eats about 1K so unless you have 200,000 files it might be too high? | 17:36 |
| mdz | jamiemcc: I might, I have tens of thousands of emails | 17:37 |
| mdz | 193001 files | 17:37 |
| jamiemcc | mdz: thats a lot | 17:37 |
| mdz | I should probably exclude my maildirs; it isn't very useful to have them indexed anyway | 17:37 |
| jamiemcc | mdz: it seems to be indexing your emails as files though | 17:38 |
| jamiemcc | mdz: because your email-* is very small | 17:38 |
| mdz | jamiemcc: yes, I assumed that was normal. is it supposed to recognize maildirs as email? | 17:38 |
| jamiemcc | mdz: not yet - we only support evolution mbox and imap | 17:38 |
| mdz | jamiemcc: imap? how does that work? | 17:39 |
| jamiemcc | mdz: i would recommend adding maildirs to ignore paths in tracker-preferences | 17:39 |
| jamiemcc | mdz: if imap files are stored locally under .evolution we index them as emails | 17:39 |
| mdz | I've excluded them now, will see if that makes a difference | 17:40 |
| jamiemcc | mdz suggest you do trackerd -R to reindex so that it cleans it up | 17:40 |
| jamiemcc | you will have much smaller dbs then | 17:40 |
| Mithrandir | seriously, does it use a gigabyte for only 300k files? | 17:42 |
| jamiemcc | Mithrandir: no worst case (if files contain a lot of metadata) | 17:42 |
| jamiemcc | a text file has maybe a 100bytes of metadata | 17:42 |
| jamiemcc | an mp3 might have 1kb+ | 17:43 |
| \sh | pitti, please get rid of koctave (see bug #185989) (source and bins for hardy) thx :) | 17:43 |
| ubotu | Launchpad bug 185989 in koctave "[REMOVAL REQUEST] koctave" [Undecided,Confirmed] https://launchpad.net/bugs/185989 | 17:43 |
| mdz | jamiemcc: changing my preferences restarted trackerd, and now it's grinding away again, "indexing in progress" "1/2 folders" | 17:43 |
| jamiemcc | mdz: yeah its probably deleting all the files in that ignored directory | 17:44 |
| mdz | my index just grew another 50M | 17:44 |
| jamiemcc | mdz: if you had a ton of files there its better to reindex | 17:44 |
| Mithrandir | jamiemcc: well, I have about 1.9M files in ~.. | 17:44 |
| mdz | ok | 17:45 |
| mdz | Mithrandir: mostly source code? that should be fun | 17:45 |
| jamiemcc | Mithrandir: heh | 17:45 |
| jamiemcc | Mithrandir: its why we have the ignored folder setting | 17:45 |
| Mithrandir | mdz: mostly emails. | 17:46 |
| Mithrandir | I have 12 years of emails, in maildirs. | 17:46 |
| mdz | Mithrandir: my mail from pre-2003 is compressed and archived | 17:47 |
| mdz | because I never look at it | 17:47 |
| jamiemcc | I guess i need to make sure tracker does not treat mail dirs as files | 17:47 |
| mdz | jamiemcc: maybe better to exclude them until they're properly supported, if that's simpler | 17:48 |
| jamiemcc | mdz: yeah makes sense | 17:48 |
| \sh | jamiemcc, do you actually know what could it be, that even I disabled trackerd from my gnome-session completly, that it's re-starting...even when told not to start at all? I wonder what's the trigger is, mostly it does it after upgrading | 17:49 |
| jamiemcc | \sh: could be activated by nautilus | 17:49 |
| jamiemcc | \sh: disable tracker in tracker-prefs (set watch dir to something bogus) | 17:49 |
| \sh | jamiemcc, ok..done | 17:52 |
| pitti | \sh: koctave removed | 17:53 |
| \sh | pitti, you rock..thx :) | 17:53 |
| Spenser309 | can anyone point me to a hal example | 18:04 |
| pitti | seb128: oh, argh, it needs ggz-server, too | 18:05 |
| seb128 | pitti: ups | 18:06 |
| pitti | seb128: I'll upload a new package with a fixed libdb dep and take a look | 18:06 |
| seb128 | pitti: thanks | 18:06 |
| === fabbione is now known as thegodfather | ||
| === dholbach_ is now known as dholbach | ||
| warp10 | Heya all! | 18:27 |
| === asac_ is now known as asac | ||
| === thekorn_ is now known as thekorn | ||
| slangasek | is anyone working on bug #184585 in gnome-mount? this seems to happen quite regularly for me on hardy :/ | 19:31 |
| ubotu | Bug 184585 on http://launchpad.net/bugs/184585 is private | 19:31 |
| \sh | pitti, could you un-NEW octave3.0 binaries for i386 and amd64, pls? :) | 19:31 |
| slangasek | hrm, "private", perhaps that's its own answer... | 19:32 |
| * ScottK mumbles something about sylpheed-claws-gtk2 stuck in dapper-backports NEW .. | 19:32 | |
| slangasek | ah, did pitti not get to that one? | 19:32 |
| ScottK | slangasek: No. I forgot to ask for it. | 19:33 |
| * ScottK forget that sylpheed-claws spawns new packages at a rate of several per release. | 19:34 | |
| ScottK | forget/forgot | 19:34 |
| * slangasek hehs | 19:34 | |
| * ScottK hopes that was funny enough to rate getting his package binary NEWed. | 19:35 | |
| slangasek | I think so. :) | 19:36 |
| slangasek | but first I have to un-bork grub | 19:36 |
| ScottK | Great. | 19:37 |
| === _MMA1 is now known as _MMA_ | ||
| === cr3_ is now known as cr3 | ||
| tmccrary | Does ubuntu support multiarch? | 20:24 |
| Mithrandir | no | 20:24 |
| tmccrary | Are there any plans to support in the near future? | 20:25 |
| Mithrandir | not in the near future, no. Long-term, hopefully. | 20:26 |
| daxroc | Evening all | 20:28 |
| daxroc | Is this the channel to discuss hardy suspected bugs ? | 20:29 |
| LaserJock | not really, #ubuntu-bugs might be a better place or maybe #ubuntu+1 | 20:30 |
| daxroc | Thanks LaserJock | 20:30 |
| tjaalton | slangasek: b.edge.lp.net doesn't like my sync requests (getting an Oops every time).. could you sync xserver-xorg-video-nv from unstable, there was a new bugfix release on Friday, includes the only patch in our package | 20:31 |
| === _MMA1 is now known as _MMA_ | ||
| slangasek | tjaalton: any chance that b.lp.net works better than b.edge.lp.net? I'm happy to do the sync but can't promise that my memory is longer than my todo list at the moment | 20:34 |
| pochu | tjaalton: bug 186564 | 20:35 |
| ubotu | Launchpad bug 186564 in malone "OOPS with edge.launchpad.net while submitting a report without an attachment" [High,Fix committed] https://launchpad.net/bugs/186564 | 20:35 |
| tjaalton | slangasek: I bet it works there, will do | 20:36 |
| tjaalton | pochu: ok, nice to know it's fixed already :) | 20:36 |
| tjaalton | slangasek: done, u-a subscribed | 20:39 |
| slangasek | tjaalton: cheers | 20:40 |
| \sh | cjwatson, ping a question concerning your gpg key and the signatures on your subkey | 20:44 |
| lamont | hrm... can one Pre-Recommends, I wonder? | 21:00 |
| === \sh is now known as \sh_away | ||
| slangasek | how is that going to be different than a regular Recommends? | 21:01 |
| slangasek | if it's a recommends, it's not enforced; so what difference if it fails to be enforced before or after unpacking? :) | 21:01 |
| lamont | point | 21:01 |
| * lamont wonders what the failure mode is that caused lzma to be a pre-depends of dpkg in hardy | 21:01 | |
| StevenK | lamont: calc | 21:04 |
| ScottK2 | slangasek: How's grub? Standing up again on it's own? | 21:05 |
| slangasek | ScottK2: yeah, I'm just about to upload my changes | 21:05 |
| slangasek | after a morning-long foray into setting up my first lp bzr project | 21:06 |
| ScottK2 | Yummy. | 21:06 |
| === rzr is now known as rZr | ||
| seb128 | grrr tracker eating 100% CPU when the laptop is on battery | 21:12 |
| seb128 | ah, it's broken again, the applet doesn't indicate what it's doing | 21:14 |
| === Ubulette_ is now known as Ubulette | ||
| lool | seb128_: lalala tracker lalala :) | 21:23 |
| lool | seb128_: But you were right, one can get rid of the icon completely by removing all tracker packages | 21:23 |
| === seb128__ is now known as seb128 | ||
| cjwatson | \sh_away: pong | 21:56 |
| cjwatson | lamont: dependencies of essential packages generally need to be pre-depends instead in order to enforce that the package works even while unconfigured | 21:57 |
| cjwatson | hence why coreutils and libc6 are pre-depends too | 21:57 |
| lamont | cjwatson: yeah. OK. | 21:57 |
| lamont | just makes what I'm banging my head against more painful | 21:57 |
| cjwatson | (gzip and bzip2 aren't there because dpkg links statically against zlib and libbz2. you probably know this but I mention it for completeness.) | 21:58 |
| * lamont needs an lzma packaged package | 22:40 | |
| ScottK2 | lamont: I think python-qt4 is, but I'm not certain. | 22:42 |
| lamont | er. source or bin? | 22:42 |
| slangasek | nothing in the archive will be. I think the test subject for lzma is OOo... | 22:42 |
| lamont | ah, ok | 22:42 |
| lamont | DOH | 22:43 |
| lamont | slangasek: thank you for the cluebat | 22:43 |
| slangasek | lamont: for pointing out that there are no such packages in the archive because we're waiting on what you're doing? :-) | 22:43 |
| lamont | got it in one | 22:43 |
| * LaserJock wondered | 22:43 | |
| lamont | slangasek: so, um, my python-apt is not for non-english-speakers. :-P | 22:45 |
| cjwatson | grab some random small package and do dh_builddeb -- -Zlzma on it | 22:45 |
| slangasek | lamont: ...ok? | 22:46 |
| lamont | dh_builddeb -Zlzma | 22:48 |
| lamont | Unknown option: Z | 22:48 |
| lamont | cjwatson: please tell me we don't need debhelper for this... that's way scary | 22:49 |
| slangasek | double-dash | 22:49 |
| lamont | oh | 22:49 |
| slangasek | you can do it with dpkg-deb too, I suppose? | 22:49 |
| cjwatson | indeed | 22:49 |
| cjwatson | dh_builddeb -- OPTIONS-TO-DPKG-DEB | 22:49 |
| lamont | x - data.tar.lzma | 22:51 |
| lamont | Unpacking ed (from .../lamont/ed_0.7-1build1_i386.deb) ... | 22:51 |
| lamont | Setting up ed (0.7-1build1) ... | 22:51 |
| lamont | win | 22:51 |
| * lamont finds a certain amount of humor in gutsy's dpkg + lzma being able to unpack the .deb too | 22:54 | |
| lamont | slangasek: in the end, my solution to python-distutils-extra was, um, a crowbar. | 22:59 |
| lamont | if someone cares, they can give me a patch. :-P | 22:59 |
| slangasek | I think caring about that is your department, not ours :) | 23:01 |
| lamont | given the target audience, ENOPROBLEM | 23:02 |
| TheMuso | cjwatson: Thanks for the ubuntustudio seed merge, however joejaxx could have easily taken care of it. | 23:04 |
| * ScottK idly mentions that someone earlier said something about NEWing something in dapper-backports after grub was fixed ... | 23:05 | |
| cjwatson | TheMuso: oh, I was just merging everything at once, not specifically ubuntustudio | 23:05 |
| ScottK | ... and then runs off to untangle the necklace his 4 year old just handed him. | 23:05 |
| TheMuso | cjwatson: Fair enough. | 23:05 |
| cjwatson | due to being up to my armpits in seed reorg stuff at the moment | 23:06 |
| lamont | ScottK: btw, 2.5.0-1 uploaded to experimental if you want to have fun with it | 23:06 |
| lamont | (and like see if you see any major b0rkage, etc) | 23:06 |
| * milli will try out 2.5.0-1, thanks | 23:07 | |
| lamont | postfix | 2.5.0-1 | experimental | source, i386, sparc | 23:07 |
| lamont | milli: oh, thanks. | 23:07 |
| milli | どういたしまして | 23:09 |
| lamont | cjwatson: slangasek: lest you think we're too far along, there is still a bit of testing to make sure we didn't break anything horribly elsewhere, etc, etc. | 23:14 |
| milli | although best I can do is build from source, it seems.. | 23:14 |
| lamont | milli: yeah. let me get you a gutsy version? | 23:14 |
| milli | feisty :) | 23:15 |
| lamont | milli: SLACKER | 23:15 |
| milli | on the main mail server.. | 23:15 |
| milli | I resemble that remark! | 23:15 |
| * lamont builds gutsy for his home machine first | 23:15 | |
| * lamont just nuked the local feisty mirror, you see. | 23:16 | |
| * milli is grabbing source for feisty box | 23:16 | |
| lamont | ok. just please remember to tweak changelog to say '2.5.0-1~feisty1', mk? | 23:17 |
| milli | vi changelog... | 23:17 |
| lamont | apt-get install devscripts; dch -i | 23:17 |
| lamont | or you could just vi | 23:17 |
| lamont | or we could read the manpage and see how to tell dch to get the ~feisty1 version without changing it in vi | 23:18 |
| lamont | ii postfix 2.5.0~rc2-0~gutsy1 High-performance mail transport agent | 23:18 |
| lamont | heh. I think this should wokr | 23:18 |
| ScottK2 | dch -v | 23:18 |
| * lamont wanders off | 23:21 | |
| jdong | urr.... launchpad is not accepting my bug report? | 23:27 |
| * jdong screams scandal | 23:27 | |
| crimsun | jdong: see the topic of #launchpad | 23:30 |
| jdong | crimsun: thanks :) | 23:31 |
| crimsun | yw | 23:31 |
| jdong | kk tx gl hf gg nr20 tvb no zerg | 23:32 |
| ScottK | lamont: I'm going to throw Postfix 2.5.0 up in my ppa. | 23:36 |
| * LaserJock wonders if ScottK will throw it hard enough to break | 23:36 | |
| ScottK | We're about to find out. | 23:36 |
| StevenK | pitti: I've run ./update for -meta and it's removing restricted-managed -- baaaaad? | 23:38 |
| cjwatson | restricted-manager got renamed | 23:39 |
| jdong | aww I was hoping for a more sensational explanation :( | 23:39 |
| StevenK | cjwatson: Ahh. What's the new name, so I can check it still exists? | 23:39 |
| TheMuso | jockey-gtk/jockey-common | 23:40 |
| StevenK | Jockey? Oh man. | 23:40 |
| bigon | mmm I have a question shouldn't libasound2-plugins be installed by default to make pulseaudio works by default on hardy? | 23:41 |
| StevenK | Which isn't in debian/control | 23:41 |
| TheMuso | bigon: Um, pulseaudio gets installed and gets used by default, without the need for that package. | 23:41 |
| TheMuso | bigon: That package has a plugin to allow alsa apps to be sent through pulseaudio however. | 23:42 |
| StevenK | cjwatson: Should I be worried that jockey-{gtk,common} isn't in debian/control of -meta? | 23:42 |
| bigon | TheMuso: aplay doesn't work without it | 23:42 |
| TheMuso | bigon: hrm. I'd need to confirm that myself, which I currently can't do. | 23:42 |
| crimsun | is pulseaudio-utils in the desktop seed? | 23:43 |
| crimsun | if so, aplay "not working" is moot, since you can just use paplay. | 23:43 |
| lamont | Unable to find distroseries: fiesty | 23:43 |
| lamont | ScottK: it's spelled 'fisty' | 23:43 |
| lamont | or something liek that | 23:43 |
| cjwatson | StevenK: sounds odd, worth checking | 23:43 |
| bigon | paplay is not installed here | 23:43 |
| ScottK | Hmmm | 23:43 |
| cjwatson | StevenK: should be showing up in desktop-recommends or whatever it is | 23:44 |
| crimsun | bigon: then pulseaudio-utils needs to be massaged in[to] the seeds. | 23:44 |
| bigon | ok | 23:44 |
| ScottK | i before e, except after c. I know. | 23:46 |
| StevenK | cjwatson: Interesting. jockey-gtk is in desktop-recommends-i386, but not in debian/control | 23:47 |
| * ScottK tries again. | 23:48 | |
| cjwatson | StevenK: err. did you look at debian/control, or are you just grepping? :-) | 23:50 |
| cjwatson | StevenK: it uses substvars rather extensively ... | 23:50 |
| StevenK | cjwatson: I was just grep'ing, so I'm a dork. :-) | 23:51 |
| cjwatson | StevenK: that's a relief ;-) | 23:53 |
| lbathnc | what programing language should one learn to program in Ubuntu | 23:53 |
| Nafallo | python | 23:53 |
| ScottK | lamont: It's in my PPA for dapper/edgy/feisty (now spelled correctly)/gutsy. Now I wait to see if it builds. | 23:53 |
| ToyKeeper | Heh, generally a good choice anyway... easy to learn, yet has a high abstraction ceiling. :) | 23:53 |
| * LaserJock recommends C++ :-) | 23:54 | |
| LaserJock | just to be different | 23:54 |
| lamont | ScottK: it'll need to have had s/binary:Version/Source-Version/ in debian/control, as well as the db hackery | 23:54 |
| lbathnc | why choose Ubuntu over Fedora core 8 | 23:55 |
| lamont | LaserJock: my coding is a mashup of C, python, and sh, actually | 23:56 |
| lamont | sh for trivial stuff, python when it gets a bit more complex, and C when it has to be. | 23:57 |
| lamont | or I'm working on a package. | 23:57 |
| LaserJock | lamont: that's about what I do, except I guess s/C/C++/ but that's sort of trivial | 23:57 |
| lamont | C++ is on my list of 'gonna learn that thar thang someday' | 23:57 |
| lamont | actually started reading a book a little. | 23:57 |
| milli | C++ ain't that hard | 23:58 |
| lbathnc | why C++ over python | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!