[00:10] bryceh, RoAkSoAx: Although, now that drm's getting USB support it's quite possible that those framebuffer devices *will* get autoprobed and kms'd at some point in the not-too-distant future. [00:15] RoAkSoAx, I recall finding adequate directions via google when I was testing one, but if you feel motivated to setting up a wiki page somewhere linked under wiki.ubuntu.com/X/ that could help other folks [00:16] I'm actually quite surprised to learn that you can do video over USB. I didn't think there'd be sufficient bandwidth. [00:16] bryceh: yeah I got one from forums, but once I get the device and get it working, will provide the wikipage [00:17] soren: neither did I [00:17] soren: http://www.amazon.com/gp/product/B000WTI6CI/ref=s9_simh_gw_p23_d0_i1?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-2&pf_rd_r=15JRYSZV13NJS5PABQ2V&pf_rd_t=101&pf_rd_p=470938631&pf_rd_i=507846 [00:17] Hm... I guess you can actually to 1440x900 (what my laptop has) at 24 bit and 60 hz with just 186 Mbps. [00:17] +error correction and whatnot, of course. [00:19] 1080p is a different story, though. [00:20] soren: this one claims to though: http://www.amazon.com/gp/product/B002F9NSMQ/ref=s9_simh_gw_p23_d0_i2?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-3&pf_rd_r=0GHBCHAEPZ8RHD44KK38&pf_rd_t=101&pf_rd_p=470938811&pf_rd_i=507846 [00:20] 10 fps, 24 bpp, 1920x1080 = 497664000 bps. USB2 is 480 Mbit/s. [00:20] "maximum 2048 x 1152 pixel resolution or 1080p" [00:21] Looks cool. [00:22] I'd be interested to hear how it works out. [00:22] indeed! I'm definitely getting te StarTech one [00:26] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: === dendrobates is now known as dendro-afk === asac_ is now known as asac === dendro-afk is now known as dendrobates === _LibertyZero is now known as LibertyZero [06:56] <\sh> hmm...since when is aptitude "Priority: optional" and not "Priority: important" anymore, is there any way to track ubuntu archive overrides file? [06:56] <\sh> good morning :) [06:57] \sh: since it's not default? [06:59] <\sh> micahg: it was in former releases marked as important...this "change" changed behaviour in one of my important admin packages ;) [07:00] \sh: in Maverick it was no longer the default cli package manager, idk about Priority per se [07:03] <\sh> micahg: I see now, since maverick it changed the priority, therefore debootstrap never installed it anymore by default inside the chroots...hooray for \sh, to never created a maverick chroot ;) [07:03] <\sh> in lucid it was still "Priority: important" [07:03] \sh: right [07:04] <\sh> ok...fixing package ;) [07:06] good morning [08:11] good morning [08:17] <\sh> highvoltage: happy birthday :) [08:18] yeah, happy birthday highvoltage [08:18] salut didrocks, sabdfl [08:18] hey dholbach [08:18] happy birthday highvoltage! [08:19] morning dholbach, how are you? hey didrocks [08:19] and happy birthday jonathan [08:19] sabdfl, great - thanks - how's life over there? :) [08:19] well [08:20] very interesting, in the spy thriller sense [08:20] that sounds interesting [08:20] tell you all about it some time, but this is a big week for my tropical project [08:21] sabdfl, you're not very good at letting people let you go easily :-P === smb` is now known as smb [08:34] Good morning [08:47] <\sh> moins pitti [08:53] pitti, hi, around? [08:54] pitti, I'd like to discuss bug #706603 for a moment [08:54] Launchpad bug 706603 in ruby1.9.1 (Ubuntu) "gem1.9.1 doens't install executables on PATH" [Undecided,New] https://launchpad.net/bugs/706603 [08:58] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: Daviey [08:58] <\sh> zyga: oh again this gem topic...every year the same ;) [09:00] zyga: is there a new approach to this rubygems thing then? [09:00] Dunno why gems are special. Same for eggs and jars and CPAN, really. [09:00] * dholbach hugs Daviey [09:01] zyga: btw, it's actually possible to add to $PATH at least for login shells by dropping a file in /etc/profile.d/ [09:01] zyga: and GUIish ones could just install .desktop files? [09:02] <\sh> persia: well, local eggs are installed in /usr/local which is really a strange behaviour in regards to gems...(dunno for jars or cpan..it's a long time ago that I installed something from CPAN with the cpan shell) [09:02] pitti, I'd like to ask just one question [09:02] pitti, why don't we install pip stuff in /var the same way? [09:02] \sh, Dunno. When I was a RoR developer, everything was in /usr/local :) [09:03] pitti, currently gems are treated "worse" than pip installs are, is there a reason for that? [09:03] zyga: pip? [09:03] pitti, python "gem" manager just deals with eggs [09:03] pitti, it also installs executables [09:03] pitti, into /usr/local [09:04] <\sh> persia: at least puppet works out of the box and that's important ;) and s/RoR/django/ ;) [09:04] pitti, if we treat gem the same way we treat pip then, IMHO, the ruby community will not be annoyed anymore [09:04] \sh, django eggs are in /usr/local, right? [09:05] persia, it depends on how you configure things [09:05] zyga, By default, based on the pip implementation we ship. [09:05] persia, but if you use out-of-the-debian-package-box pip today and use sudo to install them then yes [09:05] persia, if not they go to .local [09:05] persia, same as gems [09:05] The non-sudo case is well documented, which makes it easy to implement :) [09:06] persia, I'm just trying to show that python gets better treatment here and perhaps if we revert our gem stance ruby community will welcome this change [09:06] persia, both pip and gem behave the same way in their upstream versions, we just patch gem to install to odd place when using sudo [09:06] <\sh> persia: when you install django from upstream source, they will be installed under /usr/local/lib/python*/{site,dist}-packages/ , the same goes for every python source installed manually with setup.py [09:07] persia, note that this is not about gem --upgrade-system - this is a separate topic [09:07] right [09:07] I'm asking that we allow gems to behave the same [09:07] or explain why we treat them differently [09:07] zul: so, /usr/local/ seems okay to me, but NB that I didn't really follow the original discussion and thus don't know the arguments against it [09:07] <\sh> zyga: what about third party libs, which are deps of gems, which are also installed by ubuntu/debian dpkg system? [09:08] \sh, what about them? IMHO there is no difference to what pip and gem do in this respect [09:08] <\sh> zyga: there was this gem (something to do with imagemagick) which wanted to not use the system lib installed, but a newer version [09:08] \sh, Hrm? Stuff is either installed by dpkg or gem: what is this hybrid install? [09:08] \sh, pip will install a more recent version in that case [09:08] \sh, I'm pretty sure gem will try to do the same if the package is installable via gem [09:09] I can dpkg install django 1.1 from lucid [09:09] and pip install django 1.2.4 from upstream _on_ lucid [09:09] at the same time [09:09] /usr/local/ is pretty much meant for stuff like that, after all [09:09] that, or /opt/ [09:09] let's just answer one question: [09:10] <\sh> zyga: honestly, I never had the opportunity to install a python lib which has a native lib [09:10] why do we install gems to /var/lib/ ? [09:10] I don't remember the details, but it's worth looking up. [09:10] I seem to recall something along the lines of needing to create directory structures and metadata in /usr/local, which was bad somehow. [09:10] (we should be consistent, either there is a good reason to and we need to do the same for pip and python) [09:10] or there is no good reason anymore so we can make ruby community happy [09:11] The documentation is likely in the relevant debian bugs, or mailing list archives. [09:11] persia, all I could find was that _in the past_ the default install location was not /usr/local but /usr [09:11] Last time I watched the discussion, I didn't have the impression the "ruby community" had a consistent view of an ideal solution. [09:11] so they switched to /var/lib instead of /usr without looking at /usr/local [09:11] Who is "they" in this context? [09:11] AFAIR the debian package maintainer for gems [09:12] <\sh> zyga: did you check your PYTHONPATH when you do that? the last time I had a mess with django installed by dpkg and installed under /usr/local, the same with a local install in ~/.local/lib/python* , because our default pythonpath defaults somehow to the /usr/lib/python* dir and follows all the other directories after that (whysoever) [09:12] \sh, I always use virtualenv when I use pip so it's not really a problem for me [09:12] zyga, And did you ask? I suspect there was a reason for the choice. [09:12] \sh, python path is derived from PATH [09:13] persia, from the thread I found there was just arguments (sane) against /usr and then an announcement of a decision to use /var/lib/ [09:13] persia, I can to talk to the maintainer again but perhaps we can decide this by ourselves and win some PR points :P [09:14] I don't see how it would win PR points to announce a decision that didn't involve key stakeholders. [09:14] Moriwaki-san ought be able to provide a relatively clear answer about the selected location. [09:15] persia, it does, the ruby community discourages anyone to use debian packages for ruby/gems and advises to install from source because our two patches break a lot of ruby world assumptions [09:15] persia, so at least one stakeholder - end users - is considered [09:15] <\sh> zyga: http://www.lucas-nussbaum.net/blog/?p=617 <- that happend with the most active ruby maintainer in debian...it's not a happy environment [09:15] \sh, I know about that [09:15] zyga, It's lots more complicated than you describe. [09:16] <\sh> zyga: and I don't think we should make a step into whatever direction without having debian on our side... [09:16] \sh, that's true [09:17] persia, how is it more complicated? [09:17] lucas, around? [09:17] <\sh> if people want to install gems are on their own...and normally an admin knows what he does..(developers of {java,python,ruby,perl,} apps sometimes not ;)) [09:17] <\sh> insert a "there" between "gems" and "are" [09:17] I've been away for a while, but last I looked, there were multiple disjoint ruby communities, rather than just one, and the majority of interesting discussion on forward use of ruby was inaccessible to those who didn't read Japanese. [09:17] \sh, this discussion is not about that [09:18] <\sh> s/he/he && she/ [09:18] \sh, this discussion is about the default install path of ruby gems once you actually want to use them [09:18] I'd need a lot of convincing to accept anyone claiming to speak on behalf of "the ruby community" [09:18] \sh, and why this path is changed by debian when we are not doing equivalent changes for pip or CPAN [09:18] zyga, Who made the change? Ask them. They have the answer. [09:19] persia, the change was made long time ago by the gem maintainer [09:19] persia, I should talk to him, that's true [09:19] <\sh> zyga: it's about the ruby gem package of debian/ubuntu, which installs ruby binaries under /var/foo...and that's the discussion since ages. Ruby devs are using mostly a more recent gem version which they installed manually from upstream source and not from the debian/ubuntu package...so they have a different default somehow [09:19] By Moriwaki-san? [09:19] persia, but this is still a _ubuntu_ bug on launchpad and I'd like to ask (pitti originally) about his thoughts on this topic [09:20] persia, let me check that - I think it was him [09:20] If it was a long time ago, the maintainer may have changed. It's important to check. [09:21] But I very strongly suspect the answer to why it's different than the other tools exists, either in the documentation surrounding that change, or is available by contacting the person who made the change. [09:21] \sh, it's not about a more recent version, it's about a single patch that debian introduced - if this patch is very important and cannot be dropped then the same decision should apply to python - since it did not perhaps it's possible to revisit this decision and see what the reasons were [09:22] Indeed. We should have consistency when installing stuff with gems, pip, cpan, maven, etc. [09:22] Mind you, we should probably deprecate the use of all of them, but that's a different issue :) [09:22] <\sh> honestly, I wonder which type of users we want to catch with something like that? Admins, Application Developers or plain users of Ubuntu who want just work? [09:22] persia, that's a different story, we should be consistent first [09:23] <\sh> my devs here @work they are installing whatever comes into their mind, thinking that the latest version is the best they can get...without consulting their local sysadmin who needs to deploy, install and configure the machines where the app runs later. [09:23] \sh, For consistency, everyone: the key is that things shouldn't be confusing for all categories. In terms of use/non-use of those tools, that's a different issue (and reaching "Just Works" without them is a lot of work) [09:24] <\sh> and with my admin hat on, I don't like having software on board which doesn't come from the distro vendor [09:24] \sh, IMHO developers - when you use debian/ubuntu version of gems then all the scripts tend to break if you don't change your PATH to include that place, and you only need to do this on two systems so it's annoying [09:25] But let's avoid the discussion as to whether these tools *should* exist,and focus on what they ought do since they do exist. [09:25] right [09:26] okay, so I found this bug report in debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480250 it's about the (very broken) behaviour of installing everything to /usr - the resolution by the maintainer was to change the path to /var/lib (the maintainer then was indeed Moriwaki-san) [09:26] <\sh> I had that discussion with our devs here, regarding mono...they came up with a more recent version of the mono suite which lucid doesn't ship..anyways, I would like to see the gems/pips/cpans/etc. all packaged for debian/ubuntu in the first place...and then devs are coming back to us with bug reports about "the version of ruby-gem-foobar is too old" or "your python-netaddr pkg is outdated, please update it for we have> [09:27] I cannot find any bugs in _debian_ that relate to the request to set the installation path to /usr/local - there is on a launchpad bug about this [09:27] zyga, It appears it was never discussed as a bug then: it may be that it was just done because it seemed like a good idea at the time. [09:28] persia, yes, perhaps - that was some time ago, 2008 [09:30] hey everyone [09:30] Potentially overwriting /usr/bin/foo is exceedingly dangerous. Whether the solution is the right one deserves discussion. [09:31] i've found something that could be a bug (could be a 'feature') involving scrollbars + touchpads [09:31] persia, there is no doubt about no-no for installing anything in /usr - but nobody is asking for that fortunately [09:31] <\sh> persia: think about this behaviour: someone installed source A which installs to /usr/local/ and delivers /usr/local/bin/foobar-binary [09:32] pitti: what's the best thing for me to do with a potential ddebs issue? add a pkg-create-dbgsym task for it? [09:32] <\sh> now someone does gem install ruby-A which is a binding to source A and it needs a newer version of source A. [09:32] pitti: (bug 660360, specifically) [09:32] Launchpad bug 660360 in openafs (Ubuntu) "openafs debug information CRC mismatch" [Undecided,New] https://launchpad.net/bugs/660360 [09:32] <\sh> persia: adhere: this applies to PIP/CPAN/PEAR as well [09:32] broder: yes, and subscribe me [09:32] basically, what happens is that in certain applications (main culprit i'm thinking of is one i wrote myself, in PyGtk) - when you put the cursor on a scrollbar it messes with the touchpad scrolling behaviour [09:32] pitti: cool, thanks [09:32] \sh, And, arguably, maven [09:33] \sh, I'm not familiar with perl that much but I assume cpan stuff ends up in /usr/local, correct? [09:33] pitti, hi, could you please give us some insight into bug 706603? [09:33] Launchpad bug 706603 in ruby1.9.1 (Ubuntu) "gem1.9.1 doens't install executables on PATH" [Undecided,New] https://launchpad.net/bugs/706603 [09:33] so, if the cursor is on the horizontal scrollbar and you use the touchpad to do vertical scrolling, it scrolls *horizontally* [09:33] <\sh> persia: the fun part: /usr/local/ is something where admin can install locally needed software..should a third party package manager (like gem, pip, pear, maven, ant, whatever) install also to /usr/local , or should it install somewhere else [09:33] \sh, So admin-controlled ${INSTALL_TOOL} is dangerous because it overwrites admin-installed /usr/local/bin/foo? I'm not convinced of that. [09:34] <\sh> zyga: as said, the last time I used cpan shell was in 2002...and not on debian [09:34] \sh, Indeed. That's the core of the argument :) [09:34] i.e. it scrolls according to the scrollbar the cursor is on, not the scrolling action that you're performing [09:34] zyga: I already said, /usr/local/ seems fine to me, as it's meant for this kind of local installation; I just haven't heard the argumetns against it [09:34] pitti, oh, I did not see that - thanks [09:35] i'm inclined towards 'bug' categorisation, for two reasons: [09:35] pitti, what would be the required steps to make that change happen (from /var/lib to /usr/lib?) [09:35] <\sh> persia: depending on your admin thinking ;) I would like to see a configurable support of your install directory for all of them...(which gives at least pear a bad taste afaik) [09:35] brendand, I believe that's a feature, intended to support cases where people didn't have HID controls for the W dimension. [09:35] pitti, sorry, /var/lib to /usr/local [09:35] \sh, For gems, I believe there's GEM_INSTALL, but yeah, at least needs consistency and better documentation. [09:36] 1.) If you use the scroll wheel on a mouse then it follows the mouses behaviour, never the scrollbars [09:36] brendand, Ah, if you've a case for it, please file a bug. [09:36] 2.) It doesn't work like that in all applications (Firefox works the 'expected'(?) way) [09:37] <\sh> persia: adding debconf question to the install process of asking: "Where do you want to install your packages?" [09:37] \sh, Makes autoinstall ugly, but I suppose. Still, would need glue scripts to make it just work regardless of install location. === bilalakhtar_ is now known as cdbs [09:38] zyga: technically? I don't know, I have no clue at all about ruby or gems [09:38] zyga: the bug sounds like it'd be a ./configure option kind of switch? [09:38] or perhaps a conf file, I don't know [09:38] It's a change to a variable setting in a patch. [09:38] pitti, technically we just drop the debian patch [09:38] pitti, I'm asking about the policy/steps to take [09:38] \sh: why would an user care? [09:39] pitti, An admin of several developer workstations might care. [09:39] pitti, how do I contact the debian maintainer if necessary [09:39] zyga: I'd send a message to u-devel@, and do it if there is no major (and well-founded :) objection [09:39] pitti, awesome [09:39] <\sh> pitti: you mean "why would a developer care"...I don't think our standard desktop user base uses package managers other then apt/aptitude/dpkg [09:39] pitti, thanks [09:39] zyga: and I'd talk to the Debian developer [09:39] ah, you said that [09:39] zyga, It's more than just dropping the patch: consider migration scenarios: someone is sure to be annoyed if an upgrade breaks their carefully arranged gem behaviour. [09:39] pitti, I'll ask the debian maintainter too [09:39] ok [09:40] \sh: well, but there should IMHO be one official system place (which is pretty much /usr/local) and per-user place (~/.local); otherwise the entire thing will just continue to be an incompatible mess IMHO [09:40] zyga: yes [09:40] persia, well it's partially true but if we just install to /usr/lib then people will not need to change PATH anymore, if they already did all the old gems will still be noticed [09:40] \sh: ok, so why would a developer care? [09:40] lucas, hi [09:40] lucas, can you give me some insight into this? [09:41] wait, reading the backlog [09:41] lucas, why do we install to /var/lib in the first place? [09:41] ok [09:41] zyga, What about folk who are using the /var/lib path? [09:41] persia - turns out i was mistaken about 1 - but not 2 [09:41] ouch, it's huge [09:41] persia - why would Firefox act differently? [09:41] brendand, 2) is just an artifact of the feature being enabled only for some toolkits. [09:41] persia, to use executables they had to change their path first, that will continue to work [09:41] pitti, any chance to upload CUPS today? [09:41] persia, I'm not sure about libraries though [09:41] zyga, That's not universally true. There's lots of ways to start executables. [09:42] <\sh> pitti: they don't care actually..not on their local workstations...they are not sysadmins...but all the actions we do now, gives sysadmins a headache... [09:42] tkamppeter: is it that urgent? ok [09:42] zyga, More importantly, their gem catalog, upgrade status, etc. may be confused if GEM_HOME is randomly changed. [09:42] persia, yes but a lot of existing scripts assume that if you install rake then rake is on your path, you don't patch those scrips to look at /var/lib/gems/ etc - you just drop a PATH= before that [09:42] \sh: well, the entire idea of pip/gems/etc. does, as they are essentially a parallel and much less robust packaging system [09:42] persia, that's probably true, I'll dig deeper [09:43] zyga, Sure. I'm not saying everything works, I'm just saying that there likely exist some folk for whom it does work now, and so you need to consider a painless migration path. [09:43] persia, but even if the change is disruptive I'd say it's better than not having the change at all - we can work around that - a debconf setting that for new installs uses the /usr/local path and for existing installs continues to use /var/lib [09:43] That said, it's a good time to discuss this in Debian, as just-after-release is the best time for sweeping changes. [09:43] persia, with possible dpkg-reconfigure to start from scratch with /usr/local if someone wants to [09:43] right, that's true [09:44] debconf is a bad place to store information. Better to adjust patches to have it be a config file (and maybe ask debconf questions to set initial values) [09:44] pitti, (they also tend to work on other platforms and that's why people still use them) [09:44] persia, that makes sense [09:45] ok, backlog read. [09:45] ok [09:45] lucas, so what do you think about this bug? [09:46] so. there are two conflicting visions on this rubygems stuff. if you see rubygems as a tool that manages ruby libraries in some obscure way the user doesn't need to know about, then it makes perfect sense to install to /var/lib [09:46] <\sh> pitti: when app devs KNOW what they are doing, but most app devs DON'T. this is my experience from several years working as sysadmin in bigger companies, that's why we go to the way of "app dev needs to ask sysadmin first what to do when they need software x and y" [09:46] it's not _that_ different from mysql, for example. [09:46] it's just some data storage. [09:46] the other vision is to see it like "tar on steroids". and then it makes sense to install to /usr/local [09:46] right, for libraries users don't care as this use case works out of the box _with_ this patch [09:47] lucas, is there anything apart from executable scripts that may be broken if we stick to /var/lib? [09:47] my position is that the ruby community is making a fuss about this, while it's not really important [09:47] lucas, (in other words) can we fix this by changing path somehow or do we really need to install stuff to /usr/local [09:48] but I'm tired of the rants, so I would agree to push for going to /usr/local [09:48] zyga: please let me finish:) [09:48] (sorry) [09:48] Any gem that uses a static path rather than relatives and variables is potentially subject to issues if the path is other than that expected. [09:48] pitti, I only want to give the users more testing time, so that I can make the best decision between the two pdftoraster filters. [09:48] now, there's the problem of executables. by default, rubygems put them in /usr/bin, which is really wrong and dangerous [09:48] debian put them outside $PATH in /var/lib. that causes usability problems [09:49] if we put the rest of the gem in /usr/local, I think that it would make sense to put the executables in /usr/local/bin [09:49] so they are in $PATH, overriding stuff installed via packages [09:49] that might break some users' machines, but they are asking for it, so why not [09:49] lucas, that's consistent with other similar tools [09:50] yup [09:50] lucas, and with the purpose of /usr/local so I agree with you [09:50] lucas, so, one more question what about 1.8 and 1.9 [09:50] so, for this to happen, the correct way, we need: [09:50] - someone to update the current debian rubygems package to the latest rubygems version [09:50] - patches to revert the path changes, and install executables to /usr/local/bin [09:51] - a migration/upgrade plan that works [09:51] and that work needs to be done for the standalone rubygems package (for ruby1.8) and for the ruby1.9.1 package, which includes rubygems [09:51] (I think that first step is optional but I agree in general) [09:51] tkamppeter: right, see /query [09:52] lucas, what migration path do you think we can provide? [09:54] lucas, does the option to change this on future installs and retain the old path on existing installations seem sensible to you? [09:54] I'm not motivated to work on this personally, but will weight in the discussion, and am willing to apply the patches and maybe do the upload [09:54] I think that we should change the path also for old installs [09:54] (somehow) [09:54] not to add to the confusion [09:54] lucas, that would be an option to dpkg-reconfigure the package I think - otherwise we would break stuff that's already installed [09:55] well, we could mv + add a symlink or something [09:55] (or not if there is a way to "fix" this by moving all gems from /var to /usr/local) [09:55] hmm, symlink is a simple solution, yeah [09:55] that needs to be investigated, but as I said, I'm not motivated to work on this myself :) [09:55] lucas, I understand, I read your blog post on this [09:56] lucas, I'm asking for advice, you know much more than I do about this topic [09:57] well, I think that the way to start is to experiment with the current rubygems package [09:58] lucas, do you think it's necessary to update it to the most recent upstream version first? [09:58] zyga: it would be better [09:58] lucas, okay, let me see how much work is needed for that first [09:59] lucas, would you care to add your thoughts to that bug? [09:59] lucas, if you don't mind we could also confirm it [10:06] well, maybe you can summarize the discussion there and then I'll adjust if it doesn't match my thoughts [10:06] it's a good way to check that we understand each other [10:06] lucas, sure, that's a good idea [10:11] lucas, done [10:12] lucas, I have an email to ubuntu-devel and diago moriwaki so if you don't find anything wrong with my comment I'll send it and we'll see what he thinks [10:15] tkamppeter: uploaded to D and U, thanks [11:03] pitti, thanks for uploading. [11:13] hi guys. anyone from the package maintenance team here? [11:17] pitti: ummm what? [11:17] zul: I didn't say anythign; perhaps I mis-tab-ed "zyga" [11:18] ah, so I did [11:18] pitti: ah ok [11:18] that also explains why zyga didn't see my initial response [11:18] zul: sorry about the confusion [11:18] pitti: no worries === MacSlow is now known as MacSlow|lunch [13:15] \sh, dholbach, didrocks: thanks! :D === oubiwann is now known as oubiwann_ === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [13:55] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: jdstrand, Daviey === MacSlow|lunch is now known as MacSlow === diwic is now known as diwic_afk === sconklin-gone is now known as sconklin [14:49] pitti, whose turn is it to chair tech board? [14:50] mdz: Scott according to previous report [14:52] he doesn't seem to be online atm [14:57] mdz: next rotation would be cjwatson then? [14:57] will we even have quorum today? [14:57] ah, I think kees said he could cover if Scott wasn't available [14:58] * kees nods [14:58] mdz: we did the last one with three persons as well, we didn't have to vote, though === herton is now known as herton_lunch === diwic_afk is now known as diwic [15:08] bdrung: Hey, around? [15:09] nigelb: yes [15:09] bdrung: hey, with your new dd hat, want to talk about Debian as an upstream at UDW? [15:13] nigelb: i suspected that you ask that. i don't enjoy doing that. can't you find someone else? [15:13] * bdrung tries to hide. ;) [15:14] bdrung: well, the someone else I asked suggested you :p [15:14] bdrung: but yeah,I can ask around :) === bjf[afk] is now known as bjf [15:31] cjwatson, hi, I know it's pretty late to be noticing this, but network-manager-vpnc appears to be missing from the network-manager package set [15:34] cyphermox: odd, it was in the original list. I must have made a mistake creating the set. Fixed. [15:35] thanks [15:36] rickspencer3: hi, got a few mins? :) [15:36] hi nigelb [15:36] sure [15:36] 'sup? [15:37] rickspencer3: hey, I was wondering if you'd have time to take a Q and A at UDW [15:37] It would rock to have one of those sessions at UDW [15:37] I would be happy to, though when specifically would you need me there? [15:37] You can pick an empty slot from here https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable [15:44] nigelb, what topic should i put in? [15:44] rickspencer3: feel free to put in something creative, like I did for jcastro's session ;) [15:45] nigelb, well, what do you want me to discuss? [15:45] nigelb: can me with others in zeitgeist team take one session? [15:46] rickspencer3: general q and a would work or anything specific you want to put in :) [15:46] manish: I've been loojing for you! but then i was looking for m4n1sh [15:46] manish: YES! [15:46] Zeitgeist Internals [15:46] is the topic fine? [15:46] yup [15:47] Mon 28th Feb [15:47] 20UTC [15:47] manish: adding [15:47] rickspencer3: shall I add you in? === hanska is now known as dapal [15:47] manish: who else with you? [15:48] nigelb: need to look [15:48] probably seiflotfy or mhr3 [15:48] kamstrup is already taking a session [15:49] manish: right now, I've only put you down for it [15:49] manish: feel free to update later [15:49] sure === herton_lunch is now known as herton [15:54] nigelb, sure, I think that the Thursday slots will work best for me [15:55] rickspencer3: 1800 UTC? :) [15:55] 'Talk to Rick' [15:55] * Laney prepares some fiendish questions ;-) [15:55] nigelb, 1800 UTC is fine [15:55] thanks Laney ;) [15:56] rickspencer3: heh, Thanks :) [15:56] nigelb, I'm happy to do it, but does anyone even know who I am? [15:56] maybe "Q+A with Ubuntu Engineering Director"? [15:56] heh, ok [15:57] added [15:57] rickspencer3: people know you [15:57] hi rickspencer3! [15:57] people know you because you mythbusted about rollign release === diwic is now known as diwic_afk === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [16:18] cjwatson: do I need to file graphical boot corruption against grub2 also, or is plymouth sufficient? [16:21] mdeslaur: do you know which it is? [16:21] mdeslaur: if not, just one place would be preferable [16:21] cjwatson: unfortunately no, it's bug 713088 and I filed it under plymouth [16:21] Launchpad bug 713088 in plymouth (Ubuntu) "[natty] plymouth boot screen corrupted with nouveau on Thinkpad T61" [Undecided,New] https://launchpad.net/bugs/713088 [16:21] cjwatson: thanks [16:33] mdeslaur: I'm seeing the same, but not with alpha2 livecd [16:34] tjaalton: huh [16:34] tjaalton: I wonder why the live cd would be different [16:35] right [16:35] me too :) [16:46] tjaalton,mdeslaur: the live CD uses syslinux and doesn't start the kernel in graphics mode [16:46] (this doesn't necessarily mean it's a grub2 bug though, perhaps merely something triggered by that) [16:46] tumbleweed: ping, hey [16:46] ah, cool. thanks for the explanation cjwatson [16:47] tumbleweed: Looking for someone talk about debian at UDW, would you be interested? === beuno is now known as beuno-lunch === ogra is now known as Guest60731 [17:23] kees: ubuntu-dev-tools fails to build. [17:23] kees, watch out! bdrung is the ubuntu-dev-tools police! ;-) [17:23] * dholbach hugs bdrung [17:24] dholbach: :P === dendrobates is now known as dendro-afk [17:34] bdrung: eek, did I typo my commit? === dpm_ is now known as dpm [17:35] kees: no. you didn't check if debian/rules exist. the testcases didn't contain a rules file. [17:35] arrrgh === deryck is now known as deryck[lunch] [17:36] bdrung: sorry. I didn't check since the prior checks validated we were in a real source tree, and debian/rules is required. [17:36] kees: please extent the testcases and add one for checking for the missing rules file and one for finding xscb-original-maintainer in rules [17:36] yup [17:36] actually, the test-data does have a rules file. anyway, I'll go build it. [17:37] kees: yes, but we don't use the "test-data". we create virtual files. [17:37] bdrung: noted. I'll fix it up. [17:37] thanks === ogra_ is now known as ogra__ === ogra__ is now known as ogra_ === dendro-afk is now known as dendrobates [17:56] jhunt: FYI, i've taken to tagging bugs that we may want to discuss/watch with the tag 'upstart'.. [17:57] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: Daviey [17:57] SpamapS: great! [17:57] jhunt: should help keep our bug squashing sessions more focused [17:57] Daviey: fyi, I will upload getfem++ once I confirm it builds ok [17:57] agreed :) [17:57] Daviey: re piloting === beuno-lunch is now known as beuno === sforshee is now known as sforshee-lunch === zyga is now known as zyga-afk [18:32] bdrung: okay, should be fixed up now. [18:33] hmm, does the utouch team have a dedicaterd channel ? [18:33] *dedicated [18:40] ogra_: #ubuntu-touch [18:41] ah. thanks ! [18:41] np.. [18:42] slangasek, hey [18:43] slangasek, do you know if freetype is going to be updated from 2.4.2 to 2.4.4 in debian before natty? [18:46] slangasek, context is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612484 === deryck[lunch] is now known as deryck === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [18:48] seb128: planning to [18:49] slangasek, I was wondering if I should do some backporting on update in ubuntu or just wait on debian [18:49] on -> or [18:50] I am building lots of ubuntu packages using "debuild" from a script. Some build one package, some build more than one. How can I *programatically* tell what the filenames are of the packages that would be / have just been built? [18:53] alexbligh: you know about control file? right? [18:57] seb128: what timeframe do you need it in? I probably can't commit to getting the update done in Debian for about 2 weeks [18:58] slangasek, I would like to get the update in natty, 2.4.2 to 2.4.4 seems bug fixing so I don't think we need to aim for ff for it [18:58] slangasek, before natty beta would be nice [18:59] slangasek, what do you think? [18:59] seb128: I can do that, no worries [19:00] manish, sure, I know about the control file. That would tell me the package name(s). And the changes file would tell me the version. But I don't really want to go parse them all myself, plus work out whether it's amd64 etc. [19:00] i.e. I need the full filename, not just the package name [19:01] full name of? [19:01] Full name of the deb file "debuild" has buld, e.g. ../my-package-name_1.3.0.11822_amd64.deb [19:01] slangasek, thanks, I will wait and sync from debian when you do the update then, less work for me, thanks [19:02] seb128: happy to help! :) [19:02] manish, I am autobuilding from an svn repository, which is why it is not "just obvious". [19:03] cdbs: you are needed for help [19:03] * cdbs to the rescue [19:04] alexbligh1: you want to alter the filename of the resultant deb? [19:05] alexbligh1: will be built: can't necessarily reliably tell in all cases. have been built: debian/files, or parse the .changes ('dcmd' can help) [19:06] cdbs, no I just want to know what it will be called. Alternatively, if I could specify some form of hook at the end of the build process where it could execute some known command (without that being involved in EVERY build, that would be ok) [19:06] man debuild /HOOKS [19:06] alexbligh1: I think the name is based like this: PACKAGENAME_FULLVERSION_ARCH.deb [19:07]