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
Moin,
I've discussed this with some of you already. Anyway, for the rest...
The problem definition is this: We often have something we'd like to
discuss with others and get a quick response. At least I have these
quite often. Mailing-list works only partly as people have too much time
for their response and sometimes do not respond at all, so quick and
still good solution that could be made in 30 minutes takes two weeks.
There is a simple solution: Brainstorming - that's proven to bring fast
and good ideas (please, +1 if you are interested, -1 if not).
How to implement it with distributed team? We have plenty of
possibilities: phone conference (people only hear you and you can't
share your, e.g., drawings), video conference Orange/Rome (only
internal, e.g., Ancor can't join), G+ Hangout (some of you don't like
using Google), Internal web-based audio/video system (not tested by me).
Other ideas welcomed!
How this could work? I'd book some time in everyone's groupwise (1 hour
max per week) including a conference room with video system (if needed).
Then everyone could mention their theme on the weekly call or via
mailing-list and when will the brainstorming happen. Everyone could
decide whether to join (or not).
Would it help with your issues? It would definitely work for me. Would
it also work for you? Other ideas? How is this being done in other teams
or in other companies?
Thanks
Lukas
--
Lukas Ocilka, Systems Management (Yast) Team Leader
SLE Department, SUSE Linux
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
The yast-journal module is ready to enter YaST:Head.
It's already hosted in the yast organization at Github and integrated in
Travis with Rubocop, Coveralls (78%), and Yardoc (100%).
https://github.com/yast/yast-journal
So...
1) ...a warning
Last call to suggest an alternative name.
2) ...a question
What else do I have to do besides creating the package in OBS/IBS? I
have to admit that I have still not taken the time to look close into
our Jenkins infrastructure.
PS.- The most demanded feature is different colors for the entries (rows
on a table) depending on the priority. Is something like that possible
with libyui?
--
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
Now that overlayfs went into the 3.18 kernel I've had a look if this could
be used in our installation environment.
= what we need =
We have to combine several ro (squashfs) filesystems into the root fs. And
the final fs should be writable. Also, it should be possible to easily add
and remove fs images.
= what we currently do =
A script integrates new filesystem images by adding symlinks as needed.
= what overlayfs (currently) can do =
First, here's how to use it:
mount -t overlay overlay -olowerdir=/foo,upperdir=/bar,workdir=/xxx /mnt
where /xxx must be on the same fs as /bar but not below /bar. (That's why
upperdir must be a writable fs atm, btw.)
You can combine exactly *two* filesystems the 'upper' one must be writable.
(Doc says you can use two ro filesystems but that is not true atm and
there's a note in the sources that they might fix this.)
There's no way to combine more than two filesystems except by step-by-step
doing overlay mounts. This seems not much of a problem at first but in
practice is quite annoying as there are conditions to fulfill; namely you
have to have a 'work' directory in the upper fs that must be a separate
subtree from the '/' dir in the upper fs.
So you would have to make every squashfs writable first by overlaying it
with a tmpfs. And then add it to the existing stack. We combine 8 images atm
in Factory, so that would be about 16 overlay mounts. Plus you cannot easily
unmount parts of this beast as any process rw-opening a file and holding it
open (say, even some log or tmp) will block the umount. Plus anything you
logged into log files will be lost when you unmount the upper level.
This construction seems to be too impractical to me.
= conclusion =
Not yet.
Steffen
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
This email is automatic generated from yast CI node. It lists of pull requests that have no activity more then three working days. If your module is listed, please check all pull request, why they are not merged yet.
Pending requests in repository yast-autoinstallation:
- For SLE12-SP1: load release notes of extensions also during AutoYaST (bnc#893586) (41 days)
https://github.com/yast/yast-autoinstallation/pull/92
Pending requests in repository yast-bootloader:
- SLE12-SP1: initialize bootloader during update if proposed from scratch (bnc#899743) (57 days)
https://github.com/yast/yast-bootloader/pull/201
Pending requests in repository yast-network:
- Autoyast: do not overwrite firewall settings (7 days)
https://github.com/yast/yast-network/pull/275
Pending requests in repository yast-nis-server:
- Added command line support for Active Slave sync (33 days)
https://github.com/yast/yast-nis-server/pull/6
Pending requests in repository yast-packager:
- SLE12-SP1: initialize bootloader during update if proposed from scratch (bnc#899743) (56 days)
https://github.com/yast/yast-packager/pull/96
Pending requests in repository yast-theme:
- Install scalable icons & fix name of yast-yast-language.* to yast-language.* (153 days)
https://github.com/yast/yast-theme/pull/45
Pending requests in repository yast-yast2:
- Use native Ruby implementations in Yast::URL and Yast::IP (15 days)
https://github.com/yast/yast-yast2/pull/310
Pending requests in repository yast-docker:
- Start making this a gem (114 days)
https://github.com/yast/yast-docker/pull/2
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
I'm working on a backup program which offers the ability for users to
backup a directory based upon mimetypes. Only the mimetypes of choice
will be processed.
Also it offers access via fuse fs to different versions/snaphots of files, like:
sbon [ /srv/backupbtrfs/mount/home/sbon/Projects/fuse/fuse-backup ]$
ls -al fuse-backup-opendir.c
total 23
drwxr-xr-x 2 sbon users 11 Jan 28 14:56 .
drwxr-xr-x 67 sbon users 4096 Jan 27 19:22 ..
-rw-r--r-- 1 sbon users 14041 Jan 23 10:51 201501231350
-rw-r--r-- 1 sbon users 14137 Jan 25 18:06 201501251807
-rw-r--r-- 1 sbon users 14192 Jan 25 23:30 201501252251
-rw-r--r-- 1 sbon users 14210 Jan 26 00:06 201501260032
-rw-r--r-- 1 sbon users 14516 Jan 26 15:57 201501261554
-rw-r--r-- 1 sbon users 14295 Jan 26 15:59 201501261559
-rw-r--r-- 1 sbon users 15681 Jan 27 15:50 201501271440
-rw-r--r-- 1 sbon users 15775 Jan 27 17:53 201501271553
-rw-r--r-- 1 sbon users 15775 Jan 27 18:11 201501271754
-rw-r--r-- 1 sbon users 16244 Jan 27 19:09 201501271816
-rw-r--r-- 1 sbon users 16287 Jan 27 19:22 201501271919
This shows the different versions of the file fuse-backup-opendir.c in
/home/sbon/Projects/fuse/fuse-backup.
Note that in this fuse fs a file is presented as a directory. This is
required to show the different versions as files in this
directory.
Which directory, and with what options, are processed is stored in a
mysql db. It uses btrfs to create snapshots, and rsync to synchronize
the directory with the backup.
My intention is to create a plugin/extension for filemanagers to get
easy access to these versions in a very userfriendly manner.
I know snapper offers also backup functionality, and I would like to
test it. I've got a recent linuxfromscratch system, so familiar with
building from source. Is snapper also possible on other systems than
opensuse?
Stef Bon
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
We have just added some RSpec extensions to yast-ruby-bindings (>=3.1.28).
As explained in [1], you just need to require "yast/rspec" and you will
have some goodies available in the tests, like the shortcuts we all know
and love (for creating paths, terms and UI elements) and a
#change_scr_root method to safely chroot the tests (with automagic
management of the open SCR instance). Refer to the already mentioned
documentation for a detailed description and to this commit[2] for some
real life examples.
Enjoy.
As usual, the hardest part was having a starting point. Now it's time to
look forward and add more functionality there. What do you miss when
writing YaST tests? Which code do you find repeated over and over in
YaST tests?
Cheers
[1] http://www.rubydoc.info/github/yast/yast-ruby-bindings#Testing
[2]
https://github.com/yast/yast-yast2/commit/b7808cf4d9236e5d1755621f962810735…
--
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
This email is automatic generated from yast CI node. It lists of pull requests that have no activity more then three working days. If your module is listed, please check all pull request, why they are not merged yet.
Pending requests in repository yast-autoinstallation:
- For SLE12-SP1: load release notes of extensions also during AutoYaST (bnc#893586) (40 days)
https://github.com/yast/yast-autoinstallation/pull/92
Pending requests in repository yast-bootloader:
- SLE12-SP1: initialize bootloader during update if proposed from scratch (bnc#899743) (56 days)
https://github.com/yast/yast-bootloader/pull/201
Pending requests in repository yast-installation:
- SLE12-SP1: allow keyboard layout testing in language dialog (bnc#889549) (54 days)
https://github.com/yast/yast-installation/pull/248
Pending requests in repository yast-network:
- Autoyast: do not overwrite firewall settings (6 days)
https://github.com/yast/yast-network/pull/275
Pending requests in repository yast-nis-server:
- Added command line support for Active Slave sync (32 days)
https://github.com/yast/yast-nis-server/pull/6
Pending requests in repository yast-packager:
- SLE12-SP1: initialize bootloader during update if proposed from scratch (bnc#899743) (55 days)
https://github.com/yast/yast-packager/pull/96
Pending requests in repository yast-theme:
- Install scalable icons & fix name of yast-yast-language.* to yast-language.* (152 days)
https://github.com/yast/yast-theme/pull/45
Pending requests in repository yast-yast2:
- Use native Ruby implementations in Yast::URL and Yast::IP (14 days)
https://github.com/yast/yast-yast2/pull/310
Pending requests in repository yast-docker:
- Start making this a gem (113 days)
https://github.com/yast/yast-docker/pull/2
--
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'd like to discuss one Travis feature here.
Currently all Travis steps described in .travis.yml are executed
regardless whether something fails or not.
The problem is that if any step in the middle fails then it's quite
hard to find the issue as the logs are usually very long.
For example the yast2 log has over 4500 lines [1].
The question is whether we want to switch to the fail fast principle [2],
so the Travis build would stop at the first failure and you could easily find it at
the end of the log. (Travis does not support failing fast out of box, but there is a
workaround for this [3].)
Summary:
Current state (always run all steps)
+ can find multiple issues in a single run
- too long log for finding the issues
- may report false positives for dependent steps
(e.g. if compilation fails then obviously the tests fail too)
- longer build times
Fail fast
+ easy to find the failure
+ failed builds finish faster
- you can only see/fix one issue at a time, more iterations for fixing all
issues is needed (e.g. you fix a rubocop style issue, but then the testsuite
does not pass, after fixing it the install step fails because of a missing
change in Makefile... each fix means a new commit and a new build)
What do you think about it? Should we change the Travis behavior?
[1] https://travis-ci.org/yast/yast-yast2
[2] http://en.wikipedia.org/wiki/Fail-fast
[3] https://github.com/travis-ci/travis-ci/issues/1066#issuecomment-32415453
--
Best Regards
Ladislav Slezák
Yast Developer
------------------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: lslezak(a)suse.cz
Lihovarská 1060/12 tel: +420 284 028 960
190 00 Prague 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
On 01/27/2015 10:21 AM, Guido Berhoerster wrote:
> * Raymond Wooninck <tittiatcoke(a)gmail.com> [2015-01-27 09:56]:
>> On Tuesday 27 January 2015 09:44:36 Guido Berhoerster wrote:
>>>
>>> I don't think it is much of an improvement configuring display
>>> manager behavior through /etc/sysconfig/displaymanager while
>>> having to select the actual display manager through some other
>>> mechanism like update-alternatives.
>>
>> The question is if those settings in /etc/sysconfig/displaymanager are still
>> really affecting the how the display manager works. I know that GDM and KDM a
>> lot of their settings are no longer controlled by YaST, but through their
>> respective configuration managers. (e.g. Most of the KDM settings are now
>> controlled by the KDE systemsettings)
>>
>> So this would be a good opportunity to really look how and where we want to
>> configure our display managers and have a final cleanup of these settings.
>
> LightDM reads DISPLAYMANAGER_AUTOLOGIN,
> DISPLAYMANAGER_PASSWORD_LESS_LOGIN, DISPLAYMANAGER_REMOTE_ACCESS,
> DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN, DEFAULT_WM. GDM reads
> DISPLAYMANAGER_AUTOLOGIN,
> DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN, and
> DISPLAYMANAGER_AUTOLOGIN. LXDM reads DISPLAYMANAGER_AUTOLOGIN and
> DEFAULT_WM. With the rest I'm not familiar.
The same information for KDM can be found in the comments of this bug
report (credits to Wolfgang Bauer)
https://bugzilla.suse.com/show_bug.cgi?id=907907
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