| xevious | nacc: Do I have to do anything to clean the source repo before running debdiff? | 00:01 |
|---|---|---|
| xevious | All I've done in it was run `dpkg-buildpackage -S -us -uc -d` | 00:01 |
| nacc | xevious: that would clean it (-nc would not) | 00:02 |
| nacc | xevious: that should generate your new dsc | 00:02 |
| xevious | Thanks... just making sure there wasn't anything extra. Filing the bug now. | 00:02 |
| nacc | xevious: i'd let you know in the bug if there is :) | 00:03 |
| nacc | xevious: i'm doing php-horde-{argv,auth,autoloader} | 00:09 |
| nacc | xevious: i have a feeling it's not going to make sense to retrigger much more for php-defaults until we get all the new uploads in | 00:09 |
| xevious | I agree. | 00:10 |
| xevious | I can churn through several of these PHPUnit ones now that I've got the workflow down. | 00:11 |
| nacc | xevious: yeah, it's pretty repetitive | 00:11 |
| nacc | things to grep for PHPUnit_, setExpectedExpectation, getMoc | 00:11 |
| nacc | *getMock | 00:11 |
| nacc | and then for php7.2 itself, count( and i'm just finding create_function | 00:12 |
| xevious | nacc: https://bugs.launchpad.net/ubuntu/+source/php-guzzlehttp-promises/+bug/1749850 | 00:12 |
| ubottu | Launchpad bug 1749850 in php-guzzlehttp-promises (Ubuntu) "tests have been removed from the upstream distribution archive" [Undecided,New] | 00:12 |
| xevious | nacc: Also, I let the PHP_CodeSniffer lead dev know that we've currently got a version with known issues packaged: https://github.com/squizlabs/PHP_CodeSniffer/pull/1899#issuecomment-366100156 | 00:21 |
| nacc | xevious: thanks | 00:21 |
| nacc | yeah, and if it's not a feature thing, but a bugfix changes, we aren't bound to Feature Freeze | 00:22 |
| nacc | worst-case, we can backport the fixes back | 00:22 |
| nacc | xevious: but i expect we'll get lots of bug rreports (or none as people are using composer directly) for these packages in the next few months | 00:22 |
| xevious | nacc: If those php-guzzlehttp-promises changes look good, I'll move on to the next package with the "Class 'PHPUnit_Framework_TestCase' not found" issue. | 00:22 |
| xevious | (I'll skip over any Horde packages...) | 00:24 |
| nacc | xevious: it looked ok, except i think your debdiff's chagne to bootstrap.php may have had some local context? i'm not sure | 00:24 |
| nacc | xevious: it didn't apply cleanly here | 00:24 |
| nacc | xevious: tbh, for cases like this, i should have said, it's eaiser to give me a debdiff (really just a patch) to apply from the uupdated repo to the version you want me to build | 00:26 |
| nacc | so that i can avoid the uupdate itself as part of the patch | 00:26 |
| xevious | Isn't that what I gave you? | 00:27 |
| nacc | xevious: what you gave me appears to be the full debdiff (incl. the uupdate itself) | 00:27 |
| nacc | if that makes sense | 00:27 |
| nacc | hrm, uscan for me is not reporting a new upstrea version | 00:27 |
| nacc | did you have to modify the watch file? | 00:27 |
| xevious | I didn't | 00:27 |
| nacc | i'm admittely on bionic | 00:28 |
| xevious | About the full debdiff: when I ran debdiff, it complained about not having a directory for the 1.1.0 version to generate the diff from. So, I pulled another copy of 1.1.0 and made a debdiff that includes the uupdate. How would I generate it against the already uupdated version? | 00:29 |
| xevious | I built/tested it on a xenial system, using pull-lp-source to do the initial download. | 00:30 |
| nacc | xevious: i meant you can just give me a patch (something like): cd <old srcpkg>; uscan; uupdate ../new tarball; cd ..; cp -aR <new srcpkg> <new srcpgk>.bak; cd <new srcpkg>; <make changes>; cd ..; diff -urpN <new srcpkg>.bak <new srcpkg> > debdiff; lp-attach debdiff | 00:33 |
| nacc | xevious: since the first bits of that i have to do locally anyways, as i need th eorig tarball to build it to sponsor it :) | 00:33 |
| xevious | Want me to do that for you on this one or just the ones going forward? | 00:34 |
| nacc | going forward, i think; i'm working on this one now | 00:34 |
| nacc | xevious: those php-horde ones i just entioned all uploaded, btw | 00:37 |
| nacc | *mentioned | 00:37 |
| xevious | Looks like you need to bump php-mockery on i386. | 00:38 |
| xevious | (It's still showing regressions and is the only arch listed for the old version on the 'excuses...' page.) | 00:40 |
| nacc | xevious: thanks | 00:41 |
| nacc | xevious: did you make changes to the upstream Makefile? | 00:42 |
| xevious | I did not | 00:43 |
| xevious | Intead of removing their 'test' target, I added an empty 'override_dh_auto_test' target to debian/rules. | 00:43 |
| nacc | xevious: oh i see what's going on | 00:43 |
| xevious | I removed a patch to the Makefile | 00:43 |
| nacc | xevious: you were in a patches applied state | 00:43 |
| xevious | Uhoh | 00:43 |
| nacc | so i think it got a bit confused | 00:44 |
| nacc | so the patch is dropped in your debdiff | 00:44 |
| nacc | or maybe i am | 00:44 |
| xevious | Which patch? | 00:44 |
| nacc | let me do this by hand :) | 00:44 |
| xevious | The one that changes vendor/bin/phpunit to phpunit? | 00:44 |
| xevious | I removed that patch. | 00:44 |
| nacc | right, but sponsor-patch is claiming that it is still happening, and im' not sure why | 00:44 |
| xevious | The changes were simple. Want me to redo it with your suggested workflow? | 00:45 |
| nacc | it's ok, i can fix it up locally | 00:45 |
| nacc | so the problem is your debdiff is totally correct | 00:45 |
| nacc | except if you're already in a patches applied state (e.g., after just extracting the source package normally) | 00:46 |
| nacc | xevious: ah you're missing a changelog entry and a update-maintainer run | 00:46 |
| nacc | hrm, no you're not | 00:46 |
| nacc | well the latter yes, but for some reason patch didn't see your change to changelog | 00:46 |
| nacc | PEBKAC, nm | 00:46 |
| xevious | update-maintainer? | 00:47 |
| nacc | xevious: marks the package as being matinained by ubuntu | 00:47 |
| nacc | so that debian is not contacted for issues in it | 00:47 |
| nacc | also fixed yoru version (i thought uupdate did this correctly) it should have been 1.3.1-0ubuntu1 | 00:48 |
| nacc | because we are going ahead of debian | 00:48 |
| xevious | Yeah, I set the version when I wrote the changelog with dch. I'll stick to what uupdate recommends. | 00:49 |
| nacc | yep | 00:49 |
| nacc | also, i'm inserting a bug reference in the changelog | 00:49 |
| nacc | this way LP will close the bug for us when the package migrates | 00:50 |
| xevious | Cool | 00:50 |
| xevious | Yay automation | 00:50 |
| rbasak | nacc: mysql-5.7 migrated. Thanks! | 00:52 |
| rbasak | (I assume it was something you did, judging from your activity here) | 00:53 |
| xevious | nacc: So, I hate to be a PITA, but should we update to PHPUnit 7? Support for PHPUnit 6 ends a little less than a year into 18.04's life. PHPUnit 7 is at least supported until a couple months before 20.04 comes out. | 00:53 |
| xevious | I'm imagining the look of rage on nacc's face. | 00:54 |
| nacc | rbasak: yeah i finally got the right set of triggers | 00:56 |
| nacc | rbasak: and well, fixed that package too :) | 00:56 |
| nacc | xevious: heh, how bad is the backwards compat | 00:57 |
| nacc | xevious: the issue is this mess is already pretty bad | 00:57 |
| nacc | and, tbh, we've done no updates to phpunit 5.1.3 | 00:57 |
| nacc | in xenial | 00:58 |
| xevious | It's hard to tell how bad it'd be: https://phpunit.de/announcements/phpunit-7.html | 00:59 |
| xevious | Looks like it could be a pain. | 01:00 |
| nacc | xevious: tbh, my vested interest is pretty minimal | 01:01 |
| nacc | while i agree fully with what you are saying, phpunit itself is in universe | 01:01 |
| xevious | Ok, let's not do it. | 01:01 |
| nacc | and it would a ton (more) delta to ubuntu packages :) | 01:01 |
| xevious | I'm sold. PHPUnit 6 it is. | 01:02 |
| xevious | Guzzle dev does not want to add the tests back into the archive and asked if we can use `git clone` instead: https://github.com/guzzle/promises/pull/87#issuecomment-366109645 | 01:02 |
| nacc | xevious: this may be worth an email to the debian devs | 01:04 |
| nacc | xevious: i'm not entirely sure what the best practice is from a packaging perspective | 01:04 |
| xevious | Yeah, it kind of blows up the whole process, since `uscan` can't do its thing without a web page to parse. | 01:04 |
| xevious | Well, really it's because `uscan` only does HTTP downloads. | 01:05 |
| xevious | Oh wait | 01:06 |
| xevious | It does do git? | 01:06 |
| nacc | xevious: so it does, but only for tar.xz | 01:07 |
| nacc | which is fine | 01:07 |
| nacc | it does say 'last resort' :) | 01:07 |
| xevious | Yeah, well this is the last resort. | 01:07 |
| nacc | yeah i suppose so :) | 01:08 |
| xevious | From the man page... | 01:08 |
| xevious | > If the upstream publishes the released tarball via its web interface, please use it instead of using this mode. | 01:08 |
| xevious | ...however, if they've removed the files you need from the released tarball available via the web interface... | 01:08 |
| xevious | Alright, let me read up on uscan and see if I can make a new version that retains the tests. | 01:09 |
| nacc | new php-mail-mime is in bionic-proposed, i'm retriggering now | 01:10 |
| nacc | slangasek: i'vetried to reproduce the current failure with php-defaults & php-horde-core in bionic-proposed with: `autopkgtest -U -s --apt-pocket=proposed=src:php-defaults,src:php-horde-core php-horde-core -- autopkgtest-virt-lxd autopkgtest/ubuntu/bionic/amd64` but it passes here | 01:14 |
| nacc | slangasek: do you have any idea what i'm missing? | 01:14 |
| nacc | xevious: i need to eod/afk soon, but i'll check back in later and be back online/active tmrw morning after kid dropoff | 01:15 |
| slangasek | nacc: the passage of time? is the failure still reproducible if you retry it on autopkgtest.u.c? | 01:16 |
| xevious | nacc: Which TZ are you in? When's morning for you? | 01:16 |
| xevious | I'm Eastern US... | 01:16 |
| nacc | xevious: PST US | 01:16 |
| nacc | slangasek: i thougth so becuase i'm pretty sure i retriggered it | 01:17 |
| nacc | slangasek: but let me try again and see | 01:17 |
| xevious | Cool. I'll get all my non-PHP-packagin things out of the way in the morning tomorrow, that way I can be totally focused on this once you're online. | 01:18 |
| nacc | xevious: sounds good, thanks! | 01:18 |
| xevious | nacc: I'm going to rework this to try to add the tests back in before calling it a day. | 01:18 |
| nacc | xevious: sounds good, feel free to add the debdiff tat results in the bug (based upon the version now in b-p) | 01:19 |
| xevious | Will do | 01:19 |
| nacc | xevious: and waiting on php-guzzlehttp-promises to publish then i can retrigger those | 01:19 |
| xevious | nacc: Can you retrigger all the guzzle packages to run their tests with this new php-guzzlehttp-promises package, assuming its tests complete? | 01:23 |
| xevious | nacc: I got it to detect the new version using git, but it's failing to download it. | 01:42 |
| xevious | it=uscan with an updated debian/watch | 01:43 |
| xevious | > uscan: Newest version of php-guzzlehttp-promises on remote site is 1.3.1, local version is 1.1.0 | 01:43 |
| xevious | > uscan: => Newer package available from | 01:43 |
| xevious | > https://github.com/guzzle/promises.git refs/tags/v1.3.1 | 01:43 |
| xevious | > Undefined subroutine &main::getcwd called at /usr/bin/uscan line 3370, <REFS> line 72. | 01:43 |
| xevious | ?! | 01:44 |
| xevious | That line is: my $curdir = getcwd(); | 01:44 |
| roaksoax | xevious: uscan will downalod to ../ | 01:44 |
| xevious | Yeah | 01:45 |
| roaksoax | so you would be able to cd ../<package>-<version> | 01:45 |
| xevious | I'm trying to update the watch file to download based on a git tag instead of parsing a web page. | 01:46 |
| Unit193 | That's not entirely accurate. | 01:46 |
| xevious | It's correctly parsing the git repository, but failing immediately upon entering the git-specific section of the `uscan` code. | 01:46 |
| tsimonq2 | I hate doing that with GitHub *so* much. | 01:46 |
| tsimonq2 | I just copy/paste from other packages I maintain. | 01:46 |
| * tsimonq2 finds an example | 01:46 | |
| tsimonq2 | This is for src:vc: | 01:47 |
| tsimonq2 | version=4 | 01:47 |
| tsimonq2 | opts=filenamemangle=s/Vc-(\d\S+)\.tar\.gz/vc_$1\.orig\.tar\.gz/ \ | 01:47 |
| tsimonq2 | https://github.com/VcDevel/Vc/releases .*/Vc-@ANY_VERSION@@ARCHIVE_EXT@ | 01:47 |
| xevious | tsimonq2: For this one, I need to clone via git instead of downloading the latest release via HTTP. They added a .gitattributes file that prevents all the tests from being included in any archives. | 01:49 |
| xevious | Ok I found the bug. | 01:51 |
| tsimonq2 | Ok cool | 01:51 |
| xevious | `/usr/bin/uscan` doesn't have `use POSIX;` any where in it. | 01:51 |
| xevious | *anywhere | 01:51 |
| xevious | nacc: Ok my plan was foiled anyway: uscan's git mode uses `git archive` behind the scenes, so the resulting tarball won't include the test files. | 02:06 |
| xevious | That lack of `use POSIX;` has been fixed in a newer version of `uscan`. | 02:24 |
| xevious | They switched to `cwd()` instead of `getcwd()`: https://anonscm.debian.org/cgit/collab-maint/devscripts.git/tree/scripts/uscan.pl#n4435 | 02:25 |
| xevious | So, that's currently broken in 16.04. | 02:27 |
| nacc | xevious: ack re: guzzle | 02:29 |
| nacc | slangasek: fwiw, retrigger didn't help ... should i retry with all-proposed=1? i can't reproduce this error (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/p/php-horde-core/20180216_012156_effd8@/log.gz) | 02:31 |
| xevious | nacc: I'm done. Have a good night. See you on the onlines tomorry. | 02:32 |
| xevious | nacc: Looks like php-parser needs to be prodded for ppc64el. | 02:46 |
| tsimonq2 | tjaalton: Looking more at this patch that fixes Qt with the new mesa, there's some problems upstream with it getting approved. Solus and openSUSE have the patch now but I think generally in Ubuntu and Debian we're in agreement that we shouldn't follow suit until it's ready for review upstream. I'll keep you posted, but that's where it's at right now. | 04:27 |
| nacc | xevious: thanks, retrigged | 04:54 |
| tjaalton | tsimonq2: ok, good to know | 04:54 |
| tsimonq2 | tjaalton: Did you get a chance to look at that xorg script that doesn't follow the XDG spec? | 04:57 |
| tsimonq2 | (for lack of a better reference... heh) | 04:57 |
| tjaalton | not yet | 04:57 |
| tsimonq2 | Alright. | 04:57 |
| * mvo hugs rbalint for automatic kernel cleanup in unattended-upgrades | 08:27 | |
| rbalint | mvo: :-) | 08:36 |
| Unit193 | juliank: Pokepoke? Did you happen to see my ping the other day? | 08:45 |
| doko | jamespage, fyi: <zigo> doko: FYI, I'm currently flipping the switch to Py3 for all OpenStack stuff. | 10:03 |
| === zyga_ is now known as zyga | ||
| jamespage | doko: yeah that's quite optimistic | 10:53 |
| doko | jamespage: debian imports are still on ... | 10:55 |
| * jamespage shrugs | 10:55 | |
| jamespage | doko: debian and ubuntu don't merge/sync on openstack packages anyway | 10:56 |
| jamespage | doko: and zigo is putting all of that work into experimental first | 10:56 |
| doko | ahh, ok | 11:04 |
| ahasenack | hi, could an AA please take a look at the new queue for this libzstd sru please? | 11:25 |
| ahasenack | https://launchpad.net/ubuntu/xenial/+queue?queue_state=0&queue_text= | 11:25 |
| ahasenack | xenial, artful | 11:25 |
| jamespage | doko: and his freeze is alot further away than ours :-) | 11:28 |
| jamespage | based on my exp of the single openstack package we have migrated, there are lots of paper cuts and its not fully backed into the upstream testing | 11:29 |
| === zyga_ is now known as zyga | ||
| pitti | cjwatson: hello Colin, how are you? | 13:02 |
| pitti | cjwatson: I'm trying to change https://code.launchpad.net/~pitti/systemd/+git/debian to the new location at salsa.d.o. | 13:02 |
| pitti | I can't seem to find that - easier to delete and recreate the branch? or does that need some admin review too? | 13:02 |
| * pitti deletes and recreates it | 13:06 | |
| jbicha | doko: ring FTBFS in Ubuntu and has no rdepends. Would you be interested in kicking it out of bionic when I do the evolution-data-server transition? | 13:14 |
| === zyga_ is now known as zyga | ||
| === zyga_ is now known as zyga | ||
| dgadomski | hello, could anyone please take a look at bug #1644662? there's a trivial patch to be sponsored there, thanks | 15:35 |
| ubottu | bug 1644662 in gnome-themes-standard (Ubuntu Bionic) "Icons missing when appearance setting is "high contrast"" [Undecided,New] https://launchpad.net/bugs/1644662 | 15:35 |
| jbicha | dgadomski: the bionic part of that is fixed in https://ftp-master.debian.org/new/gnome-themes-extra_3.27.90.1-1.html | 15:46 |
| jbicha | upstream changed the source package name so it'll need to go through the new queues | 15:46 |
| jbicha | unless you were in a hurry and wanted it in bionic faster so that you could do a SRU? | 15:47 |
| dgadomski | jbicha: exactly, the fact it's missing in bionic is blocking our users waiting for SRU in xenial | 15:48 |
| slashd | jbicha, if you sponsor bionic (which is a SRU requirement). I'll sponsor dgadomski for the stable release with my SRU uploader right. | 15:49 |
| jbicha | slashd: ok, I'll upload it to bionic now | 15:51 |
| slashd | jbicha, tks | 15:52 |
| slashd | dgadomski, ^ | 15:52 |
| slashd | ddstreet, fyi ^ | 15:52 |
| dgadomski | thanks jbicha | 15:52 |
| ddstreet | thnx | 15:53 |
| jbicha | dgadomski: done: https://launchpad.net/ubuntu/+source/gnome-themes-standard/3.22.3-3ubuntu2 | 15:56 |
| xevious | nacc: Good morning. How are things looking on your end? I updated the gist this morning: https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16#file-2018-02-15_181233_php-defaults_issues-md | 18:16 |
| nacc | xevious: uploaded a few horde fixes already | 18:29 |
| nacc | xevious: otherwise same old same old ) | 18:29 |
| xevious | nacc: What about just removing unused packages? The Sabre libraries are unmaintained and only two packages are showing any reverse-dependencies: php-sabre-dav, which uses php-sabre-vobject. Can we remove the other Sabre packages? | 19:03 |
| xevious | php-sabre-dav is only used by php-horde-dav | 19:04 |
| nacc | xevious: can you see if they are removed in debian testing (rmadison -u debian <srcpkg>) and if there are bugs filed there | 19:04 |
| xevious | nacc: They're all showing "source, all" in both stable and unstable when I run rmadison on them. | 19:08 |
| nacc | xevious: ah that emans removed from testing | 19:09 |
| xevious | Ah, yeah. php-sabre-dav shows a lot more than just stable and unstable. | 19:10 |
| nacc | https://bugs.launchpad.net/bugs/1749783 | 19:10 |
| ubottu | Launchpad bug 1749783 in php-phpdocumentor-reflection (Ubuntu) "php-defaults stuck in bionic-proposed" [Undecided,Fix released] | 19:10 |
| nacc | xevious: feel free to add srcpkg task there | 19:10 |
| nacc | (also affects distribution/package) | 19:10 |
| nacc | xevious: also, i would appreciate a sanity check if you can. Can you run the autopkgtest for php-horde-core locally with just php-defaults from proposed (or all proposed) and see if it passes? | 19:12 |
| xevious | nacc: Running it with all of proposed, since I haven't learned how to enable a single package from proposed yet. | 19:21 |
| nacc | xevious: something like --apt-pocket=proposed=src:<srcpkg>, or =proposed=<binpkg> | 19:22 |
| xevious | Oh, that's pretty simple. | 19:22 |
| nacc | yeah it's handy | 19:23 |
| nacc | and that's basiclaly what the retry triggers end up translating too | 19:23 |
| nacc | *to | 19:23 |
| xevious | The Zeta components are another thing I'd like to see phased out, since they're also very old and unmaintained. However, they're used by `phpab` (only, nothing else uses them), but that's a build dependency of a ton of PHP packages. | 19:25 |
| nacc | xevious: does phpab depend on it upstrea too? | 19:26 |
| xevious | Yes | 19:27 |
| nacc | xevious: yeah hard for us to diverge there | 19:27 |
| xevious | Although, if we switch to having the packages contain their full Composer dependency stack, then it wouldn't matter. | 19:27 |
| nacc | xevious: yeah i'm drafting that up soon | 19:28 |
| nacc | although i'm going the other direction | 19:28 |
| nacc | let's drop php* in universe :) | 19:28 |
| nacc | with your suggestion hopefully being a middle ground if there is pushback | 19:28 |
| xevious | There are several PHP applications that sysadmins probably want to be able to install via packages. | 19:29 |
| xevious | Zabbix, etc. | 19:29 |
| nacc | imo, i think they should be snaps | 19:29 |
| nacc | not debian packages | 19:29 |
| nacc | the packages get out of date too quick | 19:29 |
| nacc | and if they are snpas, we might be able to get the upstream to maintain them :) | 19:30 |
| nacc | we can provide the infrastructure to use for building the snap using the right dependencies (basically the php runtie) | 19:30 |
| nacc | but it doesn't really make sense for, e.g., me to try and maintain zabbix in ubuntu | 19:30 |
| xevious | The thing slowing down the packages is just the fact that we can't have two different versions of the same PHP library installed via APT. | 19:30 |
| nacc | i never have used it :) | 19:30 |
| nacc | well, there is that and there is backwards-incompatible changes | 19:31 |
| nacc | we are in between both now | 19:31 |
| xevious | So, since those sabre packages aren't in testing, does that mean we can remove them from bionic? | 19:32 |
| nacc | xevious: should be ok, yeah | 19:32 |
| nacc | xevious: they can then come back in via unstable and get wedged in proposed separately, if they gt fixed | 19:32 |
| nacc | xevious: making good progress on horde | 19:42 |
| nacc | it's just all knotted together | 19:42 |
| nacc | so it's not worth me retrying too much until i get them all fixed | 19:42 |
| nacc | xevious: any luck getting php-horde-core to fail? i'm stumped no it | 19:47 |
| nacc | *on* | 19:47 |
| ahasenack | is it ok, in general, to call apt-cache policy in a maintainer script like postinst? | 19:49 |
| ahasenack | I'm wondering about locks and such | 19:50 |
| nacc | ahasenack: is this to see if a package is isntalled? | 19:50 |
| ahasenack | sort of, it's to see if a repository is available | 19:50 |
| ahasenack | like a ppa | 19:50 |
| xevious | nacc: No, it passed. Lots of tests that "need some love" | 19:50 |
| nacc | xevious: yeah, that's what i see too | 19:51 |
| ddstreet | jbicha re: gnome-themes-standard, it seems the pkg does a fancy dance to update the debian/control file 'Uploaders:', based on content of the currently-installed /usr/share/gnome-pkg-tools/1/rules/uploaders.mk file, you aware of that? should i just let that field get upated and sponsor/upload the sru with a changed Uploaders: entry? | 19:51 |
| nacc | xevious: but consistently fails on launchpad :/ | 19:51 |
| nacc | xevious: i'll come back to it last | 19:51 |
| nacc | ahasenack: hrm | 19:52 |
| ddstreet | jbicha e.g. for artful sru, it changed the control file Uploaders as: | 19:52 |
| ddstreet | -Uploaders: Dmitry Shachnev <mitya57@debian.org>, Jeremy Bicha <jbicha@ubuntu.com>, Laurent Bigonville <bigon@debian.org>, Michael Biebl <biebl@debian.org> | 19:52 |
| ddstreet | +Uploaders: Dmitry Shachnev <mitya57@debian.org>, Emilio Pozuelo Monfort <pochu@debian.org>, Laurent Bigonville <bigon@debian.org>, Michael Biebl <biebl@debian.org> | 19:52 |
| ahasenack | I could grep /etc/apt/sources.list.d/*, also maybe /etc/apt/sources.list | 19:52 |
| ahasenack | but apt-cache policy would also tell me if the repo I'm looking for has pinning | 19:53 |
| ahasenack | the use case is that a new version of ua-tools will enable pinning for the fips repository, but only for new installs | 19:53 |
| nacc | ahasenack: yeah, it just seems ... not great, to parse that output | 19:53 |
| ahasenack | and I'm wondering how to check a) that fips is in use already (the tool itself uses apt-cache policy + uname -r); | 19:53 |
| ahasenack | and b) if pinning is configured already or not | 19:54 |
| ahasenack | it looked more resilient to use apt-cache policy than to look for the specific config files we create | 19:54 |
| ahasenack | but I might as well call the case of the user having renamed the files a corner case | 19:55 |
| nacc | ahasenack: yeah, i'm just not sure either is great :) | 19:55 |
| ahasenack | right | 19:56 |
| xevious | nacc: I'm going to do the Zeta packages, since they have to be updated for phpab. | 19:56 |
| nacc | xevious: thanks | 19:56 |
| nacc | xevious: did you look at php-numbers-words alrady? | 19:56 |
| nacc | xevious: beause afaict, we just have horde and zeta and sabre right now? | 19:56 |
| xevious | php-numbers-words is another old, unmaintained project. | 19:57 |
| xevious | It's only *recommended* by php-text-captcha, not a hard requirement. | 19:57 |
| nacc | does it pass with the sed? | 19:57 |
| nacc | i'll check | 19:57 |
| nacc | xevious: yea looks like it will, needs a count replacement too | 20:06 |
| nacc | will do it after kid pickup | 20:06 |
| xevious | nacc: Should I run `quilt pop -a` before generating the debdiff? | 20:30 |
| xevious | nacc: Can you check out the patch on this ticket? https://bugs.launchpad.net/ubuntu/+source/php-zeta-unit-test/+bug/1750041 | 21:01 |
| ubottu | Launchpad bug 1750041 in php-zeta-unit-test (Ubuntu) "incompatible with PHPUnit 6" [Undecided,New] | 21:01 |
| xevious | nacc: If it looks good, can you merge it and rerun the tests for php-zeta-base and php-zeta-console-tools with it? | 21:02 |
| xevious | nacc: I'm doing a non-marathon day today, so I'll be calling it quits soon (going to the G3 concert in NYC!) | 21:03 |
| === zyga_ is now known as zyga | ||
| jbicha | ddstreet: all the Debian GNOME pacakges do that debian/control.in thing. I wouldn't worry about it :) | 21:11 |
| jbicha | the SRU Team doesn't worry about that field so either change it or don't change it is fine | 21:12 |
| ddstreet | jbicha awesome, i figured as much, thnx | 21:33 |
| nacc | xevious: reviewing it now | 21:36 |
| nacc | xevious: thanks! enjoy the show! | 21:41 |
| cjwatson | pitti: I could've done it, but was on leave today. I see you deleted and recreated it, so fine. | 22:28 |
| nacc | why would request.cgi complain about a non-existent package only for certain archs (e.g., i386) when it's a all binary package? and it works for some of the arches | 22:30 |
| nacc | is it just a matter of things being copied to the rigth spot? | 22:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!