Hi all,
Travis now supports debugging builds where it enables SSH access to the running VM:
https://docs.travis-ci.com/user/running-build-in-debug-mode
Unfortunately, for security reasons this is not available for public repositories.
And public forks cannot be simply changed to private ones... :-/
So there is a bit complicated way, you need to create a new empty repository and
mirror the content from the target repository there:
https://help.github.com/en/github/creating-cloning-and-archiving-repositori…
Note: for accessing the private repositories at Travis you need to use the
https://travis-ci.com URL, the https://travis-ci.org only displays the public GitHub
repositories.
When you start a debug build the VM prints the SSH command for accessing it. It does
not start the build, you can do that via SSH or you can inspect the environment
before running the tests...
The session is running for some limited time (maybe 20 minutes? I have not measured
that, but it is quite long). After a timeout the job is aborted. If you still
need it you can restart the build again, just maybe you will need to repeat some
steps again, just be prepared for that.
HTH
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
The interface of the YaST Partitioner has reached a point in which is
really hard to deal with it. We need to find a way to move forward.
As a first step, we have created this document that explains the problem
and we hope it can be used as a base to discuss the future of the
Partitioner interface.
https://github.com/yast/yast-storage-ng/blob/master/doc/partitioner_ui.md
This is a very important topic for the future of YaST. All ideas are
welcome. Feel free to reply to this mail, to create pull requests for
the document, to discuss the topic at #yast channel at Freenode...
whatever works for you.
Cheers.
--
Ancor González Sosa
YaST Team at SUSE Linux GmbH
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hello!
Today I'll create the SLE-15-SP2 maintenance branch from master
for all YaST and libyui packages.
I'll start around 16:00 CEST (14:00 UTC). Because there are so many
packages it will take some time, I'll let you know when it's done.
So if you still have some pull requests for the SP2 open then merge them ASAP,
or change the target branch after the SP2 branch is created.
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hello,
AFAIK the YaST AppArmor module uses the JSON output of aa-status.
There are two upcoming changes, and I'd like to point them out so that
you can adjust the YaST AppArmor module if needed.
a) new profile modes
Besides complain and enforce mode, future AppArmor versions (>= 3.0)
will also have `unconfined`, `mixed` and `kill`.
Technically the structure of the JSON doesn't change, but there will be
new values for the status, for example
"processes": {
"/usr/lib/GConf/2/gconfd-2": [
{
"pid": "3899",
"profile": "/usr/lib/GConf/2/gconfd-2",
"status": "kill"
}
]
}
"profiles": {
"/does/not/exist": "kill"
}
Side question: Do you think this warrants increasing the JSON version
number?
Quick explanation about the new modes:
- unconfined: similar to not having a profile, but when using an
unconfined profile, it's possible to replace it with a "real" profile
later, so that programs initially running under an unconfined profile
get a profile in enforce mode
- kill: similar to enforce, but on profile violations, the process will
be killed instead of "just" getting EPERM
- mixed: when using stacked profiles, this indicates that a program is
for example using a stack of two profiles, one in complain and one in
enforce mode. (This also means you'll see "mixed" only in aa-status
output, but never in a profile's "flags=(...)".)
(Extending the aa-* tools to support switching to kill and unconfined
mode is still on my TODO list.)
b) whitespace changes
aa-status was rewritten to C, which results in changed whitespace in the
--json output. Currently --pretty-json also results in "compressed"
JSON, but I hope that this will change again in the future.
I'd guess/hope that whitespace changes shouldn't matter, but please
check nevertheless.
Currently the new aa-status is only available in upstream git master.
If it makes testing easier for you, I can provide the compiled binary or
some example output.
Regards,
Christian Boltz
--
Es kann dadurch
, daß der Rechner (
wenn er an Trenn
- zeichen umbricht [Ratti erklärt
) die falschen Stellen den Begriff
erwischt , zu ganz gräß "Plenken"
- lichen Effekten kommen in suse-linux]
!
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
On Thu, 30 Apr 2020 14:24:16 +0100
Imobach González Sosa <igonzalezsosa(a)suse.de> wrote:
> El jue, 30-04-2020 a las 12:44 +0200, josef Reidinger escribió:
> > On Thu, 30 Apr 2020 12:40:39 +0200
> > josef Reidinger <jreidinger(a)suse.cz> wrote:
> >
> > > Hi,
> > > after modifying xml parser, it appears that our relax ng schema is
> > > too strict to allow having type for every xml element. So we should
> > > discuss possible solutions.
> > >
> > > One of solution is to modify our schema to optionally allow that
> > > types. I prepare schema change for installation control ( while
> > > change for autoyast schema will be needed to do ) and also show
> > > example how looks autoyast profile when exported by modified xml
> > > parser[1]. If you like typed languages I am sure you will like new
> > > xml more then previous :) If not, it still allows to not specify
> > > string and map type, just autoyast exported will add it everywhere
> > > to handle also empty strings and hashes ( which need it always ).
> > >
> > > Josef
> > >
> > > [1] https://github.com/yast/yast-installation-control/pull/96
> >
> > Ah, and I forgot to write that meeting will be on Monday after daily
> > call at YaST3 at 11:30 CEST.
>
> Nice, I have added the meeting to the calendar, but I am not sure
> whether the time is correct (I would bet that it is wrong). Could
> anyone check it?
>
> Thanks!
>
Good job, you use correct time.
Thanks for adding it.
Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi all,
We have just published a blog post summarizing some of the ideas
related to the "modernizing AutoYaST" initiative.
https://yast.opensuse.org/blog/2020-04-30/modernizing-autoyast
Not all ideas are there and it is possible that some of them never get
implemented. But it is a nice picture of the options we are considering
right now.
Regards,
Imo
--
Imobach González Sosa
YaST Team at SUSE LLC
https://imobachgs.github.io/
Hi,
after modifying xml parser, it appears that our relax ng schema is too strict to allow having type for every xml element. So we should discuss possible solutions.
One of solution is to modify our schema to optionally allow that types. I prepare schema change for installation control ( while change for autoyast schema will be needed to do ) and also show example how looks autoyast profile when exported by modified xml parser[1]. If you like typed languages I am sure you will like new xml more then previous :) If not, it still allows to not specify string and map type, just autoyast exported will add it everywhere to handle also empty strings and hashes ( which need it always ).
Josef
[1] https://github.com/yast/yast-installation-control/pull/96
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
On 4/30/20 12:40 PM, josef Reidinger wrote:
> [1] https://github.com/yast/yast-installation-control/pull/96
Checking the PR, I saw a diff from "disksize" to "string". That's right
as there's no "disksize" data-type. We have also discussed that we
should then modify our control.xml stored on disk during RPM-post-script
(which is the right way as `zypper dup` is supported too).
But I have a question: what happens in customers' AY profiles actually
contain these "disksize" types? Are they going to be invalid? Should we
replace/remove them when loading the profile first? I'd like to be
careful here, because what used to be valid for ages now turns into
invalid because of our internal change. That doesn't sound right even if
our intentions were crystal clear.
What do you think?
Thx
Lukas
--
Lukas Ocilka, Systems Management Team Leader & YaST Product Owner
SLE Department, SUSE Linux
🌲 Please consider the environment before printing this e-mail
☂ Handle with care - Your reply can be stored in the cloud
😱 Pie-chart is just a representation of randomly chosen data
⚠ IMPORTANT: The contents of this email and any attachments are
confidential. They are intended for the named recipient(s) only.
If you have received this email by mistake, please, notify the
sender immediately and do not disclose the contents to anyone
or make copies of thereof.
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi all,
After doing some research[1] (thanks all for your feedback), the YaST
team has started to work on improving AutoYaST. We have identified some
areas that we should focus on. One of them, is the process of creating
an AutoYaST profile.
Creating a profile can be quite challenging, so we offer two different
tools to help you in this process:
* The "yast2 clone_system" command, which generates a profile with the
configuration of the current system. It allows to filter which parts of
the profile take into account.
* The "AutoYaST UI", which allows to create a profile from scratch (or
by cloning the configuration of the current system) and modify the
values using a UI. This tool is included in the "autoyast2" package.
However, we wonder how do you create your profiles. Do you use any of
those tools? Or do you just write some XML yourself? Perhaps you use
the tools and tweak the results later...
Moreover, we would love to know which problems do you face when you try
to create a new profile. Is there anything our tools could do to make
your life easier? What about providing some kind of "templates"
(minimal, full...) you can tweak? Any other idea?
Please, if you can, help us with providing your feedback. Of course,
any comment beside these questions is highly appreciated as well.
Regards,
Imo
[1] https://lists.opensuse.org/opensuse-factory/2020-04/msg00291.html
--
Imobach González Sosa
YaST Team at SUSE LLC
https://imobachgs.github.io/
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org