[00:00] <jdong> hmm the box is a Mac Pro with FB-DIMMs and reproduces on 3 different machines
[00:00] <penguin42> ok ok, so it doesn't have to be a hardware bug!
[00:00] <jdong> aptitude doesn't say anything
[00:00] <jdong> but I still don't see the packages
[00:01] <jpds> jdong: You have a HTTP cache between you and your mirror?
[00:01] <jdong> actually....
[00:01] <jdong> clearing /var/lib/apt/lists fixed it
[00:01] <jdong> weird.
[00:01] <jdong> oh.
[00:01] <jdong> OH.
[00:01] <jdong> stupid if-modified-since handling?
[00:02] <jdong> the livecd was built using us.archive.u.c as a mirror, and then the final installed system chose mirrors.kernel.org
[00:02] <jdong> I guess technically an older file hasn't been-modified-since the newer file
[00:02] <jdong> *headdesk*
=== dendro-afk is now known as dendrobates
[00:15] <mrmonday> Is this the right pace to ask about issues when trying to package apps for ubuntu, or is there a channel better suited to that?
[00:17] <penguin42> mrmonday: There is also a #ubuntu-packaging (I think it's ing) and #ubuntu-motu where the stuff in the universe set of repos get done (I only hang out here occasionally)
[00:21] <mrmonday> Thanks, I'm in there now :)
[00:37] <bdrung> Riddelll: ping
[01:15] <TheMuso> ScottK: Thanks, that was a quick decision. :)
[01:21] <ScottK> TheMuso: I figure that's high on your list of packages not to leave broken.  Not much of a risk.
[01:21] <TheMuso> ScottK: Yeah this is true, thanks again.
[01:58] <TheMuso> c
=== lifeless_ is now known as lifeless
=== SolidLiq is now known as solid_liq
=== SolidLiq is now known as solid_liq
[05:11] <ipatrol> hello
[05:31] <ipatrol> I was thinking about configuration GUIs
[05:35] <hv> What happened to the gnome-terminal? Alt+Backspace does not delete a word anymore. (Alt is not being sent)
[05:36] <ipatrol> open xev and see what happens when you press that keystroke
[05:38] <hv> it's not from xev. xterm works fine. it is as if the gnome-terminal equivalent of "XTerm*metaSendsEscape: true" is no longer the case
[05:39] <hv> do Alt+b, Alt+f, Alt+backspace, etc work for you in gnome-terminal?
[05:40] <ipatrol> I'm not on a desktop computer
[05:42] <hv> ipatrol: I see.
[05:42] <ipatrol> If you gave me ssh or vnc access I could try :D
[05:43] <hv> there was an upgrade (2.30.2 -> 2.31.90) on Aug 17.
[05:44] <ion> Does esc-backspace work?
[05:44] <hv> yes
[05:44]  * micahg thinks there's a bug open already for that
[05:46] <hv> umm, how can I search for bugs for package $PACKAGE in launchpad? PACKAGE name is what aptitude tells me.
[05:48] <hv> there is "search in one project", but apparently project-name is not exactly the same as package-name
[05:48] <StevenK> hv: First, you need the source package name, which you can find from aptitude (under Source: ), and then https://bugs.launchpad.net/ubuntu/+source/<source package name>
[05:51] <hv> StevenK: "aptitude show" apparently does not have a section "Source". How can I get that automatically?
[05:51] <StevenK> hv: If one isn't present, it's the same as what you searched for
[05:53] <StevenK> hv: Actually, no, I'm wrong. aptitude show doesn't display it, but apt-cache show does
[05:57] <ipatrol> yeah, apt-cache
[06:04] <hv> StevenK: thanks.
[06:05] <hv> function view-package-info () { if PKGSOURCELINE="$(apt-cache show "$1" | grep '^Source:')"; then PKGSOURCE=${PKGSOURCELINE/Source: /} ; else PKGSOURCE="$1" ; fi ; xdg-open "https://bugs.launchpad.net/ubuntu/+source/$PKGSOURCE"; }
[06:05] <hv> :D
[06:56] <geser> hv: see bug #619754 for the "Alt" key issue
[06:56] <ubottu> Launchpad bug 619754 in vte (Ubuntu) "alt + backspace; alt+d etc. don't work anymore" [High,Fix released] https://launchpad.net/bugs/619754
[07:32] <mdke> morning. Can someone tell me whether, if a source package builds more than one binary package, and a change is made so that a particular binary package is no longer built, does any additional act need to be taken to remove that binary package from the archive?
[07:35] <geser> no, it will appear on in the NBS list and get removed by the archive admins if no reverse (build-)dependencies are left
[07:38] <mdke> geser: excellent, thanks for the information
[07:39] <mdke> is there an easy way to tell what dependencies exist?
[07:40] <geser> apt-cache rdepends for dependencies but for build-dependencies you need use grep-dctrl on the Source file
[07:41] <mdke> geser: thanks. I'm sure there aren't any build-dependencies in this case
[07:41] <geser> or you simply check http://people.canonical.com/~ubuntu-archive/NBS/ once you dropped the package
[07:41] <mdke> looks like no rdepends either :)
[07:42] <mdke> geser: thanks again
[07:45] <dholbach> good morning
[07:45] <mdke> morning dholbach
[07:45] <dholbach> hey mdke
[07:46] <bilalakhtar> good morning dholbach
[07:46] <dholbach> hey bilalakhtar
[07:48] <pitti> Good morning
[07:48] <pitti> erh, where did my control key go?
[07:48] <pitti> seems it's acting like another windows key
[07:50] <nigelb> heh
[07:50] <nigelb> pitti: Nice way to start the morning.
[07:51] <nigelb> Good morning :)
[07:51] <mok0> What GNU autotools files do you guys include in your brz repo? Do you have all files at the "make dist" level, or do you not include the autogenerated files?
[07:52] <mok0> Of course, you need "./configure" etc. for bzr-builddeb to work
[07:52] <mok0> But that could be restricted to the package branch
[07:53] <mok0> Do you consider the casual user, that might do a bzr branch lp:xxxx ; configure; make ?
[07:56] <pitti> mok0: for upstream projects, definitively don't include autotools stuff; it's just noicse
[07:57] <pitti> mok0: some packaging branches do that, when they import upstream tarballs instead of being a real branch from upstream trunk
[07:57] <mok0> pitti, so, in your opinion, I should have the GNU autotools only in the "ubuntu" branch? (The one that includes debian/ )
[07:58] <pitti> mok0: depends on the packaging style
[07:58] <pitti> but upstream branches with autoconfiscation (or more generally, with anything that gets autogenerated) are pretty annoying
[07:58] <geser> pitti: is it bug 619754 or a different issue?
[07:58] <ubottu> Launchpad bug 619754 in vte (Ubuntu) "alt + backspace; alt+d etc. don't work anymore" [High,Fix released] https://launchpad.net/bugs/619754
[07:59] <pitti> geser: ah, I did have a libvte upgrade yesterday afternoon indeed; trying
[07:59] <mok0> pitti, unless you have configure and friends, bzr-builddeb doesn't work
[07:59] <pitti> mok0: so your packgaging branch derives straight from trunk?
[07:59] <mok0> pitti: yes
[07:59] <mok0> pitti, it includes trunk, and adds debian/
[08:00] <mok0> pitti, but I could also add m4/
[08:00] <pitti> mok0: you could call autotools in debian/rules; if you use cdbs, you can just set the flags, otherwise call autoreconf before ./configure
[08:00] <pitti> geser: hmm, no new vte in this morning's dist-upgrade
[08:00] <mok0> pitti: yeah, that is a possibility...
[08:01] <pitti> ah, vte failed to build on amd64
[08:02] <mok0> pitti: thanks for your input
[08:03] <pitti> robert_ancell: I'll give back vte on amd64 once glib has published (it just finished building on amd64
[08:04] <robert_ancell> pitti, thanks
[08:07] <mdke> I believe that the ubuntu-docs and gnome-user-docs packages both used to have a "XS-Vcs-Bzr" field, but they seem to have disappeared somehow. Are these still in use generally?
[08:14] <pitti> mdke: it's now called Vcs-Bzr:
[08:16] <pitti> ah, keyboard sanity! thanks geser
[08:18] <mdke> pitti: thanks. That seems not to be there either, I'll readd it. No idea how it got lost
=== dholbach_ is now known as dholbach
[08:34] <kblin> hi folks
[08:35] <kblin> I take it's too late to get driver support for a wifi dongle into 10.10?
=== Tm_Tr_ is now known as Tm_Tr
=== Nicke is now known as 18VABDTK5
=== dholbach_ is now known as dholbach
=== maxb_ is now known as Guest7510
=== jmarsden is now known as Guest11851
=== amitk is now known as amitk-afk
[10:57] <cjwatson> pitti: upstream autoconfiscation> disagree, just for the record.  (I'm not really trying to persuade you, but I want it to be on the record that not all upstreams act the same way.)
[10:57] <pitti> cjwatson: hm, I've never seen one anyway
[10:57] <cjwatson> anything I maintain for starters :)
[11:00] <pitti> cjwatson: that makes upstream commits pretty noisy, though?
[11:00] <cjwatson> Yes, exactly as noisy as I want them to be
[11:00] <cjwatson> I want to be able to see what changes the autotools are making, and having the generated files in revision control is an excellent way to do that
[11:00] <cjwatson> it's a good way to spot mistakes
[11:01] <pitti> cjwatson: hmkay :) seems I just haven't stumbled over one of those upstream VCSes then
[11:01] <cjwatson> man-db, ubiquity (OTTOMH)
[11:32] <soren> cjwatson: That only really works for single-person projects, doesn't it?
[11:33] <soren> cjwatson: Or do you just have a rule that only one person gets to change those things or do you mandate a very specifically versioned toolchain?
[11:33] <cjwatson> soren: you do have to be reasonably close in autotools versions but that's often the case anyway.
[11:34] <cjwatson> soren: this way, at least it's explicit what random set of stuff the principal maintainer was using.
=== amitk-afk is now known as amitk
[11:35] <soren> cjwatson: True. I'm with pitti, though. I don't recall stumbling upon vcs with autogenerated stuff in it that wasn't a mistake.
[11:35] <cjwatson> it's certainly popular to not include it, but I thought it worth mentioning that the practice is not universal
[11:35] <soren> cjwatson: I acknowledge you do things differently, though, and I how it can be valuable.
[11:35] <soren> right.
[11:35] <soren> Good to know.
[11:36] <chrismsnz> hey guys, do you know where i can find the people that run the xorg edgers ppa?
[11:36] <cjwatson> in fact, if you do it very consistently, it avoids the need for a tarball branch sitting in between the upstream vcs and the packaging branch
[11:36] <cjwatson> which can be convenient
[11:36] <nigelb> chrismsnz: #ubuntu-x perhaps?
[11:36] <chrismsnz> nigelb, ty
[11:43] <jibel> pitti, hello, sru bug 595116, apache 2.2.14-5ubuntu8.1 failed to build in lucid, who should I warn ?
[11:43] <ubottu> Launchpad bug 595116 in apache2 (Ubuntu Lucid) "ssl "error reading the headers"" [Undecided,Fix committed] https://launchpad.net/bugs/595116
[11:44] <pitti> jibel: that already happened; the package was pulled from -proposed, and we asked zul to reupload
[11:44] <jibel> pitti, okay thanks.
=== MacSlow is now known as MacSlow|lunch
=== tuos_ is now known as tuos
=== Guest7510 is now known as maxb
=== maxb is now known as Guest10006
[12:22] <doko> seb128: when is the next set of gnome updates expected, and when do you expect the archive be stable again after these are uploaded?
[12:22] <doko> Riddell: when is the next set of kde updates expected, and when do you expect the archive be stable again after these are uploaded?
[12:23] <seb128> doko, what is not stable and what do you try to figure?
[12:23] <seb128> doko, is that for an archive rebuild? cd builds?
[12:23] <doko> trying to figure out a good time to take a snapshot for a rebuilt test
=== ryanakca_ is now known as ryanakca
[12:25] <seb128> doko, next GNOME changes are august 30th
[12:25] <ogra> doko, the archive is in its best condition right before a milestone
[12:25] <seb128> doko, I don't expect GNOME to be unstable until then
[12:26] <doko> seb128: ok, thanks
[12:27] <bilalakhtar> okay, I need an FFe for a new upstream release, should I file 2 separate bugs (one for sponsorship, other for FFe) or merge 'em ?
[12:27] <geser> merge them
[12:28] <geser> it's easier to look at only one bug
=== maxb_ is now known as maxb
=== lamont` is now known as lamont
[12:33] <Riddell> doko: probably next big KDE update September 9th
[12:39] <webczat> Hey.
[12:39] <webczat> What usb-creator requires? i want to install it on gentoo and then create ubuntu liveusb pendrive
[12:39] <webczat> version 0.2.22
[12:43] <webczat> i'm extremely annoyed about that freeze!
[12:46] <ricotz> seb128, hi
[12:47] <webczat> :/
[12:48] <seb128> ricotz, hey
[12:57] <webczat> wrrrrrrr
[12:57] <webczat> is that freeze something normal?
[13:19] <webczat> hmm, 0.2.20 also does not work
[13:19]  * webczat curses
=== dendrobates is now known as dendro-afk
=== zul_ is now known as zul
=== dendro-afk is now known as dendrobates
=== thekorn is now known as thekorn_
=== doko_ is now known as doko
=== MacSlow|lunch is now known as MacSlow
=== JayFo is now known as JFo
[14:15] <webczat> does anyone have a clue why usb-creator freezes?
=== dendrobates is now known as dendro-afk
=== seb128_ is now known as seb128
=== LucidFox is now known as lucidfox
=== sconklin-gone is now known as sconklin
[14:49] <webczat> ?
[14:54] <Pici> webczat: This isn't a support channel.  Please use #ubuntu for that.
=== doko__ is now known as doko
=== bjf[afk] is now known as bjf
=== doko_ is now known as doko
[15:16] <cnd_> seb128, I'm working on adding udebs to mtdev and utouch-grail
[15:16] <cnd_> I've pushed packaging commits to enable udebs to lp
[15:16] <cnd_> would you be able to review the changes?
[15:17] <seb128> cnd_, sorry but I'm over busy atm, I've at least 5 changes in my queue and 3 person who pinged me
[15:17] <seb128> cnd_, can you drop me an email with the references?
[15:17] <seb128> cnd_, I might review that later otherwise it will be tomorrow
[15:17] <cnd_> seb128, is there someone else you could recommend who could help?
[15:17] <seb128> or maybe somebody else there can do reviews
[15:17] <cnd_> I can also drop an email
[15:18] <cnd_> I just don't want to overburden you :)
[15:18] <seb128> well let's say that's the right channel
=== 18VABDTK5 is now known as Nicke_
[15:18] <seb128> but I suggest opening bugs with the change and subscribing sponsors
[15:19] <cnd_> seb128, ok, I'll open bugs like you suggest
[15:20] <cnd_> should I subscribe just yourself, or some team, or?
[15:20] <dholbach> cnd: subscribe ubuntu-sponsors
[15:20] <cnd_> dholbach, ok, thanks!
[15:21] <cjwatson> cnd_: udebs> why?
[15:21] <cnd_> cjwatson, mtdev and utouch-grail handle gesture recognition, and they siphon events from xserver-xorg-input-evdev in Maverick
[15:22] <cnd_> (right now they siphon events off from a new *-gevdev package because we don't have udebs so we can't merge changes into the real *-evdev)
[15:23] <cnd_> we want to just have a patch against evdev for Maverick, but if we do that right now, the evdev udeb will also depend on mtdev and utouch-grail
[15:23] <cnd_> and the installer will burst into flames :)
[15:24] <cnd_> cjwatson, I'm sure you're busy too, but would you have a moment to check my udeb changes?
[15:24] <cnd_> np if you can't
[15:30] <cjwatson> cnd_: what installer do you have in mind that uses evdev?
[15:31] <cjwatson> cnd_: (noting that we don't actually use graphical d-i at the moment)
[15:31] <cjwatson> cnd_: I don't object to adding the udebs, just surprised that it's a priority
[15:31] <cjwatson> cnd_: happy to look at your changes
[15:38] <robbiew> cjwatson: noticed bug 620293, bug 620302, and bug 620338 all created in the last 24hours....could there be a possible bug in initramfs-tools (Lucid)...or is this a common error message for multiple failures
[15:38] <ubottu> Launchpad bug 620293 in initramfs-tools (Ubuntu) "package initramfs-tools 0.92bubuntu78 [modified: usr/sbin/update-initramfs] failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/620293
[15:38] <ubottu> Launchpad bug 620302 in initramfs-tools (Ubuntu) "package initramfs-tools 0.92bubuntu78 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/620302
[15:38] <ubottu> Launchpad bug 620338 in initramfs-tools (Ubuntu) "package initramfs-tools 0.92bubuntu78 [modified: usr/sbin/update-initramfs] failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/620338
[15:39] <cjwatson> robbiew: I'll look, but it's a very common message
[15:40] <cjwatson> and it's a "something broke" kind of thing
[15:40] <robbiew> cjwatson: ack..then no worries
[15:40] <robbiew> I thought it might be
[15:45] <cjwatson> robbiew: two undebuggable problems with no useful information attached; one problem which is odd but isolated
[15:45] <cjwatson> all different
[15:46] <robbiew> cjwatson: cool...thnx
[15:46] <robbiew> and sorry to take 5min of your life that you will never get back :P
[15:47] <cnd_> cjwatson, sorry, didn't notice your messages
[15:48] <cnd_> cjwatson, I was under the assumption that the graphical installer was running through X
[15:48] <cnd_> if not, then this may all be a moot point :)
[15:49] <cnd_> or perhaps you're meaning that the ubiquity installer image isn't built from udebs?
[15:49] <cjwatson> cnd_: so, there are two graphical installers.  one (which we may use for something in the future, perhaps the server) uses udebs.  the other (which we use for the desktop today) does not.
[15:49] <cjwatson> cnd_: don't let me stop you adding the udebs - we will probably want them eventually and we might as well add them while they're uppermost in our minds
[15:49] <cjwatson> cnd_: it just won't affect ubiquity in any way
[15:49] <cnd_> ok
[15:50] <cnd_> at least it lowers the priority for now :)
[15:51] <cnd_> cjwatson, you can review the changes at:
[15:51] <cnd_> http://bazaar.launchpad.net/~chasedouglas/mtdev/packaging/revision/45
[15:51] <cnd_> http://bazaar.launchpad.net/~chasedouglas/utouch-grail/packaging/revision/42
[15:52] <cnd_> I suppose we should do the udebs anyways because we don't want to break anyone wishing to play with graphical d-i
[15:52] <cjwatson> cnd_: you can drop debian/libmtdev1.shlibs
[15:52] <cjwatson> right
[15:53] <cnd_> cjwatson, what about the shlib deps checking though?
[15:53] <cjwatson> and likewise you can drop debian/libutouch-grail.shlibs.  the rest is fine
[15:53] <cnd_> the symbols file doesn't know anything about udebs
[15:53] <cjwatson> cnd_: dh_makeshlibs will create that shlibs file all by itself
[15:53] <cjwatson> keep the --add-udeb stuff
[15:54] <cnd_> cjwatson, it didn't seem to do it for me...
[15:54] <cjwatson> let me check
[15:54] <cnd_> I'll check again
[15:54] <cjwatson> certainly there is no need to hardcode the udeb: line in .shlibs
[15:54] <cjwatson> the point of --add-udeb is to add that line
[15:54] <cnd_> ok, I'll try without the line to see
=== deryck is now known as deryck[lunch]
[15:55] <cjwatson> E: libmtdev1-udeb udeb: udeb-contains-documentation-file usr/share/doc/libmtdev1-udeb/
[15:56] <cjwatson> E: libmtdev1-udeb udeb: udeb-contains-documentation-file usr/share/doc/libmtdev1-udeb/buildinfo.gz
[15:56] <cjwatson> that's probably a dh_buildinfo bug
[15:56] <cjwatson> works fine without the .shlibs file
[15:57] <cjwatson> heh, how about I just purge dh-buildinfo here, since you don't build-depend on it :)
[15:57] <cnd_> cjwatson, you're right
[15:57] <cnd_> I think I was looking in the wrong place before
[15:57] <cnd_> thanks for the review!
[15:58] <cjwatson> yep, it's fine now that I've purged dh-buildinfo.  I'll go report that bug
=== doko_ is now known as doko
[16:26] <barry> james_w: ping
[16:26] <james_w> hi barry
[16:27] <barry> james_w: hi.  do you have a few minutes to walk through a udd scenario with me?
[16:27] <james_w> of course
[16:28] <barry> thanks!  okay, background: i'm trying to get subversion to build against py27.  it currently fails because of some test failures...
[16:28] <barry> first i did: bzr init-repo svn; cd svn; bzr branch lp:ubuntu/subversion
[16:28] <barry> then bzr branch subversion py27
[16:28] <barry> cd into py27 and loomified that branch
[16:29] <barry> bzr create-thread disable-tests
[16:29] <barry> (note: the "fix" is currently to just disable a handful of failing tests)
[16:29] <barry> hack, hack, hack, build, test, commit change, bzr record
[16:29] <barry> push to lp
[16:30] <barry> okay, so now i have a branch that builds, as a two-thread loom.  so far so good?
[16:30] <james_w> yes
[16:31] <barry> cool.  so, subversion uses quilt and now i want to turn that patch in a thread into a quilt patch.  i've tried a couple of things that haven't succeeded, but i guess let's start with what you'd recommend as the next step?
[16:31] <james_w> something like "bzr diff -r thread: | quilt import disable_tests" would be my guess
[16:32] <barry> james_w: should i do the import in the trunk thread?  in a pristine branch?  doesn't seem right to do it in the thread that contains the source change
[16:33] <james_w> barry: is it quilt v3?
[16:33] <james_w> or v1 + quilt?
[16:33] <barry> james_w: 'what-patch' just says 'quilt'
[16:33] <james_w> cat debian/source/format
[16:34] <james_w> ENOENT means v1
[16:34] <barry> 1.0
=== SpamapS_ is now known as SpamapS
[16:36] <james_w> barry: ok, so you could either do the import in a thread without your changes, or do the import in the same thread, and then back the changes out of the working tree
[16:36] <james_w> I don't think it particularly matters, you will end up with the same tree state, so it just depends what you want in the history
[16:37] <barry> james_w: i think i see what you mean.  thanks, let me try that...
[16:41] <barry> james_w: this is interesting.  i tried creating a thread between trunk and disable-tests, called 'quilt'.  then i did a bzr diff -rthread:disable-tests -rthread:trunk and it returned an empty diff.  the same command returned the full diff only if i'm in the disabled-tests thread
=== doko_ is now known as doko
[16:42] <james_w> barry: I don't think two -r does what you would expect there
[16:42] <james_w> try -r thread:trunk..thread:disable-tests
[16:42] <barry> james_w: oh right.  so many diff command syntaxes ;)
[16:43] <barry> james_w: that did the trick.  thanks, let's see if quilt will import the diff
[16:44] <james_w> barry: you might need a --prefix=a/:b/ to get it at the natural -p level for quilt
[16:44] <cjwatson> quilt has -p options itself
[16:44] <barry> james_w: quilt import doesn't read from stdin, so i think i need to save it to a file first
[16:45] <cjwatson> so you can use -p0
[16:45] <cjwatson> also, quilt import -p0 /dev/stdin :-)
[16:45] <james_w> barry: huh
[16:45] <barry> cjwatson: yep, just saw that.  i think what tripped me up about trying to use edit-patch is that it *doesn't* take a -p argument, so edit-patch ends up rejecting the patch
[16:45] <james_w> nice :-)
[16:45] <barry> cjwatson, james_w: indeed... let's see!
[16:46] <barry> ah, wait, i need to push all patches first before i import though, right?
[16:48] <barry> cjwatson: that works, except that the patch file is called stdin.  probably not quite right :)
[16:49] <cjwatson>            -P patch
[16:49] <cjwatson>                Patch filename to use inside quilt. This option can only be used when importing a single patch.
[16:52] <barry> cjwatson, james_w: very nice. i think i have a workflow now.  i'm going to write this up, and will send you a link.  thanks for your help!
=== deryck[lunch] is now known as deryck
[16:52]  * barry might even try to automate this
[16:53] <james_w> barry: I'd love a command in bzr-builddeb to turn revisions in to a patch
[16:53] <barry> james_w: you and me both!  do you have a suggestion for a command name?
[16:53] <james_w> like turning a bzr revisionspec for diff in to something for edit-patch
[16:54] <james_w> import-deb-patch for a pretty poor first thought :-)
[16:54] <barry> james_w: i probably have to hack edit-patch to take -p and -P
[16:54] <barry> :)
[16:54] <james_w> barry: it may be easier to get bzr to generate patches that don't need -p
[16:54] <barry> james_w, cjwatson: oh, one other thing.  my thread included a debian/changelog entry.  i need to filter that out of my quilt patch
[16:55] <barry> james_w: yeah, but -P is required i think if you don't use a tmp file
[16:56] <james_w> ah, ok
[16:57] <barry> this has been great, thanks guys
[17:16] <SpamapS> Whats the feeling on a FFE for a package to sync changes from debian that only change the build process to run the automated testing suite? Otherwise the package is basically the same.
[17:18] <cjwatson> SpamapS: what's the feature requiring an exception?
[17:18] <cjwatson> syncing from Debian alone doesn't require an exception, it depends on whether it introduces new features
[17:18] <Chipaca> is there something that would build up a changelog from bzr commit messages?
[17:19] <Chipaca> not a changelog, I mean a changelog entry
[17:19] <SpamapS> libdbi-drivers (in main), the Debian Maintainer and I did considerable work to run automated tests against mysql, pgsql, and sqlite.
[17:19] <SpamapS> cjwatson: ^
[17:19] <SpamapS> cjwatson: so the feature is running the tests.
[17:21] <asac> jdstrand: are you awake?
[17:21] <jdstrand> I am
[17:21] <cjwatson> SpamapS: it's a feature in the build system I suppose, but I don't think it's a feature visible to users of the package (other than "less buggy")
[17:21] <asac> jdstrand: what else besides the bug to track qt-qws code duplication did you want?
[17:21] <cjwatson> SpamapS: so I don't think it needs an exception
[17:21] <asac> seb128: ^^
[17:21] <asac> here is the discussion now
[17:21] <cjwatson> Chipaca: more usual to do it the other way round, write the changelog as you go and use that to generate commit messages (with debcommit)
=== zyga is now known as zyga-lunch
[17:22] <SpamapS> cjwatson: I'll just requestsync then. :) Thanks!
[17:22] <jdstrand> asac: well, I'm not sure I am the gatekeeper of that bug. I just wanted to make sure that enough people were in agreement that that is the only thing we can do. someone from linaro saying they will maintain it for -security (since it is universe) and people more knowledgeable than I saying the technical issues can only be resolved with a copy copy
[17:23] <Chipaca> cjwatson: right, i want to generate the package changelog based on the individual commits made on the project itself (also in bzr)
[17:23] <jdstrand> s/copy copy/code copy/
[17:24] <cjwatson> Chipaca: usually produces rubbish output, but as you like :)
[17:24] <cjwatson> (don't know of anything; the kernel team does this with git)
[17:25] <SpamapS> james_w: http://package-import.ubuntu.com/status/libdbi-drivers.html#2010-08-07 15:12:07.002397 ... did we mess up by importing 0.8.3-1 upstream without tagging the change ?
=== zyga-lunch is now known as zyga
[17:28] <james_w> SpamapS: possibly. Is that version number (0.8.3-1-0ubuntu1) intentional? Do upstream release 0.8.3-1?
[17:29] <Riddell> asac: bug 618733
[17:29] <ubottu> Launchpad bug 618733 in Ubuntu "package qt4-qws" [Undecided,New] https://launchpad.net/bugs/618733
[17:29] <SpamapS> james_w: yes
[17:29] <james_w> SpamapS: then it's probably a bug in bzr-builddeb
[17:29] <SpamapS> james_w: though as of 0.9 they'll be moving to 0.9.0.0
[17:29] <james_w> let me look
=== al-maisan is now known as almaisan-away
[17:34] <SpamapS> james_w: let me know if I can help
[17:56] <james_w> SpamapS: so yeah, it's caused by a bug in merge-upstream
[18:00] <james_w> SpamapS: I can fix that branch, and then fix the bug as well
[18:01] <SpamapS> james_w: well I'm glad to hear that we didn't screw it up.. but sorry to put more on your plate. ;)
[18:02] <james_w> np, it's my fault for this stupid bug anyway
[18:03] <james_w> SpamapS: if you run "bzr pull lp:ubuntu/libdbi-drivers" and try again it should now work
=== almaisan-away is now known as al-maisan
[18:05] <james_w> SpamapS: let me know if that doesn't work
[18:05] <james_w> I'll fix the bug so that it doesn't happen in future
[18:06] <james_w> SpamapS: oh, if you are trying to merge a new upstream version of this package today then let me know and I'll help you workaround the bug.
[18:10] <SpamapS> james_w: no, I just noticed that it had an error in package-import
[18:10] <SpamapS> james_w: and it was uploaded to Debian today, so I wasn't sure if it was just out of sync w/ debian, or an error. Looks like both. ;)
[18:11] <SpamapS> james_w: by it, I mean a new version of the same upstream.
[18:11] <james_w> SpamapS: ok
[18:14] <SpamapS> james_w: I'll keep an eye on it as the new release is imported into lp:debian, thanks for taking a look.
=== almaisan-away is now known as al-maisan
[18:14] <james_w> np
=== astralja1a is now known as astraljava
[18:46] <canesin> Hi all, I want to help maintain an package in ubuntu .. how can I do this ??
=== dendro-afk is now known as dendrobates
[18:48] <johanbr> canesin, have a look at https://wiki.ubuntu.com/MOTU
[18:49] <canesin> Thanks
=== al-maisan is now known as almaisan-away
[18:57] <jcole> question about the livecd... i am providing remastered versions and would like to "force" encrypted home directories by default... what config would i modify to make that happen?
=== ivoks is now known as ivoks-away
[19:37] <seb128> kees, hey, could you review bug #609081?
[19:37] <ubottu> Launchpad bug 609081 in libdmapsharing (Ubuntu) "[MIR] libdmapsharing" [Wishlist,New] https://launchpad.net/bugs/609081
[19:39] <kees> seb128: sure, one sec
[19:41] <seb128> kees, thanks
[19:54] <soren> StevenK: Doing AA stuff today?
[19:55] <lifeless> soren: @5am? :P
[19:55] <soren> lifeless: Hmm.. point. :)
[20:04] <pitti> isn't it funny how lifeless proves himself wrong? :-)
[20:16] <dobey> is revu closed off now for maverick? or is it just confused at the moment?
[22:13] <james_w> SpamapS: fixed, and will be uploaded soon. Next time you do a new upstream of a package like you shouldn't have a problem. Thanks for catching the issue.
=== sconklin is now known as sconklin-gone
=== yofel_ is now known as yofel
=== dendrobates is now known as dendro-afk