Hi there!
Is there any plan for starting the SLE-15-SP2 branching? Who? When?
BTW, that's comes to my mind that Iván started some time ago (during
HackWeek 18?) an script[2] to ease the version bumping of YaST modules.
Unfortunately, it still as WIP/PoC.
Regards.
[1] https://github.com/joseivanlopez/yast-dev
--
David Díaz González
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
Hi,
I am currently working on research how to improve XML parser in YaST. What we have nowadays is libxml2 based c++ parser ( that almost noone use directly ) and XML module ( module as a code, not YaST module :). I check usage of XML module and main usage is data to XML and back ( with variant xml as string or xml as file ). There is just two additional functionality. One is checking xml error ( almost noone use it ) and setting metadata for generated xml ( bad API as it should be part of that data to XML method ).
So my question is what we would like to have better? One thing for sure that hit us often is optional schema validation ( as some XML is prevalidated like control files for products of roles, but autoyast is user generated/written ). Also some nicer error reporting would be nice because current XMLError method is almost never used (and yes, you should read nicer as using exception that can/have to be catched otherwise it report popup with internal error and not cause some strange error later ). Do you think that it makes sense at all to have own module as ruby, perl and also python, for whose we currently have bindings, all have own good ( good as better then our ) parser. So does it makes sense to have own XML parser beside backward compatibility and for new stuff as already seen on some places just use rexml or nokogiri that e.g. already have support for relax ng validation[1]? Or do we have some functionality that we would like to have on top of standard parsers?
Only thing that current parser have on top of generic xml parsers is understanding of type attribute that do automatic type conversion so `<a type="boolean>true</a>` is returned as `true` and not `"true"`. But this magic is also source of some bugs as e.g. hash does not have this type attribute and result is that `<a><key>b</key>c</a>` is returned as `"c"` and not hash, which cause many recent failures we get with typos in autoyast profiles. And as bonus we do not specify this types in schema, so during validation if you omit type it is still valid xml, but it crashes in code as it expect different type.
I would welcome any suggestions or ideas how your ideal xml parser should look like.
Thanks
Josef
[1] https://stackoverflow.com/questions/913489/how-do-i-validate-xml-via-relax-…
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
FYI,
On the $subject cited web page, the link to Bugzilla seems to be
outdated, yielding:
Sorry, either the product openSUSE Factory does not exist or you
aren't authorized to enter a bug into it.
After a bit of browsing found the following
https://bugzilla.suse.com/show_bug.cgi?id=906727, so suggest updating
the link via s/openSUSE+Factory/openSUSE+Tumbleweed/
P.S. the context around this is to submit feature requests for YaST,
so hoping that bugzilla is the right answer
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi all,
I'm improving the YaST self-update [1] to avoid applying wrong patches to the
installer (i.e. using the SP1 or SP3 update repository in the SP2 installer).
I have already implemented the downgrade check [2] (e.g. using the SP1 updates
in SP2), now I'd like to also implement the other check (using the future SP3
updates in SP2).
However, this case is a bit more complicated, we need to somehow differ between
the "new" (a valid update) and "too new" (update for a newer SP release) packages.
And we need some reliable solution for that to avoid false errors.
Here is a summary of my ideas, please comment them or add your own.
1. Compare the major and minor YaST package versions
As the YaST package versions are bound to specific SP release (e.g.
4.1.x for SP1, 4.2.x for SP2) we could simply check that the updated
package version has the same major and minor version as the installed one.
I.e. allow a difference only in the patch number.
But unfortunately this is not bullet-proof, we still have some YaST packages
in version 4.1.x even in SP2. That should be hopefully fixed during branching
SP2 in Git but it still shows that it's not 100% percent reliable.
2. The RPM "Distribution" value
Every package has a "Distribution" flag (check with
"rpm --queryformat '%{DISTRIBUTION}' -q ..." command).
Unfortunately even for the SP2 the value is still "SUSE Linux Enterprise 15"
so we cannot differ between the GA/SP1/SP2/... packages. :-/
And I think it would not work well with unofficial testing packages built
in your OBS branch project as the "Distribution" then contains the "home:..."
prefix. So testing would be more difficult.
3. Custom provides flag
We could possibly use some custom RPM flag, something like
"Provides: yast-self-update-version(15.2)" added when releasing a self-update.
We could compare it with the value stored in the /etc/os-release file in the
inst-sys.
Because it's enough to have this flag only once in the self-update repository
we would add it just to the first YaST package released as a self-update.
The other package updates released later would not need to have this flag.
I deliberately selected the "15.2" value which corresponds to the "VERSION_ID"
tag in the /etc/os-release file because this is the same for both SLE-15-SP2
and Leap 15.2 so we could easily build the same self-update packages also for
Leap 15.2 if needed.
Any comments, ideas?
Thank you in advance!
[1] https://github.com/yast/yast-installation/blob/master/doc/SELF_UPDATE.md
[2] https://github.com/yast/yast-installation/pull/842
--
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
Hi all,
A short version: see https://github.com/lslezak/ghreview
The minimalistic version: "gem install ghreview" :-)
Full version:
Sometimes we need to do a simple change but in many Git repositories.
Sometimes we need to touch *all* repositories, like when we need to change the
CONTRIBUTION.md or some similar file.
Approving several dozens of pull requests in the GitHub web UI is not easy
or convenient so I have created a simple script which can approve the
pull requests from command line.
The tool is interactive, for each pull request is displays some details,
the diff, the Travis status, etc... and then it asks for approval.
If you accept it will approve the pull request at GitHub with the usual "LGTM"
message. If there is an issue the review is skipped, you need to manually comment
at the GitHub web UI. (There is no easy way for commenting a diff from command line.)
For more details like usage and installation see https://github.com/lslezak/ghreview
PS: So far there are no RPM packages provided, but you can convince me to build it
in YaST:Head :-)
--
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
Dne 24. 03. 20 v 19:43 Arvin Schnell napsal(a):
> The POs should know what work is ahead.
I'm afraid that there is a misunderstanding about our superpowers :) POs
know which features are now requested, which P1s are mandatory to fix.
POs even guess which features could be requested in the future if they
are in JIRA already and they partly know what should be done based on
their and the team experience, but - and that is the most important -
POs don't, and never will be, able to "read" the future, e.g., how many,
how important and how hard P1s are going to come tomorrow, or in a week
or two. The same for L3s. We can only guess based on some old data,
e.g., previous products.
The decision when and how to branch is still on the team. I can only say
that I'm going to plan for "the future" already.
HTH
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
Dne 24. 03. 20 v 18:49 Arvin Schnell napsal(a):
> I am working on SP2 so I suggest to still wait with creating the
> branch.
I'm afraid that most of the developers still work on SP2 fixes, but the
point is that some (even the same ones) already started or want to start
(or even have to start) working on new products.
We can't really wait till SLE 15 SP2 is out. Or did I understand
something incorrectly?
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
Since nobody on our IRC channel seemed to know this and it took me quite
a while to figure out, I thought I'd write this up for the benefit of
others:
I wanted to use a shared folder in a VirtualBox Linux VM where I can
edit source files on my host system, yet build inside the VM with a
well-defined development environment.
By default, VirtualBox uses bizarre permissions that won't let you do
very much; but that can be hammered into shape to become useful:
https://github.com/shundhammer/huha-linux-tips/blob/master/doc/virtualbox-t…
Kind regards
--
Stefan Hundhammer <shundhammer(a)suse.de>
YaST Developer
SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG
Nürnberg)
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org