Bug#951911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax
Daniel Shahaf wrote on Sat, 14 Mar 2020 19:57 +00:00: > ... Sorry for the noise! I typo'd the bug number in the To: header ☹
Bug#951911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax
Daniel Shahaf wrote on Sat, 14 Mar 2020 18:14 +00:00: > - :: > - > - /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i > - > + All of the bug numbers listed must be given on the same physical line > + as the word ``closes:``. Is this newly-added sentence correct? Whether it correctly states the semantics of the regexp depends on whether the regexp is matched against the changelog entry as a single multiline string or line-by-line. In the former case, the list of bug numbers would be allowed to span multiple lines, but in the latter case it wouldn't. Currently, the patch assumes all bug numbers should be on the same line, but /usr/share/vim/vim81/syntax/debchangelog.vim allows bug numbers to span multiple lines. I'm guessing the syntax file is right and the patch should be changed? Cheers, Daniel
Bug#909084: [Pkg-zsh-devel] Bug#909084: Bug#909084: Missing pcre module
Control: clone -1 -2 Control: retitle -2 Build should fail when PCRE is not available Control: severity -2 wishlist Axel Beckert wrote on Tue, Sep 18, 2018 at 11:53:36 +0200: > Yuri D'Elia wrote: > > In the last release, the pcre module does not seem to be built anymore. > > This causes "setopt rematch_pcre" to fail: > > > > failed to load module `zsh/pcre': > > /usr/lib/x86_64-linux-gnu/zsh/5.6.2/zsh/pcre.so: cannot open shared object > > file: No such file or directory > > -pcre-match not available for regex > > Thanks for the bug report. I just noticed it, too. > > I seem to have missed that the Recommends vanished because of the > according plugin files were no more built. The upstream build system treats PCRE as an optional dependency. In Debian, however, we should have the build fail hard when PCRE is not available, for compatibility reasons. Hereby filing that as #-2. Off the top of my head, we have several options: 1. Pass --with-pcre=foo to configure *and* make sure that configure dies if pcre is not found. (The configure.ac patch can be upstreamed.) 2. After running configure, check that the pcre line in config.modules has the expected values. (not upstreamable) 3. Patch Test/V07pcre to fail, rather than skip, if the PCRE module was not built. (not upstreamable) We can do more than one of these, e.g., #1+#3. Cheers, Daniel
Bug#902526: [Pkg-zsh-devel] Bug#902526: Bug#902526: Bug#902526: zsh-syntax-highlighting: FTBFS in buster/sid (does not work with recent debhelper)
Control: tag -1 pending Daniel Shahaf wrote on Thu, Jun 28, 2018 at 09:36:07 +: > Control: tags -1 patch > > Axel Beckert wrote on Thu, 28 Jun 2018 11:24 +0200: > > Daniel Shahaf wrote: > > > If that's the case, then removing the override_dh_installchangelogs > > > target would be the correct fix. > > > > Yes. > > > > Okay. In this case the attached patch should fix it. > > Getting a bit ahead of myself, we don't seem to have anywhere to push > that patch now, since the package's repository was on alioth and hasn't > been migrated to salsa. I'll have to look into migrating that. (Also would > need to test the patch and tag an 0.6.0-2 that has it.) Okay. I've verified the patch and pushed it in 7ce9697ed43d20e9a10fce052516b4b324654c6c. (Does salsa have a facility for automatically adding the 'pending' tag, like git-tag-pending on alioth?) There are a few lintian warnings with that, but I think they are less important than fixing the FTBFS: > P: zsh-syntax-highlighting source: package-uses-old-debhelper-compat-version > 10 I've looked through the upgrade checklist in debhelper(7) on buster. It's probably safe to just bump to 11 but I would like to first upload the FTBFS fix since, if there is fallout here, I wouldn't have time to deal with it. > I: zsh-syntax-highlighting source: out-of-date-standards-version 4.1.1 > (released 2017-09-27) (current is 4.1.4) v4.1.2 adds a requirement in §4.10 that Perl scripts must use "#!/usr/bin/perl" as the first line. I assume that requirement doesn't affect tests/tap, right? Assuming that's the case, it's safe to just bump to 4.1.4 with no changes. > I: zsh-syntax-highlighting source: testsuite-autopkgtest-missing New feature, not a bug, doesn't block fixing the FTBFS. > X: zsh-syntax-highlighting source: upstream-metadata-file-is-missing New feature, not a bug, doesn't block fixing the FTBFS. > P: zsh-syntax-highlighting source: debian-watch-does-not-check-gpg-signature > N: > N: This watch file does not include a means to verify the upstream > N: tarball using cryptographic signature. Upstream doesn't provide signed tarballs, only signed git tags. We can either ignore this warning or ask upstream to start producing signed tarballs as well. At any rate, doesn't block fixing the FTBFS, especially since this isn't a new upstream release. > W: zsh-syntax-highlighting source: debian-watch-could-verify-download > debian/upstream/signing-key.asc > N: > N: One or more upstream signing keys are present in the Debian package > N: but are not being used. > N: > N: Please enable the cryptographic verification of downloads with the > N: "pgpsigurlmangle" option in your watch file or remove the key. > N: False positive. Upstream provides only signed tags, no signed tarballs, so there is no value pgpsigurlmangle can be set to, but at the same time, having signing-key.asc in the package adds value, since it allows maintainers to manually verify upstream releases (using 'git tag --verify'). > N: Refer to the uscan(1) manual page for details. > N: > N: Severity: normal, Certainty: certain > N: > N: Check: watch-file, Type: source Assuming we're in agreement about all that, I'll extend my PGP key validity (just expired earlier today) and tag 7f8062b9b0d656292080d441f417e84adc253d78 as debian/0.6.0-2 and upload it. And I suppose I should check whether there's a bug open against lintian asking to demote the severity of debian-watch-could-verify-download. Cheers, Daniel
Bug#902526: [Pkg-zsh-devel] Bug#902526: zsh-syntax-highlighting: FTBFS in buster/sid (does not work with recent debhelper)
Axel Beckert wrote on Thu, Jun 28, 2018 at 13:47:38 +0200: > Daniel Shahaf wrote: > > Axel Beckert wrote on Thu, 28 Jun 2018 12:11 +0200: > > > Tell me if you can't create repos under /debian/ (the collab-maint > > > successor) and I'll create one for you. > > > > Indeed I can't; I can sign in to salsa but even then I have read-only > > access to salsa.d.o/debian/. Could you please create a z-sy-h > > repository and give me push access thereto? > > Done: https://salsa.debian.org/debian/zsh-syntax-highlighting > Thanks! > > I can take care of populating the empty clone with the preexisting > > history (planning to download the tar.xz from alioth-archive.d.o and > > 'git push --mirror' to salsa). > > Thanks! Done: https://salsa.debian.org/debian/zsh-syntax-highlighting > :-) Daniel
Bug#902526: [Pkg-zsh-devel] Bug#902526: Bug#902526: zsh-syntax-highlighting: FTBFS in buster/sid (does not work with recent debhelper)
Axel Beckert wrote on Thu, 28 Jun 2018 12:11 +0200: > Tell me if you can't create repos under /debian/ (the collab-maint > successor) and I'll create one for you. Indeed I can't; I can sign in to salsa but even then I have read-only access to salsa.d.o/debian/. Could you please create a z-sy-h repository and give me push access thereto? I can take care of populating the empty clone with the preexisting history (planning to download the tar.xz from alioth-archive.d.o and 'git push --mirror' to salsa). Thanks, Daniel
Bug#902526: [Pkg-zsh-devel] Bug#902526: Bug#902526: zsh-syntax-highlighting: FTBFS in buster/sid (does not work with recent debhelper)
Control: tags -1 patch Axel Beckert wrote on Thu, 28 Jun 2018 11:24 +0200: > Daniel Shahaf wrote: > > If that's the case, then removing the override_dh_installchangelogs > > target would be the correct fix. > > Yes. > Okay. In this case the attached patch should fix it. Getting a bit ahead of myself, we don't seem to have anywhere to push that patch now, since the package's repository was on alioth and hasn't been migrated to salsa. I'll have to look into migrating that. (Also would need to test the patch and tag an 0.6.0-2 that has it.) > > Does this make senes? > > Now that I verified that your guess was right, yes. :-) Thanks again your the help, Axel. :-) Daniel From 7ce9697ed43d20e9a10fce052516b4b324654c6c Mon Sep 17 00:00:00 2001 From: Daniel Shahaf Date: Thu, 28 Jun 2018 09:29:06 + Subject: [PATCH] Bump debhelper dependency to 11.3 and rely on new dh_installchangelogs deduplication features. Closes: #902526. --- debian/changelog | 2 ++ debian/control | 2 +- debian/rules | 5 - 3 files changed, 3 insertions(+), 6 deletions(-) diff --git a/debian/changelog b/debian/changelog index 233eab7..725c862 100644 --- a/debian/changelog +++ b/debian/changelog @@ -6,6 +6,8 @@ zsh-syntax-highlighting (0.6.0-1+git) UNRELEASED; urgency=medium Debian maintainer and the upstream maintainer are currently the same person.) + §9.2.3: Patch unit test to use /nonexistent. No functional change. + * Bump debhelper dependency to 11.3 and rely on new dh_installchangelogs +deduplication features. Closes: #902526. -- Daniel Shahaf Wed, 30 Aug 2017 08:06:24 + diff --git a/debian/control b/debian/control index 16f9a20..4e10b7e 100644 --- a/debian/control +++ b/debian/control @@ -4,7 +4,7 @@ Priority: optional Maintainer: Debian Zsh Maintainers Uploaders: Daniel Shahaf Build-Depends: - debhelper (>= 10), + debhelper (>= 11.3), zsh, Standards-Version: 4.1.1 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-zsh/zsh-syntax-highlighting.git/ diff --git a/debian/rules b/debian/rules index f8e3ec6..76ab9b2 100755 --- a/debian/rules +++ b/debian/rules @@ -9,11 +9,6 @@ override_dh_auto_install: dh_auto_install -- PREFIX=$(PREFIX) rm debian/$(NAME)/usr/share/doc/$(NAME)/COPYING.md -# Remove 'changelog.md' which both upstream and debhelper install to different names -override_dh_installchangelogs: - dh_installchangelogs - rm debian/$(NAME)/usr/share/doc/$(NAME)/changelog.md - %: dh $@
Bug#902526: [Pkg-zsh-devel] Bug#902526: Bug#902526: zsh-syntax-highlighting: FTBFS in buster/sid (does not work with recent debhelper)
Axel Beckert wrote on Wed, 27 Jun 2018 15:19 +0200:
> Hi,
>
Thanks for having a look, Axel.
> Daniel Shahaf wrote:
> > > dh_installchangelogs
> > > rm
> > > debian/zsh-syntax-highlighting/usr/share/doc/zsh-syntax-highlighting/changelog.md
> > > rm: cannot remove
> > > 'debian/zsh-syntax-highlighting/usr/share/doc/zsh-syntax-highlighting/changelog.md':
> > > No such file or directory
> > > debian/rules:14: recipe for target 'override_dh_installchangelogs' failed
> > > make[1]: *** [override_dh_installchangelogs] Error 1
> >
> > I'm guessing that debhelper on buster installs that file as
> > /usr/share/doc/.../changelog.md.gz or something,
>
> It is only installed as
> /usr/share/doc/zsh-syntax-highlighting/changelog at that time.
>
> Not sure why the path used by the upstream build system to install it,
> seems no more present.
>
That's odd. Upstream's 'make install' does 'cp changelog.md $(DOC_DIR)'
and that part hasn't changed between 0.5.0 (stretch) and 0.6.0 (buster). It's
even
the same in upstream's HEAD.
> > but I don't have a buster build env handy to investigate. Is someone
> > able to look into this?
>
> Done: Dropping override_dh_installchangelogs already suffices to make
> the package build again.
>
> I though wonder if that isn't actually a regression in a recent
> debhelper release.
You mean, a regression whereby debhelper removes the .md suffix
overzealously? According to debhelper's own changelog, there have been
several changes to dh_installchangelogs in debhelper 11.3{,.1,.2}, so a
regression is not inconceivable. However, all those mentions of
'upstream changelogs' in dh's own changelog make me wonder if dh got smarter,
is recognising changelog.md as an upstream changelog, and by itself avoids
installing
changelog twice --- which makes the 'rm' in z-sy-h's d/rules redundant.
If that's the case, then removing the override_dh_installchangelogs
target would be the correct fix.
Does this make senes?
Thanks again,
Daniel
Bug#902526: [Pkg-zsh-devel] Bug#902526: zsh-syntax-highlighting: FTBFS in buster/sid (does not work with recent debhelper)
[dropping the OP from CC] Santiago Vila wrote on Wed, Jun 27, 2018 at 12:50:53 +: > make[2]: Leaving directory '/<>' > rm > debian/zsh-syntax-highlighting/usr/share/doc/zsh-syntax-highlighting/COPYING.md > make[1]: Leaving directory '/<>' >dh_installdocs -i >debian/rules override_dh_installchangelogs > make[1]: Entering directory '/<>' > dh_installchangelogs > rm > debian/zsh-syntax-highlighting/usr/share/doc/zsh-syntax-highlighting/changelog.md > rm: cannot remove > 'debian/zsh-syntax-highlighting/usr/share/doc/zsh-syntax-highlighting/changelog.md': > No such file or directory > debian/rules:14: recipe for target 'override_dh_installchangelogs' failed > make[1]: *** [override_dh_installchangelogs] Error 1 I'm guessing that debhelper on buster installs that file as /usr/share/doc/.../changelog.md.gz or something, but I don't have a buster build env handy to investigate. Is someone able to look into this? Thanks. Daniel
Bug#877683: jessie version of dns-root-data lacks new ksk in root.ds
Control: fixed -1 2017072601~deb9u1 Hi, Sergio Gelato wrote on Wed, Oct 04, 2017 at 11:26:02 +0200: > Package: dns-root-data > Version: 2017072601~deb8u1 > Severity: serious > > The corresponding package in stretch-updates looks OK. Could it be that the > one in jessie-updates needs to be built with a newer version of bind9utils? I've added a 'fixed' annotation so apt-listbugs(1) in stretch wouldn't warn about this bug. Cheers, Daniel
Bug#872263: [rb-general] Bug#872263: linux-image-4.11.0-1-amd64-dbg: file overwrite error upgrading from stretch-backports
Chris Lamb wrote on Wed, 16 Aug 2017 07:54 -0700: > > Still, it seems like there is a wider problem here: if the exact same > > code is ever built in two unrelated packages then their debug info > > packages will conflict even if the regular binary packages don't. > > I've seen this outside of reproducibility where I was shipping the exact > same binary in the redis-server and redis-sentinel packages (it changes > behaviour based on argv[0]). > > The -dbgsym packages then conflicted for the same reason. Stupid question, but why _do_ the packages conflict? Couldn't the package manager notice that the file versions that would be installed by each package are equivalent [= same name, chmod, and bit-by-bit contents], and keep the file existing so long as _either_ package is installed?
Bug#872017: [Pkg-zsh-devel] Bug#872017: Bug#872017: zsh-syntax-highlighting FTBFS with zsh 5.4.1-1
Control: tags -1 pending Daniel Shahaf wrote on Sun, 13 Aug 2017 18:14 +: > Fixed upstream in 9523d6d49cb3d4db5bd84c3cec6168a2057fe3ab, already in > experimental and due to be uploaded to sid soon. Fixed in 0.5.0-2 and uploaded to DELAYED/5. The upload has debian-rules-parses-dpkg-changelog and out-of-date-standards-version. Both of these are already fixed in the 0.6 package, I just didn't backport the fixes. (Wanted to keep the 0.5.0-1..0.5.0-2 interdiff minimal.) Cheers, Daniel
Bug#872017: [Pkg-zsh-devel] Bug#872017: zsh-syntax-highlighting FTBFS with zsh 5.4.1-1
Control: tag -1 + fixed-upstream Control: fixed -1 0.6.0~rc1-2 Adrian Bunk wrote on Sun, 13 Aug 2017 16:39 +0300: > # alias > /build/1st/zsh-syntax-highlighting-0.5.0/./highlighters/main/test-data/alias.zsh:32: > defining function based on alias `alias1' > /build/1st/zsh-syntax-highlighting-0.5.0/./highlighters/main/test-data/alias.zsh:32: > parse error near `()' > Bail out! Either 'PREBUFFER' or 'BUFFER' must be declared and non-blank > Bail out! output on stderr Fixed upstream in 9523d6d49cb3d4db5bd84c3cec6168a2057fe3ab, already in experimental and due to be uploaded to sid soon. To be clear, there is no bug in z-sy-h itself; this is entirely a test suite issue. Thanks, Daniel
Bug#872017: marked as pending
tag 872017 pending thanks Hello, Bug #872017 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: https://anonscm.debian.org/cgit/pkg-zsh/zsh-syntax-highlighting.git/commit/?id=93d31c2 --- commit 93d31c2496d3a5609f52320a8faff26c99d6bc98 Author: Daniel Shahaf <d...@daniel.shahaf.name> Date: Sun Aug 13 18:18:01 2017 + d/changelog: #872017 will be fixed by the next upload. It is already fixed in experimental 0.6.0~rc1-2. diff --git a/debian/changelog b/debian/changelog index d6b2ba5..a7f32df 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +zsh-syntax-highlighting (0.6.0~rc1-2+git) UNRELEASED; urgency=medium + + * New upstream release. +- Fixes test suite error on zsh>=5.4~. (Closes: #872017) + + -- Daniel Shahaf <danie...@apache.org> Sun, 13 Aug 2017 18:16:12 + + zsh-syntax-highlighting (0.6.0~rc1-2) experimental; urgency=medium * New upstream pre-release.
Bug#870207: light-locker-command --lock returns 0 without locking (breaks slock)
Package: light-locker Version: 1.7.0-3 Severity: serious Justification: breaks unrelated software Dear Maintainer, On my system, 'light-locker-command --lock' returns 0 without doing anything. I presume that is because there no 'light-locker' process is running (due to #858445). In case it's relevant, I don't use lightdm either; I login by running 'startx' in a vt. That breaks the Ctrl+Alt+Del (lock screen) combination in xfce4, which defaults to running xflock4. xflock4 invokes a number of screen lockers and exits whenever any one of them returns true: % sh -x /usr/bin/xflock4 + PATH=/bin:/usr/bin + export PATH + xscreensaver-command -lock + light-locker-command --lock + exit (the screen did not lock) Could the --lock option please learn to return non-zero when it did not lock the screen. This way, xflock4 would start working again. Thanks, Daniel P.S. My /usr/bin/xflock4 comes from xfce4-session/4.12.1-5. -- System Information: Debian Release: 9.0 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable'), (250, 'testing'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages light-locker depends on: ii dconf-gsettings-backend [gsettings-backend] 0.26.0-2+b1 ii libc62.24-11+deb9u1 ii libcairo21.14.8-1 ii libdbus-1-3 1.10.18-1 ii libdbus-glib-1-2 0.108-2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-0 3.22.11-1 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libsystemd0 232-25 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxss1 1:1.2.2-1 ii lightdm 1.18.3-1 light-locker recommends no packages. light-locker suggests no packages. -- debconf-show failed
Bug#772576: taskcoach bug 772576
Hi, On Mon, Aug 29, 2016 at 12:58:03PM +0200, Nicolas Boulenguez wrote: > However... > Popcon reports 144 users of the .deb distributed by Debian. There are > probably more of them either not running popcon or installing the > almost identical .deb from Ubuntu. No one else has reported the same > issue for 18 months. Some really run it daily, since unrelated issues > have been reported meanwhile. So I intend to reduce the severity to > important and allow the package to migrate to testing. > > important: a bug which has a major effect on the usability of a >package, without rendering it completely unusable to everyone. I see that this bug is still grave. However, the package compiles and runs fine on stretch. Any reason not to set this bug to important to let taskcoach enter buster? Cheers, Daniel
Bug#868300: yadm: race condition allows access to ssh and pgp keys
Package: yadm Version: 1.10.0-1 Severity: grave Tags: security upstream Justification: user security hole Dear Maintainer, In its default configuration, yadm ensures that .ssh/ and .gnupg/ files are readable by the owner only. That is implemented by running 'chmod' on the files after they have been created: https://sources.debian.net/src/yadm/1.10.0-1/yadm/#L671 That way has a race condition: whilst the git worktree is being checked out, the .ssh and .gnupg files have the permissions of the user's umask. I added a debug printf just before the 'chmod' and it showed .ssh/ and .ssh/config having permissions «u=rwX,go=rX», i.e., world readable. I tested in an uptodate sid chroot. (I'm leaving the severity as 'grave' since I figure the vulnerability window may be long in setups where the tree being checked out is large.) Cheers, Daniel
Bug#849142: [PATCH] Update dex_expected_diffs and test requirement to ensure test compatibility with enjarify >= 1.0.3. (Closes: #849142)
Chris Lamb wrote on Sat, Dec 24, 2016 at 18:57:38 +:
> @@ -30,6 +31,17 @@ from test_java import javap_version
> +def enjarify_version():
> +# Module enjarify.typeinference appeared in enjarify 1.0.3. We use a
> call
> +# directly to the python3 binary over importing with this module to
> escape
> +# virtualenvs, etc.
> +if subprocess.call(
> +('python3', '-c', 'import enjarify.typeinference'),
Use sys.executable instead of hardcoding 'python3', to handle the case
that there's more than one python3 binary on the system?
(This would be correct for straight python3; is it also correct with
virtualenvs at play?)
Cheers,
Daniel
> +stderr=subprocess.PIPE,
> +) == 0:
> +return '1.0.3'
> +return '1.0.2'
Bug#797479: write(2): returns success but discards the data
Package: src:linux Version: 3.16.7-ckt11-1+deb8u3 Severity: grave Justification: causes non-serious data loss Dear Maintainer, In certain circumstances, the write(2) syscall returns success, but the data written is not seen on the other end of the fd. For example: * What led up to the situation? 1. Run 'cat' in xterm 2. Type a single line with 4098 characters (including the newline), e.g., by running `yes | head -2049 | xargs | xclip -i` and pasting the output. 3. Type ^D (EOF) * What was the outcome of this action? 4. The write(2) syscall in xterm indicates all 4098 bytes and the subsequent EOF were written, but the read(2) syscall receives only 4096 bytes before the EOF. Neither xterm nor cat reports an error. straces are enclosed; compare lines 37-39 in the xterm xtrace to lines 3-5 in the cat strace. * What outcome did you expect instead? I expected the read(2) call on line 5 to read the two bytes y\n, or failing that the write(2) call on line 38 to return an error. Cheers, Daniel P.S. I initially filed this as #796226 against coreutils. strace of xterm: 1 % strace -e write -p ... 2 write(5, c, 1)= 1 3 write(5, a, 1)= 1 4 write(5, t, 1)= 1 5 write(5, \r, 1) = 1 6 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 7 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 8 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 9 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 10 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 11 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 12 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 13 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 14 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 15 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 16 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 17 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 18 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 19 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 20 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 21 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 22 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 23 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 24 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 25 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 26 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 27 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 28 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 29 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 30 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 31 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 32 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 33 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 34 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 35 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 36 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 37 write(5, y y y y y y y y y y y y y y y y ..., 128) = 128 38 write(5, y\r, 2) = 2 39 write(5, \4, 1) = 1 strace of cat: 1 % strace -e trace=desc -p ... 2 Process 4519 attached 3 read(0, y y y y y y y y y y y y y y y y ..., 131072) = 4096 4 write(1, y y y y y y y y y y y y y y y y ..., 4096) = 4096 5 read(0, , 131072) = 0 6 close(0)= 0 7 close(1)= 0 8 close(2)= 0 9 +++ exited with 0 +++ -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04) -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 'stable-updates'), (250, 'testing'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#796226: cat: truncates long lines when input is terminal
Package: coreutils Version: 8.23-4 Severity: grave Justification: causes non-serious data loss Dear Maintainer, The command 'cat somefile' truncates input lines longer than 4096 characters. To reproduce: [[[ % yes | head -2049 | xargs | xclip -i # copy 4098 bytes on a single line % xclip -o | cat foobar wc -c foobar # no problem when stdin is a pipe 4098 foobar % cat foobar wc -c foobar pasteEOF 4096 foobar ]]] In the above, paste represents using the X11 paste action (such as middle-click or shift+insert) and EOF represents pressing Ctrl+D. I expected the full 4098 bytes to be pasted. -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 'stable-updates'), (250, 'testing'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages coreutils depends on: ii libacl1 2.2.52-2 ii libattr1 1:2.4.47-2 ii libc62.19-18 ii libselinux1 2.3-2 coreutils recommends no packages. coreutils suggests no packages. -- debconf-show failed
Bug#794298: asciinema: broken, Unable to upload
Marcin Kulik wrote on Thu, Aug 06, 2015 at 10:31:46 +0200: [api] url = https://asciinema.org Thanks, this value works. Note that if I add a trailing slash, then I get an error: ~ Asciicast recording finished. ~ Do you want to upload it? [Y/n] y ~ Uploading... Unauthenticated So, to summarize: the workaround is to set url to the value given by Marcin above, and exactly that value: no trailing slash, no leading www., and keep the leading url =. (no „www.”, and the „url =” is needed too) See https://asciinema.org/docs/config for config syntax. Thanks for the pointer. Daniel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794298: asciinema: broken, Unable to upload
Daniel Shahaf wrote on Tue, Aug 04, 2015 at 10:28:47 +: [api] token = 5539660d-91c0-4a29-975c-6ecb14523fce Note that this token is anonymized; it's not the actual token in my config file. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794298: asciinema: broken, Unable to upload
gustavo panizzo gfa wrote on Tue, Aug 04, 2015 at 00:05:46 +0800: being so simple to fix, wouldn't be more easy just to configure it on config file [api] https://asciinema.org This works for me: using asciinema 0.9.8-1 and python3-openssl 0.14-1, and the following ~/.asciinema/config, uploads work. [[[ [user] [api] token = 5539660d-91c0-4a29-975c-6ecb14523fce https://www.asciinema.org/ ]]] Uploads also work if I delete the last line, but not if I prefix url = to it (in that case I get the original error again). Thanks, Daniel I was expecting something more difficult, I will contact my sponsor to get the fix out (for default configs) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794298: asciinema: broken, Unable to upload
Marcin Kulik wrote on Sun, Aug 02, 2015 at 14:42:18 +0200: These issues (https, saving to tmp file) has been addressed in 0.9.9 (the latest version is 1.1.1 btw). Versions 0.9.8 also use documented, open format for the recordings. Thank you for the prompt response and fix, Marcin! I look forward to 0.9.9. I have just re-enabled support for 0.9.8 on the server side to fix this problem, but I’d like to stop supporting it in the near future (unsafe http connection is the #1 reason). Is there a chance to update this Debian package to the latest upstream version in not so distant future? I don't know; I'm not familiar with Debian's policies. Cheers, Daniel Marcin Kulik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794298: asciinema: broken, Unable to upload
Package: asciinema Version: 0.9.8-1 Severity: grave Tags: upstream Justification: renders package unusable Dear Maintainer, asciinema cannot upload new recordings: % asciinema -c /bin/true screen blanks ~ Asciicast recording finished. ~ Do you want to upload it? [Y/n] y ~ Uploading... ~ Upload failed: Your client version is no longer supported. Please upgrade to the latest version. I expected the upload to succeed. Moreover, if the asciinema client is too old to upload, then either that should be reported prior to starting the recorded command, or the recorded session should be saved in a file that the error message names; doing neither causes user effort (the recorded session) to be lost. I'm on jessie/stable, however, Carsten Hey (carsten@d.o) reproduced this in sid. Cheers, Daniel -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 'stable-updates'), (200, 'unstable'), (200, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages asciinema depends on: ii python3 3.4.2-2 ii python3-requests 2.4.3-6 pn python3:any none asciinema recommends no packages. asciinema suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
