Re: [ITA] Perl distributions (in preparation of Perl 5.22)

2015-07-02 Thread Achim Gratz
Marco Atzeri writes:
>> I will prepare
>>   perl-Graphics-Magick
>>   perl-Image-Magick
>> by end of the week.
>
> uploading now

Thank you.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


Re: [ITA] Perl distributions (in preparation of Perl 5.22)

2015-07-02 Thread Marco Atzeri

On 6/22/2015 11:46 PM, Marco Atzeri wrote:

On 6/22/2015 6:59 PM, Achim Gratz wrote:




I would appreciate if you could indicate whether the builds are
finished.  In particular I didn't hear anything from Volker yet.


Regards,
Achim.



I will prepare
  perl-Graphics-Magick
  perl-Image-Magick
by end of the week.


uploading now

Marco


Re: setup

2015-07-02 Thread Achim Gratz
Corinna Vinschen writes:
> (*) This puzzles me a bit.  You're keeping arrays and lists in terms of
> the file suffix (setup_ext, setup_ext_list), but you don't use the
> information here and elsewhere.

THat vector is a relatively late addition to the code when the rest was
already using literals as before.  It's something that I want to clean
up, but not necessarily right now.  As you noted, I'd probably need to
use a more structured data type.

> I'd prefer /* */ for multiline comments, but that's used pretty
> inconsistently anyway, so, never mind.

If you insist… but setup is C++ and not C anyway.

> The existing code is inconsistently formatted, but for new code it would
> be nice if we could try to be more consistent.  Always prepend a space
> to a left parenthesis, please.

I'll check that.

> Sorry if that's a lot.  It just occured to me while reading your code.
> I'm not adamant about the structural change I outlined above, but to
> me it seems better to do it that way.  What do you think?

It will just have to wait a bit, I think.  But yes, these are all good
suggestions.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


Moving desktop environment packages out of the X11 category

2015-07-02 Thread Michael DePaulo
Hi everyone,

We recently added new package categories for desktop environments
https://cygwin.com/ml/cygwin-apps/2015-05/msg00013.html

However, some desktop-environment-specific packages remain under the
X11 category. For example:
gnome-backgrounds
gnome-menus
metacity

Note that I think that toolkits should remain under X11. (Although one
could argue that GTK3 should be under GNOME.) I also think that window
managers that are not associated with a desktop environment should
remain X11.

Ideally, I would like to be able to install the entire X11 category
without numerous desktop environment packages (like libgtop2.0_10)
being pulled in due to dependencies.

-Mike


Re: setup

2015-07-02 Thread Corinna Vinschen
Hi Achim,

On Jul  1 22:37, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Ok, for once.  But please make sure that you split the commit into
> > functional chunks next time it's so large.  And send it to this list, so
> > code snippets can be referenced in the review.
> 
> I've split it up into three parts that at least compile cleanly.

Thanks!

> +extern IniList found_ini_list, setup_ext_list;
> +const std::string setup_exts[] = { "xz", "bz2", "ini" };

See (*) below.

> @@ -97,6 +99,8 @@ static BoolOption PackageManagerOption (false, 'M', 
> "package-manager", "Semi-att
>  static BoolOption NoAdminOption (false, 'B', "no-admin", "Do not check for 
> and enforce running as Administrator");
>  static BoolOption WaitOption (false, 'W', "wait", "When elevating, wait for 
> elevated child process");
>  static BoolOption HelpOption (false, 'h', "help", "print help");
> +static StringOption SetupBaseNameOpt ("setup", 'i', "ini-basename", "Use a 
> different basename instead of setup", false);

The word setup needs quoting of some sort I think.  An example wouldn't
hurt either.  What about

  "Use a different ini file basename instead of \"setup\", e.g. \"foo\".ini"

?

> + (theFile->nFileSizeLow || theFile->nFileSizeHigh))
> +  {
> + if (!casecompare (SetupBaseName + ".xz",  theFile->cFileName))
> +   found_xz  = true;
> + if (!casecompare (SetupBaseName + ".bz2", theFile->cFileName))
> +   found_bz2 = true;
> + if (!casecompare (SetupBaseName + ".ini", theFile->cFileName))
> +   found_ini = true;
> +  }

(*) This puzzles me a bit.  You're keeping arrays and lists in terms of
the file suffix (setup_ext, setup_ext_list), but you don't use the
information here and elsewhere.  The setup_exts array already contains
the suffixes and constitutes an order.  If you extend the array of
strings to a struct, you could just run a loop over it in places like
the above and generalize the suffix handling.  For instance...

  struct ini_suffix_t
  {
char *suffix;
bool needs_decompressing;
[...]
  } 

  ini_suffix_t ini_suffixes[] = {
{ "xz", true },
{ "bz2", true },
{ "ini", false },
{ NULL, false } };

  bool found_ini[];  // <- just as example

  for (i = 0; ini_suffixes[i].suffix; ++i)
if (!casecompare (SetupBaseName + "." + ini_suffixes[i].suffix, ...)
  found_ini[i] = true;

This would work OOTB, without C++11x initializer lists, and you could
drop setup_ext_list entirely.

This would also simplify things if there's a new compression we want to
support.

> +if (found_xz)
> +  found_ini_list.push_back(basePath + "/" + aDir->cFileName + "/" + 
> SetupBaseName + ".xz");
> +else if (found_bz2)
> +  found_ini_list.push_back(basePath + "/" + aDir->cFileName + "/" + 
> SetupBaseName + ".bz2");
> +else if (found_ini)
> +  found_ini_list.push_back(basePath + "/" + aDir->cFileName + "/" + 
> SetupBaseName + ".ini");

Same kind of loop here.

  for (i = 0; ini_suffixes[i].suffix; ++i)
if (found_ini[i])
  found_ini_list.push_back (... + ini_suffixes[i].suffix);

Ideally found_ini_list keeps a pointer into ini_suffixes as well so
you don't have to extract the suffix again at (**).

> Subject: [PATCH 3/5] Refactor setup search and implement XZ compressed setup
>  files
> 
>   * ini.cc: Construct setup_ext_list from array until we can use
>   C++11 aggregate initializers.
>   (decompress_ini): Refactored for use from do_local_ini and
>   do_remote_ini.  Change outdated comment about setup.ini
>   uncompressed size.
>   (check_ini_sig): Factor out signature check.
>   (fetch_remote_ini): Refactored for use from do_remote_ini.
>   (do_local_ini): Iterate over search results in found_ini_list.
>   Use ini_decompress and check_ini_sig.
^^
missing name change

> +  // Unless the NoVerifyOption is set, check the signature for the
> +  // current setup and record the result.  On a failed signature check
> +  // the streams are invalidated so even if we tried to read in the
> +  // setup anyway there's be nothing to parse.

I'd prefer /* */ for multiline comments, but that's used pretty
inconsistently anyway, so, never mind.

> +  IniDBBuilderPackage aBuilder(myFeedback);
> +  io_stream *ini_file, *ini_sig_file;
> +  // iterate over all setup files found in do_from_local_dir
> +  for (IniList::const_iterator n = found_ini_list.begin();
> +   n != found_ini_list.end(); ++n)
> +{
> +  bool sig_fail = false;
> +  std::string current_ini_ext, current_ini_name, current_ini_sig_name;
> +
> +  current_ini_name = *n;
> +  current_ini_sig_name = current_ini_name + ".sig";
> +  current_ini_ext = current_ini_name.substr(current_ini_name.rfind(".") 
> + 1);

(**) See above.

> +  ini_sig_file = io_stream::open("file://" + current_ini_sig_name, "rb", 
> 0);
> +  ini_file = io_stream::open("file://" + current_ini_name, "rb", 0);
> +  ini_fil