| pitti | Good morning | 06:05 |
|---|---|---|
| Quintasan | Good morning. | 06:18 |
| dholbach | good morning | 07:53 |
| === smb` is now known as smb | ||
| scientes | gm | 08:40 |
| === doko_ is now known as doko | ||
| === bambee is now known as rperier | ||
| zequence | diwic: Hi. I was just giving PA 3 a go. Seems to work a lot nicer with jack. There are a few odd things that I'm wondering about. PA is able to use multiple interfaces at once, correct? As I start jack, I need to set PA to use jack of course. Let's say rhythmbox is using PA all along this process. Then, when I stop jack, and start it again, PA is now not using jack anymore, but Rhythmbox is. | 09:16 |
| zequence | diwic: I'm thinking it might make good sense to have the module set PA to use jack automatically. Optimally, one should be able to set this in user settings somehow. But, initially, I think that's what people would expect to happen. What do you think? | 09:18 |
| diwic | zequence, module-jackdbus-detect should do this | 09:18 |
| === henrix_ is now known as henrix | ||
| zequence | diwic: the sink and source are created, but PA is not set to use the jack sink and source. I do that manually | 09:19 |
| diwic | zequence, but it is possible that streams need to be moved manually in PA from the hardware sink to the JACK sink and back again as you start/stop jack | 09:19 |
| diwic | zequence, right. This is all part of the routing, which currently has a non-scalable solution, pending a better one that is currently implemented...we hope | 09:20 |
| zequence | diwic: will this happen before the release of 13.04? | 09:21 |
| diwic | zequence, no | 09:21 |
| diwic | zequence, 3.0 is what's going to be in 13.04. | 09:22 |
| zequence | Ok, I think I might want to patch the module meanwhile. I'll have a look at that next week (studying for a A+ certificate this week) | 09:23 |
| zequence | ..or see what is possible, and what would be a good thing to do | 09:24 |
| diwic | zequence, ok, patches welcome :-) | 09:24 |
| diwic | zequence, but given that 13.04 is two months from release, there is not much time. | 09:25 |
| diwic | zequence, Feature Freeze is 7th of March | 09:26 |
| zequence | diwic: Yep. Should be ok | 09:27 |
| hrw | ech, FF... I wonder will I get chromebook support in archive to that time | 09:28 |
| zequence | hmm, ok. I should probably do that pretty soon then | 09:28 |
| hrw | zequence: I do wonder when audio in linux will get automatic output switch on hdmi plug in x86 world | 09:30 |
| zequence | hrw: That sounds like something for the pulseaudio people to do :). I'm a developer for Ubuntu Studio, and am mainly concerned with jack and PA interoperabilty. I use hdmi for my monitor. I use a TV as my monitor. I don't want the TV to be my speaker. I have two studio monitors for that | 09:31 |
| zequence | hrw: I suppose one could have a advanced setting toggle for that kind of thing somewhere, given that hdmi can be detected in smart ways | 09:33 |
| hrw | zequence: I gave new netbook for my wife as birthday present. amount of problems with 'hdmi connect, audio on speakers' is arghhh | 09:33 |
| hrw | zequence: and I do not want her to go to PA settings each time to switch default output hdmi<>speakers | 09:34 |
| === Sweetsha1k is now known as Sweetshark | ||
| zequence | hrw: I could see the point in having that as an option, and maybe also as a default. Probably the more technical person, who might not want things to always happen automatically is also the kind that more easily would be able to change that in somwhere in settings | 09:53 |
| === henrix_ is now known as henrix | ||
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| mterry | pitti, mind if I swap patch pilots days with you? I have this Thursday, but would like to have your slot next Monday | 10:33 |
| pitti | mterry: no problem | 10:33 |
| mterry | pitti, thanks | 10:34 |
| pitti | mterry: I updated my calendar | 10:34 |
| mterry | k | 10:34 |
| === yofel_ is now known as yofel | ||
| caribou | I have a total nOObie's python question: should I concentrate learning directly on Python 3 or python 2.7 ? | 10:48 |
| pitti | caribou: I'd recommend py3 | 10:50 |
| pitti | caribou: you are going to get a much cleaner understanding of e. g. byte arrays vs. strings, and py 3 has some nicer API in some places | 10:50 |
| caribou | pitti: that's what I thought | 10:51 |
| pitti | caribou: but it depends a bit, e. g. the juju world is still firmly py2 | 10:51 |
| xnox | caribou: this is not really the right channel for such questions. #ubuntu-app-devel is better for questions about developing on ubuntu or targetting ubuntu. This channel is about developing the core ubuntu operating system. But yes, I'd also recommend python3 directly, and if need be its easy to write python3 which is also happens to be valid python 2.7. | 10:51 |
| pitti | the desktop world is rapidly moving towards 3 | 10:51 |
| caribou | xnox: understood, but I only needed a quick opinion and I hate joining a channel just for a question. Looks like I'll add #ubuntu-app-devel to my list | 10:52 |
| xnox | ;_ | 10:52 |
| xnox | ;) | 10:52 |
| caribou | xnox: thanks for the info | 10:52 |
| caribou | xnox: tbh, the code I'm hacking at is apport which is py3 so I knew that pitti was hanging around here ;-) | 10:55 |
| alkisg | Hi, with the Precise 12.04.2 CD having the quantal-lts kernel, samba is unusable due to this bug: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1016895 | 10:56 |
| ubottu | Ubuntu bug 1016895 in samba (Ubuntu Precise) "smbd crashed with SIGABRT in dump_core()/setgroups being passed a -1 group is causing crashes." [High,Triaged] | 10:56 |
| xnox | caribou: if you are hacking on apport, all irc channels policy is waved and you can ask us anything on any channel! | 10:56 |
| alkisg | That's fix-released in quantal, but for some reason the planned backport never happened | 10:56 |
| alkisg | Can I do something to help in SRU'ing it? | 10:56 |
| caribou | xnox: :D | 10:57 |
| pitti | caribou: FYI, apport still needs to run with 2.7 as well, so please don't use py3 only API (or fallbacks, the code has a few already) | 10:57 |
| caribou | pitti: don't think I'm smart enough on python to do any of those, I'll only use very basic things but I'll keep an eye on it | 10:57 |
| xnox | caribou: if sys.version < '3': | 10:59 |
| xnox | easy | 10:59 |
| caribou | xnox: /usr/bin/kernel_crashdump already invokes /usr/bin/python3 | 11:00 |
| xnox | alkisg: you could update the bug description as per https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template | 11:00 |
| caribou | xnox: but I'll take a note of that | 11:00 |
| alkisg | xnox: is that enough? I saw jamespage was working on it, but I don't know why the work stopped... | 11:00 |
| xnox | alkisg: what do you mean " by enough"? SRU template with a testcase is the next step one should complete, then anyone can upload it into -proposed unapproved queue, then SRU team will review it, then publishing will happen, then verification, then released into -updates | 11:06 |
| alkisg | xnox: maybe I need to prepare a debdiff or a branch + file a merge request too... | 11:06 |
| alkisg | There's an upstream commit link, but not a fresh debdiff afaik | 11:07 |
| xnox | alkisg: start with an SRU template. The exact fix/patch is known such that a debdiff is easy to generate. | 11:07 |
| alkisg | Thanks, doing so... | 11:07 |
| xnox | alkisg: and nobody can/will sponsor a debdiff without SRU template filled. | 11:07 |
| alkisg | Sure, I was just asking if someone was working on it and if it was blocked for some reason, so any time I put on writing an SRU template would be in vain... (as were some others in the past)... Thanks, doing the SRU. | 11:08 |
| alkisg | Done | 11:19 |
| hrw | btw - who (except infinity) has power to take packages from NEW? | 11:22 |
| jamespage | alkisg, I'm not working on it but would be happy to sponsor unless xnox wants to | 11:22 |
| xnox | hrw: members of ~ubuntu-archive team | 11:23 |
| xnox | the AA team =) | 11:23 |
| hrw | gracias | 11:23 |
| alkisg | jamespage, xnox: I've done the SRU description, is that enough? | 11:25 |
| jamespage | alkisg, no - I need a merge proposal or debdiff as well for precise | 11:28 |
| jamespage | I need/it needs | 11:29 |
| ogra_ | hrw, see the wikipage for archive administration, there is a schedule with the daily AA | 11:30 |
| hrw | thanks ogra_ | 11:31 |
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| cjwatson | Some of that schedule may even not be mythical | 11:39 |
| alkisg | jamespage: thanks, I'll do that in a while as one of my kids is sick today | 11:39 |
| === amitk is now known as amitk-afk | ||
| === amitk is now known as amitk-afk | ||
| === _salem is now known as salem_ | ||
| melodie | hello | 12:17 |
| melodie | I am seeking some information about how Casper operates, and about the packages which come along for it to fulfill it's task. can someone help me ? | 12:17 |
| cjwatson | melodie: depends on what exactly you need to know | 12:23 |
| cjwatson | it's just a fairly complex initramfs hook | 12:24 |
| melodie | hi cjwatson | 12:37 |
| melodie | I am searching for what makes it trigger autologin in a Live CD, for a spin I try to do and which don't land on the desktop, but on the lightdm login scree ? | 12:38 |
| melodie | s/scree/screen/ | 12:38 |
| cjwatson | scripts/casper-bottom/15autologin | 12:39 |
| melodie | I look, thank you ! | 12:39 |
| cjwatson | It has explicit support for various DMs so it's possible it needs some tweaking | 12:39 |
| melodie | so ? | 12:39 |
| melodie | I am going to look in the last version of my spin and will compare with what I find in Lubuntu/Xubuntu in vbox | 12:40 |
| melodie | cjwatson, the support for various DE ok, but see: when I stripped off some dev packages, and some ibus packages from Lubuntu, in a customized version, after there was no more autologin, when I put it back, autologin was back. But in the other version I try to do, it only brought the choice for languages at the start of the live, when selecting "try without installing". so I also wonder if there are not some packages which should be depend | 12:43 |
| melodie | s to casper, or even to a higher level of core packages ? | 12:43 |
| cjwatson | Impossible to tell given only that information. Trace it, find out exactly what's going wrong, and then think about a solution | 12:44 |
| cjwatson | You can use break=casper-bottom as a boot parameter and then start running scripts in /scripts/casper-bottom/ by hand (perhaps under sh -x) | 12:44 |
| melodie | that sounds interesting. | 12:45 |
| cjwatson | Or boot with 'debug' and you should get a giant log in /run/initramfs/initramfs.debug | 12:45 |
| melodie | ok, I look at the casper-bottom scripts first, then I will try the debug method with large debug log. | 12:46 |
| melodie | if I have an idea what I will be looking for in there | 12:46 |
| cjwatson | Well, just look for where the autologin script starts and trace through its execution against the code | 12:46 |
| melodie | ok, I will do that | 12:47 |
| === francisco is now known as Guest5868 | ||
| melodie | cjwatson, thank you | 12:49 |
| melodie | I have one more question | 12:58 |
| melodie | I have added a script which I was provided, to add 2 icons/launchers on the desktop ("home" and "trash")on the live, and that works, but I don't know how to make the 2 launchers follow at post-install ? any idea ? | 12:59 |
| cjwatson | melodie: see the ubiquity-hooks/ directory in the casper source packag | 13:00 |
| cjwatson | e | 13:00 |
| melodie | cjwatson, ok I will. thank you very much! | 13:00 |
| doko | stgraber, #1123588 looks like an issue in upstart | 13:13 |
| xnox | doko: loads of nih_* memory commands allocate new, or realloc memory. and we use malloc attribute all over the place. | 13:25 |
| === amitk-afk is now known as amitk | ||
| doko | xnox, looks like the real issue is that at least job_new caches the pointer, and expects that the latter assignments will have some effect | 14:04 |
| === Ursinha is now known as Ursinha-afk | ||
| jamespage | Laney, around? I have a question re backports (and Jenkins) | 14:21 |
| Laney | yes | 14:21 |
| Laney | what's up holmes | 14:21 |
| jamespage | Laney, do backports build against backports? I'd like to start doing backports of Jenkins but its pretty much always Jenkins + Associated Jenkins Deps that need updating | 14:24 |
| Laney | jamespage: there's a bug there :( | 14:25 |
| Laney | https://bugs.launchpad.net/launchpad/+bug/888665 | 14:25 |
| ubottu | Ubuntu bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [High,Triaged] | 14:25 |
| Laney | see the assignee? give him crap about it :-) | 14:26 |
| jamespage | Laney, ah - I see this has been rolling on for some time.... | 14:27 |
| jamespage | Laney, thanks for the backport of mininet yesterday btw.... | 14:29 |
| === Ursinha-afk is now known as Ursinha | ||
| Laney | np! hope it's useful | 14:31 |
| Quintasan | Laney: Did maliit make it out of NEW? | 14:32 |
| Laney | Quintasan: yeah | 14:33 |
| Quintasan | Laney: Splendid. Now I can legitmately whine about Plasma Active 3 being not done \o/ | 14:33 |
| Laney | no whining, just doing | 14:33 |
| Laney | :P | 14:34 |
| Quintasan | shadeslayer: do plasma active 3 | 14:34 |
| shadeslayer | I already did | 14:34 |
| shadeslayer | didn't I | 14:34 |
| Quintasan | Kidding me? | 14:34 |
| shadeslayer | it's in raring! | 14:34 |
| Quintasan | \o/ | 14:35 |
| shadeslayer | !info plasma-mobile raring | 14:35 |
| Quintasan | Laney: Now I have nothing to do | 14:35 |
| ubottu | plasma-mobile (source: plasma-mobile): transitional package for plasma-active. In component universe, is extra. Version 2.0+git2012071701-0ubuntu1 (raring), package size 3 kB, installed size 41 kB | 14:35 |
| Laney | sure you do | 14:35 |
| shadeslayer | though last I checked it was stuck in proposed | 14:35 |
| shadeslayer | no idea why | 14:35 |
| Laney | im-config integration | 14:35 |
| Laney | build it against qt5 ;-) | 14:35 |
| shadeslayer | Quintasan: help us automate Kubuntu QA | 14:35 |
| shadeslayer | :P | 14:35 |
| Quintasan | Laney: im-config should be there | 14:35 |
| Quintasan | Laney: That xinput stuff in debian/ was there to make it working | 14:35 |
| Laney | only im-switch is | 14:35 |
| Quintasan | oh | 14:36 |
| Quintasan | that behaves differently? | 14:36 |
| Laney | yeah apparently you patch im-config itself for new IMs | 14:36 |
| Laney | seems like a pain to me | 14:36 |
| Quintasan | well, it IS a pain | 14:36 |
| Quintasan | I'll get to it | 14:36 |
| Quintasan | shadeslayer: It involves Python, I don't want it :P | 14:36 |
| shadeslayer | haha | 14:37 |
| Laney | Qt5 would be a good thing to do though, so we can build the nemo keyboard | 14:37 |
| Quintasan | Laney: We do have Qt5 packages somewhere don't we? I remember mikhas kind of implying it should work | 14:38 |
| xnox | some qt5 is stuck in -proposed as far as i remember | 14:39 |
| Quintasan | Laney: Well, if that's the case I'll get to it after I'm done with input methods in Kubuntu | 14:41 |
| Laney | It does build apart from a change to QSKIP: https://gitorious.org/maliit/maliit-framework/merge_requests/239 | 14:41 |
| Laney | I'm not clear what it does to Qt4 applications though as Qt5 contains the input context stuff itself so maliit-inputcontext-qt4 goes away | 14:42 |
| Laney | will need to check if they keep on working / we care if they don't | 14:42 |
| * Quintasan really really needs to learn how to code | 14:47 | |
| RZAFC | can someone help? | 14:56 |
| RZAFC | <RZAFC> I can't compile c program in gcc | 14:58 |
| psusi | see topic | 14:59 |
| xnox | RZAFC: this channel is for development of the ubuntu operating system. for programming help on ubuntu see #ubuntu-app-devel | 15:07 |
| * xnox wants a factoroid for this. | 15:08 | |
| === rsalveti_ is now known as rsalveti | ||
| === Ursinha_ is now known as Ursinha | ||
| RZAFC | ok | 15:09 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === baba is now known as hack | ||
| aPpYe | I am building a custom system based on the mini.iso and am using the various *buntu-desktop packages as a reference. I am wondering why anacron is listed as a dependency... Do thhe update managers use cron/anacron to schedule daily updates? | 15:58 |
| mdeslaur | pitti: could pygtk need to be adjusted for the new glib behaviour described here? http://blogs.gnome.org/desrt/2012/11/05/a-warning-about-glib/ | 16:39 |
| mdeslaur | pitti: I'm hitting the warning when running meld on raring: bug 1103170 | 16:39 |
| ubottu | bug 1103170 in meld (Ubuntu) "meld crashed with TypeError in <lambda>(): <HistoryFileEntry object at 0x1e58960 (HistoryFileEntry at 0x1f08540)>: unknown signal name: changed" [Medium,Confirmed] https://launchpad.net/bugs/1103170 | 16:39 |
| pitti | ugh, pygtk | 16:39 |
| mdeslaur | hehe :) | 16:39 |
| pitti | mdeslaur: I thought on the last hackfest someone mentioned that they ported it to GI and gtk3 | 16:40 |
| mdeslaur | pitti: I see some other things also, like dia: bug 1102960 | 16:40 |
| ubottu | bug 1102960 in dia (Ubuntu) "dia crashes on startup" [Undecided,Confirmed] https://launchpad.net/bugs/1102960 | 16:40 |
| pitti | mdeslaur: too bad, meld git head is still on pygtk | 16:42 |
| mdeslaur | :( | 16:42 |
| pitti | mdeslaur: I guess it's possible, yes; no idea how much effort it will be, I'm not familiar with the pygtk code; but for pygobject it was half a day's work | 16:42 |
| === hack is now known as megha | ||
| alexbligh1 | If package A depends on package B, and both packages are upgraded through the same apt-get line, is it possible to arrange matters so the ordering of the start/stops of A and B guaraateed? (preferably stop A, stop B, start B, start A) | 16:58 |
| xnox | stop A, stop B, start B, start A - usually happens when package B depends on A. | 17:00 |
| xnox | alexbligh1: you could in package A postinst to do restart B, before restart A. | 17:01 |
| ogra_ | and if your upstart jobs are sane :) | 17:01 |
| alexbligh1 | So if A depends on B, and just B is upgraded, then that will stop and start A (whilst B is upgraded) too? | 17:01 |
| Laney | you'll want a versioned depends if you want that configuration order | 17:02 |
| === deryck is now known as deryck[lunch] | ||
| alexbligh1 | Can't really do that as I'd have to change package A whenever I rebuild B, which is pretty much all the time. | 17:04 |
| xnox | alexbligh1: package B can also have a postinst snippet to restart A | 17:04 |
| infinity | Sounds to me like B just wants to stop A before itself and start A after itself. This can easily be confined to B's maintainer scripts. | 17:05 |
| xnox | alexbligh1: or job A can have "stop on stopped B" and "start on started B", and then whenever B is stopped/started you will get the behaviour you are describing. | 17:05 |
| xnox | alexbligh1: and job B's pre-stop also needs stop A. | 17:06 |
| infinity | Or if, indeed, they depend on each other being started/stopped even not during upgrade scenarios, xnox's suggestion about upstart dependencies is sane. | 17:06 |
| alexbligh1 | The issue I have is this: I have an OCFS2 package and an openiscsi package. Both very similar to ubuntu mainline, but fortunately (or not) we need a couple of local patches or a version that isn't upstream. Neither depends on eachother right now. When I upgrade them, iscsi's prerm calls the init script (not upstart, sadly) to stop it, and it disconnects iscsi, despite OCFS2 using it for heartbeat. OCFS2 then fences the box a | 17:06 |
| alexbligh1 | nd does a hard restart. | 17:06 |
| alexbligh1 | Obviously this behaviour is undesirable. | 17:06 |
| alexbligh1 | I am trying to think of a general fix for this (i.e. one I can get upstream) | 17:06 |
| alexbligh1 | Currently AFAICT iscsi is unupgradeable in various situations - the above being an obvious one. | 17:07 |
| xnox | iscsi prerm call should not stop hard-drives | 17:07 |
| alexbligh1 | iscsi prerm removes kernel modules! | 17:07 |
| xnox | see for example mdadm package which never stops raid arrays on upgrade. | 17:07 |
| alexbligh1 | it also closes the initiator. | 17:07 |
| xnox | /o\ | 17:08 |
| xnox | that's like so totally not safe. | 17:08 |
| alexbligh1 | This seems to be because icssi's initiator works a bit like nbd, ad the fd starts in user space to do the initiation, then gets passed to the kernel. | 17:08 |
| alexbligh1 | We have tried the obvious fixes (like not doing that) but the world gets confused. | 17:08 |
| alexbligh1 | I have no idea how iscsi even runs with root on iscsi. | 17:08 |
| alexbligh1 | xnox, indeed it's not. I think hard reboot without sync (OCFS2 fence action) is about the most exciting consequence. | 17:09 |
| xnox | and the packages in ubuntu-archive do this? | 17:10 |
| alexbligh1 | I filed LP #1123192, but I am not sure how to fix it | 17:10 |
| ubottu | Launchpad bug 1123192 in open-iscsi (Ubuntu) "open-iscsi removes modules on stop but should not" [Undecided,New] https://launchpad.net/bugs/1123192 | 17:10 |
| alexbligh1 | Yes they do | 17:10 |
| xnox | assigned to myself | 17:10 |
| alexbligh1 | I only noticed the modprobe when I first filed it. But you can see stop() calls stopalltargets() | 17:10 |
| xnox | I will ponder about it, over a cup of green tea =) | 17:10 |
| alexbligh1 | xnox, much appreciated. We are pulling our hair out a bit. And I haven't got much left. | 17:11 |
| infinity | Those two 'modprobe -r' lines should be no-ops if the module is in use (ie: if root is on iscsi), surely? | 17:11 |
| alexbligh1 | infinity, indeed. Those two cause us (and probably only us) problems because we manipulate /proc/scsi/scsi ourselves. It's the 'stop all targets' thing that is the real problem. | 17:12 |
| alexbligh1 | stoptargets() { | 17:12 |
| alexbligh1 | log_daemon_msg "Disconnecting iSCSI targets" | 17:12 |
| alexbligh1 | sync | 17:13 |
| alexbligh1 | # only logout if daemon is running, iscsiadm hangs otherwise | 17:13 |
| alexbligh1 | if pidofproc -p $PIDFILE $DAEMON > /dev/null; then | 17:13 |
| alexbligh1 | $ADM -m node --logoutall=all > /dev/null | 17:13 |
| alexbligh1 | fi | 17:13 |
| alexbligh1 | log_end_msg 0 | 17:13 |
| alexbligh1 | } | 17:13 |
| alexbligh1 | So the line starting $ADM logs out targets other than the targets that were logged in with the conf file. | 17:13 |
| alexbligh1 | IE everything | 17:13 |
| xnox | !pastebin | 17:13 |
| ubottu | For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. | 17:13 |
| alexbligh1 | Which it seems to have to do, in order to stop the daemon | 17:13 |
| alexbligh1 | xnox, yeah sorry - confusion with internal IM | 17:14 |
| xnox | alexbligh1: also there is handy pastebinit command line tool which can paste from command line e.g. $ pastebinit mylog.txt or $ run-command | pastebinit | 17:14 |
| alexbligh1 | xnox, ty. I know. I just forgot different etiquitte on 3 different IM systems. | 17:16 |
| alexbligh1 | xnox, part of the issue here is that OCFS2 heartbeat does not use an FS mounted device. It just finds what device it's on, then O_DIRECT opens the block device, and carries on writing to it. This seems to die when iscisd gets restarted. At the least it needs a cluster stop and cluster start, but ocfs2 has no obvious way of knowing about iscsid. | 17:19 |
| infinity | lool: It's somewhat pointless to have an ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) wrapping your CC setting, if you're setting to $(DEB_HOST_GNU_TYPE)-gcc | 17:30 |
| infinity | lool: Since that will work just as well in native builds, you could replace five lines of vague confusion with just one export CC. | 17:31 |
| === Quintasan_ is now known as Quintasan | ||
| cjwatson | infinity: I prefer the ifneq myself since it avoids confusion if you later have to add in e.g. $(DEB_HOST_GNU_TYPE)-ar | 17:32 |
| infinity | cjwatson: Which should also work just as well in either case, no? But, to each their own. | 17:33 |
| cjwatson | No, i686-linux-gnu-ar doesn't exist here | 17:34 |
| infinity | Oh, except that that's $(DEB_HOST_GNU_TYPE)-gcc-ar-4.7 here. What a pleasant path construct. | 17:34 |
| cjwatson | And I think -gcc-ar-X.Y is kind of internal - gcc-ar-4.7(1) indicates that that's a wrapper adding --plugin | 17:34 |
| === henrix is now known as henrix_ | ||
| infinity | It could be considered a bit of a misfeature/bug if we're not providing the same paths for native builds as we do for cross. | 17:36 |
| infinity | GCC does it, surely binutils can too. | 17:36 |
| === henrix_ is now known as henrix | ||
| cjwatson | Maybe. It also kind of depends on whether you prefer uglifying debian/rules or uglifying build logs. | 17:37 |
| infinity | cjwatson: Perhaps, yeah. I like my build logs matching between native and cross, easier to compare. But I can see the opposite argument. | 17:38 |
| infinity | cjwatson: Then again, I maintain something with eight billion character compiler calls, a few more doesn't really make it worse. | 17:38 |
| * xnox remembers that at one point calling $(DEB_HOST_GNU_TYPE)-gcc was causing it to start cross-compiling for native arch. glad it's ok to use that directely now. but so far, yeah I have been exporting CC in ifneq as well. | 17:47 | |
| === imbrando1 is now known as imbrandon | ||
| wookey | infinity: It would make sense if we put in more native fully-qualified names. so that you could just use <arch>-command (at least for binutils and pkg-config stuff). | 18:16 |
| wookey | Can we do this generically with some kind of trap? because <BUILD_ARCH>-command should always map to command | 18:17 |
| === zequence_ is now known as zequence | ||
| wookey | rather than putting in a thausand symlinks | 18:18 |
| wookey | And we should think about things like when we recommend ifeq (BUILD, HOST) blah, vs just making arch explicit always. | 18:19 |
| wookey | Packagers need 'suggested standard proactice' for this stuff | 18:19 |
| * xnox somehow thinks that cdbs & dh should as if almost export CC when ifneq (BUILD, HOST) | 18:20 | |
| xnox | that would fix so many packages out of the box. | 18:20 |
| wookey | it would. We actually need a proper solution to setting CC that covers llvm as well | 18:21 |
| wookey | currently it a mess | 18:21 |
| infinity | xnox: But there's no x86_64-linux-gnu-cc, only x86_64-linux-gnu-gcc, so having debhelper cleverly rewrite CC to $(DEB_HOST_ARCH)-$(CC) wouldn't work as expected. | 18:21 |
| wookey | with way too much hard-coding for no good reason | 18:21 |
| wookey | because that's currently to only way to make it work | 18:22 |
| wookey | the | 18:22 |
| infinity | If we had x86_64-linux-gnu-cc, that would solve the llvm and cross use-cases together. | 18:22 |
| infinity | Since cc and HOST-cc should be alternatives, in that ideal world. | 18:22 |
| xnox | infinity: if dh already cleverly passes correct --build & --host when cross-compiling, it can as well figure out & export a cross-CC as well ;-) | 18:22 |
| wookey | infinity: right - something along those lines | 18:23 |
| infinity | xnox: See above, re: clang. If it's figuring it out for you, it's also (in the currently world), forcing you to use gcc. | 18:23 |
| xnox | ok. i see what you mean now. | 18:23 |
| infinity | Not that I mind forcing GCC right now, clang's not really all that useful on more than one and a half arches, but still. If you're going to do it, do it right. | 18:23 |
| wookey | exactly - and more clang use is obviously headed our way, so to ignore it at this stage would be fgoolish | 18:24 |
| infinity | It would definitely be great if I could just define CC at the top of my rules (or leave it undefined, which uses the make default of "cc"), and let debhelper DTRT, though. | 18:25 |
| infinity | So, CC=gcc-4.6 or CC=clang or CC=cc would all Just Work for native and cross. | 18:26 |
| wookey | A log of things have invented cc_for_build to mess that up. We'd probably have to fix those more generically too. | 18:27 |
| wookey | lot | 18:27 |
| infinity | cc_for_build is BUILD_ARCH, not HOST_ARCH, but yes, that needs dealing with. | 18:27 |
| infinity | Still something DH could probably cleverly divine on its own. | 18:28 |
| infinity | (Then again, --host/--build with autotools, combined with $(CC) being set to a generic, is MEANT to DTRT out of the box, regardless. Sadly, this isn't often the case when people fight against autotools because they think they know better) | 18:29 |
| wookey | well DH can easily set BUILD, HOST and CC correctly, but it doesn;t know what the package has called BUILD-CC-when-it-differs-from-cc | 18:29 |
| infinity | wookey: Know, but we could export/set a few of the more common ones, perhaps. | 18:30 |
| wookey | exactly. there is quite a lot of historical bodging to undo to make this actually nice | 18:30 |
| wookey | but I'd like to try :-) | 18:30 |
| * infinity wonders how his fingers turned "No" into "Know". | 18:30 | |
| infinity | Cleary a sign that I shouldn't be on IRC on a holiday. | 18:31 |
| === deryck[lunch] is now known as deryck | ||
| zyga | bryce: ping | 18:33 |
| zyga | bryce: I still have my X crashed under gdb | 18:33 |
| zyga | bryce: if you want some data to https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1127497/ | 18:33 |
| ubottu | Ubuntu bug 1127497 in xserver-xorg-video-intel (Ubuntu) "Xorg crashes when exiting steam" [High,New] | 18:33 |
| zyga | bryce: now is the time to tell me | 18:33 |
| wookey | If autotools and cmake just defined CC (=HOST-CC) and BUILD-CC then everyone could use that and life would be great. | 18:34 |
| slangasek | zyga: fwiw, it's a public holiday in the US today so I don't know that bryce is around | 18:34 |
| zyga | wookey: hey, long time no see | 18:34 |
| zyga | ah, right, boo | 18:34 |
| wookey | hi there < in voice of eddie the shipboard computer> | 18:35 |
| === odifis is now known as oDiafanos | ||
| === francisco is now known as Guest44847 | ||
| === yofel_ is now known as yofel | ||
| melodie | hi | 19:53 |
| temporary_ | hi, i think i found some files that do not match their md5 or sha checksums on http://releases.ubuntu.com/ does anyone here know what to do about it? | 20:16 |
| infinity | temporary_: Example(s)? | 20:19 |
| temporary_ | http://releases.ubuntu.com/12.04.2/wubi.exe appears to not match it's checksums | 20:20 |
| temporary_ | they sha1sum i see is 79d2efd6992d969e4790b088b782c0173281639c | 20:21 |
| temporary_ | but it should be 40b3aac9a6e0464d7a9724f93b28515771e6c43a | 20:21 |
| temporary_ | the other checksums don't seem to match up either | 20:22 |
| infinity | Yeahp, looks broken on the master mirror too. Lovely. | 20:22 |
| infinity | cjwatson: You oopsed the publishing of 12.04.2, wubi.exe got the wrong sums. | 20:23 |
| infinity | cjwatson: Not sure if that means we have the wrong wubi.exe in simple/precise, or if updating the sums just didn't DTRT for you. | 20:25 |
| temporary_ | so i guess it's just a small mistake? | 20:25 |
| infinity | temporary_: Yeah, it's one of two potential mistakes, we'll sort it out. Thanks for the heads-up. | 20:26 |
| temporary_ | i was wondering if a third party had inserted some malicious code and got all paranoid | 20:26 |
| infinity | temporary_: Paranoia's generally the right response to mismatched hashes. | 20:27 |
| infinity | temporary_: I can confirm that the wubi.exe on the master mirror is 79d2efd6992d969e4790b088b782c0173281639c however. | 20:27 |
| infinity | temporary_: So, no MITM attacks or anything. Just something wrong on our end with the sum versus the file. | 20:28 |
| temporary_ | oh cool, that's good to know | 20:28 |
| temporary_ | i'm sometimes lazy about verifying hashes, so this has been interesting | 20:29 |
| === cmagina is now known as cmagina_away | ||
| === cmagina_away is now known as cmagina | ||
| cjwatson | infinity: I did oops that at one point but I thought I'd fixed it | 20:53 |
| infinity | cjwatson: nusakan disagrees. | 20:54 |
| cjwatson | Ah, I ran checksum-directory and it decided all the timestamps are up to date | 20:54 |
| cjwatson | Or something | 20:54 |
| cjwatson | Possibly my code is too clever for its own good | 20:54 |
| infinity | cjwatson: I'd have just resummed the directory, but given that ancestry of the signed wubi.exe binary is a pain to sort out if you're not the person who put it there, I figured I'd let you sort out if the binary or the sums are wrong. :P | 20:54 |
| cjwatson | I'll double-check but 99% sure it's the sums | 20:55 |
| cjwatson | temporary_: OK, fixed checksum files syncing out now - sorry about that | 20:57 |
| cjwatson | Whether it was the code or the operation of it, it was my fault either way ... | 20:58 |
| cjwatson | Ah | 20:58 |
| cjwatson | The reason it didn't get resummed automatically was that the timestamp of wubi.exe from the build had been preserved | 20:58 |
| infinity | cjwatson: The last time I ran into all that clever code, I was unconvinced that caching the sums was buying us anything except pain. | 20:59 |
| infinity | I mean, it's a great speed optimisation, but it's optimising for (in theory) the non-common path. | 21:00 |
| infinity | And when it breaks, it's confusing. :P | 21:00 |
| cjwatson | It's critical path for release publication and makes a giant difference to the length of said critical path | 21:00 |
| cjwatson | Originally I had no caching and it was awful | 21:00 |
| cjwatson | Also, the code should be much clearer now than the last time you ran into it ... | 21:01 |
| infinity | Hrm, yeah, I guess for the daily->release path, it's critical. | 21:01 |
| cjwatson | Anyway, I've tweaked the process to recommend publishing wubi.exe first, which would have avoided this in practice | 21:01 |
| infinity | cjwatson: Clearer being a matter of perspective, if it's changed languages. ;) | 21:01 |
| cjwatson | This was a case where the implementation language made a big difference - it'd outgrown shell | 21:02 |
| cjwatson | And I'll fix it to honour ctime as well as mtime, which will permanently avoid this problem | 21:02 |
| temporary_ | cjwatson, infinity: ah cool, thanks for update and fixing things so quickly | 21:04 |
| temporary_ | now i don't need to spend all week checking my computer for rootkits :) | 21:04 |
| lool | infinity: That's a good point! I had to think hard now at why it is that we have this in packages, and I guess it is only important for autotools packages as to not trigger cross-compilation mode, but clearly it would be much simpler to always use $triplet-gcc; thanks for the tip | 21:14 |
| infinity | ScottK: pkgkde-symbolshelper seems to really hate qscintilla. | 21:47 |
| infinity | ScottK: I tried feeding the -2 build logs to it, and the result still doesn't build. Silly thing. | 21:47 |
| infinity | ScottK: Oh, I wonder if this is because I fed the Debian -2 build logs at it and then tried the build on Ubuntu. Compiler version mismatch fun. :/ | 21:49 |
| * infinity tries that build on experimental. | 21:49 | |
| chilicuil | NCommander: ping | 21:53 |
| NCommander | chilicuil, pong | 21:54 |
| chilicuil | NCommander: sry to bother you, could you come to #ubuntu-mx just a momment? | 21:54 |
| === salem_ is now known as _salem | ||
| ScottK | infinity: Thanks for looking at it. Agreed. C++ symbols are a PITA. They symbolshelper takes them down from impossible to really annoying. | 22:26 |
| === charles_ is now known as charles | ||
| === highvoltage is now known as hv-onlogged | ||
| === henrix is now known as henrix_ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!