bugGNU Octave - Bugs: bug #60472, pkg -global option changes pkg...

 
 

bug #60472: pkg -global option changes pkg prefix for subsequent calls

Submitter:  Nicholas Jankowski <nrjank>
Submitted:  Thu 29 Apr 2021 03:54:43 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Nicholas Jankowski Open/Closed:  * Closed
Release:  * 6.2.0 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 05 May 2021 05:17:21 PM UTC, comment #18: 

I believe this is working as expected now.
Closing report.

Markus Mützel <mmuetzel>
Group administrator
Fri 30 Apr 2021 06:07:34 PM UTC, comment #17: 

@mtmiller, yes, I agree with your understanding. with markus's patch i think it now follows that intent, where global and local behave properly unless a manual prefix change occurs, at which point it takes over for the session.

Nicholas Jankowski <nrjank>
Group Member
Fri 30 Apr 2021 05:24:56 PM UTC, comment #16: 

Thanks for testing.

I pushed the patch to stable here:
https://hg.savannah.gnu.org/hgweb/octave/rev/3a9000d18596

Markus Mützel <mmuetzel>
Group administrator
Fri 30 Apr 2021 05:15:08 PM UTC, comment #15: 

I don't know if this helps, but for what it's worth, the way I understood "pkg prefix" is that if a user sets a custom prefix, the intention is that whatever "prefix" is will be used for all packages from now on, "global" and "local" are no longer relevant, they might as well not exist for the remainder of this Octave session. If a user wants to use the default "global" and "local", those two work together fairly well I think, but the user should not set "prefix" at all in that case.

That may not be what we want for a new "pkg" behavior, but that's the way I have understood what we have now.

Mike Miller <mtmiller>
Group Member
Fri 30 Apr 2021 04:18:48 PM UTC, comment #14: 

ok, applying the patch the the latest version of 6.2.1 stable:

before patch, prefix starts local as it should, -global call makes persistent change to subsequent calls to global package location:

>> pkg prefix
Installation prefix:             C:\Users\NICHOL~1.JAN\octave
Architecture dependent prefix:   C:\Users\NICHOL~1.JAN\octave
>> pkg install -global abc
error: pkg: file not found: abc.
This looks like an Octave Forge package name.  Did you mean:
       pkg install -forge abc
error: called from
    pkg at line 554 column 19
>> pkg prefix
Installation prefix:             C:\Programs\Octave\OCTAVE~2\mingw64\share\octave\packages
Architecture dependent prefix:   C:\Programs\Octave\OCTAVE~2\mingw64\lib\octave\packages


after applying the patch:


>> pkg prefix
Installation prefix:             C:\Users\NICHOL~1.JAN\octave
Architecture dependent prefix:   C:\Users\NICHOL~1.JAN\octave
>> pkg install -global abc
error: pkg: file not found: abc.
This looks like an Octave Forge package name.  Did you mean:
       pkg install -forge abc
error: called from
    pkg at line 554 column 19
>> pkg prefix
Installation prefix:             C:\Users\NICHOL~1.JAN\octave
Architecture dependent prefix:   C:\Users\NICHOL~1.JAN\octave


so prefix now reverts to the proper context on the next call to pkg. This appears to fix at least part of the problem. running a single -global install/uninstall will not change the default local/global behavior, and subsequent packages will go to their default location.


>> pkg list ga
package ga is not installed.

>> pkg install -global -forge ga
For information about changes from previous versions of the ga package, run 'news ga'.

>> pkg list ga
Package Name  | Version | Installation directory
--------------+---------+-----------------------
          ga  |  0.10.2 | ...\Octave\octave-stable\mingw64\share\octave\packages\ga-0.10.2

>> pkg list arduino
package arduino is not installed.

>> pkg install -forge arduino
For information about changes from previous versions of the arduino package, run 'news arduino'.

>> pkg list arduino ga
Package Name  | Version | Installation directory
--------------+---------+-----------------------
     arduino  |   0.7.0 | C:\Users\nicholas.jankowski\octave\arduino-0.7.0
          ga  |  0.10.2 | ...\Octave\octave-stable\mingw64\share\octave\packages\ga-0.10.2


this should solve the main issue that kicked off this bug report trying to manage locally and globally installed packages. pkg update should behave better as well since it doesn't currently take -local/-global options.


checking the behavior of prefix, it appears a manual setting does take priority over any following -local or -global statements.


>> pkg prefix
Installation prefix:             C:\Users\NICHOL~1.JAN\octave
Architecture dependent prefix:   C:\Users\NICHOL~1.JAN\octave

>> pkg list arduino
package arduino is not installed.

>> pkg list ga
package ga is not installed.

>> pkg prefix C:\Programs\Octave\testpackages C:\Programs\Octave\testpackages
ans = C:\Programs\Octave\testpackages

>> pkg prefix
Installation prefix:             C:\Programs\Octave\testpackages
Architecture dependent prefix:   C:\Programs\Octave\testpackages

>> pkg install -global -forge arduino
For information about changes from previous versions of the arduino package, run 'news arduin
o'.

>> pkg list arduino
Package Name  | Version | Installation directory
--------------+---------+-----------------------
     arduino  |   0.7.0 | C:\Programs\Octave\testpackages\arduino-0.7.0

>> pkg install -local -forge ga
For information about changes from previous versions of the ga package, run 'news ga'.

>> pkg list ga
Package Name  | Version | Installation directory
--------------+---------+-----------------------
          ga  |  0.10.2 | C:\Programs\Octave\testpackages\ga-0.10.2

>> load(pkg('local_list'))
>> local_packages
local_packages =
{
  [1,1] =

    scalar structure containing the fields:

      name = ga
      version = 0.10.2
      date = 2020-12-02
      author = Luca Favatella <slackydeb@gmail.com>
      maintainer = Octave-Forge community <maintainers@octave.org>
      title = Genetic Algorithm
      description = Genetic optimization code
      categories = Optimization
      depends =
      {
        [1,1] =

          scalar structure containing the fields:

            package = octave
            operator = >=
            version = 3.4.0

      }

      autoload = yes
      license = GPL version 3 or later
      url = http://octave.sf.net
      dir = C:\Programs\Octave\testpackages\ga-0.10.2
      archprefix = C:\Programs\Octave\testpackages\ga-0.10.2

}

>> load(pkg('global_list'))
>> global_packages(end)
ans =
{
  [1,1] =

    scalar structure containing the fields:

      name = arduino
      version = 0.7.0
      date = 2021-04-28
      author = John Donoghue <john.donoghue@ieee.org>
      maintainer = John Donoghue <john.donoghue@ieee.org>
      title = Octave Arduino Toolkit
      description = Basic Octave implementation of the matlab arduino extension,  allowing co
mmunication to a programmed arduino board to control its  hardware.
      categories = Arduino Toolkit
      depends =
      {
        [1,1] =

          scalar structure containing the fields:

            package = octave
            operator = >=
            version = 4.0.0

        [1,2] =

          scalar structure containing the fields:

            package = instrument-control
            operator = >=
            version = 0.3.0

      }

      systemrequirements = arduino-ide (>= 1.5)
      license = GPLv3+
      url = https://octave.sourceforge.io/arduino/
      dir = C:\Programs\Octave\testpackages\arduino-0.7.0
      archprefix = C:\Programs\Octave\testpackages\arduino-0.7.0

}


So, after a prefix change, -local and -global flags will not change the install location, but they will populate the appropriate local and global package lists. I think this behavior makes sense and is consistent with intent unless someone knows otherwise.

It would be nice if there was a 'pkg prefix -default' option to force a reset back to default paths and set user_prefix back to false without the need to close/restart octave.  but maybe the wishlist is stretching a bit long for, as Kai said, what is already a bit of an overburdened tool.

TL;DR:  absent any other issues, Markus's patch seems to fix the primary issue that prompted this bug report. As the rmdir bug was fixed elsewhere, I would consider it complete.

Nicholas Jankowski <nrjank>
Group Member
Fri 30 Apr 2021 02:56:17 PM UTC, comment #13: 

as noted on bug #60473, patch pushed there to stable branch has corrected the rmdir crash. can no longer create the crash from comment #2.

Nicholas Jankowski <nrjank>
Group Member
Fri 30 Apr 2021 02:37:17 PM UTC, comment #12: 

will manually apply the change to 6.2.1 and see how the behavior changes. 

it appears that this should work.  the only way of flipping user_prefix to true is with an explicit call to prefix to change location.  otherwise all other calls to pkg will revert to default prefixes prior to doing anything else.

Nicholas Jankowski <nrjank>
Group Member
Fri 30 Apr 2021 01:04:09 PM UTC, comment #11: 

I haven't run any tests yet. But does the attached patch improve the behavior?

(file #51343)

Markus Mützel <mmuetzel>
Group administrator
Fri 30 Apr 2021 12:21:40 PM UTC, comment #10: 

@siko1056, thanks, I think I had picked up on most of that.

I guess if anything is to be considered a bug for fixing prior to a v7 (assuming there's a bugfix release at some point), it's the fact that a -global or -local command creates a persistent prefix change. It seems like the change should just be specific to that single function call. But, with the way it processes -global/-local options first and then processes commands, there's no code block at the end to revert back to the 'normal' state, and I'm not sure if it would be feasible (or worthwhile) to just stick that on the end.

Nicholas Jankowski <nrjank>
Group Member
Fri 30 Apr 2021 07:01:22 AM UTC, comment #9: 

@nrjank: I recently also came across "pkg prefix".  The documented behavior will be preserved (for backward compatibility) in the version I am working on, but not every "accidental" undocumented side effect will be preserved.  Hopefully, the comprehension by the average user will be improved a lot =)

To put a little light into the current pkg magic.  You are dealing with two concepts:


pkg prefix
pkg local_list / global_list


which in theory are decoupled, but practically they share the very same persistent variables 😵 🤯

The "pkg prefix" defines where things get installed to.  "prefix" is the directory for all package files, "archprefix" defines where compiled ARCHitecture depended stuff ("*.oct" files) go to.  Both can point to the same directory.

Next you have to distinguish between three categories of (arch)prefixes:

1. global
2. local
3. user defined

The latter one comes out only very implicitly and it not really documented. https://octave.org/doc/v6.2.0/XREFpkg.html  But once the prefix was changed by the user is takes absolute precedence until Octave is restarted (thus "pkg install -local" and "pkg install -global" are not working as expected anymore and should be called "pkg install -userDefined" for clarity).  Similar with calling "pkg -global" or "pkg -local" as you observed.  I assume this is an unforeseen side-effect, due to mixing of two concepts sharing the same persistent variables and this will be not part of my pkg version.  "pkg install" becomes an independent command (function), controlled by "pkg config".

On the other hand "pkg local_list / global_list" define the locations of "index files" for globally and locally installed packages, respectively.  If those files are changed, "pkg" "forgets" previous package installations.

Another severe point is, that "pkg list" merges both indices "pkg local_list / global_list" in a crude way taking precedence for local ("pkg local_list") packages.

Thus if you had a global and local "tsa" installation, you the local ("pkg local_list") "tsa" shadows the global ("pkg global_list") one.


Off-topic note:
pkg has grown into an "unnecessary complicated structured" tool.  Some side effects by sub-commands are hard to oversee and my current refactoring actions focus on decoupling of responsibilities into separate functions.  All controlled by a single configuration "pkg config" without any side effects or actions that can only be reverted easily by an Octave restart.

Still it is work in progress below alpha-status.  I hope to close a bunch of pkg bugs this summer =)

Kai Torben Ohlhus <siko1056>
Group Member
Thu 29 Apr 2021 05:26:36 PM UTC, comment #8: 

@siko1056, does your pkg revision project maintain this prefix behavior ?

Nicholas Jankowski <nrjank>
Group Member
Thu 29 Apr 2021 03:58:43 PM UTC, comment #7: 

jumped back to older versions of pkg, and the persistent prefix change behavior appears to be persistent as far back as v4.4.1 (checked 5.1.0 as well).  the rmdir crash seems new, though.

(following is the same in v4.4.1 ad 5.1.0)

>> rmdir("")
ans = 0

>> pkg prefix
Installation prefix:             C:\Programs\Octave\OCTAVE~1.1-W\share\octave\packages
Architecture dependent prefix:   C:\Programs\Octave\OCTAVE~1.1-W\lib\octave\packages

>> pkg install -local abc
error: pkg: failed to read package 'abc': Couldn't resolve host name
error: called from
    pkg at line 429 column 17

>> pkg prefix
Installation prefix:             C:\Users\NICHOL~1.JAN\octave
Architecture dependent prefix:   C:\Users\NICHOL~1.JAN\octave

>> pkg list tsa
Package Name  | Version | Installation directory
--------------+---------+-----------------------
         tsa  |   4.4.5 | ...\Octave\OCTAVE~2.0-W\mingw64\share\octave\packages\tsa-4.4.5

>> pkg uninstall tsa

>> pkg install -forge tsa
For information about changes from previous versions of the tsa package, run 'news tsa'.

>> pkg list tsa
Package Name  | Version | Installation directory
--------------+---------+-----------------------
         tsa  |   4.6.2 | C:\Users\NICHOL~1.JAN\octave\tsa-4.6.2


running a pkg rebuild without changing the prefix back, pkg list only shows tsa, and only that package will load, even though 'pkg local_list' and global_list point to the right files and they are properly populated, but there is no local .octave_packages file. forcing -global again, and a pkg rebuild, shows all but tsa and still refuses to build a local .octave_packages.

at this point, I'm not sure what's going on.  right now the general rule of thumb for this windows setup is: never call install/uninstall without manually specifying -local -global.  never call update. 

Nicholas Jankowski <nrjank>
Group Member
Thu 29 Apr 2021 02:41:36 PM UTC, comment #6: 

rmdir - that would maybe work in the short term.  I do see that @jwe already pushed a possible rmdir fix to stable on that bug report.  So I can give that a try on windows after the next 6.2.1 buildbot cycle.

Took me a while to sort out what 'prefix' meant too and how that worked into things. I'm still not sure what archprefix is.

my understanding of 'prefix' is just from the help:


          pkg prefix ~/my_octave_packages

          sets the installation prefix to '~/my_octave_packages'.
          Packages will be installed in this directory.

          It is possible to get the current installation prefix by
          requesting an output argument.  For example:

               pfx = pkg ("prefix")


e.g., whatever the prefix is, that's "where things will be installed now unless you tell pkg otherwise".  looking at default_prefix, it sets local to be in the users profile folder (~ on nix systems,  C:\users\*username on windows) and global to be inside the Octave installation.

it appears that that -global and -local switches essentially just make a prefix switch.  I "think" these changes are meant to be temporary, and they aren't.  I never paid attention to this before, since on windows before v6 everything defaulted to global. I may install v5 or v4 copy of octave and compare the pkg behavior to see if this is new.

Nicholas Jankowski <nrjank>
Group Member
Thu 29 Apr 2021 02:07:46 PM UTC, comment #5: 

Where you write "prefix" you actually refer to the difference between local and global packages, right?
FTR, "prefix" is also meant for the storage location of local packages. It's confusing, agreed.

It would be good if the (or a?) desired behavior of pkg.m gets sorted out well and compared to its actual behavior. But then again both may differ depending on platform, on where/how Octave got installed and maybe on who is doing some operation (admin/root or ordinary user).
In some way there seem to be just too many options and scenario's.

As to rmdir:
Would it help to temporarily wrap calls to rmdir into an if block that checks if rmdir's input argument is empty? Then you don't have to rebuild Octave.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 29 Apr 2021 05:16:01 AM UTC, comment #4: 

ok. just verified that octave 6.2.0 and 6.2.1 gui will crash to desktop on a:

rmdir("")

filed separate bug report, bug #60473

this does make troubleshooting this pkg bug rather tedious.

Nicholas Jankowski <nrjank>
Group Member
Thu 29 Apr 2021 04:58:14 AM UTC, comment #3: 

stepping through uninstall.m to where it crashes, it gets to the line 107 block to delete the directories.

the results of 'desc = installed-pkgs_lst(i)' for the single ga package is:


debug> desc
desc =

  scalar structure containing the fields:

    name = ga
    version = 0.10.2
    date = 2020-12-02
    author = Luca Favatella <slackydeb@gmail.com>
    maintainer = Octave-Forge community <maintainers@octave.org>
    title = Genetic Algorithm
    description = Genetic optimization code
    categories = Optimization
    depends =
    {
      [1,1] =

        scalar structure containing the fields:

          package = octave
          operator = >=
          version = 3.4.0

    }

    autoload = yes
    license = GPL version 3 or later
    url = http://octave.sf.net
    dir = C:\Programs\Octave\octave-dev\mingw64\share\octave\packages\ga-0.10.2
    archprefix =
    loaded = 0


it steps through the line 125 rmdir(desc.dir, "s") without problem. same with the line 129 rmdir(getarchdir(desc),"s").  for reference:


debug> getarchdir(desc)
ans = x86_64-w64-mingw32-api-v55


then it gets to

        if (dirempty (desc.archprefix))
          rmdir (desc.archprefix, "s");
        endif


the if statement is true,  so it runs the rmdir line, and rmdir apparently crashes to desktop when passed an empty string.

so... is this related to the prefix thing? should rmdir not be crashing when passed an empty string? is it an odd combination of the two?


Nicholas Jankowski <nrjank>
Group Member
Thu 29 Apr 2021 04:34:43 AM UTC, comment #2: 

to recreate gui crash to desktop, from a fresh install:


>> pkg uninstall -global ga

>> pkg list ga
package ga is not installed.

>> pkg prefix
Installation prefix:             C:\Programs\Octave\OCTAVE~1\mingw64\share\octave\packages
Architecture dependent prefix:   C:\Programs\Octave\OCTAVE~1\mingw64\lib\octave\packages

>> pkg install ga-0.10.2.tar.gz
For information about changes from previous versions of the ga package, run 'news ga'.

>> pkg uninstall ga

***crash to desktop***


happens every time repeating those steps. will try to step through uninstall and get state of things at the rmdir call.

Nicholas Jankowski <nrjank>
Group Member
Thu 29 Apr 2021 03:59:46 AM UTC, comment #1: 

I was doing all of that on the CLI.  running it in the gui, apparently some combinations of uninstall with the issues mentioned cause the gui to hard crash to desktop.  stepping thruogh pkg, it occurs on the rmdir line near the end. the rmdir occurs, but it crashes before updating .octave_packages, so on restart it still appears in a list even with a pkg rebuild, but needs a second pkg uninstall to declare "directory is previously lost" and remove it from pkg list.

will try to tease this out further, and see if it needs its own bug report.

Nicholas Jankowski <nrjank>
Group Member
Thu 29 Apr 2021 03:54:43 AM UTC, original submission:  

Octave on Windows 10.  Tested with the 6.2.0 release and the 6.2.1 build hg id: 50aa945836c3 Mon, Apr 26, 2021, using the zip installer into userspace (C:\Octave\octave-*version*).  User has write access to both global and local package location.

Default install has packages in global location.  User does not have administrative rights, but does have write access to global package location. Attempting uninstall without -global flag refuses to do so as expected, and forcing -global flag does the uninstall:


octave:1> pkg local_list, pkg global_list, __is_elevated_process__
C:\Users\NICHOL~1.JAN\.octave_packages
C:\Programs\Octave\OCTAVE~1\mingw64\share\octave\octave_packages
ans = 0

octave:2> pkg prefix
Installation prefix:             C:\Users\NICHOL~1.JAN\octave
Architecture dependent prefix:   C:\Users\NICHOL~1.JAN\octave

octave:3> pkg list ga
Package Name  | Version | Installation directory
--------------+---------+-----------------------
          ga  |  0.10.2 | ...\octave-dev\mingw64\share\octave\packages\ga-0.10.2

octave:4> pkg uninstall ga
warning: some of the packages you want to uninstall are not installed
warning: called from
    uninstall at line 72 column 7
    pkg at line 582 column 7

warning: no packages will be uninstalled
warning: called from
    uninstall at line 77 column 5
    pkg at line 582 column 7

octave:5> pkg uninstall -global ga
octave:6> pkg list ga
package ga is not installed.


but after that -global, the prefix remains changed:


octave:7> pkg prefix
Installation prefix:             C:\Programs\Octave\OCTAVE~1\mingw64\share\octave\packages
Architecture dependent prefix:   C:\Programs\Octave\OCTAVE~1\mingw64\lib\octave\packages

octave:8> __is_elevated_process__
ans = 0

octave:11> pkg install ga-0.10.2.tar.gz
For information about changes from previous versions of the ga package, run 'news ga'.

octave:12> pkg list ga
Package Name  | Version | Installation directory
--------------+---------+-----------------------
          ga  |  0.10.2 | ...\octave-dev\mingw64\share\octave\packages\ga-0.10.2

octave:14> pkg uninstall ga

octave:15> pkg list ga
package ga is not installed.


so it essentially did an install to the global location without me asking and lets me uninstall as well when that should require a -global option.

Trying to do a global and local install with different versions, things are weird:


octave:17> pkg install ga-0.10.1.tar.gz
For information about changes from previous versions of the ga package, run 'news ga'.

octave:18> pkg list ga
Package Name  | Version | Installation directory
--------------+---------+-----------------------
          ga  |  0.10.1 | ...\octave-dev\mingw64\share\octave\packages\ga-0.10.1

octave:19> pkg prefix
Installation prefix:             C:\Programs\Octave\OCTAVE~1\mingw64\share\octave\packages
Architecture dependent prefix:   C:\Programs\Octave\OCTAVE~1\mingw64\lib\octave\packages

octave:20> pkg install -local ga-0.10.2.tar.gz
For information about changes from previous versions of the ga package, run 'news ga'.

octave:21> pkg list ga
Package Name  | Version | Installation directory
--------------+---------+-----------------------
          ga  |  0.10.2 | C:\Users\nicholas.jankowski\octave\ga-0.10.2

octave:22> pkg prefix
Installation prefix:             C:\Users\NICHOL~1.JAN\octave
Architecture dependent prefix:   C:\Users\NICHOL~1.JAN\octave

octave:23> pkg uninstall ga

octave:24> pkg list ga
package ga is not installed.

octave:25> pkg rebuild

octave:26> pkg list ga
package ga is not installed.


just trying to global uninstall, even if unsuccessful, changes the prefix

octave:27> pkg uninstall -global ga
warning: some of the packages you want to uninstall are not installed
warning: called from
    uninstall at line 68 column 9
    pkg at line 582 column 7

warning: no packages will be uninstalled
warning: called from
    uninstall at line 77 column 5
    pkg at line 582 column 7

octave:28> pkg prefix
Installation prefix:             C:\Programs\Octave\OCTAVE~1\mingw64\share\octave\packages
Architecture dependent prefix:   C:\Programs\Octave\OCTAVE~1\mingw64\lib\octave\packages


repeating above, verifying the pkg installation occurs (global location prefix still set):


octave:29> pkg install ga-0.10.1.tar.gz
For information about changes from previous versions of the ga package, run 'news ga'.
octave:30> pkg list ga
Package Name  | Version | Installation directory
--------------+---------+-----------------------
          ga  |  0.10.1 | ...\octave-dev\mingw64\share\octave\packages\ga-0.10.1


verify ga folder present where stated above


octave:31> pkg install -local ga-0.10.2.tar.gz
For information about changes from previous versions of the ga package, run 'news ga'.

octave:32> pkg list ga
Package Name  | Version | Installation directory
--------------+---------+-----------------------
          ga  |  0.10.2 | C:\Users\nicholas.jankowski\octave\ga-0.10.2


verified local pkg is installed as stated, BUT ga-0.10.1 has been deleted from global location, as would occur when updating in the same location. hence after the local uninstall, neither is left.

so, it seems the prefix is being updated and acts as a persistent switch rather than a temporary change, but my guess is it still logs the pkg in the local_list .octave_packages?

(there are enough changes to pkg on the default branch I can't check it without being set up to recompile, so I can't verify if this persists in that version, but the pkg code appears the same.)

Nicholas Jankowski <nrjank>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #51343:  bug60472_pkg_prefix.patch added by mmuetzel (732B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by nrjank
  • -email is unavailable- added by nrjank (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-05-05 mmuetzel StatusNone Fixed
        Open/ClosedOpen Closed
    2021-04-30 mmuetzel Attached File- Added bug60472_pkg_prefix.patch, #51343
        Operating SystemMicrosoft Windows Any
    2021-04-29 nrjank Carbon-Copy- Added siko1056

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code