=== pitti is now known as pitti_ [04:49] good morning [05:39] pitti_: howdy [05:39] hey jbicha, how are you? [05:40] I'm fine, staying busy :) [05:40] I was wondering about the status of https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-freerdp [05:40] maybe that's not the right blueprint... [05:41] ah, it's in the default apps one, never mind [06:54] good morning [07:00] hey didrocks [07:00] didrocks: how are you? [07:01] guten morgen pitti_ [07:02] pitti_: finding again some mobility of my neck. Not healed 100%, but way better ;) and you? [07:02] I'm glad it wasn't somethign serious [07:02] I'm quite fine, just my server isn't [07:02] still without email and IRC proxy [07:03] * pitti_ is glad about http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html still being empty [07:05] pitti_: what gets tested there ATM? [07:06] micahg: uninstallable packages in main [07:06] http://people.canonical.com/~ubuntu-archive/testing-ports/precise_probs.html is the equivalent for ports (armhf and powerpc) === korben is now known as Guest72958 [07:27] pitti_, I guess we don't really need +1 maintenance, considering that this list is always empty: [07:27] http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html [07:27] j/k [07:28] rickspencer3: we do! which other excuse do I have to play Diablo II all day? [07:28] pitti_, I can't really argue with that one [07:28] rickspencer3: our current target is bringing http://people.canonical.com/~ubuntu-archive/nbs.html to zero, FYI [07:29] pitti_, zero ftbs for the whole archive? [07:29] rickspencer3: no, that's NBS (not built from source), i. e. library transitions, package renames, etc. [07:29] rickspencer3: wendar is working on FTBFS, but fixing them all will still take a bit [07:29] (James and I will join at some point) [07:32] I se [07:32] e [07:45] that's great to see the +1 team working that well! Well done pitti :) [07:46] heh, thanks :) [07:46] didrocks: it's fun to spend hours to make the reports much more useful and then driving them to zero so that you don't see the improvements :) [07:46] well, http://people.canonical.com/~ubuntu-archive/component-mismatches.svg is still useful [07:48] pitti_: indeed, it's quite ironic in the end :) [07:48] oh didn't see this svg [07:49] and it's linked to bugs, excellent! [07:49] didrocks: the .txt variant now has links to MIR bugs and (MAIN) tags as well [07:50] pitti_: great, and if we file a MIR, we need to file this file as well or is there a parser looking for bugs where MIR team is subscribed? [07:50] didrocks: the latter [07:51] didrocks: it looks for source package bugs where ~ubuntu-mir is subscribed [07:51] nice :) [07:51] and for demotion? [07:51] like nothing depending on foo, needs to be pushed back to universe [07:51] how it is represented in the graph? [07:51] didrocks: the .txt file has some more details, it shows all MIR bugs (and their title unless it starts with '[MIR]', the .svg only shows the first found bug [07:51] didrocks: the graph only has source/binary universe->main [07:52] ok [07:52] the rest is just a list, so the .txt file is fine [07:52] I don't see how to usefully represent this in a graph [07:52] so, the txt for the rest :) [07:52] but source/binary -> main is the one which requires most work and MIRs, etc. [07:52] yeah, that was my question [07:52] seems you have fun writing those tools :) [07:52] oh, absolutely! [07:52] nice improvments [07:53] didrocks: it also bothered me that _probs.html only said "foo is uninstallable" and then showing you the finger and say "go figure why" :) [07:53] didrocks: http://people.canonical.com/~ubuntu-archive/testing-ports/precise_probs.html shows the improvements there [07:54] openoffice.org-common: Depends: libreoffice-common (>= 1:3.3.0~rc4-2) but it is not going to be installed [07:54] so then, we need to look at libreoffice-common [07:54] didrocks: http://people.canonical.com/~pitti/tmp/precise_probs.html [07:54] didrocks: that was a snapshot when I was working on it, showing it better [07:55] didrocks: right, testing-ports is now just buildd lag for armhf's gcc and libreoffice FTBFS [07:55] didrocks: that's why it shows pending builds [07:55] oh, excellent! [07:55] didrocks: so on the pitti/tmp one, you see why libxsltc-java-gcj is uninstallable [07:55] the dependency version doesn't match, and i386 FTBFS is why [07:56] exactly what we need as well in soyuz :) [07:56] and, the why is before the text, [07:56] writing those tools is so much fun :) [07:57] uploading a gazillion packages for actually fixing the problems less so, but driving lists to zero is still satisfying [07:57] indeed, I can imagine :) [07:58] nice work, I think precise_probs.html will be really useful when a buildd is failing [08:08] hi [08:10] bonjour baptistemm [08:11] hey pitti_ [08:13] salut baptistemm [08:24] salut didrocks, comment ca va ? [08:24] baptistemm: j'ai presque retrouvé la mobilité de mon cou, donc ça va beaucoup mieux merci! et toi? [08:24] (process:15905): mc-plugins-DEBUG: loader.c:167 g_module_open (/usr/lib/mission-control-plugins.0/mcp-account-manager-goa.so, ...) = /usr/lib/mission-control-plugins.0/mcp-account-manager-goa.so: failed to map segment from shared object: Permission denied [08:25] thanks apparmor [08:30] I'm a little bit tired, but apart from that I'm okay [09:04] hello [09:08] rickspencer3: in case you get another heart attack when looking at jenkins: it's bug 894768 again [09:08] Launchpad bug 894768 in linux "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument " [High,In progress] https://launchpad.net/bugs/894768 [09:10] hey there [09:10] hi seb128, pitti_ [09:11] bonjour seb128 [09:11] hey rodrigo_ [09:11] seb128: ca va? [09:11] hey pitti, rodrigo_ [09:11] pitti_, I'm good thanks [09:11] dang pitti_ I hope we get that one fixed soon [09:11] I would love to see a block of green [09:11] rickspencer3: see current #u-devel [09:11] rickspencer3: hope just raised a lot :) [09:12] :) [09:12] pitti_, what do you think about uploading the new glib to the archive today? [09:12] seb128: we got through most of the poppler transition now, just http://cgit.freedesktop.org/poppler/poppler/commit/?id=149b7fec4 really sucks [09:12] we can't let precise start working great [09:12] lol [09:12] we need to break some stuff to keep rickspencer3 busy :p [09:12] seb128: do we have a solution for the empathy crash? [09:12] seb128, what would you think about working with the QA team to do some kind of pre-archive test of the new glib? [09:12] pitti_, it was missing schemas in the .install, the new glib abort on those again, ken fixed in precise yesterday [09:13] maybe they could do a special spin and run some tests to see what breaks? it would be a nice experiment [09:13] it would certainly make an excellent showcase for the "staging area/run all tests against that", but I don't think we have it yet [09:13] seb128: aah [09:13] nice [09:13] seb128: no objection from me then, it works quite well here [09:13] rickspencer3, glib has a pretty solid testsuit and we did team test this update on the ubuntu-desktop, but I would be happy to land that work to qa for next time ;-) [09:13] seb128: it'll cause some packages to FTBFS due to the stricter #include requirement, of course [09:14] pitti_, well, better earlier than later... [09:14] seb128, right, the purpose would be to see if we can find what else breaks with the new glib [09:14] rather than finding it out by breaking things in the development release, finding it out by testing [09:14] seb128: yes, absolutely [09:14] seb128: well, armhf has 4k packages to go, you can get a partial rebuild test still :) [09:15] micahg: right :) [09:15] rickspencer3, who do you recommend I talk to in the qa team about that? [09:15] seb128, hmmm, gema? [09:15] ok, will do that [09:15] seb128, it may be as pitti says, a good idea, but they are not ready [09:16] rickspencer3, thanks for the suggestion [09:16] rickspencer3, yeah, I assume it's non trivial and that will not be set for it yet but let's see [09:16] rickspencer3, it might be a good case to push that forward and get the infrastructure starting [09:16] good morning everyone [09:16] hey chrisccoulson, how are you? [09:17] hey chrisccoulson [09:17] hi seb128, i'm good thanks, how are you? [09:17] hi pitti_ [09:17] pitti_, I'm good thanks [09:17] pitti_, is there many softwares using that poppler gdk api? [09:18] seb128: http://people.canonical.com/~ubuntu-archive/nbs.html the libpoppler-glib6 section [09:18] seb128: that's pretty much it, we did all the rest [09:18] seb128: plus gimp (but that got fixed yesterday) [09:19] seb128: so we'll need to copy that removed code into these 5 packages instead, plus change the build system to check for/link against cairo, etc. [09:19] and gdk [09:19] pitti_, nothing left in main, great, do you work on universe as well? [09:19] seb128: yes, everything [09:19] seb128: james and I will deal with it [09:19] oh ok, I though focus was main [09:19] but fair enough ;-) [09:20] seb128: it wasn't meant as a blame towards you, just towards upstream ;) [09:20] pitti_, seems fedora took the opposite approch [09:20] they just dropped some of those stuff as "not maintained upstream" [09:20] seb128: no, the gimp patch is just like that [09:21] it basically copies the function into the patch [09:21] seb128: oh, you mean for some other packages; yes, dropping them is still an option of course [09:23] pitti_, thanks for making pdftoopvp building with Poppler 0.18.x. I have upstreamized your patch now. [09:23] tkamppeter: oh, thanks [09:23] tkamppeter: the one I applied directly should be fine for upstream; the debian/patches/ubuntu/poppler one can go there as well, if they only want to support 0.18 [09:27] pitti_, I have applied the changes on the pdftoopvp source code upstream. What do you mean with debian/patches/ubuntu/poppler? There is no such directory in the CUPS package. [09:27] tkamppeter: debian/patches/ubuntu/poppler-0.18.patch [09:27] tkamppeter: it's conditionally applied in Ubuntu only, as Debian still has poppler 0.16; and this change only works with 0.18 [09:28] pitti_, I have "bzr pull"ed the CUPS package and do not have a file named debian/patches/ubuntu/poppler-0.18.patch. [09:28] tkamppeter: whoops, sorry; please pull again [09:30] pitti_, do I have to apply this patch upstream, too, so that pdftoopdf actually builds upstream? [09:30] s/upstream/under Poppler 0.18.x/ [09:30] tkamppeter: that's the tricky question; without the patch, it builds with poppler 0.16; with the patch it builds with poppler 0.18 [09:31] tkamppeter: 0.18 is the current stable version, so I'd say "apply it", but I don't know whether upstream has some target dependency versions there [09:31] that stuff is easier with poppler-glib, you have feature test macros [09:32] but with pure poppler you'd need to do your own version test macros; but probably not worth the trouble [09:32] pitti_, another reason to prefer Ghostscript as PDF renderer. [09:33] tkamppeter: heh, fun; a few years ago it was the other way round :) [09:52] seb128: ok, that libgksu crash is easy [09:52] it's so glazingly obvious, I wonder how upstream could have missed that [09:52] *phew* [09:52] pitti_, is it new? I had the impression libgksu didn't change in years [09:52] or is the precise toolchain exposing an old bug in some way? [09:53] seb128: well, it was aggravated by the -Wformat-security changes [09:53] anyway, rather uninteresting, I'll just upload the fix [09:54] pitti_, \o/ [09:54] oh, it's in pkg-gnome, nice [09:54] let's see how much we can merge/sync [09:55] OMG we have millions of patches [09:55] lool merged it just a week ago [09:55] with all sorts of bling [09:56] ok, I'll just fix it in both places then [09:58] pitti_, yeah, gksu and libgksu are crazy [09:58] pitti_, btw did you tag your poppler-0.18 bugs in the bts or do you have a list? [09:58] seb128: not tagged [09:58] pitti_, I think I will send my 0.18 update debdiff to the bts today, I would like to point also to your patches [09:58] seb128: in fact, 6 of the bug creations are still in my local postfix queue [09:59] seb128: but I CC'ed the original bug which asks for the update [09:59] the debian maintainer was mostly blocked on having fixes available, I think we have enough to get things moving [09:59] HRMPF #(*$#*($ need my server back [09:59] pitti_, ok, I will send my poppler debdiff and say that you will follow with pointers to the fixes you work on [09:59] pitti_, works for you? [09:59] seb128: once my server comes back, the remainign bugs will be sent, and we have a complete list [09:59] seb128: sounds good [09:59] pitti_, excellent, thanks [10:00] with some luck they pick it up and we can be back in sync for most of those soon [10:09] seb128: would you mind sending a mail to the team that I'm without email since yesterday afternoon? I hope they'll fix it today [10:09] seb128: to platform@ perhaps [10:09] not that anyone waits for somethign urgent [10:16] pitti_, ok [10:16] RAOF: nice that David accepted your .owner polkit patch; that should make the colord package much nicerr [10:17] seb128: merci [10:19] pitti, poppler-0.18 patch is upstreamized now, too. [10:19] pitti_, ^^ and thanks for fixing this. [10:20] tkamppeter: great, thanks [10:25] seb128: FYI, retracers are back since this morning [10:25] pitti_, I noticed from my emails, thanks ;-) [10:25] ah, you people who get emails.. [10:25] . o O { how long can it take to re-sync a RAID!?! } [10:27] lol [10:27] pitti_, it took less time for the launchpad librarian :p [10:28] pitti_, email sent to the platform team about your lack of email btw [10:29] cheers [10:29] I mean, not having mails has probably doubled my productivity yesterday and today :) [10:29] but I do miss it for some things [10:29] and I'll spend half a day to catch up [10:29] pitti_, btw did you see that I Cced you on an g-s-d,suspend,hotkey bug recently? [10:30] where recently is a week or so [10:30] seb128: bug 868358 [10:30] yes, I did [10:30] Launchpad bug 868358 in gnome-settings-daemon "hibernate key (fn + 12) triggers suspend on ThinkPad X200s" [Low,Confirmed] https://launchpad.net/bugs/868358 [10:30] ok, great [10:30] it's yelling at me every day [10:30] ;-) [10:30] I just wanted to make sure you noticed it, I think xev is the wrong tools there [10:31] I figured you know better about those stuff and that it will be easier to ask you rather than trying to figure it [10:32] seb128: yes, that's fine [10:35] seb128: was a nice opportunity to update https://wiki.ubuntu.com/Hotkeys/Troubleshooting to the current world :) [10:35] pitti_, ;-) [10:35] nice [10:36] didrocks: who would be a good person to look at bug 897829? [10:36] Launchpad bug 897829 in compiz "Assigning shortcut to "Move window to workspace X" doesn't ever take effect" [Low,New] https://launchpad.net/bugs/897829 [10:37] pitti_: otp, one sec [10:37] didrocks: (not urgent at all) [10:37] pitti_: I guess it's a duplicate, but yes please, assign it to me, I'll dup it then [10:37] didrocks: okay, thanks [10:39] pitti_, we should depends on python-gi rather than python-gobject for stuff that use gtk3 right? [10:39] seb128: correct [10:39] same for -cairo-gi [10:39] pitti_, you might want to send an email about it to ubuntu-devel (desktop?) about it (once you get emails back) [10:40] pitti_, I noticed because I follow up #debian-gnome mostly, I guess it would be an "useful to know" for others [10:41] seb128: I actually thought we already fixed most of the rdepends; but yes, I'll do that [10:42] pitti_, well, I just ran into the question for rhythmbox yesterday [10:42] totem is likely in the same case (will look at it today) [10:42] pitti_, thanks [10:45] +/c [10:47] seb128: mail composed, waiting in my local postfix now :) [10:48] ;-) [11:02] seb128: bug-buddy was removed in Debian: ROM; obsolete, dead upstream; Debian bug #645646 [11:02] Debian bug 645646 in ftp.debian.org "RM: bug-buddy -- ROM; obsolete, dead upstream" [Normal,Open] http://bugs.debian.org/645646 [11:03] seb128: we have a newer version (2.30.0+dfsg-1 vs. 2.31.92-0ubuntu4) [11:03] but still, should we follow suit? [11:03] I think yes, but would like to confirm [11:03] no rdepends [11:07] * pitti_ kills it, will take the bullets [11:07] has anyone used brasero to burn a video dvd? it doesn't seem to work here at all :( [11:08] pitti_, yes please drop it [11:08] rodrigo_, no, but pedro keeps complaining it's a buggy software where nothing works [11:09] right [11:09] last time I built a dvd, it was 1 year and half ago to watch something on my parent's TV without having the right cable? [11:09] s/\?/…/ [11:09] I've used it to burn isos several times, but not dvds [11:09] didrocks, did you ever get to see the movie or did you run into bugs and gave up as well? ;-) [11:10] :) [11:10] seb128: it worked. In fact, this software was working quite well few years ago, I even dumped k3b from my machine at the time :) [11:10] ;-) [11:11] is it brasero which is bugged or the underline I-dont-remember-the-rename-for-legal-reason command line tool? [11:11] nah, it always says 'please replace the disc with a supported CD or DVD', on a DVD+RW I just blanked in brasero :( [11:12] oh, should try k3b... [11:12] yeah, I think it's using the same tool… [11:12] ouch, http://asserttrue.blogspot.com/2011/12/how-google-is-quietly-killing-firefox.html ;) [11:12] didrocks, the same command line tool, you mean? [11:12] ah, my memory, I don't remember the name… [11:12] didrocks, growisofs, cdrecord? [11:13] ... wodim [11:13] wodim [11:13] probably growisofs for DVDs [11:13] which is a rename from… [11:13] cdrecord :) [11:13] indeed \o/ [11:13] but anyway, everytime I tried brasero it failed on me :( [11:14] that is to say, BOTH times in the past three years or so [11:16] rodrigo_, " oh, should try k3b..." <- wrong response [11:16] rodrigo_, "oh, should debug brasero"! [11:16] ^ good response [11:16] (just completing ;)) [11:17] :) [11:17] seb128, I'll do it :) [11:21] chrisccoulson, lot of conspiracy theories on google and firefox recently ;-) [11:21] seb128, yeah [11:22] although, i see similar issues with gmail too, which is why i never keep it open in a tab anymore (and google plus) [11:22] firefox leaks like a sieve if i keep those open ;) [11:22] chrisccoulson, well don't worry by the end of the year we will have firefox 25 and it will solve all the world issues [11:22] ;-) [11:22] lol [11:22] now you're trolling! :-P [11:23] * didrocks waits on firefox 31 [11:23] what, me? come on! [11:23] can't wait for it! [11:23] chrisccoulson, is it fixed yet?! [11:23] ;-) [11:23] by which time, the whole world will have switched to chrome, all sites will be using native client and we'll be back to the good 'ole days of the 90's ;) [11:23] see, i can troll too :) [11:24] ;-) [11:25] chrisccoulson, should bug #871568 be assigned to you btw? [11:25] Launchpad bug 871568 in thunderbird "Removing spam does not clear flag" [Low,Triaged] https://launchpad.net/bugs/871568 [11:25] yeah, probably [11:25] doing that [11:25] perhaps all thunderbird bugs should be assigned to me ;) [11:25] actually [11:25] that's a bad idea :) [11:25] lol [11:25] indeed, not the best idea for you [11:26] seb128: see, we are back to a minitel world. French were right! [11:26] chrisccoulson, but that one is reproducible by some people, including a responsive co-worker, so you might have a chance to get enough infos to fix it ;-) [11:26] i desparately need to fix some of these bugs once i've got this current work finished [11:26] chrisccoulson, still fighting the debug symbols stuff? [11:26] seb128, yeah, i really want to get this one working, so we can figure out some of the thunderbird crashes [11:28] hopefully that will be finished this week now i've got a more sane way of doing it, which doesn't involve forking breakpad :) [11:48] seb128: yay glib fallout :) http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html [11:48] seb128: (should only be transient, provided that glib i386 builds soon)_ [11:49] time for lunch, bbl [11:49] pitti_, doesn't look good [11:49] seb128: I think it's just because glib amd64 is already published while i386 is still building [11:50] pitti_, if you can kill the i386 build and retry it it would be good [11:50] looks like test suite hang [11:50] seb128: I can't [11:50] pitti_, no, the i386 build doesn't look good [11:50] it's stucked in the gdbus test where it often hangs [11:50] it will stay there until timeout [11:50] i.e until the builder decide it's stucked and stop the build [11:50] pitti_, who can? lamont? [11:51] seb128: see #u-devel, pinged him [11:51] pitti_, thanks [11:51] lunch here as well [11:51] see you in a bit [11:52] seb128: so that's not just because of the old kernel, is it? it also happens in PPAs [11:53] do we have new kernels in ppa? dunno [11:53] desrt said he would welcome a stacktrace of an hanging build [11:53] but lunch for now [11:53] bbiab [11:53] seb128: yes, PPAs are running the precise kernel AFAIK, it's a full VM [11:55] pitti_, the ppa builders seems to run on 2.6.24-30-xen [11:55] ricotz: right, the hosts, but I thought the guests were full VMs with the dev kernel? [11:56] pitti_, i dont think so [11:56] otherwise it wouldnt happen ;) [11:57] ricotz: ah, ok; thanks for the info, that explains some things [11:58] pitti_, i think it needs to be >= 2.6.26 to solve this [11:58] ricotz: once we release precise, the buildds will hopefully be upgraded soon :) [11:59] pitti_, i was hoping they would at least use lucid ;) [12:04] ricotz: confirmed, zirconium is an old xen machine running hardy [12:04] ricotz: but I am told it's going to be upgraded RSN :) [12:06] pitti_, i see, so hoping it will be soon [12:06] otherwise you can disable this specific test (like i have done in my ppa) [12:17] ricotz, I will refrain from comments on "if you sent your work to the team we wouldn't have to debug the same issues that you already debugged in your ppa while testing" today ;) [12:18] didrocks, is compiz "default" profile supposed to launch unity? [12:18] seb128: no, the default is the one not launching unity [12:18] the ubuntu profile is launching unity [12:18] hum ok, I wonder what's going on there [12:19] seb128, hehe [12:20] didrocks, I fixed gnome-session yesterday, the "classic GNOME" was broken since Oneiric, but with the fix "classic GNOME" starts unity for me, not sure why (tested with a guest session started from lightdm, the .xsessionerrors indicates it's using the "default" profile and not the unity one" [12:20] seb128: that's weird, I'll try to have a look, but right now, I'm racing rebuilding everything and updating packaging because dx break the ABI dee [12:21] * didrocks needs more hours in a day [12:21] didrocks, don't bother, there is no hurry there, I will try on my 10v, I was just checking that it was supposed to run without unity [12:21] seb128: normally, it shouldn't, that's really weird that it happens in a fresh profile [12:21] didrocks, it's possible that over years I hacked my box to workaround a bug and broke "default" [12:21] possibly [12:21] so don't bother with that [12:21] ok :) [12:22] didrocks, thanks [12:22] thanks to you, keep me in touch [12:22] will do [12:47] ricotz, do you have a vcs for your ppa work? [12:49] seb128, i have a local bzr repo which contains all packaging stuff of the ppa, nothing mergable though [12:50] ricotz, it's not merging which interest me, it's having an easy command line access to see your refreshed patches and packaging changes with an history [12:50] ricotz, like the ppa only diff with the previous version so it's useless to know what you did to i.e glib or gtk compared to Ubuntu [12:50] especially that you don't keep the changelogs [12:50] ricotz, what I mainly want is not having to refresh the patches you already refreshed or adapted to new versions [12:51] it would also be good if there was a way to see what issues you run into and how you solved it [12:52] seb128, hmm, i can see your need for it [12:53] ricotz, other suggestions on how to track your packaging fixes are welcome [12:53] there might be a better way, I'm just trying to figure how to look at your work without dgetting a new git snapshot every time [12:54] i think dget the ppa package and debdiff and filter for debian folder [12:54] should work === MacSlow is now known as MacSlow|lunch [12:57] ricotz, well that forces me to "open a webbrowser on your ppa, get the url, dget a full tarball each time, unpack it, diff it, and figure myself what you did and why since you don't keep changelogs entries from previous uploads" [12:57] ricotz, I can as well redo the work myself directly in most case, it's as much time wasted than having to go through the manual getting, review and understanding what you did and why [12:58] ricotz, can I convince you to add some context or summary of your changes in the changelog or in the patches you add maybe though? ;-) [13:00] seb128, absolutly right, currently i dont have "support" to add changelog entries, i was thinking about something simliar like we have for the xorg-edgers ppa [13:02] i think gtk has quite some changes :\ [13:11] seb128, on the other hand, i am trying to keep the changes quite minimal [13:12] ricotz, right, I'm sure that as you said the new gtk will need some patches refreshes and tweaks [13:13] ricotz, it would be nice if your work was useful to us as well [13:13] like right now I'm unsure if I should try to figure what you did and why or if I should just redo it myself because that's maybe easier [13:15] seb128, i am merging/syncing the ubuntu/debian packaging regulary which doesnt result in huge changes [13:16] ricotz, well still a changelog or something with the summary would be useful [13:16] like you commented some tests in glib and I would have no clue why if I didn't ask you [13:16] seb128, some changes are natty/oneiric/ppa specific too (like debhelper, c4>c1) [13:16] seb128, right [13:17] it's hard to know if you did something as a workaround, if you discussed the issue with upstream, etc [13:17] seb128, i will try to add some changelog insertion process [13:17] so it's not easy to know if we want to copy what you did without knowing the rational behind the change ;-) [13:17] ricotz, thanks! [13:17] ricotz, or at least a one liner comment in the .patches or rules changes [13:18] like #ppa hack: don't break on new symbols for git snapshots [13:18] or #upstream knows issue, discussed on IRC [13:18] or #workaround for some hangs [13:18]