Bug#809383: mention explicitly double listing: Depends, Recommends, Suggests

e an answer to Sean's question. Why do you want the question of redundant dependencies dealt with in policy ? What bad things are happening, or might be likely to happen, because it is not mentioned ? Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my

Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

Guillem Jover writes ("Re: Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same"): > On Fri, 2018-04-13 at 19:01:08 +0100, Ian Jackson wrote: > > AIUI binNMUs are now coinstallable ? And that is why > > I think I mig

Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

by having the on-disk mtime only go forwards. As for Guillem's complaints about the design of multiarch: these concerns were overruled by a decision of the Technical Committee. I don't think they are good reasons to divert from the straightforward, if not entirely neat, course I propose. Thanks, Ian. --

Bug#895546: uscan: Please make --safe the default

onnection attempts (so https to port 443 is probably OK; gopher to arbitrary ports is not) * avoid writing any files with unpredictable names (or names too-much-controlled by the source package or the network) Thanks, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opin

Bug#515856: Debian Policy 4.1.4.0 released

that the target's purpose and inclusion should be reconsidered. (ii) You make a very good argument that policy should continue to give guidance for this kind of situation. The target should probably be put back in policy, but with an explicit note saying it's not normally desirable, or

Bug#877024: marked as done (modemmanager should ask before messing with serial ports)

Philip Hands : > You'll be pleased to note that the original bug in this case has now > been closed as a result of a newly uploaded package version: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#101 > > Thanks to all involved for bringing this to a successful

Bug#694068: (solved) Re: wireless fail after stretch installation

o I have CC'd it. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#891216: Requre d-devel consultation for epoch bump

Guillem Jover writes ("Re: Bug#891216: Requre d-devel consultation for epoch bump"): > I also ended up writing a new dpkg FAQ entry, given that thread: > > > Thanks. Would you care to

Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64

Christian Schwamborn writes ("Re: Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64"): > I can try, but the only system I can really test this is a productive > system, as this 'reliable' shows this issue (and I don't want to crash > it on purpose on a regular basis). Since I

Bug#877024: modemmanager should ask before messing with serial ports

Aleksander Morgado writes ("Re: Bug#877024: modemmanager should ask before messing with serial ports"): > Ian, any comment about this 1.8-rc1 version with the filter policies > implemented? Thanks for the ping. I haven't had a chance to test it, but if it behaves as described earlier here then

Bug#28250: closed by Credible Finance <y_mai...@yahoo.com> (reply to Credible Finance <crediblefinance....@gmail.com>) (Apply for a Personal/Business Loan)

Control: reopen -1 Control: retitle -1 perl can lose output due to stdio buffering Control: found -1 5.20.2-3+deb8u9 Debian Bug Tracking System writes ("Bug#28250 closed by Credible Finance (reply to Credible Finance ) (Apply for a

Bug#28251: closed by Credible Finance <y_mai...@yahoo.com> (reply to Credible Finance <crediblefinance....@gmail.com>) (Apply for a Personal/Business Loan)

Control: reopen -1 Control: retitle -1 libc should unilaterally report buffered write error on close Debian Bug Tracking System writes ("Bug#28251 closed by Credible Finance (reply to Credible Finance ) (Apply for a Personal/Business Loan)"):

Bug#879751: [PATCH] init scripts: Do not kill per-domain qemu processes.

Richard, thanks for your perseverence. Can you please test the patch I have just sent to the bug ? You should be able to patch <0001-init-scripts-Do-not-kill-per-domain-qemu-processes.patch /etc/init.d/xen It WFM. That is, I checked that it kills the global qemu but leaves a domU one alone.

Bug#879751: [PATCH] init scripts: Do not kill per-domain qemu processes.

Control: tags -1 + patch >From 1bb0ee913b35da4d4e6a86b92beb01aa5f77e5c9 Mon Sep 17 00:00:00 2001 From: Ian Jackson <ian.jack...@eu.citrix.com> Date: Fri, 23 Feb 2018 17:04:16 + Subject: [PATCH] init scripts: Do not kill per-domain qemu processes. Drop 2nd start-stop-da

Bug#890488: xen-utils-common is missing README.pti, README.comet

on a subset of all architectures This was a mistake. I wasn't thinking clearly. I think the file being distributed by Debian must have been built on ARM. Anyway, thanks for the report and I think you have indeed pointed to the correct fix. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk>

Bug#891216: Requre d-devel consultation for epoch bump

n of people who _do_ read that list. There is a lot of expertise there and escalating difficult things there is very effective. (It's less good for things which are politically contentious, but as a project we are very poor at those and d-devel is often the least bad option. Anyway, that's not relevant h

Bug#891216: Requre d-devel consultation for epoch bump

Package: debian-policy Version: 4.1.3.0 We had another thread on debian-devel recently, in which it once again became evident that epochs are misunderstood. Epoch bumps should be rare and there are often better solutions. I suggest that we should ask people to consult debian-devel. Also we

Bug#881339: marked as done (allow node-babel-preset-env to build depend on itself)

e Haskell binaries in stretch is an undocumented chain of recompilations of packages from snapshot.d.o. If we let Haskell do that, why are we being so hard on JavaScript ? Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @

Bug#891033: dgit: Please integrate with pristine-tar

Control: retitle -1 on push/build, generate missing orig from pristine-tar Felipe Sateler writes ("Re: Bug#891033: dgit: Please integrate with pristine-tar"): > On Wed, Feb 21, 2018 at 8:32 PM, Ian Jackson > > Do you mean when the user says "dgit clone" ? Or

Bug#891031: dgit: Please make the unavoidable error message on first push more user-friendly

Felipe Sateler writes ("Bug#891031: dgit: Please make the unavoidable error message on first push more user-friendly"): > Prodded by Sean Whitton's blog post[1], I decided to give dgit another > try. I found an upload I needed to do, and used `dgit push-source > --gbp`, only to have that fail

Bug#891033: dgit: Please integrate with pristine-tar

Felipe Sateler writes ("Bug#891033: dgit: Please integrate with pristine-tar"): > It would be great if dgit would detect a pristine-tar enabled repo, and > in that case try to checkout the upstream tarball if it is not present > in `..`. Hi. I'm not sure exactly when you think it should do this.

Bug#890946: debian-policy: Editor policy is inconsistent with sensible-editor's behaviour

e, I predict (additional) annoyance. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#839046: debootstrap: enable --merged-usr by default

inds, much of it quite heated. Thanks for your attention, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#867699: fatal: transport 'ext' not allowed

Jakub Wilk writes ("Re: Bug#867699: fatal: transport 'ext' not allowed"): > * Ian Jackson <ijack...@chiark.greenend.org.uk>, 2017-07-08, 18:30: > >if this change was done for security reasons, why has it not been done > >in stretch ? > > This change w

Bug#889594: dgit started to fails its autopkgtests, with git gnupg2/2.2.4-1+

Control: reassign -1 gnupg2 Control: found -1 2.2.4-1 Dimitri John Ledkov writes ("Bug#889594: dgit started to fails its autopkgtests, with git gnupg2/2.2.4-1+"): > dgit used to pass its autopkgtests, but doesn't anymore. ... > Note, this appears to be due to a change in gnupg2 package.

Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]

Sean Whitton writes ("Re: Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]"): > I haven't yet read your older mail where you came to the conclusion that > it would be necessary for dgit to parse pbuilder's config, but we should > be really sure it's necessary before going for

Bug#720177: git-debrebase progress

tly what's in README.git-debrebase git-debrebase(1) currently mostly what's in the script head comment What do you think ? Would you like to help out with the docs ? (Feel free to switch to private email for your reply. We may not want to burden the bug with minutiae.) Regards, Ian.

Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]

Mattia Rizzolo writes ("Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]"): > On Mon, Jan 29, 2018 at 01:09:25PM +, Ian Jackson wrote: > > I'm not sure why anyone would use SOURCE_ONLY_CHANGES=yes so I don't > > know why and how dgit should allow

Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]

interrogate the pbuilder config so that it can honour it.) Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]

not doing a -1 upload the .orig is somewhere else ? > Of course, pbuilder expects the .orig to be next to the .dsc as an > input. Right, but is the normal workflow to have the .orig in .. when working in ../ ? Does that mean the origs end up in multiple places ? Ian. -- Ian Jac

Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]

Ian Jackson writes ("Re: Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]"): > 1. I think many pbuilder users expect to be able to set a build > products directory. Currently there are bugs in dgit's > --build-products-dir option; probably, too many hardc

Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]

ng there and it's from late 2016 so it's probably useless. In case it is any use I have pushed to my chiark branch wip.pbuilder-config (base was base.pbuilder-config and I haven't rebased it onto recent code). Regards, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinion

Bug#888496: Test suite runner should use `nproc'

Package: dgit Version: 4.3 I have just discovered `nproc' from coreutils. This is much better than libsys-cpu-perl because it is more portable. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.

Bug#888494: Should use `nproc'

Package: xfonts-traditional Version: 0.61-1+b1 I have just discovered `nproc' from coreutils. This is much better than libsys-cpu-perl because it is more portable. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyv

Bug#885753: New upload planned

FYI Harald Dunkel has emailed me to say he plans to provide a fixed version, which I intend to sponsor. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypas

Bug#888205: openssh-client: ssh-keygen -t rsa1 fails very late

purpose. Oh! I was unaware of this. Thanks. > On Tue, Jan 23, 2018 at 09:52:42PM +, Ian Jackson wrote: > > Failing that, I would like ssh-keygen to say "never heard of that key > > type" rather than going ahead and generating a perfectly good RSA key > > before failing

Bug#888205: openssh-client: ssh-keygen -t rsa1 fails very late

Package: openssh-client Version: 1:7.4p1-10+deb9u2 Severity: normal $ ssh-keygen -t rsa1 -b 2048 -f t Generating public/private rsa1 key pair. t already exists. Overwrite (y/n)? y Enter passphrase (empty for no passphrase): Enter same passphrase again: Saving key "t" failed: unknown or

Bug#299007: Transitioning perms of /usr/local

e have elapsed > since they made their decision, and the world has changed a lot since > then. None of the reasons why I like to use the group staff the way I do have changed. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484841#62 Ian. -- Ian Jackson <ijack...@chiark.greenend.org.

Bug#880920: Document Rules-Requires-Root field

tly say > something like "the command must preserve all environment variables, > unmodified". I think the environment does need to be preserved, indeed. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#886219: lintian should be less pedantic about latest policy version

Sean Whitton writes ("Re: Bug#886219: lintian should be less pedantic about latest policy version"): > Let me first say exactly what change I'd recommend: > - out-of-date-standards-version should be I: or P: instead of W: > - ancient-standards-version should remain W: > -

Bug#886219: lintian should be less pedantic about latest policy version

Mattia Rizzolo writes ("Re: Bug#886219: lintian should be less pedantic about latest policy version"): > Currently there are two related tags: > * https://lintian.debian.org/tags/out-of-date-standards-version.html > which is reported when an upload is done and the date of the > changelog is

Bug#886645: want guidance for changelogs when history is merge-ish

Don Armstrong writes ("Re: Bug#886645: want guidance for changelogs when history is merge-ish"): > On Tue, 09 Jan 2018, Ian Jackson wrote: > > * Each node inherits the merger of the bug map of its parents > >When merging, for each key we take the largest value fo

Bug#886645: want guidance for changelogs when history is merge-ish

ite_ because the BTS is only required to tell anyone whether the version in each suite has the bug. The UI on the BTS website would cease to be a DAG. Instead, it would be a set of parallel linear histories derived from the changelogs (which might disagree about which versions have the bug). Ian. --

Bug#886645: want guidance for changelogs when history is merge-ish

and the version which it is based on > (must be second).[2] I don't think this explanation can be sufficient to see what I saw. In my case, the upload of a new version (4.2) caused the reordering of a few previous versions. Also, it doesn't tell me which of the multiple parents to list first. I

Bug#886625: push-source should be usable no matter the state of the working tree

(resending to the bug) Sean Whitton writes ("Re: Bug#886625: push-source should be usable no matter the state of the working tree"): > On Mon, Jan 08 2018, Ian Jackson wrote: > > I think we should probably retain the current checks that the working > > tree is up to

Bug#886625: push-source should be usable no matter the state of the working tree

Mattia Rizzolo writes ("Bug#886625: push-source should be usable no matter the state of the working tree"): > On Mon, Jan 08, 2018 at 11:20:08AM +, Ian Jackson wrote: > > (Now that push-source exists I'm not sure why you would build-source, > > really.) > >

Bug#886645: want guidance for changelogs when history is merge-ish

potted a hint on the full-size version graph page, probably. FYI full git history of my package (as far as Debian is concerned) is here: https://browse.dgit.debian.org/dgit.git/ https://git.dgit.debian.org/dgit Thanks, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinion

Bug#867185: BTS is wrong about version graph

Control: fixed -1 3.13 Control: fixed -1 4.1 (Let's try the BTS syntax again.0 None of the 3.x series contain the changes from 4.0. This bug was fixed in the 3.x branch in 3.11. That was merged into the 4.x series in 4.1. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These op

Bug#886625: push-source should be usable no matter the state of the working tree

ee as at present. Maybe. I think build-* are for the old package-ish workflow. (Now that push-source exists I'm not sure why you would build-source, really.) Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.u

Bug#867185: BTS is wrong about version graph

Control: tags -1 notfound 3.13 Control: tags -1 notfound 4.1 None of the 3.x series contain the changes from 4.0. This bug was fixed in the 3.x branch in 3.11. That was merged into the 4.x series in 4.1. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.

Bug#886592: forwarded message from Cron Daemon

"(end of string)") at -e line 7. --- End Message --- -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#868550: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro

testing). I hope this information is useful. Regards, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#886580: meshlab crashes on empty .stl

: std::bad_alloc Aborted zealot:play> -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#886570: Please move all Recommends to Suggests, or delete them

also seems wrong to me, unless the python modules work by calling the command line utility (in which case it should be Depends). You don't want someone whose Python program uses the Python admesh libraries to pull in whole piles of stuff, too. Thanks, Ian. -- Ian Jackson <ijack...@chiark.gr

Bug#868550: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro

Ian Jackson writes ("Re: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro"): > This just happened to me again. The problem persisted even after > git-clean -xdff which deletes the GNUPGHOME directory (since it's in > my source tree). "killall gpg-agent&qu

Bug#868550: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro

Ian Jackson writes ("Re: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro"): > I put a wrapper around my gpg wrapper, so that only one copy of gpg > could be invoked across the whole set of parallel tests, in case the > different processes were sharing somet

Bug#868550: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro

Ian Jackson writes ("Re: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro"): > Ian Jackson writes ("Re: [pkg-gnupg-maint] Bug#868550: reprepro seems to > provide a repro"): > > Even worse, I seem to have found that sometimes a public ke

Bug#868550: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro

failed, and that was caught by my retry script. The retry script has a "sleep 10". So all the other tests that wanted to use gpg had to wait. I think this just demonstrates that my locking arrangements were working. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opi

Bug#868550: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro

Ian Jackson writes ("Re: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro"): > Here's the stderr output from one of the tests: > > + gpg --detach-sign --armor -u 39B13D8A > /home/ian/things/Dgit/dgit/tests/tmp/debpolicy-quilt-gbp/example/.git/dgit/tag.tmp

Bug#868550: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro

Ian Jackson writes ("Re: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro"): > I applied this. It doesn't seem to help. Here's the stderr output from one of the tests: + gpg --detach-sign --armor -u 39B13D8A /home/ian/things/Dgit/dgit/tests/tmp/debpolicy-quilt-gbp

Bug#868550: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro

NIIBE Yutaka writes ("Re: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro"): > I examined the code again. I found a redundant part in > exechelp-posix.c. I think that gnupg_spawn_process_detached can be > simplified. That's because: When gpg-agent (and dirmngr) is invoked >

Bug#886442: dgit: obtuse info in diff for permissions change

). dgit: To see a full diff, run git diff dc66d4bce760602ff12f5894baaf931caa2c01fa b0d8df9d891ed99cd925749cdba44e6176e3cbcc ! Push failed, while preparing your push. ! You can retry the push, after fixing the problem, if you like. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These op

Bug#884646: marked as done (No commands in dgit-maint-gbp appear to work with 3.0 (quilt) packages)

# Thanks for your diligence in closing this bug, however: reopen 884646 clone 884646 -1 retitle -1 obtuse info in diff for permissions change: # # dgit push printed this # dgit: HEAD specifies a different tree to rssh_2.3.4-6.dsc: # dgit: conf_convert | 0 # dgit: 1 file changed, 0

Bug#880658: dgit server rejects unattributed commits

Control: tags -1 found 2.15 Control: tags -1 notfound 3.13 Control: tags -1 fixed 3.11 Bizarrely, this bug is only still in production because the dgit-repos-server is running dgit 2.15. It's quite late in the day here so now is not a good time to mess with it. Ian. -- Ian Jackson <ij

Bug#871908: dgit fails to work when .git is a reference not a directory

ackages to push ATM. > However if it works that well, I think it is conclusive. Thanks. This will be going to unstable soonish. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a priva

Bug#719273: Acknowledgement (sysvinit-utils: /bin/pidof fails when there are stuck NFS mount points, preventing shutdown)

Daniel Povey writes ("Bug#719273: Acknowledgement (sysvinit-utils: /bin/pidof fails when there are stuck NFS mount points, preventing shutdown)"): > We're going to check it out early next week, whether it still applies. > > The bug it fixes is a situation where pidof reaches a process that's in

Bug#719273: Acknowledgement (sysvinit-utils: /bin/pidof fails when there are stuck NFS mount points, preventing shutdown)

Control: tags -1 + patch Daniel Povey writes ("Bug#719273: Acknowledgement (sysvinit-utils: /bin/pidof fails when there are stuck NFS mount points, preventing shutdown)"): > No-one ever responded to this thread (years ago). > We have just noticed the same problem on a newer version of Debian and

Bug#879526: dgit broken by recent dpkg (Can't locate object method "new" via package "Dpkg::Compression::Process" …)

ne, and that's how #879526 was fixed in dgit. My comment ... > Ian Jackson <ijack...@chiark.greenend.org.uk> (2017-10-22): > > Sadly I am not aware of a good way of detecting missing `use' > > direcctives other than waiting for things to break when an implicitly > &

Bug#884646: No commands in dgit-maint-gbp appear to work with 3.0 (quilt) packages

Ian Jackson writes ("Re: Bug#884646: No commands in dgit-maint-gbp appear to work with 3.0 (quilt) packages"): > Are you sure that dgit's suggestion: > > > dgit: perhaps tree changed since dgit build[-source] ? > > was false ? I discover from UTSL that dgi

Bug#884646: No commands in dgit-maint-gbp appear to work with 3.0 (quilt) packages

mmit id 4dcfadb60855855fa909fb1544c22af63084b4c0) and then the expected message: dgit: HEAD specifies a different tree to rssh_2.3.4-6.dsc: Are you sure that dgit's suggestion: > dgit: perhaps tree changed since dgit build[-source] ? was false ? Regards, Ian. -- Ian Jackson <ijack...@chia

Bug#884646: No commands in dgit-maint-gbp appear to work with 3.0 (quilt) packages

still have the full shell history or any other information about how you got into this state ? > I then tried with --git-ignore-new, but get: Trying this was a mistake, since you shouldn't really have been in this situation, and you shouldn't need to supply that flag unless you deliberately have

Bug#884646: No commands in dgit-maint-gbp appear to work with 3.0 (quilt) packages

pts to touch files in non-existent subdirectories of > .git. I wasn't sure what to make of that. I confess I didn't look at the earlier messages in any detail. Now that I look at them again they are perplexing. I will see if I can reproduce them. Ian. -- Ian Jackson <ijack...@chiark.gree

Bug#884646: No commands in dgit-maint-gbp appear to work with 3.0 (quilt) packages

Ian Jackson writes ("Re: Bug#884646: No commands in dgit-maint-gbp appear to work with 3.0 (quilt) packages"): > More when I have figured out what is going on. So, my discoveries and some other facts: The file debian/patches/0008-Add-support-for-Subversion-svnserve.patch says

Bug#884646: No commands in dgit-maint-gbp appear to work with 3.0 (quilt) packages

3c9399243e4b86ff7c dgit --quilt=gbp --overwrite -wgf build-source dgit --quilt=gbp --overwrite --damp-run push More when I have figured out what is going on. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an addr

Bug#884646: No commands in dgit-maint-gbp appear to work with 3.0 (quilt) packages

Can you please tell me where to find your git tree, and reconfirm your HEAD commit ? Thanks, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#884616: exception "ValueError: The truth value..." on import

erials.py", line 70, in __init__ self.__setattr__(key, value) ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() >>> I had a look at the source but I'm afraid I'm mystified. Ian. -- Ian Jackson <ijack...@chi

Bug#883938: linux-image-3.16.0-4-amd64: Kernel panic on boot after upgrading to debian 8.10 kernel 3.16.51

The Xen Project CI has six machines which were affected by this regression. (Kernel messages are near-identical to those reported by others in this bug.) As suggested I downloaded this kernel;

Bug#884283: lvm2 prerm ought to check if root is on lvm

Package: lvm2 Version: 2.02.111-2.2+deb8u1 A few weeks ago, I asked apt to remove dmeventd and it removed lvm2 as a consequence. Failing to observe that lvm2 was in the list of other things to be removed was user error on my part. However, it would have been nice if lvm2's prerm had observed

Bug#883731: audacious: Debian packaging has incorrect license

Nicholas D Steeves writes ("Re: Bug#883731: audacious: Debian packaging has incorrect license"): > Will I also need to provide formal copies in debian/COPYING.emails or > would a README.copyright or similar pointing to the bug report > suffice? In particular I'm concerned about lines like this

Bug#459427: changelog vs. NEWS handling

Peter Eisentraut writes ("Re: Bug#459427: changelog vs. NEWS handling"): > On 12/1/17 11:19, Ian Jackson wrote: > > Is there some reason why exacdt standardisation of the filenames is > > necessary here ? For most of the uses I can think of, it is OK to > > look in

Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)

nse of knowledge or ownership that would be appropriate for that. > On Tue, Dec 05, 2017 at 05:36:10PM +, Ian Jackson wrote: > > One question I have is about this: "several packages now require just > > systemd-sysv". Can someone refer to some examples, please ? >

Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)

t;several packages now require just systemd-sysv". Can someone refer to some examples, please ? Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#883340: dgit build accesses the internet and fails when offline.

Sean Whitton writes ("Bug#883340: dgit build accesses the internet and fails when offline."): > On Mon, Dec 04 2017, Ian Jackson wrote: > > Well, yes, except that the dgit *build subcommands are already such > > aliases. They exist because debuild etc. mishandle .

Bug#883340: dgit build accesses the internet and fails when offline.

dd a warning "note that this accesses > the network. If you want to do a purely offline build, invoke > dpkg-buildpackage or debuild directly" (I wouldn't mention sbuild, > because by default sbuild also accesses the network to update your > schroot). I'm happy to add su

Bug#883340: dgit build accesses the internet and fails when offline.

other information in a build that comes from off the local machine. I hope this is helpful. Regards, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#459427: changelog vs. NEWS handling

share/doc/P/changelog) to find out why something is broken. IMO it all depends on what upstream does. Is there some reason why exacdt standardisation of the filenames is necessary here ? For most of the uses I can think of, it is OK to look in a handful of files to see which one might answer the q

Bug#881339: let's find a solution

ns the single sentence | it is strange that the package Build-Depends: on itself!? Lots of language compilers build-depend on themselves so surely there is more to this. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an

Bug#882445: Proposed change of offensive packages to -offensive [and 1 more messages]

Sean Whitton writes ("Bug#882445: Proposed change of offensive packages to -offensive [and 1 more messages]"): > On Thu, Nov 23 2017, Ian Jackson wrote: > > I'm not wedded to this second half of the sentence. > > Is this a proposal/seconding of the modified patch? Su

Bug#874295: Not a bug

Ben Finney writes ("Re: Bug#874295: Not a bug"): > Thomas Pierson writes: > > It's only if a user want to connect to a particular external service > > that a plugin file is downloaded and used. > > That is still a problem, IMO. It would be best if the program did not do

Bug#883005: [pkg-gnupg-maint] Bug#883005: gpg2 too annoying about lack of a passphrase

Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#883005: gpg2 too annoying about lack of a passphrase"): > On Tue 2017-11-28 17:20:56 +, Ian Jackson wrote: > > Package: gnupg2 > > Version: 2.0.26-6+deb8u1 .. > I'm not seeing this particular warning on the ver

Bug#883005: gpg2 too annoying about lack of a passphrase

At least 3 of these 5 prompts are superfluous. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#858398: Proposed (lib)curl switch to openssl 1.1

Ian Jackson writes ("Re: Proposed (lib)curl switch to openssl 1.1"): > Adrian Bunk writes ("Re: Proposed (lib)curl switch to openssl 1.1"): > > What I suggest above would be a transition that should be coordinated > > with the release team like other transitions.

Bug#858398: Proposed (lib)curl switch to openssl 1.1

I don't feel I understand the tradeoffs well. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#882445: Proposed change of offensive packages to -offensive [and 1 more messages]

just A, but censored right in some cases package not in Debian at all right in some cases more problematic content We don't need policy to explain why Depends is probably daft here. The maintainer will figure that out. The bug I mentioned earlier shows that it i

Bug#858398: Proposed (lib)curl switch to openssl 1.1

8572f5bff93734624fc214a Mon Sep 17 00:00:00 2001 From: Ian Jackson <ijack...@chiark.greenend.org.uk> Date: Thu, 23 Nov 2017 12:49:08 + Subject: [PATCH] Change build-depends to list libssl-dev first. Outcome in sid/buster is to switch to openssl 1.1. I am not changing the sonam

Bug#858398: Proposed (lib)curl switch to openssl 1.1

would be quite happy to hand this issue over to someone else. Failing that, any contribution of relevant facts, opinions, suggestions, etc. would be very welcome. Thanks, Ian. >From 87df3380466355ac58572f5bff93734624fc214a Mon Sep 17 00:00:00 2001 From: Ian Jackson <ijack...@chiark.gree

Bug#858398: curl: Please migrate to openssl1.1 in Buster

n Stretch because a few reverse dependecies of libcurl needed to stay > with 1.0. To be honest, I am not sure. But I will try to proceed anyway. I will send a longer mail with a wider distribution shortly. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are

Bug#874295: clementine: installs non-free plugin at runtime

) from the proprietary music files it downloads (permitted, if there were a Free client that could do the download). Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private addr

Bug#881831: dgit-infrastructure: doesn't show anything on cgit when the only digt push hit only experimental

feeb3b4d92b77 iwj@gideon:/srv/dgit.debian.org/repos/dgit.git$ And see https://browse.dgit.debian.org/dgit.git/ I think that this HEAD-less state is appropriate for Mattia's repo. It would be better if cgit displayed its contents. Regards, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.u

Bug#880920: Document Rules-Requires-Root field

ial document set, on the task of reformatting it into docbook. So yes it should probably go into the policy package (since there is no better home for it). Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org

<    7   8   9   10   11   12   13   14   15   16   >