| bkerensa | barry: do you know what the bug id you open for landscape-client? | 00:37 |
|---|---|---|
| bkerensa | in regards to the name tweak? | 00:37 |
| bkerensa | disregard I found it >.< | 00:38 |
| apachelogger | skaet: no status page for kubuntu quantal yet? | 01:28 |
| skaet | apachelogger, give me a list of blueprints you want linked, and I'll set it up. :) | 01:31 |
| apachelogger | skaet: groovy... https://blueprints.launchpad.net/sprints/uds-q?searchtext=kubuntu all starting with kubuntu- please :) | 01:38 |
| skaet | apachelogger, https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-flavor-kubuntu has been setup. for the work items to show up, the kubuntu-q-* blueprints will need to have priority set, and have their definition approved. | 02:15 |
| apachelogger | skaet: thank you | 02:18 |
| apachelogger | ScottK: ^ | 02:19 |
| TheMuso | @pilot in | 02:47 |
| === udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso | ||
| RAOF | Note to the KDE team: launchpad will hate you should you try to do things like https://bugs.launchpad.net/ubuntu/+source/meta-kde/+bug/1002336 - it's not possible to accept the nominations for Precise because LP times out. | 02:47 |
| ubottu | Launchpad bug 1002336 in smokeqt (Ubuntu) "SRU tracking bug for KDE SC 4.8.3" [Undecided,Fix released] | 02:47 |
| === Jacky is now known as JackyAlcine | ||
| === JackyAlcine is now known as Jacky | ||
| === dendrobates is now known as dendro-afk | ||
| pitti | Good morning | 03:35 |
| === Jacky is now known as siibot | ||
| pitti | apw: apt-cache show linux-firmware-nonfree has the modaliases now :) | 04:17 |
| === siibot is now known as Jacky | ||
| pitti | apw: btw, the script spits out firwmare files which are not referenced by any module; it seems that l-f-nonfree ships an older version of the DVB-USB firmware, while linux-firmware ships the current and actually working versions | 04:18 |
| pitti | apw: I hope that's not an accident (i. e. the firwmare is actually free) | 04:18 |
| pitti | apw: so I guess we should remove the old one from -nonfree? | 04:18 |
| === thegodfather is now known as fabbione | ||
| === astraljava1 is now known as astraljava | ||
| === mbiebl_ is now known as mbiebl | ||
| TheMuso | @pilot out | 06:43 |
| === udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| dholbach | good morning | 07:05 |
| apw | pitti, generally the firmware in linux-firmware comes either from the upstream firmware tree which is all redistributible or has been through legal for confirmation, if you know the filename i'll get the right people to confirm | 07:20 |
| pitti | apw: ah, great; one example is /lib/firmware/dvb-usb-dib0700-1.20.fw | 07:20 |
| pitti | apw: nonfree ships a -1.10 version | 07:21 |
| pitti | apw: I don't doubt much that it's ok to have in -free now (great thing!), just saying that we can most probably ditch the old version from -nonfree? | 07:21 |
| apw | pitti, yeah for sure, i believe the latter too, and getting rid of anything from -nonfree should be on our list for sure | 07:23 |
| pitti | apw: not sure if you already looked at the changelog, but for now you need to run "debian/rules debian/linux-firmware-nonfree.modaliases" manually every now and then | 07:24 |
| pitti | apw: do you see a way how this could work during build time, even on the buildds? | 07:25 |
| pitti | apw: i. e. could we do something like build-depen on linux-generic to pull the current kernel into the buildd chroot, and iterate over that instead of /lib/modules/`uname -r`? | 07:25 |
| pitti | apw: then the modaliases would auto-update itself during build and would always be current | 07:25 |
| pitti | and we would also have the list of abandoned firmware files for free in every build log | 07:26 |
| apw | pitti, hmmm i was indeed reading that changelog with dismay :) | 07:27 |
| pitti | apw: because of the manual step, or something else? | 07:27 |
| apw | pitti, heh yeah just the manual step, as i assume the manual step includes installing and booting the kernel from the wording | 07:28 |
| pitti | apw: yes; IOW, you'd usually run this on your developer machine | 07:28 |
| pitti | apw: I just don't know whether it has ever been tried to build-depend on the current kernel | 07:29 |
| apw | pitti, which branch are you using for this, i'd like to have a look | 07:29 |
| pitti | apw: ubuntu:linux-firmware-nonfree (the UDD branch) | 07:29 |
| pitti | apw: I guess that would need to be something like linux-generic [i386 amd64], linux-whatever [powerpc], linux-ti-omap4 [armel, armhf], etc.? | 07:30 |
| apw | pitti, i would expect to be able to do that indeed, build-dep on the binary kernels and do it in the build | 07:30 |
| apw | pitti, well the issue is that its an arch: all package, so only builds on i386 | 07:30 |
| pitti | oh, right | 07:30 |
| apw | so we'd only get the deps on that one | 07:30 |
| pitti | so linux-generic would actually be sufficient | 07:30 |
| pitti | apw: well, if we find out that ti-omap4 has modules that need -nonfree firmware (we don't have that ATM), we can always extend that | 07:31 |
| apw | yeah, and probabally that'd be close enough for most use cases, if its not then we'd probabally want to do the others manually | 07:31 |
| pitti | it's an improvement either way | 07:31 |
| apw | yeah | 07:31 |
| pitti | and right now (running manually) I only get linux-generic as well | 07:31 |
| apw | pitti, i think this can be done, i'll poke it | 07:35 |
| apw | pitti, if i want to use sed in my debian/rules do i need a builddep (and how do i work that out) | 07:46 |
| pitti | apw: no, sed is essential | 07:47 |
| pitti | apw: but I did forget to add a python3 build dep, for the gen-modaliases script | 07:47 |
| pitti | apw: why do you need sed, OOI? dh_modaliases already does the substitution in the Modalises: field | 07:47 |
| apw | pitti, this is to work out the version of the kernel that we installed by depending on linux-image-generic | 07:48 |
| pitti | ah | 07:48 |
| apw | it may not be sed by the time i am done, i was realising i needed to tell it about some commands, rsync for instance in the kernel package and i don't know how to know what is "essential" and therefore not necessary to mention | 07:49 |
| pitti | apw: I guess this is a good start? dpkg-query -f'${Depends}' -W linux-image-generic | 07:50 |
| pitti | $ dpkg-query -f'${Depends}' -W linux-image-generic | cut -f1 -d, | cut -f3- -d- | 07:50 |
| pitti | 3.4.0-3-generic | 07:50 |
| pitti | apw: first cut gets the first dependency, second cut chops off the linux-image- prefix | 07:51 |
| pitti | apw: as a check I'd add a test -d /lib/modules/$version to debian/rules, so that it fails if it's not there | 07:51 |
| apw | yep thats slightly simpler than my: | 07:54 |
| apw | kernel_version = $(shell, apt-cache depends linux-image-generic | sed -ne 's/^ Depends: linux-image-//p') | 07:54 |
| apw | but replies on the order ... hmmm mine is order independant | 07:55 |
| pitti | apw: actually, using apt-cache is more clever because you don't need to build-depend on it | 07:56 |
| apw | ok cool | 07:56 |
| pitti | hm why does that not work here | 07:56 |
| pitti | oh! translations | 07:57 |
| pitti | $ LC_MESSAGES=C apt-cache depends linux-image-generic | sed -ne 's/^ Depends: linux-image-//p' | 07:57 |
| pitti | 3.4.0-3-generic | 07:57 |
| pitti | extra-3.4.0-3-generic | 07:57 |
| apw | oh of course | 07:57 |
| apw | ok | 07:57 |
| pitti | apw: so it's still order dependent, you'd need to find the one without extra- ? | 07:57 |
| apw | LC_MESSAGES=C apt-cache depends linux-image-generic | sed -ne 's/^ Depends: linux-image-[0-9]//p | 07:58 |
| pitti | LC_MESSAGES=C apt-cache depends linux-image-generic | sed -ne 's/^ Depends: linux-image-[0-9]//p;' | 07:58 |
| pitti | apw: ^ how about this? | 07:58 |
| apw | pitti, i think thats the same :) | 07:58 |
| pitti | ah, snap | 07:59 |
| apw | but it loses the 3 | 07:59 |
| * pitti ch$ LC_MESSAGES=C apt-cache depends linux-image-generic | sed -ne 's/^ Depends: linux-image-\([0-9]\)/\1/p;' | 07:59 | |
| pitti | 3.4.0-3-generic | 07:59 |
| apw | yep thats the one | 07:59 |
| pitti | without the /me ch crap, of course | 07:59 |
| pitti | apw: oh, hang on -- we still need to build-depend on it, as we need to iterate over the modules | 08:00 |
| apw | right | 08:00 |
| * apw is working on it :) | 08:01 | |
| vibhav | Is it possible for upstream to be the repository itself? | 08:13 |
| cjwatson | apw: how do you know if it's essential> apt-cache show sed | grep ^Essential | 08:19 |
| cjwatson | well, ^Essential: | 08:19 |
| apw | cjwatson, awsome, thats what i wanted to know | 08:19 |
| cjwatson | with one extra caveat: awk is "virtual Essential" by way of a Pre-Depends from base-files (i.e. the Essential facility is having one of mawk or gawk installed, although neither specific one is Essential) | 08:20 |
| apw | pitti, subprocess.Popen communicate is barfing on a utf8 character in modinfo output, know how to fix that off the top of your head ? | 08:29 |
| pitti | apw: oh, with python 3? | 08:30 |
| apw | pitti, indeed using your script, was just testing my mod to take a directory for the modules, using the ones on my precise system | 08:30 |
| apw | pitti, and there is: | 08:31 |
| apw | author: Bj�rn Stenberg | 08:31 |
| apw | in one of them, and it dies on it... | 08:31 |
| pitti | hm, I already specified universal_newlines=True, so it shoudl do the decoding itself | 08:31 |
| pitti | apw: UnicodeDecoreError, or Encode? | 08:31 |
| apw | UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position 125: invalid start byte | 08:31 |
| apw | the special 'o' there in the author: field | 08:31 |
| pitti | oh, so it's already trying UTF-8, not ascii | 08:31 |
| pitti | apw: try dropping universal_newlines=True | 08:31 |
| pitti | apw: and instead | 08:32 |
| pitti | out = modinfo.communicate()[0].decode('UTF-8', errors='ignore') | 08:32 |
| pitti | apw: that might be fixed in quantal's kernel? It ran flawlessly on 3.4.0-2 | 08:32 |
| apw | that takes a lot longer | 08:33 |
| apw | yeah it maybe that the modules don't have the name in the later kernel indeed | 08:33 |
| pitti | apw: which module is that? | 08:33 |
| apw | will find out, but i wanted to zap the bug while i was seeing it | 08:33 |
| apw | modinfo /lib/modules/3.2.0-23-generic/kernel/drivers/usb/storage/ums-isd200.ko | 08:33 |
| pitti | no, authors are still there | 08:33 |
| pitti | author: Björn Stenberg <bjorn@haxx.se> | 08:34 |
| apw | but note that when you pasted it its an o" | 08:34 |
| pitti | your special 'o' was broken here (a diamond with a question mark) | 08:34 |
| apw | and when i pasted it it was ... right | 08:34 |
| apw | so i suspect its been corrected in the source to be valid | 08:34 |
| pitti | apw: heh, funny; exactly the other way roundhere | 08:34 |
| pitti | apw: when I do modinfo ums-isd200, I get an o with two dots on top, it looks correct | 08:35 |
| apw | nnng | 08:35 |
| apw | ahh no i was saying ... "right what you said" not it was "right" | 08:35 |
| apw | and when i pasted it it was ... "what you said" | 08:36 |
| apw | ok ... so i think the kernel source has the name fixed or something b | 08:36 |
| pitti | aah | 08:36 |
| pitti | confusion FTW | 08:36 |
| apw | but its good to catch the errors case | 08:36 |
| pitti | right | 08:36 |
| pitti | thanks for spotting | 08:36 |
| * apw gets this cleaned up | 08:36 | |
| pitti | we don't really need the author or anything being UTF-8anyway | 08:37 |
| cjwatson | apw: I expect the problem is that the output was in ISO-8859-1 | 08:39 |
| cjwatson | Yep, indeed | 08:40 |
| apw | pitti, right ... we don't care on the encoding though i believe the kernel should be utf-8 so i am not supprised it got fixed | 08:40 |
| apw | cjwatson, ahh that makes sense then, a common other form | 08:41 |
| === dpm__ is now known as dpm | ||
| apw | pitti, and we said it needs a python3 build-dep as well yes ? may as well fix that while i am here | 08:47 |
| pitti | apw: when we run the script during build, yes | 08:47 |
| apw | pitti, of course, i am running it in the build now, *slap* | 08:48 |
| apw | pitti, it is me or are a huge number of the firmware files saying they are unreferenced | 09:06 |
| pitti | apw: yes, here as well | 09:06 |
| apw | ok ... then i didn't break it | 09:06 |
| pitti | apw: I guess b43 is still a bit special, the module doesn't declare firmware: | 09:06 |
| pitti | apw: but the various dvb bits are indeed obsolete | 09:06 |
| apw | pitti, i shall add a WI to our config review to review it, tim can do it, he loves firmware :) | 09:06 |
| pitti | apw: http://paste.ubuntu.com/1002650/ is what I get on quantal | 09:07 |
| pitti | apw: we shoudl probably not print the message for b43, but the rest could be real | 09:08 |
| === elleuca is now known as deborho | ||
| === deborho is now known as deboroh | ||
| dpm | hi pitti, did you have a chance to look at the example on https://bugzilla.gnome.org/show_bug.cgi?id=676543 - sorry to keep asking, it's a major blocker for shipping localized apps in our app developer process, and I'm trying to see what we can do as the next steps. Alternatively, any other pygobject/gtk people you'd suggest me to talk to, so as not to keep bothering you? thanks! | 09:26 |
| ubottu | Gnome bug 676543 in GtkBuilder "Cannot load translations from a locale dir other than the default" [Normal,Unconfirmed] | 09:26 |
| pitti | dpm: not yet, sorry | 09:27 |
| dpm | pitti, no worries. Any other gtk/pygobject people I could ask? | 09:40 |
| pitti | not sure if there is a #gtk channel on gimpnet | 09:40 |
| seb128 | dpm, pitti: #gtk+ on irc.gnome.org | 09:43 |
| seb128 | or #gnome-hackers is usually good for GNOME,GTK questions as well | 09:44 |
| dpm | thanks seb128 :) | 09:44 |
| apw | pitti, i notice i failed to remove the pre-built file, i've dropped that in the top if the tree | 10:41 |
| apw | pitti, you said that b43 doesn't have aliases, but i note in the built version it actually does: Modaliases: b43(bcma:m04BFid0812rev1Dcl ...) | 10:41 |
| pitti | apw: ah, you mean the .modalias file should be generated, and removed again after dh_modaliaes? | 10:41 |
| pitti | apw: it does have aliases -- I said (or at least meant) that b43 does not have firmware: links | 10:41 |
| apw | pitti, you had made one by hand and checked it in, i removed that from the bzr branch | 10:42 |
| apw | pitti, ahh ok makes sense | 10:42 |
| pitti | apw: right, that was necessary while it wasn't generated at build time; I guess it doesn't matter that much to keep it, but it's cleaner to remove now indeed | 10:42 |
| apw | pitti, seems we got away with it in the builds cause it is older, but it is now gone for the next upload | 10:42 |
| apw | pitti, i'll upload it with the cleanout of old firmwares | 10:45 |
| pitti | thanks! | 10:45 |
| === MacSlow is now known as MacSlow|lunch | ||
| pitti | apw: hm, in your l-f-nonfree commit, it seems you forgot to actually rm the file? or committed this after building, and forgot to rm the file in debian/rules after dh_modaliases? | 11:07 |
| apw | pitti, ihmmm | 11:12 |
| pitti | mvo: is there an apt config option to disable authentication checks? (for a test suite) | 11:13 |
| apw | pitti, sorting | 11:13 |
| geser | pitti: like APT::Get::AllowUnauthenticated? | 11:15 |
| pitti | geser: ah, thanks; I was looking in man apt.conf, and it's not there | 11:16 |
| pitti | ah, it's in man apt-get | 11:16 |
| pitti | mvo: unping, sorry | 11:16 |
| geser | pitti: /usr/share/doc/apt/examples/configure-index.gz has all the available options listed | 11:17 |
| Daviey | pitti: if using d-i (guess you are not?), d-i debian-installer/allow_unauthenticated boolean true | 11:17 |
| pitti | nope, regular apt | 11:17 |
| pitti | geser, Daviey: working fine, thanks! | 11:17 |
| === yofel_ is now known as yofel | ||
| pitti | tseliot: do you see a reason why ubuntu-drivers-common should not be arch:all ? | 11:25 |
| tseliot | pitti: there's a C program for hybrid graphics which shouldn't run on archs other than i386 and amd64 | 11:27 |
| pitti | tseliot: (sorry, was at lunch) ah, I see; but the package is already built on arm{el,hf}, too?} | 12:16 |
| ogra_ | is jockey supposed to use that in the future ? | 12:17 |
| ogra_ | (do i need to make any adjustments for armhf drivers ?) | 12:18 |
| pitti | ogra_: no, jockey is going to _be_ that in the future :) | 12:18 |
| ogra_ | ah | 12:18 |
| pitti | ogra_: in other words, we plan to drop jockey and replace it with something much simpler | 12:18 |
| ogra_ | well, ping me if arm changes are needed | 12:18 |
| ogra_ | :) | 12:18 |
| pitti | it was built for a lot more and different use cases that we are actually using it for | 12:18 |
| === _salem is now known as salem_ | ||
| pitti | ogra_: I have a work item to see what to do with that pvr-omap4 handler that we currently have | 12:19 |
| pitti | ogra_: could you please check if "modinfo omapdrm_pvr" shows any modaliases? | 12:20 |
| pitti | ogra_: i. e. is that module loaded automatically, or do you need some special magic for it? | 12:20 |
| ogra_ | will do, i have no panda running atm, gimme a few | 12:20 |
| pitti | ogra_: no worries, not urgent | 12:20 |
| ogra_ | you dont look for the architecture ? | 12:21 |
| * ogra_ would have thought just using archdetect would be easier | 12:21 | |
| pitti | I'm still working on the infrastructure bits, the special cases and migration come later | 12:21 |
| pitti | ogra_: just looking for the arch is not enough for e. g. the nvidia or the bcmwl driver | 12:22 |
| ogra_ | on arm you usually only have one driver for one SoC, its a bit easier than all these PCI and AGP cards on x86 | 12:22 |
| pitti | we need to check the system's modaliases against the patterns that the kmods specify | 12:22 |
| ogra_ | k | 12:22 |
| pitti | ogra_: so _if_ it has modaliases which match, it will just work if we fix the package to actually declare them | 12:22 |
| pitti | if not, we'll need a special case | 12:22 |
| pitti | but that shouldn't be hard to do | 12:22 |
| vibhav | Can somebody nominate https://bugs.launchpad.net/ubuntu/+source/munin/+bug/598385 for Lucid? | 12:23 |
| ubottu | Launchpad bug 598385 in munin (Ubuntu Oneiric) "[SRU] munin plugin exim_mailqueue has incorrect graph configuration" [Undecided,In progress] | 12:23 |
| ogra_ | tegra will be problematic here, it doesnt use any kernel modules | 12:23 |
| pitti | vibhav: done | 12:23 |
| vibhav | pitti: thanks! | 12:24 |
| pitti | ogra_: I'll make sure we'll have replacements for all the existing handlers before we switch over | 12:24 |
| ogra_ | yeah, no hurry :) | 12:24 |
| ogra_ | tegra users are used to having to jump through hoops ... i'm happy with every release that makes it a bit easier but people usually can cope :) | 12:25 |
| vibhav | what version of perl does oneiric and lucid use? | 12:31 |
| pitti | $ rmadison -s lucid,oneiric perl | 12:32 |
| pitti | perl | 5.10.1-8ubuntu2 | lucid | source, amd64, armel, i386, ia64, powerpc, sparc | 12:32 |
| pitti | perl | 5.12.4-4 | oneiric | source, amd64, armel, i386, powerpc | 12:32 |
| vibhav | thanks pitti ! | 12:32 |
| pitti | vibhav: rmadison is in devscripts, FYI | 12:33 |
| vibhav | I did not know that, thanks (again) | 12:33 |
| vibhav | https://bugs.launchpad.net/ubuntu/+source/munin/+bug/598385/comments/12 says that he is too affected by the bug, But I noticed the bug only affected perl 5.14 , any ideas? | 12:35 |
| ubottu | Launchpad bug 598385 in munin (Ubuntu Oneiric) "[SRU] munin plugin exim_mailqueue has incorrect graph configuration" [Undecided,In progress] | 12:35 |
| vibhav | jamespage: ^^ | 12:36 |
| tseliot | pitti: err.. is it? | 12:39 |
| ogra_ | tseliot, well, if it replaces jockey it surely should :) | 12:40 |
| pitti | tseliot: yes, because there is a pvr-omap4 handler | 12:40 |
| tseliot | oh | 12:40 |
| pitti | tseliot: which needs the alternatives handling, I guess | 12:40 |
| tseliot | right | 12:41 |
| pitti | tseliot: I didn't write that myself | 12:41 |
| pitti | so I can't tell much about it | 12:41 |
| ogra_ | there also will be a tegra handler soon | 12:41 |
| tseliot | yes, I remember now | 12:41 |
| pitti | ogra_: please don't write a new one, though; the new system shoudl be ready by next week hopefully | 12:41 |
| ogra_ | and probably an omap3 one if we ever get armhf drivers from TI | 12:41 |
| tseliot | pitti: let's just make sure that C app is not built and installed on anything other than amd64 and i386 then | 12:42 |
| pitti | but as long as installing a package will set up everything, we can integrate it | 12:42 |
| ogra_ | pitti, no worries, but i want all drivers supported by release | 12:42 |
| ogra_ | (all we have packages for in the archive) | 12:42 |
| pitti | ogra_: you can certainly start packaging those, but the logic needs to be/go into the postinsts, not external | 12:42 |
| pitti | tseliot: that can certainly be arranged | 12:42 |
| tseliot | good | 12:42 |
| ogra_ | pitti, they are packaged since precise :) | 12:42 |
| pitti | tseliot: and then arch:any, I guess | 12:43 |
| pitti | ogra_: I mean, the jockey handler has an awful lot of extra code to juggle around alternatives symlinks, etc. | 12:43 |
| tseliot | yep | 12:43 |
| pitti | this needs to go into the postinst (if it isn't already) | 12:43 |
| ogra_ | pitti, oh, indeed, i didnt plkan to touch that right now | 12:43 |
| vibhav | What should be the ubuntu delta for an SRU which has a previous version from debian? | 12:55 |
| vibhav | 5.0.15-2 in unstable; should it be 5.0.15-2ubuntu0.1 for an SRU? | 12:56 |
| pitti | yes, that will work fine | 12:57 |
| cjwatson | It must be less than the version in the development release | 12:57 |
| vibhav | thanks | 12:58 |
| cjwatson | 5.0.15-2ubuntu0.1 in precise-proposed would be inappropriate if the same fix is in 5.0.15-2 in quantal | 12:58 |
| vibhav | cjwatson: What it should be then? | 12:59 |
| pitti | vibhav: oh, I assumed when you said "unstable" you meant "that version was synced from Debian into whichever Ubuntu release you want to SRU TO" | 12:59 |
| cjwatson | vibhav: There is fairly comprehensive advice in https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging | 13:00 |
| vibhav | pitti: Your right,I assumed that | 13:00 |
| cjwatson | You can follow the same convention for SRUs | 13:00 |
| cjwatson | (This is linked from https://wiki.ubuntu.com/StableReleaseUpdates#Procedure) | 13:01 |
| vibhav | thanks | 13:01 |
| ScottK | RAOF: For the KDE SRU tracking bug - we've done a single bug up to now in the previous updates. | 13:03 |
| vibhav | openerp-server is removed from precise and quantal, would it be considered sane to fix bugs for openerp-server in oneiric and other supported releases? | 13:11 |
| ScottK | If they are serious enough to meet the SRU criteria, although I'd suspect there'd be relatively few users of a package like that on non-LTS releases so it may not be the highest priority thing to tackle. | 13:17 |
| xnox | vibhav: please, no. | 13:19 |
| * xnox is OpenERP developer in previous live. | 13:19 | |
| xnox | me and a few other people are in process of repackaging 6.1, 6.0 & 5.0 together with migration scripts. | 13:20 |
| xnox | anyone running 5.0 is doomed, and they know it =))) | 13:20 |
| diwic | seb128, I was thinking of writing a patch for sound-nua, but cjcurran has so many assorted branches of that, do you have any idea of what branch one should start with? | 13:20 |
| vibhav | xnox: thanks! | 13:20 |
| xnox | vibhav: I would check if CVE affect it, e.g. the recent feedparser. | 13:21 |
| seb128 | diwic, is that a patch for precise? | 13:21 |
| diwic | seb128, probably | 13:21 |
| seb128 | diwic, https://code.launchpad.net/~cjcurran/+junk/soundnua-gtk-warnings | 13:21 |
| seb128 | diwic, don't ask about the name, he just kept working on that vcs | 13:21 |
| diwic | seb128, all right, thanks | 13:21 |
| seb128 | diwic, that what we currently have in precise | 13:21 |
| seb128 | diwic, well rather we have that and r31 from lp:~diwic/+junk/soundnua-lp984637 | 13:22 |
| seb128 | diwic, so just stack it on top of that branch of yours | 13:22 |
| diwic | seb128, okay, thanks | 13:23 |
| seb128 | diwic, yw! | 13:23 |
| pitti | tseliot: ok, hybrid-detect now only gets built on x86 in my latest branch | 13:35 |
| pitti | tseliot: I'm quite satisfied for a first run with what's in the branch now | 13:35 |
| pitti | tseliot: but I'd like to see it tested at bit on an nvidia or fglrx machine before uploading; do you have some minutes for that? | 13:36 |
| === MacSlow|lunch is now known as MacSlow | ||
| tseliot | pitti: I have an nvidia machine here with hybrid graphics | 13:41 |
| pitti | tseliot: it doesn't handle the hybrid special case yet (I have a WI for this) | 13:43 |
| pitti | tseliot: I'm mainly interested whether "ubuntu-driver list" shows the nvidia cards | 13:44 |
| pitti | tseliot: and it now assumes that merely installing nvidia-current sets up all the alternatives, etc. | 13:44 |
| pitti | tseliot: i. e. no extra code any more that the handlers used to do | 13:44 |
| tseliot | pitti: I thought you wanted to test hybrid-detect | 13:45 |
| pitti | tseliot: I didn't touch the source | 13:45 |
| pitti | tseliot: just setup.py to only build/install it on 86; I already tested taht | 13:45 |
| tseliot | pitti: ok, feel free to send me whatever script you'd like me to test | 13:45 |
| pitti | tseliot: the main thing that I haven't tested yet is that jockey still detects and installs the nvidia drivers with all the nvidia-common -> u-d-common renaming and changed file paths | 13:46 |
| pitti | tseliot: i. e. check out https://github.com/martinpitt/ubuntu-drivers-common, build/install it, and test in jockey; plus ensure that "ubuntu-drivers list" shows the nvidia bits | 13:46 |
| === andreas__ is now known as ahasenack | ||
| tseliot | pitti: which jockey shall I test it with? The one in precise? | 13:47 |
| pitti | tseliot: that's fine, yes | 13:47 |
| Daviey | Hmm, why is that on github and not launchpad? | 13:48 |
| tseliot | pitti: ok, I'll test both cases | 13:48 |
| pitti | tseliot: note that if you run precise, then the test suite will fail, it needs some fixes in aptdaemon's test module | 13:48 |
| tseliot | Daviey: do we have git hosting on launchpad? | 13:48 |
| Daviey | tseliot: i think you know the answer to that. | 13:48 |
| pitti | Daviey: I branched from tseliot's nvidia-common git, which is there | 13:48 |
| tseliot | Daviey: and that's your answer ;) | 13:48 |
| tseliot | pitti: ok, I can probably use a quantal chroot and see if it works | 13:49 |
| Daviey | tseliot: this is a ubuntu native codebase, right? Not forked from a project that uses git upstream? | 13:49 |
| tseliot | Daviey: yes | 13:50 |
| tseliot | it's a matter of taste | 13:50 |
| vibhav | Could anybody nominate https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/924002 for oneiric?? | 13:59 |
| ubottu | Launchpad bug 924002 in autofs5 (Ubuntu) "build system strips binaries, so no debug symbol packages available" [Medium,Fix released] | 13:59 |
| pitti | tseliot: back in 45 mins or so, have to run for some errands | 14:01 |
| tseliot | ok | 14:01 |
| === bregma_ is now known as bregma | ||
| === dendro-afk is now known as dendrobates | ||
| === deryck is now known as deryck[afk] | ||
| hallyn | sorry, I know this has been mentioned before, but is there something I can do on quantal to fix the following: | 14:40 |
| hallyn | /gnulib/tests/test-stdalign.c:72:1: error: static assertion failed: "verify (alignof (int64_t) == offsetof (int64_t_helper, slot2))" | 14:40 |
| hallyn | (from a libvirt build failure in buildds) | 14:41 |
| hallyn | I thought there was a fix going in... | 14:41 |
| === debfx_ is now known as debfx | ||
| pitti | tseliot: re | 14:59 |
| === emma is now known as em | ||
| vibhav | pitti: ping | 15:13 |
| pitti | vibhav: pong | 15:13 |
| vibhav | pitti: Could you check if https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/924002 can be nominated for oneiric? | 15:13 |
| ubottu | Launchpad bug 924002 in autofs5 (Ubuntu) "build system strips binaries, so no debug symbol packages available" [Medium,Fix released] | 15:13 |
| pitti | vibhav: done | 15:14 |
| vibhav | pitti: Could you also check the debdiff I attached? | 15:17 |
| pitti | not right now, sorry; can you please just subscribe sponsors? | 15:17 |
| vibhav | They are already suscribed | 15:18 |
| vibhav | Since the bug was fixed in precise | 15:18 |
| wookey_ | anyone know if a rebuild of libc for armhf is planned? /win 29 | 15:27 |
| wookey_ | it failed to build 3 weeks ago so nothing is multi-arch co-installable: https://launchpad.net/ubuntu/+source/eglibc/2.15-0ubuntu11/+build/3458753 | 15:28 |
| dupondje | SpamapS: you read the comments on the remmina bug? :) | 15:31 |
| cjwatson | wookey_: Isn't it awaiting a compiler fix (infinity was working on that, I think), not simply another build attempt? | 15:32 |
| cjwatson | wookey_: Unless you've just checked that a rebuild attempt would succeed, that is :) | 15:32 |
| wookey_ | cjwatson: looking at the log - it does look like something actually needs fixing, yes | 15:32 |
| wookey_ | does x86 libc migrate even if armhf didn't build? | 15:33 |
| SpamapS | dupondje: not yet, just woke up | 15:33 |
| cjwatson | wookey_: We have no migration as yet | 15:34 |
| cjwatson | wookey_: So, er, yes and no? :-) | 15:34 |
| wookey_ | right. | 15:34 |
| wookey_ | I guess this is what happens in 'latest'. | 15:35 |
| dupondje | SpamapS: np, first grab your breakfast :) | 15:35 |
| cjwatson | wookey_: I'm hoping we'll get a roughly sort of testing-like migration thing in place soonish | 15:35 |
| wookey_ | I guess armel built, so I'll go back to crossing that for now, so as to get some useful output | 15:36 |
| cjwatson | Makes sense | 15:40 |
| cjwatson | I see the apt [] resolution bug got fixed in Debian | 15:41 |
| slangasek | infinity: ^^ how goes it with giving us back libc on armhf? Was the plan still to disable the biarch from that side? | 15:41 |
| slangasek | cjwatson: it did? sweet | 15:41 |
| wookey_ | yep - on monday | 15:41 |
| wookey_ | I got some cross-build stats on unstable yesterday - 'not great' :-) | 15:41 |
| wookey_ | http://people.linaro.org/~wookey/buildd/unstable/sbuild-ma/status.html | 15:42 |
| wookey_ | needs either a lot of M-A: foreign fixes or the apt fix to make it default that way for arch:all | 15:42 |
| cjwatson | wookey_: Do you know what's happening with :any support on Debian buildds? | 15:42 |
| wookey_ | in a word, no | 15:43 |
| cjwatson | wookey_: We've tried to push some gettext:any patches to Debian, but they've bounced because Debian's buildd configuration means that fails to build everywhere | 15:43 |
| slangasek | cjwatson: :any == I took an action to follow up on that | 15:43 |
| cjwatson | Significant progress in unstable is going to be contingent on getting that fixed | 15:43 |
| cjwatson | slangasek: right | 15:43 |
| slangasek | of course then my irc server rebooted and I lost the record of what I'd agreed to because I don't log that client | 15:43 |
| slangasek | but I have a general idea still :P | 15:43 |
| infinity | slangasek: The plan for right now is just to flip libc-armel (on armhf) back to v7. | 15:43 |
| luk_work | cjwatson, slangasek: can you poke someone to import the new cifs-utils as the currently imported one does not work at all | 15:44 |
| luk_work | from Debian that is | 15:44 |
| cjwatson | luk_work: A package sync you mean? | 15:44 |
| luk_work | right | 15:44 |
| cjwatson | luk_work: looking | 15:44 |
| cnd | slangasek, a utouch-geis sru was uploaded after the archive branch but before quantal was open, it needs to be copied over to quantal | 15:44 |
| slangasek | (i.e., :any support needs backported for DSA) | 15:44 |
| cnd | how do I make that happen? | 15:44 |
| infinity | wookey_: Sorry about that, I didn't think that it would be an issue for your M-A work, I'll upload a fix today. | 15:44 |
| === dendrobates is now known as dendro-afk | ||
| slangasek | cjwatson: <grunt> apparently it's a merge | 15:45 |
| cjwatson | Yeah, was just looking at that | 15:45 |
| wookey_ | any opinoin on whether I should file a lot of M-A: foreign fixes or try and get the apt behaviour change in? | 15:45 |
| slangasek | Daviey: ^^ you merged the critically-broken version of cifs-utils, can you merge the fixed one? ;) | 15:45 |
| luk_work | would solve #903888 and #1001680 | 15:45 |
| wookey_ | #666772 | 15:45 |
| cjwatson | wookey_: ultimately both, but we should get the apt behaviour change done I think since it makes things a lot more practical ... | 15:46 |
| === deryck[afk] is now known as deryck | ||
| bdmurray | dobey: could you review https://code.launchpad.net/~brian-murray/lptools/grab-descriptions/+merge/106469 | 15:46 |
| Daviey | slangasek: why is it we have a +1 team again? :) | 15:46 |
| slangasek | Daviey: not to clean up after the server team :P | 15:46 |
| cjwatson | Daviey: the +1 team doesn't have a charter to do all the work themselves | 15:46 |
| Daviey | cjwatson / slangasek: right, but it's a QRF to solve issues like this? no? | 15:47 |
| Daviey | Anyway, yes.. i'll take it.. but i can't do it /right now/. | 15:47 |
| infinity | Daviey: The +1 team's biggest job is to annoy other people to fix their bugs. | 15:47 |
| * Daviey pretends he is annoyed. | 15:48 | |
| tseliot | pitti: yes? | 15:48 |
| pitti | tseliot: just said "I'm back" back then, in case you wanted to discuss some stuff | 15:48 |
| slangasek | Daviey: the +1 team's main charter is to give us a consistent archive. cifs-utils doesn't break the archive, just itself | 15:48 |
| tseliot | pitti: ah, ok, sorry too many pings at the same time ;) | 15:49 |
| pitti | actually, http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html had beer for most of the day :) | 15:49 |
| Daviey | slangasek: don't try and use logic to combat my slippery shoulders. | 15:49 |
| slangasek | :) | 15:49 |
| pitti | the ti-omap4 breakage is very very recent | 15:49 |
| Daviey | slangasek / cjwatson: For the avoidance of doubt, i wasn't being serious. | 15:50 |
| slangasek | :) | 15:50 |
| infinity | pitti: Yeah, the kernel team likes to drop building tools every second release. :P | 15:53 |
| * pitti waves good night, time for sport | 15:58 | |
| tremolux | slangasek: hey! we (the Software Center team) have an SRU 5.2.2 that's in process, as you know, but we have unfortunately discovered a regression in one of the fixes (bug #1002271) | 15:59 |
| ubottu | Launchpad bug 1002271 in software-center (Ubuntu) "REGRESSION: crash in cell renderer" [Medium,In progress] https://launchpad.net/bugs/1002271 | 15:59 |
| tremolux | slangasek: and another of the fixes was inadvertently disabled in the release, so three bugs can't be strictly verified | 16:00 |
| tremolux | slangasek: so we are wondering if the best approach is to release 5.2.3 now, which we have in the queue and is ready to go, or should we cherry pick the specific fixes for a 5.2.2.1 release? to me, it seems the former is best as either case will reset the clock, no? | 16:01 |
| slangasek | tremolux: I think the latter is far preferable... otherwise we can be on that verification treadmill indefinitely | 16:03 |
| tremolux | slangasek: but, doesn't the clock reset in either case? the former will just add a few more to the already large number that we have to deal with anyway ;) | 16:04 |
| tremolux | slangasek: unless a cherry-pick can shorten the 1-week hold time, I don't see it buying us too much, but maybe I don't know all the gritty details | 16:05 |
| slangasek | is everything in 5.2.3 an SRU-worthy bugfix? | 16:06 |
| slangasek | from my POV, the number of bugs in the previous upload is already on the far end of what the SRU process can effectively handle | 16:06 |
| tremolux | slangasek: yes, I think we are fixing all worthy bugs, many or from errors.ubuntu.com | 16:09 |
| tremolux | slangasek: is the issue the sheer number of bugs for each release? | 16:09 |
| slangasek | tremolux: yes | 16:09 |
| tremolux | slangasek: we are trying, as a team, to take a policy of releasing all bug fixes that don't break UI/strings/etc. back to Precise | 16:10 |
| slangasek | right - but we need to have discrete points where we can validate one batch and push it through to -updates | 16:10 |
| tremolux | slangasek: and we want to continue this for the next couple of weeks | 16:10 |
| slangasek | and a backport against the current SRU would help that process along | 16:10 |
| tremolux | slangasek: I'm sorry, I'm not sure what you mean by a "backport against the current SRU", you mean just fix the regressions? | 16:11 |
| slangasek | yes | 16:11 |
| slangasek | so we can finish this one, push it through, and then do the next SRU | 16:11 |
| slangasek | instead of getting wedged in -proposed | 16:12 |
| tremolux | slangasek: ok, so then it won't reset the clock on the SRU? | 16:12 |
| slangasek | tremolux: it resets the clock on the report... but we can override | 16:14 |
| tremolux | slangasek: that's what my concern was, if we are resetting the clock again, might as well just take the next set of fixes too, but I see your point of course | 16:14 |
| tremolux | slangasek: ok, then we will do a 5.2.2.1, thanks for your help/advice! | 16:14 |
| slangasek | tremolux: great, thank you :) | 16:14 |
| vibhav | foobar6.1 waits for verification in oneiric-proposed , can I upload fixes into oneiric-proposed using version foobar6.2 ? | 16:16 |
| micahg | vibhav: you should wait until the previous SRU completes unless this fixes a regression in that SRU (you can also help the process along by verifying the fix) | 16:17 |
| vibhav | fine | 16:18 |
| geser | does somebody have an idea why apt tries to download the uncompressed Packages file? as that file doesn't exist it results in a 404. I've seen two users with this problem in the recent days. Or is it an mirror issue as both used the same mirror? | 16:19 |
| vibhav | geser: Which mirror? | 16:19 |
| geser | de.archive.u.c | 16:20 |
| vibhav | micahg: Did you check the application I sent to the bug control? | 16:29 |
| micahg | vibhav: #ubuntu-bugs would be better to discuss | 16:29 |
| ScottK | wgrant: Do we still have the Ubuntuwire FTBFS pages for previous releases? If so, what would be the link for precise? | 16:42 |
| geser | ScottK: http://qa.ubuntuwire.com/ftbfs/precise.html | 16:43 |
| ScottK | geser: Thanks. | 16:44 |
| ScottK | I guess that doesn't include -proposed? | 16:45 |
| geser | it probably would if the precise page would still get updated, but the last update was 2012-04-27 | 16:47 |
| ScottK | Ah. | 16:47 |
| ScottK | wgrant: ^^^ can it be updated? | 16:47 |
| infinity | ScottK: pending-sru has a nice view of FTBFS in proposed. | 16:48 |
| ScottK | infinity: Thanks. | 16:48 |
| infinity | ScottK: http://people.canonical.com/~ubuntu-archive/pending-sru.html <-- Search for ia64, for instance. | 16:48 |
| infinity | Well, I'm not sure that view is "nice", per se. But it's there. :P | 16:48 |
| ScottK | That does what I need. | 16:49 |
| ScottK | Trying to make sure I retried everything from the stack of KDE packages that fail due to build-dep installablity. | 16:49 |
| ScottK | Speaking of which ... | 16:49 |
| ScottK | infinity: How does the plan to implement a rough equivalent of BD-Uninstallable for Soyuz? | 16:50 |
| infinity | It's somewhere in my TODO. Nothing specifically planned to happen. | 16:51 |
| infinity | I might get fed up and JFDI on a plane or something. Dunno. | 16:52 |
| ScottK | Please. | 16:52 |
| geser | so we just need to buy a plane ticket for infinity once around the world? | 16:53 |
| dobey | can someone with perms to upload cython do this please? "syncpackage --force -d unstable -r quantal cython" | 16:58 |
| dobey | the patch that created the ubuntu diversion is included in debian now | 16:59 |
| geser | dobey: syncpackage: Request succeeded; you should get an e-mail once it is processed. | 17:01 |
| dobey | cool, thanks geser | 17:02 |
| PaoloRotolo | Hi all! | 17:08 |
| mlankhorst | heya | 17:08 |
| mhall119 | how can I get quilt to apply a patch to a soure that is in a .orig.tar.gz? | 17:46 |
| mhall119 | do I have to manually extract it? | 17:46 |
| Daviey | mhall119: depends what you want as an outcome.. Normally the patch would be in debian/, *not* in the orig tarball | 17:47 |
| mhall119 | Daviey: my patch is in debian/patches | 17:48 |
| Daviey | if you are putting it in the orig tarball, you are repacking it.. which is not normally what we'd do | 17:48 |
| mhall119 | but it's removing a file in the source package | 17:48 |
| Daviey | mhall119: for legal reasons? | 17:48 |
| === dendro-afk is now known as dendrobates | ||
| mhall119 | for build reasons | 17:49 |
| slangasek | that smells odd to me | 17:49 |
| mhall119 | python-django-openid-auth has a Makefile for running tests, but it causes bzr builddeb to not include any of the actual code into the binary deb | 17:49 |
| slangasek | why patch out the file for build reasons, instead of patching the build system to DTRT? | 17:50 |
| Daviey | sounds like a bad import of upstream into bzr | 17:50 |
| Daviey | or bad 'make' | 17:50 |
| mhall119 | it *is* a bad make | 17:50 |
| mhall119 | the Makefile isn't used to build the source | 17:50 |
| slangasek | so is the problem that you're using dh, dh_auto_build is invoking make when it shouldn't? | 17:51 |
| Daviey | mhall119: can you post a bzr branch? | 17:51 |
| mhall119 | but when it's there, the setup.py seems to be ignored | 17:51 |
| slangasek | right | 17:51 |
| slangasek | so you need to edit debian/rules to tell it the right way to build the package | 17:51 |
| slangasek | rather than patching the upstream source | 17:51 |
| mhall119 | Daviey: lp:django-openid-auth | 17:51 |
| mhall119 | slangasek: okay, I currently have for debian/rules: | 17:52 |
| mhall119 | #!/usr/bin/make -f | 17:52 |
| mhall119 | %: dh $@ --with python2 | 17:52 |
| mhall119 | with proper formatting, of course | 17:52 |
| mhall119 | which works fine when the Makefile isn't there | 17:52 |
| mhall119 | http://paste.ubuntu.com/1003370/ is the contents of Makefile | 17:53 |
| slangasek | mhall119: dh $@ --with python2 --buildsystem=python_distutils | 17:53 |
| slangasek | mhall119: should give preference to setup.py over the Makefile | 17:55 |
| slangasek | mhall119: contents should be ignorable, with the above debian/rules tweak :) | 17:55 |
| mhall119 | yup, that did it, thanks for the help slangasek and Daviey | 17:57 |
| dasKreech | Hello can I get some help with a USB ethernet adapter? | 18:19 |
| dasKreech | I've loaded the driver for it (I think) but it resets everytime I get an IP address which also happens to be a recent NM bug | 18:20 |
| dasKreech | how can I debug if it's the driver causing the issue? | 18:20 |
| dobey | dasKreech: you want #ubuntu for help | 18:21 |
| dasKreech | I was told to ask here but ok | 18:21 |
| hallyn | hm, someone re-pushed the libvirt, and it built? I assume.... but i didn't re-push | 18:25 |
| bdmurray | @pilot in | 18:47 |
| === udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurray | ||
| hyperair | dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libc.so.6 (used by debian/libtinyxml2-0.0.0/usr/lib/x86_64-linux-gnu/libtinyxml2.so.0.0.0). | 18:57 |
| hyperair | weird, what's up wit hthat error? | 18:57 |
| slangasek | hyperair: implies you're missing /var/lib/dpkg/info/libc6:amd64.{shlibs,symbols} | 19:01 |
| hyperair | slangasek: yeah, i thought so too, but they exist. | 19:01 |
| slangasek | hmm | 19:01 |
| === dendrobates is now known as dendro-afk | ||
| hyperair | i'm checking to see if dpkg-shlibdeps is looking for the non-multiarch path | 19:01 |
| stgraber | smoser: can you have a look at bug 1003595? | 19:01 |
| ubottu | Launchpad bug 1003595 in resolvconf (Ubuntu) "resolvconf 1.63ubuntu14 upgrade error: /etc/resolv.conf isn't a symlink, not doing anything" [Undecided,New] https://launchpad.net/bugs/1003595 | 19:02 |
| stgraber | (not really a bug) | 19:02 |
| slangasek | if it's not really a bug, why looking at it? :) | 19:02 |
| smoser | utlemming, ^ | 19:03 |
| smoser | utlemming did some things to deal with that symlink i think when it first started causing build issues. | 19:03 |
| stgraber | slangasek: because it's not a resolvconf bug but the cloud stuff is apparently removing the /etc/resolv.conf symlink and replacing it by a static file | 19:03 |
| smoser | (when you added resolvconf, stgraber ) | 19:03 |
| stgraber | slangasek: which is "allowed" but shouldn't be the recommended way of doing it, even less so on an official ubuntu image | 19:03 |
| smoser | but i dont remember exactly, only that we did have build failures, as a result of it. | 19:04 |
| stgraber | smoser: yeah, it took a few weeks to get all the possible build scripts to deal with it properly | 19:04 |
| stgraber | smoser: though most of them now use a static resolv.conf at build time, then move the symlink back to place before finishing the build. It looks like the one for the cloud stuff doesn't | 19:05 |
| stgraber | which effectively disables resolvconf completely... | 19:05 |
| slangasek | stgraber: right - so it's a bug, just not a resolvconf bug, gotcha | 19:07 |
| smoser | we need to fix that in the images for sure. | 19:08 |
| stgraber | smoser: what package should I assign that bug to? | 19:10 |
| smoser | stgraber, its just "ubuntu" | 19:12 |
| hyperair | slangasek: aha, i had some garbage at the bottom of /var/lib/dpkg/info/shotwell.list for some reason. | 19:13 |
| stgraber | smoser: ok, anyone in particular to assign it to? utlemming? | 19:13 |
| smoser | stgraber, yeah. | 19:18 |
| geser | cjwatson: as you did the last proper merge of fuse (before I became TIL for it with a FTBFS fix), do you have time to review/sponsor the current merge? bug #1003613 | 19:23 |
| ubottu | Launchpad bug 1003613 in fuse (Ubuntu) "Merge fuse 2.9.0-1" [Undecided,New] https://launchpad.net/bugs/1003613 | 19:23 |
| bdmurray | bryceh: you modified the description in bug 887806 - is that manual or automatic? do they end up getting filled out? | 19:50 |
| ubottu | Launchpad bug 887806 in wxmaxima (Ubuntu Precise) "wxmaxima is not in the 'open with' nautilus menu" [Undecided,Confirmed] https://launchpad.net/bugs/887806 | 19:50 |
| === nxvl is now known as inxvl | ||
| bryceh | bdmurray, manual | 19:52 |
| === inxvl is now known as nxvl | ||
| bdmurray | and is the intent for the debdiff adder to modify the description with test case etc? | 19:54 |
| bdmurray | cnd: in theory ginn will be updated in quantal making the patch in bug 769959 unnecessary right? | 20:25 |
| ubottu | Launchpad bug 769959 in ginn (Ubuntu) "accumulate property is undocumented" [Wishlist,Triaged] https://launchpad.net/bugs/769959 | 20:25 |
| SpamapS | [578849.820024] [Hardware Error]: Machine check events logged | 20:25 |
| SpamapS | run roh | 20:25 |
| cnd | bdmurray, ginn is going to be removed from main | 20:25 |
| cnd | and we aren't going to support it any more | 20:26 |
| cnd | if you want to help develop it and fix issues, please feel free to contribute, but it's essentially a community project now | 20:26 |
| barry | xnox: are you sure the transition tracker is getting updated correctly? i removed egenix-mx-* from the spreadsheet but it's still showing up as a level 1 dependency | 20:52 |
| Laney | that is the problem with manual lists | 20:52 |
| barry | yeah, but i thought he had it set up to pull automatically from the googledoc | 20:53 |
| barry | maybe not tho | 20:54 |
| Laney | nope | 20:54 |
| Laney | i'm not sure the transition tracker is suitable for this if you need it to be dynamic | 20:55 |
| slangasek | barry, Laney: maybe it would be a good idea to sunset the spreadsheet (which has to have manual status updates) in favor of the transition tracker? | 21:00 |
| slangasek | or is the transition tracker itself configured awkwardly right now? | 21:00 |
| cjwatson | geser: OK | 21:04 |
| cjwatson | (modulo kind of falling asleep now) | 21:04 |
| Laney | slangasek: no, not really. Whoever just needs to be added to the ~ubuntu-transition-trackers team. | 21:04 |
| Laney | as long as the spreadsheet isn't tracking anything more than the transition tracker does | 21:05 |
| Laney | like notes. | 21:05 |
| cjwatson | Which it kind of is right now, isn't it | 21:05 |
| cjwatson | ? | 21:05 |
| Laney | not seen it | 21:06 |
| barry | yeah, the spreadsheet does have useful notes | 21:06 |
| Laney | we could just put barry in the team so that he can update the .ben file | 21:07 |
| Laney | cjwatson: ^ ? | 21:07 |
| barry | we could always move the useful notes (i.e. not the "unknown" bits ;) to the blueprint | 21:07 |
| cjwatson | sure | 21:08 |
| cjwatson | Done | 21:09 |
| barry | let see if i can push an update | 21:10 |
| geser | cjwatson: no hurry, it would be probably better when you are more awake when reviewing this as I hope I got the postinst merged sanely and as fuse changed from an init script (which we drop) to udev rules (which I assume we should drop too), it might be good if someone double-checks that dropping it is correct. | 21:10 |
| bdmurray | I'm looking at bug 965772 and the upstream mutt bug has a 2nd patch which fixes the issue. However, the first incorrect patch was included in debian. So what is the right way to add the good patch to the package or should I just let debian handle it? | 21:11 |
| ubottu | Launchpad bug 965772 in mutt (Ubuntu) "mutt-org crashed with SIGSEGV" [Medium,Confirmed] https://launchpad.net/bugs/965772 | 21:11 |
| cjwatson | geser: oh ow right | 21:12 |
| geser | bdmurray: both, for a SRU we should replace the wrong patch with the good one and for quantal wait on Debian (or go ahead now and merge later as we already have Ubuntu delta) | 21:17 |
| bdmurray | geser: but replacing the contents of the patch is correct? | 21:18 |
| geser | bdmurray: yes, but you can also drop the old patch and include the new one with a different name (makes probably the review easier as reading a diff of a diff isn't fun) | 21:20 |
| bdmurray | geser: great, thanks1 | 21:21 |
| barry | Laney, cjwatson update pushed | 21:25 |
| === salem_ is now known as _salem | ||
| === deboroh is now known as elleuca | ||
| LinuxAdmin | hello guys | 21:55 |
| LinuxAdmin | I'm an experienced c# developer | 21:55 |
| bdmurray | @pilot out | 21:55 |
| === udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| LinuxAdmin | I hold love to start developing for ubuntu and debian | 21:56 |
| LinuxAdmin | I hold, I mean | 21:56 |
| LinuxAdmin | oh my god, I don't know what's happening with my keyboard | 21:57 |
| LinuxAdmin | I want to experience to contribute with bug correction | 21:59 |
| LinuxAdmin | can I get some help in this channel if I have some questions? | 21:59 |
| slangasek | LinuxAdmin: welcome! if you mean fixing bugs in Ubuntu, definitely - that's what the channel's here for | 22:00 |
| LinuxAdmin | I have a lot to read, I don't make development in C for a long time, although I'm an experienced developer | 22:02 |
| LinuxAdmin | but that was my favorite language at the high school time | 22:03 |
| LinuxAdmin | I know motu is passing for a lot of changes and it seems easier to contribute | 22:05 |
| LinuxAdmin | i would love to start contributing for ubuntu and get deeper again in C language | 22:06 |
| SpamapS | LinuxAdmin: There are some C# programs still around in Ubuntu, so you can use your knowledge there too. :) | 22:12 |
| LinuxAdmin | SpamapS, your talking about mono project, right? | 22:13 |
| SpamapS | LinuxAdmin: yes, 'apt-cache rdepends mono-runtime' shows quite a few packages | 22:13 |
| SpamapS | f-spot .. banshee.. | 22:13 |
| LinuxAdmin | I've read a few months ago that mono project was end of line | 22:14 |
| LinuxAdmin | is it still under development? | 22:14 |
| ajmitch | yes, mono is still being developed | 22:15 |
| LinuxAdmin | maybe it's a good way to go, in my case | 22:16 |
| LinuxAdmin | but I think I'm more interested about C language on Linux environment | 22:17 |
| LinuxAdmin | I'm going to read developer help pages on ubuntu website | 22:17 |
| LinuxAdmin | thank you for answer | 22:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!