I want to fix yast2-slide-show for SLE11 SP3. Which git commands do I
have to use, please?
Thus far, I have checked out trunk only.
--
Karl Eichwalder SUSE LINUX Products GmbH
R&D / Documentation Maxfeldstraße 5
90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (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
Hello,
Can any tell me please, witch packet i have to install for the "graphic" in
console Mode
There is a missing dependency for the correct drawing the frame ?.
This is a minimal Install and running in init 3 mode.
Thanks :)
--
mit freundlichen Grüßen / best Regards,
Günther J. Niederwimmer
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
I would like to announce, that new version of ruby bindings (3.1.2) is
released. There is two changes:
1. Detect if there is invalid response type from client ( client call
using component system, so only simple types are allowed ) -
https://github.com/yast/yast-ruby-bindings/issues/81
2. Improved exception handling. Now if exception appear in client, then
error message about internal error is shown to user. It using
Report.Error so it works good in various cases ( TUI, autoyast, CLI ).
After report it works as before, so client return nil and continue.
Reason for this change is to reduce number of silent failures and
encourage everyone to use exceptions in yast code.
I think we need some rules for exceptions. My proposel is to use
exceptions everywhere and every uncaught exception is bug. This
behavior allows us to quickly see problem and do not have current
silent failures.
Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
At first I think that there is now good time to switch hudson to start
sending sr to openSUSE:Factory when version changed as we already
agreed in past. It is good time, because we are only weak away from
GMC, so there is really low risk of accidental took of package to 13.1.
At the second I like to enable together with this step also sending
emails when build start failing. We agreed on yast-commit mailing list.
But when I check the mailing list I found there a bunch of useless
mails like few commits send to repo, click on link to see diff. I think
that github works fine even without this email notification.
Who read such commit mails? I think that we can stop sending there such
emails and send there failures from jenkinks and set OBS to send there
also if a package start failing in YaST:Head. What do you think about
it?
What do you think about proposals?
Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
as part of a Hack Week project [1], some members (and one non-member :-)
of the Prague SUSE YaST team decided it is a good idea to add the
following two files with standardized content to each YaST GitHub
repository:
* README.md
* CONTRIBUTING.md
The README.md file would provide a visitor of the repository with the
description of given YaST module, basic installation & usage
instructions and pointers to other documentation. Content of this file
would be similar (but not exactly the same) for each repository.
The CONTRIBUTING.md file would be displayed in GitHub UI when a
contributor creates an issue or opens a pull request [2]. It is a
convenient place to put basic contribution guidelines and pointers to
development documentation. Content of this file would be exactly the
same for each repository.
We didn't discuss the idea of adding these files with the rest of YaST
community so far, because we felt it is non-controversial. In the next
paragraphs, I'll assume you generally agree with it -- if that's not the
case, or you have some comments, please speak up now.
As a flollow-up to the Hack Week project, I finished a draft of the
CONTRIBUTING.md file today:
https://github.com/yast/yast-nfs-server/pull/11
Let me know what you think about it in comments on GitHub. My plan is to
adapt the draft if necessary and once it's stable, I'd like to
mechanically add the file to all relevant non-dead repositories inside
the YaST organization. If all goes well, I assume I'll do that at the
beginning of the next week. After that, I'd like to look at REAMDE.md.
[1] https://hackweek.suse.com/projects/132
[2] https://github.com/blog/1184-contributing-guidelines
--
David Majda
SUSE developer
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
as factory is already splitted to 13.1 and we have bunch of quite
aggresive changes on stack like rake build system, rubify code or core
changes, I think we should do fixes for 13.1 in maintenance branch
following common naming schema[1] - openSUSE-13_1
Any comments, counter-proposals or complains?
Josef
[1] https://en.opensuse.org/openSUSE:YaST_SVN_to_GIT#Conventions ( yes,
location sucks and we plan to improve documentation )
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
it looks like after conversion to ruby number of external contribution
to yast repo slightly increase. It is quite nice effect, but we should
try to keep such contribution. From my POV our current biggest problem
with some contributions is small reactions in some cases. So I think
how to solve it and propose few rules for yast maintainers.
1. keep response time short ( I think that 24 hours response time is
the best, if you check once a day your mailbox, then you should also
check if you should review something )
2. member who do yast screening should at least once a weak check pull
requests without activity ( how define it? no activity for week?) and
ping proper person ( you can easily sort it from the latest activity
with
https://github.com/organizations/yast/dashboard/pulls?direction=asc&page=1&…
)
3. member who do screening team should manage* review for modules
without specific maintainer
* manage mean, that he can ask person who looks the most appropriate
for such review
I think that even you are discouraged from contribution if noonse seems
interested in your fix, so we should act better to encourage
contributors.
ideas, opinions, comments?
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,
for the new installer project I need to update the inst-sys image quite often,
to share the knowledge I wrote a blog post.
There is a summary how to add a new package to inst-sys (the same applies
also to the rescue system, you just need to touch a different file).
You can read it here:
http://lslezak.blogspot.cz/2013/10/adding-new-package-to-opensuse.html
If you have any questions just ask me.
--
Ladislav Slezák
Appliance department / YaST Developer
Lihovarská 1060/12
190 00 Prague 9 / Czech Republic
tel: +420 284 028 960
lslezak(a)suse.com
SUSE
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi there,
I would like to know whether Snapper avoids creating snapshots on disks
which are on standby, preventing the disks to spin up.
Kind regards,
Alain
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
