Bug#1057119:
mpv bug I opened, now closed: https://github.com/mpv-player/mpv/issues/13062 looks like this is mutter? some gnome desktop component? For now, I don't know what or how to test further.
Bug#1057119:
See also https://github.com/mpv-player/mpv/issues/11342
Bug#1057119: mpv: wayland/gnome crash, after fullscreen or zoom video, then quit mpv
Package: mpv Version: 0.35.1-4 Severity: important Dear Maintainer, default debian gnome wayland desktop consistently crashes when using mpv to play a video (or gif) then zooming then quitting. Able to test - I reported initially against intel video driver: https://github.com/intel/media-driver/issues/1743 [Bug]: wayland/gnome crash, after fullscreen or zoom video, then quit, mpv, 6.1.0-13-amd64, both intel free and non-free drivers #1743 -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mpv depends on: ii libarchive13 3.6.2-1 ii libasound21.2.8-1+b1 ii libass9 1:0.17.1-1 ii libavcodec59 7:5.1.4-0+deb12u1 ii libavdevice59 7:5.1.4-0+deb12u1 ii libavfilter8 7:5.1.4-0+deb12u1 ii libavformat59 7:5.1.4-0+deb12u1 ii libavutil57 7:5.1.4-0+deb12u1 ii libbluray21:1.3.4-1 ii libc6 2.36-9+deb12u3 ii libcaca0 0.99.beta20-3 ii libcdio-cdda2 10.2+2.0.1-1 ii libcdio-paranoia2 10.2+2.0.1-1 ii libcdio19 2.1.0-4 ii libdrm2 2.4.114-1+b1 ii libdvdnav46.1.1-1 ii libegl1 1.6.0-1 ii libgbm1 22.3.6-1+deb12u1 ii libjack-jackd2-0 [libjack-0.125] 1.9.21~dfsg-3 ii libjpeg62-turbo 1:2.1.5-2 ii liblcms2-22.14-2 ii liblua5.2-0 5.2.4-3 ii libmujs2 1.3.2-1 ii libpipewire-0.3-0 0.3.65-3 ii libplacebo208 4.208.0-3 ii libpulse0 16.1+dfsg1-2+b1 ii librubberband23.1.2+dfsg0-1 ii libsdl2-2.0-0 2.26.5+dfsg-1 ii libsixel1 1.10.3-3 ii libswresample47:5.1.4-0+deb12u1 ii libswscale6 7:5.1.4-0+deb12u1 ii libuchardet0 0.0.7-1 ii libva-drm22.17.0-1 ii libva-wayland22.17.0-1 ii libva-x11-2 2.17.0-1 ii libva22.17.0-1 ii libvdpau1 1.5-2 ii libvulkan11.3.239.0-1 ii libwayland-client01.21.0-1 ii libwayland-cursor01.21.0-1 ii libwayland-egl1 1.21.0-1 ii libx11-6 2:1.8.4-2+deb12u2 ii libxext6 2:1.3.4-1+b1 ii libxinerama1 2:1.1.4-3 ii libxkbcommon0 1.5.0-1 ii libxpresent1 1.0.0-2+b10 ii libxrandr22:1.5.2-2+b1 ii libxss1 1:1.2.3-1 ii libxv12:1.0.11-1.1 ii libzimg2 3.0.4+ds1-1 ii zlib1g1:1.2.13.dfsg-1 Versions of packages mpv recommends: ii xdg-utils 1.1.3-4.1 ii yt-dlp 2023.03.04-1 Versions of packages mpv suggests: pn libcuda1 -- no debconf information
Bug#872778: xterm -lc (with UTF-8 locale) cannot properly copy some utf-8 unicode chars
> > Thomas is there any other test I can run on Debian stable? > > fwiw "locale" says > > LANG=en_US.UTF-8 > LANGUAGE= > LC_CTYPE="en_US.UTF-8" > LC_NUMERIC="en_US.UTF-8" > LC_TIME="en_US.UTF-8" > LC_COLLATE="en_US.UTF-8" > LC_MONETARY="en_US.UTF-8" > LC_MESSAGES="en_US.UTF-8" > LC_PAPER="en_US.UTF-8" > LC_NAME="en_US.UTF-8" > LC_ADDRESS="en_US.UTF-8" > LC_TELEPHONE="en_US.UTF-8" > LC_MEASUREMENT="en_US.UTF-8" > LC_IDENTIFICATION="en_US.UTF-8" > LC_ALL=en_US.UTF-8 > > and "env|grep -E '(LANG|LC_)'" says > > LANG=en_US.UTF-8 > GDM_LANG=en_US.UTF-8 Thank you - I set all those and xterm now works the same as xfce4-terminal. Problem isolated, thanks.
Bug#872778: xterm -lc (with UTF-8 locale) cannot properly copy some utf-8 unicode chars
On Mon, Sep 17, 2018 at 04:47:28AM -0400, Thomas Dickey wrote: > On Wed, Aug 22, 2018 at 08:05:51PM +1000, Zenaan Harkness wrote: > > Create a text file containing e.g. the musical natural symbol, and > > the mathematical function symbol, e.g. "ƒƒƒ ♮♮♮" (three function > > symbols, a space, and three natural symbols, inside plain quotes). > > > > Now in an xterm -lc instance, with a UTF-8 locale, cat the file. > > > > xterm displays the function and the natural symbols. > > > > Now start the utf-8 compatible gui editor Geany, and open the same > > file in Geany. > > > > Copy and paste those characters from Geany, into Geany - works. > > > > Copy from Geany, paste to xterm - this also works. > > > > Select/copy from xterm, middle-click paste into Geany - only the > > natural symbols, and not the function symbols, are pasted, also > > pasting to xterm (from copying from xterm) does not work. > > > > SO, xterm is not properly copying some UTF-8 Unicode characters. > > This update is unrelated to the original report, which deals with > characters past BMP (the example uses U+0192 and U+266E). > > I have not been able to reproduce the problem. > > See also: > > https://lists.debian.org/debian-user/2017/09/msg00518.html > > https://lists.debian.org/debian-user/2017/09/msg00527.html > > > > Should I file a different bug for this, or just leave this here? > > It might be related to #901249, but I cannot say. The other client > (Geany) seems to be a factor - if you can reproduce the problem with > xsel, that would be helpful. copy and paste rely on the source to > provide the data in different formats, and the target to request > what's appropriate. OK, so I've tested just using xsel: The string I start with is "# ƒƒ ♮♮" without the quotes, and that should appear as: hash space function function space natural natural In vim in xfce4-terminal (to write this email), that sequence pastes correctly. Now, in xfce4-terminal, after selecting those chars, xsel -o correctly dumps them. Jumping immediately to xterm -lc, then: xsel -o -also- correctly dumps those chars to the xterm. That's good. Next, select those chars in xterm, and xsel -o no longer dumps the function symbols; That's not good. xfce4-terminal now has the same problem with xsel -o NOT dumping the function symbols, as does middle click pasting into geany - SO, in my setup at least, the problem is copying the function symbol -from- xterm (copying from other apps, such as geany and from vim in xfce4-terminal, and straight from xfce4-terminal, all works correctly for xsel -o (in both xfce4-terminal and xterm -lc). According to https://en.wikipedia.org/wiki/%C6%91 this "function symbol" is actually called the "florin sign", but in any case has the code U+0192 which seems well within the 16-bit code plane. Here's what a little test run looks like in xterm -l (I've bound the function symbol to my keyboard so I can type it successfully): $ echo $ # select above string, and: $ xsel -o $ $ # now middle click: $ ?^C $ # now select from xfce4-terminal, then come back here: $ xsel -o $ $ # now middle click: $ Thomas is there any other test I can run on Debian stable?
Bug#872778: xterm -lc (with UTF-8 locale) cannot properly copy some utf-8 unicode chars
Create a text file containing e.g. the musical natural symbol, and the mathematical function symbol, e.g. "ƒƒƒ ♮♮♮" (three function symbols, a space, and three natural symbols, inside plain quotes). Now in an xterm -lc instance, with a UTF-8 locale, cat the file. xterm displays the function and the natural symbols. Now start the utf-8 compatible gui editor Geany, and open the same file in Geany. Copy and paste those characters from Geany, into Geany - works. Copy from Geany, paste to xterm - this also works. Select/copy from xterm, middle-click paste into Geany - only the natural symbols, and not the function symbols, are pasted, also pasting to xterm (from copying from xterm) does not work. SO, xterm is not properly copying some UTF-8 Unicode characters. See also: https://lists.debian.org/debian-user/2017/09/msg00518.html https://lists.debian.org/debian-user/2017/09/msg00527.html Should I file a different bug for this, or just leave this here?
Bug#906674: consequences to deleting a (generic name) alternative? - reverse dependencies on ImageMagick binaries?
ImageMagick (IM) seems to be needed (at least on XFCE desktop) for the PDF printer (cups-filters). There are many apparent rdepends of IM, from a2ps and devede to inkscape and sunclock. ImageMagick in Debian stable is a bit of a bush pig, dominating the /usr/bin default PATH namespace with a number of excessively generic verbs. Although the files are apparently strictly versioned: /usr/bin/animate-im6.q16 /usr/bin/compare-im6.q16 /usr/bin/composite-im6.q16 /usr/bin/conjure-im6.q16 /usr/bin/convert-im6.q16 /usr/bin/display-im6.q16 /usr/bin/identify-im6.q16 /usr/bin/import-im6.q16 /usr/bin/mogrify-im6.q16 /usr/bin/montage-im6.q16 /usr/bin/stream-im6.q16 , alternatives are put in place: /usr/bin/animate -> /etc/alternatives/animate /usr/bin/animate-im6 -> /etc/alternatives/animate-im6 /usr/bin/animate-im6.q16 /usr/bin/compare -> /etc/alternatives/compare /usr/bin/compare-im6 -> /etc/alternatives/compare-im6 /usr/bin/compare-im6.q16 /usr/bin/composite -> /etc/alternatives/composite /usr/bin/composite-im6 -> /etc/alternatives/composite-im6 /usr/bin/composite-im6.q16 /usr/bin/conjure -> /etc/alternatives/conjure /usr/bin/conjure-im6 -> /etc/alternatives/conjure-im6 /usr/bin/conjure-im6.q16 /usr/bin/convert -> /etc/alternatives/convert /usr/bin/convert-im6 -> /etc/alternatives/convert-im6 /usr/bin/convert-im6.q16 /usr/bin/display -> /etc/alternatives/display /usr/bin/display-im6 -> /etc/alternatives/display-im6 /usr/bin/display-im6.q16 /usr/bin/identify -> /etc/alternatives/identify /usr/bin/identify-im6 -> /etc/alternatives/identify-im6 /usr/bin/identify-im6.q16 /usr/bin/import -> /etc/alternatives/import /usr/bin/import-im6 -> /etc/alternatives/import-im6 /usr/bin/import-im6.q16 /usr/bin/mogrify -> /etc/alternatives/mogrify /usr/bin/mogrify-im6 -> /etc/alternatives/mogrify-im6 /usr/bin/mogrify-im6.q16 /usr/bin/montage -> /etc/alternatives/montage /usr/bin/montage-im6 -> /etc/alternatives/montage-im6 /usr/bin/montage-im6.q16 /usr/bin/stream -> /etc/alternatives/stream /usr/bin/stream-im6 -> /etc/alternatives/stream-im6 /usr/bin/stream-im6.q16 There is no "magick" command (or alternative), yet it seems as though there is meant to be a "magick" program: http://www.imagemagick.org/script/command-line-tools.php Perhaps this "magick" command is only available in newer versions of ImageMagick? Anyway, "import" gets in the way, and others such as "convert", "stream", "identify" and "display" really dominate those respective generic namespaces, and in this particular case, are directly obstructing: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906674 "Alternatives" provides for choosing amongst "functionally the same" alternatives, or "deleting" the generic name. My question is, can I safely remove the symbolic link "generic" names applied by the IM package, or IM's reverse dependencies going to bite me? TIA,
Bug#906674: imagemagick: Sub-commands by default are symlinked into PATH (/usr/bin), "import" is a problem
Package: imagemagick
Version: 8:6.9.7.4+dfsg-11+deb9u5
Severity: normal
Tags: upstream
Dear Maintainer,
Bash has flexible similarity between scripts and the REPL/command shell.
Enhancing the shell requires choosing and using a name - a name identifies a
command, program, script (file), function, alias or variable (etc).
Newer ImageMagick (IM) versions provide the command "magick" which has the
traditional IM commands as subcommands of this "magick" command, e.g.
magick convert ...
magick import ...
This is similar to the way Git and other ("relatively modern") programs are
structured.
IM's "import" command, when in the global PATH at /usr/bin, dominates this
namespace - i.e. the name "import" gets in the way of using the word "import"
for other purposes, for example in the project I am gestating, enhancing Bash to
provide for import of modules, and in this case the name "import" is the natural
name for this function.
Now XFCE (my desktop) seems to want ImageMagick (perhaps for its printing
subsystem), and so the program name "import" gets in the way of this little
project I'm developing - especially when trying to debug a problem, and when for
some reason I have an "import module" problem, IM's import program first
baffles, then gets in the way, and finally, seems to dump random files around
the place.
It seems the name "import" is merely a symlink to the actual program in
"alternatives", which provides for removing the /usr/bin/import link using
update-alternatives, however as the update-alternatives man page says, the
"generic name" is meant to choose one of the corresponding "files providing
interchangeable functionality", and so the obvious problem is other packages
(e.g. the XFCE printing (cups?) subsystem) depending on "/usr/bin/import" rather
than on say /usr/bin/import-im6.q16 - so I don't know if there are such
dependencies, but if there are, then a transition period is required to wean the
reverse dependencies of ImageMagick off of the generic "PATH" names such as
import, identify and display, and onto the "/usr/bin/magick import" etc. - thus
this bug report/ feature request.
Philosophically, programs (such as IM) ought not dominate the top level program
name space, especially for the more generic names including the examples given
above - by avoiding such namespace domination, greater room is provided to
future hackers to tinker and expand their systems in ways we have not yet
thought of.
-- System Information:
Debian Release: 9.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-7-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_zen.UTF-8, LC_CTYPE=en_zen.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_zen.UTF-8), LANGUAGE=en_zen.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_zen.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages imagemagick depends on:
ii imagemagick-6.q16 8:6.9.7.4+dfsg-11+deb9u5
imagemagick recommends no packages.
imagemagick suggests no packages.
Bug#861584: xfwm4 bug report filed
See XFCE / xfwm4 bug report filed here: https://bugzilla.xfce.org/show_bug.cgi?id=13575 See recent email here: https://mail.xfce.org/pipermail/xfce/2017-May/035584.html
Bug#861606: mutt: header cache file(s) not being created
Package: mutt Version: 1.5.23-3 Severity: normal Dear Maintainer, mutt-patched is not creating header_cache files. I tested also with all other muttrc options commented out except for this one: set header_cache = "~/Mail/mutt-cache/" and yet when I open a folder, and then quit mutt, never is a file in the ~/Mail/mutt-cache/ directory created. Thanks. -- Package-specific info: Mutt 1.5.23 (2014-03-12) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 4.9.0-0.bpo.2-amd64 (x86_64) ncurses: ncurses 5.9.20140913 (compiled with 5.9) libidn: 1.29 (compiled with 1.29) hcache backend: tokyocabinet 1.4.48 Compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-4' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-4) Configure options: '--prefix=/usr' '--sysconfdir=/etc' '--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' '--with-mailpath=/var/mail' '--disable-dependency-tracking' '--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' '--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'x86_64-linux-gnu' '--enable-nntp' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm' Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall Compile options: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_NNTP +USE_IMAP +USE_SMTP -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/share/mutt" SYSCONFDIR="/etc" EXECSHELL="/bin/sh" MIXMASTER="mixmaster" To contact the developers, please mail to . To report a bug, please visit http://bugs.mutt.org/. misc/am-maintainer-mode.patch features/ifdef.patch features/xtitles.patch features/trash-folder.patch features/purge-message.patch features/imap_fast_trash.patch features/sensible_browser_position.patch features-old/patch-1.5.4.vk.pgp_verbose_mime.patch features/compressed-folders.patch features/compressed-folders.debian.patch debian-specific/Muttrc.patch debian-specific/Md.etc_mailname_gethostbyname.patch debian-specific/use_usr_bin_editor.patch debian-specific/correct_docdir_in_man_page.patch debian-specific/dont_document_not_present_features.patch debian-specific/document_debian_defaults.patch debian-specific/assumed_charset-compat.patch debian-specific/467432-write_bcc.patch debian-specific/566076-build_doc_adjustments.patch misc/define-pgp_getkeys_command.patch misc/gpg.rc-paths.patch misc/smime.rc.patch misc/fix-configure-test-operator.patch upstream/531430-imapuser.patch upstream/543467-thread-segfault.patch upstream/542817-smimekeys-tmpdir.patch upstream/548577-gpgme-1.2.patch upstream/553321-ansi-escape-segfault.patch upstream/547980-smime_keys-chaining.patch upstream/528
Bug#673232: mutt shutdown
Yes, mutt should be able to shutdown nicely. When editing a draft email though the external editor, e.g. vim, emacs etc, also needs to do something sane. For starters, the temp files of any draft you are editing can be saved in a custom tmp dir, e.g.: set tmpdir = "~/Mail/mutt-editor-drafts/" This is often better in an emergency than having /tmp/ cleaned on reboot and losing your draft. Downside is you must manually check and clean that directory now and then. If mutt were to process a unix "shutdown" signal, it could (assuming concurrency issues are carefully thought about and handled) save current mailbox status changes (like stuff "^q" or save-mailbox etc). This sounds like a relatively "easy hack" (as the libreoffice guys call it) for someone new chomping at the bit to start learning mutt's code :)
Bug#160678: [Pkg-xfce-devel] Bug#524711: xfwm4: New window placement problem
This would be a nice feature to have. At the moment, to create the desired swapping between wrap and no wrap, in the pager, one must use two key bindings (rather, macros), rather than just one to "inv"ert the value, as in the following example workaround: macro pager w "set wrap=0" macro pager W "set wrap=$my_wrap" Regards,
Bug#861537: detox: git, upstream, and tags/branches ?
Hello Eriberto and Doug, I just added github as an "upstream" remote to my local detox git repo, which was cloned from Debian's. 1) git had to download the entire upstream repo, saying specifically: $ git fetch upstream warning: no common commits remote: Counting objects: 310, done. remote: Total 310 (delta 0), reused 1 (delta 0), pack-reused 309 Receiving objects: 100% (310/310), 268.73 KiB | 7.00 KiB/s, done. Resolving deltas: 100% (201/201), done. >From https://github.com/dharple/detox * [new branch] develop-> upstream/develop * [new branch] master -> upstream/master * [new tag] v1.3.0 -> v1.3.0 * [new tag] v1.2.0 -> v1.2.0 * [new tag] v1.2.1 -> v1.2.1 So, is there a way to connect the repos so that when one clones from one repo, then fetches from the other, the shared objects are not re-downloaded? (detox is a great repo to figure out how to solve this problem on, because it's so small) 2) Having included both repos in my local repo, I am wondering about these two tags, which ought be the same git ID, but are not!: 1.3.0 according to upstream: d23cd12f7ff3730f4be9643fdcabe2fe0f3ebd74 refs/tags/upstream/1.3.0 1.3.0 according to debian: de8750555a2ae79dc138d5433879de0bd5d76f62 refs/tags/v1.3.0 Now, if Debian's repo is older, then of course that's the obvious "reason". Not that there's any "should"s, but is it appropriate to say for example that one repo "should" clone the other? Or, for another example, "should" the upstream repo import all the Debian tags and objects? Or "should" the Debian repo import the upstream now that it's in git? Or, finally, "should" each import the other? I.e. Debian import upstream, and upstream import Debian? I'm actually not the knowledgeable about git sorry, so my questions might be stupid - I'm trying to figure out how to create "the ideal situation" if that makes sense... I have set up my local clone repos, and backups, to have "remotes" that point to each other. I.e. e.g.: - I've cloned the antlr and stringtemplate projects onto my local workstation - I backup all my cloned repos to an external hdd - but sometimes I've "accidentally" worked in a clone repo on the external hdd, and then needed to pull that across to my internal hdd! - so, I set up remotes on each hdd, pointing to the other hdd, as well as to the (sometimes more than one) upstream/external/public repos, - then when I do a git fetch --all, the priority/sequencing in my .git/config file is such that: - git will always first try to grab any updates locally, from the other hdd This is important to me, because some repos are large and have lots of public updates (e.g. the linux kernel) and my remote rural wireless internet link is not particularly "abundant" and so I DEFINITELY don't want to download all the changes twice (accidentally), so I always try to get changes first from my backup, and my backup repo always tries to get changes first from my workstation, and I am happy and calm :) Hope you don't mind my rambling.. Kind regards, Zenaan
Bug#861584: xfwm4: xfmw4 dual-monitor (landscape+portrait) new xterm on "other" monitor incorrectly resized
Package: xfwm4 Version: 4.10.1-3 Severity: normal Tags: upstream Dear Maintainer, See original email here: https://mail.xfce.org/pipermail/xfce/2017-April/035547.html Two monitors, each 1920x1200 resolution, LHS monitor in landscape RHS in portrait. So the total "X desktop" space (e.g. on xrandr) is actually: (1920+1200) by 1920 :== 3120 x 1920 but of course some of the "X desktop" area on the left is not usable. xfwm4 is reasonably capable in its awareness of this situation, but insufficient. xfwm4 naturally has a built in compensation for this "unavailable area", both resizing, maximising and moving, new windows which are created with parameters "out of limits". Unfortunately its algorithm for "fixing up the location and size of 'badly' located and sized new X windows" is not correct in the config above, as follows: When the mouse pointer is on the LHS (e.g. over an xterm from which we launch a new xterm), and a new xterm is launched with geometry targetting the RHS, this works for new xterms which have size which is within the "visible size" of the LHS monitor. But if the newly created xterm, targetting the RHS monitor, is e.g. taller than the actual physical height of the LHS monitor (and the mouse cursor is within the LHS monitor), then xfwm INCORRECTLY resizes the newly created xterm before displaying it. Example: - have two monitors, LHS in landscape, RHS in portrait - make sure mouse cursor is within the bounds of LHS monitor - launch from LHS monitor a new xterm, with geometry: - height "too large" for LHS monitor, but within RHS monitor "height" - width within width of RHS monitor - e.g. if using a 6x10 font, and 1920x1200 monitors as above, then: xterm -geometry 128x150+1920+0 - xfwm incorrectly assesses the new window as "too tall for the current monitor" (rather than "actually, the new window is to be displayed on that second RHS monitor, and it's not too tall for that montor") - next, xfwm "reduces" the height of the new window to the maximum for "the on which it is to be displayed", in this case the RHS monitor, which effectively INCREASES the height of the newly created xterm! - finally, the new window is displayed (on the 2nd/RHS monitor) Now, to check what SHOULD happen: - same as above, but move the mouse cursor to the RHS monitor, before launching the new xterm - xfwm displays and sizes it correctly The inverse/vice-versa problem also happens (e.g. with mouse cursor on RHS monitor, try to create new xterm "too wide for RHS monitor" but not too wide for LHS monitor, and to be displayed on LHS monitor). When (again, in above lanscape+portrait monitor config): - starting xterms from a shell script, - for both LHS and RHS monitors, - and at least one RHS term is too tall if it were placed on LHS - and at least one LHS term is too wide if it were placed on RHS then there is no way to run this shell script and get the desired xterms layout, which is most definitely a bug. Finally I note that the wmctrl program could possibly be figured out and used to come in and mop up after xfwm fails to properly lay out the new xterm(s), but that looks quite complicated to me (hey, I haven't used it before :) and certainly this should be unnecessary to do, since I know the exact geometry I want, and I specify the exact, CORRECT geometry when starting my xterms from my script! One shouldn't have to apply the desired geometry twice, once after the window is created, just to mop up (even if this can be done). Regards, Zenaan -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=zen.UTF-8, LC_CTYPE=zen.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to zen.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfwm4 depends on: ii libc6 2.19-18+deb8u7 ii libdbus-glib-1-2 0.102-1 ii libgdk-pixbuf2.0-02.31.1-2+deb8u5 ii libglib2.0-0 2.42.1-1+b1 ii libgtk2.0-0 2.24.25-3+deb8u1 ii libpango-1.0-01.36.8-3 ii libstartup-notification0 0.12-4 ii libwnck22 2.30.7-2 ii libx11-6 2:1.6.2-3 ii libxcomposite11:0.4.4-1 ii libxdamage1 1:1.1.4-2+b1 ii libxext6 2:1.3.3-1 ii libxfce4ui-1-04.10.0-6 ii libxfce4util6 4.10.1-2 ii libxfconf-0-2 4.10.0-3 ii libxfixes31:5.0.1-2+b2 ii libxrandr22:1.4.2-1+b1 ii libxrender1 1:0.9.8-1+b1 Versions of packages xfwm4 recommends: ii librsvg2-common 2.40.5-1+deb8u2 Versions of packages xfwm4 suggests: ii xfce4 4.10.1 ii xfwm4-themes 4.10.0-2 -- no debconf information
Bug#832271: xfwm4: maximize behavior differs between screens of a dual-screen setup
Could be related to: xfwm4: Workspaces should have different margins for different screen on multihead https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530965
Bug#530965: xfwm4: Workspaces should have different margins for different screen on multihead
On Mon, May 01, 2017 at 01:14:26PM +1000, Zenaan Harkness wrote: > This bug is probably solved now - the OP didn't give a specific > example, but when I maximize a window e.g. firefox, xfwm4 correctly > maximises depending on the monitor I maximise on. > > Have not tested with gkrellm. Could also be related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832271
Bug#530965: xfwm4: Workspaces should have different margins for different screen on multihead
This bug is probably solved now - the OP didn't give a specific example, but when I maximize a window e.g. firefox, xfwm4 correctly maximises depending on the monitor I maximise on. Have not tested with gkrellm.
Bug#524711: [Pkg-xfce-devel] Bug#524711: xfwm4: New window placement problem
>> When I turn off 2), all new windows appear underneath, which is not >> what >> I want. I would like new windows to appear on top, but not above >> (and >> therefore cover, and take mouse/keyboard focus) a window that is >> currently in the middle of a mouse/keyboard action. > > Well, then you don't want it “on top”. And basically a window can be > on > top but not have focus. (yes I know, this is really hard, and I guess > it's harder for window manager developers :) ) The algorithm can be conceived: Z-depth of new window should be set as "on top" at the point in time when the user clicks/double-clicks the application icon or starts the app from the cmd line. the Z-depth of a newer window, i.e. an app started more recently in time, should be higher again, even though the window for the previously started app has not yet started. We can conceive a window manager wrapper for all "gui" apps: - the wrapper passes through all options to the underlying program - the wrapper does a single thing in addition: it also "passes" somehow (perhaps via an environment variable), the desired Z-order for "windows about to be created" Regards, Zenaan
Bug#861537: [PATCH 5] Fix table/unicode.tbl '#' quoting
- the number/hash/sharp symbol is now quoted - looks like this has not been used much, hopefully this utf-8 pathway will see more use soon --- table/unicode.tbl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/table/unicode.tbl b/table/unicode.tbl index 5828787..4753a03 100644 --- a/table/unicode.tbl +++ b/table/unicode.tbl @@ -55,7 +55,7 @@ start # characters removed. # -0x0023 # # NUMBER SIGN +0x0023 '#' # NUMBER SIGN 0x0025 % # PERCENT SIGN 0x0026 _and_ # AMPERSAND 0x002B + # PLUS SIGN -- 2.9.0
Bug#861537: [PATCH] Fix Debian Bug#861537: malformed UTF-8 chars in output - failure to fall through
Found the clean_utf_8() bug too (PATCH 4 above). Now the question comes to mind "why doesn't replacing space with '_' work in utf_8 mode?" Detox newbie here, so perhaps there's an obvious reason, but at least now we can cascade through from safe(), to utf_8(), as needed.
Bug#861537: [PATCH 4] Fix UTF-8 pathway, so fall through works properly.
- This should solve the malformed output bugs on each of the three main
pathways.
- Also made one of the new table files sane.
---
src/clean_string.c | 2 +-
table/punct2.tbl | 20 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/clean_string.c b/src/clean_string.c
index f1a75ba..fc84f72 100644
--- a/src/clean_string.c
+++ b/src/clean_string.c
@@ -681,7 +681,7 @@ unsigned char *clean_utf_8(unsigned char *s, void *opts)
/*
* Null translation == leave it alone
*/
- *input_walk -= characters_eaten;
+ input_walk -= characters_eaten - 1;
while (characters_eaten) {
*output_walk++ = *input_walk++;
diff --git a/table/punct2.tbl b/table/punct2.tbl
index 7a49307..2ea488f 100644
--- a/table/punct2.tbl
+++ b/table/punct2.tbl
@@ -2,15 +2,15 @@
start
-0x23 '#'
-0x25 %
-0x2b +
-0x2c ,
-0x2d -
-0x2e .
-0x3d =
-0x5e ^
-0x5f _
-0x7e ~
+0x23 _ # '#'
+0x25 _ # %
+0x2b _ # +
+0x2c _ # ,
+0x2d _ # -
+0x2e _ # .
+0x3d _ # =
+0x5e _ # ^
+0x5f _ # _
+0x7e _ # ~
end
--
2.9.0
Bug#861537: [PATCH 3] Tidy up table sample filenames - optional patch
- just tidy up the sample table filenames
- sample files need to be installed (and are on Debian), at least for new
users, and shouldn't end with ".sample"
- also this patch has little undo for space->tab conversion problem in last
patch (sorry)
---
etc/detoxrc.sample| 10 +-
table/{iso8859_1.tbl.sample => iso8859_1.tbl} | 0
table/{safe.tbl.sample => safe.tbl} | 0
table/{unicode.tbl.sample => unicode.tbl} | 0
4 files changed, 5 insertions(+), 5 deletions(-)
rename table/{iso8859_1.tbl.sample => iso8859_1.tbl} (100%)
rename table/{safe.tbl.sample => safe.tbl} (100%)
rename table/{unicode.tbl.sample => unicode.tbl} (100%)
diff --git a/etc/detoxrc.sample b/etc/detoxrc.sample
index 1e8bfe7..a1d6b9a 100644
--- a/etc/detoxrc.sample
+++ b/etc/detoxrc.sample
@@ -6,15 +6,15 @@
# met:
#
# 1. Redistributions of source code must retain the above copyright
-# notice, this list of conditions and the following disclaimer.
+#notice, this list of conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright
-# notice, this list of conditions and the following disclaimer in the
-# documentation and/or other materials provided with the distribution.
+#notice, this list of conditions and the following disclaimer in the
+#documentation and/or other materials provided with the distribution.
#
# 3. Neither the name of author nor the names of its contributors may be
-# used to endorse or promote products derived from this software
-# without specific prior written permission.
+#used to endorse or promote products derived from this software
+#without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
diff --git a/table/iso8859_1.tbl.sample b/table/iso8859_1.tbl
similarity index 100%
rename from table/iso8859_1.tbl.sample
rename to table/iso8859_1.tbl
diff --git a/table/safe.tbl.sample b/table/safe.tbl
similarity index 100%
rename from table/safe.tbl.sample
rename to table/safe.tbl
diff --git a/table/unicode.tbl.sample b/table/unicode.tbl
similarity index 100%
rename from table/unicode.tbl.sample
rename to table/unicode.tbl
--
2.9.0
Bug#861537: [PATCH 2/2] Add "fall through" sequences and samples
- These of course rely on the previous patch - fixing the detox bug causing
malformed UTF-8 chars.
- example table files provided, and can easily imagine some people will now
come up with specific sets of files which would work for their language, e.g.
Java creates (anonymous class) class files with '$' symbol in them, which
could possibly be useful for detox to know about (then again, may be not)
- added commend to detoxrc.sample about utf-8 cleaning method not yet done
---
etc/detoxrc.sample | 63 +-
table/brackets.tbl | 12 +++
table/punct1.tbl | 23
table/punct2.tbl | 16 ++
table/space.tbl| 5 +
5 files changed, 114 insertions(+), 5 deletions(-)
create mode 100644 table/brackets.tbl
create mode 100644 table/punct1.tbl
create mode 100644 table/punct2.tbl
create mode 100644 table/space.tbl
diff --git a/etc/detoxrc.sample b/etc/detoxrc.sample
index 3247fc7..1e8bfe7 100644
--- a/etc/detoxrc.sample
+++ b/etc/detoxrc.sample
@@ -6,15 +6,15 @@
# met:
#
# 1. Redistributions of source code must retain the above copyright
-#notice, this list of conditions and the following disclaimer.
+# notice, this list of conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright
-#notice, this list of conditions and the following disclaimer in the
-#documentation and/or other materials provided with the distribution.
+# notice, this list of conditions and the following disclaimer in the
+# documentation and/or other materials provided with the distribution.
#
# 3. Neither the name of author nor the names of its contributors may be
-#used to endorse or promote products derived from this software
-#without specific prior written permission.
+# used to endorse or promote products derived from this software
+# without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
@@ -32,6 +32,7 @@
#
# Basically just utf_8
#
+
sequence default {
utf_8;
safe;
@@ -67,6 +68,29 @@ sequence "lower" {
wipeup;
};
+sequence "punctuation" {
+ safe {filename "/usr/share/detox/space.tbl";};
+ safe {filename "/usr/share/detox/brackets.tbl";};
+ safe {filename "/usr/share/detox/punct1.tbl";};
+ wipeup;
+};
+
+sequence "unix" {
+ uncgi;
+ # perhaps insert utf_8 fall through option here (when implemented) ?
+ # i.e. unicode control characters, special blocks, line terminators
+ # (there's at least 4) etc, should be filtered out here, or in the
+ # lines below, but we need first to be able to replace "safe" with
+ # "utf_8" detox (internal) processing codepath (that's the "when
+ # implemented" bit :)
+ safe {filename "/usr/share/detox/space.tbl";};
+ safe {filename "/usr/share/detox/brackets.tbl";};
+ safe {filename "/usr/share/detox/punct1.tbl";};
+ safe {filename "/usr/share/detox/punct2.tbl";};
+ wipeup {remove_trailing;};
+};
+
+
#
# Sequences meant primarily for inline-detox
#
@@ -87,6 +111,35 @@ sequence "lower-only" {
lower;
};
+sequence "space" {
+ safe {filename "/usr/share/detox/space.tbl";};
+};
+
+sequence "brackets" {
+ safe {filename "/usr/share/detox/brackets.tbl";};
+};
+
+sequence "punct1" {
+ safe {filename "/usr/share/detox/punct1.tbl";};
+};
+
+sequence "punct2" {
+ safe {filename "/usr/share/detox/punct2.tbl";};
+};
+
+sequence "shell-punct" {
+ safe {filename "/usr/share/detox/space.tbl";};
+ safe {filename "/usr/share/detox/punct1.tbl";};
+};
+
+sequence "punct" {
+ # for performance, these might need to be combined into one file
+ safe {filename "/usr/share/detox/space.tbl";};
+ safe {filename "/usr/share/detox/brackets.tbl";};
+ safe {filename "/usr/share/detox/punct1.tbl";};
+ safe {filename "/usr/share/detox/punct2.tbl";};
+};
+
#
# Files to ignore (detox only)
diff --git a/table/brackets.tbl b/table/brackets.tbl
new file mode 100644
index 000..ade8770
--- /dev/null
+++ b/table/brackets.tbl
@@ -0,0 +1,12 @@
+# See file "LICENSE" for distribution and modification terms.
+
+start
+
+0x28 - # (
+0x29 - # )
+0x5b - # [
+0x5d - # ]
+0x7b - # {
+0x7d - # }
+
+end
diff --git a/table/punct1.tbl b/table/punct1.tbl
new file mode 100644
index 000..e5eb817
--- /dev/null
+++ b/table/punct1.tbl
@@ -0,0 +1,23 @@
+# See file "LICENSE" for distribution and modification terms.
+
+start
+
+0x21 _ # !
+0x22 _ # "
+0x24 _ # $
+0x27 _ # '
+0x2a _ # *
+0x2f _ # /
+0x3a _
Bug#861537: [PATCH] Fix Debian Bug#861537: malformed UTF-8 chars in output - failure to fall through
- Debian bug is Bug#861537
- when constructing a custom detox "translation table" with the fall through
option (no default specified, or "default" without a value), detox creates
malformed characters in the output - every "clean_*" code path is effected.
- clean_iso8859_1() and clean_safe() methods have simple change to fix this
bug.
- clean_utf_8() still to be done
- Thank you to Vasily Kolobkov for the fix, I am
a mere Java programmer still learning C.
---
src/clean_string.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/src/clean_string.c b/src/clean_string.c
index 7aa054e..f1a75ba 100644
--- a/src/clean_string.c
+++ b/src/clean_string.c
@@ -131,16 +131,15 @@ unsigned char *clean_iso8859_1(unsigned char *s, void
*opts)
* Null translation == leave it alone
*/
*output_walk++ = *input_walk++;
+ continue;
}
else {
replace_walk =
table->default_translation;
}
}
- if (replace_walk != NULL) {
- while (*replace_walk != '\0') {
- *output_walk++ = *replace_walk++;
- }
+ while (*replace_walk != '\0') {
+ *output_walk++ = *replace_walk++;
}
input_walk++;
@@ -296,16 +295,15 @@ unsigned char *clean_safe(unsigned char *s, void *opts)
* Null translation == leave it alone
*/
*output_walk++ = *input_walk++;
+ continue;
}
else {
replace_walk = table->default_translation;
}
}
- if (replace_walk != NULL) {
- while (*replace_walk != '\0') {
- *output_walk++ = *replace_walk++;
- }
+ while (*replace_walk != '\0') {
+ *output_walk++ = *replace_walk++;
}
input_walk++;
--
2.9.0
Bug#861537: detox: causes malformed UTF-8 characters when no default character is set - fails to "fall through"
Package: detox
Version: 1.2.0-5
Severity: normal
Tags: upstream patch
Dear Maintainer,
detox does not "pass through" - that is, when configuring a .tbl table
file with not default, or "default" with nothing else on the line,
followed by those changes I want to achieve with my files, detox fails
to achieve desired outcome. Instead with certain UTF-8 characters, detox
creates malformed output characters (i.e. incomplete).
Here's an example of what I cannot achieve with detox (only changing a
few problematic chars, keeping all the greek, cyrillic etc chars),
running in uxterm (or xterm -u8):
$ cat /home/justa/etc/detox/ztest.tbl
start
0x0026 _and_ # AMPERSAND
# Chars to translate to _
0x0020 _ # space
0x0021 _ # !
0x0022 _ # "
0x0024 _ # $
0x0027 _ # '
0x002a _ # *
0x002f _ # /
0x003a _ # :
0x003b _ # ;
0x003c _ # <
0x003e _ # >
0x003f _ # ?
0x0040 _ # @
0x005c _ # \
0x0060 _ # `
0x007c _ # |
# Chars to translate to -
0x0028 - # (
0x0029 - # )
0x005b - # [
0x005d - # ]
0x007b - # {
0x007d - # }
end
$ cat ~/.detoxrc
sequence gnu {
utf_8 {filename "/home/justa/etc/detox/ztest.tbl";};
};
$ env|egrep "LOC|LANG|UTF|utf|LC"
LC_ALL=zen.UTF-8
MAILCHECK=0
LANG=zen.UTF-8
XTERM_LOCALE=zen.UTF-8
unset -v CLASSPATH_LOCAL;
$ # (my custom locale is just UTF-8 with a custom default date format)
$ touch "mÉ Æ.txt"
$ ls *txt; ls -l *txt; ls -lb *txt
mÉ Æ.txt
-rw--- 1 justa justa 0 Apr 30 22:04 mÉ Æ.txt
-rw--- 1 justa justa 0 Apr 30 22:04 mÉ\ Æ.txt
What I want is for the file "mÉ Æ.txt" to end up with the following
name:
mÉ_Æ.txt
but instead as we can see:
$ detox -vs gnu *txt
Scanning: mÉ Æ.txt
mÉ Æ.txt -> m .txt
$ ls *txt; ls -l *txt; ls -lb *txt
m? ?.txt
-rw--- 1 justa justa 0 Apr 30 22:04 m? ?.txt
-rw--- 1 justa justa 0 Apr 30 22:04 m\207\ \204.txt
and we see that some malformed chars have been created,
(whatever that is, I'm not sure).
The patch, thanks to Vasily Kolobkov, is quite simple - basically just a
missing "continue;" is added in a couple of places, fixing up the
clean_safe and clean_iso8859_1 methods. There's probably a similar
change needed in clean_utf_8 method - this is not yet done.
Patch 1 is just the fix.
Patch 2 adds example table files for fine grained "cascading" in user
defined detox config sequences.
Patch 3 tidies up the "sample" filenames, which don't need to end with
".sample" and are actually required in a normal installation anyway, and
so e.g. on Debian stable, result in duplicate files (should be symlinks
at least, but shouldn't be duplicated anyway - DRY/ remove redunancy).
-- System Information:
Debian Release: 8.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=zen.UTF-8, LC_CTYPE=zen.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to zen.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages detox depends on:
ii libc6 2.19-18+deb8u7
detox recommends no packages.
detox suggests no packages.
-- no debconf information
Bug#819465: /sbin/losetup: losetup -l -a fails to work when /dev/loop/ (directory) exists
On Sun, Nov 06, 2016 at 03:27:00PM +0100, Andreas Henriksson wrote: > > > Any comments to convince me to reconsider closing this as wontfix? > > > > All I can add is that I have no preference for which way (old/new) that > > loop nodes are represented in the filesystem, but that, for control in > > my script, and certainty of closing correct loop nodes (optionally > > crypted), I needed to determine the exact loop node name for notation > > outside the startup script, and subsequent pull down of the node on > > shutdown. I recall having trouble obtaining the loop node name when > > relying on automatic allocation/creation - perhaps this is no longer a > > problem. > > I'd suggest using the output from 'losetup -f' if you need to know > the name. Ofcourse obtaining a name and then later allocating it > is racy, but oh well There's probably a good way to mount first > and then look up which loopdev was allocated to solve that if needed. Yes that's the issue. Anyway, the interesting thing I found (at least as of a few years ago now), is that the name is entirely arbitrary - can use any (currently unused) name. So because I had a bunch of debootstrap chroots I used to spin up and down automatically, I made sure that the loop dev name, matched the crypt dev name, matched the filename that stored this loop instance. Actually what I really did :), was take the container's basename, add a random string to that, and use this name as a dot file name to contain any other info I needed about the container instance, such as the loop dev name/num, so I could later determinstically unwind cleanly. This basename, a semi-randomized name (container basename + rand) became the unique, but somewhat recognizable, crypt dev name, and is stored in the dot file so I can cleanly locate the loop dev file. But given that the crypt subsystem (cryptsetup command at least) takes an arbitrary name, why not also the loop dev? So ultimately, what my scripts need to do, for very practical reasons, is allocate a new loop dev with a name predetermined by my script. And someone else's auto loop mounting lightweight container system, may have a different naming scheme you see, so someone using my scripts, may well want the loop devs created by it to be in a common directory, and those from some other lightweight container system to be contained in a different directory. And why not have such flexibility? Sure makes for quick determination of which vm (/ lightweight chroot etc) is related to which loop dev, which you're debugging or just wanting to investigate. The crypt devs already support this. Nowadays we have the -j option to losetup, along with -P and other goodies in other places, so things are steadily getting easier for the home-spun lightweight container buffs. Not to mention systemd :) - which reminds me, I need to go learn systemd :) Thanks again :) Zenaan
Bug#819465: /sbin/losetup: losetup -l -a fails to work when /dev/loop/ (directory) exists
On Sun, Nov 06, 2016 at 12:38:01PM +0100, Andreas Henriksson wrote: > > FWIW, I think it is much tidier to have all loop devices in a sub > > directory of /dev/ , but my personal scripts need their own directory > > anyway, and I think that /dev/loop/ should contain all "default" / > > "auto generated"/ system loop devices - but that's just appearance > > and would probably require changes to many packages, just guessing. > The loop nodes > are usually dynamically created these days so you don't need to > mess with them yourself. The automatic way will DTRT.) I think I was not clear - yes, they are (now) "automatic" from the admin setup perspective, but I'm pretty sure there is still a fixed upper limit, e.g. of 64 or something, which can be raised, but I think up to a maximum of 255 or something - but I last checked the kernel's loop module code only in March/April this year, and then it had that "max" hard coded kernel side limit that was existing up until that point at least. Perhaps it's been updated in more recent kernels to be fully dynamic in the kernel, to overcome this "max loop devices" limit? > The losetup utility supports both /dev/loopN and /dev/loop/N layout > (the latter likely for compatibility with older kernels/usecases). > > Atleast in my testing the attached patch should fix your particular > example, but I'm at the same time not sure how much else it breaks. > > I'm inclided to "wontfix" this because as far as I can tell the > problem only exists when you're /mixing/ both new and old way. Thank you for the old/new clarification. > That's something I'd just call not supported. I'd refer to using > either or. Either put your loop nodes in a the subdirectory or > don't. (I'd suggest don't and don't mess around with setting > things up more manually than you absolutely need. > Any comments to convince me to reconsider closing this as wontfix? All I can add is that I have no preference for which way (old/new) that loop nodes are represented in the filesystem, but that, for control in my script, and certainty of closing correct loop nodes (optionally crypted), I needed to determine the exact loop node name for notation outside the startup script, and subsequent pull down of the node on shutdown. I recall having trouble obtaining the loop node name when relying on automatic allocation/creation - perhaps this is no longer a problem. I can always reopen the bug if needed in the future, and there are other infrastructure projects nowadays anyway, rather than the old roll your own that I used up until I originally filed this bug report (containers, systemd and plenty more), which I should probably investigate and build on. > Regards, > Andreas Henriksson Thank you for the patch, appreciated. Kind regards, Zenaan
Bug#835382: liblog4j2-java-doc: depends on default-jdk-doc, mysteriously and unnecessarily
Package: liblog4j2-java-doc Version: 2.0~beta9-1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I tried to run eclipse, and got an error "Unrecognized VM option 'UseStringDeduplication'" Turns out eclipse-4.6 requires java 8, and default-jre on Debian stable is java7. This package dependency chain unnecessarily causes default-jre to be installed, causing default java (/etc/alternatives) to be java 7. * What exactly did you do (or not do) that was effective (or ineffective)? I uninstalled this package for now, there's some update-alternatives thing if I really needed to have this documentation installed, but I am not installing jre (and jdk!) version 7, and its documentation!, just to get liblog4j2-java-doc installed!!! * What was the outcome of this action? I removed liblog4j2-java-doc to solve the bloat. * What outcome did you expect instead? liblog4j2-java-doc should be installable without depending on default-java! Thanks :) Zenaan *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=zen.UTF-8, LC_CTYPE=zen.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to zen.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#383840: Solution to this bug: /usr/share/fonts/X11/misc/fonts.alias is the culprit - aliases need to be updated to 10646-1
/usr/share/fonts/X11/misc/fonts.alias is the culprit and needs to be updated with modern UCS / UTF8 / UTF-8 / ISO10646-1 alias defaults. The problem is that this file specifies as default font alias, for example: 6x10 -misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1 Note the "iso8859-1" char set - which according to wikipedia https://en.wikipedia.org/wiki/ISO8859-1 contains only 191 characters, whereas iso10646 https://en.wikipedia.org/wiki/ISO10646 contains up to 128,000 characters. The head of the above file dates it to circa 2000. Back then, UTF-8 support was probably thin on the ground, and defaulting the fonts to iso10646 may have caused problems. But today this is not the case, so this bug should probably be fixed by changing the default character sets for fixed font aliases, from iso8859-1 to iso10646-1. In the meantime, a workaround in X is to manually specify your font, for example as follows: xterm -fn "-misc-fixed-medium-r-normal--10-100-75-75-c-60-iso10646-1" and optionally if needed (don't know sorry), also specify the same font for your bold font: ... -fb "-misc-fixed-medium-r-normal--10-100-75-75-c-60-iso10646-1" It would certainly be preferable to just call, e.g.: uxterm -fn 6x10 -fb 6x10 I guess if this would possibly cause problems for some people (really everyone SHOULD be using utf8 by now, and at the very least the default should all be utf-8 by now), then additional alias could be included in the fonts.alias file above, e.g.: 6x10utf8 -misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1 or perhaps 6x10iso10646 -misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1 etc This is a generic xterm / uxterm problem, affecting vim, mutt etc, and not just emacs.
Bug#289078: should probably be closed
I believe this is an overstrike or "fake bolding" issue. With such tiny fonts, it is essential to disable xterm's auto bolding feature, for example in ~/.Xresources as follows: *xterm.allowBoldFonts: false *vt100.allowBoldFonts: false or alternatively set your bold font to match your normal font, e.g.: *xterm.font: 5x7 *xterm.boldFont: 5x7 In X, I just manually specify font from command line/ launch hotkey e.g.: xterm -fn -*-clean-medium-r-*-*-*-80-*-*-*-*-*-* \ -fb -*-clean-medium-r-*-*-*-80-*-*-*-*-*-* or e.g.: xterm -fn 5x7 -fb 5x7 This bug should be closed - the fonts are fine, it is just config if anything...
Bug#822438: a hint at the source of the problem
> Here's a hint at the source of the problem: > http://www.in-ulm.de/~mascheck/locale/ > " > XFree86 Xlib calls setlocale(3), but with values in > /usr/X11R6/lib/X11/locale/. If you - particularly after an upgrade - get > a "Warning: locale not supported by Xlib, locale set to C", then have a > look into locale.alias in that directory and adjust it, in case. > (Details from Olav Kvittem.) > " > > ... > > The /usr/share/X11/locale dir contains these files: > compose.dir > locale.alias > locale.dir adding the requisite/ corresponding lines for my custom chosen locale into each of the above 3 files, namely /usr/share/X11/locale/compose.dir /usr/share/X11/locale/locale.alias /usr/share/X11/locale/locale.dir handles the X/X11/xterm etc problem - I think in particular it is the /usr/share/X11/locale/locale.alias file which must be updated for xlib to not spew out its error. Works for me. Conclusion for me: these files either need to be auto updated by /usr/sbin/locale-gen , or a big command line WARNING ought be displayed suggesting to the end user who has changed (customized) their locale, to update those files to ensure X can find the specifics/ overridden data thingies that it needs. Would be nice to have.
Bug#822438: a hint at the source of the problem
Here's a hint at the source of the problem: http://www.in-ulm.de/~mascheck/locale/ " XFree86 Xlib calls setlocale(3), but with values in /usr/X11R6/lib/X11/locale/. If you - particularly after an upgrade - get a "Warning: locale not supported by Xlib, locale set to C", then have a look into locale.alias in that directory and adjust it, in case. (Details from Olav Kvittem.) " ... The /usr/share/X11/locale dir contains these files: compose.dir locale.alias locale.dir Which may also need to be updated if/when one creates a custom locale. Note also: /etc/locale.gen /etc/locale.conf /etc/locale.alias /etc/environment At the end of this tutorial: http://askubuntu.com/questions/21316/how-can-i-customize-a-system-locale is the suggestion to add your custom locale (or make sure the locale you wish to use is found in there I guess) to this file: /usr/share/i18n/SUPPORTED Yet, after all the above have been updated, still no go starting a new xterm, still the error: "Warning: locale not supported by Xlib, locale set to C" I guess next step is to try logout/login, or reboot.
Bug#822438: debian locales - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822438
Hi Michael, I just tried to subscribe to this bug, it affects custom locales too, see e.g.: http://askubuntu.com/questions/21316/how-can-i-customize-a-system-locale Have you solved this yet? In my case, I create a custom locale, as per instructions above, set locale to my custom locale: # cat /etc/locale.conf /etc/environment LANG=zen.UTF-8 LC_TIME="zen.UTF-8"
Bug#819465: /sbin/losetup: losetup -l -a fails to work when /dev/loop/ (directory) exists
Package: mount Version: 2.25.2-6 Severity: normal File: /sbin/losetup Dear Maintainer, Not sure if this is upstream. BUG: losetup fails to list loop devices in use when /dev/loop directory exists. I thought the /dev/loop-control file was all that was needed by losetup, but perhaps not - it's been a few years since I perused the kernel's loop module source code, which also reminds me, at some point it would be nice for kernel loop device support to be fully dynamic - for someone inclined, that could be an opportunity to learn to code in C and get some kernel cred. Background: I created a number of scripts a few years back to facilitate working with chroots in loop mounted files, run deboostrap in these etc. To facilitate my automation I found it convenient to create my own loop device nodes in a directory I created, namely: /dev/loop/ Today I finally solved the Subject problem that has arisen (I don't know when) with the /sbin/losetup command for me - it fails to list info/ list all loop devices (as in produces no output whatsoever) when there is a directory named /dev/loop - at least, when I deleted this directory, losetup started working properly again. >From memory, an 'ancient' version of Debian actually made use of and/ or supported loop devices being in the sub directory /dev/loop/ - perhaps 5 or more years ago, but don't quote me, my memory may be faulty. FWIW, I think it is much tidier to have all loop devices in a sub directory of /dev/ , but my personal scripts need their own directory anyway, and I think that /dev/loop/ should contain all "default" / "auto generated"/ system loop devices - but that's just appearance and would probably require changes to many packages, just guessing. WORKAROUND: rename loop device directory to /dev/lloop (or pick any name other than something beginning with "/dev/loop"). * What led up to the situation? Custom bash scripts breaking. * What exactly did you do (or not do) that was effective (or ineffective)? See WORKAROUND above - rename /dev/loop/ to /dev/something-else/ -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mount depends on: ii libc6 2.19-18+deb8u4 ii libmount1 2.25.2-6 ii libselinux12.3-2 ii libsmartcols1 2.25.2-6 mount recommends no packages. Versions of packages mount suggests: ii nfs-common 1:1.2.8-9 -- no debconf information
Bug#728669: analysis link of goldbug, its developers and etc
https://www.mail-archive.com/cypherpunks@cpunks.org/msg05277.html "goldbug" and all its developers now have zero credibility with me. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742578: reopen, retitle 742578, and add details
reopen 742578 ! reassign 742578 apt retitle 742578 --simulate (etc) dropped from apt summary 742578 apt-get man-page still includes --summary --no-act, Debian wiki tutorial depends on --no-act thank you The Debian wiki at: https://wiki.debian.org/BuildingAPackage/SourceInVCS currently relies on --no-act as follows: Vcs-* fields If apt-get source --no-act $package outputs a message like this: NOTICE: 'fdupes' packaging is maintained in the 'Git' version control system at: git://git.debian.org/users/morph/fdupes.git Perhaps either of the following would solve this bug - allowing this option again for apt-get, or both: - removing the options from apt-get's man page, - and putting alternative command in tutorial above (I don't know what that command would be sorry) Note that the comment from Ritesh below (above) "The newer versions of apt have completely replaced --simulate with -s." is incorrect, as far as I can see - see my test commands below, where all of -s and --simulate and the other variations (--no-act etc) all fail to work as per apt-get's manual page. Explanation for the record (re previous email from rrs@) follows: ------ Forwarded message -- From: Zenaan Harkness Date: Mon, 13 Oct 2014 23:52:00 +1100 Subject: Re: Processed: reassign 742578 apt Hi Ritesh, please let me know if my thinking is right on the following (I'm a user, not a DD): $ apt-get --version apt 1.0.9.2 for amd64 compiled on Oct 2 2014 22:36:40 ... $ apt --version apt 1.0.9.2 for amd64 compiled on Oct 2 2014 22:36:40 ... $ apt -s E: Command line option 's' [from -s] is not known. $ apt --simulate E: Command line option --simulate is not understood $ apt-get -s E: Command line option 's' [from -s] is not known. $ apt-get --simulate E: Command line option --simulate is not understood ie, it appears to me, that at least on my version of sid, that the --simulate option simply doesn't work. The option is in the man-page for apt-get, not in the man page for apt, and produces the same error as above, for both. This is why I transferred the bug to apt package, because to me it looks like a bug, and a debian.org tutorial (reprepro I think) says that option is needed with apt-get source, to get certain output (such as the vcs url for source package cloning). Do you think this is an error for apt/apt-get? Thanks Zenaan On 10/13/14, Ritesh Raj Sarraf wrote: > Why did you reassign it to apt ? This bug actually should be closed now. > The newer versions of apt have completely replaced --simulate with -s. ... -- Banned for life from Debian (MLs), for suggesting Debian's Code of Conduct is being swung in our faces a little too vigorously. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736258: acpid won't stop, won't upgrade (systemd) - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736258
Debian sid acpid | 1:2.0.22-3 Interrelated problem A: $ ps aux|egrep -i acpid root 318 0.0 0.0 0 0 ?S< 12:40 0:00 [ktpacpid] root 19855 0.0 0.0 4372 972 ?Ss 17:45 0:00 /usr/sbin/acpid $ sudo systemctl stop acpid Job for acpid.service canceled. $ ps aux|egrep -i acpid root 318 0.0 0.0 0 0 ?S< 12:40 0:00 [ktpacpid] root 19960 0.0 0.0 4372 972 ?Ss 17:46 0:00 /usr/sbin/acpid Interrelated problem B: $ sudo apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: acpid 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/54.5 kB of archives. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] Reading changelogs... Done (Reading database ... 354024 files and directories currently installed.) Preparing to unpack .../acpid_1%3a2.0.22-3_amd64.deb ... Job for acpid.service canceled. invoke-rc.d: initscript acpid, action "stop" failed. dpkg: warning: subprocess old pre-removal script returned error exit status 1 dpkg: trying script from the new package instead ... Job for acpid.service canceled. invoke-rc.d: initscript acpid, action "stop" failed. dpkg: error processing archive /var/cache/apt/archives/acpid_1%3a2.0.22-3_amd64.deb (--unpack): subprocess new pre-removal script returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/acpid_1%3a2.0.22-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Possibly the bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736258 Been happening the past week or so (although I hadn't tried to upgrade for a while before that). Any ideas? Zenaan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736682: linux-image-3.12-1-rt-amd64 3.12.8-1 fails to boot too early for netconsole; 3.12.6-2 succeeds
Package: src:linux Version: 3.12.8-1 Severity: critical Justification: breaks the whole system Dear Maintainer, *** Please consider answering these questions, where appropriate *** As subject says, the previous version 3.12.6-2 of the -rt-amd64 kernel boots on my Lenovo X220 laptop, the current version 3.12.8-1 does not. I successfuly enabled kernel netconsole logging, for all my installed kernels, with debug on etc, and I verify this with a bootable kernel (not -rt works), but the latest -rt kernel hangs too early in the boot process for any netconsole output to appear. I am competant to follow procedures, although I don't have access to a camera (very old phone, rural area) so I can't show the early boot log messages - although the last line of output that does appear on the boot screen is the following: [0.191060] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored (although the time is probably different) (this one just here is from my current non-rt kernel, but that's the last line of output I get when trying to boot the -rt kernel), so it looks like there is nothing obvious in the logs, as far as I can see (although I am not particularly familiar with them). I have two laptops - one to do the netconsole logging, but currently only one USB to serial port adapter - should I order/buy another, and try netconsole logging with a USB serial connection? Let me know what I need to do next to facilitate finding (if possible) this bug. Thanks Zenaan *** End of the template - remove these lines *** -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: LENOVO product_name: 4286CTO product_version: ThinkPad X220 chassis_vendor: LENOVO chassis_version: Not Available bios_vendor: LENOVO bios_version: 8DET61WW (1.31 ) board_vendor: LENOVO board_name: 4286CTO board_version: Not Available ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09) Subsystem: Lenovo Device [17aa:21da] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:21da] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: Kernel driver in use: i915 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04) Subsystem: Lenovo Device [17aa:21da] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_me 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04) Subsystem: Lenovo Device [17aa:21ce] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: e1000e 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 04) (prog-if 20 [EHCI]) Subsystem: Lenovo Device [17aa:21da] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: ehci-pci 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller [8086:1c20] (rev 04) Subsystem: Lenovo Device [17aa:21da] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel 00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b4) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:1c.1 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 [8086:1c12] (rev
Bug#736335: gladish does not allow viewing of jack settings or copying of application settings
Package: gladish Version: 1+dfsg0-4 Severity: wishlist Tags: upstream Dear Maintainer, *** Please consider answering these questions, where appropriate *** As I continue to set up my audio system and experiment, I discover that each time I need to check some jackd settings, I have to stop my whole studio including the track I'm currently playing. This is really annoying. Also, I can view the settings for an application, but cannot copy the application's command line, while it is running, either necessitating stopping that app, or the whole studio, or having to manually retype it in the other place that I need it (sometimes this has been documentation, sometimes this is simply to run the app in a command shell to test something else). So, there are definitely some UI limitations in gladish. Compare this to qjackctl, which _does_ allow viewing, and even changing! the jackd settings, whilst jackd is running! (of course, with a little warning that those settings will not take effect until jackd is restarted). So this behaviour of qjackctl is _much_ better, _much_ more convenient. With gladish, I keep having to work around its limitations. *** End of the template - remove these lines *** -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gladish depends on: ii ladish 1+dfsg0-4 ii libart-2.0-2 2.3.21-2 ii libatk1.0-02.10.0-2 ii libatkmm-1.6-1 2.22.7-2 ii libc6 2.17-97 ii libcairo2 1.12.16-2 ii libcairomm-1.0-1 1.10.0-1 ii libdbus-1-31.7.10-2 ii libdbus-glib-1-2 0.100.2-1 ii libflowcanvas5 0.7.1+dfsg0-0.2 ii libfontconfig1 2.11.0-2 ii libfreetype6 2.5.2-1 ii libgcc11:4.8.2-14 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglib2.0-0 2.36.4-1 ii libglibmm-2.4-1c2a 2.36.2-1 ii libgnomecanvas2-0 2.30.3-2 ii libgnomecanvasmm-2.6-1c2a 2.26.0-1 ii libgtk2.0-02.24.22-1 ii libgtkmm-2.4-1c2a 1:2.24.4-1 ii libpango-1.0-0 1.36.0-1+b1 ii libpangocairo-1.0-01.36.0-1+b1 ii libpangoft2-1.0-0 1.36.0-1+b1 ii libpangomm-1.4-1 2.34.0-1 ii libsigc++-2.0-0c2a 2.2.10-0.2 ii libstdc++6 4.8.2-14 Versions of packages gladish recommends: ii laditools 1.0.1-2 gladish suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736132: ladish: wmctrl integration to track and reset window locations and sizes, per-studio
Package: ladish Version: 1+dfsg0-4 Severity: wishlist Tags: upstream Dear Maintainer, *** Please consider answering these questions, where appropriate *** When I stop and start my studio (with gladish), I would like ladish to restore my window locations. I run alsaplayer, a compressor, two jack_mixer instances (capture and playback volume strips) and calfjackhost, and sometimes an independent windowed audio meter. Each time I reboot, or for some reason restart my ladish session, I have to drag all these windows around to where they "need" to be. Debian's wmctrl package provides the program wmctrl which may be quite convenient, especially eg: wmctrl -d wmctrl -l and corresponding options to move windows around given the right window ID as listed. In the meantime, calfjackhost has provided much organisation of what were 5 windows (with jalv) into just one window (calfjackhost). But I still have 5 or more windows which need placing each time I start my studio. *** End of the template - remove these lines *** -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ladish depends on: ii jackd 5 ii libc6 2.17-97 ii libdbus-1-3 1.7.10-2 ii libexpat1 2.1.0-4 ii libjack-jackd2-0 [libjack-0.116] 1.9.9.5+20130622git7de15e7a-1 ii libuuid1 2.20.1-5.5 ii python2.7.5-5 ii python-dbus 1.2.0-2+b1 Versions of packages ladish recommends: ii a2jmidid 8~dfsg0-1 Versions of packages ladish suggests: ii gladish 1+dfsg0-4 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736131: Feature: in calfjackhost, add "bypass" buttons, and optionally input and output gain knobs
Package: calf-plugins Version: 0.0.19+git20131202-1 Severity: wishlist Tags: upstream Dear Maintainer, *** Please consider answering these questions, where appropriate *** I am setting up a nice jackd based system, and calfjackhost rocks! However, I find myself clicking Edit button repeatedly, to open and later to close the various plugin edit windows, simply to enable and disable the "Bypass" for each plugin. It would be great to have these "Bypass" buttons mirrored in the Calf JACK Host :) Also, as a nice additional option, input and output gain knobs would be something I'd most likely enable, if they were available :) :) Also, some specific plugins may have one extra function (besides bypass, in and out gain) which is a particularly toggle-able function which might be useful to be able to enable in the Calf JACK Host, e.g.: The Bass Enhancer plugin has a "Listen" function - I run the bass enhancer in parallel with the 5-band Equalizer (not in series), and usually "Listen" is enabled, but for some tracks I like to disable the "List" function of the Bass Enhancer (given that I run it in parallel with eq5). Finally, the Multiband (4-band) Compressor, has 4 Bypass buttons, one for each band. It would of course make sense for these to all be avilable in the Calf JACK Host. In summary: Calf JACK Host provides a great opportunity for a visually tight (economic of screen realestate) yet feature/plugin-packed rack. *** End of the template - remove these lines *** -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages calf-plugins depends on: ii libatk1.0-0 2.10.0-2 ii libc6 2.17-97 ii libcairo2 1.12.16-2 ii libexpat1 2.1.0-4 ii libfftw3-single3 3.3.3-7 ii libfluidsynth11.1.6-2 ii libfontconfig12.11.0-2 ii libfreetype6 2.5.2-1 ii libgcc1 1:4.8.2-14 ii libgdk-pixbuf2.0-02.28.2-1+b1 ii libglib2.0-0 2.36.4-1 ii libgtk2.0-0 2.24.22-1 ii libjack-jackd2-0 [libjack-0.116] 1.9.9.5+20130622git7de15e7a-1 ii libpango-1.0-01.36.0-1+b1 ii libpangocairo-1.0-0 1.36.0-1+b1 ii libpangoft2-1.0-0 1.36.0-1+b1 ii libstdc++64.8.2-14 Versions of packages calf-plugins recommends: ii gtk2-engines-pixbuf 2.24.22-1 Versions of packages calf-plugins suggests: ii ladish 1+dfsg0-4 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736074: reassigned - only applies to jalv; was: calf-plugins: calf plugins lack graph display components, Calf Analyzer is empty, others still functional
On Sun, Jan 19, 2014 at 11:59:36PM +1100, Zenaan Harkness wrote: > Package: calf-plugins I reassigned this to package jalv > Dear Maintainer, > > When running a jackd session of some sort, the Calf plugins work in general, > except for the "graph" display components of the plugins. This is the case, when running the plugins with jalv. I suspect this 'bug' might ought be downgraded to feature-request. Feel free to do so if applicable. > I am currently using gladish to set up my session, and running plugins for > testing purposes from the command line (and adding them to gladish when they > appeal to me), for example, here's another command line plugin cmd/run: > > jalv.gtk http://calf.sourceforge.net/plugins/TransientDesigner I discovered calfjackhost - it supports the graph component of the calf plugins. I assumed something like that existed, but only just found it. > Also, the Calf Rack is missing, although it is advertised/mentioned in the > package description - however this should probably be a separate bug - let me > know if you'd like me to file a separate bug for this particular issue. This was not the case - I found it, as above. Thanks for your patience, Zenaan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736074: calf-plugins: calf plugins lack graph display components, Calf Analyzer is empty, others still functional
Package: calf-plugins Version: 0.0.19+git20131202-1 Severity: normal Dear Maintainer, *** Please consider answering these questions, where appropriate *** When running a jackd session of some sort, the Calf plugins work in general, except for the "graph" display components of the plugins. This is most visible in the Calf Analyzer plugin, which only shows graphs, and therefore when I run it, I get an empty plugin window, with no functionality. I am currently using gladish to set up my session, and running plugins for testing purposes from the command line (and adding them to gladish when they appeal to me), for example, here's another command line plugin cmd/run: jalv.gtk http://calf.sourceforge.net/plugins/TransientDesigner I ought be grateful, since from one perspective, the lack of graph components in these Calf plugins means I can fit more plugins in one screen - this principle would lead to a feature request for an option to disable such components - perhaps a button on each plugin screen - probably a feature-request bug for upstream though, not for the Debian packagers, I don't know. Also, the Calf Rack is missing, although it is advertised/mentioned in the package description - however this should probably be a separate bug - let me know if you'd like me to file a separate bug for this particular issue. I have tested the jalv.gtk, jalv.gtkmm, jalv.qt, and jalv.gtk3, which all work, except jalv.gtk3 only brings up the built-in default (LADSPA style) minimal gui for each plugin. All jalv.* plugin runners have the same problem displaying the graph. It is entirely feasible that the bug is a jalv bug, and that if the plugins are run in some other way, that they would display their graph components, I don't know sorry. If someone suggests a procedure/ application in which I can test the Calf plugins without using jalv, I am willing to do so. *** End of the template - remove these lines *** -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages calf-plugins depends on: ii libatk1.0-0 2.10.0-2 ii libc6 2.17-97 ii libcairo2 1.12.16-2 ii libexpat1 2.1.0-4 ii libfftw3-single3 3.3.3-7 ii libfluidsynth11.1.6-2 ii libfontconfig12.11.0-2 ii libfreetype6 2.5.2-1 ii libgcc1 1:4.8.2-14 ii libgdk-pixbuf2.0-02.28.2-1+b1 ii libglib2.0-0 2.36.4-1 ii libgtk2.0-0 2.24.22-1 ii libjack-jackd2-0 [libjack-0.116] 1.9.9.5+20130622git7de15e7a-1 ii libpango-1.0-01.36.0-1+b1 ii libpangocairo-1.0-0 1.36.0-1+b1 ii libpangoft2-1.0-0 1.36.0-1+b1 ii libstdc++64.8.2-14 Versions of packages calf-plugins recommends: ii gtk2-engines-pixbuf 2.24.22-1 Versions of packages calf-plugins suggests: ii ladish 1+dfsg0-4 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#359717: bash workaround
If using bash, this is what I've come to in my local bashlib,
over the last few years:
isMounted () {
# make sure a target/ arg is passed in:
[ -z "$1" ] && return 1
# turn target into fully qualified filename/ location
# (not doing so can cause problems with some of the tests I've tried,
# eg perhaps the one currently used see below):
DIR=`readlink -f "$1"`
# Option 1, from: http://arstechnica.com/civis//viewtopic.php?f=16&t=1174539
#
#grep -q "$DIR" /proc/mounts
#[ $? -eq 0 ] && return 0 # Alternatively: "return $?", I guess
# or alt alternative, make sure no other commands like echo follow :)
# From url: "For more robust bash scripting, using $? is preferred as it
# allows you to detect extra error conditions (like the command not
# existing, or you gave it syntactically invalid arguments, etc.)"
# Option 2:
#
# The following seemed unsophisticated, and clunky, when the /bin/mountpoint
# command is installed by default, thus option 3 below. But as can be seen
# with option 3, the "sophisticated" option is in fact buggy. I emailed
# this bug to initscripts maintainer, debian and ubuntu, on 20101029.
# See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359717
# See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622595
# See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460898
#mount | grep "on ${DIR} type" > /dev/null && return 0
#mount | grep -q "on ${DIR} type" && return 0
mount | grep -q "on ${DIR} type"
# Option 3:
#
# The following (off the web, and a standard command in debian)
# fails for a directory mounted on itself,
# which is needed prior to mount --make-rshared /directory.
#mountpoint -q ${DIR}
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622595: duplicate of 359717
This looks like a duplicate of: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359717 -- Free Australia: www.UPMART.org Please respect the confidentiality of this email as sensibly warranted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#359717: /bin/mountpoint bug: mount -o bind /dir /dir, creates a mountpoint for which /bin/mountpoint is unsuccessful
Sent this in 2010 as email to pkg-sysvinit-devel... :
PS: now I'm on sid, the following was from 2010:
To use 'mount --make-rshared' on say /media or /mnt, requires that
I first run:
mount -o bind /media /media
to create a mountpoint at /media, so that subsequently I can successfully run:
mount --make-rshared /media
This is useful when using chroots, as I do.
I was using "mountpoint -q $DIR" to determine if an arbitrary
directory was mounted or not, in my chroot u/mount script.
Unfortunately this broke when I started using "mount -o bind /media
/media".
So since /bin/mountpoint does not work, I am instead now using:
if mount | grep "on ${DIR} type" > /dev/null; then ...; fi
I just checked initscripts in a Ubuntu 10.04 chroot guest (initscripts
"Version: 2.87dsf-4ubuntu17"),
on my Ubuntu 8.04 host, and /bin/mountpoint there displays the same bug.
My Ubuntu 8.04 uname -a:
Linux ip61 2.6.24-28-generic #1 SMP Sat Oct 16 17:46:03 UTC 2010 i686 GNU/Linux
Initscripts Version: 2.86.ds1-14.1ubuntu45.1
Hope the above is useful,
Zenaan
--
Free Australia: www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694332: systemctl man page deficiency re user needing to be in adm group
> On 25.11.2012 16:20, Zenaan Harkness wrote: >> Package: systemd >> Version: 44-5 >> >> When I run systemctl status normally gives for a service, status >> output _and_ last 10 lines of journal output. >> >> Unless run as root (eg via sudo) or the user is in the adm group, only >> status is shown, and not the journal entries. >> >> The systemctl man page fails to advise the user of this requirement. >> >> The systemctl man page, or the README.Debian file or something like >> that, should advise the user of this requirement to be in the adm >> group to properly use systemctl/ systemd-journalctl. > > All this information is in the systemd-journalctl man page and the > systemctl man page already has as SEE ALSO systemd-journalctl(1). > I'm not convinced that duplicating that information in systemctl is > helpful. The systemctl man page is already long enough as it is. > Also note, that systemd-journalctl also warns you on stdout if you are > running as non-root user and you're not in group adm. Ahh, perhaps systemctl is calling journalctl with -q option? That would be the "bug" then. The problem is, systemctl is now masquerading as a front end to journalctl. Since it's doing that, to assist newbies it ought to by default give the same journalctl warning, and have the -q override this (*). I agree it's a minor bug, but it's a discoverability issue nonetheless. (*) I'm pretty sure this is the case, but currently can't boot with systemd again, so I've yet more to learn :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694332: systemctl man page deficiency re user needing to be in adm group
Package: systemd Version: 44-5 When I run systemctl status normally gives for a service, status output _and_ last 10 lines of journal output. Unless run as root (eg via sudo) or the user is in the adm group, only status is shown, and not the journal entries. The systemctl man page fails to advise the user of this requirement. The systemctl man page, or the README.Debian file or something like that, should advise the user of this requirement to be in the adm group to properly use systemctl/ systemd-journalctl. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#693843: systemd hangs on fstab "directory" bindmount
PS, This is still just an assumption, as I don't have a photographic memory of every command I ran over the last week, but it's the only way I can recreate something that appears similar/same as I experienced before, so it seems to me, the most likely possibility. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#693843: systemd hangs on fstab "directory" bindmount
OK, speaking of gooses, I've discovered the goose is me. I've just spent an hour testing and retesting, trying to recreate the problem! Quite exasperating. So I went back to previous versions of fstab, finally digging up an old internal IDE drive from a previous laptop, to find what I'd somehow changed and hadn't realised I'd changed. So: I use plug-in USB drives here and there (especially when rebuilding/ rescuing my workstation or [re]installing a box). To this end, I create fstab entries on occasion for my USB backup drive, in particular, normally with an "auto" mount option to speed up my reboot and rescue cycles. My brown paper bag moment (I was evidently not quite as rigorous in my one-change-at-a-time methodology as I thought I was) is my failure to add "noauto" or "comment=systemd.automount" to my USB rescue "automount". Twice now I've discarded entries in the thought that they were not relevant. This is not so cool, but anyway, problem found. Bit too late now, but I ought to have advised myself to attach a full fstab file, and someone probably would have seen it straight away. Thank you for assisting me on my wild goose chase. I'm now found so we can close this bug... Now, to discover if fstab somehow applies to the ls problem on my eee. Thanks Zenaan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681879: provide file:// url/uri packages/ download option alongside http:// and ftp://
This used to be possible! This morning I remembered that a few years ago (about 2008, perhaps earlier), I could drop into a shell, and configure something, then return to continue the installation with a file:// url for packages for installing a system. Anyone know how to do that now? Zen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681879: provide file:// url/uri packages/ download option alongside http:// and ftp://
Package: debian-installer Version: 20120716 testing Severity: wishlist When using expert-install, option is provided to get packages from a http:// or an ftp:// URL. file:// option should also be provided. This implies either command shell mounting, or some DI .udeb to provide a 'mount local/USB package mirror' step. At least, even manual (sub shell) mount and specification of file:// protocol, then enter the file path/url, manually, would be adequate for now. We have high-latency low-bandwidth rural internet connection, so anything other than installing off a CD or local HDD package archive is painful; we regularly travel to a location where we update our local mirror (USB) hdd, and package updates come from that. It is desirable to be able to install in the first instance onto new pcs, from our local mirror, rather than having to setup a webserver on another computer serving the mirror, plug our mirror in to that, cope with DI networking issues etc, all just for an install. Small laptops come without CD/DVD drive, limiting install option to USB stick (another current source of some frustration - for other bug reports). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
