| cjwatson | directhex: let me know when you've had .orig.tar.gz confirmation from meebey | 00:01 |
|---|---|---|
| directhex | confirmed | 00:02 |
| cjwatson | directhex: hmm, xsp won't dep-wait; all its build-dependencies are already available | 00:04 |
| cjwatson | directhex: I think I'll indeed leave this until tomorrow morning after it's all built and I've done binary NEW | 00:05 |
| cjwatson | seems safer | 00:05 |
| directhex | yeah, indeed. let me check my build-deps | 00:05 |
| cjwatson | I don't have a major problem with the build-deps not being 100% accurate for Ubuntu since we're going to operate in strict order anyway, but you might want to get them right for Debian | 00:06 |
| directhex | hm, no, i think it's a bug in the archive. build-depends-indep: mono-devel | 00:07 |
| directhex | mono-devel doesn't currently exist in jaunty | 00:08 |
| directhex | i should version that as (>=2.0) though | 00:08 |
| cjwatson | oh, yeah, you're right | 00:08 |
| cjwatson | no bug in the archive, bug in my brain | 00:08 |
| directhex | same difference! | 00:08 |
| cjwatson | thankfully, the archive has more work to do :) | 00:09 |
| directhex | heh! | 00:09 |
| cjwatson | I've uploaded xsp, then | 00:09 |
| Mithrandir | mmm, braaains | 00:09 |
| directhex | yay, thanks cjwatson | 00:09 |
| cjwatson | Mithrandir: could you score up https://launchpad.net/ubuntu/+source/mono/2.0.1-0ubuntu1/+build/794238, please? sparc is down to one buildd so it'll take forever otherwise | 00:12 |
| cjwatson | maybe also https://launchpad.net/ubuntu/+source/mono/2.0.1-0ubuntu1/+build/794235, though that's less bad | 00:13 |
| Mithrandir | cjwatson: sure, doing so | 00:14 |
| Mithrandir | done, 5k | 00:14 |
| cjwatson | thanks | 00:14 |
| Mithrandir | 50k for sparc, so it builds now | 00:14 |
| * Hobbsee waves to Mithrandir, directhex, and cjwatson | 00:14 | |
| directhex | hello Hobbsee | 00:15 |
| cjwatson | perfect, all builds due to start within an hour now | 00:15 |
| Mithrandir | hiya little green Australian | 00:15 |
| cjwatson | Hobbsee: hiya | 00:15 |
| Hobbsee | Mithrandir: i'm not a green alien today. i'm a blue, crystalised alien. | 00:15 |
| Mithrandir | oh, is it cold? | 00:16 |
| Hobbsee | very. 14C here | 00:16 |
| directhex | 14C is cold? | 00:16 |
| directhex | they had snow oop norf today! | 00:16 |
| Hobbsee | directhex: it is for here | 00:17 |
| Hobbsee | we're probably getting snow on the mountains today | 00:17 |
| Hobbsee | directhex: oh, and i freeze extremely quickly. | 00:17 |
| Mithrandir | it's only like 20°C here now. | 00:17 |
| Hobbsee | send us a bit of warmth, then! :P | 00:18 |
| Mithrandir | I'm here for another week, come visit | 00:18 |
| Hobbsee | someone else can do my dratted exams? | 00:18 |
| Hobbsee | oh *damn*. This is the max temp for san fransisco in december, too. I thought it'd be a bit warmer, at least. | 00:21 |
| stgraber | Hobbsee: California will be warm, at least compared to what I've here (-7C) :) | 00:30 |
| Hobbsee | stgraber: ewww! | 00:30 |
| Hobbsee | stgraber: you're..canadian now, right? | 00:30 |
| directhex | http://www.bbc.co.uk/weather/5day.shtml?id=2941 - toasty! | 00:31 |
| stgraber | yeah but I'd have get something similar in switzerland too | 00:31 |
| stgraber | but yeah, if you plan to relocate and like warm winters, don't choose canada :) | 00:32 |
| directhex | go south for the winter? | 00:33 |
| stgraber | yeah, I should ask to work at the Brazilian office during the winter :) (well, office == 1 employee at the moment) | 00:36 |
| directhex | so ask to work in a brazilian employee's closet? | 00:38 |
| directhex | and now, time for bed. tonight i sleep the sleep of the just | 00:43 |
| Hobbsee | night! | 00:45 |
| kirkland | madduck: because the user might boot into a system where they are no longer protected by redundancy, and loss of a second disk would spell permanent data loss | 01:26 |
| kirkland | madduck: seemed wise, to us, to provide the option to the system administrator | 01:26 |
| === foxxtrot_ is now known as foxxtrot | ||
| persia | directhex, Some people have found that using gzip -9fn is a handy for bzip -> gzip changes to maintain md5sum reproduction (for future reference) | 03:18 |
| === anil1 is now known as anilg | ||
| madduck | kirkland: sure, knowing that there is no redundancy and the data are in immediate danger is helpful, but choosing not to assemble the degraded array doesn't increase the lifetime of the other component disks. | 09:19 |
| doko_ | directhex, cjwatson: mono did fail to build on arm. maybe wait until accepting it from NEW? | 09:44 |
| directhex | doko_, doko_ balls. build log? | 10:17 |
| directhex | wait, got it | 10:18 |
| doko_ | directhex: see bug 301232 | 10:18 |
| ubottu | Launchpad bug 301232 in mono "armel build failure" [High,Confirmed] https://launchpad.net/bugs/301232 | 10:18 |
| directhex | NCommander, i need your healing touch i think | 10:19 |
| directhex | doko_, i don't have much knowledge of arm porting. can you answer a couple of questions, or should i wait for NCommander to appear? | 10:36 |
| doko_ | directhex: not that much time today, I may be unresponsive | 10:39 |
| === doko_ is now known as doko | ||
| directhex | doko, i think the problem comes from incomplete changes to the code relating to the new arm-darwin target (i.e. iphone). the darwin target explicitly defines -DARM_FPU_NONE=1, the linux target does not. what kind of FPU should be checked for slash built for? | 10:49 |
| directhex | hm, config.log would probably be helpful :/ | 10:55 |
| doko | directhex: defining -DARM_FPU_NONE=1 should be ok for now | 11:00 |
| directhex | for now? | 11:00 |
| cjwatson | doko: rather too late, I already accepted it | 11:04 |
| cjwatson | directhex: we might want a variant built with VFP later, but ARM_FPU_NONE will be a baseline | 11:05 |
| doko | directhex: yes | 11:05 |
| directhex | morning cjwatson | 11:06 |
| directhex | i'll prep a 0ubuntu2 then, it's a 1-line change | 11:06 |
| cjwatson | throw me a patch and I'll sponsor it | 11:06 |
| cjwatson | directhex: did you get round to writing that gluezilla MIR? | 11:37 |
| directhex | cjwatson, no, it was late last night, and i got up late today | 11:38 |
| directhex | cjwatson, i'll do that now | 11:38 |
| cjwatson | mono-debugger uploaded | 11:42 |
| cjwatson | directhex: was there a reason to repack the mod-mono tar? | 11:45 |
| cjwatson | (i.e. do you want to take the opportunity to just bunzip2 | gzip?) | 11:46 |
| directhex | no explicit reason (i was probably glancing over the code), but at this stage, it would do more harm than good to regenerate the orig (as meebey has already got the one from LP to be used for debian) | 11:48 |
| cjwatson | ok | 11:48 |
| directhex | rules r.e. repacking are being added to cli policy | 11:48 |
| directhex | or at least to team policy | 11:48 |
| cjwatson | directhex: mono-debugger failed to build: http://launchpadlibrarian.net/19878271/buildlog_ubuntu-jaunty-i386.mono-debugger_2.0-0ubuntu1_FAILEDTOBUILD.txt.gz | 11:50 |
| cjwatson | mod-mono uploaded | 11:50 |
| directhex | okay, thanks for mod-mono | 11:52 |
| directhex | mono-debugger..... it seems that whilst it was marked as "done", it's anything but. sigh. | 11:52 |
| directhex | sorry | 11:52 |
| cjwatson | looks like mono-debugger needs to look for gmcs2 rather than gmcs? | 11:52 |
| cjwatson | or is that a bug in mono-gmcs? | 11:53 |
| cjwatson | hmm, or csc? | 11:53 |
| directhex | control and rules need patching | 11:54 |
| directhex | for all my bluster, it hasn't actually been transitioned to the new build-deps | 11:55 |
| directhex | cjwatson, it should look for csc, but that change isn't in svn. i'll do it now | 11:55 |
| cjwatson | ok | 11:55 |
| directhex | gah, parents have turned up. back in a couple | 12:01 |
| === _luisbg is now known as luisbg | ||
| === mrooney1 is now known as mrooney | ||
| maxb_ | Would anyone happen to know of an alternate implementation of sha256 besides the coreutils one? | 16:10 |
| maxb_ | it and reprepro are disagreeing about what the sha256 of a file is, and I want to determine which package has the bug by getting a third opinion | 16:11 |
| directhex | cjwatson, ping: https://bugs.launchpad.net/ubuntu/+source/mono/+bug/301232 | 16:13 |
| ubottu | Ubuntu bug 301232 in mono "armel build failure" [High,Confirmed] | 16:13 |
| geser | maxb_: openssl dgst -sha256 $file | 16:19 |
| cjwatson | directhex: I think it would be better to decide on a particular one in debian/rules, rather than having it depend on the build machine | 16:32 |
| cjwatson | directhex: we don't necessarily want runtime requirements to be identical to what the buildd has available | 16:32 |
| cjwatson | directhex: ... i.e. add --with-fpu=NONE on armel please? | 16:33 |
| directhex | cjwatson, eh, it's added: | 16:35 |
| directhex | else ifeq ($(DEB_BUILD_ARCH), armel) | 16:35 |
| directhex | CONF_FLAGS += --with-tls=pthread --with-fpu=NONE | 16:35 |
| cjwatson | directhex: not in the debdiff attached to that bug | 16:36 |
| cjwatson | directhex: oh, I see, it was there already | 16:36 |
| directhex | cjwatson, upstream promised the --with-fpu= thing had gone upstream a while ago. it's a regression that means it's gone, so we've updated a dpatch which adds it back | 16:37 |
| directhex | so passing --with-fpu wasn't doing anything | 16:37 |
| cjwatson | directhex: ok, edited the changelog entry to close that LP bug, otherwise uploading as given | 16:37 |
| cjwatson | thanks | 16:37 |
| directhex | cjwatson, well, meebey fixed it, i was out with visiting parents today | 16:38 |
| cjwatson | directhex: oh, I'm also putting the Ubuntu Maintainer field back | 16:47 |
| directhex | oh, cocks, sorry. i keep forgetting about those | 16:49 |
| cjwatson | directhex: sorry to keep going back and forward, but is it just me or will the automatic detection override anything you set via AC_TRY_WITH anyway? | 16:56 |
| cjwatson | directhex: it doesn't seem to check whether fpu is already set before doing AC_TRY_COMPILE | 16:56 |
| cjwatson | directhex: ... except that I'm blind and can't read diffs. Ignore me! | 16:56 |
| directhex | /ignore | 16:56 |
| cjwatson | really uploaded this time | 16:57 |
| directhex | heh. better *right* than rushed | 16:59 |
| === njpatel is now known as njpatel_away | ||
| directhex | sparc build of mono 2.0.1-0ubuntu2 in ubuntu jaunty RELEASE | 17:37 |
| directhex | Estimated build start: 2008-11-26 | 17:37 |
| directhex | someone needs to beat more sunfires out of sun | 17:37 |
| directhex | (nah, scoring it up isn't worth it, it has 0ubuntu1 and 0ubuntu2 is arm fixes only) | 17:38 |
| directhex | jaunty armel Successfully built (ACCEPTED) | 18:34 |
| directhex | cjwatson, can i hear a "w00t"? :) | 18:34 |
| cjwatson | directhex: w00t | 19:04 |
| directhex | :) | 19:04 |
| directhex | cjwatson, hanska has finalized his monodoc 2.0 package, which includes some *great* backports from 2.2 (in <2.2, the monodoc.xml index file needs mangling every time a manual package is added or removed, we've backported dynamic index generation from an improvement upstream wrote for our benefit). once meebey signs off on it, i'll file a bug on that. ditto a *fixed* mono-debugger | 19:06 |
| cjwatson | ok, cool | 19:07 |
| === RAOF_ is now known as RAOF | ||
| NCommander | hola | 19:44 |
| directhex | HELO! | 19:47 |
| directhex | NCommander, needed you this morning, had to fix armel ftbfs all alone ;) | 19:47 |
| NCommander | I was recovering from beer | 19:48 |
| NCommander | directhex, and the ARM one is still broken | 19:48 |
| directhex | NCommander, hm? | 19:49 |
| NCommander | directhex, nm, the build log I saw was old | 19:50 |
| NCommander | directhex, how did you fix it? | 19:50 |
| NCommander | (what did you define?) | 19:50 |
| directhex | NCommander, we had an old patch to make configure understand a --with-fpu= setting, which we turned back on after refreshing | 19:50 |
| directhex | NCommander, basically defining ARM_FPU_NONE explicitly | 19:51 |
| NCommander | I thought were compiling FPU support in ... | 19:51 |
| NCommander | directhex, er, nm | 19:51 |
| directhex | NCommander, important thing is, mono 2.0.1 ACCEPTED on armel | 19:52 |
| persia | NCommander, The idea is to start with a base system that should work everywhere, and build optimised versions of libraries where required. It might make sense to have a vfp version of mono, but not in the default build. | 19:53 |
| NCommander | persia, an VFP version will work fine | 19:53 |
| NCommander | The kernel will catch the exception when a FPU instruction is executed, and then emulate it | 19:53 |
| NCommander | (its slow, but the binaries themselves would worK :-)) | 19:53 |
| persia | slow isn't better :) | 19:54 |
| directhex | i'm open to long-term solutions, but i think letting mono use its own ARM_FPU_NONE code for now is a sensible enough solution to having it at least be functional | 19:55 |
| sebner | persia: only some hours left until you leave :) | 19:56 |
| persia | directhex, Short-term, I'd agree. Longer-term, if there's a signficant performance difference, it might be worth having a double-build with different versions of the library available. | 19:57 |
| directhex | persia, yes, i think that would be interesting | 19:57 |
| directhex | persia, an alternate mono-jit package i think | 19:58 |
| persia | directhex, I'll trust you on which bit might benefit from optimisation :) | 19:58 |
| directhex | persia, it might require some re-sculpting of debian/rules unless armel-fpu got its own $ARCH, lpia-style | 19:59 |
| cjwatson | I don't expect it to be a separate dpkg architecture | 20:01 |
| cjwatson | we have enough to do bringing one architecture up | 20:02 |
| persia | directhex, It would require sculpting of debian/rules, but I suspect the adjustment would have benefit for both Debian and Ubuntu. | 20:02 |
| persia | directhex, Given where you tend to concentrate your work, if you get something that seems to work, it's probably worth chatting with the Debian armel team about the possible optimisations. | 20:03 |
| directhex | persia, without access to an armel machine for testing, i'm pretty much unable to help | 20:12 |
| directhex | persia, i.e. a buildd or developer machine | 20:13 |
| * NCommander just found his next project | 20:14 | |
| directhex | NCommander, mono-jit-supermegaarmfpu? | 20:14 |
| NCommander | directhex, orig.tar.bz2/orig.tar.lzma | 20:15 |
| NCommander | in dak | 20:15 |
| directhex | NCommander, even better! | 20:15 |
| * directhex is slightly aroused at the thought | 20:15 | |
| NCommander | I figure it I can get Debian to accept them | 20:15 |
| NCommander | THe LP devs must add support | 20:15 |
| * NCommander laughs evilly | 20:15 | |
| Byrnison | I haven't been paying attention... LZMA compressed packages? | 20:16 |
| ajmitch | directhex: funny, I thought that NCommander would be porting mono to nvidia/ati cards | 20:17 |
| NCommander | mono works fine on both | 20:17 |
| ajmitch | I mean using the GPU to accelerate certain things | 20:18 |
| directhex | ajmitch, O RLY? | 20:18 |
| directhex | [jms@durandal ~]$ mono deviceQuery.exe | 20:18 |
| directhex | There are 2 devices supporting CUDA | 20:18 |
| directhex | Device 0: "Tesla C870" | 20:18 |
| ajmitch | interesting | 20:18 |
| ajmitch | and mildly scary | 20:19 |
| cjwatson | NCommander: I thought it was something planned for dak after lenny anyway, TBH | 20:19 |
| cjwatson | NCommander: I'd take it as a favour if you'd ensure that LP gets fair warning if you do it, though; it would be very annoying to be unable to sync lots of packages for a month | 20:19 |
| directhex | ajmitch, hell to code, and CUDA.NET.dll is non-free | 20:19 |
| NCommander | cjwatson, of course, I'll make sure the devs get fair warning before any code lands on ftp-master-production | 20:20 |
| directhex | ajmitch, it's a direct language binding, e.g. only supports native CUDA data types like "float4", not normal CLI ones like Double | 20:21 |
| directhex | and once you start using array pointers to point to c# arrays, you've already lost | 20:23 |
| === snova is now known as Byrnison | ||
| doko | directhex, NCommander: if you rebuild packages for the mono transition, please don't upload openoffice.org. still building on armel, and there's at least on other change to make with the next upload | 20:30 |
| directhex | doko, i don't intend to molest any non-pkg-cli-* apps directly - other than offer patches | 20:31 |
| directhex | doko, did calc CC you the OOo patch i sent him? | 20:32 |
| doko | directhex: no, calc is currently preparing 3.0, please could you send it to me as well? | 20:33 |
| directhex | doko@debian ? | 20:33 |
| doko | directhex: doko@ubuntu.com | 20:33 |
| directhex | senyt | 20:40 |
| kees | hrm, what's this Pulse Null Output junk? | 20:46 |
| persia | kees, Maybe you want to use pulse, but you don't want to make any noise. | 20:57 |
| slangasek | yes, a frequent goal of mine is to consume CPU cycles without generating output | 20:58 |
| kees | slangasek: I always run "cat /dev/urandom > /dev/null" for each CPU I have. | 20:59 |
| persia | slangasek, Maybe you have an app that won't shut up, and you want to redirect it's output? Maybe you're testing something, and want to avoid interactions of a given output plugin? | 21:00 |
| NCommander | Question, IF I'm converting a friend to Ubuntu for the first time, should I give him Hardy or Intrepid? | 21:02 |
| directhex | intrepid imho | 21:03 |
| slangasek | persia: I am immune to your logic | 21:03 |
| persia | slangasek, We've known that for a while :) | 21:04 |
| cody-somerville | lol | 21:04 |
| * NCommander packs up | 21:05 | |
| mok0 | Anyone with a bit of time on their hands, please take a look at Bug #299489 , there is a patch to fix an annoying bug in libupsclient1-dev | 21:12 |
| ubottu | Launchpad bug 299489 in nut "[jaunty] /usr/lib/libupsclient1.so is a dangling link" [Medium,Confirmed] https://launchpad.net/bugs/299489 | 21:12 |
| NCommander | mok0, let me see | 21:19 |
| NCommander | oh, needs a core dev | 21:19 |
| mok0 | yes | 21:20 |
| * NCommander pokes LP | 21:49 | |
| NCommander | I think I broke it | 21:49 |
| directhex | NCommander, consider it just punishment for no debian PPAs | 21:52 |
| * NCommander also learned his laptop knows what a DVD-RAM is O_O; | 21:52 | |
| directhex | NCommander, panasonic drive? | 21:56 |
| NCommander | Nope | 21:56 |
| directhex | hm, odd then. i thought it was mostly panasonic drives w/ dvd-ram support | 21:56 |
| ScottK | mok0: It looks like the Debian maintainer is trying to be responsive. Could you work with him to try and get a complete fix in Debian and then we sync the pacakge? | 22:04 |
| ScottK | doko: Are you going to update python 3.0 in Intrepid too (please)? | 22:06 |
| mok0 | ScottK: that was fast | 22:07 |
| ScottK | mok0: Is that a yes then? | 22:08 |
| mok0 | ScottK: of course | 22:09 |
| mok0 | ScottK: trying to find his reply | 22:09 |
| ScottK | mok0: I don't think he replied to your last comment, just the one from two days ago. | 22:10 |
| mok0 | Ah, ok | 22:10 |
| ScottK | If the Debian maintainer is active in the bug, then I think it's good to try and work with them. | 22:10 |
| mok0 | Absolutely | 22:10 |
| ScottK | Generally I think it's good, but particularly in such a case. | 22:10 |
| doko | ScottK: not before the final | 22:11 |
| ScottK | doko: OK. I can understand that. Is that expected soon? | 22:11 |
| mok0 | ScottK: Actually, I don't think I got all the Ubuntu changes merged in. I don't know what happened, I took the grab-merge output | 22:11 |
| doko | Dec 3 | 22:12 |
| ScottK | Not long at all. | 22:12 |
| ScottK | mok0: Sounds like a good time to sort it all out with Debian and see how much they'll take. | 22:12 |
| mok0 | ScottK: will you remove the bug from the sponsor queue, then? | 22:15 |
| ScottK | Sure thing | 22:15 |
| ScottK | mok0: Done. | 22:16 |
| james_w | when a package needs specific permissions on a owner/permissions on a package it will chown/chmod it in postinst. If that directory is in /var/run then Ubuntu will move that code to the init script. | 22:22 |
| james_w | the correct way to change the owner/permissions is to guard the call with a call to dpkg-statoverride | 22:22 |
| james_w | however, I haven't seen many packages do that in code in the init script. | 22:23 |
| james_w | Is this a bug that we are introducing to these packages, or is it not a problem as dpkg-statoverride doesn't work on a tmpfs? | 22:23 |
| mok0 | james_w: good question | 22:27 |
| soren | james_w: One could easily make the argument that we should be respecting statoverrides in init scripts. | 22:54 |
| soren | james_w: Regardless of whether the created files/directories are on tmpfs. | 22:58 |
| Philip5 | hi! is there a dh-command for bumping the changelog with a new timestamp etc in a existing debian/files tree like the autogenerated one you get in the changelog the first time you run dh_make? | 23:37 |
| TheMuso | Philip5: dch -e | 23:39 |
| TheMuso | Philip5: which is in devscripts | 23:39 |
| TheMuso | Philip5: or dch -i depending on whether you want a new changelog entry, or update the timestamp for the top most entry. | 23:39 |
| TheMuso | Philip5: man dch for more info. | 23:39 |
| Philip5 | nice... thanks | 23:39 |
| Philip5 | it was the -i parameter and the command it self i was looking for | 23:41 |
| Philip5 | thanks a bunch | 23:41 |
| TheMuso | Philip5: You're welcome. | 23:41 |
| savvas | Now that Philip5 mentioned it, do you happen to know a script that creates just the timestamp line similar to the changelog one, e.g. -- Name Surname <email> date/time | 23:47 |
| TheMuso | savvas: Creates, or edits? | 23:49 |
| savvas | creates | 23:50 |
| TheMuso | Dch may have something, but if it does, I don't know about it yet. | 23:50 |
| savvas | I just wanted to add a timestamp in debian/README.Debian file :) | 23:50 |
| TheMuso | savvas: devscripts may have something, the package devscripts that is. | 23:50 |
| savvas | I'll take a look | 23:51 |
| james_w | savvas: dch can create other files | 23:51 |
| james_w | savvas: but I'm not sure it does README.Debian, as that is normally considered to be for all versions, as opposed to NEWS.Debian | 23:52 |
| savvas | wait I think I'm on to something, debchange --news | 23:53 |
| james_w | dch -c README.Debian as well | 23:54 |
| savvas | by the way, is it recommended to use debian/README.Debian in Ubuntu packages or debian/README.Source ? | 23:54 |
| RAOF | savvas: Those two files serve different purposes. | 23:56 |
| RAOF | savvas: README.Debian is things that (advanced) end-users may want to know about the package; README.Source is things that packagers should know when messing with the package. | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!