[05:38] good morning [07:11] good morning [07:28] hi enick_997 [07:28] good mornign to you as well [07:28] rbasak: on the virt-manger merge https://code.launchpad.net/~paelzer/ubuntu/+source/virt-manager/+git/virt-manager/+merge/328824 you already commented a bit in IRC [07:29] rbasak: I made the reason to not drop the gir1 dependency explicitly mentioned in the MP [07:29] rbasak: I also have good user feedback on the ppa [07:29] rbasak: if you could afford a few minutes to review for formal or overlooked issues this morning that would be great === enick_997 is now known as lordievader [07:50] This nick is better :) [07:50] Hey cpaelzer, how are you doing? [07:54] good [07:54] I almost thought somebody other than us would care about a good morning at this time reading the other nick name :-) [07:55] Yeah, the matrix-irc bridge had a restart. Changes nicks. But for me that is not allways obvious that it happened. [11:08] ahasenack: so I'm about to start looking at https://code.launchpad.net/~paelzer/ubuntu/+source/virt-manager/+git/virt-manager/+merge/328824 for cpaelzer. Should I be clicking "Claim review" against either of the two requested reviewers? [11:56] rbasak: yes [11:56] rbasak: in this case the MOTU is for the actual review by a group that could sponsor [11:56] rbasak: and the generic server team is to have it on the active reviews list [11:57] rbasak: you can only take one, but that is fine - doesn't matter to much which one you claim [11:57] ahasenack: or did we agree already which of the two we take? [11:57] rbasak: and finally - thanks rbasak for looking into that [11:58] Presumably I should claim the MOTU one, so the ~canonical-server one remains, so we can see all outstanding requests still in ~canonical-server's active reviews queue? [11:59] rbasak: I'd think vice versa [11:59] rbasak: claim the one on the team - because then on the overview it is visible that one took a look [12:00] I think if you approve/deny/comment those will be counted no matter from which review slot they come from [12:00] so it isn't too important [12:00] I'll look in the samba or bind one so that andreas can also be unblocked [12:00] but samba is "take 4" maybe there is too much history on that already by whoever reviewed before [12:05] rbasak: yes, please claim the motu one [12:05] as unclaimed reviews requested from that group won't appear in the ~canonical-server queue [12:05] and good morning :) [12:06] hi andol [12:06] still hi andol, but I actually meant ahasenack - hi [12:07] hi cpaelzer [12:08] ahasenack: I try to digest "unclaimed reviews requested from that group won't appear in the ~canonical-server queue" - so reviews that have MOTU + Server team and are unclaimed in both do not show up on the active reviews? [12:08] cpaelzer: no, that's not it [12:09] good because that sentence puzzled me [12:09] cpaelzer: if an MP has only non-canonical-server requests, it won't shoud up in ~canonical-serve [12:09] ack [12:09] the only way for it to keep appearing in the canonical-server queue is for there to be an unclaimed slot for canonical-server [12:10] but if it has (canonical-server = c-s) c-s-motu and c-s then why claim c-s-motu preferrably? [12:10] will it not go away from he c-s list when you only claim c-s-motu ? [12:10] if you claim c-s, it will disappear from the queue and we won't see it. It's a visibility thing [12:11] so the rule is more or less to never anybody claim c-s (only there for visibility) [12:11] ? [12:11] yes [12:11] thanks for clarification [12:11] doesn't mean a c-s person cannot review it, I'd say that's encouraged even [12:11] just never claim the slot, or give a +1 or -1 [12:11] just "comment" [12:11] unfortunately [12:11] cpaelzer: AIUI, the sole reason we have a review slot for c-s is because ahasenack wanted a single place to see all pending MPs. So we're using it as a tag really, rather than a review slot. [12:11] yeah, it's a workaround [12:12] I filed a bug in launchpad about it [12:12] * rbasak claims the MOTU slot in https://code.launchpad.net/~paelzer/ubuntu/+source/virt-manager/+git/virt-manager/+merge/328824 [12:12] I would like the same view for ~team/+activereviews that already exists for /+activereviews [12:12] Thank you (both) for the clarification/discussion. [12:12] let's give it a try, and re-evaluate [12:13] ahasenack: I want to unblock you as well - which one would you like me to take a look more - bind or samba ? [12:13] cpaelzer: can you upload either? [12:13] mdeslaur manifested interest in the bind one [12:14] oh, nacc grabbed the bind9 uploader slot [12:14] hm, the "claims" don't show up in the +activereviews page either [12:14] ahasenack: can't upload either until the DMB aggrees [12:15] -g [12:15] cpaelzer: I think samba might be the most confusing one, because of a reverse patch that was incomplete. Might be the most enlightening one for that reason, though [12:16] cpaelzer: bind is interesting because I split two debian patches to remove test cases from them and make them individual new patches [12:17] cpaelzer: ssd-krb5 is an sru, and a very simple one, would be cool to get that unblocked [12:17] then lets start there [12:17] low hanging foul fruits and such :-) [12:17] and I at least somewhat looked in that soruce before [12:19] haha, great analogy :) [12:26] ahasenack: does the ppa of this still lvie somehwere? [12:26] cpaelzer: it should [12:26] cpaelzer: ppa:ahasenack/ssd-krb5-locator-path-1664566 ? [12:26] no link in the bug or MP [12:27] thanks [12:27] ah in the mp description it is [12:27] it's hidden in the test case, let me make that more clear [12:45] ahasenack: I'm done with the sssd review - all good, one spin off question in the MP [12:45] ok, will check [12:45] ahasenack: since I can't tag do you mind loosing the rich history on that minimal change? [12:45] ahasenack: otherwise I'd sponsor [12:45] cpaelzer: go for it, I don't mind [12:51] ahasenack: done and bug updated [12:51] and MP [12:51] thanks cpaelzer [12:51] ahasenack: do you claim the team review slot so it goes away on the active reviews? [12:51] I can't take two [12:51] interesting [12:51] I hadn't thought about this case :) [12:52] will do [12:59] cpaelzer: about your MP comment, you mean that the directory from the libkrb5 package exists, and supposedly is meant for plugins, and is now empty? [13:00] ahasenack: yes [13:00] ok [13:00] ahasenack: I just spun forward the thought if the dir is wrong as well [13:00] ahasenack: but it is not from sssd packages but krb5 itself [13:00] it may be dedicated to plugins coming from the krb5 package itself, like its ldap backend [13:00] let me try installing all binaries [13:00] yes [13:00] let me apt-file that [13:01] good idea [13:01] no ither hit but for the sssd-common file [13:02] so at least no other pkg places anything there today [13:02] xenial? [13:02] yes [13:04] ahasenack: artful as well [13:05] plugins/kdb has content, plugins/tls has content [13:05] just not plugins/krb5 [13:05] ahasenack: apt-file can only ifnd files, so this only tells us that there is no file in the archive that uses this path [13:06] ahasenack: it seems to me that after your fix /usr/lib/x86_64-linux-gnu/krb5/plugins/krb5/ is an empty wasteland [13:06] and my uneducated guess was that it might be the case that it (the path) shouldn't exist at all [13:07] thats all I can say [13:07] and that is is unused over the entirety of the archive other than the wrong path in sssd-common seems to confirm [13:07] so far I found only this on mit's site: [13:07] Plugin base directory LIBDIR/krb5/plugins [13:07] although one would have to look (deep) in krb5 [13:08] after installing a few more plugin packages, they seem to create their own subdirectories [13:08] -e "s\"@MODULEDIR\"/usr/lib/x86_64-linux-gnu/krb5/plugins\"" [13:08] that is from the build [13:08] maybe there just doesn't exist a krb5 plugin yet, whatever that means. Sounds client-side [13:09] but if it would take from "anywhere" in there then ...plugins/krb5 and ...plugins/libkrb5 wouldn't makea a difference in your fix [13:10] maybe worth a mail to Debian and/or upstream krb? [13:10] not entriely sue since this came up as "guess" I don't feel convinced enough to ring a lot of bells and whistles [13:12] rbasak: thanks for the review - would you mind tagging this before I upload? [13:12] this is a rich history that helps to be preserved for next time [13:13] s/helpswould be useful/ [13:13] cpaelzer: checking this comment: "You're right, running 'strings /usr/lib/../libkrb5.so.3|grep plugins' shows that it's ../krb5/plugins/libkrb5. For some reason I changed it to plugins/krb5 some years ago, without a bug reference.." [13:13] cpaelzer: of course. Sorry I had forgotten that. [13:13] PEBKAC error in my typing :-/ [13:13] ahasenack: where is that comment? [13:14] in the bug that ws fixed? [13:14] cpaelzer: comment #2 in https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1664566 [13:14] Launchpad bug 1664566 in sssd (Ubuntu Xenial) "sssd_krb5_locator_plugin.so is not loaded (installed at wrong path)" [Medium,In progress] [13:14] funny that there are two major libkrb5 files [13:14] .so.26 and .so.3 [13:14] yep [13:14] I saw that, well sover compat and it seems krb5 can build both so helps the old dependencies [13:14] oh, .26 is from heimdal [13:14] uh - ok [13:15] a whole lot of stuff links against heimdal [13:15] apt-transport-https, reportbug, curl, to name a few interesting ones [13:16] cpaelzer: hitting a few bugs in "git ubuntu tag --upload" - I may be a few minutes. [13:16] rbasak: ok, please ping me once it is done or if you give up the immediate try [13:16] ack [13:20] cpaelzer: upload tag pushed [13:20] rbasak: and on the format of merge-bug closing I already have an improved style for multiple fixes due to a merge - let me make a pastebin to show you [13:20] rbasak: thanks [13:21] rbasak: http://paste.ubuntu.com/25312255/ [13:21] rbasak: you are right there is no policy, but this is my personal new oen for now [13:21] for better readability [13:21] It also easens to take over the line if a change is "remaining" on the next merge [13:21] cpaelzer: I like it [13:27] cpaelzer: libkrb5 is definitely the correct directory for krb5 plugins, [13:27] ./src/lib/krb5/os/locate_kdc.c:static const char *objdirs[] = { LIBDIR "/krb5/plugins/libkrb5", NULL }; [13:27] the bug was just an incorrect assumption from sssd [13:27] which seems to be the only libkrb5 plugin we have [13:29] cpaelzer: debian/libkrb5-3.dirs.in in the krb5 source package lists the incorrect plugins/krb5 directory [13:29] that's the bug (task) we need now? [13:29] to fix that? [13:30] ahasenack: I would not mind to fix that in any SRU [13:30] ahasenack: nor for Debian delta [13:30] but a simple patch to Debian would be nice [13:31] let me check the debian status [13:31] and link the Debian bug on the bug you had [13:31] so one can find the whole context in one place [13:32] just checking if that comes fromd debian/* or from the upstream build system [13:35] rbasak: I checked on your correct request for a tracker WRT the package names in virt-manager [13:35] rbasak: "libvirtd" is the correct service name since Yakkety - so that is a no-op and we don't want a change [13:35] rbasak: I'll submit something upstream that fixes this now and forever [13:36] rbasak: dropping the need to make this proper names for every dirsto (there might be more differences) [13:36] cpaelzer: ah, OK. I hadn't really considered the service name message. I was thinking more of the message listing the package names that needed installing. [13:37] cpaelzer: but I didn't really think too hard about it. As long as a bug exists for anything you think you dropped that would be nice to upstream (to Debian or upstream upstream), I'm happy :) [13:38] I think it is wrong to call it "package X" which leads to all this [13:38] and will propose something saying th packages containing kvm, qemu, ... [13:38] that way it applies to all distros [13:39] That is less helpful to users though, who mostly don't know how to look up what package provides a particular command. [13:39] hmm, true as well [13:40] \ | / - ... processing [13:40] But a distro delta is also bad [13:40] So I don't really know what a great solution would be. [13:40] I check if the configure has any distro detect already [13:40] A hook into command-not-found perhaps? [13:40] But that's probably not worth the effort. [13:40] all but a simple change is over engineering [13:40] give me a few minutes [13:40] Yeah :) [13:41] I'm fine for you to just leave a bug open on it somewhere, importance wishlist, and call it done :) [13:41] rbasak: my soul wants things done not tracked :-) [13:41] but yeah I might end up that way [14:10] rbasak: I have a whishlist bug to track but also a submission to upstream now [14:10] coldn#t leave it like that [14:11] cpaelzer: thank you! [14:17] ahasenack: thanks for the debian bug on the cleanup [14:22] o/ [14:22] it feels good to have everything explained [14:27] rbasak: hi, could you please import cifs-utils? [14:31] ahasenack: running [14:31] Hmm. It failed very quickly. [14:34] I think it's a regression in master. Going back a bit in the state of the repo works. [14:34] But nacc isn't here right now. [14:35] Running with an older importer version [14:37] rbasak: could be, I'm getting a weird error with merge start: [14:37] (ubuntu/devel)andreas@nsn7:~/git/packages/cyrus-sasl2$ git ubuntu merge start ubuntu/devel [14:37] 08/14/2017 11:36:54 - ERROR:ubuntu/devel is not a defined object in this git repository. [14:37] we need unit tests :/ [14:37] ahasenack: that's a separate regression I found earlier and I have an MP fixing it awaiting nacc's review. [14:37] ahasenack: we're busy polishing up the code so it can be testable. That's what's causing the regressions right now. It'll get better soon. [14:40] nice [14:53] ahasenack: done [14:53] rbasak: thx [14:53] let me try to revert to the previous snap [15:03] rbasak: the snap seems a bit busted now, or the store [15:03] $ snap install git-ubuntu --classic [15:03] error: cannot perform the following tasks: [15:03] - Download snap "git-ubuntu" (117) from channel "stable" (received an unexpected http response code (404) when trying to download https://api.snapcraft.io/api/v1/snaps/download/VAGSRAriUyDDlqsLunShJTe7503Uw4GF_117.snap) [15:29] im getting a grep: broken pipe error when running a certain python file anyone able to help ? [15:37] nacc: rbasak: git ubuntu clone (r119) working again, but it spits out this fatal-not-fatal error at the end [15:37] fatal: remote error: Repository '~ahasenack/ubuntu/+source/cifs-utils' not found. [15:38] $? is 0 at least [15:38] nacc: wrt snap error, snap logout;snap login to fix it [15:38] ahasenack: that's a message when it can't find your personal repo [15:38] ahasenack: that's propogated directly from `git clone`-like output [15:38] ahasenack: i agree it's a bit messy [15:39] yep, no biggie [15:40] ahasenack: fyi, 121 is out :) [15:40] yay [15:40] (artful based snap) [15:58] .o/ moin [17:44] nacc: rbasak: known? http://pastebin.ubuntu.com/25313513/ ValueError: ubuntu/devel [17:44] snap r122 [17:45] ahasenack: thanks, fixing, one sec [17:50] ahasenack: fix pushed to master, triggered a snap build, sorry abou thtat [17:50] thx [17:53] nacc: r126 still fails, your last push is newer? [17:54] ahasenack: yeah, give it a bit [17:54] ok [17:58] ahasenack: 129 should be avail. [17:58] ahasenack: 130 even === JanC is now known as Guest47969 === JanC_ is now known as JanC [17:58] * ahasenack refrehes [17:59] interesting, the download is slower now [17:59] maybe a cold cache [17:59] 5min eta [18:00] ahasenack: if i had to guess cyrus-sasl2 can be syncd [18:01] ahasenack: the delta is a backport from upstream [18:01] we have a patch [18:01] ahasenack: ? [18:01] the patch we have comes from upstream, not debian [18:01] ahasenack: right. [18:01] oh i see, i though it was a new upstream version [18:01] no, the upstream change is barely worth it [18:02] ahasenack: not really important to merge that [18:02] sorry, s/upstream/debian/ [18:02] I'm doing it for the exercise [18:02] ahasenack: there are more importnat merges, i mean :) [18:02] ack [18:02] first time in my life git rebase new/debian completed on its own === Epx998- is now known as Epx998 [18:06] nacc: in which step do you adjust the indentation of the d/changelog lines: deconstruct, logical, or when rebasing on new/debian? Or something else? [18:06] for a remaining change, for example [18:06] d/changelog has it as a * [18:08] I'd guess new/debian rebase [18:09] ahasenack: meaning something that was new before, but is now part of remaining? [18:09] ahasenack: yeah, i usually do the adjustment in the rebase to new/debian [18:09] yes [18:09] k [18:13] nacc: got a lint backtrace: http://pastebin.ubuntu.com/25313636/ NameError: name 'treeish' is not defined [18:13] that was after i created a branch from my detached head [18:13] that sentence sounds funny [18:19] ahasenack: thanks, fixing and pushing, give it about 5 minutes for the snap to build & publish [18:19] ok [18:21] nacc: I'm seeing other "new" errors, maybe not fatal [18:21] nacc: http://pastebin.ubuntu.com/25313688/ in merge start: [18:21] "08/14/2017 15:20:15 - ERROR:ubuntu/devel version (2:6.6-5ubuntu1) is after debian/sid version (None). Are you sure you want to merge? (Pass -f to force the merge)." [18:21] cifs-utils was just imported this morning by rbasak, and I think he had to revert to an older snap to do it [18:21] maybe something failed and wasn't caught [18:21] or it's just a new harmless error [18:22] since I do have a local debian/sid branch after that clone process finished [18:22] ahasenack: let me look [18:24] that's with snap r130 [18:24] ahasenack: fixing [18:24] :) [18:27] nacc: in snap r131, ubuntu lint broke differently: http://pastebin.ubuntu.com/25313712/ AttributeError: module 'enum' has no attribute 'IntFlag' [18:27] maybe once this is stabilized we should start using the edge channel [18:28] random question since snaps were mentioned... despite having tried to understand what's going on I still don't get when and why I'd want to use snaps [18:28] is it just IoT stuff? [18:28] no [18:28] sometimes it almost sounds like a dockerish thing for self-container deployments [18:28] contained* [18:28] there are feature that appeal more to one group of people than the other, sure [18:28] one example: you have a software that you want to make available to ubuntu lts [18:28] you have xenial and trusty [18:29] these two have different versions of supporting libraries [18:29] you would have different packages of your software for each probably [18:29] with snaps, you can have just one snap for both [18:29] think of the snap as being self-contained [18:29] also, you push it to the store, and it's instantly available [18:30] well, minus build time :) [18:30] can i run my own store to push things around local boxes? [18:30] I *think* yes [18:30] better check with #snappy [18:30] maybe becuase I'm used to it, but I'm thinking of them as "special" .debs with dependencies included and so I'm thinking "oh, run a local repo" [18:30] I'm not entirely sure about all aspects of the store [18:30] but maybe I'm off/stuck on a diff framework [18:31] you can think of them as being some sort of "static" debs, if you want to compare with libraries and such [18:31] but that's just one aspect of snaps [18:31] you can easily rollback, for real [18:32] that's another cool feature [18:32] ahasenack: grr, i see what's wong with lint, one sec [18:32] ah, so things are sort of installed in parallel? back in the days we used to do sw deployments installing from git and symlinking to current [18:32] so that a rollback was just a re-link away [18:32] pretty handy [18:32] drab: you get common areas where to store your data, and versioned areas [18:32] that sounds pretty sweat [18:32] drab: if that part is interesting, this page makes it nice a clear: https://snapcraft.io/docs/core/versions [18:33] is there a substantial push from canonical to move to this kind of thing over debs? [18:33] thanks dpb1 [18:33] drab: you also have different distribution channels for your snap: stable, candidate, beta, edge [18:33] ahasenack: do you have the branch that's ailing to lint anywher? [18:33] by default people get stable, but they can pass flags to get more and more bleeding edge [18:34] nacc: let me check [18:34] nacc: let me push, lint was the last step before pushing [18:34] yeah seems you can run your own store: https://github.com/noise/snapstore/ [18:34] linked from the docs dpb1 shared, looks useful [18:35] ahasenack: thx [18:35] nacc: I'm afraid now, last time the linter failed on a branch of mine it was because I did something silly :) [18:35] nacc: https://code.launchpad.net/~ahasenack/ubuntu/+source/cyrus-sasl2/+git/cyrus-sasl2/+ref/artful-sasl2-merge-1710684 [18:36] drab: http://pastebin.ubuntu.com/25313769/ [18:36] drab: no effort that I know of to bring this kind of thing to debs, no. But, debs aren't going anywhere, Canonical and Ubuntu continue to be built on debs, and even the first step many snaps do when building is to install debs to download versioned dependencies they need. [18:36] drab: followed by http://pastebin.ubuntu.com/25313777/ [18:38] nacc: fwiw, git ubuntu clone is also failing with that AttributeError [18:38] so not just the linter [18:38] ah, heh, same principle, good to know, I always liked that way of doing deployments, even if in some places we packged that into debs, the uidea remained the same, post-install scripts would change the symlinks etc [18:38] ahasenack: yeah i see why [18:39] drab: btw, if you like information and have just a few minutes of time, https://snapcraft.io/ -- the tutorial linked off there is very nice having followed it myself a few months back. [18:39] dpb1: will do so, thank you [18:39] ahasenack: the reason you're seeing this is i fixed the snap to actually use only the snap's internals [18:39] * dpb1 takes off snap pushing hat. [18:39] lol [18:39] ahasenack: so it's leading to some more nasty debugging [18:39] heh [18:39] oh, we had a leak [18:39] ahasenack: yeah [18:39] speaking of time, I forgot to take the time to upload the csv for tomreyn... [18:39] ahasenack: and we have a mixed python env because of gbp (python2) [18:39] * drab goes doing that [18:51] ahasenack: i *think* i fixed the snap python paths, building now [18:51] ahasenack: not sure why perl isn't getting put in the snap yet [18:58] is there a proper way to remove an upstart job? [19:01] ahasenack: i *think* the correct chnages have been pusehd for the two issues you hit, in r136, i'm testing it a bit now [19:01] ok [19:02] actually, I might not need to do anything... I just upgraded from 14.04 to 16.04 and upstart just doesn't work [19:02] I guess I just need to create a new conf for systemd [19:03] nacc: clone and merge start worked [19:04] nacc: lint failed with AttributeError: 'GitUbuntuLint' object has no attribute 'pkg_remote_branch' [19:04] http://pastebin.ubuntu.com/25313927/ (r136) [19:04] nacc: ^ [19:05] ahasenack: ok, have a fix for that queued [19:08] tomreyn: dropped you a msg with the link to the csv stuff, lemme know [19:40] ahasenack: i think the lint issue is fixed (importer is still broken) [19:40] ok [19:41] nacc: finding all the missing deps the hard way, huh [19:43] #!/usr/bin/python [19:43] f. [19:43] rbasak: suggestions for how to workaround gbp harcoding the path to python? [19:43] i *think* that's why it's not working in the snap, but not 100% yet [19:45] nacc: IMHO, that's up to snapcraft to patch. If it can't, then maybe that's something for the snappy forums? [19:45] Or convince upstream to use /usr/bin/env? [19:49] rbasak: classic snaps don't get that help :) [19:51] Hello, I have a question: I want to create a user in my server, so a remote computer can connect to the server with that user, and rsync some files. Yet I would like for this user (on the server-side) NOT to have a shell. [19:52] Does rsync use the shell for its operations, or can I put the user's shell as /bin/false ? [19:53] nacc: hm, I got a silly situation where our delta is just different permissions in two files in debian/: http://pastebin.ubuntu.com/25314155/ [19:53] new/debian has postinst.in, prerm.in as 0755, we have those 0644 [19:54] ahasenack: is there a reason (from d/changelog) as to why they are different? [19:54] no [19:54] ahasenack: then you can probalby sync it [19:54] it's a silent change [19:54] ahasenack: i'd ping the person who introduced it,if you're not sure [19:54] it was introduced from 6.6-5 to 6.6-5ubuntu1: -- Dave Chiluk Tue, 03 May 2016 17:30:11 +0000 [19:55] chiluk: --^ :) [19:55] chiluk: around? [19:56] that 5ubuntu1 version is supposed to have introduced debian/patches/stat_systemd-ask-password.patch, but I didn't see that in the delta [19:56] checking [19:56] oh, that patch was introduced in 2013 [19:56] n/m [19:56] ok, so no sync [19:56] tsglove: rsync needs a shell to function. As an alternative, if you don't need rsync specifically but only care about uploading files, you may want to try SFTP [19:57] it's just this deconstruct phase that got silly because of the chmoded files [19:57] so, what I said before, that our delta was just the chmod change, is not correct [19:57] that is the change in the 5ubuntu1 merge [19:57] I guess I'll use "previously undocumented" [19:58] sdeziel, true... sftp can very much work! I just thought rsync because of familiarity. So, question: if I create a user, and set the shell to /bin/false, rsync will fail? [19:58] tsglove: yes, rsync will fail if the user's shell is /bin/false [19:58] sdeziel, ok thanks! I'm reading up on sftp now. [19:58] I didn't know sftp ran over ssh [19:59] tsglove: for sftp, you can even have the user chrooted to a given dir [19:59] sdeziel, that would be ideal! searching for that now [20:01] nacc: can you verify if the import of cifs-utils done earlier today is correct? I'm seeing some strange stuff [20:01] ahasenack: such as? [20:01] I know rbasak had to downgrade git-ubuntu to get it to work, but maybe there was some subtle error or bug [20:01] nacc: git status says debian/patches is untracked [20:01] tsglove: http://paste.ubuntu.com/25314208/ [20:02] ahasenack: untracked where? [20:02] when I rebase on old/debian [20:02]