Bug#912956: ttf-mscorefonts-installer: Should use https URLs
Package: ttf-mscorefonts-installer Version: 3.7 Severity: normal Dear Maintainer, The best would be to uses https URLs and uses https_proxy instead of https_proxy Christian -- System Information: Debian Release: buster/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.78 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ttf-mscorefonts-installer depends on: ii cabextract 1.6-1.1 ii debconf [debconf-2.0] 1.5.69 ii wget 1.19.5-2 ii xfonts-utils 1:7.7+6 Versions of packages ttf-mscorefonts-installer recommends: pn fonts-liberation ttf-mscorefonts-installer suggests no packages. -- debconf information: msttcorefonts/dldir: msttcorefonts/http_proxy: msttcorefonts/dlurl: msttcorefonts/savedir: msttcorefonts/baddldir:
Bug#912952: RM: postgresql-10-{pgrouting,postgis-2.4,postgis-2.5} [hurd-i386 kfreebsd-amd64 kfreebsd-i386] -- NBS; Superseded by postgresql-11-*
Package: ftp.debian.org Severity: normal postgis and pgrouting currently have unsatisfyable Build-Depends on the non-Linux ports. This is blocking the removal of postgresql-10 from unstable because of cruft. Please remove from unstable: postgresql-10-pgrouting [kfreebsd-amd64] postgresql-10-postgis-2.4 [hurd-i386 kfreebsd-amd64 kfreebsd-i386] postgresql-10-postgis-2.5 [hurd-i386] Thanks, Christoph
Bug#912924: classy-prelude-yesod: not worth maintenance burden?
Control: reassign -1 haskell-classy-prelude-yesod 1.4.0-1 On Sun, Nov 04, 2018 at 11:38:47PM +, Clint Adams wrote: > Package: classy-prelude-yesod you typoed the package name here… reassigning. > Version: 1.4.0-1 > Severity: serious > > classy-prelude-yesod is not currently needed and may not be > worth the maintenance burden. Please close this bug if you > disagree. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#912955: python-zeitgeist: depends on deprecated python-gobject-2
Package: python-zeitgeist Version: 1.0.1-0.2 Severity: important User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: oldlibs pygobject-2 This package depends on python-gobject-2, which is the old "static" Python binding for GLib and GObject. python-gobject-2 is only available for Python 2, and is unmaintained upstream. Python 2 will also reach end-of-life upstream during the lifetime of Debian 10 'buster'. Please port dependent packages to use PyGI (the python-gi or python3-gi packages in Debian), which is the GObject-Introspection-based replacement for python-gobject-2. More information about porting from the static bindings is available here: https://pygobject.readthedocs.io/en/latest/guide/porting.html python-gobject-2 and Python 2 will probably be removed from Debian during the bullseye release cycle, so the severity of this bug is likely to be increased to serious after the buster release. Thanks, smcv
Bug#912954: sat-xmpp-core: depends on deprecated python-gobject-2
Package: sat-xmpp-core Version: 0.7.0a1+hg20180914.f69c1b260e49-1 Severity: important User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: oldlibs pygobject-2 This package depends on python-gobject-2, which is the old "static" Python binding for GLib and GObject. python-gobject-2 is only available for Python 2, and is unmaintained upstream. Python 2 will also reach end-of-life upstream during the lifetime of Debian 10 'buster'. Please port dependent packages to use PyGI (the python-gi or python3-gi packages in Debian), which is the GObject-Introspection-based replacement for python-gobject-2. More information about porting from the static bindings is available here: https://pygobject.readthedocs.io/en/latest/guide/porting.html python-gobject-2 and Python 2 will probably be removed from Debian during the bullseye release cycle, so the severity of this bug is likely to be increased to serious after the buster release. Thanks, smcv
Bug#912953: wicd-daemon: depends on deprecated python-gobject-2
Package: wicd-daemon Version: 1.7.4+tb2-6 Severity: important User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: oldlibs pygobject-2 wicd-daemon depends on python-gobject-2, which is the old "static" Python binding for GLib and GObject. python-gobject-2 is only available for Python 2, and is unmaintained upstream. Python 2 will also reach end-of-life upstream during the lifetime of Debian 10 'buster'. Please port dependent packages to use PyGI (the python-gi or python3-gi packages in Debian), which is the GObject-Introspection-based replacement for python-gobject-2. More information about porting from the static bindings is available here: https://pygobject.readthedocs.io/en/latest/guide/porting.html python-gobject-2 and Python 2 will probably be removed from Debian during the bullseye release cycle, so the severity of this bug is likely to be increased to serious after the buster release. Thanks, smcv
Bug#912948: boost1.67: 1.68 or 1.69?
Op ma 5 nov. 2018 om 09:50 schreef Giovanni Mascellani : > I don't know, for the moment. First of all, we have to finish > transitioning to 1.67, which is already proving rather long, and What's holding up 1.67? > possibly getting rid of 1.62 (we can in theory ship more than a version > in the same distribution, but if we can avoid it it is better from my > point of view). > > Then, supposing that all of the above runs smoothly, we could aim for > 1.69, which is due to be released for December 12th. The transition > freeze is exactly a month after, so we would have just a month for doing > all the work of preparing the upload, update d/copyright (a quite time > consuming task), obtain a transition slot and fix all the reverse > dependencies. I am not really sure we really want to go through that, > but I reserve my decision for later. A beta is scheduled for November 14th, so preparations could start sooner. -- Olaf
Bug#898820: libicu-dev is not Multi-Arch compatible
I am unable to build Wine due to several packages being not multiarch, libicu-dev is one of them. Any hope of having it fixed in debian relatively soon?
Bug#912946: pygobject-2: deprecated and unmaintained upstream
On Mon, 05 Nov 2018 at 08:13:01 +, Simon McVittie wrote: > Please use PyGI (python-gobject, in the pygobject source package) instead. This should have said: Please use PyGI (python-gi or python3-gi) instead. python-gobject is a transitional package that depends on both python-gi and python-gobject-2. It should not be used either. smcv
Bug#912951: midori: update to midori 6
Package: midori Version: 0.5.11-ds1-4+b1 Severity: important Dear Maintainer, Some time ago, Midori was marked as deprecated and out of the new branches. But Midori is not dead. In fact, one new version is recently published. So, I contact you to notify this and , please, consider to re incorporate Midori to the main repositories. Thanks a lot. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-19.2-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), LANGUAGE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages midori depends on: ii libatk1.0-0 2.28.1-1 ii libc6 2.27-3 ii libcairo2 1.15.10-1 ii libfontconfig1 2.13.0-4 ii libfreetype62.8.1-2 ii libgck-1-0 3.20.0-5 ii libgcr-base-3-1 3.28.0-1 ii libgdk-pixbuf2.0-0 2.36.12-2 ii libglib2.0-02.58.1-2 ii libgtk2.0-0 2.24.32-3 ii libjavascriptcoregtk-1.0-0 2.4.11-4 ii libp11-kit0 0.23.12-2 ii libpango-1.0-0 1.42.4-1 ii libpangocairo-1.0-0 1.42.4-1 ii libpangoft2-1.0-0 1.42.4-1 ii libsoup-gnome2.4-1 2.60.3-1 ii libsoup2.4-12.62.2-2 ii libsqlite3-03.25.2-1 ii libwebkitgtk-1.0-0 2.4.11-4 ii libx11-62:1.6.6-1 ii libxml2 2.9.4+dfsg1-6.1 ii libxss1 1:1.2.2-1+b2 ii libzeitgeist-2.0-0 0.9.16-0.2 Versions of packages midori recommends: ii gnome-icon-theme 3.12.0-3 ii gnome-keyring 3.28.0.2-1 midori suggests no packages. -- no debconf information
Bug#896684: fontconfig-config errors: Maybe tightening the dependencies is an option?
On 2018-11-05 09:34:55 +0100, Laurent Bigonville wrote:
> For what I see, libfontconfig1 package has a dependency against
> fontconfig-config (>= ${source:Version})
>
> Note that the relation is >= and not =
>
> Looking at the git history, I can see the following commit:
>
> commit 7278b583d2ec28786ae75d1917a5eab98c63fbf9
> Author: Keith Packard
> Date: Sun Feb 23 14:29:53 2014 -0800
>
> Relax libfontconfig1 dependency on fontconfig-config to >=
> This will allow building the package on other architectures where
> the build dependencies require that fontconfig be installed in order
> to build fontconfig.
> Signed-off-by: Keith Packard
This requirement is really strange. I would say that something is
wrong in the build process. If the build requires some tool that
is built in a first step, it should use some search path relative
to the build directory.
> We could make the dependency more strict again, but that cause issues to
> build the package.
I don't see how a more strict dependency could cause issues to build
the package, since in any case, you need an older version to be
installed first. Then you could install all the needed generated
binary packages (new version) at the same time.
--
Vincent Lefèvre - Web:
Bug#882715: ping wrt mutt alternatives
> Thus, could you please use alternatives to manage /usr/bin/mutt ? Andreas: > patches So... I just got bitten by this again. Ping? -- ⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road? For thousands of years, the ⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the ⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk. To where it came ⠈⠳⣄ together with silk (judging by today's amber stalls).
Bug#904316: transition: boost-defaults
On 05/11/2018 09:32, László Böszörményi (GCS) wrote: > On Fri, Nov 2, 2018 at 9:57 AM Emilio Pozuelo Monfort > wrote: >> On 02/11/2018 00:13, Dimitri John Ledkov wrote: >>> On Mon, 23 Jul 2018 10:26:34 +0100 Dimitri John Ledkov >>> wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition >>> >>> This transition was ready to be started for just over three months now. >>> >>> May I upload boost-defaults to start the transition to boost1.67? >> >> Let's do this one once perl has migrated to testing. > Now the perl5.28 transition is over, it's migrated to testing. Boost > transition can start as Emilio noted. > Still, may I ask for two days to finalize the ICU 63.1 rebuilds and do > its transition[1] with Boost? These need to be done together as Boost > ABI changes with ICU rebuild. > > Sorry for the late note, even if ICU 63.1 is recently released - I > couldn't start much sooner. Yes, let's wait for those test results. Let us know how things are when your rebuild is finished. Cheers, Emilio
Bug#912948: boost1.67: 1.68 or 1.69?
Hi, Il 05/11/18 09:28, Olaf van der Spek ha scritto: > Source: boost1.67 > Severity: wishlist > > Dear Maintainer, > > What's the plan for Buster? 1.67, 1.68 or 1.69? > 1.69 would be nice. ;) I don't know, for the moment. First of all, we have to finish transitioning to 1.67, which is already proving rather long, and possibly getting rid of 1.62 (we can in theory ship more than a version in the same distribution, but if we can avoid it it is better from my point of view). Then, supposing that all of the above runs smoothly, we could aim for 1.69, which is due to be released for December 12th. The transition freeze is exactly a month after, so we would have just a month for doing all the work of preparing the upload, update d/copyright (a quite time consuming task), obtain a transition slot and fix all the reverse dependencies. I am not really sure we really want to go through that, but I reserve my decision for later. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#912950: ITP: puppet-module-antonlindstrom-powerdns -- Puppet module for PowerDNS
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: puppet-module-antonlindstrom-powerdns Version : 0.0.5 Upstream Author : Anton Lindström * URL : https://github.com/antonlindstrom/puppet-powerdns * License : GPL-2 Programming Lang: Puppet Description : Puppet module for PowerDNS Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . antonlindstrom-powerdns installs and manages PowerDNS. The configuration is split into several files and put in /etc/powerdns/pdns.d. This makes it easy to read which bits of the configuration are currently modified. Note: This is a missing dependency for puppet-module-designate which I intend to fix with this package.
Bug#911418: closed by to...@debian.org (Dr. Tobias Quathamer) (Bug#911418: fixed in rapid-photo-downloader 0.9.12-2)
control: severity -1 important Am 22.10.2018 um 04:19 schrieb Antoine Beaupré: > On 2018-10-20 22:03:03, Debian Bug Tracking System wrote: >> This is an automatic notification regarding your Bug report >> which was filed against the rapid-photo-downloader package: >> >> #911418: missing dependency: ImportError: cannot import name 'sip' >> >> It has been closed by to...@debian.org (Dr. Tobias Quathamer). > > ... I did not quite mean for you to take the patch I provided as-is > without investigating further. :) > > Upstream is unhappy with the result: > > https://discuss.pixls.us/t/rapid-photo-downloader-0-9-12-is-released/9209/6?u=anarcat > > Apparently, this is something about Qt.. It would be nice if you could > followup with him directly so that I wouldn't have to play the > intermediate like this. :) Hi Antoine, sorry for your intermediate role, that was not intended by me. However, I did not simply take your patch without investigation -- I did take a look at pyqt5 and found the changelog entry about the convenience code copy of sip. For me, that was a good enough reason why the sip copy in pyqt5 had not been used. Furthermore, I tried to run rapid-photo-downloader 0.9.12 with your patch applied, and I cannot see any problem. The program seems to work just fine in a current sid chroot. Therefore, I'm downgrading this bug. Hopefully we can investigate further if we get some new information. Regards, Tobias signature.asc Description: OpenPGP digital signature
Bug#912707: cp -p from ext4 partition to ntfs partition mounted with default permission mappings produces wrong file permissions
Jean-Pierre André wrote: Jean-Pierre André wrote: > I copy a directory tree from an ext4 partition to a NTFS one > mounted with 'permissions' option using cp -r -p. For all files > which have access permissions set to 755 their copies have > access mask 700, [...] /dev/sda1 on /mnt/ssd_win type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allo w_other,blksize=4096,user) This does not show your mount options. I need the command having the option "permissions" which you set. For instance, your syslog should show something like : Configuration type 7 KERNELPERMS 1 CACHEING 0 Version 2017.3.23AR.3 integrated FUSE 28 Requested device ../images/cf32M.ntfs canonicalized as /shared/ntfs/images/cf32$ Mounted /shared/ntfs/images/cf32M.ntfs (Read-Write, label "ntfs-try", NTFS 3.1) Cmdline options: permissions Mount options: allow_other,nonempty,default_permissions,relatime,fsname=/shared$ User mapping built, Posix ACLs not used, configuration type 7 An apparently unrelated problem: I cannot launch a linux executable file from NTFS partition, even using root priveleges. For running as root, one of the 'x' bit must be set (any one). If it is that way, the issue is probably not related to ntfs-3g. Did you also check your umask setting ? Note : I am to go on travel, I will probably not reply until end of next week.
Bug#896684: fontconfig-config errors: Maybe tightening the dependencies is an option?
On Thu, 19 Jul 2018 08:39:02 +0200 Thomas Viehmann wrote:
> Hi,
>
> So the original report experienced this - like me - with emacs.
> I could also produce it with just running fc-cache.
>
> Damien's hint is spot-on, thank you Damien!
>
> I had a 2.13 fontconfig-config but 2.12 (lib)fontconfig:
>
> ii fontconfig 2.12.6-0.1
> ii fontconfig-config 2.13.0-5
> ii libfontconfig1:amd64
> 2.12.6-0.1 ii libfontconfig1-dev:amd64
> 2.12.6-0.1
>
> After upgrading everything to 2.13.0-5, the errors are gone.
>
> Would it be an option to require the same (upstream?) version in the
> dependency on fontconfig on fontconfig-config. Clearly fontconfig may
> break if it get's a too new fontconfig-config.
For what I see, libfontconfig1 package has a dependency against
fontconfig-config (>= ${source:Version})
Note that the relation is >= and not =
Looking at the git history, I can see the following commit:
commit 7278b583d2ec28786ae75d1917a5eab98c63fbf9
Author: Keith Packard
Date: Sun Feb 23 14:29:53 2014 -0800
Relax libfontconfig1 dependency on fontconfig-config to >=
This will allow building the package on other architectures where
the build dependencies require that fontconfig be installed in order
to build fontconfig.
Signed-off-by: Keith Packard
We could make the dependency more strict again, but that cause issues to
build the package.
For what I can see, the circular dependency is caused by
texlive-binaries (used for the documentation generation) that pulls
libfontconfig1. That could be a good example for using the nodoc build
profile
Bug#904316: transition: boost-defaults
On Fri, Nov 2, 2018 at 9:57 AM Emilio Pozuelo Monfort wrote: > On 02/11/2018 00:13, Dimitri John Ledkov wrote: > > On Mon, 23 Jul 2018 10:26:34 +0100 Dimitri John Ledkov > > wrote: > >> Package: release.debian.org > >> Severity: normal > >> User: release.debian@packages.debian.org > >> Usertags: transition > >> > > > > This transition was ready to be started for just over three months now. > > > > May I upload boost-defaults to start the transition to boost1.67? > > Let's do this one once perl has migrated to testing. Now the perl5.28 transition is over, it's migrated to testing. Boost transition can start as Emilio noted. Still, may I ask for two days to finalize the ICU 63.1 rebuilds and do its transition[1] with Boost? These need to be done together as Boost ABI changes with ICU rebuild. Sorry for the late note, even if ICU 63.1 is recently released - I couldn't start much sooner. Laszlo/GCS [1] https://bugs.debian.org/912853
Bug#912948: boost1.67: 1.68 or 1.69?
Source: boost1.67 Severity: wishlist Dear Maintainer, What's the plan for Buster? 1.67, 1.68 or 1.69? 1.69 would be nice. ;) Gr, Olaf -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#884978: libtiff-dev: Please mark Multi-Arch: same
I was trying to compile Proton (https://github.com/ValveSoftware/Proton) from source on debian testing and failed to satisfy all dependencies of wine subcomponent. One of few remaining offending packages is libtiff-dev. I would appreciate if this would be fixed without waiting for upstream release. Thank you.
Bug#912947: autofs: new upstream version (5.1.5) available
Source: autofs Severity: wishlist Hi There was a new autofs version released (5.1.5) upstream, could it be packaged for Debian? Regards, Salvatore
Bug#908755: RM: knot-resolver [arm64] -- ROM; arm64 build fails
On Mon 2018-11-05 00:43:16 -0500, Scott Kitterman wrote: > I've asked for a give back on knot-resolver for armhf. If that succeeds, I > think it will migrate. thanks! looks like the giveback succeeded :) https://buildd.debian.org/status/fetch.php?pkg=knot-resolver=armhf=3.0.0-9=1541396378=0 > I will go ahead and to the rm, but I don't think that's what'll help. thanks for taking care of this, Scott. --dkg
Bug#909740: libsdl2-dev: No longer multi-arch co-installable
Hi, are there any ETAs on resolving this issue? It prevents me from building 32+64 bit Wine.
Bug#897040: fontconfig: .uuid files in font directories not removed during purge
On Tue, 23 Oct 2018 10:49:32 +0200 Andreas Beckmann wrote: > On Wed, 26 Sep 2018 19:49:31 +0200 Sven Joachim wrote: > > On 2018-05-23 16:43 +0200, Laurent Bigonville wrote: > > That upstream bug has been fixed in commit f5dd851[1] which is included > > in fontconfig 2.13.1, so I think the Debian bug should be closed too. > > Haven't tested whether the fix works, though. > > This doesn't work, or maybe it does not get executed by the removal > sequence performed by piuparts. > > Removing fonts-cantarell (0.111-2) ... > Removing fontconfig (2.13.1-1) ... > Removing libfontconfig1:amd64 (2.13.1-1) ... > Removing fontconfig-config (2.13.1-1) ... > Removing fonts-dejavu-core (2.37-1) ... > Removing libexpat1:amd64 (2.2.6-1) ... > Removing libfreetype6:amd64 (2.8.1-2) ... > Removing libpng16-16:amd64 (1.6.34-2) ... > Processing triggers for libc-bin (2.27-6) ... > > 0m52.0s INFO: IGNORED PATH@2: /usr/share/fonts/truetype/dejavu/.uuid > 0m52.0s INFO: IGNORED PATH@2: /usr/share/fonts/.uuid > 0m52.0s INFO: IGNORED PATH@2: /usr/share/fonts/opentype/.uuid > 0m52.0s INFO: IGNORED PATH@2: /usr/share/fonts/opentype/cantarell/.uuid > 0m52.0s INFO: IGNORED PATH@2: /usr/share/fonts/truetype/.uuid > 0m52.5s ERROR: FAIL: Package purging left files on system: > /usr/share/fonts/opentype/ owned by: fonts-cantarell > /usr/share/fonts/opentype/cantarell/ owned by: fonts-cantarell > > Tried it manually in a sid chroot, there it works if fontconfig can > perform its trigger processing. > > But if fontconfig has pending triggers while being removed, .uuid files > will stay behind. > Probably add a fontconfig.prerm script and in the "remove" case perform > that same actions as in fontconfig.configure "triggered" > > fc-cache unfortunately does not seem to have an option for "clear the > cache and delete all .uuid files (and do not regenerate anything)" which > would be the best thing to do in fontconfig.prerm remove FTR, f5dd851 has been reverted in fontconfig, see https://gitlab.freedesktop.org/fontconfig/fontconfig/merge_requests/8 An other attempt to implement this is waiting at https://gitlab.freedesktop.org/fontconfig/fontconfig/merge_requests/10
Bug#912946: pygobject-2: deprecated and unmaintained upstream
Source: pygobject-2 Version: 2.28.6-13 Severity: important Tags: wontfix Control: block -1 by 885135 python-gobject2 (src:pygobject-2) is an old branch of the pygobject source package. It no longer receives any upstream support, is Python-2-only, and will probably be removed from Debian after the Debian 10 'buster' release. Please use PyGI (python-gobject, in the pygobject source package) instead. smcv
Bug#911772: fontconfig: missing build dependencies
tag 911772 + moreinfo thanks On Wed, 24 Oct 2018 17:22:50 +0200 Francesco =?utf-8?Q?Potort=C3=AC?= wrote: Hello, > > While rebuilding the package, evan after > > $ aptitude build-dep fontconfig > > I had to manually install > uuid-dev > docbook-utils I cannot reproduce this here in a clean build environment. Did you get any log or error message when trying to build fontconfig? Kind regards, Laurent Bigonville
Bug#912945: ITP: egl-wayland -- Wayland EGL External Platform library
Package: wnpp Severity: wishlist Owner: Timo Aaltonen * Package name: egl-wayland Version : 1.1.0 Upstream Author : NVIDIA * URL : https://github.com/NVIDIA/egl-wayland * License : MIT Programming Lang: C Description : Wayland EGL External Platform library This is a work-in-progress implementation of a EGL (Embedded-System Graphics Library) External Platform library to add client-side Wayland support to EGL on top of EGLDevice and EGLStream families of extensions. This library implements an EGL External Platform interface to work along with EGL drivers that support the external platform mechanism.
Bug#912707: cp -p from ext4 partition to ntfs partition mounted with default permission mappings produces wrong file permissions
On Mon, Nov 5, 2018 at 8:58 AM László Böszörményi (GCS) wrote: > On Mon, Nov 5, 2018 at 4:54 AM Ilya Tsindlekht > wrote: > > No, it doesn-t seem to be the case > > ~/ (mount ; getfacl /mnt/ssd_win ; ls -l /bin/bash ; getfacl /bin/bash > > ; sudo cp -p /bin/bash /mnt/ssd_win ; ls -l /mnt/ssd_win/bash ; getfacl > > /mnt/ssd_win/bash ) > test > > results > Can you try the ntfs-3g 1:2017.3.23AR.3-1 version from unstable if > that produce the same problem or not? Sorry typo, it's available from experimental. Laszlo/GCS
Bug#912707: cp -p from ext4 partition to ntfs partition mounted with default permission mappings produces wrong file permissions
On Mon, Nov 5, 2018 at 4:54 AM Ilya Tsindlekht wrote: > On Sat, 03 Nov 2018 12:14:46 +0100 =?UTF-8?Q?Jean-Pierre_Andr=c3=a9?= > wrote: > > Jean-Pierre André wrote: > > > > I copy a directory tree from an ext4 partition to a NTFS one > > > > mounted with 'permissions' option using cp -r -p. For all files > > > > which have access permissions set to 755 their copies have > > > > access mask 700, > > > > [...] > > > > > Can you confirm this matches your situation by displaying the ACL > > > of the base directory you are copying from (the one designated as > > > source in your "cp -p") : > > > getfacl your-source-directory > > > > Sorry, I meant the target directory, not the source one : > > getfacl your-target-directory > > > > > > > No, it doesn-t seem to be the case > ~/ (mount ; getfacl /mnt/ssd_win ; ls -l /bin/bash ; getfacl /bin/bash > ; sudo cp -p /bin/bash /mnt/ssd_win ; ls -l /mnt/ssd_win/bash ; getfacl > /mnt/ssd_win/bash ) > test > results Can you try the ntfs-3g 1:2017.3.23AR.3-1 version from unstable if that produce the same problem or not? Thanks, Laszlo/GCS
