Customizing repos in 16.0, and zypper repos (lr)

English Open Chat
1

Host ab250: without zypper & repos as normally here configured, instead with openSUSE-repos-Leap installed, but the same actual repos, as typically seen here in the forums when a repo list is presented via copy & paste:

# zypper lr
Repository priorities in effect:                            (See 'zypper lr -P' for details)
      90 (raised priority)  :  2 repositories
      99 (default priority) :  4 repositories

#  | Alias                       | Name                      | Enabled | GPG Check | Refresh
---+-----------------------------+---------------------------+---------+-----------+--------
 1 | FCL-leap                    | FCL-leap                  | Yes     | ( p) Yes  | No
 2 | TDE                         | TDE                       | Yes     | (  ) No   | No
 3 | TDEnoarch                   | TDEnoarch                 | Yes     | (  ) No   | No
 4 | homeEcsosMC                 | homeEcsosMC               | Yes     | (r ) Yes  | No
 5 | openSUSE:repo-non-oss       | repo-non-oss (16.0)       | No      | ----      | ----
 6 | openSUSE:repo-non-oss-debug | repo-non-oss-debug (16.0) | No      | ----      | ----
 7 | openSUSE:repo-openh264      | repo-openh264 (16.0)      | Yes     | (r ) Yes  | Yes
 8 | openSUSE:repo-oss           | repo-oss (16.0)           | Yes     | (r ) Yes  | Yes
 9 | openSUSE:repo-oss-debug     | repo-oss-debug (16.0)     | No      | ----      | ----
10 | openSUSE:repo-oss-source    | repo-oss-source (16.0)    | No      | ----      | ----

typically of little value to problem solving, or

# zypper lr -d
#  | Alias                       | Name                      | Enabled | GPG Check | Refresh | Keep | Priority | Type   | URI                                                                          | Service
---+-----------------------------+---------------------------+---------+-----------+---------+------+----------+--------+------------------------------------------------------------------------------+---------
 1 | FCL-leap                    | FCL-leap                  | Yes     | ( p) Yes  | No      | -    |   99     | rpm-md | http://silk.apana.org.au/rpm-opensuse15-unstable-dev                         | 
 2 | TDE                         | TDE                       | Yes     | (  ) No   | No      | -    |   90     | rpm-md | http://archive.trinitydesktop.net/trinity/rpm/oss160/trinity-r14/RPMS/x86_64 | 
 3 | TDEnoarch                   | TDEnoarch                 | Yes     | (  ) No   | No      | -    |   90     | rpm-md | http://archive.trinitydesktop.net/trinity/rpm/oss160/trinity-r14/RPMS/noarch | 
 4 | homeEcsosMC                 | homeEcsosMC               | Yes     | (r ) Yes  | No      | -    |   99     | rpm-md | https://download.opensuse.org/repositories/home:/ecsos/16.0/                 | 
 5 | openSUSE:repo-non-oss       | repo-non-oss (16.0)       | No      | ----      | ----    | -    |   99     | N/A    | http://cdn.opensuse.org/distribution/leap/16.0/repo/non-oss/x86_64           | openSUSE
 6 | openSUSE:repo-non-oss-debug | repo-non-oss-debug (16.0) | No      | ----      | ----    | -    |   99     | N/A    | http://cdn.opensuse.org/debug/distribution/leap/16.0/repo/non-oss/x86_64     | openSUSE
 7 | openSUSE:repo-openh264      | repo-openh264 (16.0)      | Yes     | ( p) Yes  | Yes     | -    |   99     | N/A    | http://codecs.opensuse.org/openh264/openSUSE_Leap_16                         | openSUSE
 8 | openSUSE:repo-oss           | repo-oss (16.0)           | Yes     | ( p) Yes  | Yes     | -    |   99     | N/A    | http://cdn.opensuse.org/distribution/leap/16.0/repo/oss/x86_64               | openSUSE
 9 | openSUSE:repo-oss-debug     | repo-oss-debug (16.0)     | No      | ----      | ----    | -    |   99     | N/A    | http://cdn.opensuse.org/debug/distribution/leap/16.0/repo/oss/x86_64         | openSUSE
10 | openSUSE:repo-oss-source    | repo-oss-source (16.0)    | No      | ----      | ----    | -    |   99     | N/A    | http://cdn.opensuse.org/source/distribution/leap/16.0/repo/oss               | openSUSE

Both the above are typical examples of what shows up in forums, either none of the (usually) most crucial information (the URLs), or no convenient way, or any way at all, to see a full line without scrolling or a double- or triple-wide display screen and full width browser window. When I wish to evaluate a typical poster’s repos paste, I need to copy it into an editor or other viewer that allows the entire screen(s) width to be used. My head can’t connect beginning to end when I can’t see both ends at the same time: Evaluation blocked.

same host as here in its normal customized state, both the individual repo files, and the repoListColumns = line in zypper.conf (inter alia to make URLs part of default lr output):

# zypper lr
Repository priorities in effect:                                                                (See 'zypper lr -P' for details)
      90 (raised priority)  :  2 repositories
      99 (default priority) :  5 repositories

# | Alias       | Enabled | GPG Check | URI
--+-------------+---------+-----------+-----------------------------------------------------------------------------
1 | FCL-leap    | Yes     | ( p) Yes  | http://silk.apana.org.au/rpm-opensuse15-unstable-dev
2 | NonOSS      | Yes     | ( p) Yes  | http://download.opensuse.org/distribution/leap/16.0/repo/non-oss/
3 | OSS         | Yes     | ( p) Yes  | http://download.opensuse.org/distribution/leap/16.0/repo/oss/
4 | TDE         | Yes     | (  ) No   | http://archive.trinitydesktop.net/trinity/rpm/oss160/trinity-r14/RPMS/x86_64
5 | TDEnoarch   | Yes     | (  ) No   | http://archive.trinitydesktop.net/trinity/rpm/oss160/trinity-r14/RPMS/noarch
6 | homeEcsosMC | Yes     | (r ) Yes  | https://download.opensuse.org/repositories/home:/ecsos/16.0/
7 | openh264    | Yes     | ( p) Yes  | http://codecs.opensuse.org/openh264/openSUSE_Leap/

Here in house, all the repo information I normally care about requires no scrolling to see, without an extra wide terminal window. Names need not be lengthy, because their URLs expound them. The aliases are all equal to the names, all of which are of limited length, so it would add no meaning to lr output to include both. :slight_smile:

I :heart: zypper!

2

But the last output still omits important information, which is needed to properly troubleshoot user issues.

  • is auto refresh enabled (the usual issues when a package versions don’t get found)?
  • is the repo provided/managed by a service (important for the handling in case of duplicates)?
  • which repo has which priority (important when packages are available in different enabled repos)

The most convinient way stays zypper lr -d. In cases when a user have a messed up system with 20 or more repos, it is absolutely no problem for the potential helper to copy the output (that is why we use preformatted text tags here), paste it into a text editor, analyze, respond to the user.

In my humble opinion, when preformatted text is used, it is no issue to scroll sideways or down. If you have a massive amount of data to analyze, simply copy it to a text editor. The forum cannot fulfill the purpose of a data analizing tool like a advanced text editor.

3

True that, in a pasted into a forum help request context, but I did write “here in house”, and I started the post with “customizing”. I didn’t mean for the whole world to replicate what I did. 'Tis here “open chat”. :slight_smile:

4

Ok, i missunderstood your post then, as you explicitely mentioned the forum and browser window.

What terminal under which DE do you use? Still KDE3?

Because as example Konsole under Plasma 6 has a small font size by default, which does not need any side or down scrolling with the full zypper lr -d output. Most modern terminals also have the possibility to change the font size on the fly (shortcut or mouse), so that no scrolling is needed in case the line exceeds the width as example. Additionally Konsole under Plasma 6 has line break enabled by default, which makes scrolling less needed.

That means modern terminals have much more possibilities to customize the output than years ago with the KDE3 stuff.

1 Like
5

@hui, you did ask. :stuck_out_tongue: I use Konsole3 and TDE’s Konsole most of the time on installations other than my primary, including in most of my few remaining Plasma sessions (3 remaining on TW, 2 on SR, 4 in Mageia & 1 Neon). In the K3s, optimal font size is selected first, then rows and columns, meaning window size is consequent when not maximized, and text size, numero uno in legibility, is locked on legibly right size. Plasma4 and later omit the Midnight Commander sessions I’m rarely without in any tabbed X terminal on tab 2, so in Plasma must be opened anew on each K4+ session start whether session had been saved or not, while neither can remember either of the directories MC was in last either. When in other session types (all minimally used), where K3s are not normally available I typically have lxterminal installed in e.g. IceWM, or whatever in XFCE or other X session types is called the native GUI X terminal. The FCL repo you see in OP is the source of File Commander/L, filecommander by package name, fcl by binary. I configure it to use somewhere between 100% and 96% of available desktop space in manner similar to MC, but with a significantly different set of hotkeys, shortcuts and built-ins. It’s my primary alternate to K3s in GUI sessions, but there’s yet another well used alternate here, the vttys themselves. I spend a lot of time in them with MC on 2 and plain bash on 3, where font size results according to video= cmdline parameter, which I specify according to screen size and resolution of whichever display(s) are connected, leaving the actual font used up to the kernel and whatever impact /etc/vconsole.conf has by default. To the end of resolution and thus text size selection I use the E key in Grub2 a lot on UEFI PCs. With Grub Legacy GFXBoot, master bootloader on all non-UEFI PCs here, edit mode is employed by default just like in 10.2 or so and later, except configured to 100% instead of random. I :heart: my GFXBoot penguin. :slight_smile:

In others’ environments that may well be, but not so much here with text big enough to read without eyestrain, with my back against the back of my chair, and all that CSS/JS-forced whitespace wasteland left and right of actual content.

No problem for most others I suppose, but not so much here, where most windows use most or all the desktop, and that editor window is occupying most or all of a different virtual desktop, making quick scanning back and forth to the related post text or reply composition area inconvenient at best.