=== _salem is now known as salem_
=== salem_ is now known as _salem
[05:54] <pitti> Good morning
[05:54] <Unit193> Howdy.
[05:54] <pitti> infinity: hm, maybe; I was hoping we could avoid requiring an init system in every chroot, but if that' an actual issue we may still go that way
[05:54] <pitti> infinity: but wouldn't that mean that we need to promote systemd and systemd-sysv to essential too?
[05:55] <pitti> then we could just as well do that for systemd-sysv and keep skipping "init"
[05:55] <pitti> we don't really need "init" as we don't want to support multiple init systems at the same time
[05:55] <pitti> speaking of which, something utterly broke systemd boot yesterday
[05:55] <pitti> Laney: ^ I now get this as well
[05:55] <pitti> so yay reproducability
[05:56] <infinity> pitti: essential isn't a closed set.
[05:56] <infinity> pitti: If it was, you'd be in a world of pain with libraries.
[05:57] <pitti> oh, right
[05:57] <pitti> so we might just need to bump some package priorities
[05:57] <infinity> pitti: The point of 'init' being essential in Debian while the init systems aren't is to make sure you have one, but not require any specific one.  We may as well follow suit to keep the delta low in spirit, even if our "init" only has one dep.
[05:58] <infinity> pitti: And upstart has been transitively Essential for ages anyway.
[05:58] <pitti> so that would pull it in again in chroots
[05:58] <infinity> pitti: We're not really changing the status quo here.
[05:59] <pitti> right, it would just have been a slight improvement
[05:59] <infinity> pitti: "again"?  You have magic chroots without init?  I don't.
[06:00] <infinity> Oh, wait, maybe that was fixed in vivid and my chroots are dirty.
[06:01] <infinity> Oh, or even as far back as trusty?
[06:01] <pitti> no, my schroots do have /sbin/init -> upstart
[06:01] <infinity> Clearly, I'm behind the times.
[06:01] <infinity> pitti: But they don't have to.
[06:01] <pitti> no, I can purge upstart just fine
[06:01] <pitti> infinity: I created them before we juggled the sysvinit bits
[06:02] <infinity> So, that's really just a failure on mk-sbuild's fault for creating chroots that are too fat. :P
[06:02] <infinity> Oh, or a failure on my/your part for copying old chroots to new series'...
[06:03] <infinity> At least I'm not entirely insane, upstart was transitively Essential in precise.
[06:05] <infinity> pitti: So, okay.  Hrm.  I think it's not an awful goal to want a chroot without init if we don't actually need it.  But I'm then back to the drawing board on how you force an upgrade. :P
[06:05] <infinity> pitti: And if Debian's okay with this init->initsystem Essential bit, I don't suppose it hurts terribly to follow suit.
[06:06] <pitti> infinity: yes, it's nothing I'd spend an undue amount of time on; as you say, it's not a regression
[06:06] <infinity> pitti: We could drop it after 16.04, perhaps.
[06:06] <pitti> right
[06:06] <infinity> pitti: Well, it's a regression from trusty, where upstart is removable.
[06:06] <infinity> pitti: But also, I doubt many people care.
=== kickinz1|afk is now known as kickinz1
[06:09] <infinity> pitti: Anyhow, first step is to see if apt will give you the right sort of love.  Rebuild 'init' with Essential: yes, and swap the dep from upstart to systemd-sysv, toss it in a local repo, and see what damage it inflicts.
[06:12] <pitti> infinity: right; yesterday I just  tried with swapping the seeds around, which fortunately already DTRT (assuming that ureadahead gets fixed, which I'm working on)
[06:13] <pitti> upgrading utopic to vivid plus https://launchpad.net/~pitti/+archive/ubuntu/systemd works
[06:13] <infinity> pitti: Assuming we don't obtusely drop any of Debian's sysvinit compat, this also gives downstreams like Mint a simple "change one package" approach to swapping init systems, if they so feel the urge.
[06:13] <pitti> infinity: yeah, or ubuntu touch :)
[06:13] <infinity> pitti: Sure, swapping seeds works if you have minimal installed. :)
[06:13] <pitti> infinity: it doesn't work with current vivid's ureadahead, so this was still an useful exercise
[06:14] <infinity> pitti: So, yeah, I'd try the local Essential init and upgrading a non-minimal (err, very minimal?) chroot and see if apt does the correct magic.
[06:14] <infinity> I'm pretty sure it does, though.
[06:14] <pitti> yep, I'll try that too
[06:14] <infinity> I think that's how I ended up with 'init' in some chroots in the first place, before we un-essentialled it. :P
[06:14] <pitti> infinity: yes, my chroots don't have ubuntu-minimal installed
[06:16] <infinity> pitti: And once we're sure V->V and U->V work, the next is T->V, and maintaining that upgrade path all the way to 16.04.  Whee.
[06:17] <infinity> pitti: By which time, I assume someone will have released a better init system, and 16.04 will be using the no-longer-cool systemd.
[06:17] <pitti> infinity: yay, congrats to 14.04.2, just saw the announcement
[06:17] <pitti> infinity: openrc, clearly
[06:18] <infinity> pitti: I have high hopes for uselessd, if they have enough motivation and time to live up to their mission statement.
[06:18] <infinity> pitti: So, less about "new and better" and more about "a fork that doesn't annoy me as much".
[06:19]  * pitti off IRC to some laptop boot testing
=== kickinz1 is now known as kickinz1|afk
=== kickinz1|afk is now known as kickinz1
[07:32] <dholbach> good morning
[07:49] <didrocks> ricmm: rsalveti: hey, mind updating us once you are awake on the bluez5 situation?
[08:50] <jamespage> Laney: can I get your opinion on https://bugs.launchpad.net/precise-backports/+bug/1422417 please?  its not going to conform with the typical backports process.
[08:50] <ubottu> Launchpad bug 1422417 in Precise Backports "ceph radosgw needs mod-proxy-fcgi for apache 2.2" [Undecided,New]
[09:04] <geser> pitti: Hi, re my boot problem with systemd as default: do you have an idea why the initram complains with "/init: line 307: chroot: not found" (also for line 325) before the kernel panic?
[09:05] <pitti> geser: hm, that does sound relevant indeed; it might call chroot to resolve symlinks or so; sorry, firefighting right now, could you please add that info to the bug report?
[09:06] <ogra_> why would there be a chroot call in the /init script
[09:06] <pitti> well, obviously geser's has one
[09:06] <ogra_> oh, yeah, i see it
[09:07] <ogra_> checktarget="$(chroot ${rootmnt} readlink ${checktarget})"
[09:07] <ogra_> geser, fyi /usr/share/initramfs-tools/init is that script :)
[09:11] <Laney> jamespage: possibly - is there a sane upgrade path to newer releases?
[09:12] <jamespage> Laney: good point - lemme take a think at that
[09:14] <jamespage> Laney: for 14.04 the separate package would be superceeded by the module provided in apache2-bin
[09:14] <jamespage> Laney: so we would need an associated SRU fix into 14.04 to deal with upgrades
[09:14] <Laney> jamespage: as long as the packaging makes that happen cleanly
[09:14] <Laney> I think it's plausible
[09:15] <Laney> I'd like ScottK's thoughts
[09:15] <jamespage> Laney: ack - we'd make that part of the testing plan
[09:22] <ricmm> greyback: what was the reason to have qtmir acquire wakelocks? I know I proposed it, but now I forgot :)
[09:22] <ricmm> didrocks: hey, the update is that we still dont have it fully woking on the touch kernels, sadly
[09:23] <ricmm> working real hard on it
[09:23] <greyback> ricmm: need to keep the wakelock until the app was SIGSTOPPed, so it could clean up. Sometimes cpu clocked down before app had cleaned up
[09:23] <didrocks> ricmm: I hope we'll get a FFe for it, keep us posted
[09:24] <ricmm> greyback: got it, so unrelated to music-app's lifecycle
[09:24] <ricmm> salveti's bug confused me, as that logic is handled by media-hub
[09:25] <greyback> ricmm: it might be as music app lifecycle excepted, the wakelock is always held
[09:25] <ricmm> ah right of course
[09:25] <ricmm> because the ->suspend() never goes
[09:25] <greyback> yeah
[09:26] <ricmm> greyback: should probably move the logic to still have the suspend() be called and the QTimer fired
[09:26] <ricmm> and then check there for the lifecycle exception -> no signal/no sigstop
[09:36] <geser> ogra_: do you know by chance if chroot is a build-in or a real binary in the initramfs?
[09:37] <ogra_> geser, i guess it is busybox ... but i think the erorr is that chroot doesnt find one of the variable contents in that line
[09:37] <ogra_> how does your init= on the kernle cmdline look like ?
[09:39] <geser> ogra_: I've installed systemd-sysv (making systemd the default in my vivid VMware VM) and without a init= it doesn't boot at all (kernel panic with attempt to kill init), but it boots with init=/lib/systemd/systemd
[09:39] <geser> ogra_: see bug #1421117
[09:39] <ubottu> bug 1421117 in systemd (Ubuntu) "fails to boot with "Attempted to kill init" in VMWare, absolute /sbin/init symlink does not work" [Undecided,Incomplete] https://launchpad.net/bugs/1421117
[09:40] <ogra_> well, that command tries to call "readlink /lib/systemd/systemd" inside the mounted rootfs
[09:42] <ogra_> i assume it is either unhappy that /lib/systemd/systemd isnt a link or your rootfs isnt mounted at all at this point
[09:43] <ogra_> both conditions should be catched by the above "if" line though ... which is weird
[09:53] <geser> ogra_: I booted earlier today with break=bottom and tried "chroot /root readlink /sbin/init" which returned /lib/systemd/systemd
[09:53] <ogra_> funny
[10:02] <pitti> geser: ah, that chroot is for "Work around absolute symlinks"
[10:03] <pitti> $ zcat /initrd.img |cpio -tv | grep chroot
[10:03] <pitti> -rwxr-xr-x 141 root     root            0 Oct 27 09:40 sbin/chroot
[10:03] <pitti> geser: does that exist for you too? (it should be a hardlink to busybox)
[10:08] <geser> pitti: nope, the only output I get is "105117 blocks"
[10:08] <pitti> a-ha!
[10:09] <ogra_> heh, how did that get there
[10:09] <geser> pitti: I just did a test with "break=init" and checked the output from env: init=/bin/sh doesn't look what I'd expect
[10:10] <pitti> ogra_: you mean how did it not get in there?
[10:10] <pitti> ogra_: "it" == /sbin/chroot; or do you mena something else?
[10:11] <ogra_> oh, i thought it was supposed to be busybox's by default
[10:11] <pitti> ogra_: it is, it's a hardlink to /bin/busybox
[10:12] <pitti> or at least supposed to
[10:12] <ogra_> /usr/share/initramfs-tools/hooks/busybox
[10:12] <pitti> look at the link count (141)
[10:13] <pitti> geser: do you have BUSYBOX=y in /etc/initramfs-tools/initramfs.conf? and busybox-initramfs installed?
[10:13] <ogra_> i see it removing the klibc one but not create a link to the busybox binary
[10:14] <pitti> ogra_: yeah, but it seems to work for everyone else
[10:14] <ogra_> nor does it copy_exec the one from the filesystem
[10:14] <geser> pitti: yes to both (BUSYBOX=Y and installed)
[10:16] <geser> /usr/lib/initramfs-tools/bin/busybox lists chroot in its functions and according to that hook a real chroot binary should get removed (if I read it right)
[10:17] <ogra_> geser, right, it removes the klibc one
[10:18] <ogra_> but it doesnt create a /bin/chroot link to busybox
[10:18] <ogra_> which i aways thought is required to make use of a busybox module
=== Laney changed the topic of #ubuntu-devel to: Archive: open, feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[10:19] <geser> I can use chroot in the busybox shell (break=bottom or break=init)
[10:19] <cjwatson> y
[10:19] <ogra_> (but i'm probably wrong)
[10:20] <cjwatson> oops, wrong window
[10:20] <ogra_> geser, right, and pitti obviously has a sbin/chroot above
[10:20] <ogra_> so the link must come from somewhere else
[10:21] <geser> the if check in that hook should fail for pitti otherwise there shouldn't be a chroot binary
[10:22] <pitti> geser: right, but in the busybox shell chroot probably counts as a builtin
[10:22] <pitti> check with "type"
[10:22] <pitti> and not /sbin/chroot, as that doesn't exist for you
[10:22] <ogra_> pitti, but where does sbin/chroot in your unpacked initrd come from then ?
[10:22] <pitti> I don't know
[10:23] <ogra_> ubuntu@localhost:~$ grep -r chroot /usr/share/initramfs-tools/*
[10:23] <ogra_> /usr/share/initramfs-tools/hooks/busybox:	rm -f ${DESTDIR}/bin/chroot
[10:23] <ogra_> /usr/share/initramfs-tools/init:			checktarget="$(chroot ${rootmnt} readlink ${checktarget})"
[10:23] <pitti> I have it on my laptop and my VMs, and lots of other folks are booting with systemd-sysv
[10:23] <pitti> so I'm certanly not the only one
[10:23] <ogra_> there is nothing that puts it in place
[10:24] <pitti> so if explicitly adding it to /usr/share/initramfs-tools/hooks/busybox helps, then let's do that
[10:24] <pitti> it certainly sounds plausible to explicitly link it
[10:25] <pitti> geser: to double-check, could you add that to /usr/share/initramfs-tools/hooks/busybox, then sudo update-initramfs -u, and check that it works then?
[10:25] <pitti>         ln -s busybox ${DESTDIR}/bin/busybox
[10:25] <pitti> err
[10:25] <pitti>         ln -s busybox ${DESTDIR}/bin/chroot
[10:26] <pitti> # ... and we need readlink to support /sbin/init to be a symlink LP: #1351295
[10:26] <ubottu> Launchpad bug 1351295 in initramfs-tools (Ubuntu) "Boot fails if /sbin/init (or init= arg) is an absolute symlink" [Undecided,Fix released] https://launchpad.net/bugs/1351295
[10:26] <pitti> that indicates that we had to do that for another shell command for this
[10:29] <geser> with the ln call it works
[10:30] <pitti> geser: cool, thanks for testing
[10:30] <pitti> geser: I'll get that uploaded then
[10:31] <ogra_> pitti, well, i'm still curious where it comes from for people that have it
[10:31] <pitti> yeah
[10:32] <ogra_> we might clash with something if we just try to link it
[10:32] <pitti> I also have busybox-static which also has an initramfs-tools hook
[10:32] <pitti> but that's in ubuntu-standard
=== beisner- is now known as beisner
[10:36] <ogra_> well, do vmware images use -standard or just -minimal ?
[10:37] <geser> I've neither ubuntu-minimal nor ubuntu-standard installed if it matters
[10:37] <pitti> ogra_: ah, purging that indeed drops /sbin/chroot from initramfs
[10:37] <pitti> mystery solved
[10:37] <ogra_> :D
[10:51] <geser> pitti: I hope I didn't distract you from your firefighting too much
[10:51] <pitti> geser: that's ok; simple bug for a change :)
[10:52]  * ogra_ wonders if we could even call it a bug :P
[10:52] <ogra_> ubuntu without ubuntu-minimal isnt really ubuntu IMHO :)
[10:54] <pitti> ogra_: that was without ubuntu-standard
[10:57] <ogra_> ah
[10:57] <ogra_> well, geser said he has neither installed
[11:02] <geser> ogra_: but IYHO only missing ubuntu-minimal isn't really an Ubuntu anymore, you didn't say anything about a missing ubuntu-standard :)
[11:02] <ogra_> well, standard is comfort :) -minimal is ... well. the minimal set of packages making up an ubuntu system :)
[11:08] <geser> hmm, perhaps I should add an ubuntu-minimal depending on systemd-sysv instead of upstart into my PPA :)
[11:09] <ogra_> oh, systemd-sysv conflicts ?
[11:11] <geser> yes, indirectly as systemd-sysv conflicts upstart which is a dependency of ubuntu-minimal
[11:11] <ogra_> right, well, then not having it installed is indeed right in this case :)
[11:34] <LocutusOfBorg1> hi folks
[11:43] <Riddell> mhall119: I want to use €66 for pizzas for the plasma sprint so we can continue to work effectively with them
=== kickinz1 is now known as kickinz1|afk
=== _salem is now known as salem_
=== MacSlow is now known as MacSlow|lunch
[12:49] <dholbach> Riddell, the process is still the same one you used before: http://community.ubuntu.com/help-information/funding/
[12:52] <rbasak> chiluk: looking at bug 1420647
[12:52] <ubottu> bug 1420647 in ceph (Ubuntu) "Please apply nofile limit fix of ceph-osd to trusty, utopic" [Medium,Confirmed] https://launchpad.net/bugs/1420647
[12:52] <rbasak> chiluk: is this fixed in Vivid please?
[13:32] <Riddell> dholbach: I've been told I need to pre-apply now
[13:32] <dholbach> right
[13:33] <dholbach> that's what the vast majority of requests did already, ie "we're going to do X at Y and need Z"
[13:33] <dholbach> using the same request form
[13:34] <dholbach> just some time in advance, rather than afterwards
=== MacSlow|lunch is now known as MacSlow
[13:35] <dholbach> Mirv, thanks a lot for fixing the libcitygml ftbfs
[13:38] <Mirv> dholbach: eh yeah I didn't know what I got into though, since it's kind of still continuing ;) (OSG 3.2.1 migration)
[13:40] <Mirv> but progress anyway, helping is a pleasure
[13:50] <cyphermox> good morning!
[13:54] <xnox> sil2100: are you about?
=== kickinz1|afk is now known as kickinz1
[13:58] <flexiondotorg> cyphermox, Morning.
[13:58] <sil2100> xnox: hey, what's up?
[13:58] <xnox> sil2100: did you see email from pitti a while back?
[13:58] <sil2100> xnox: uh, I might have missed it by accident, what was it about?
[13:59] <pitti> the train not doing proper upload verification?
[13:59] <xnox> sil2100: citrain modifications that developer membership board wants to get implemented.
[13:59] <xnox> pitti: yeah, that.
[13:59] <sil2100> xnox, pitti: trying to find it in my e-mail, but so far I don't see it, depending how long ago that was
[14:00] <pitti> Subject: CI train upload privilege escalation [was: Upload Permissions]
[14:00] <pitti> Date: Mon, 16 Feb 2015 08:46:10 +0100
[14:01] <flexiondotorg> cyphermox, Can we try a build?
=== pgraner-afk is now known as pgraner
[14:01] <cyphermox> flexiondotorg: could you ping #ubuntu-release for this? since I don't have access, all I can do is copy your request there :)
[14:02] <sil2100> pitti: thanks, looking
[14:03] <sil2100> pitti: hm, filtering returns no results, where did you sent the e-mail to?
[14:04] <pitti> lukasz.zemczak@canonical.com
[14:04] <pitti> sil2100: I can bounce it someplace else if you want?
[14:04] <pitti> or just again to the same address?
[14:05] <sil2100> pitti: if you could send it to lukasz.zemczak@ubuntu.com
[14:05] <sil2100> Maybe this time I'll get it
[14:05] <sil2100> hm, maybe it's filtered out somewhere
[14:05] <pitti> bounced
[14:10] <pitti> sil2100: got it now?
[14:10] <ScottK> Laney: Commented in the bug.
[14:10] <pitti> sil2100: mx.canonical.com accepted it, anyway
[14:11] <pitti> sil2100: but then again, teh @c.c worked as well a few days ago..
[14:12] <flexiondotorg> cyphermox, Who could help with testing a build?
[14:12] <cyphermox> flexiondotorg: can't you?
[14:12] <cyphermox> or do you mean with starting the build?
[14:13] <cyphermox> if so, just wait for someone in the release team to be up and kick it off :)
[14:13] <flexiondotorg> cyphermox, OK.
[14:15] <sil2100> pitti: hm, still nothing ;/
[14:17] <pitti> sil2100: spam filter?
[14:23] <sil2100> pitti: yeah, found it in spam ;)
[14:23] <sil2100> Thanks! Let me read up
[14:37] <chiluk> rbasak it is fixed in vivid
[14:37] <chiluk> rbasak that's why I only submitted debdiffs for trusty and utopic
[14:50] <rbasak> chiluk: thanks. Just need to wait on the current ceph SRU to go through first then I guess.
[14:50] <chiluk> yeah..
[14:51] <chiluk> rbasak I was thinking we might want to push it through ceph stable
[14:51] <chiluk> instead and get it pulled in that way.
[14:52] <rbasak> chiluk: it's fine either way, thought I think the SRU team should be made aware of the conffile prompt issue in both cases.
[14:52] <rbasak> I don't see any particular reason to prefer one way over the other - since it's fixed in Vivid, and Ubuntu is probably the only upstart-using Ceph distribution anyway?
[14:53] <rbasak> jamespage: ^^ ceph upstart ulimit fix for Trusty and Utopic. Through a distro patch in an SRU, or through Ceph stable. Any preference? I don't suppose it really matters.
[14:54] <jamespage> rbasak, not fussed either way - but I think there is a minor point release in proposed still so this may block things a bit
[14:54] <jamespage> rbasak, I need to get that flushed through
[14:58] <rbasak> jamespage: ack
=== Guest35307 is now known as rcj
=== rcj is now known as Guest81339
[15:08] <rainbowtux> Hi all, is there somewhere a good tutorial for creating .deb packages? That seems unnecessarily hard :/
[15:17] <mdeslaur> rainbowtux: start here: http://packaging.ubuntu.com/html/
=== ubuntu is now known as Guest76382
[15:33] <caribou> Does the PlusOne maintenance team still exist ?
[15:35] <caribou> I'm looking at the FTBS for deja-dup : it builds find locally but fails on the builder
[15:36] <caribou> seems that it doesn't like the message saying that appdata-validate is deprecated
=== teward- is now known as teward
[16:08] <DaGoaty> I'm making a custom distro based on Ubuntu with an extra repo added to the disk containing my additional packages. In 14.04.1 I replaced the ubuntu-archive-keyring.gpg file in the squashfs with one which had my public gpg key added. This no longer works with the 14.04.2 disk. Is there a 'proper' way to include additional public gpg keys?
[16:28] <DaGoaty> I may have found my problem. I replaced the /usr/share/keyrings/ubuntu-archive-keyring.gpg but not /etc/apt/trusted.gpg
[16:29] <tarpman> DaGoaty: instead of modifying existing files, consider shipping an additional keyring in /etc/apt/trusted.gpg.d
[16:30] <DaGoaty> inside the squashfs?
[16:30] <tarpman> wherever you're currently making your changes
[16:30] <DaGoaty> okay, thanks
=== pgraner is now known as pganer-afk
=== anthonyf is now known as Guest70178
=== kickinz1 is now known as kickinz1|afk
=== pganer-afk is now known as pgraner
[20:31] <Noskcaj> Can someone please upload a no-change rebuild of nant? It's needed for nunit 2.6.3 to migrate
=== roadmr is now known as roadmr_afk
[20:34] <cjwatson> Noskcaj: monogame too, right?
[20:35] <cjwatson> (For a different reason, but still)
[20:37] <cjwatson> Noskcaj: nant done
[20:43] <cjwatson> Noskcaj: ah, monogame is harder, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765120
[20:43] <ubottu> Debian bug 765120 in src:monogame "monogame: support monodevelop 5" [Serious,Open]
[20:44] <cjwatson> and https://bugs.launchpad.net/ubuntu/+source/monogame/+bug/1400216 ... will process that
[20:44] <ubottu> Launchpad bug 1400216 in monogame (Ubuntu) "Remove from archive" [Undecided,New]
[20:46] <cjwatson> Noskcaj: OK, hopefully that'll migrate in a publisher run or two now
=== roadmr_afk is now known as roadmr
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
[23:35] <infinity> rbasak: percona-galera has that same "Breaks/Replaces where we mean Conflicts/Replaces" thing going on.
[23:40] <infinity> rbasak: And so does xtradb.  Whee.
[23:55] <rbasak> infinity: yeah. When they're all in the archive, then I can file a bug with tasks against all of them
[23:56] <infinity> rbasak: They're all in, I held my nose and accepted after the licenses and general other packaging checked out sane enough.
[23:56] <rbasak> Oooh, thanks!
[23:56] <infinity> rbasak: But wherever this unversioned Breaks/Replaces thing started in MySQL packaging land, I do hope the people responsible are being educated.
[23:57] <rbasak> I will do so.
[23:57] <rbasak> Everyone is quite happy to fix things when pointed out.
[23:57] <rbasak> It's hard to coordinate and track them though. Now that they're all in Ubuntu, Launchpad should help with it.
[23:57] <infinity> rbasak: Breaks/Replaces should always be versioned, and always used for replacing files.  Conflicts/Replaces is the construct for replacing whole packages.
[23:57] <rbasak> Every issue can just have a bug, and we can track their progress against every package.
[23:57] <rbasak> Understood.
[23:58] <infinity> I do feel like dpkg could do with a solid README on this.. Or a pointer to where Policy attempts to define it, and maybe a cleanup there.