[Pharo-dev] Sign Windows VMs

[Vincent.Blondeau]

Hi!

I am using Pharo in a company network under a firewall, an antivirus, and 
windows, and each day I have an issue with some parts of the Pharo application 
that are recognized as a threat.  So, I cannot download it or execute it 
straightforwardly.

Today was this one:

[https://cdn.discordapp.com/attachments/365850577340727296/445688856948506624/unknown.png]
Another day was the Cairo Dll where a "Veil Evasion Payload" has been detected.

And some people has encounter the same kind of issues:

  *   https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/152
  *   
https://pharo.fogbugz.com/f/cases/20500/WindowsDefender-consider-SqueakSSL-dll-as-a-virus-and-delete-it

It seems that the solution is to sign the VM with Authenticode, but for this, 
one needs to acquire a certificate (which is, of course, not free).
Has the community such a certificate? Maybe the same that for MacOS?
Would someone configure the VM builds to automatically sign them? (I can spend 
some time for this if needed)

TIA,

Cheers,
Vincent

<>

Re: [Pharo-dev] File/Stream changes: one Integer decoder/encoder to rule them all

[Nicolas Cellier]

2018-05-14 15:15 GMT+02:00 Marcus Denker :

>
>
> On 14 May 2018, at 15:09, Nicolas Cellier  gmail.com> wrote:
>
>
>
> 2018-05-14 14:44 GMT+02:00 Marcus Denker :
>
>> >
>> >
>> > For ByteArray, I didn't check recently in Pharo, but I know that it's
>> quite a mess in Squeak because some methods are in Alien, other in FFI,
>> other in base Squeak...
>> > IMO all methods should be in core Squeak/Pharo because of general usage
>> (like decoding binary data).
>> >
>> I want to move the methods from FFI to the base since years… I was told
>> that this is impossible to ever happen because it is not important to do
>> changes like that.
>>
>
> Marcus
>>
>
> Hi Marcus,
> we all know that those un-important and not-so-much-rewarding changes
> makes a big difference at the end.
> like commenting classes, classifying methods, deprecating duplicates,
> reducing package inter-dependencies, etc...
> I thought that the defenders of statu quo had two reasons in mind:
> - the will to keep a FFI-less (locked-in) image
> - the fear to loose backward compatibility
>
>
> The idea that “only big important changes” are worth doing… you know, it’s
> “inventing the future” business, not “cleaning up”!
>
> (Of course revolutionary changes while staying 100% backward compatible…
> because think about the Children!)
>
> It would be funny if it would not be sad…
>
> But's it the past, now you are free :)
>
>
> Not really, because we share that package with Squeak. If I would be free
> to change it, it would have happened a loong time ago…
>
> Marcus
>
>
OK, coordinated changes must be performed then, but it's a bit more
difficult...
It can be a two step process:
1) separate the methods to be re-integrated in core into a separate package
2) move this methods in core, or use the separate package for old images
(backward compatibility)
It has to be performed both in FFI and Alien.

[Pharo-dev] [Pharo 7.0-dev] Build #897: 21900-GTExamplesBrowser-uses-old-Compiler-API

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #897 was: FAILURE.

The Pull Request #1353 was integrated: 
"21900-GTExamplesBrowser-uses-old-Compiler-API"
Pull request url: https://github.com/pharo-project/pharo/pull/1353

Issue Url: https://pharo.fogbugz.com/f/cases/21900
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/897/

[Pharo-dev] [Pharo 7.0-dev] Build #896: 21903-GT-tools-still-uses-old-compiler-API-evaluateforlogged

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #896 was: FAILURE.

The Pull Request #1354 was integrated: 
"21903-GT-tools-still-uses-old-compiler-API-evaluateforlogged"
Pull request url: https://github.com/pharo-project/pharo/pull/1354

Issue Url: https://pharo.fogbugz.com/f/cases/21903
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/896/

[Pharo-dev] [Pharo 7.0-dev] Build #895: 21904-TextDoIt-TextPrintIt-uses-old-compiler-API

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #895 was: SUCCESS.

The Pull Request #1352 was integrated: 
"21904-TextDoIt-TextPrintIt-uses-old-compiler-API"
Pull request url: https://github.com/pharo-project/pharo/pull/1352

Issue Url: https://pharo.fogbugz.com/f/cases/21904
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/895/

Re: [Pharo-dev] File/Stream changes: one Integer decoder/encoder to rule them all

[Marcus Denker]

> On 14 May 2018, at 15:09, Nicolas Cellier 
>  wrote:
> 
> 
> 
> 2018-05-14 14:44 GMT+02:00 Marcus Denker  >:
> > 
> > 
> > For ByteArray, I didn't check recently in Pharo, but I know that it's quite 
> > a mess in Squeak because some methods are in Alien, other in FFI, other in 
> > base Squeak...
> > IMO all methods should be in core Squeak/Pharo because of general usage 
> > (like decoding binary data).
> > 
> I want to move the methods from FFI to the base since years… I was told that 
> this is impossible to ever happen because it is not important to do changes 
> like that.
>  
> Marcus
> 
> Hi Marcus,
> we all know that those un-important and not-so-much-rewarding changes makes a 
> big difference at the end.
> like commenting classes, classifying methods, deprecating duplicates, 
> reducing package inter-dependencies, etc...
> I thought that the defenders of statu quo had two reasons in mind:
> - the will to keep a FFI-less (locked-in) image
> - the fear to loose backward compatibility

The idea that “only big important changes” are worth doing… you know, it’s 
“inventing the future” business, not “cleaning up”!

(Of course revolutionary changes while staying 100% backward compatible… 
because think about the Children!)

It would be funny if it would not be sad…

> But's it the past, now you are free :)

Not really, because we share that package with Squeak. If I would be free to 
change it, it would have happened a loong time ago…

Marcus

[Pharo-dev] [Pharo 7.0-dev] Build #894: 21888 Tagging in CodeImportCommandLineHandlers

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #894 was: SUCCESS.

The Pull Request #1343 was integrated: "21888 Tagging in 
CodeImportCommandLineHandlers"
Pull request url: https://github.com/pharo-project/pharo/pull/1343

Issue Url: https://pharo.fogbugz.com/f/cases/21888
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/894/

Re: [Pharo-dev] File/Stream changes: one Integer decoder/encoder to rule them all

[Nicolas Cellier]

2018-05-14 14:44 GMT+02:00 Marcus Denker :

> >
> >
> > For ByteArray, I didn't check recently in Pharo, but I know that it's
> quite a mess in Squeak because some methods are in Alien, other in FFI,
> other in base Squeak...
> > IMO all methods should be in core Squeak/Pharo because of general usage
> (like decoding binary data).
> >
> I want to move the methods from FFI to the base since years… I was told
> that this is impossible to ever happen because it is not important to do
> changes like that.
>

Marcus
>

Hi Marcus,
we all know that those un-important and not-so-much-rewarding changes makes
a big difference at the end.
like commenting classes, classifying methods, deprecating duplicates,
reducing package inter-dependencies, etc...
I thought that the defenders of statu quo had two reasons in mind:
- the will to keep a FFI-less (locked-in) image
- the fear to loose backward compatibility
But's it the past, now you are free :)

Re: [Pharo-dev] File/Stream changes: one Integer decoder/encoder to rule them all

[Marcus Denker]

> 
> 
> For ByteArray, I didn't check recently in Pharo, but I know that it's quite a 
> mess in Squeak because some methods are in Alien, other in FFI, other in base 
> Squeak...
> IMO all methods should be in core Squeak/Pharo because of general usage (like 
> decoding binary data).
> 
I want to move the methods from FFI to the base since years… I was told that 
this is impossible to ever happen because it is not important to do changes 
like that.

Marcus

[Pharo-dev] [Pharo 7.0-dev] Build #893: 21885-Simplify-ProcessList-classdumpPigStackOnandClose

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #893 was: FAILURE.

The Pull Request #1351 was integrated: 
"21885-Simplify-ProcessList-classdumpPigStackOnandClose"
Pull request url: https://github.com/pharo-project/pharo/pull/1351

Issue Url: https://pharo.fogbugz.com/f/cases/21885
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/893/

Re: [Pharo-dev] File/Stream changes: one Integer decoder/encoder to rule them all

[Nicolas Cellier]

2018-05-14 13:22 GMT+02:00 Guillermo Polito :

>
>
> On Fri, Apr 20, 2018 at 5:24 PM, Sven Van Caekenberghe 
> wrote:
>
>> Hi,
>>
>> After the File and Stream changes in Pharo 7, a binary read, resp. write
>> stream from/to a file is actually a ZnBuffered(Read|Write)Stream on a
>> BinaryFileStream. You access these using #binary(Read|Write)Stream[Do:]
>> sent to a FileReference.
>>
>> As minimal streams the API of ZnBuffered(Read|Write)Stream was different
>> from what existed before.
>>
>> Specifically, a number of Integer decoding/encoding methods were missing.
>> It is probably best to add those (an alternative would be a subclass).
>>
>> When I looked at what was available, I thought I could improve upon the
>> current situation. In fact, I think all existing ones can be written in
>> terms of just one key method, one for reading and one for writing. The
>> existing methods than become simple aliases, all while offering more
>> functionality.
>>
>> (Incidentally this would be an ideal use of a Trait, can we use them
>> again/still ?)
>>
>> The key method is #nextIntegerOfSize: numberOfBytes signed: signed
>> bigEndian: bigEndian [put: value] and can be found in the latest version of
>> Zinc-CharacterEncoding-Core with a comprehensive set of unit tests.
>>
>> For example,
>>
>> int32
>>   ^ self nextIntegerOfSize: 4 signed: true bigEndian: true
>>
>> nextWord
>>   ^ self nextIntegerOfSize: 2 signed: false bigEndian: true
>
>
>> or non-aliases ones like
>>
>>   binaryStream nextIntegerOfSize: 3 signed: true bigEndian: false
>>
>> I think I nailed it, but I would love a second pair of eyes to check what
>> I did.
>>
>
> Sorry I arrive late.
>
> I'm thinking that this is only valid for binary streams, putting it in
> buffered stream overloads the API... We can leave with it but... Two
> thoughts that come to my mind about this:
>
>  - first, when we are decoding like that from a stream, we are probably
> parsing a binary format, so we want in general to have utility methods to
> read different sizes. Maybe we could include a Reader class with methods
> such as
>* readSignedInt32
>* readUnsignedInt32
>* readSignedInt64
>* readUnsignedInt64
>* readFloat64
>
> ... and so on?
>
> - Second, that Reader may be (or not) a new decorator alternative.
> ZnBinaryDecoder? Wrapping a binary (buffered or not) stream. And this would
> not overload the API ^^.
>
> What do you think?
>

Hi Guillermo,
wouldn't a specialized wrapper work for adding this protocol where required?
I have to add such BinaryStream wrapper in VW and Squeak

http://www.squeaksource.com/STEM.html
http://www.cincomsmalltalk.com/publicRepository/SYSEXT-BinaryStream.html

For ByteArray, I didn't check recently in Pharo, but I know that it's quite
a mess in Squeak because some methods are in Alien, other in FFI, other in
base Squeak...
IMO all methods should be in core Squeak/Pharo because of general usage
(like decoding binary data).



>
>> The same functionality could be added to ByteArray in a slight variation
>> (with offsets), where similar integer encoding/decoding methods exist.
>>
>> Sven
>>
>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13
>

Re: [Pharo-dev] File/Stream changes: one Integer decoder/encoder to rule them all

[Guillermo Polito]

On Fri, Apr 20, 2018 at 5:24 PM, Sven Van Caekenberghe  wrote:

> Hi,
>
> After the File and Stream changes in Pharo 7, a binary read, resp. write
> stream from/to a file is actually a ZnBuffered(Read|Write)Stream on a
> BinaryFileStream. You access these using #binary(Read|Write)Stream[Do:]
> sent to a FileReference.
>
> As minimal streams the API of ZnBuffered(Read|Write)Stream was different
> from what existed before.
>
> Specifically, a number of Integer decoding/encoding methods were missing.
> It is probably best to add those (an alternative would be a subclass).
>
> When I looked at what was available, I thought I could improve upon the
> current situation. In fact, I think all existing ones can be written in
> terms of just one key method, one for reading and one for writing. The
> existing methods than become simple aliases, all while offering more
> functionality.
>
> (Incidentally this would be an ideal use of a Trait, can we use them
> again/still ?)
>
> The key method is #nextIntegerOfSize: numberOfBytes signed: signed
> bigEndian: bigEndian [put: value] and can be found in the latest version of
> Zinc-CharacterEncoding-Core with a comprehensive set of unit tests.
>
> For example,
>
> int32
>   ^ self nextIntegerOfSize: 4 signed: true bigEndian: true
>
> nextWord
>   ^ self nextIntegerOfSize: 2 signed: false bigEndian: true


> or non-aliases ones like
>
>   binaryStream nextIntegerOfSize: 3 signed: true bigEndian: false
>
> I think I nailed it, but I would love a second pair of eyes to check what
> I did.
>

Sorry I arrive late.

I'm thinking that this is only valid for binary streams, putting it in
buffered stream overloads the API... We can leave with it but... Two
thoughts that come to my mind about this:

 - first, when we are decoding like that from a stream, we are probably
parsing a binary format, so we want in general to have utility methods to
read different sizes. Maybe we could include a Reader class with methods
such as
   * readSignedInt32
   * readUnsignedInt32
   * readSignedInt64
   * readUnsignedInt64
   * readFloat64

... and so on?

- Second, that Reader may be (or not) a new decorator alternative.
ZnBinaryDecoder? Wrapping a binary (buffered or not) stream. And this would
not overload the API ^^.

What do you think?


> The same functionality could be added to ByteArray in a slight variation
> (with offsets), where similar integer encoding/decoding methods exist.
>
> Sven
>



-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

[Pharo-dev] [Pharo 7.0-dev] Build #892: 21890 Cleanup Collections-Sequenceable

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #892 was: SUCCESS.

The Pull Request #1345 was integrated: "21890 Cleanup Collections-Sequenceable"
Pull request url: https://github.com/pharo-project/pharo/pull/1345

Issue Url: https://pharo.fogbugz.com/f/cases/21890
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/892/

[Pharo-dev] [Pharo 7.0-dev] Build #891: 21738 Fix inconsistent method classifications (lint) in Collections

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #891 was: SUCCESS.

The Pull Request #1222 was integrated: "21738 Fix inconsistent method 
classifications (lint) in Collections"
Pull request url: https://github.com/pharo-project/pharo/pull/1222

Issue Url: https://pharo.fogbugz.com/f/cases/21738
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/891/

Re: [Pharo-dev] [Pharo 7.0-dev] Build #890: 21896-Cleanup-Shout

[Marcus Denker]

Builds are failing du to CI problems…. e.g this one
missing workspace 
/builds/workspace/branch_Pipeline_development-CMOUMEH7DVLJPL2EIJ6VPEHUQRS3W4AK3FD4ESTKJ3YGKZERQFUQ
 on pharo-ci-jenkins2-bootstrap-unix-2

But the granularity of PRs are very small (and they are tested on the PR level, 
too), so just one build in 6 or so is not that dangerous.

(if the build for a merged PR fails, the merge still happened: the next PR 
merge then will build the system with the old one and the current one…)

We need to track down the problems on the CI.


Marcus

> On 14 May 2018, at 12:06, ci-pharo-ci-jenki...@inria.fr wrote:
> 
> There is a new Pharo build available!
>   
> The status of the build #890 was: FAILURE.
> 
> The Pull Request #1350 was integrated: "21896-Cleanup-Shout"
> Pull request url: https://github.com/pharo-project/pharo/pull/1350
> 
> Issue Url: https://pharo.fogbugz.com/f/cases/21896
> Build Url: 
> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/890/

[Pharo-dev] [Pharo 7.0-dev] Build #890: 21896-Cleanup-Shout

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #890 was: FAILURE.

The Pull Request #1350 was integrated: "21896-Cleanup-Shout"
Pull request url: https://github.com/pharo-project/pharo/pull/1350

Issue Url: https://pharo.fogbugz.com/f/cases/21896
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/890/

Re: [Pharo-dev] Easy way to browse Hermes packages?

[Alistair Grant]

Hi Pablo,

Thanks! I'll take a look (my Pharo time is very limited at the moment,
unfortunately).

Cheers,
Alistair


On 12 May 2018 at 20:19, teso...@gmail.com  wrote:
> Hello,
>having the Hermes files and any Pharo7 image it is easy to inspect the
> Hermes package.
> It only had to be read from the fileSystem.
>
> You can execute:
>
> reader := HEBinaryReader new
> stream: ('AST-Core.hermes' asFileReference) binaryReadStream;
> yourself.
>
>
> package := HEPackage readFrom: reader.
>
>
> If you inspect the package you will see all the content in the Hermes file
> (the format allows us to have different root elements in the file, but we
> are exporting a package per file).
> If it is useful we can include it as an inspector.
>
> Cheers,
> Pablo
>
> On Fri, May 11, 2018 at 10:55 PM, Alistair Grant 
> wrote:
>>
>> Hi Everyone,
>>
>> Is there an easy way to browse the contents of .hermes files (from the
>> Pharo 7 bootstrap process)?  Or at least list the packages, classes
>> and methods defined within?
>>
>> Thanks!
>> Alistair
>>
>
>
>
> --
> Pablo Tesone.
> teso...@gmail.com

[Pharo-dev] [Pharo 7.0-dev] Build #889: 21889 Tag manifest in Collections-Arithmetic

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #889 was: FAILURE.

The Pull Request #1344 was integrated: "21889 Tag manifest in 
Collections-Arithmetic"
Pull request url: https://github.com/pharo-project/pharo/pull/1344

Issue Url: https://pharo.fogbugz.com/f/cases/21889
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/889/

Re: [Pharo-dev] Problems with the removal of Nautilus

[Guillermo Polito]

Cool, Thanks!

On Fri, May 4, 2018 at 3:24 PM, Pavel Krivanek 
wrote:

> createPackageNamed: - solved by you
> browse - adds an ability for RBBrowserEnvironment to be browsed by
> Nautilus, no action needed
> asRingDefinition - for UndefinedObject, solved by Nautilus removal, no
> action needed
> addCategory:before: - solved by Nautilus removal, no action needed
> hasErrorTest - solved by Nautilus removal, no action needed
> inheritsFrom:  - solved by Nautilus removal, no action needed
> compile:classified:notifying: - solved by Nautilus removal, no action
> needed
> traits  - solved by Nautilus removal, no action needed
> hasPassedTest - solved by Nautilus removal, no action needed
> extendingPackages - solved by Nautilus removal, no action needed
> hasFailedTest  - solved by Nautilus removal, no action needed
> #color - solved by Nautilus removal, no action needed
> annotateRubricText: - solved by Nautilus removal, no action needed
>
> The rest are the menu entries (https://pharo.fogbugz.com/f/
> cases/21827/clean-NautilusRefactoring-menu-entries-for-Nautilus).
>
> So at least from the method extensions point of view, we should be safe.
> Thanks
>
> -- Pavel
>
> 2018-05-04 13:30 GMT+02:00 Pavel Krivanek :
>
>> In an old image with Nautilus I did this:
>>
>> names := #('Nautilus' 'NautilusCommon' 'Nautilus-GroupManager'
>> 'Nautilus-GroupManagerUI' 'QualityAssistant' 'QualityAssistantRecording'
>> 'QualityAssistant-Test').
>>
>> selectors := names flatCollect: [ :packageName | packageName asPackage
>> extensionMethods collect: #selector as: Set ].
>> selectors reject: [ :each |
>> senders := SystemNavigation default allSendersOf: each.
>> senders allSatisfy: [ :sender | names includes: sender package name ] ].
>>
>> This is the result of problematic extensions. Some of them are solved by
>> the removal, most of them are menu entries in NautilusRefactorings. The
>> mentioned selector #createPackageNamed: is there.
>>
>>  "#(#codeRewritingClass: #methodRefactoring: #refactoringMenu:
>> #varRefactoringSubMenu: #groupRefactoring: #createPackageNamed:
>> #sourceCodeRefactoring: #refactoringSubmenu: #instVarRefactoring:
>> #refactoringMethod: #browse #sourceCodeRefactoringMenu: #asRingDefinition
>> #addCategory:before: #hasErrorTest #inheritsFrom:
>> #compile:classified:notifying: #traits #hasPassedTest #extendingPackages
>> #browsedEnvironment: #hasFailedTest #notifyViewedDiffFor:of: #repairIcon
>> #color #annotateRubricText: #notifyBanInitiatedFor:of:
>> #notifyCritique:AutoFixedFor:)"
>>
>> I will check them and make the issue entries.
>>
>> -- Pavel
>>
>> 2018-05-04 13:08 GMT+02:00 Pavel Krivanek :
>>
>>>
>>>
>>> 2018-05-04 10:19 GMT+02:00 Guillermo Polito :
>>>
 Hi,

 I've just tried to create a new package in Calypso and I got bitten by
 this:

 https://pharo.fogbugz.com/f/cases/21804/Creating-a-Package-f
 rom-Calypso-produces-DNU

 Creating a new package was an extension of Nautilus, and was never
 introduced in RPackage.

 How should we procceed? How can we know all the "extensions" that were
 not so?

>>>
>>> I will try to check them
>>>
>>> -- Pavel
>>>
>>>

 --



 Guille Polito

 Research Engineer

 Centre de Recherche en Informatique, Signal et Automatique de Lille

 CRIStAL - UMR 9189

 French National Center for Scientific Research - *http://www.cnrs.fr
 *


 *Web:* *http://guillep.github.io* 

 *Phone: *+33 06 52 70 66 13

>>>
>>>
>>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

[Pharo-dev] [Pharo 7.0-dev] Build #888: 21891-PluggableButtonMorph-in-dark-theme-does-not-take-the-theme-into-account-for-the-border

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #888 was: FAILURE.

The Pull Request #1348 was integrated: 
"21891-PluggableButtonMorph-in-dark-theme-does-not-take-the-theme-into-account-for-the-border"
Pull request url: https://github.com/pharo-project/pharo/pull/1348

Issue Url: https://pharo.fogbugz.com/f/cases/21891
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/888/

[Pharo-dev] [Pharo 7.0-dev] Build #887: 21892 Tag and comment Multilingual packages

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #887 was: FAILURE.

The Pull Request #1346 was integrated: "21892 Tag and comment Multilingual 
packages"
Pull request url: https://github.com/pharo-project/pharo/pull/1346

Issue Url: https://pharo.fogbugz.com/f/cases/21892
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/887/