XZ Utils Compromised Releases

[Frank Dean]

I received a security announcement on the Debian mailing list [1].  It appears 
versions 5.6.0 of XY Utils and later may be compromised.  I also found a 
discussion on Openwall [2].


[1]: https://lists.debian.org/debian-security-announce/2024/msg00057.html 


[2]: https://www.openwall.com/lists/oss-security/2024/03/29/4 



I'm afraid that's all I know.  Just a heads-up.

Re: Files and Folders access

[Frank Dean]

Lenore Horner  writes:

> [1:text/plain Show]
>
>
> [2:text/html Hide Save:noname (7kB)]
>
> I’m still struggling with letting Inkscape (I think Gimp too) installed via 
> MacPorts to be able to open files.  I’ve searched the mailing list archive 
> for the last
> year for any mention of this and found zip so apparently I’m particularly 
> incompetent.  Here’s what I’ve tried.
>
> Big Sur 11.6
> MacPorts base 2.7.1
> Just updated the tree and all anything listed as outdated.
> inkscape-app @0.92_1, inkscape @0.92.5_9_x11, and xorg-server @1.20.11_1  
> installed and active
> r
> In Apple -> System Preferences -> Security and Privacy -> Files and Folders I 
> cannot do any thing even having unlocked with an admin password.
> In Apple -> System Preferences -> Security and Privacy -> Full Disk Access I 
> have given the following access the following:
> Inkscape (the terminal app found with Show Contents in the Inkscape.app file 
> in my MacPorts folder)
> Xquartz
> Terminal
> X11.app
> Inkscape.app (the Inkscape icon in the MacPorts folder)
>
> I’ve shut down and restarted the computer and I’m still getting  "Could not 
> read the contents of Desktop” and a parallel complaint for Documents.  I know
> that a dialog box should pop up asking for my permission to access my 
> Desktop, Documents, etc. folder and that those dialogs not popping up is a 
> known
> (and unfixible I think) issue.  I thought granting full disk access was the 
> only known work-around, but full disk access to what?   
>
> I have, by the way also tried the dmg from the Inkscape website for version 
> 1.1.1.  I don’t get error messages with it, but it also can’t open a file 
> (spinning
> beachball of death). So that’s not good either.  
>
> Thanks,
> Lenore


Hi Lenore,

I don't know if this is the **proper** way to do it, but after running
Inkscape via the launcher, `ps ux | grep -i inkscape` shows Inkscape is
being executed via `/bin/sh`.

Giving `/bin/sh` full disk access allows it to open files in the
Documents folder, but presumably this allows pretty well all
applications to access the entire disk, somewhat subverting the entire
privacy mechanism.  Hopefully, someone knows of a better way.

Similarly, granting the Terminal application access to the Documents
folder allows you to execute the inkscape binary from `/usr/local/bin`
and open documents in the Documents folder, with the advantage of being
able to reduce the scope of access.

All, far from intuitive.

Cheers,

Frank

Re: Portfile dependencies relying on specific variant Mugvagut7

[Frank Dean]

Ryan Schmidt  writes:

> On Oct 5, 2021, at 05:36, Frank Dean wrote:
>> 
>> I've submitted a pull request [1] for a new Portfile, `mod_tile`, but the
>> checks are failing because this port requires the `mapnik` port to be
>> installed with a non-default variant, `+postgis`.  Similarly, it requires the
>> `osm2pgsql` port to have been installed with `+lua`.
>> 
>> [1]: https://github.com/macports/macports-ports/pull/12391
>> 
>> I've specified the dependency with:
>> 
>>require_active_variants mapnik postgis
>> 
>> If the dependent ports have not already been installed with the correct
>> variant, simply performing a `port install` on `mod_tile` fails due to this
>> dependency check, unless the install command includes the variant specifiers.
>> 
>> 1.  How should I handle this so that the automated builds complete
>>successfully?
>
> There is no solution. MacPorts base does not have the ability to depend on a 
> variant of a port. (https://trac.macports.org/ticket/126)
>
>
>> 2.  How can I improve the user experience in the same scenario?
>
> The user experience is already as good as it can get, given how things 
> currently work in MacPorts.
>
> Ideally, ports should be designed so that they can depend on other ports 
> wholesale without regard for variants.
>
> For example, if osm2pgsql's lua support is something that other ports want to 
> depend on, then either osm2pgsql should be modified so that it provides lua 
> support unconditionally, or osm2pgsql's lua support should be broken out into 
> another port (perhaps a subport) perhaps called osm2pgsql-lua.

Thanks Ryan, I'll submit PR's for the other ports and follow up with their
maintainers.

Portfile dependencies relying on specific variant

[Frank Dean]

Apologies, resending to dev list as incorrectly sent to user's list.


I've submitted a pull request [1] for a new Portfile, `mod_tile`, but the
checks are failing because this port requires the `mapnik` port to be
installed with a non-default variant, `+postgis`.  Similarly, it requires the
`osm2pgsql` port to have been installed with `+lua`.

[1]: https://github.com/macports/macports-ports/pull/12391

I've specified the dependency with:

require_active_variants mapnik postgis

If the dependent ports have not already been installed with the correct
variant, simply performing a `port install` on `mod_tile` fails due to this
dependency check, unless the install command includes the variant specifiers.

1.  How should I handle this so that the automated builds complete
successfully?

2.  How can I improve the user experience in the same scenario?


Thanks,

Frank Dean

Portfile dependencies relying on specific variant

[Frank Dean]

I've submitted a pull request [1] for a new Portfile, `mod_tile`, but the
checks are failing because this port requires the `mapnik` port to be
installed with a non-default variant, `+postgis`.  Similarly, it requires the
`osm2pgsql` port to have been installed with `+lua`.

[1]: https://github.com/macports/macports-ports/pull/12391

I've specified the dependency with:

require_active_variants mapnik postgis

If the dependent ports have not already been installed with the correct
variant, simply performing a `port install` on `mod_tile` fails due to this
dependency check, unless the install command includes the variant specifiers.

1.  How should I handle this so that the automated builds complete
successfully?

2.  How can I improve the user experience in the same scenario?


Thanks,

Frank Dean

Re: changing 'configure' options for testing

[Frank Dean]

Daniel J. Luke  writes:

> The newest version of clamav uses cmake for builds. In the 'configure' stage, 
> I have it disabling tests because otherwise it won't build without the test 
> dependencies installed (check and pytest). 
>
> Do we have a template or example of a canonical way to handle this? I don't 
> see an obvious hook for when someone is running `port test` to change 
> configure.args (I could, of course, add a post-extract/pre-configure and do 
> some non-declaritive test to see if `port test` is being run and use that to 
> branch - but that feels like a bad design choice).

The rapidjson port implements a 'tests' variant to handle a similar
situation.  I used the same pattern for the libosmium port.  The tests
can then be run with `sudo port -d test current +tests`.

HTH

Frank

Re: Zint port?

[Frank Dean]

Henning Hraban Ramm  writes:

> [1:text/plain Hide]
>
> The barcode maker/library zint (https://zint.org.uk) is only available via 
> Homebrew yet.
>
> It depends on cmake and libpng-dev, but if I try to compile the sources with 
> MacPorts libs, it fails to find stdio.h
>
> I don’t speak C...
>
> I’d appreciate a zint port, but a hint what environment variables I should 
> set or whatever else I should try would be nice enough.
>
> Best regards,
> Hraban
>
> [2:application/pgp-signature Show Save:signature.asc (833B)]

Specifying the cmake PortGroup will do almost all of the work for you:

PortGroup   cmake 1.1

If you choose to get it from their GitHub mirror, use the github port
group:

PortGroup   github 1.0
github.setupwoo-j zint 2.10.0
github.tarball_from archive

You might want to use the macports-dev mailing list for any more
Portfile development questions.

[1]: https://lists.macports.org/mailman/listinfo/macports-dev/

HTH

Frank

Re: GNUradio on Mac mini Big Sur M1 Install errors

[Frank Dean]

Dan Hinckley  writes:

> I’m not clever enough to understand these errors. If there is a remedy, can 
> someone point me at solutions?
>
>> sudo port install gnuradio
>> Password:
>> --->  Computing dependencies for glib2
>> --->  Fetching archive for glib2
>> --->  Attempting to fetch 
>> glib2-2.62.6_0+universal+x11.darwin_20.arm64-x86_64.tbz2 from 
>> https://packages.macports.org/glib2
>> --->  Attempting to fetch 
>> glib2-2.62.6_0+universal+x11.darwin_20.arm64-x86_64.tbz2 from 
>> https://ywg.ca.packages.macports.org/mirror/macports/packages/glib2
>> --->  Attempting to fetch 
>> glib2-2.62.6_0+universal+x11.darwin_20.arm64-x86_64.tbz2 from 
>> https://mse.uk.packages.macports.org/glib2
>> --->  Fetching distfiles for glib2
>> --->  Attempting to fetch glib-2.62.6.tar.xz from 
>> http://mirror.cc.columbia.edu/pub/software/gnome/sources/glib/2.62/
>> --->  Attempting to fetch glib-2.62.6.tar.xz from 
>> https://distfiles.macports.org/glib2
>> --->  Verifying checksums for glib2
>> --->  Extracting glib2
>> --->  Applying patches to glib2
>> --->  Configuring glib2
>> Warning: Configuration logfiles contain indications of 
>> -Wimplicit-function-declaration; check that features were not accidentally 
>> disabled:
>>   isnanf: found in build-x86_64/meson-logs/meson-log.txt
>> --->  Building glib2
>> --->  Staging glib2 into destroot
>> Error: Failed to destroot glib2: glib-2.0.pc differs in 
>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/work/destroot-arm64//opt/local/lib/pkgconfig
>>  and 
>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/work/destroot-ppc-intel//opt/local/lib/pkgconfig
>>  and cannot be merged
>> Error: See 
>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/main.log
>>  for details.
>> Error: Unable to execute port: upgrade cairo failed

It looks like it's doing a 'universal' build of 'glib2' for both 'arm64' and
'ppc-intel/x86_64' architectures, which you probably don't need.

My understanding is that MacPorts no longer builds 'universal' by default [1].
Is '+universal' defined in your '/opt/local/etc/macports/variants.conf'?

[1]: https://trac.macports.org/wiki/FAQ#universal

The 'main.log' referred in the error messages may have more information.

You could try cleaning the 'glib2' build and specifically disabling the
'universal' variant [2] while installing glib2.

[2]: https://guide.macports.org/#using.variants

$ sudo port clean glib2
$ sudo port install glib2 -universal

I'd concentrate on installing 'glib2' before continuing to install
'gnuradio'.

Re: Portfiles for an OpenStreetMap Tile Server

[Frank Dean]

Craig Treleaven  writes:

>> On Aug 29, 2021, at 8:02 AM, Frank Dean  wrote:
>> 
>> I have a few questions to ask in relation to a series of Portfiles that
>> I have created to support installing and running a map tile server for
>> OpenStreetMaps [1].
>> 
>> [1]: https://switch2osm.org/serving-tiles/
>> 
>> The logical Portfiles:
>> 
>> - libprotozero - library required by libosmium
>> 
>>https://github.com/mapbox/protozero
>> 
>> - libosmium - library required by osmium-tool
>> 
>>https://github.com/osmcode/libosmium
>> 
>> - osmium-tool - application required at runtime by mod_tile/renderd
>> 
>>https://github.com/osmcode/osmium-tool
>> 
>> - osmosis - Java application required at runtime by mod_tile/renderd
>> 
>>https://github.com/openstreetmap/osmosis
>> 
>> - openstreetmap-carto - style sheets used by mod_tile/renderd
>> 
>>https://github.com/gravitystorm/openstreetmap-carto
>> 
>> - mod_tile/renderd - the OpenStreetMaps tile server
>> 
>>https://wiki.openstreetmap.org/wiki/Mod_tile
>> 
>> 1.  Should I submit each Portfile in dependency order and await its
>>acceptance before submitting the next in sequence, or submit them
>>in dependency related batches in a single pull request?
>> 
>> 2.  The primary port is 'mod_tile' which contains an Apache module for
>>serving the tiles and a 'renderd' daemon that renders and creates
>>tile images based on requests from 'mod_tile'.  Both artefacts are
>>created in a single build.
>> 
>>I have currently named the port 'renderd', but the project is
>>commonly known as 'mod_tile'.  Naming the port 'renderd' was the
>>only way I could succeed in the 'renderd' startup item being loaded
>>via the 'sudo port load ${subport}' command.
>> 
>>Is there a better way of naming and creating this port, perhaps as
>>subports?
>> 
>> 3.  Getting the tile server up and running requires quite a number of
>>steps.  I have created a shell script to largely automate the
>>process.  At runtime it uses scripts from both 'openstreetmap-carto'
>>and 'mod_tile/renderd', so doesn't immediately sit comfortably being
>>installed with either of them.
>> 
>>Is it best to create a simple separate standalone port (without an
>>upstream project), containing just the shell script, naming it
>>something like 'osm-tile-server' and depending on the other two
>>ports; or simply include it in one of the other ports with runtime
>>checks for the existence of required executables with helpful error
>>messages when they're absent?
>> 
>> Many thanks,
>> 
>> Frank
>
> I’ll offer my thoughts to get the ball rolling.  First, from briefly looking 
> over the involved projects, this is a relatively complex set of ports so be 
> prepared that it may take some time to get everything working properly.  Good 
> on you for tackling this!
>
> Do you have some support upstream?  AFAICT, mod_tile seems to pretty much 
> only on Debian at this point.  
>
> Re your questions:
>
> 1) I think you should add the ports in dependency order rather than one 
> submission including everything.  These days, pull requests tend to get acted 
> on more quickly than tickets.  If you haven’t seen it, we have a wiki page 
> about MacPorts and git at:
>
> https://trac.macports.org/wiki/WorkingWithGit 
> <https://trac.macports.org/wiki/WorkingWithGit#CommongittaskswhileworkingwithMacPortsbase>
>
> You can submit multiple pull requests at once.  Just add links to the other 
> related PRs so anyone reviewing will know that there is a series.
>
> 2) I see that the GitHub project is named “mod_tile” while Debian has called 
> their package "libapache2-mod-tile”.  MacPorts has several ports named 
> mod_foo so I think mod_tile makes the most sense.
>
> https://ports.macports.org/search/?installed_file==mod_=on 
> <https://ports.macports.org/search/?installed_file==mod_=on>
>
> Re the startup item, I think you should be able to use the startupitem.name 
> and startup item.executable keywords to make the renderd daemon work as 
> required.  No?
>
> https://guide.macports.org/#reference.startupitems 
> <https://guide.macports.org/#reference.startupitems>
>
> 3) Without seeing the shell script you’ve developed, it is difficult to say 
> whether you should add it to the mod_tile port or port it in a standalone 
> port.  I would lean towards including it in mod_tile.  Perhaps you could 
> submit it u

Portfiles for an OpenStreetMap Tile Server

[Frank Dean]

I have a few questions to ask in relation to a series of Portfiles that
I have created to support installing and running a map tile server for
OpenStreetMaps [1].

[1]: https://switch2osm.org/serving-tiles/

The logical Portfiles:

- libprotozero - library required by libosmium

https://github.com/mapbox/protozero

- libosmium - library required by osmium-tool

https://github.com/osmcode/libosmium

- osmium-tool - application required at runtime by mod_tile/renderd

https://github.com/osmcode/osmium-tool

- osmosis - Java application required at runtime by mod_tile/renderd

https://github.com/openstreetmap/osmosis

- openstreetmap-carto - style sheets used by mod_tile/renderd

https://github.com/gravitystorm/openstreetmap-carto

- mod_tile/renderd - the OpenStreetMaps tile server

https://wiki.openstreetmap.org/wiki/Mod_tile

1.  Should I submit each Portfile in dependency order and await its
acceptance before submitting the next in sequence, or submit them
in dependency related batches in a single pull request?

2.  The primary port is 'mod_tile' which contains an Apache module for
serving the tiles and a 'renderd' daemon that renders and creates
tile images based on requests from 'mod_tile'.  Both artefacts are
created in a single build.

I have currently named the port 'renderd', but the project is
commonly known as 'mod_tile'.  Naming the port 'renderd' was the
only way I could succeed in the 'renderd' startup item being loaded
via the 'sudo port load ${subport}' command.

Is there a better way of naming and creating this port, perhaps as
subports?

3.  Getting the tile server up and running requires quite a number of
steps.  I have created a shell script to largely automate the
process.  At runtime it uses scripts from both 'openstreetmap-carto'
and 'mod_tile/renderd', so doesn't immediately sit comfortably being
installed with either of them.

Is it best to create a simple separate standalone port (without an
upstream project), containing just the shell script, naming it
something like 'osm-tile-server' and depending on the other two
ports; or simply include it in one of the other ports with runtime
checks for the existence of required executables with helpful error
messages when they're absent?

Many thanks,

Frank

Re: Portfile license attribute with CC0-1.0 license

[Frank Dean]

Ryan Schmidt  writes:

> On Aug 23, 2021, at 11:39, Frank Dean wrote:
>> 
>> 
>> I am creating a Portfile for a project that uses the Creative Commons
>> CC0 licence [1].  I have specified the licence in the Portfile as:
>> 
>>license CC0-1.0
>> 
>> [1]: https://creativecommons.org/publicdomain/zero/1.0/
>> 
>> Note that the first character after CC is a zero.
>> 
>> When I run `port lint`, I get the following error:
>> 
>>Error: invalid license 'CC0-1.0': missing hyphen before version
>>--->  1 errors and 0 warnings found.
>> 
>> The validation logic in `portlint.tcl` is to split the string on the
>> hyphen and treat it as invalid, if the last character of the first part
>> is a digit.
>> 
>> Should I represent the CC0 licence in another way, ignore the error, or
>> is a fix needed to `portlint.tcl`?
>
> This is a portfile development question so the macports-dev mailing list 
> would be a better place to ask.
>
> MacPorts license checking code (port_binary_distributable.tcl) does not 
> recognize the license name "CC0" but the license is a formalization of public 
> domain, so just write "license public-domain". You can add a comment line 
> above that mentioning that it's really CC0, like some other ports 
> (mypaint-brushes, libb2) already do.
>
> Some day we may overhaul our license handling to use SPDX identifiers but we 
> don't use them as of this time.

Many thanks.  I'll use macports-dev next time.

Portfile license attribute with CC0-1.0 license

[Frank Dean]

I am creating a Portfile for a project that uses the Creative Commons
CC0 licence [1].  I have specified the licence in the Portfile as:

license CC0-1.0

[1]: https://creativecommons.org/publicdomain/zero/1.0/

Note that the first character after CC is a zero.

When I run `port lint`, I get the following error:

Error: invalid license 'CC0-1.0': missing hyphen before version
--->  1 errors and 0 warnings found.

The validation logic in `portlint.tcl` is to split the string on the
hyphen and treat it as invalid, if the last character of the first part
is a digit.

Should I represent the CC0 licence in another way, ignore the error, or
is a fix needed to `portlint.tcl`?

Many thanks,

Frank

Bug#576416: gip: Does not reliably display calculated results

[Frank Dean]

Package: gip
Version: 1.6.1.1-1.1.1
Severity: normal
Tags: patch


On some installations/instances, Gip fails to display any results.
E.g. on the 'IPv4 Address Analyzer' page all the output values, such
as address range, are blank.

Looks like the lock_events variable is not initialised at startup.


diff -Nur a/src/gui_ipv4_analyzer.cc b/src/gui_ipv4_analyzer.cc
--- a/src/gui_ipv4_analyzer.cc  2005-09-13 19:20:32.0 +0100
+++ b/src/gui_ipv4_analyzer.cc  2010-04-04 11:52:46.0 +0100
@@ -28,7 +28,7 @@
 /**
  * Constructor/Destructor
  
**/
-GUIIPv4Analyzer::GUIIPv4Analyzer()
+GUIIPv4Analyzer::GUIIPv4Analyzer() : lock_events(FALSE)
 {
 #ifdef _DEBUG_
   printf(GUIIPv4Analyzer::GUIIPv4Analyzer(): Called.\n);
diff -Nur a/src/gui_ipv4_subnet_calculator.cc 
b/src/gui_ipv4_subnet_calculator.cc
--- a/src/gui_ipv4_subnet_calculator.cc 2005-09-13 19:20:32.0 +0100
+++ b/src/gui_ipv4_subnet_calculator.cc 2010-04-04 12:02:51.0 +0100
@@ -30,7 +30,8 @@
  
**/
 GUIIPv4SubnetCalculator::GUIIPv4SubnetCalculator()
 : label_range(_(Address range:)),
-  label_dash(-)
+  label_dash(-),
+  lock_events(FALSE)
 {
   resize(2, 4);
   set_border_width(6);
diff -Nur a/src/gui_ipv4_subnet_splitter.cc b/src/gui_ipv4_subnet_splitter.cc
--- a/src/gui_ipv4_subnet_splitter.cc   2005-09-13 19:20:32.0 +0100
+++ b/src/gui_ipv4_subnet_splitter.cc   2010-04-04 12:03:17.0 +0100
@@ -32,7 +32,8 @@
 : label_range(_(Address range:), 0, 0.5),
   label_dash(-),
   label_pfxlen(_(Subnetted using prefixlength:), 0, 0.5),
-  label_maxmatch(_(Showing a maximum of 1000 subnets.), 1, 0.5)
+  label_maxmatch(_(Showing a maximum of 1000 subnets.), 1, 0.5),
+  lock_events(FALSE)
 {
   resize(4, 4);
   set_border_width(6);


-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.29-bpo.2-686-bigmem (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gip depends on:
ii  libatk1.0-0 1.22.0-1 The ATK accessibility toolkit
ii  libc6   2.7-18lenny2 GNU C Library: Shared libraries
ii  libcairo2   1.6.4-7  The Cairo 2D vector graphics libra
ii  libcairomm-1.0-11.6.0-1  C++ wrappers for Cairo (shared lib
ii  libgcc1 1:4.3.2-1.1  GCC support library
ii  libglib2.0-02.22.2-2~bpo50+1 The GLib library of C routines
ii  libglibmm-2.4-1c2a  2.16.4-1 C++ wrapper for the GLib toolkit (
ii  libgtk2.0-0 2.12.12-1~lenny1 The GTK+ graphical user interface 
ii  libgtkmm-2.4-1c2a   1:2.12.7-1   C++ wrappers for GTK+ 2.4 (shared 
ii  libpango1.0-0   1.20.5-5+lenny1  Layout and rendering of internatio
ii  libsigc++-2.0-0c2a  2.0.18-2 type-safe Signal Framework for C++
ii  libstdc++6  4.3.2-1.1The GNU Standard C++ Library v3

gip recommends no packages.

gip 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