| === salem_ is now known as _salem | ||
| slangasek | infinity: shim itself build-depends on gnu-efi, so if gnu-efi is missing on arm64, pesign isn't terribly relevant | 00:45 |
|---|---|---|
| infinity | slangasek: Well, unless you want to sign grub yourself. But yes, that does put a kink in the shim->grub->kernel way we do things. | 00:50 |
| slangasek | oh right, we don't actually need shim on arm64 because no signing regime | 00:51 |
| psusi | eh? I thought that "windows certified" arm hardware *required* signing | 00:51 |
| slangasek | sure it does | 00:51 |
| slangasek | with a key that Microsoft will not use to sign anything from third parties | 00:51 |
| infinity | psusi: None of which is a target for us currently. | 00:52 |
| === mfisch is now known as Guest68660 | ||
| pitti | Good morning | 04:14 |
| robert_ancell | RAOF, have you ever removed a package from the archive? I want to clean out all the old vala packages. Wondering if there's anyone I should check with first | 05:01 |
| RAOF | robert_ancell: You're not an archive admin, right? You *can't* remove a package from the archive :). | 05:01 |
| pitti | robert_ancell: there's two things to check: (1) all reverse dependencies must be gone, and (2) the package should also be removed in Debian, or we should blacklist it | 05:01 |
| StevenK | Removing packages from the archive was one of my favourite things. | 05:01 |
| pitti | these checks can be done by anyone | 05:01 |
| RAOF | But the way to do so is to file a bug against all the various packages and subscribe ubuntu-archive. | 05:01 |
| pitti | StevenK: ~ubuntu-cruft-busters! \o/ | 05:02 |
| RAOF | Also that. | 05:02 |
| robert_ancell | RAOF, ah, I was reading https://wiki.ubuntu.com/ArchiveAdministration and thinking I just needed core perms | 05:02 |
| robert_ancell | RAOF, pitti, OK I have the bugs and I've chased down the reverse-deps so I'll sub ~ubuntu-archive | 05:02 |
| RAOF | robert_ancell: I'm pretty sure that needs LP privs. (Same as you can't accept things into foo-proposed). | 05:02 |
| StevenK | pitti: Represent! | 05:04 |
| Unit193 | pitti: Upgraded to vivid just so I could get systemd user units (yes I'm aware upstart had them.) :P | 05:05 |
| infinity | pitti: Didn't that all start from the two of us sitting at a table in Montreal, whining about duplication in the archive? | 05:05 |
| infinity | Although, the cruft-busters team is much newer than our spec. :P | 05:05 |
| pitti | infinity: I can easily whine about it on any table in the world | 05:06 |
| infinity | pitti: You're so versatile. | 05:06 |
| infinity | pitti: This must be why you have a fan club. | 05:06 |
| robert_ancell | mterry is the last thing blocking Vala 0.16 (via vala-dep-scanner which looks like it too should be removed from the archive) | 05:06 |
| pitti | robert_ancell: sorry, we can't possibly remove mterry from wily | 05:07 |
| infinity | Wait, vala-0.16 is still in the archive? | 05:07 |
| infinity | It's been removed from Debian since last year. | 05:07 |
| robert_ancell | infinity, yes, I was surprised too | 05:08 |
| pitti | $ reverse-depends -b src:vala-0.16 | 05:08 |
| infinity | pitti: If we remove him, he'll just MIR himself back in. | 05:08 |
| robert_ancell | Bug 1465486, bug 1465487 and bug 1465488 for Vala 0.18, 0.20, 0.24 | 05:08 |
| ubottu | bug 1465486 in vala-0.18 (Ubuntu) "Remove from archive" [Medium,Triaged] https://launchpad.net/bugs/1465486 | 05:08 |
| ubottu | bug 1465487 in vala-0.20 (Ubuntu) "Remove from archive" [Medium,Triaged] https://launchpad.net/bugs/1465487 | 05:08 |
| ubottu | bug 1465488 in vala-0.24 (Ubuntu) "Remove from archive " [Medium,Triaged] https://launchpad.net/bugs/1465488 | 05:08 |
| robert_ancell | I figure we don't need six versions of Vala... | 05:09 |
| infinity | I suspect you're right. | 05:09 |
| StevenK | Maybe it's trying to make Python jealous | 05:09 |
| infinity | Does vala-dep-scanner have any rdeps? | 05:09 |
| pitti | vala-dep-scanner has zero reverse deps | 05:09 |
| infinity | Jinx. | 05:09 |
| pitti | so maybe we shuld just drop that along? | 05:09 |
| pitti | it's never been in Debian either | 05:09 |
| robert_ancell | v-d-s looks like an experiment that went nowhere | 05:09 |
| infinity | Yep, agreed. Punt it, if someone likes it, they can resurrect it with a newer vala. | 05:10 |
| * pitti sharpens the knife | 05:10 | |
| robert_ancell | See bug 1465484 and bug 1189642 | 05:10 |
| ubottu | bug 1465484 in vala-0.16 (Ubuntu) "Remove from archive" [Medium,Triaged] https://launchpad.net/bugs/1465484 | 05:10 |
| ubottu | bug 1189642 in vala-dep-scanner (Ubuntu) "Update vala-dep-scanner for vala-0.28 or remove from archive" [Medium,Triaged] https://launchpad.net/bugs/1189642 | 05:10 |
| infinity | pitti: Are you all over this? I was just about to start the abuse, but you're welcome to have the honours. I know how much you love deleting things. :P | 05:10 |
| pitti | infinity: we can share the love -- we have four bugs, nicely splits in half :) | 05:11 |
| * pitti is on 0.16 ATM | 05:11 | |
| infinity | pitti: No, no. Go ahead. I'm trying to make Mirv happy. | 05:12 |
| infinity | Which is, apparently, really difficult. | 05:12 |
| pitti | -16: history | 05:12 |
| * robert_ancell gets the marshmallows | 05:13 | |
| pitti | -18 is gone as well | 05:14 |
| pitti | robert_ancell: -20 has rdeps, I followed up to bug 1465487 | 05:14 |
| ubottu | bug 1465487 in vala-0.20 (Ubuntu) "Remove from archive" [Medium,Triaged] https://launchpad.net/bugs/1465487 | 05:14 |
| pitti | err | 05:15 |
| pitti | sorry, it seems UDD or so is out of date | 05:15 |
| robert_ancell | pitti, I've updated all those, not sure if they've flowed through yet | 05:15 |
| pitti | all gone | 05:17 |
| pitti | removing 4 compilers on one day? it's too good! | 05:17 |
| StevenK | pitti: Up next, gcc? | 05:17 |
| pitti | and python 2 | 05:17 |
| sarnold | and how many awks do we really need? | 05:18 |
| robert_ancell | Thanks pitti! | 05:19 |
| StevenK | pitti: Python 2 isn't a compiler, why is it on that list? :-P | 05:19 |
| StevenK | pypy on the other hand ... | 05:19 |
| robert_ancell | I did a few packages to help move python2 off the image... | 05:19 |
| robert_ancell | bye all | 05:20 |
| === Malsasa_ is now known as Malsasa | ||
| LocutusOfBorg1 | good morning | 07:26 |
| LocutusOfBorg1 | does anybody know why gdb-arm-none-eabi is built for debian but not for ubuntu? | 07:26 |
| LocutusOfBorg1 | I mean, where the hell does the gdb source come from in debian buildds? | 07:27 |
| cjwatson | gdb-arm-none-eabi build-depends on gdb-source, which is a binary package built by the gdb source package. | 07:29 |
| cjwatson | The gdb-arm-none-eabi build failure in Ubuntu just looks like it's because the patches it carries are out of sync with Ubuntu's gdb. | 07:29 |
| dholbach | good morning | 07:29 |
| LocutusOfBorg1 | thanks cjwatson :) | 07:33 |
| LocutusOfBorg1 | hi dholbach 1 | 07:34 |
| dholbach | hey LocutusOfBorg1 | 07:35 |
| tjaalton | is wily "safe" to use yet? :) | 07:57 |
| seb128 | tjaalton, no issue here or that I saw others report | 07:59 |
| seb128 | so I would say "yes" | 07:59 |
| tjaalton | cool | 07:59 |
| tjaalton | will switch my laptop to it then | 07:59 |
| seb128 | :-) | 07:59 |
| tjaalton | @pilot in | 08:12 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: wily 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: tjaalton | ||
| tjaalton | ugh | 08:12 |
| seb128 | bdmurray, hey, is that a known issue that e.u.c "channels" category stopped listing channels? | 08:31 |
| seb128 | it only has "all channels" option | 08:31 |
| seb128 | same for "rootfs" or "device image" | 08:31 |
| zyga | hey | 08:45 |
| * zyga filed a bug about those python packages that use PEP440 incompatible versions | 08:46 | |
| zyga | https://bugs.launchpad.net/ubuntu/+source/apturl/+bug/1465549 | 08:46 |
| ubottu | Ubuntu bug 1465549 in PlainBox (Toolkit) "Plainbox tests are broken by PEP 440 incompatible Debian/Ubuntu packages" [Undecided,Confirmed] | 08:46 |
| zyga | I can fix all three easily but I don't have any rights to upload them | 08:46 |
| zyga | what should I do? attach debdiffs to the bug? | 08:47 |
| === vrruiz_ is now known as rvr | ||
| zyga | juliank: can the fixed package be uploaded to vivid-updates? | 09:13 |
| juliank | Oh, I'm online. | 09:14 |
| davmor2 | juliank: or are you? | 09:14 |
| juliank | zyga: Well, vivid needs the commit cherry-picked, that'd solve the issue. There are some other commits that should be cherry picked as well, though. | 09:16 |
| juliank | The others are the same I'll propose for a stable update in Debian. They fix crashes on LFS .deb files, and a memory leak. | 09:17 |
| zyga | juliank: can you do that? I can only prepare debdiffs / patches but I have no upload rights | 09:17 |
| juliank | I have no upload rights either, but mvo has. | 09:17 |
| * juliank should work on getting upload rights | 09:17 | |
| * zyga feels the same | 09:18 | |
| zyga | mvo: how can I get upload rigths for command-not-found? | 09:18 |
| juliank | Apply for PPU | 09:19 |
| mvo | juliank, zyga: what needs sponsoring? | 09:19 |
| mvo | zyga: yeah, what juliank said | 09:19 |
| zyga | juliank: thanks, I'll check what that is (personal package uploads?) | 09:19 |
| juliank | mvo: We'll need to cherry-pick some patches from python-apt 1.0 beta to the vivid version (and the one in wily, or just push the 1.0 beta there) | 09:20 |
| zyga | mvo: I'd like to see a few PEP440 violations fixed, juliank was thinking about python-apt | 09:20 |
| cjwatson | per-package upload permissions. Ubuntu has a bad acronym habit. | 09:20 |
| zyga | is there a spec for PPU, I see lots of wikis for people (that I know) that have applied | 09:21 |
| juliank | Not sure how urgent this is, we could try to get a python-apt 0.9.3.12 uploaded to Debian stable and then merge that release + the versioning fix into vivid-updates | 09:22 |
| zyga | juliank: one by istself is not urgent but those versions do break tests in our team so we'd like to fix that over time | 09:22 |
| juliank | Let me prepare the list of other patches for python-apt (aka create a branch), so we now what we're dealing with. (It'd be useless to do two uploads) | 09:24 |
| === jincreator1 is now known as jincreator | ||
| zyga | juliank: thanks | 09:27 |
| juliank | mvo: I pushed three branches into the python-apt repository (they might still need some rebasing though). debian/jessie contains fixes for crashes and the memory leak, debian/jessie-pu fixes 2 multi-arch and 1 .dsc parsing issue (all small, but not sure whether we'll get that into Debian jessie). And finally, ubuntu/vivid, based on debian/jessie-pu, that also contains the setup.py versioning fix. | 09:44 |
| juliank | If 0.9.3.12 would get all fixes from debian/jessie-pu, then the diff for vivid-updates would be http://paste.debian.net/231237/ | 09:44 |
| * juliank probably should also strip ~ubuntu... in setup.py, but that's not needed for stable updates anyway | 09:46 | |
| mvo | juliank: neat! | 09:46 |
| juliank | The LFS patches for tarfile do not work entirely correctly, because the size members are not actually long long yet, but they still catch too large allocations instead of crashing | 09:46 |
| juliank | OK, the version number should probably be different, not sure about Ubuntu stable release update versioning | 09:47 |
| juliank | (in the paste) | 09:48 |
| infinity | 0.9.3.12ubuntu1 is sane versioning for an ubuntu update to a native package. | 09:48 |
| juliank | OK, great | 09:48 |
| infinity | Should be vivid instead of vivid-updates, but that's easy enough to fix. | 09:49 |
| juliank | OK | 09:49 |
| juliank | it was just to give an overview anyway, not final yet. | 09:49 |
| juliank | I'd use my email address for an Ubuntu update, anyway. | 09:50 |
| juliank | s/email/Ubuntu email/ | 09:50 |
| rbasak | Is there any easy way for me to detect in a maintainer script whether dpkg considers certain conffiles to have been modified? | 10:02 |
| rbasak | I know I could just scan for known md5s or something. Is there an easier way? | 10:03 |
| juliank | Back soon | 10:07 |
| rbasak | pitti: can you tell me how systemd integrates with dh_installinit please? If I use dh_installinit with --error-handler, will the error handler get called if it's actually a systemd unit that fails to start? I can't see how that would happen, nor where else I could put --error-handler. | 10:12 |
| === mvo__ is now known as mvo | ||
| pitti | rbasak: AFAIK there is no special integration -- this is simply expanded to invoke-rc.d .. || error_handler | 10:26 |
| pitti | rbasak: I have never used it myself, but according to the manpage and the template you just define a myerror() { ... } in your postinst and then dh_installinit --error-handler=myerror; this will then generate invoke-rc.d myservice start || myerror | 10:27 |
| rbasak | pitti: I'm confused because the invoke-rc.d ... start call is wrapped in if [ -x "/etc/init.d/#SCRIPT#" ] || [ -e "/etc/init/#SCRIPT#.conf" ] | 10:29 |
| rbasak | pitti: so if there weren't init.d or upstart scripts, then it wouldn't get called? So I wondered if systemd services are started from elsewhere, but I couldn't see where. | 10:30 |
| pitti | rbasak: ah, so you have a package which only ships a systemd unit, but no corresponding init script? | 10:30 |
| rbasak | pitti: in this case I think there is an init script. I was wondering about the safe thing to do in the general case. | 10:30 |
| infinity | rbasak: Given that Debian policy requires an init script, that shouldn't matter. | 10:30 |
| rbasak | Or if that meant I was missing something. | 10:30 |
| rbasak | Ah, OK. Thanks. | 10:30 |
| infinity | rbasak: Though, that may not always be true. | 10:30 |
| pitti | rbasak: the "main" service from a package should always be accompanied by an init script, by Debian policy | 10:30 |
| pitti | rbasak: for some "auxilliary" units, that's why dh_systemd_start exists | 10:30 |
| rbasak | I will write an error handler then. Thank you! | 10:31 |
| pitti | rbasak: e. g. for timers, sockets, or if the units are more fine-grained than the init script | 10:31 |
| juliank | mvo_: I asked for permission to update jessie's python-apt in https://bugs.debian.org/788928. After 0.9.3.12 gets accepted, we can merge it into vivid. | 10:54 |
| ubottu | Debian bug 788928 in release.debian.org "jessie-pu: package python-apt/0.9.3.12" [Normal,Open] | 10:54 |
| juliank | (I'll rebase the vivid branch in that case, and prepare the upload, you just need to sponsor it) | 10:55 |
| juliank | This way, everyone should be happy :) | 10:56 |
| * juliank really needs to work on https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-PPU2 so he can upload himself | 10:58 | |
| juliank | BTW, IIRC, It's called DeveloperApplication-PPU2 instead of DeveloperApplication-PPU due to a wiki issue (I think I could not rename it) | 10:58 |
| mvo_ | juliank: awesome, thanks a bunch | 11:01 |
| juliank | zyga: mvo_: I'd like to talk about command-not-found. Debian's still at 0.2.38, and Ubuntu has seen tons of ubuntu... releases on top of 0.3. A sane new upstream release would be appreciated, in case I need to update it. (I also have or had a much faster (but slightly limited) version in C somewhere I might push instead, and PackageKit has its own handler, although it's not installed yet) | 11:04 |
| juliank | I uploaded that thing 5 years ago, so it will probably be hard for me to merge the new release, as I have a bunch of changes in there. | 11:05 |
| * juliank needs to find his bzr branch from 2009 | 11:05 | |
| zyga | juliank: so there are a few options that we can explore | 11:06 |
| zyga | juliank: first of all, a reboot of the current ubuntu package, it has lots of issues and I wasn't a very effective upstream | 11:07 |
| zyga | juliank: but that was largely caused by my lack of effective way to release it to ubuntu | 11:07 |
| zyga | juliank: a C version would be appreciated (speed and ctrl+c support) | 11:08 |
| juliank | I need to see if I can find it and bring it up to the current standards. | 11:08 |
| juliank | Or just restart, it's not going to take longer than a week. | 11:09 |
| tjaalton | @pilot out | 11:09 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: wily 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: | ||
| zyga | juliank: I'm breaking for lunch, let's talk about this later | 11:11 |
| juliank | OK, I also need to do university work | 11:11 |
| === MacSlow is now known as MacSlow|lunch | ||
| === mzanetti is now known as mzanetti|run | ||
| === pgraner-dr is now known as pgraner | ||
| caribou | Does someone have a minute to help out with a merge (rsyslog) ? | 12:37 |
| caribou | I need to remove a dependency to liblogging-stdlog since it is a Universe package | 12:38 |
| caribou | but the new version introduce a slew of unit tests where some of those tests rely on that package | 12:39 |
| caribou | our previous version did not implement unit tests at all | 12:39 |
| caribou | should I just strip out each test that rely on this dependancy ? | 12:40 |
| caribou | I also have other FTBS caused by some of the tests race conditions (according to upstream's statements) | 12:41 |
| rbasak | I don't see liblogging-stdlog | 12:42 |
| rbasak | Is it new? Should it stay in universe or should it be pulled into main? | 12:42 |
| caribou | rbasak: yes, it's new in the 8.0 stream | 12:43 |
| rbasak | Ah it's liblogging-stdlog0 | 12:43 |
| === mzanetti|run is now known as mzanetti | ||
| caribou | rbasak: sorry, I cnp the --enable statement | 12:44 |
| caribou | rbasak: maybe, I just sorta followed what had been done before for other dependancies not into main | 12:45 |
| === _salem is now known as salem_ | ||
| rbasak | I've read up on what liblogging is. Sounds like it's very much a client thing, so presumably rsyslog is using it to run tests only, and it doesn't form any part of the function of rsyslog itself. | 12:46 |
| rbasak | So I guess it doesn't make sense to pull it into main unless it's necessary. | 12:46 |
| juliank | mvo_: Can you sponsor a python-apt sync for me (syncpackage -s juliank python-apt)? I'd like to see python-apt 1.0.0~beta2 in wily now, the fix from 0.9.4ubuntu1 is contained in it as well (well, I rewrote it, but achieved the same in the end). The earlier we sync, the better. | 12:46 |
| caribou | rbasak: mmnormalize, kafka, rsyslog-mongodb are also dropped because of Universe dependancies | 12:46 |
| mvo_ | sure | 12:46 |
| rbasak | caribou: I'd say drop the tests from build time. If possible, you can add dep8 tests since those can depend on stuff in universe. | 12:47 |
| caribou | rbasak: well, it is now enabled by default so I suppose it does use it somehow | 12:47 |
| caribou | rbasak: all tests or only those specific to that lib ? | 12:47 |
| rbasak | caribou: in that case I'd like to understand the consequences of not building with it, since that might have a bearing on whether we want it in main. | 12:47 |
| caribou | rbasak: ok, I'll dig a bit deeper into this | 12:48 |
| rbasak | caribou: preferably specific to that lib. If that's really awkward then maybe better to remove all and have dep8 do the full test instead? I'm not really sure about this though, would prefer a +1 from someone else. | 12:48 |
| mvo_ | juliank: done | 12:49 |
| mvo_ | juliank: lots of great fixes/features! | 12:49 |
| juliank | mvo_: Yeah, thanks. I still need to work out the new Files API for ~beta3 (or ~rc1, depending on how I feel) | 12:50 |
| caribou | rbasak: here is a short discussion b/w the debian maintainer & upstream about what that library is meant to be : http://lists.adiscon.net/pipermail/rsyslog/2014-February/036448.html | 12:54 |
| mvo_ | juliank: :) | 12:55 |
| zyga | re | 12:57 |
| === anthonyf is now known as Guest89967 | ||
| * zyga added another patch to https://bugs.launchpad.net/ubuntu/+source/apturl/+bug/1465549 | 12:58 | |
| ubottu | Ubuntu bug 1465549 in PlainBox (Toolkit) "Plainbox tests are broken by PEP 440 incompatible Debian/Ubuntu packages" [Undecided,Confirmed] | 12:58 |
| zyga | juliank: about command-not-found, I'd like to iterate on the python version | 12:58 |
| zyga | juliank: to fix some annoyances | 12:58 |
| zyga | juliank: and get the UI better | 12:58 |
| zyga | juliank: and then work on the C rewrite | 12:58 |
| === MacSlow|lunch is now known as MacSlow | ||
| zyga | juliank: (c/rust/go/$shiny) | 12:58 |
| zyga | juliank: to improve performance | 12:58 |
| zyga | juliank: but I'd like to keep the python API as strangely enough, some things call it | 12:59 |
| juliank | zyga: The patch looks wrong, is c a valid Python alternative to ~rc? | 12:59 |
| zyga | yes | 12:59 |
| zyga | juliank: it's part of PEP486 | 12:59 |
| zyga | juliank: no, wait, wrong pep :) | 13:00 |
| juliank | 440 | 13:00 |
| zyga | juliank: a - alpha, b - beta, c - candidate (rc only for python itself) | 13:00 |
| zyga | juliank: (there's another pep, I think, that defines this, apart from 440) | 13:00 |
| zyga | one sec | 13:00 |
| zyga | 386 | 13:00 |
| juliank | PEP440 only defines a b and rc | 13:00 |
| zyga | those x86 names :P | 13:00 |
| juliank | Oh no, it says Installation tools SHOULD interpret c versions as being equivalent to rc versions (that is, c1 indicates the same version as rc1 ). | 13:01 |
| zyga | that's more what I remember | 13:01 |
| zyga | https://www.python.org/dev/peps/pep-0386/#id18 | 13:01 |
| zyga | rc and c are equivalent | 13:01 |
| zyga | and c is more recommended | 13:01 |
| zyga | AFAIR | 13:01 |
| juliank | 386 is superseded, I would not refer to it. | 13:01 |
| zyga | thanks, I need to read 440 then | 13:02 |
| zyga | I should patch python-versiontools to support this | 13:02 |
| zyga | oh, and I'm always happy to see packages accepted in debian :-) woot | 13:02 |
| zyga | juliank: do you think I should keep 'rc' as rc? | 13:03 |
| zyga | juliank: I can regenerate the pathc | 13:03 |
| caribou | rbasak: reading more about it, looks like liblogging-stdlog will be more and more in use with rsyslog; might be a better choice to MIR the lib | 13:03 |
| zyga | patch | 13:03 |
| juliank | zyga: I (would) do that. The function I use for python-apt does it. It even maps ubuntu to +ubuntu, so that information is not lost either | 13:04 |
| zyga | juliank: perhaps I should move your function to python-versiontools and start patching all of those to just import it, right now that's just three packages (that I see) but if the same code needs to be copy-pasted around it doesn't look too good | 13:05 |
| rbasak | caribou: sure, if you think that's appropriate. I can't find much in rsyslog 8.9.0-3 that would be lost if built without liblogging, but maybe in the future. | 13:06 |
| caribou | rbasak: looks to me like rsyslog upstream is also the author of that library so I wouldn't be surprised if he was to make more usage of it. I'll ping him | 13:07 |
| juliank | zyga: Something like that might be a good idea (I suggested to move it to dh-python, but its maintainer was not that happy about the idea). The ~exp thing is a bit python-apt specific, though, but the rest is generic. | 13:07 |
| juliank | zyga: Also, normalized versioning now uses 1.0.alpha1 instead of 1.0a1 (with an added dot before the a), AFAICT | 13:09 |
| juliank | Not sure if a or alpha is standard | 13:10 |
| juliank | probably a | 13:10 |
| zyga | juliank: .alpha1? | 13:10 |
| juliank | so 1.0.a1 | 13:10 |
| zyga | I think a | 13:10 |
| zyga | yes, that's more like it | 13:10 |
| juliank | Oops, I might be wrong | 13:10 |
| zyga | 1.0a1 | 13:10 |
| juliank | It's far too complicated | 13:10 |
| zyga | it's not much different from pep386 -- I'm still reading 440 | 13:10 |
| zyga | it's more liberal from what I remember | 13:11 |
| zyga | but not incompatible with 386 | 13:11 |
| juliank | The dev releases have ".dev", but alpha and beta have "a" and "b" without a dot | 13:11 |
| zyga | 440 adds different version types | 13:11 |
| juliank | in the normalized version | 13:11 |
| juliank | but 1.0.a1 is accepted to | 13:11 |
| juliank | too | 13:11 |
| zyga | yes, .devN and .postN are different | 13:11 |
| juliank | just like 1.1-a1 | 13:11 |
| juliank | It's crazy | 13:11 |
| zyga | well, I think that -a1 should be different | 13:12 |
| zyga | at least if it's debian's -a1 | 13:12 |
| zyga | I would strip those out enitrely | 13:12 |
| zyga | as this fact (debian version) is almost never relevant | 13:12 |
| zyga | in fact, in all the patches that was my intent | 13:12 |
| zyga | though those are debian native packages with weird non-pythonic conventions | 13:12 |
| zyga | (e.g broken setup.py that only works via debian/rules) | 13:12 |
| juliank | Well, in native packages we don't really have the issue with -. But I prefer keeping, for example, the Ubuntu part, and map it to a local label, by prepending a + to it | 13:13 |
| zyga | yeah, it seems that local version is "debian version" in generic temrs | 13:13 |
| zyga | terms | 13:13 |
| zyga | Source distributions using a local version identifier SHOULD provide the python.integrator extension metadata (as defined in PEP 459 ). | 13:14 |
| zyga | I need to catch up on PEPs | 13:14 |
| juliank | Summary is good https://www.python.org/dev/peps/pep-0440/#summary-of-permitted-suffixes-and-relative-ordering | 13:15 |
| zyga | juliank: I agree it's complicated but it seems that the goal was to capture everything sensible that is done in reality and just standardize that | 13:15 |
| juliank | Debian version numbers are much more simple and capture more of the domain | 13:15 |
| zyga | juliank: I don't know, I'm too corrputed by exposure to both over years :-) | 13:16 |
| zyga | juliank: go ahead explain ~ : + and - vs _ to a novice ;) | 13:16 |
| juliank | I really need to work on university stuff now, I have to hand in things tomorrow. | 13:16 |
| zyga | juliank: good luck, thanks for the help! | 13:17 |
| juliank | No problem. I'll now hangout with python-ldap and see how that works.... | 13:18 |
| zyga | juliank: is that your university stuff? | 13:18 |
| juliank | Part of it | 13:18 |
| juliank | Learning ldap | 13:19 |
| === pete-woods1 is now known as pete-woods | ||
| juliank | zyga: One thing I do today is for a lecture about distributed systems. Part of it this week is LDAP. | 13:20 |
| zyga | juliank: when does it start? ;-) | 13:20 |
| juliank | distributed systems is a fun lecture, much like networks I had last year. | 13:20 |
| * zyga makes silly distributed systems what-time-is-it jokes | 13:20 | |
| juliank | zyga: Well, that's just the homework. | 13:21 |
| juliank | I also need to do university work work stuff sometime, though | 13:21 |
| * juliank works 10 hours / week at university. Could use something else 10 hours a week instead ... | 13:22 | |
| zyga | juliank: working at the university or remotely? | 13:22 |
| * zyga likes his university days | 13:22 | |
| juliank | zyga: I'm helping students with programming an Android app 4 hours a week at the university (aka sit around and wait for a question, last week I worked on python-apt during work time), and the rest I'm at home and don't have much work to do. | 13:23 |
| juliank | It's a boring job :) | 13:24 |
| juliank | Gives me some time to work on open source | 13:24 |
| zyga | juliank: perhaps, I cannot relate to that -- though I think some questions may be eye-opening :) | 13:24 |
| juliank | s/open source/free software/ | 13:24 |
| juliank | I'm happy that I can solve the LDAP exercise in Python (although only Python 2, unfortunately) and don't have to use Java. | 13:25 |
| juliank | Oh, there's a python3-ldap3 package. | 13:26 |
| juliank | Because two threes are better than one? | 13:26 |
| zyga | juliank: because apis and packages perhaps | 13:26 |
| juliank | Ah entirely different software. | 13:27 |
| * zyga updates his RTM phone to vivid, \o/ | 13:27 | |
| bdmurray | seb128: The channels don't display if you are not logged in. | 13:46 |
| kamal | @pilot in | 13:59 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: wily 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: kamal | ||
| LocutusOfBorg1 | mterry, seems that unity-scope-click is blocking libjsoncpp migration | 14:04 |
| mterry | LocutusOfBorg1, https://code.launchpad.net/~mterry/unity-scope-click/missing-iostream/+merge/262035 | 14:04 |
| LocutusOfBorg1 | holy sh*t you rock man | 14:05 |
| LocutusOfBorg1 | I was downloading the source | 14:05 |
| LocutusOfBorg1 | thanks! | 14:05 |
| LocutusOfBorg1 | dholbach, do you mind syncing libserial from debian? :) | 14:05 |
| mterry | LocutusOfBorg1, :) | 14:06 |
| LocutusOfBorg1 | or kamal if you are patch piloting ;) | 14:06 |
| kamal | LocutusOfBorg1, I'm on patch pilot duty, but I don't have upload rights (afaik!), so afraid I can't actually do so | 14:08 |
| dholbach | kamal, just for the kernel packages, right? | 14:08 |
| kamal | dholbach, correct (I only have upload rights for kernel) | 14:08 |
| dholbach | ok... the review/pilot duties are then a special case as discussed with the kernel team ages ago :) | 14:09 |
| kamal | dholbach, yup, I'm just here because my calendar says I'm supposed to be here :-) | 14:10 |
| dholbach | LocutusOfBorg1, looking at it now | 14:11 |
| caribou | rbasak: turns out that the one test is easily fixed with conditionals so I can still use it. | 14:15 |
| caribou | rbasak: I sent an email upstream to know is future plans | 14:15 |
| dholbach | LocutusOfBorg1, done | 14:16 |
| dholbach | LocutusOfBorg1, I won't have time to look into other sponsoring items today though | 14:17 |
| LocutusOfBorg1 | no problem dholbach, thanks! | 14:18 |
| dholbach | anytime | 14:18 |
| === Guest68660 is now known as mfisch | ||
| === mfisch is now known as Guest81226 | ||
| rbasak | caribou: great. Thanks! | 14:33 |
| caribou | rbasak: wow, Rainer has already replied | 14:33 |
| juliank | mvo__: Oh I see, python-apt failed the autopkgtest because of deprecation warnings in the test you added for checking that the deprecated argument works :( - They're somehow shown by default during autopkgtest | 14:36 |
| juliank | Python3 has assertWarns, but Python2 does not | 14:37 |
| juliank | I'm fixing it | 14:38 |
| === davidcalle_ is now known as davidcalle | ||
| juliank | mvo_: Fixed in debian/sid | 14:41 |
| juliank | It now uses catch_warnings to catch the warning and record it, and then asserts that the use of the md5 parameter caused a DeprecationWarning | 14:42 |
| juliank | :) | 14:42 |
| juliank | My editor misdetected the indentation , I'll fix that too | 14:44 |
| juliank | I can either push a ~beta3 to unstable and we resync, or we just push out an ~beta2ubuntu1 release for now | 14:49 |
| juliank | We should make our testing more strict to also fail on stderr during package build, I believe the buildds showed the warning too | 14:50 |
| juliank | No they did not. Strange. | 14:51 |
| juliank | That is, we could use warnings.simplefilter('error') or something in test_all | 14:54 |
| juliank | Oh well, an error filter does not allow me to use catch_warnings. | 14:55 |
| juliank | and it does not raise any exception if used in a catch_warnings block | 14:55 |
| juliank | ... | 14:55 |
| === mfisch is now known as Guest25676 | ||
| zyga | juliank: for python2 you can use unittest2 | 14:58 |
| zyga | juliank: it has assertWarns and the zoo of new features | 14:58 |
| juliank | Well, I used catch_warnings manually. Better than adding a build-time dependency. | 14:58 |
| zyga | juliank: yep, it's typically something upstreams should adopt | 14:59 |
| zyga | juliank: for command not found in debian, I'm scared of building the hints database | 15:01 |
| === Guest25676 is now known as mfisch | ||
| zyga | juliank: for ubuntu I did it manually on my machine after downloading 50GBs of the archive | 15:02 |
| juliank | zyga: Well in Debian, we download Contents files and build from that with a command in the package. | 15:02 |
| zyga | juliank: and I'd like that process to be separate from the upstream hacking on the tool itself | 15:02 |
| zyga | kgunn: oh | 15:02 |
| zyga | juliank: oh | 15:02 |
| zyga | juliank: contents is insufficient | 15:02 |
| juliank | zyga: That's true, but it's all we get for now. | 15:02 |
| zyga | juliank: you need postinst scripts and metadata (symlink, mode) that is AFAIR not there | 15:02 |
| juliank | zyga: ftpmaster did not want the hints thing packaged | 15:02 |
| zyga | juliank: ah, ok | 15:02 |
| zyga | juliank: what? | 15:02 |
| zyga | juliank: why not | 15:02 |
| juliank | Well, I split it into its own package, which probably was the main factor (so we could have shared the main c-n-f package), but even in the same package, I'm not sure they would have liked it, because it gets outdated to quickly. | 15:03 |
| zyga | juliank: I somewhat agree with them | 15:04 |
| zyga | juliank: ideally, it would be a bit of meta-data that one can harvest easily | 15:04 |
| juliank | So, only contents files for now, until we have the proper metadata in the archive. | 15:04 |
| zyga | juliank: and declarative | 15:04 |
| juliank | That's WiP | 15:04 |
| zyga | juliank: not just random insanity like guessing from postinst scripts | 15:04 |
| juliank | zyga: Adding metadata is ximion's show | 15:05 |
| zyga | ximion: tell me about it, I'm very interested in this | 15:05 |
| ximion | metadata what? metadata where? ;-) | 15:05 |
| * ximion reads backlog | 15:05 | |
| zyga | ximion: declarative list of executables per package | 15:06 |
| Laney | X-Metadata-Lover: ximion | 15:06 |
| zyga | ximion: and handling stuff like vim using alternatives | 15:06 |
| zyga | ximion: and divertions | 15:06 |
| zyga | ximion: so that common (but hard) cases are supported | 15:06 |
| zyga | juliank: one other thing that is problematic is knowing the right package to install | 15:06 |
| zyga | juliank: often a -bin or -common package is the one that has the executable | 15:06 |
| zyga | juliank: but the foo (not foo-bin) should be installed for good upgrades | 15:07 |
| zyga | juliank: I'd love to have this at the meta-data layer as well | 15:07 |
| zyga | juliank: and lastly, I want "gcc", there are 1234 versions of gcc avaialble and the hint should be smart there, the "smarts" should be declarative | 15:07 |
| zyga | (coffee) | 15:07 |
| juliank | Well, it should simply install the default gcc, obviously. Which is in the gcc package | 15:08 |
| zyga | juliank: or mabe pentium-builder | 15:08 |
| zyga | juliank: or maybe the package names are not a hint at all (gcc is a symlink or something like alternative) | 15:09 |
| zyga | juliank: obviously is not good, it has to be an algorithm :) | 15:09 |
| zyga | juliank: or if it's manual, it has to be a packaging-level declarative hint | 15:09 |
| ximion | zyga: about gcc I agree with juliank. About binary-fetching, that is in-scope for DEP-11/AppStream, and could be added to it at a later stage (we need to see how much overhead it would be to add this information to every metadata) | 15:09 |
| zyga | ximion: I read dep 11 a while ago, how close is that to reality? | 15:10 |
| juliank | I do *not* want pentium-builder if I ask for gcc. The algorithm should take the command - package name distance into account when finding a package | 15:10 |
| zyga | ximion: (I actually had some of that in one of my first packages but my sponsor asked to remove the meta-data) | 15:10 |
| juliank | distance to package names is always a good idea. | 15:11 |
| zyga | juliank: that's google's business | 15:11 |
| zyga | juliank: it's hard problem | 15:11 |
| zyga | juliank: and gcc is the bad example as some packages are widely different | 15:11 |
| ximion | zyga: at Debian: very close, I am running the data generator there, and I hope I can soon switch it to automatic mode. The remaining bits are archive integration then (pull the data into the apt repo) and Apt integration, where all the groundwork has already been done by mvo's GSoC student a while ago, AFAIR | 15:11 |
| zyga | juliank: and command and package names will actually worsen the result (suggesting other packages) | 15:11 |
| * zyga has gone that way | 15:11 | |
| ximion | at Ubuntu, I have no idea yet | 15:11 |
| zyga | ximion: wait, I'm lost one one thing, can I use the new provides syntax today or not? | 15:12 |
| juliank | zyga: You just need to calculate the Levenshtein distances between the command and the package names and choose the smallest as the best option | 15:12 |
| zyga | ximion: and do I understand that it's still needed to patch all the packages to declare this correctly | 15:12 |
| zyga | juliank: it's crap, I tried that | 15:12 |
| zyga | juliank: really | 15:12 |
| zyga | juliank: I spent a year just on this part of c-n-f | 15:12 |
| zyga | juliank: and it's utter crap in the end | 15:12 |
| zyga | juliank: you need way more context to produce hints that are not silly | 15:13 |
| zyga | juliank: and you want to still have fast lookup | 15:13 |
| juliank | What? *If you know* that the file is in a few packages, choosing the one with the closest distance is the best idea. | 15:13 |
| zyga | juliank: (though I'm sure there are structures that answer this quickly) | 15:14 |
| zyga | juliank: I see what you mean but the problem is that it's not good in general | 15:14 |
| ximion | zyga: no, it's not yet usable to the full extend. It's enough though to power GNOME-Software, if you do a little bit of manual work | 15:14 |
| zyga | juliank: gcc is just one example | 15:14 |
| zyga | ximion: ok, so I can use it today? | 15:15 |
| juliank | It may fail on some cases, but in most it should work just fine. | 15:15 |
| zyga | ximion: and then this gets aggregated by some archive | 15:15 |
| ximion | zyga: no, a lot of data can be extracted automatically - but for really rich metadata, you need to drop a little bit of XML into /usr/share/appdata | 15:15 |
| zyga | ximion: (cnf should also be offline, if it is online we can just ask google each time) | 15:15 |
| juliank | awk is a silly example, because both mawk and gawk have the same distance | 15:15 |
| zyga | juliank: I think this is highly subjective but the value is in _useful_ hints, not theory, IMHO non-declarative or weighted declarative approaches for that are not worth the trouble as the advice is just poor and the extra cost is large | 15:16 |
| zyga | ximion: ok, for the trivial cases dep-11 is not an improvement | 15:16 |
| juliank | It's extracted from packages and XML in packages, and put into a YAML (?) index that APT will download. You/It then parse the index and create a database | 15:16 |
| juliank | The difficult cases need to be declared manually then | 15:17 |
| ximion | zyga: https://github.com/ximion/dep11 - careful though, the code has some very awkward bits which I intend to improve soon. Reason is its past as integral DAK component and GSoC work | 15:17 |
| zyga | ximion: it is an improvement for cases like vim, that are actually quite complex and rely on alternatives | 15:17 |
| zyga | ximion: and that naive harvesters cannot process | 15:17 |
| zyga | ximion: the harvester in cnf is one level above naive | 15:17 |
| zyga | ximion: so dep11 has to be better in practice if it can be adopted as a data source | 15:18 |
| ximion | zyga: for the immediate use, I'd stick to c-n-f - it does a reasonably good job :) (don't have enough backlog to fully understand the issues you have with it) | 15:18 |
| * zyga looks at the link | 15:18 | |
| juliank | zyga: Try taking popcon into account as well, that might help. Algorithms. Get a few drunk Google search people to help you. | 15:18 |
| zyga | ximion: the issue is that 1) harvesting requires the full archive 2) it's a heruistic as many "interesting" packages use scripts to actually create executables and simple scans don't reveal those | 15:18 |
| * juliank is not sure if you can drink and develop search algorithms | 15:18 | |
| zyga | juliank: is popcon data available offline | 15:18 |
| ximion | zyga: the python-dep11 stuff just generates the metadata. To access it, you can use "appstream-index search <blah>", or whatever the tool hughsie wrote for appstream-glib is called | 15:19 |
| juliank | zyga: You'd obviously fetch it once. | 15:19 |
| zyga | juliank: I strongly oppose online searches as this basically turns cnf into a different product/service (which is not bad, just different) | 15:19 |
| juliank | and from time to time | 15:19 |
| zyga | ximion: I see, so ... | 15:19 |
| juliank | that is, when apt-get update runs | 15:19 |
| zyga | ximion: so to get a replacement dataset for cnf | 15:19 |
| zyga | ximion: I'd still have to do this locally and then regenerate a big -data package | 15:20 |
| zyga | ximion: (well not big but non-trivial) | 15:20 |
| zyga | ximion: and that would work for debian and ubuntu down the line later | 15:20 |
| zyga | ximion: I'd preferrably have a python or ctypes python api though I can probably make that (gi should work) | 15:20 |
| juliank | Well no, APT get will download the DEP-11 metadata. You'd parse it in a post-download hook and generate a cache locally on the client (or use the appstream library) | 15:21 |
| juliank | s/APT get/APT/ | 15:21 |
| zyga | ximion: do you accept pep-8 clenup patches? | 15:21 |
| ximion | zyga: I accept all reasonable patches | 15:21 |
| ximion | ....and PEP-8 cleanup is highly welcomed! | 15:21 |
| ximion | need to fire it at the code again soon anyway, after the dust has settled | 15:22 |
| juliank | We need a newer pep8 version in the archives | 15:22 |
| * ximion plans to rip out some really bad design issues and dak-isms to make it nicer to use by 3rd-parties outside Debian | 15:22 | |
| juliank | zyga: barry: Any idea how to translate 1.0~ubuntu1 to PEP440 version numbers? Not really possible, right? | 15:23 |
| juliank | 1.0 and the 1 just chosen as an example | 15:23 |
| zyga | juliank: hmm, perhaps to 1.0c1 | 15:23 |
| zyga | juliank: but yeah, .preN doesn't exist, I think | 15:23 |
| zyga | ximion: as a good sanity check, make the package pip-installable on something totally non-debian | 15:24 |
| juliank | What I am saying is: I miss a local label for sort of pre-versions | 15:24 |
| ximion | zyga: and APT will later know about DEP-11 and will download it on-demand. We can then read the data directly, or use the cache which will be automatically updated (Xapian is fast as hell \o/) | 15:24 |
| zyga | juliank: I'd just ignore it TBH | 15:24 |
| zyga | juliank: most of the time it's not relevant | 15:24 |
| * zyga hatex xapian | 15:24 | |
| zyga | slow as hell to update | 15:25 |
| barry | 1.0rc1 i think | 15:25 |
| juliank | ximion: Downloading code is in. | 15:25 |
| zyga | brb | 15:25 |
| juliank | in DonKult's branch | 15:25 |
| juliank | For arbitrary indices | 15:25 |
| juliank | in an archive | 15:25 |
| ximion | zyga: then you haven't met the appstream-index tool ;-) | 15:26 |
| ximion | juliank: I know, mvo told me :) | 15:26 |
| * juliank does not like xapian either, because C++ | 15:27 | |
| juliank | which is not good for minimal solutions. | 15:27 |
| juliank | But otherwise, it's good. | 15:27 |
| barry | at least there are rumors that xapian is now py3 compatible | 15:27 |
| juliank | barry: Is Python 3 all you can think about? | 15:28 |
| juliank | ;) | 15:28 |
| zyga | ximion: I think that xapian should warrant the move to online queries | 15:28 |
| zyga | ximion: but if you look at other OSes xapian is very bad in comparison :/ | 15:28 |
| zyga | barry: yeah, I heard that too | 15:28 |
| barry | juliank: what else is there in life? | 15:28 |
| zyga | but it's still slow and bloated | 15:29 |
| juliank | barry: Music | 15:29 |
| zyga | for what it does | 15:29 |
| barry | juliank: my bass is py3 compatible | 15:29 |
| juliank | zyga: Well, you could parse the indices yourself and generate your own database. | 15:29 |
| juliank | zyga: It'll be cool and awesome. | 15:30 |
| zyga | juliank: I still think that offline package generated by something like the repo itself (replace repo with something on the server side) is better | 15:31 |
| ximion | zyga: if you think of apt-xapian-index, it might be slow, but appstream-index beats most other tools in performance and memory usage (it's also 99% C code). Richard's appstream-glib uses the XML/YAML directly without cache, implementing a custom XML parser which does some pretty crazy things to be really, really fast | 15:31 |
| zyga | juliank: as downloadin a small update vs computing this over and over on memory-constrained devices (and slow devices) feels like the wrong tradeoff | 15:31 |
| juliank | There's no large difference between a package an an index. | 15:31 |
| juliank | With such an index, computation is not an issue | 15:32 |
| zyga | ximion: I haven't played with a-i, I'll check it out | 15:32 |
| ximion | so, no matter how you access AppStream/DEP-11 data, it will not really take long ;-) | 15:32 |
| zyga | ximion: cnf is slow | 15:32 |
| zyga | ximion: I'd like to give hints in 30ms | 15:32 |
| zyga | ximion: that would warrant rewrite to C | 15:32 |
| zyga | ximion: (rust/go/$shiny) | 15:32 |
| juliank | cnf is slow. TheC version takes < 10 ms IIRC | 15:32 |
| zyga | ximion: and proper databases | 15:32 |
| zyga | juliank: yeah, python start-up is just slow for that | 15:33 |
| ximion | yes indeed, C would be a much better fit for cnf | 15:33 |
| zyga | juliank: no doubt about that | 15:33 |
| zyga | I think one of the oldest versions of CNF were written in C | 15:33 |
| zyga | but I didn't publish that | 15:33 |
| zyga | then I rewrote it to vala | 15:33 |
| juliank | It's more crazy on HDDs and uncached. | 15:33 |
| zyga | but one of the bits were missing a .vapi and I didn't know how to make the lacking parts | 15:33 |
| zyga | the last thing I did is a dbus service | 15:33 |
| zyga | where it would spawn and sit around | 15:34 |
| juliank | Oh god, no dbus | 15:34 |
| zyga | that was actually neat | 15:34 |
| zyga | but yeash | 15:34 |
| zyga | and then it was impossible to shutdown dbus services reliably | 15:34 |
| zyga | on idle | 15:34 |
| juliank | Just a simple hash db like now, and a C frontend. | 15:34 |
| zyga | now with systemd it is, but that was long ago | 15:34 |
| zyga | juliank: some things (spell checks) are cpu and db heavy | 15:34 |
| zyga | juliank: I think the current DB is not good for that | 15:34 |
| zyga | juliank: or the hash db has to have misspellings but that's crazy | 15:35 |
| juliank | Well, then you need either xapian or sqlite3 | 15:35 |
| zyga | juliank: a hybrid db would be better (hybrid == different DBs) | 15:35 |
| juliank | those can match related words | 15:35 |
| zyga | juliank: I wasn't aware sqlite has that feature, do you have any hints? | 15:36 |
| ximion | can KyotoCabinet match similar phrases? | 15:36 |
| zyga | (currently cnf just generates more queries0 | 15:36 |
| juliank | KyotoCabinet might be nice too | 15:37 |
| zyga | juliank: looking at the api it doesn't seem to | 15:37 |
| zyga | juliank: unless you want to just walk the keyspace and run conversions | 15:37 |
| juliank | Well, it's a B+ Tree | 15:38 |
| zyga | yeah | 15:38 |
| zyga | I did a project a decade ago | 15:38 |
| zyga | that has some value | 15:38 |
| zyga | but it does require an offline processed database index | 15:38 |
| zyga | though | 15:38 |
| zyga | one small observation | 15:38 |
| zyga | even if each debian package has 10 executables | 15:39 |
| juliank | I think sqlite3's full-text-search engine has a feature to match misspelled words, but I'm not sure | 15:39 |
| zyga | that is still _very little_ data to compute | 15:39 |
| juliank | But I think it's overkill and the current version works well enough. | 15:39 |
| zyga | and I think just runing a very fast routine on _everything_ is faster than anything else fancy | 15:39 |
| juliank | People won't run command-not-found on phones | 15:39 |
| zyga | a list of just the keys (executable names) | 15:39 |
| zyga | that list is probably around a meg or two | 15:40 |
| zyga | juliank: try raspberry pi | 15:40 |
| zyga | juliank: slow CPU, slow IO | 15:40 |
| juliank | I'm basically happy with the state I have in Debian's 0.2.38. | 15:40 |
| * zyga hasn't used cnf on debian yet | 15:40 | |
| juliank | zyga: Why would you want to run stuff there in an interactive terminal? | 15:41 |
| zyga | juliank: I do all the time :) | 15:41 |
| juliank | You should just deploy your finalized container there.... | 15:41 |
| * juliank had to mention containers once in his lifetime | 15:41 | |
| zyga | juliank: I use it for tinkering and on-device hacking, different use case, it's not a server | 15:41 |
| zyga | heh :D | 15:41 |
| juliank | I think Vala is a good language, but it's a bit overly complex for something as simple as command-not-found. | 15:43 |
| juliank | No need for object orientation and friends. | 15:43 |
| juliank | zyga: The hard-core version is to create a domain-specific library in C++ and then create C++ code from the archive and compile the entire database into the executable. | 15:44 |
| juliank | That would be insanely fast. | 15:44 |
| zyga | juliank: with my love for C++ that's not likely, I'll probably use C for the fast version | 15:45 |
| zyga | juliank: for the database, not sure | 15:45 |
| juliank | We don't want something exotic. | 15:45 |
| juliank | It should be priority: standard or important or required | 15:46 |
| zyga | juliank: I agree | 15:46 |
| zyga | juliank: I think just running the exact same stuff in C will be great | 15:46 |
| juliank | It will. | 15:47 |
| juliank | There are not many alternatives anyway. You could switch to berkeley db, sqlite3 or xapian. | 15:47 |
| jrwren | zyga: i remove xapian. :) Who needs it? | 15:47 |
| juliank | Nothing is going to improve a lot. | 15:47 |
| zyga | separate problem, first let's revive the upstream code | 15:48 |
| zyga | and dedupe forks and whatever | 15:48 |
| zyga | so that there's one code to work on | 15:48 |
| juliank | zyga: BTW, The thing with the spelling corrections is: The DBs use stemming algorithms for it. That won't work well on packages. | 15:49 |
| zyga | juliank: ah, yeah, package names can be hostile | 15:49 |
| juliank | or well, command names. | 15:49 |
| juliank | zyga: Just take the 0.3ubuntu15.1 release and call it 0.3.1? Then move the data out of the package, so mvo or a bot can update it automatically | 15:51 |
| zyga | juliank: yep, that's a good first step | 15:51 |
| juliank | That is, have a command-not-found source package and a command-not-found-data package. | 15:51 |
| juliank | source package. | 15:51 |
| zyga | juliank: oh, that is true today | 15:51 |
| zyga | juliank: but those are binary packages | 15:51 |
| zyga | juliank: I think what you are asking for are source packages | 15:51 |
| zyga | juliank: that would make sense | 15:52 |
| juliank | Right, yes | 15:52 |
| juliank | Then you have sane releases of code. | 15:52 |
| zyga | juliank: one thing I don't know how to do is where to keep the git tree, I'm used to svn based python workflow in debian | 15:52 |
| zyga | and I love git | 15:52 |
| juliank | And can just version the data in a sane way, such as 15.10.20150403 | 15:52 |
| zyga | but I don't know how to get a collab maint git repo in debain | 15:52 |
| zyga | debian | 15:52 |
| juliank | zyga: Launchpad also has limited git support now. | 15:53 |
| zyga | juliank: I know that very well (using it) | 15:53 |
| juliank | zyga: But collab-maint is easy. You just need to join the group in alioth | 15:53 |
| barry | zyga: it's pretty easy | 15:53 |
| barry | zyga: well, alioth is | 15:53 |
| zyga | give me a sec | 15:53 |
| juliank | And then you ssh to alioth and run a command | 15:53 |
| zyga | ok, I've sshd to alioth | 15:53 |
| zyga | now what? | 15:54 |
| juliank | https://wiki.debian.org/CollaborativeMaintenance | 15:54 |
| juliank | zyga: cd to /git | 15:54 |
| barry | zyga: if it's dpmt: https://wiki.debian.org/Python/GitPackaging | 15:55 |
| juliank | No wait. | 15:55 |
| juliank | There was a shell script somewhere | 15:55 |
| juliank | https://wiki.debian.org/Alioth/Git | 15:56 |
| kamal | zyga, juliank: https://wiki.debian.org/Alioth/Git | 15:56 |
| kamal | yeah. that. :-) | 15:56 |
| zyga | daughter emergency | 15:56 |
| juliank | zyga: Easiest way: Run gbp create-remote-repo from your source tree | 15:56 |
| zyga | crying because jurrasic world is not good for 6 year olds | 15:56 |
| zyga | juliank, barry, kamal: thanks, I'll give that all a try in a sec | 15:57 |
| zyga | as soon as I can :) | 15:57 |
| juliank | Oh cool, my 0.2.38-1 package has proper patches. | 15:59 |
| juliank | zyga: My idea would be to have the code + update from Contents file thing upstream, and installing update-command-not-found on !ubuntu (depending on command-not-found-data in Ubuntu instead). This way, we can have one command-not-found package synced between Debian and Ubuntu. | 16:04 |
| juliank | Not even have to merge it. | 16:04 |
| juliank | Ubuntu just provides the additional command-not-found-data source and binary package and everyone is happy. | 16:05 |
| juliank | (Maybe also ship update-command-not-found in Ubuntu for third-party repositories) | 16:05 |
| === salem_ is now known as _salem | ||
| zyga | juliank: that sounds good to me (still not here yet) | 17:37 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| mhall119 | cjwatson: pitti: mdeslaur: and any other dual Ubuntu/Debian developers, I've been asked for somebody from the Ubuntu side to comment on https://lists.debian.org/debian-derivatives/2015/06/msg00021.html about how we manage the same process (porting patches back to Debian) | 18:58 |
| mdeslaur | mhall119: I use submittodebian, I don't have anything further to contribute to that discussion beyond that | 18:59 |
| mhall119 | mdeslaur: is that an ubuntu-specific tool? | 19:00 |
| mdeslaur | mhall119: yeah, it's in the ubuntu-dev-tools package | 19:01 |
| mhall119 | mdeslaur: you might just mention that it exists and what it does, maybe it's something rasbian can use | 19:01 |
| * mdeslaur googles "rasbian" | 19:02 | |
| mhall119 | raspbian actually | 19:02 |
| * mdeslaur googles "raspberry pi" | 19:02 | |
| mhall119 | it's Debian for Raspberry pi | 19:02 |
| mhall119 | what rock have you been under? | 19:03 |
| dobey | a securely reinforced one, i hope | 19:04 |
| mdeslaur | mhall119: I'm old. When I was in school, our boards had 6809's on them. | 19:05 |
| mhall119 | when I was in school, our boards were black and required chalk :-P | 19:05 |
| mdeslaur | hehe | 19:06 |
| zyga | mhall119: ah, the best kind | 19:06 |
| mhall119 | zyga: meh, the I/O throughput left a lot to be desired | 19:06 |
| zyga | mhall119: I'll take that over whiteboards any day | 19:06 |
| sarnold | that "new chalk smell" tho | 19:06 |
| === _salem is now known as salem_ | ||
| mhall119 | some classrooms even had dual-board technology: http://aarco.com/05B.gif | 19:08 |
| sarnold | banked memory! sweet! | 19:08 |
| mdeslaur | wow, fancy :) | 19:08 |
| mdeslaur | you went to one of those expensive schools by the looks of it :) | 19:09 |
| mhall119 | only problem was that whenever you tried to delete something, you invariable ended up with data all over your hands | 19:10 |
| jrwren | i/o throughput on rpi isn't that great either ;) | 19:11 |
| mhall119 | jrwren: so I've heard :) | 19:12 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === anthonyf is now known as Guest41199 | ||
| === athairus is now known as afkthairus | ||
| kamal | @pilot out | 20:39 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: wily 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: | ||
| === afkthairus is now known as athairus | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| juliank | Guys, anyone still here (barry?? I'm not sure what's happening: Our Python extension is producing a DeprecationWarning. I want to catch that in the unittests (did not check previously). Now, on the build daemons, the warning is not issued (those the new assert fails), but on autopkgtests it is (previously failed because warning was printed) | 20:59 |
| juliank | What's the best way out this? Pass -Wall to our test script in both enviroments? | 20:59 |
| juliank | I mean, I'm not entirely sure why the DeprecationWarning is issued on autopkgtest, but not on the build servers. That does not make sense to me | 21:01 |
| * juliank just got the report from the daily PPA build, that's why he's asking now | 21:02 | |
| infinity | juliank: The warning is so issues on the build daemons. | 21:08 |
| juliank | so issues? | 21:08 |
| infinity | juliank: The only difference here is that you can spew whatever you want to stderr in a build log and we don't care, but autopkgtest's default is to fail on stderr. | 21:08 |
| ogra_ | some ? | 21:08 |
| ogra_ | :) | 21:08 |
| infinity | s/issues/issued/ | 21:08 |
| infinity | /build/buildd/python-apt-1.0.0~beta2/tests/test_paths.py:46: DeprecationWarning: Using the md5 keyword is deprecated, please use 'hash' instead | 21:09 |
| infinity | md5="abcdef") | 21:09 |
| infinity | I see that in your build log. | 21:09 |
| infinity | The same warning that's killing adt. | 21:09 |
| juliank | infinity: No, it does not show at all. Python disables it by default, but the autopkgtest server seems to enable it. | 21:09 |
| juliank | infinity: Well, strange. On the PPA, the build failed, because no warning was issues: https://launchpadlibrarian.net/209249914/buildlog_ubuntu-vivid-amd64.python-apt_1.0.0~beta2%2B866~ubuntu15.04.1_BUILDING.txt.gz | 21:09 |
| infinity | juliank: I'm staring at a build log right now with the warning in it... | 21:09 |
| juliank | This assertion checks that a warning was issued. | 21:09 |
| infinity | https://launchpadlibrarian.net/209219612/buildlog_ubuntu-wily-amd64.python-apt_1.0.0~beta2_BUILDING.txt.gz | 21:09 |
| juliank | Right. That was the old version. We did not catch the warning there. We catch now, and the PPA build fails. | 21:10 |
| infinity | juliank: Okay, so this isn't about a difference between a buildd and adt, this is about your code changing. :) | 21:11 |
| infinity | juliank: And catching warning implies not printing them, I suspect. | 21:11 |
| infinity | Just like any other caught exception. | 21:12 |
| juliank | Yes, that's the point. I'm not sure why it cannot catch the warning (I assume it does not produce two warnings, I check for len(warnings) == 1) | 21:12 |
| juliank | if it was issued previously, it should be now | 21:12 |
| juliank | Anyway, I think I'll just add -Wall everywhere and it should work | 21:12 |
| infinity | juliank: Okay, maybe I'm misunderstanding. I assumed you were talking about the production adt, which was printing the same warning as the production buildd on the same version. | 21:12 |
| juliank | Or does someone have a better idea? | 21:12 |
| infinity | juliank: And the PPA build, of course, is catching and not printing the warning, but asserting instead, which seems to be what you asked it to do. | 21:13 |
| juliank | infinity: The autopkgtest on 1.0.0~beta2 failed because it wrote the warning. Now I'm trying to fix that. I catched the warning and assert that it's there. But during the build, it suddenly is not there anymore according to the PPA builder (or 2 warnings were issued inside the block, which seems unlikely). | 21:13 |
| juliank | I checked that precisely one warning is issued and that it has the type deprecationwarning | 21:14 |
| infinity | juliank: Okay, but this has nothing to do with how buildds are calling/building it, as can be seen by the version in the archive whose output matches the adt run. | 21:14 |
| juliank | But how do those buildds and adt call it to enable the warning? Maybe there's a difference to PPA builders (Debian buildds do not show the warning either) | 21:15 |
| infinity | juliank: They do nothing special. It's just dpkg-buildpackage | 21:15 |
| juliank | But it's strange. On 1.0.0~beta2, the same version. The Ubuntu buildds show a DeprecationWarning and the Debian ones don't | 21:16 |
| juliank | Let me check how previous PPA builds went | 21:16 |
| juliank | The old PPA build issued the warning too | 21:17 |
| infinity | juliank: Debian buildds appear to skip your testsuite entirely because sources.list isn't readable. | 21:17 |
| infinity | juliank: So, not a useful datapoint. | 21:17 |
| juliank | True | 21:18 |
| juliank | But still, that commit http://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=12b0e06cb6db76e60455d13269e6ff3fedab5812 should catch precisely the warning and check for it. | 21:18 |
| juliank | Is there any danger in passing -Wall to python? | 21:19 |
| infinity | I'm not a python guy, don't know. | 21:20 |
| infinity | juliank: So, if I'm reading https://docs.python.org/2/library/warnings.html right, the warning filter ignores DeprecationWarning by default. | 21:23 |
| juliank | Yeah, but it somehow shows up on the buildds and on autopkgtest | 21:23 |
| juliank | That's the reason I'm wondering | 21:23 |
| infinity | juliank: Not a python guy, but I assume they mean the fancy filter, ie: the one you just added to catch your warnings. | 21:24 |
| infinity | Maybe not, though. I dunno. | 21:24 |
| juliank | If I run it locally, it works with -Wall (the warning is issued and catched (previous behavior as it was on buildd)). Without -Wall, the warning is not issued and not caught | 21:25 |
| juliank | But now, it is not caught on the buildds, despite being printed in previous builds. | 21:26 |
| juliank | Which is crazy | 21:26 |
| infinity | I would have assumed that's a byproduct of you importing the class and mucking with it. | 21:26 |
| infinity | juliank: 28.6.4 seems relevant on that page. | 21:28 |
| infinity | juliank: I think you just need a 'warnings.simplefilter("always")' before you trip your warning. | 21:28 |
| infinity | juliank: But that exact code example is exactly what you want to do, so a bit of copy and paste should do it. | 21:28 |
| infinity | https://docs.python.org/2/library/warnings.html#testing-warnings | 21:29 |
| juliank | Ah right | 21:29 |
| juliank | Missed that bit | 21:29 |
| juliank | Thanks, infinity | 21:29 |
| juliank | Fixed in git. Started an import in launchpad, and will then trigger a PPA build again. | 21:38 |
| juliank | If it works, I'' do a beta3 tomorrow | 21:39 |
| robert_ancell | How to I get valac-0.28 into main? Since nothing explicitly depends on it is there some override that brings it in like valac-0.26? | 22:06 |
| juliank | Oh yes, it build! | 22:13 |
| infinity | robert_ancell: You don't. | 22:31 |
| infinity | robert_ancell: Not until the default vala version (defined by who builds the valac binary) changes. | 22:31 |
| robert_ancell | infinity, that already appears to have changed | 22:31 |
| robert_ancell | infinity, I'm getting build failures e.g. https://launchpadlibrarian.net/209188618/buildlog_ubuntu-wily-amd64.zeitgeist_0.9.14-2.2ubuntu5_BUILDING.txt.gz | 22:32 |
| infinity | robert_ancell: Oh, so it did, apt-cache and I were having a small argument there. | 22:32 |
| infinity | robert_ancell: So, the answer is "ask". I'll do it now. | 22:32 |
| robert_ancell | infinity, thanks! | 22:32 |
| infinity | robert_ancell: Fixed after ~30m of publisher churn. | 22:33 |
| === anthonyf is now known as Guest21341 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
