[00:00] geofft: I checked for updates and patches and fixes. 14.04 wasn't this broke, and it had hundreds of updates in the first week or so. This has been a dead stick; no patches coming down. I am completely up to date. :| [00:00] oh, and I'm using an Intel core i5 with Intel HD 3000 graphics [00:00] If anything should not be broken, it's the Intel graphics driver :| [00:01] Bluefoxicy: keep dreaming :p [00:01] Seriously this is like when people had XP and installed Vista. I was like "ahahaha I have Ubuntu over here" [00:01] (Intel driver did break several tbefore) [00:01] and now I'm like A*<#AG *times* [00:02] Gnome keeps forgetting my keymap, so I have to go load something else and then delete it to get dvorak back [00:02] but not sure this is what's happening here [00:02] oh and then I get a pop-up dialog telling me I have multiple input methods installed and that it doesn't know what to do with my config. [00:05] do you? [00:10] (do you use multiple input methods?) [00:20] JanC: I mean like... ibus and imx or such [00:20] it's found 2 different installed back-ends to type in Gapanese or Arab or something. [00:20] so, any reason why you have 2? [00:20] Think of it like having SystemD and upstart both running [00:21] no, no reason I have 2. I wound up with 2 during the 14.04 to 14.10 upgrade and don't know why. [00:22] likely you had 2 before? [00:23] or maybe ibus got pulled in while you had another one [00:23] Possibly. Not sure how I got 2 in the first place. I know how I got 1: I had set up the keyboard a year ago to type japanese [00:24] * Bluefoxicy eats a pork chop. [00:24] I'm pretty sure this is the first time I've actually regretted upgrading my OS. Ever. [00:36] oh [00:36] my god. [00:37] JanC: it's sound. [00:37] Rhythmbox hangs. VLC won't play sound, but plays video. Flash plays video, but no sound. [00:41] http://pastie.org/9682073 [00:41] so is this bad? [00:43] seems like an occasion to reboot, to me [00:47] Yeah... that's bad. === Guest32914 is now known as ogasawara === ogasawara is now known as Guest89782 [03:05] what's the colour of the default ubuntu tty? [03:06] i mean the actual tty, not gnome-termianl [03:07] hyperair: Black? [03:07] okay [03:07] i'm still sane. [03:07] still sane [03:07] *deep breaths* [03:07] Doesn't sound like it... [03:08] * infinity backs away slowly. [03:08] 11:00:14 ubuntu just lacks basic QA [03:08] 11:00:35 :/ [03:08] 11:00:39 e.g. their black is still broken, startup flickers in ways that suggest no one cares, and distro upgrade usually self-destructs [03:08] 11:00:44 black? [03:08] 11:00:52 yeah, black is purple [03:08] deep calming breaths [03:08] must not rage [03:08] must not flip tables [03:09] > gentoo developer [03:09] > complaining about upgrade stability [03:09] hrm. [03:09] hyperair: I'd love bug reports for the last thing. [03:09] rww: lol! i didn't notice! [03:09] also it's not purple, it's aubergine. please. [03:10] :) [03:10] hyperair: I mean, assuming he's interested in being constructive instead of just slagging Ubuntu for kicks. [03:10] GRUB's background is aubergine, which is what most people will be seeing for most of the boot... [03:10] infinity: unfortunately i haven't been able to reproduce the distro upgrading self-destructing issue, because once i'm done, it's kinda... gone.. [03:11] infinity: and i'm just stuck picking up the pieces with dpkg --configure -a [03:11] and apt-get install -f [03:11] and aptitude install -f [03:11] i ran those commands almost 20 times, each time upgrading 200 packages or so [03:11] hyperair: There are logs from the upgrade, generally. The first failure is the interesting one. [03:11] whera? [03:12] where* [03:12] hyperair: In your experience, is this with update-manager/do-release-upgrade, or raw apt-get? [03:12] infinity: do-release-upgrade bails halfwya [03:12] it's done that for the past few distro upgrades for me [03:12] but this time was particularly bad, because apt-get install -f wouldn't budge [03:12] a bunch of odd broken packages here and there [03:12] aptitude install -f did work [03:12] Kay. It leaves a log somewhere (I forget the precise name) when it explodes. [03:13] but even that only managed to move 200 packages or so [03:13] I wonder if we could get away with taking "anonymous usage statistics" that grabbed people's package lists. [03:13] and then it bailed again a few times due to broken postinst or something [03:13] Cause testing random upgrade paths is nice, but doesn't simulate real users. [03:13] infinity: cue: ubuntu IS SPYWARE [03:13] hyperair: Yeah. [03:14] god fucking damnit [03:21] Well once you start sending local search results to remote servers by default, you can't blame people for being suspicious. [04:30] yeah well, it's a little hard to benefit from hive-mind optimization without sending local search results to remote servers. [04:36] infinity: if you ask the users nicely, probably === Daryl_ is now known as Guest86047 [05:53] is it okay to forward patches to debian for build-depending on libappindicator-dev for indicator support? they do have that package as well [05:57] Good morning [05:58] Logan_: it depends. [05:58] Logan_: debian does have libappindicator [05:58] but most people don't use it, and more importantly, it breaks the UX on DEs that use GtkStatusIcon [05:58] ah, I see [05:58] i mean the standard notification area [05:59] so a given Debian maintainer probably wouldn't accept the patch? [05:59] and I should keep the delta? [05:59] i know appindicator has some fallback that stuffs itself into the notification area, but it clobbers left click launch, and launches the menu on left click [05:59] well that's wonderful :P [05:59] it depends. don't file a bug, just try looking for the maintainer directly [05:59] he orphaned the package [05:59] oh lol [05:59] then it's up to qa.debian.org [05:59] which package is this? [06:00] flush [06:00] some obscure Bittorrent client [06:00] heh i see [06:00] is upstream still alive? [06:00] idk, I like forwarding things whenever possible [06:00] no, it's inactive [06:00] you could try forwarding [06:00] I guess the worst that could happen is they don't accept the patch [06:01] yeah [06:01] usually Debian gets mad if we forward things without justification, though [06:01] not Debian in general, but some maintainers [06:01] yes, I should've clarified that [06:01] If it's orphaned and dead upstream, removal is more likely the right move. [06:02] true that [06:02] the Git repo hasn't been touched in two years [06:02] it's marked as inactive on Sourceforge [06:02] and it doesn't even support magnet links :P [06:03] Logan_: with my DD hat on, i'd say that the first time a dumb patch is uploaded, i'd reject it with an explanation. and the following times, possibly without an explanation [06:03] if it's orphaned, do I have to ask for approval from QA before filing for removal in Debian? [06:03] hmm [06:03] Logan_: In Debian, the QA team is everyone. [06:03] so I can ask myself [06:03] i don't think there's any prereq for filing for removal [06:03] Yes. [06:04] check popcon [06:04] some users might get annoyed [06:04] but that could be a good thing [06:04] Then they can maintain it. [06:04] :D [06:04] * hyperair has stepped up as maintainer for things that have been RM'd before [06:04] mostly out of rage [06:04] like NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO DON'T REMOVE THIS I STILL WANT IT [06:04] I was so surprised when they removed compiz [06:04] Take your motivation where you can get it. [06:04] indeed [06:04] wait [06:04] compiz was removed? [06:05] seriously? [06:05] yep [06:05] =\ [06:05] meh [06:05] huh [06:05] whatever floats their boat. [06:05] they said it was dead upstream I believe [06:05] which is BS [06:05] is it still maintained? [06:05] smspillaz has retired from compiz iirc [06:05] compiz is not dead? [06:06] it's definitely still being developed [06:06] afaik it's an undead state [06:06] unity's moving away from compiz [06:06] and after what canonical's done to compiz, it's probably just going to die without unity's support [06:06] * hyperair shrugs [06:06] there's now an ITP for compiz in Debian [06:07] that's amusing [06:07] http://cgit.compiz.org/?s=idle [06:07] or is somewhere else now? [06:08] last change anywhere was 5 months and compiz core has not been updated in 3 years [06:08] Logan_: that typically happens with RM'd packages. [06:08] Logan_: i think it happened for aircrack also [06:08] goodwill: bzr possibly [06:08] because canonical loves bzr [06:09] I've been meaning to ask does anyone else use bzr? what is it about bzr that Canonical loves [06:10] hmmm ... I guess it is not dead [06:10] how nice [06:10] hmm, i think emacs used to use bzr [06:10] I think they haven't switched to Git because it would require changing the whole LP infrastructure [06:10] then they moved to git [06:10] like every other sane project ;-) [06:10] We're working on git in LP, it's just not done yet. [06:11] there's nothing special about Bazaar, other than that it's backed by Canonical [06:11] infinity: oh, so it's actually being worked on! [06:11] infinity: that's music to my ears [06:11] infinity: that's nice! [06:11] infinity: nice :) Good to hear [06:11] goodwill: As for "what Canonical loves about it", it's that we developed it (and it predates git), and inertia is hard to overcome, even when you've "lost". [06:11] right [06:11] mercurial is still alive right? [06:11] Alive and well. [06:11] good [06:11] :) [06:11] love mercurial [06:11] meh [06:11] git ftw [06:11] Written in Python and used by Python upstream. [06:11] Not my cup of tea, but some communities swear by it. [06:12] Mozilla does, for sure [06:12] although they've been using Git for some projects as well [06:12] oh mariadb uses bzr too [06:12] I'm a simple man, though. I still don't mind SVN, even though that makes me a social pariah in the modern DVCS world. [06:12] they'll probably move away from it once Ubuntu does [06:13] go away Adam, we don't want your outdated opinions here ;) [06:13] well, bzr is a GNU project technically [06:13] RCS FOR LIFE. [06:13] i wouldn't mind bzr so much if git-bzr was actually properly usable [06:14] but about half of the time, it fails with some kind of error due to some weird compatibility issue with the repo it's trying to fetch from [06:20] Probably doesn't help that bzr has a slightly richer data model. [06:21] heh [06:21] i've found some repositories with unresolvable tags as well [06:21] referring to wrong hashes [06:22] RAOF: The richer data model, unfortunately, is sometimes a hindrance. [06:22] crap [06:22] I accidentally wrote utopic in a changelog instead of vivid [06:22] RAOF: Overly complicates things like tracking moves in merges and such. [06:22] Logan_: Need a reject from the queue? [06:22] can someone please reject 0.9.12-3.1ubuntu1 from topic? [06:22] *utopic [06:23] Logan_: flush, I assume? [06:23] yup [06:23] thanks :) [06:23] I probably shouldn't be doing package merges at 2:30 AM [06:23] * Logan_ goes to sleep [06:23] infinity: Right. I've not found git's non-handling of moves problematic, whereas bzr sometimes gets shirty. [06:25] infinity: I thoroughly appreciated your rejection reason [06:25] Logan_: :) [06:25] Logan_: That's my default for "people I know/like well enough to not be professional". [06:26] Logan_: So, welcome to the inner circle, I guess. [06:26] I feel so honored [06:26] oh, upgrading util-linux triggers update-initramfs -u, which now synchronously starts fstrim.service [06:26] that causes the package upgrade to hang a looooong time [06:26] infinity: ^ that's presumably not intended? fstrim.service shouldn't be started on package install IMHO [06:27] pitti: I feel like there's a Debian bug about this that I've seen fly by my INBOX. [06:27] pitti: I've been amazingly disconnected from all of that, but I need to get involved again before ah shanks me in my sleep. [06:27] oh, it was mvo who merged that, nevermind [06:28] I don't see anything relevant on https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=util-linux, I'll file one then [06:45] filed now as Debian bug 767194, I'll have a look [06:45] Debian bug 767194 in util-linux "util-linux upgrade synchronously starts fstrim multiple times" [Important,Open] http://bugs.debian.org/767194 [06:45] it's highly annoying as each initramfs upgrade now takes 10 minutes or longer [06:47] wgrant: hey William! [06:48] wgrant: all the outstanding imports at https://translations.launchpad.net/ubuntu-rtm/14.09/+source/ciborium/+imports?field.filter_status=all&field.filter_extension=all , are these normal? the pots got imported over a week ago [06:48] pitti: Probably because of the arch in the path? [06:48] wgrant: well, I imported the armhf pot and deleted all the others (as this is RTM) [06:48] Some packages end up with the POs in both the source and binary directories. [06:49] wgrant: but the outstanding PO files are from all arches [06:49] i. e. neither get the armhf ones imported nor the !armhf ones ignored [06:49] wgrant: yeah, unfortunately stuff only ends up in the per-arch build dir for ciborium [06:50] but then again, https://translations.launchpad.net/ubuntu/utopic/+source/ciborium/+imports?field.filter_status=all&field.filter_extension=all looks similar [06:50] so perhaps that's "normal" [06:50] pitti: Are you sure? The template path is currently set to "po/ciborium.pot", no arch. [06:50] wgrant: hm, that's not what I imported, but perhaps someone else already did that [06:51] https://translations.launchpad.net/ubuntu-rtm/14.09/+source/ciborium/+pots/ciborium has translations, so supposedly it somehow works [06:51] Examining the tarballs in the queue, they're in source/po/*.po too [06:51] Someone should really fix all these cmake-y build systems to not produce both, though. [06:51] ok [06:52] I don't think there's a problem here, besides the duplicated import entries. [06:52] https://launchpad.net/ubuntu-rtm/14.09/+queue?queue_state=3&queue_text=ciborium, look at one of those tarballs. [06:52] wgrant: so po files in dirs where pot files got explicitly deleted/rejected don't get cleaned up, they just keep stuck in "needs review"? [06:52] pitti: Files are approved based on templates, not based on other files. [06:53] A queue entry has no idea that another queue entry was rejected. [06:53] Though Blocked has some special handling. [06:53] wgrant: ok, so that is normal then? [06:53] This particular case seems very common with qt things; someone should investigate and remove the duplication, I think. [06:53] This behaviour is normal and expected given the input tarball, yes. [06:53] wgrant: ack, thanks for checking! [06:54] (and yay broken build systems) [07:01] pitti: I guess that's probably easy enough to fix in pkgstriptranslations, too. [07:09] good morning [07:12] hey dholbach [07:14] hey pitti [07:14] how's life over there? [07:15] dholbach: lots of catch-up to do from last week :) [07:15] yep, I can relate to that :) [07:51] mvo: guten Morgen [07:52] mvo: so where's the magic in http://launchpadlibrarian.net/188488665/command-not-found_0.3ubuntu15_0.3ubuntu15.1.diff.gz ? is there an external blacklist which isn't represented in that diff, or did you hand-edit scan.data after scanning? [07:54] pitti: there is a external blacklist on nusakan [07:55] pitti: I ran a full scan with postgresql-xc blacklisted [08:00] mvo: ah, thanks; so SRUing this to trusty would merely mean to re-run scan, and it picks up the blacklist? [08:02] pitti: yeah, thats probably the most simple way, do you want me to prepare trusty too? [08:03] mvo: depends, if it's not too much effort for you; otherwise I can look into it. I mostly wanted to understand the mechanics how this works [08:06] mvo: I verified the utopic SRU, thanks! [08:07] pitti: no problem, I just started the extraction [08:09] Does ubuntu have any plans to implement dep-11? https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCEQFjAA&url=https%3A%2F%2Fwiki.debian.org%2FDEP-11&ei=uaBQVPyeE8btmQW7oYLYCQ&usg=AFQjCNFAC6PqqgyxzcQWi42MmlGzNBouKQ&sig2=mZX3PiNYRlsX2hlWGzHwKg [08:09] pitti: it takes some time to run though [08:10] mvo: would hand-editing have been faster? [08:10] well, I assume "yes"; I meant "more appropriate" [08:11] pitti: either way is fine, the upside of running the extraction again is that we catch if more got changed in trusty (which really shouldn't be the case). but yeah, hand-editing is the fastest path :) [08:21] mvo, i just noticed that ubuntu-core-system-image fails to build images in vivid ... with the same issue we had on touch and ubuntu-core yesterday (image builds accidentially using PPA builders) ... infinity knows what to do (he fixed the two others) [08:27] ogra_: thanks, but it seems like the latest image build was successful (3h ago) - I had to update a bunch of stuff in the PPA because of vidid changes [08:27] ah, k [08:28] sorry, didnt check the timestamp on the mail [08:33] ogra_: no problem :) [09:02] hmm [09:04] * ogra_ has by accident looked into his router syslog ... runnint minimal trusty there and i just noticed os-prober running there [09:04] is that normal ? [09:04] i never saw that on an installed system [09:09] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Archive: open | 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: Laney [09:09] irritating ... [09:09] it also seems to load a lot of filesystem modules doing that [09:10] even before os-prober runs [09:13] ogra_: os-prober is executed by update-grub [09:13] ogra_: well one of the snippets to test/check/detect/generate boot entries. [09:13] xnox, why would that run on a regular basis on a running system though ? [09:13] i seem to see it pretty regular in syslog [09:14] ogra_: trusty gets new kernels every two weeks. so i'd expect it to run every two weeks. [09:14] hmm [09:14] ogra_: unless your /boot is full, and unattended upgrades active, which would constantly try to configure new kernel, run os-prober, and fail. [09:14] * ogra_ checks his /boot [09:15] indeed i run unattended upgrades ... since its a router :) [09:15] andin fact there is a newer kernel than i run [09:16] so why didnt i get a reboot notification on login [09:16] my trusty server install definitely gives me one ... weird [09:17] * ogra_ guesses ubuntu-minimal lacks that bit [09:17] xnox, thanks ! you rock ! [10:11] Laney: dh-autoreconf> I don't think so; part of the rationale for the split is that virtually nothing actually needs /usr/bin/libtool, and typically should be fixed if it does [10:16] Laney, so should I ask for miniupnpc and transmission merges? I actually did them both, also rdesktop [10:16] usually dholbach doesn't ask me to do, but I can ask if needed :) [10:16] they are all trivial merges [10:24] cjwatson: Maybe so. I found three packages broken by this during the gi transition, which were using `libtool --mode=execute' in their test wrappers. (Okay, these three were Ubuntu specific) [10:24] LocutusOfBorg1: You risk duplicating work or missing some piece of knowledge [10:24] LocutusOfBorg1: See the first bullet https://merges.ubuntu.com/universe.html [10:25] This cycle I've already had two merges I was already working on performed by someone else [10:26] Laney: If they're doing that, then they should have a direct build-dependency anyway, rather than relying on dh-autoreconf to supply it for them. [10:26] Laney: But the right fix is to make them use the libtool in their build tree, not /usr/bin/libtool which may bear only passing resemblance in terms of configuration. [10:27] Laney: Compare e.g. http://git.savannah.gnu.org/cgit/man-db.git/tree/src/tests/testlib.sh#n17 [10:28] Right [10:28] I'm just observing that there are things now which have become broken because they were assuming dh-autoreconf gave them /u/b/libtool [10:28] oh indeed, so do you plan to merge gdcm? it is a package I worked on debian [10:28] Oh, yeah, just saying those are things to be fixed and not papered over [10:29] bdrung, you there? [10:30] LocutusOfBorg1, yes [10:30] I would like to report a bug against wrap-and-sort [10:30] but I ask you prior [10:30] http://anonscm.debian.org/cgit/collab-maint/transmission.git/commit/?id=aa78e17e550005e12bd8251d694af450113f5d9c [10:30] look at this [10:30] you know he's in #debian-devel too? :) [10:30] wrap-and-sort dropped dpkg-dev b-d, because seems to strip everything after the first comment "#" in b-d [10:30] ops :) [10:31] gdcm> go ahead [10:31] Sometimes I feel more confortable here rather than in debian :) [10:31] LocutusOfBorg1, i am 99% sure that this is a bug in python-debian (and it is probably already reported) [10:32] dpm: If you're talking about myspell-ca, I copied that in a few days back, you just weren't on IRC for me to respond at the time [10:32] So Noskcaj posted a silly google link, but are there any plans for DEP-11 in ubuntu in the near future? [10:32] pitti, cjwatson ^ [10:33] Ubuntu GNOME will probably switch to gnome-software at some point, but without that, is largely useless [10:33] I don't think it has ever been discussed so far [10:33] bdrung_work, you mean something like #694142? [10:34] LocutusOfBorg1, yes, that's exactly the bug you described [10:34] :D thanks! [10:34] I subscribed to it, thanks for avoiding me to report a new bug [10:35] i should implement an option to just show the diff instead of applying it [10:35] thanks for asking [10:35] bdrung_work, I'm wondering how many times people drops b-d in an unaware mode [10:35] seems dangerous! [10:36] i only run wrap-and-sort in git repositories (where you can run 'git diff' afterwards to check the result) [10:36] yes, but sometimes with huge dependencies it becomes difficult to track all of them, I double check them (this is why I spotted this one, in the transmission merge) [10:37] cjwatson, ah, awesome. I hadn't re-pinged as I wasn't sure if you were away. Thanks! [10:37] but the "one-line" to multiline switch makes things hard [10:38] dholbach: Thanks for uploading https://code.launchpad.net/~gunnarhj/ubuntu/vivid/im-config/merge-0.27-1/+merge/239853 [10:38] dholbach: Can you please push the branch too? (The bots didn't do their job.) [10:40] pitti, right, would be good to start that discussion at some point, but not really a priority this cycle [10:41] though given it require backend changes to the archives afaics it might be better to start sooner than later? [10:44] GunnarHj, done [10:45] dholbach: Great, thanks! [10:57] Laney, can I give you the debdiff or should I open abug? [10:57] LocutusOfBorg1: bug please [10:57] s/abug/a bug/ [10:57] ack [11:01] FYI #1387114 [11:01] was trivial :) [11:08] bah [11:08] * ogra_ glares at his half pushed livecd-rootfs branch [11:09] damn [11:17] so will the next ubuntu have systemd by default? [11:18] most of the ubuntu deltas I'm looking at have upstart init scripts, I'm wondering if they can be synced over [11:23] mvo, any objections to me uploading livecd-rootfs ? [11:24] (just ran into your changes there) [11:27] * ogra_ uploads ... [11:29] ogra_: there's a sponsor request in the queue [11:29] can you take that at the same time? [11:29] actually two === _salem is now known as salem_ [11:34] LocutusOfBorg1: we'll need to retain upstart jobs as a transition mechanism for a while no matter what [11:34] LocutusOfBorg1: please don't drop those [11:38] Laney, i'll have to do more subsequent uploads of livecd-rootfs today (this one is just to give you proper info in the build error so all needed changes are listed in it, i actually need to make these changes i teh next one) [11:39] Laney, so yeah, i'll happily take them with the next one [11:39] thanks [11:39] One of them is basically a c+p of a script in ubuntu-touch hooks, wonder if they can be shared somehow [11:40] i'll take a look [11:40] hoperfully not the password hardcoding :) [11:40] (since i'm just changing that bit) [11:40] nah, /etc/writable stuf [11:41] ah, thats fine [11:41] * ogra_ notes that systemd causes issues in touch even before being the default [11:42] * ogra_ blames lennart ... because everyone does === MacSlow is now known as MacSlow|lunch [11:49] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Archive: open | 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: mdeslaur, Laney [11:54] ogra_: none, thanks [11:54] :) [11:54] ogra_: sorry for the delay, was having lunch [11:54] to late anyway :) [11:55] ogra_: I meant to upload them but got distracted :) [11:55] (i assumed if you merge into trunk the code would be ready) [11:57] ogra_: yes, it should be fine and got tested in our PPA for some time already [11:57] right [11:57] thanks [11:57] :) [11:59] ogra_: oh, just got the mail from the archive that I did indeed upload (and not dreamed it). so you will have to do another upload with your " * properly redirect error output in 99zz-check-uid-gid.chroot" change and a new version number. maybe you looked while LP was still processing the upload [11:59] hmm [11:59] mvo, did you debcommit ? [12:00] the tree didnt have a new tag [12:00] oh, and there is the rejected mail :P [12:01] hmm the tree is a mess [12:02] mvo, please push --overwrite your upload and do a proper debcommit ... seems the tree has my debian/changelog and my tag now [12:03] ogra_: sure, done [12:03] thx [12:03] ogra_: at r990 [12:03] ogra_: sorry for the trouble, that was the part I meant to do and got distracted [12:04] yeah, no prob ... [12:04] * mvo hugs ogra_ [12:05] * ogra_ hugs mvo [12:23] cjwatson, I never drop without asking first :) and of course *not* before any systemd transition :D [12:23] and thanks for the clarification ;) === _salem is now known as salem_ [12:53] LocutusOfBorg1: are you going to handle rebuilds for gdcm? === MacSlow|lunch is now known as MacSlow [13:03]