Search results for

Re: [opensuse-factory] openSUSE Leap's Next Major Version Number

by Dave Plater

On 22/04/2017 13:37, Richard Brown wrote: > Hi all, > > On behalf of the openSUSE Board and Leap Release Management I am > pleased to announce the next version of openSUSE Leap after 42.3 will > be: > > openSUSE Leap 15 > > As with Leap 42.x, minor releases are expected annually for at least 3 > years, so you can expect a Leap 15.1 to follow, then 15.2 and onwards. > > Obviously this is quite a dramatic change from the current version > number of 42.x, so I will explain what justifies this change in some > detail below. > > First, some history. When we started openSUSE Leap, the version number > was an issue that needed addressing. openSUSE at that time was at > 13.2, but SUSE Linux Enterprise (SLE) was at 12 and heading towards 12 > SP1. > > As the main unique selling point of Leap compared to every other > distribution is the fact it is based on SLE sources. We wanted to > reflect that in the version number. > This was particularly important when you consider that a major version > in SLE really means something ("major architectural changes from the > last version are introduced here") whereas minor versions/service > packs have a very different message ("easy to upgrade to, no major > workflow breaking changes"). Leap follows a similar philosophy, so we > wanted a versioning scheme to reflect SLEs. > > But openSUSE had already had versions starting with 12, so we couldn't > sync up with SLE. This is where 42.x came from. It gave us the > opportunity to establish a relationship with SLE versions (SLE Version > + 30 = Leap Version), reflect the major/minor nature of Leap releases, > and avoid clashes with version numbers we'd already used. > The choice of 42 doubled as a humorous nod to hitchhikers guide to the > galaxy and the first version numbers of SuSE Linux and YaST (4.2 and > 0.42 respectively). > > The plan was therefore for the next version of Leap to be 43 with it's > release aligned with SLE 13, followed by Leap 43.1 (with SLE 13 SP1), > Leap 43.2 (w. SP2), etc > > However, like all good plans, things change. > > SUSE have decided that their next version of SLE will be 15, not 13. > > Upon learning of SUSE's plans the Board and Leap release team have > been considering our options. > This included ignoring the changes to SLE and releasing Leap 43 as > planned, at the cost of the link between SLE versions and Leap > versions. > 45 was also considered, as were some frankly hilarious ideas that made > me worry about my own sanity and that of my fellow contributors. > > After considering the pros and cons of all the options however, the > decision has been that Leap 15 will be our next version. > > SUSE's decision to skip SLE 13 and 14 gave us a perfect opportunity to > sync up with SLE versions like we always wanted to originally with > Leap. It's an opportunity we will not be able to take so easily a few > years from now if we continued with Leaps current versioning. > > There are only a few packages in our distribution that reference the > 42.x versioning, and they should be easily handled as part of a zypper > dup, so we are not concerned about this decision impacting users > upgrading. > > We are aware that this decision could be a minor annoyance for users > of Leap with configuration management tools like saltstack and puppet, > but the long term opportunity to simplify such configuration (by being > able to treat SLE and Leap similarly) outweighed our desire to avoid a > 'one-time' effort for people currently handling the overly complicated > situation caused by Leap being at 42.x and SLE being at 12 SPx. > > Packagers should be able to look forward to an easier time of things > as a result of this change. We intend to deprecate the > 0%{leap_version} macro and simplify the current complex nest of > suse_version and sle_versions that can make it very frustrating to > build packages appropriately for Tumbleweed, Leap and SLE. > > 0%{suse_version} should continue to be available as a simple indicator > of the major version of Leap & SLE for packagers (eg, 0%{suse_version} > == 1500 is the expected value for SLE 15 and Leap 15 and all of their > minor versions/service packs). > > 0%{sle_version} should remain as a more precise indicator when > packagers need to handle specific versions of Leap and SLE (eg. > 0%{sle_version} == 150000 is the expected value for SLE 15 & Leap 15, > with 150100 being the expected value for SLE 15 SP1 & Leap 15.1) > > 0%{is_opensuse} will continue for those times when packagers need to > distinguish between Leap and SLE even though they will now more > closely share their versions. > > The above examples and what the future suse_version number will be for > Tumbleweed is not yet final, so expect to see emails from ludwig in > opensuse-factory(a)opensuse.org when they are set. > > Thanks to everyone involved in this so far, I'm looking forward to > seeing what we make out of Leap 15, and even though I cross-posted > this I would like to ask that any followup conversation is kept to the > opensuse-project(a)opensuse.org thread. > > Regards, > > Richard Brown > on behalf of the openSUSE Board > Not once in this message is there a positive reason for this change but in this thread there are many negative marketing effects put forward. This brings to mind the saying "If it ain't broke don't fix it!" Dave Plater -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 years, 9 months

Re: [opensuse-factory] Firefox new upgrades for current Opensuse versions - now sticking to ESR?

by Anton Aylward

On 02/05/17 10:44 AM, Carlos E. R. wrote: > On 2017-05-02 15:59, Wolfgang Rosenauer wrote: >> Am 02.05.2017 um 15:49 schrieb Carlos E. R.: > > >>> A friend has asked me about Thunderbird: apparently upstream has v52, >>> but we are on 45. Maybe it has already been explained on another post? I >>> don't remember. >> >> Tumbleweed or Leap? > > Hum. Leap, I think. > > (I later noticed 52 was on the mozilla repo) Indeed: # zypper info MozillaFirefox Information for package MozillaFirefox: --------------------------------------- Repository: openSUSE BuildService - Mozilla Name: MozillaFirefox Version: 53.0-6.3 Arch: x86_64 Vendor: obs://build.opensuse.org/mozilla Installed: Yes Status: out-of-date (version 53.0-6.1 installed) Installed Size: 103.9 MiB Summary: Mozilla Firefox Web Browser "45" to "53" is a big step. >> For Tumbleweed an update to 52.0 was in the pipeline for two weeks now. >> I think one reason why it was delayed is a failing ppc64 build. (I do >> not even know if it was successful before.) >> For Leap we do not do version upgrades for the purpose of version >> upgrades. Version 52.0 did not bring any additional security fixes >> (which are the main and almost only reason for the version upgrades >> remember) compared to 45.latest. * Mon Apr 17 2017 wr(a)rosenauer.org - update to Firefox 53.0 ......... * Permission notifications have a cleaner design and cannot be easily missed * CVE-2017-5456 (bmo#1344415) Sandbox escape allowing local file system access * CVE-2017-5442 (bmo#1347979) Use-after-free during style changes * CVE-2017-5443 (bmo#1342661) Out-of-bounds write during BinHex decoding * CVE-2017-5429 (bmo#1341096, bmo#1342823, bmo#1343261, bmo#1348894, bmo#1348941, bmo#1349340, bmo#1350844, bmo#1352926, bmo#1353088) Memory safety bugs fixed in Firefox 53, Firefox ESR 45.9, and Firefox ESR 52.1 * CVE-2017-5464 (bmo#1347075) Memory corruption with accessibility and DOM manipulation * CVE-2017-5465 (bmo#1347617) Out-of-bounds read in ConvolvePixel * CVE-2017-5466 (bmo#1353975) Origin confusion when reloading isolated data:text/html URL * CVE-2017-5467 (bmo#1347262) Memory corruption when drawing Skia content * CVE-2017-5460 (bmo#1343642) Use-after-free in frame selection * CVE-2017-5461 (bmo#1344380) Out-of-bounds write in Base64 encoding in NSS * CVE-2017-5448 (bmo#1346648) Out-of-bounds write in ClearKeyDecryptor * CVE-2017-5449 (bmo#1340127) Crash during bidirectional unicode manipulation with animation * CVE-2017-5446 (bmo#1343505) Out-of-bounds read when HTTP/2 DATA frames are sent with incorrect data * CVE-2017-5447 (bmo#1343552) Out-of-bounds read during glyph processing * CVE-2017-5444 (bmo#1344461) Buffer overflow while parsing application/http-index-format content * CVE-2017-5445 (bmo#1344467) Uninitialized values used while parsing application/http-index-format content * CVE-2017-5468 (bmo#1329521) Incorrect ownership model for Private Browsing information * CVE-2017-5469 (bmo#1292534) Potential Buffer overflow in flex-generated code * CVE-2017-5440 (bmo#1336832) Use-after-free in txExecutionState destructor during XSLT processing * CVE-2017-5441 (bmo#1343795) Use-after-free with selection during scroll events * CVE-2017-5439 (bmo#1336830) Use-after-free in nsTArray Length() during XSLT processing * CVE-2017-5438 (bmo#1336828) Use-after-free in nsAutoPtr during XSLT processing * CVE-2017-5437 (bmo#1343453) Vulnerabilities in Libevent library * CVE-2017-5436 (bmo#1345461) Out-of-bounds write with malicious font in Graphite 2 * CVE-2017-5435 (bmo#1350683) Use-after-free during transaction processing in the editor * CVE-2017-5434 (bmo#1349946) Use-after-free during focus handling * CVE-2017-5433 (bmo#1347168) Use-after-free in SMIL animation functions * CVE-2017-5432 (bmo#1346654) Use-after-free in text input selection * CVE-2017-5430 (bmo#1329796, bmo#1337418, bmo#1339722, bmo#1340482, bmo#1342101, bmo#1344081, bmo#1344305, bmo#1344686, bmo#1346140, bmo#1346419, bmo#1348143, bmo#1349621, bmo#1349719, bmo#1353476) Memory safety bugs fixed in Firefox 53 and Firefox ESR 52.1 * CVE-2017-5459 (bmo#1333858) Buffer overflow in WebGL * CVE-2017-5458 (bmo#1229426) Drag and drop of javascript: URLs can allow for self-XSS * CVE-2017-5455 (bmo#1341191) Sandbox escape through internal feed reader APIs * CVE-2017-5454 (bmo#1349276) Sandbox escape allowing file system read access through file picker Correct me if I'm wrong but aren't those "CVE" things security issues ? >> Thunderbird 52.1 which brings additional security fixes was released Looking at "rpm -q --changelog MozillaFirefox" I see quite a few in * Sat Mar 04 2017 wr(a)rosenauer.org - update to Firefox 52.0 (boo#1028391) but not many in-between that and "53.0" -- "There are two primary choices in life: to accept conditions as they exist, or accept the responsibility for changing them". -- Denis Waitley. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 years, 9 months

Re: [opensuse-factory] Re: What's needed for boot? (was Re: Fixing usr merge and boot probs...)

by Anton Aylward

On 12/28/2016 05:40 PM, L A Walsh wrote: > Have you ever built your own kernel? Not since I started using openSuse. Well, maybe. If you 'compile from source", the see above. if you mean buqqer around with mkinitrd to include and omit -- and its a LOT easier with Dracut! -- then yes. > As a start, look at output of: > sudo lspci -k|grep kernel|cut -d: -f2|sort|uniq That needs "grep -i" > That will show you modules that you should *likely* > build into your kernel as they are drivers for _your_ > machine's hardware, though not all of them are needed for > boot. For example, probably don't need network to boot unless > you boot from net. Ah, "probably". If I'm not booting from the net then I cant see why I should. What exception are you thinking of? By the same reasoning, I should be able to eliminate RAID (md and dm), all of CRYPTO/LUKS, and all of USB. Perhaps the serial port can go too. This is only booting this specific machine, its not a generic, portable kernel such as we get on the DVD. What else don't I need? I'm reminded of the scene in book/movie "The Martian" where he's stripping the rocket down to reduce weight. oops, there goes the crash couch! its going to be a rough ride without that. > "lsmod", will show you what modules have been dynamically loaded, > while "ls /sys/module" will show you all modules the kernel > has builtin OR dynamically loaded. Hmm. I (still) can't see where the ext[234] driver is, but I do note that BtrFS requires a few other modules like XOR and raid6_pq. More incentive to go for a ext4 RootFS, eh? >>>> For example, I have >>>> everything except /boot and SWAP on LVM. That includes the ROOTFS. So the LVM >>>> modules needs to be included in initrd. >>>> >>> Yes, the initrd becomes bigger. >>> >> >> Yes, but I absolutely need LVM. >> > --- > Do you need your rootfs to be LVM? I am @#$$%$#@ sick and tired of having the RootFS grow and having to take down the disk and shuffle partitions around. I use the predecessor to LVM on an IBM AID years go and had great joy rearranging a DB@ database for balance and performance across 96 spindles! Oh, joy! oh. tabulations! Having /usr as part of the RootFS is ... not nice. It complicates provisioning. > FWIW, My > 12G root is about half full. I think if I could have /usr on a separate FS as of old and this whole stillness of where the binaries live sorted out, then yes my RootFS would be a LOT smaller. But I don't want to follow your approach; I want to have a system that follows an upgrade path as delivered. > I wanted to minimize software > complexity involved in booting root. I also > wanted to constrain it at the start of the disk to limit > seeks for reading the root files, so it is the 1st > partition with only the 1st half of the disk used > for content (short-stroking), also to limit seek > latency on 15K SAS disks. I recall from the 1970s and 1980s a lot of papers about disk latency, rotational spacing when doing a MKFS, how the Berkeley Fast File System approached that, the idea of inverted FS so that inodes were groups adjacently on single RM02 drives with "/" and "usr" (in the days before we had "/home"). I remember experimenting with a DEC 8-drive controller (but only one data path at a time). It was all quite pointless. Every optimization was promptly outclassed by and advance in the disk technology. When I worked on optical storage, every advance in rewritable magneto-optical was matched by the same advance in plain magnetics. Now we have SSDs that are dirt cheap. My core system, that is without /home (and all my photographs) and the web stuff on /srv (not the least of which is ownCloud for my home WLAN and mobile devices) will fit on a 60G pci-e insert that I can get for less than router cost. Check eBay for example. If I omit /srv and the ~anton/Photographs and ~anton/Movies and ~anton/music then everything including /usr/share can fit, comfortably, on a 120G SSD. I might just do that some time next year. Santa didn't deliver on the SSD :-( So the kind of optimization you talk about becomes irrelevant. My home system has to live by the whim of my free time and what's left over after mortgage and food; you're in a commercial setting. You can probably make budget submission :-) Goodluck! >> Well, there's >> >> * what don't I need if all I'm doing is a regular boot? >> > --- > My initial boot uses 'B'oot mode (i.e.: /etc/rc.d/boot.d, pre-SysD): And in this day and age when openSuse ships with systemd, you have to maintain that by hand. Something I'm not willing to do. [Big snip about using stuff in /etc/rc.d etc etc which I grew up with and to be honest am glad is past. I much prefer systemd.] -- Man is fed with fables through life, and leaves it in the belief he knows something of what has been passing, when in truth he has known nothing but what has passed under his own eye. --Thomas Jefferson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 years, 1 month

Re: [opensuse-factory] Better joint effect in Leap maintenance

by Ludwig Nussel

Marguerite Su wrote: > Firstly, I know Leap is joint effect. That is, some packages are from > SLE and some others are from Factory. Both sides are working great, > "separately". Today I just want to talk about some leaf problems. > > 1. Some packages have different maintainers for the version in Factory > and the version in Leap. > > No explanation. It is the nature of Leap. I wouldn't say it the nature of Leap nor is it a desirable state but it happens. > 2. The maintainers from SLE for Leap is actually unknown from build.opensuse.org > > eg. I am the maintainer for all the lua versions in openSUSE:Factory, > and libplist/libimobiledevice stuff in hardware repository. > > But I don't know who is the maintainer from SLE counterpart. No one > tells me. No where to find. I don't even know SLE has those packages The GNOME team is responsible for those packages. They most likely weren't pulled into the product due to customer demand but rather because the GNOME update in SP2 required them for building. > But when users report bug on bugzilla, everything is assigned to me > because I am the only person they know. sometimes security leaks too > (our security team is brilliant, they care both openSUSE and SLE, but > in different bugzilla IDs) If a package is from SLE nobody demands nor expects you to fix the package for SLE. The security team will assign such bug reports to the SLE maintainer. It could happen though that after evaluating a bug it may be decided to not actually release an update for SLE as the effort (paperwork, QA, etc) outweights the benefit. It may nevertheless be useful to fix the problem in Factory, e.g. via version update to the next upstream version. At that point a bug may end up on your desk. If you then decide to also backport the fix to Leap nevertheless, maintenance and security will not say no to that. > So I take cares of it, interact with the reporter, preparing fixes for > Factory and Leap. I just following the standard procedure for bug > fixes. > > Bang! "Sorry, XXX is from SLE, MR rejected!" > > This message annoys me because the fixes now look like a waste of my time. We'd have to look at a concrete case. Mainenance may indeed reject requests for SLE inherited package. However, usually they would then mirror the update internally and push it through the process so it ends up in Leap nevertheless. > I don't know who to talk now. And the maintainer from SUSE doesn't > know there's a bug here needed to be fixed by him either. If related to security issues feel free to talk to security directly. They know and care for both worlds so will try find a good solution. If in doubt talk to me. > Let's say, even if it is from SLE, what about a bug fix backported > from Factory? By nature, it should be taken care of by Factory > maintainers. > > But you can't touch it at all. Because it will break the "sync" > between SLE and Factory. There's only one-way sync: SLE to Factory. Depending on whether we are talking about a release in development or maintenance the process differs. As outlined above an update for SLE maintenance may get rejected if it's too minor. For a release in development you can submit updates of course. Prepare to have to answer questions in the submit request though. We may also pull the SLE maintainer into the discussion to check if we can e.g. update a package in SLE. > And many times, it just vanished after I reassigned it to SLE > maintainer. (boo#1010089, boo#988491 and more) because Leap is not > their 1st priority, leaving me the person on fire. Well, in the case of lua Jan did prepare an update for SLE actually. It just takes time to pass through the process. The nginx case is different. It's actually not part of SLE but some ancient version was contained in some old add-on. So from Leap PoV it comes from Factory ie responsibility of the server:http/nginx maintainers. > Can you imagine that a security flaw is known by me for one month but > just no way to fix it? mailto:security@suse.de ASAP :-) > 3. People don't know which package is from SLE. > > Release team knows. We don't. Or we can't remember that much even was told. As others have pointed out there is a lookup file that lists the mapping. See also https://en.opensuse.org/openSUSE:How_to_contribute_to_Leap There are also lookup files in the :Update projects as the mapping may change. For example in 42.2 we originally updated some packages compared to SLE but SLE catched up via maintenance update. > 4. There is no clear rule to override packages by the one from different origin. > > In 42.1, I know there's an email sent here, that people who want to > override SLE packages can submit directly from openSUSE:Factory to > openSUSE:Leap:42.1 That was the case for 42.2 and is the case for 42.3. Noone prevents anyone from submitting. Just the level of questions asked and extra reviews needed may change depending on origin and importance of the package :-) Staying in sync with SLE is just one criteria anyways. Independently of that we have to keep in mind that Leap is a stable release. So the default choice usually is to stay with whatever version we already have. > So why not let community maintainers help maintaining SLE to some > extent, in Leap field that can easily/flawlessly go into SLE? To the best of my knowledge you can help with that. It's just not as smooth due to the separate OBS instances. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 years

[opensuse-factory] New Tumbleweed snapshot 20170723 released!

by Dominique Leuenberger

Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here. Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&versio… When you reply to report some issues, make sure to change the subject. It is not helpful to keep the release announcement subject in a thread while discussing a specific problem. Packages changed: apparmor ffmpeg libreoffice (5.4.0.1 -> 5.4.0.2) mpg123 (1.25.2 -> 1.25.3) perl-CPAN-Changes virtualbox (5.1.22_k4.11.8_2 -> 5.1.24_k4.11.8_2) === Details === ==== apparmor ==== Subpackages: apparmor-abstractions apparmor-docs apparmor-parser apparmor-profiles apparmor-utils pam_apparmor pam_apparmor-32bit perl-apparmor python3-apparmor - don't rely on implementation details for reload in %post - add JSON support. Required for FATE#323380. (apparmor-yast-cleanup.patch, apparmor-json-support.patch) ==== ffmpeg ==== Subpackages: libavcodec57 libavfilter6 libavformat57 libavresample3 libavutil55 libpostproc54 libswresample2 libswscale4 - Add 0001-avcodec-apedec-Fix-integer-overflow.patch to address CVE-2017-11399 [boo#1049095] ==== libreoffice ==== Version update (5.4.0.1 -> 5.4.0.2) Subpackages: libreoffice-base libreoffice-base-drivers-mysql libreoffice-branding-upstream libreoffice-calc libreoffice-draw libreoffice-filters-optional libreoffice-gnome libreoffice-gtk3 libreoffice-icon-theme-breeze libreoffice-icon-theme-galaxy libreoffice-icon-theme-hicontrast libreoffice-icon-theme-sifr libreoffice-icon-theme-tango libreoffice-impress libreoffice-kde4 libreoffice-l10n-cs libreoffice-l10n-da libreoffice-l10n-de libreoffice-l10n-el libreoffice-l10n-en libreoffice-l10n-es libreoffice-l10n-fr libreoffice-l10n-hu libreoffice-l10n-it libreoffice-l10n-ja libreoffice-l10n-pl libreoffice-l10n-pt_BR libreoffice-l10n-ru libreoffice-l10n-zh_CN libreoffice-l10n-zh_TW libreoffice-mailmerge libreoffice-math libreoffice-pyuno libreoffice-writer libreofficekit - Version update to 5.4.0.2: * More fixes from 5.4.0 release branch - Use system based xmlsec1 - Add api keys for google drive to work bsc#1047167 * Copied from chromium ==== mpg123 ==== Version update (1.25.2 -> 1.25.3) Subpackages: libmpg123-0 libmpg123-0-32bit mpg123-esound mpg123-openal mpg123-pulse - Update to version 1.25.3 libmpg123: * Better checks for xrpnt overflow in III_dequantize_sample() before each use, avoiding false positives and catching cases that were rendered harmless by alignment-enlarged buffers. ==== perl-CPAN-Changes ==== - disable perl(version) - obsolete by perl ==== virtualbox ==== Version update (5.1.22_k4.11.8_2 -> 5.1.24_k4.11.8_2) Subpackages: virtualbox-guest-kmp-default virtualbox-guest-tools virtualbox-guest-x11 - File "vbox_fix_for_kernel_4.12.patch" removed as these changes are fixed upstream. - File "vbox_fix_for_kernel_4.13.patch" removed as these changes are fixed upstream. - Version bump to 5.1.24 (released 2017-07-18 by Oracle) This is a maintenance release. The following items were fixed and/or added: VMM: mask the VME CPUID capability on AMD Ryzen processors for now to make certain guests works, for example Windows XP VMM: emulate more SSE2 instructions VMM: properly clear the TF and AC flags when dispatching real-mode interrupts GUI: fixes to make the mini-toolbar work with recent versions of KDE / Plasma (bug #16325) GUI: fixed a potential crash when a VM with multiple screens is running in full screen / seamless mode and a host screen is removed, for example when connecting to the host via RDP GUI: fixed initial size hints for guests which set intermediate sizes before responding (bug #16593) GUI: prevent stopped screen updates or black screen on reboot in a multi-screen setup under certain conditions Audio: many improvements for Windows 10 guests (bugs #15189, #15925, #16170, #16682, #16794 and others) Storage: fixed possible crash when using Intels SPDK API: use the correct file name of the VM machine state if the VM settings directory is renamed, for example during grouping / ungrouping a VM (bugs #16075 and #16745) API: return the correct error code if powering up a VM fails API: video recording did not automatically start at VM start when enabled in the VM settings (bug #16803) API: when relocating a medium, check that the target path is fully qualified EFI: fix for VMs with more than 3504MB RAM (bug #11103) Host-only adapter: correctly determine IPv4 netmasks on Windows hosts (bug #16826) NAT network: properly do the refcounting for starting / stopping the NAT / DHCP services if the NAT network is changed while the adapter network connection type is anything else but NAT network VBoxManage: fixed controlvm videocapfile (bug #16779) Linux / Mac OS X hosts: more fixes for loading shared libraries (5.1.20 regression; bugs #16778, #16693) Linux hosts / guests: Linux 4.12 fixes (bugs #16725, #16800) Linux hosts / guests: reduce the kernel stack consumption for Linux kernels with CONFIG_CPUMASK_OFFSTACK defined Linux hosts / guests: fixes for kernel modules built with gcc-7 (bug #16772) Linux hosts / guests: Linux 4.13 fix (bug #16887) Linux hosts: don't depend on net-tools on newer distributions as this package is deprecated in favour of iproute (bug #16764) Linux hosts: make 2D video acceleration available for older Linux distributions (5.1 regression; bug #16858) Linux Additions: fix for dynamic resizing with Oracle Linux 6 with UEK4 Linux Additions: make Fedora 25 and 26 Alpha work when 3D pass-through is enabled Linux Additions: no longer recommend removing distribution- installed Additions if they are updated to our guidelines - In kernel 4.13, wait_queue_t => wait_queue_entry_t. File "vbox_fix_for_kernel_4.13.patch" patches the source to account for this change. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 years, 6 months

Re: [opensuse-factory] We're all people, after all. [was: Toxic inuslt directed at contributers [was Re: Re: bug 1022830 GTK3 apps not honoring system-wide DPI settings]]

by Andrei Borzenkov

19.10.2017 00:01, Christopher Myers пишет: > It deeply saddens me how terribly human beings treat each other. > > > Christian, you very much owe an apology to the folks you just > lambasted. There is absolutely no excuse for someone to act the way > that you did, Sorry? Christian was wrong in telling someone to behave properly?!? What should he apologize for? > especially over something that, in the grand scheme of > life, matters so very very little. > > > Atri, while I don't use Gnome, I very much appreciate the (often > thankless) effort that you and the other maintainers put in on our > behalf. > > > > > On Wed, 2017-10-18 at 21:35 +0200, badshah400(a)gmail.com wrote: >> Dear Christian, > >> As one of these voluntary contributors to the openSUSE GNOME >> desktop*, >> I am __personally__ offended by the email quoted below, and >> furthermore >> by the board's tolerance of such toxic insult, by essentially >> rewarding >> virulence** with a slap-of-the-wrist "consider yourself warned" >> message. > >> Let's just summarise what the email alleges about me, given that I am >> part of the GNOME team: >> * I want to be an asshole to the whole userbase, >> * So-called "maintainer" who sits with thumb up someone else's arse, >> and >> * A useless prick. > >> In response, you "warned" him. Yeah, much good that will do!!! If >> every >> single one of us gets one chance to spit such insult on someone else >> on >> this ML, I am pretty sure you know how that will turn out. While I >> understand differences in opinion can drive conflict which can >> sometimes straddle the boundary of civil and not-so-civil, this kind >> of >> abuse is not something anyone, let alone the board of a respectable >> community organisation, ought to tolerate. Even. Once. > >> Please consider this my official complaint against this particular >> individual, and against this policy of warn once no-matter-how-bad. > >> * I also voluntarily devote my not-all-that-much free time toward the >> maintenance of several packages in the science and Education >> projects. >> ** No, I won't just accept and move on, in case you are wondering. >> Nobody told me I had to first build the skin of a rhino to contribute >> to an opensource community project. >> *** In case you received my email twice, apologies! My previous >> message >> didn't get through to the list, as far as I can see. >> -- >> Atri B (irc nick: badshah400) > >> On Wed, 2017-10-18 at 14:30 +0200, Christian Boltz wrote: >>> Hi Sergey, >>> >>> Am Mittwoch, 18. Oktober 2017, 10:13:51 CEST schrieb Sergey >>> Kondakov: >>>> Then this "final decision" makes even less sense. It's like >>>> someone >>>> just wants to be an asshole to whole userbase. How the hell it's >>>> a >>>> random user's responsibility to single-handedly fix core >>>> functionality _and_ deal with upstream while these so called >>>> "maintainers", "teams" and paid project leader himself >>>> comfortably >>>> sit with each others' thumbs up their assess ? First take (if you >>>> too >>>> irresponsible to even find/make it yourself) the fix in your >>>> "product" and then deal with upstream yourselves, you useless >>>> pricks >>>> ! >>> >>> Please adjust your tone! >>> >>> Flaming and insulting people won't help you to convince someone to >>> fulfil >>> your wish (quite the opposite). The only thing you improve this way >>> is >>> the chance to get banned from the mailinglist. (Consider this an >>> official >>> warning from the Board!) >>> >>> Please also take a few minutes to read >>> https://en.opensuse.org/Guiding_principles >>> and act in a way that follows our guiding principles. >>> >>> >>> Regards, >>> >>> Christian Boltz >>> -- >>> <sarnold> the old "which is worse, X or Y?" game :) >>> <mancha> which is worse, the which is worse game or recursion >>> jokes? >>> > N��r��y隊Z)z{.��r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.��r�+��0��Ǩrg== >

7 years, 3 months

Re: [opensuse-factory] Next steps for Firefox on TW

by Felix Miata

Christian Boltz composed on 2017-08-12 00:34 (UTC+0200): > BTW: AFAIK Debian ships firefox and firefox-esr. I don't know the details, > but a quick look indicates that they don't have conflicts. I know for > sure [1] that Debian uses /usr/lib/firefox-esr/ paths, so it's likely > that they allow parallel installation. What kind of quick look did you take? It does not look to me like Debian ships in parallel, at least, not through standard repos in its latest LTS release: # grep RETT /etc/os-release PRETTY_NAME="Debian GNU/Linux 9 (stretch)" # apt install firefox firefox-esr Reading package lists... Done Building dependency tree Reading state information... Done Package firefox is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'firefox' has no installation candidate # apt search ire | grep ox | grep -v l10n v firefox-adblock-plus - v firefox-adblock-plus-element-hiding-helper - v firefox-all-in-one-sidebar - v firefox-autofill-forms - v firefox-automatic-save-folder - v firefox-branding-iceweasel - v firefox-certificatepatrol - v firefox-classic-theme-restorer - v firefox-colorfultabs - v firefox-cookie-monster - v firefox-custom-tab-width - v firefox-debianbuttons - v firefox-dom-inspector - v firefox-downthemall - p firefox-esr - Mozilla Firefox web browser - Extended Support Release (ESR) v firefox-esr-adblock-plus - v firefox-esr-adblock-plus-element-hiding-helper - v firefox-esr-all-in-one-sidebar - v firefox-esr-autofill-forms - v firefox-esr-automatic-save-folder - v firefox-esr-certificatepatrol - v firefox-esr-classic-theme-restorer - v firefox-esr-colorfultabs - v firefox-esr-cookie-monster - v firefox-esr-custom-tab-width - p firefox-esr-dbg - Debugging symbols for Firefox ESR v firefox-esr-debianbuttons - p firefox-esr-dev - Development files for the Gecko engine library v firefox-esr-dom-inspector - v firefox-esr-downthemall - v firefox-esr-firebug - v firefox-esr-firegestures - v firefox-esr-firetray - v firefox-esr-firexpath - v firefox-esr-flashblock - v firefox-esr-flashgot - v firefox-esr-form-history-control - v firefox-esr-foxyproxy-standard - v firefox-esr-gnome-keyring - v firefox-esr-greasemonkey - v firefox-esr-https-everywhere - v firefox-esr-iceweasel-branding - v firefox-esr-itsalltext - v firefox-esr-kwallet5 - v firefox-esr-lightbeam - v firefox-esr-livehttpheaders - v firefox-esr-noscript - v firefox-esr-openinbrowser - v firefox-esr-password-editor - v firefox-esr-pdf.js - v firefox-esr-personasplus - v firefox-esr-perspectives - v firefox-esr-pwdhash - v firefox-esr-refcontrol - v firefox-esr-reloadevery - v firefox-esr-requestpolicy - v firefox-esr-sage - v firefox-esr-scrapbook - v firefox-esr-self-destructing-cookies - v firefox-esr-status4evar - v firefox-esr-stylish - v firefox-esr-tabmixplus - v firefox-esr-toggle-proxy - v firefox-esr-treestyletab - v firefox-esr-ublock-origin - v firefox-esr-uppity - v firefox-esr-useragentswitcher - v firefox-esr-webdeveloper - v firefox-esr-y-u-no-validate - v firefox-esr-zotero - v firefox-firebug - v firefox-firegestures - v firefox-firetray - v firefox-firexpath - v firefox-flashblock - v firefox-flashgot - v firefox-form-history-control - v firefox-foxyproxy-standard - v firefox-gnome-keyring - v firefox-greasemonkey - v firefox-https-everywhere - v firefox-iceweasel-branding - v firefox-itsalltext - v firefox-kwallet5 - v firefox-lightbeam - v firefox-livehttpheaders - v firefox-noscript - v firefox-openinbrowser - v firefox-password-editor - v firefox-pdf.js - v firefox-personasplus - v firefox-perspectives - v firefox-pwdhash - v firefox-refcontrol - v firefox-reloadevery - v firefox-requestpolicy - v firefox-sage - v firefox-scrapbook - v firefox-self-destructing-cookies - v firefox-status4evar - v firefox-stylish - v firefox-tabmixplus - v firefox-toggle-proxy - v firefox-treestyletab - v firefox-ublock-origin - v firefox-uppity - v firefox-useragentswitcher - v firefox-webdeveloper - v firefox-y-u-no-validate - v firefox-zotero - p firefoxdriver - Firefox WebDriver support p firejail - sandbox to restrict the application environment p firetools - Qt frontend for the Firejail application sandbox p fusiondirectory-theme-oxygen - Icon theme Oxygen for FusionDirectory p mail-expire - Utility to extract outdated messages from mbox files p xul-ext-firebug - web development plugin for Firefox p xul-ext-firetray - system tray extension for Firefox, Thunderbird, etc. > Do you know the Debian maintainer so that you could ask if/how they > handle the user profile? If not, I can try to get you in contact via the > Debian AppArmor maintainers ;-) -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 years, 6 months

[opensuse-factory] Splitting patterns

by Simon Lees

Hi All, Time for part 2 of the pattern cleanup (i've already put through an SR to update package names and remove packages that don't exist). In this round i am aiming to split the 1 pattern package into several so that A) some patterns can be maintained in there associated devel repo and B) hopefully so that we can share some patterns with SLE (with that in mind maybe we should remove openSUSE from the package names). The following is a suggestion of what I think we (I) should implement, it is of course all up for change and suggestions. With that in mind firstly i'd like to suggest that we drop the following patterns. The following are collections of miscellaneous similar software rather then software that works together to perform a task * devel_ide * misc_server * remote_desktop * voip The following should be dropped for there given reason. * generic_server - (Merge into the console pattern, as these are console tools) * devel_qt4 - (Only 1-2 packages) * non_oss / non_oss_opt - (these could just be merged, between them they recommend gst-fluendo-mp3 and unrar, then suggest 1-2 things) * tabletpc - (drivers should be part of X11) * sw_management - (only contains zypper which is in minimal) * rest_dvd9 - (not used) * rest_promo_dvd - (not used) These patterns are the only ones I'd like to do internal changes to. * base * enhanced_base * enhanced_base_opt * minimal_base * minimal_base-conflicts As was mentioned in the previous thread in SLE we have a "Minimal" and "Base" pattern, i'd like to replace the above with these. Any tools that are currently in enhanced_base/enhanced_base_opt but not in the new base can be moved into "console", console being what gets installed if you select "text mode" in the installer. This will mean that by default text only systems will get a decent set of tools but that users can use the advanced install options to strip back to a more basic system. As has been mentioned minimal and base aren't very descriptive, so I'm going to suggest minimal-appliance (minimal) and minimal-server (base), but I'll post the description of both so someone can suggest something better. Minimal: This is the minimal openSUSE runtime system. It is really a minimal system, you can login and a shell will be started, that's all. It is intended as base for Appliances. Base: This is the base runtime system. It contains only a minimal multiuser booting system. For running on real hardware, you need to add additional packages and pattern to make this pattern useful on its own. The following will stay in system:install:head/patterns-openSUSE but I will possibly rename it to "patterns-openSUSE-base" depending on what people think. * 32bit / 64bit * apparmor/apparmor_opt * console * update_test * x11 * x11_opt * x86 The following patterns were split out of base hopefully to make this more usable for SLES/SLED if thats not possible they could be included in the base package, most of the desktop patterns are here because I couldn't find a better place to put them, system:install:head/patterns-openSUSE-server * dhcp_dns_server * directory_server * file_server * gateway_server * kvm_server * lamp_server * mail_server * print_server * xen_server system:install:head/patterns-openSUSE-desktop * books * laptop * technical_writing * imaging * imaging_opt * multimedia * multimedia_opt * technical_writing The following devel pattern's I couldn't think of a better place for (someone else might be able too) these could also just go in patterns-openSUSE-base as well. system:install:head/patterns-openSUSE-devel-base * devel_basis * devel_kernel * devel_rpm_build * devel_web The "rest" patterns are used to build the iso's there big and annoying so I think they'd be best in there own package system:install:head/patterns-openSUSE-rest * rest_cd_gnome * rest_cd_kde * rest_cd_x11 * rest_core_dvd * rest_dvd I am suggesting that the remaining patterns are all moved to packages in there corresponding devel repos as follows. The idea here is that I won't modify the contents of these patterns but it will make it much easier for the individual maintainers to. devel:libraries:c_c++/patterns-openSUSE-devel-C-C++ * devel_C_C++ GNOME:Factory/patterns-openSUSE-gnome * devel_gnome * gnome * gnome_admin * gnome_basis * gnome_basis_opt * gnome_games * gnome_ide -> rename (gnome-devel-tools, dropping ide patterns) * gnome_imaging * gnome_imaging_opt * gnome_internet * gnome_laptop * gnome_multimedia * gnome_multimedia_opt * gnome_office * gnome_office_opt * gnome_utilities * gnome_yast * sw_management_gnome -> rename gnome_sw_management Java:packages/patterns-openSUSE-devel-java * devel_java KDE:Frameworks5/patterns-openSUSE-KDE * kde * kde_plasma * kde_edutainment * kde_games * kde_ide -> rename to kde_devel_tools * kde_imaging * kde_internet * kde_telepathy * kde_multimedia * kde_office * kde_utilities * kde_utilities_opt * kde_yast * sw_management_kde -> rename to kde_sw_management (could drop, only has libyui-qt-pkg) KDE:Qt5/patterns-openSUSE-devel-KDE (Maybe this should be part of the kde pattern?) * devel_kde_frameworks * devel_kde * devel_qt5 Mono:Factory/patterns-openSUSE-devel-mono * devel_mono devel:languages:perl/patterns-openSUSE-devel-perl * devel_perl devel:languages:python:Factory/patterns-openSUSE-devel-perl (maybe these should be in devel:languages:python?) * devel_python * devel_python3 openSUSE:Tools/patterns-openSUSE-devel-osc * devel_osc_build devel:languages:ruby/patterns-openSUSE-devel-ruby * devel_ruby devel:languages:tcl/patterns-openSUSE-devel-tcl * devel_tcl YaST:Head/patterns-openSUSE-yast * devel_yast * x11_yast * yast2_basis * yast2_install_wf X11:Enlightenment:Factory/patterns-openSUSE-enlightenment * enlightenment M17N:fonts/patterns-openSUSE-fonts * fonts * fonts_opt games/patterns-openSUSE-games * games devel:languages:haskell/patterns-openSUSE-haskell * haskell_platform network/patterns-openSUSE-network * network_admin network/patterns-openSUSE-leechcraft * leechcraft * leechcraft_media * leechcraft_messenger * leechcraft_netutils * leechcraft_office * leechcraft_utilities X11:lxde/patterns-openSUSE-lxde * lxde * lxde_laptop * lxde_office X11:lxqt/patterns-openSUSE-lxqt * lxqt X11:MATE:Factory/patterns-openSUSE-mate * mate * mate_admin * mate_basis * mate_internet * mate_laptop * mate_office * mate_office_opt * mate_utilities LibreOffice:Factory/patterns-openSUSE-office * office - (it only contains libre office anyway) X11:xfce/patterns-openSUSE-xfce * xfce -> X11:xfce * xfce_basis * xfce_laptop * xfce_office That was rather long, congrats if you got to the bottom. Looking forward to your feedback. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

8 years, 1 month

[opensuse-factory] New Tumbleweed snapshot 20170414 released!

by Dominique Leuenberger

Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here. Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&versio… When you reply to report some issues, make sure to change the subject. It is not helpful to keep the release announcement subject in a thread while discussing a specific problem. Packages changed: icu (57.1 -> 58.2) nano (2.8.0 -> 2.8.1) purple-facebook (0.9.0 -> 0.9.3) squid (3.5.24 -> 3.5.25) terminus-bitmap-fonts (4.39 -> 4.40) xf86-video-siliconmotion yast2-dhcp-server (3.2.1 -> 3.2.2) === Details === ==== icu ==== Version update (57.1 -> 58.2) - Update to new upstream release 58.2 * CLDR 30.0.3: + Fix incorrect data for number of Cantonese speakers in China. + Hani_Latn transform was not updated with Unihan 9.0 kMandarin readings. * Time zone database version 2016j * #12815 uspoof_getSkeleton sets backwards-incompatible illegal argument exception * #12825 uspoof_check goes into an "infinite loop" when U+30FB is in an input string * #12832 GreekUpper::toUpper skips the final character on a non-terminated UTF-8 string * #12849 u_strToTitle returns incorrect length if destination is NULL - Update to new upstream release 58.1 * CLDR 30.0.2: For details of the many changes in CLDR, see CLDR 30. Some things to note: * For some combinations of numbering system (arab, arabext, latn) and/or locale (ar, fa, he), there were changes to the bidirectional control characters used with certain symbols (percent, minus, plus), and changes to number patterns (currency and/or percent, including addition of bidirectional control characters in some cases). * Thhe bidirectional controls used for such purposes include U+061C ARABIC LETTER MARK (ALM), which requires use of the bidirectional algorithm from Unicode 6.3 or later. * The time separator for Norwegian locales (nb, nn) was changed to be ':' throughout. * Unicode 9.0: Version 9.0 adds exactly 7,500 characters, for a total of 128,172 characters. These additions include six new scripts, 19 symbols for the new 4K TV standard, and 72 new emoji characters. * Draft Emoji 4.0 data * Emoji updates for word & line breaking * UBiDiTransform/BidiTransform API for convenient transformation of text between different Bidi layouts. * MeasureFormat API for measurement unit display names * Most COUNT and LIMIT enum constants have been deprecated * SpoofChecker: Handling of "whole script confusables" has been removed from ICU, in accordance with its removal from UTS #39 Version 9.0.0 and the removal of the corresponding Unicode data file. * Greek uppercasing ("el" locale ID) removes most diacritics. * More robust locale data loading across ICU implementation code. * Reduced heap memory usage in DateTimePatternGenerator ==== nano ==== Version update (2.8.0 -> 2.8.1) Subpackages: nano-lang - GNU nano 2.8.1: * fix scrolling problems in softwrap mode when double-width characters on row boundaries are involved * show double-width characters as ">" and "<" when split across two rows * move the cursor more predictably (at the cost of sometimes putting it on the second "half" of a character) * avoid creating lines that consist of only blanks when using autoindent * make ^Home and ^End go to the start and end of the file (on terminals that support those keystrokes) * place the cursor better when linting * let the linter ask only once whether to open an included file * add bindings for ^Up and ^Down in the file browser ==== purple-facebook ==== Version update (0.9.0 -> 0.9.3) - Update to version 0.9.3 (changes since 0.9.0): * This is now the minimum required version. It fixes connection errors after facebook discontinued support for old versions of facebook messenger for android. While most of the protocol implementation was already above that version, there was a subtle change that broke fetching of sync_sequence_id, and the previously empty MQTT user agent string is now considered an old version too. * Set the MQTT user agent to look like Orca-Android 38.0.0.22.155 Fixes errors when trying to send messages. * Use the new ThreadListQuery hash for seq id only, not for thread queries. * Fixes groupchat join errors. * Send orca-formatted user agent for all HTTP requests too. Fixes "Failed to parse thread information" errors when joining channels. ==== squid ==== Version update (3.5.24 -> 3.5.25) - Update Squid to 3.5.25 * Fix host forgery stalls intercepted being-spliced connections * Native FTP relay fixes, now able to cope with active-mode FTP DATA connections when intercepting FTP traffic. * SSL Bump client fixes. Error responses for issues encountered early in the TLS/SSL handling being sent to clients unencrypted when Squid should have bumped and delivered them encrypted. ==== terminus-bitmap-fonts ==== Version update (4.39 -> 4.40) - Update to version 4.40 * Added 6 combining accents as separate characters. * Added 14 letters with dot above / dot below. * Added partial subscript and superscript: all digits and 11 letters. * Added 30+ math characters, notably large braces, brackets and parens. * Added unicode range 2800-28FF in two variants (br1 and br2). * A few small character fixes. * Altered configure to be a bit more POSIX compliant. * Replaced some obscure (un)install Makefile targets with variables. - Set direct source URL ==== xf86-video-siliconmotion ==== - u_siliconmotion_fix_segfault_on_xorg_server_1.19.patch * fixes segfault at ScreenInit on Xorg server 1.19 (boo#1033528) ==== yast2-dhcp-server ==== Version update (3.2.1 -> 3.2.2) - Fixed a crash at start when the "dhcp-server" package was not installed in the system. The crash happens with the latest yast2-core and yast2-ruby-bindings packages (it is related to the bsc#932331 fix). - 3.2.2 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 years, 10 months

Re: [opensuse-factory] Establishing policy on packages owning files at /etc/alternatives/*

by Todd Rme

On Thu, Aug 11, 2016 at 2:15 PM, Andrei Borzenkov <arvidjaar(a)gmail.com> wrote: > 11.08.2016 18:53, Todd Rme пишет: >> On Thu, Aug 11, 2016 at 11:37 AM, Dominique Leuenberger / DimStar >> <dimstar(a)opensuse.org> wrote: >>> On Thu, 2016-08-11 at 11:32 -0400, Todd Rme wrote: >>>> On Thu, Aug 11, 2016 at 5:41 AM, Stephan Kulow <coolo(a)suse.de> wrote: >>>>> >>>>> On 11.08.2016 11:27, Víctor Cuadrado Juan wrote: >>>>>> >>>>>> Hi everyone! >>>>>> >>>>> >>>>>> >>>>>> I would love to gather some ideas and consensus on this, and >>>>>> ideally, >>>>>> get a policy on how update-alternatives should be used, and have >>>>>> an >>>>>> rpmlint check written/improved so we can start filling bugs per >>>>>> package. >>>>>> >>>>> There is a policy and a rpmlint check for it - so either you report >>>>> bugs or fix the packages. >>>>> There are 61 packages atm hitting this error in Factory. >>>>> >>>>> E.g. >>>>> https://api.opensuse.org/public/build/openSUSE:Factory/standard/x86 >>>>> _64/ctags/rpmlint.log >>>>> >>>>> Greetings, Stephan >>>> >>>> Where is the policy documented? I can't find it. There is an >>>> rpmlint >>>> warning, but it is unclear from the warning how to fix it, since the >>>> packages seem to be doing what the warning requests. >>> >>>> Perhaps it might be helpful to pick an example package that is >>>> violating the policy and explain exactly what needs to be changed to >>>> make it complaint. >>>> >>>> The whole update-alternatives system is pretty cryptic and almost >>>> totally undocumented in the openSUSE wiki from what I have been able >>>> to find. >>> >>> Today I just fixed gtk2 and gtk3, the submissions are: >>> https://build.opensuse.org/request/show/418653 >>> https://build.opensuse.org/request/show/418655 >>> Maybe they serve as indication what was wrong and what is right now >>> >>> AS for the documentation >>> https://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines >>> is the one giving most hints imho >>> >>> Cheers, >>> Dominique >> >> >> Maybe it would be better if I chose an example and explain my source >> of confusion. python3-Cython is the example I have been using for >> other packages, because previously it worked fine with no rpmlint >> warnings: https://build.opensuse.org/package/show/devel:languages:python3/python3-Cyt… >> > > update-alternatives --remove should be in %preun, not in %postun Okay. > >> Let's look at the current warnings: >> >> python3-Cython.x86_64: W: suse-alternative-link-missing /etc/alternatives/" >> The file %{_sysconfdir}/alternatives/$(basename generic-name) is missing in >> the file list. Mark it as %ghost and add it to the file list. >> > > Somehow it fails to parse script. My hunch is, quotes around > update-alternatives invocation ("%_sbindir/update-alternatives") confuse > it. They are not needed anyway - try to remove them. That seems to have fixed the problem, thanks. This is the sort of thing more documentation for update-alternatives on the wiki could help with. >> python3-Cython.x86_64: W: suse-alternative-generic-name-missing " >> The update-alternatives generic name is not in the filelist. Create it as a >> symlink to %{_sysconfdir}/alternatives/$(basename generic-name) and add it to >> the file list. >> >> >> But if you look at the files list, that seems to be exactly what is being done: >> >> %{_bindir}/cygdb >> %{_bindir}/cython >> %{_bindir}/cythonize >> %{_bindir}/cygdb-%{py3_ver} >> %{_bindir}/cython-%{py3_ver} >> %{_bindir}/cythonize-%{py3_ver} >> %ghost %{_sysconfdir}/alternatives/cygdb >> %ghost %{_sysconfdir}/alternatives/cython >> %ghost %{_sysconfdir}/alternatives/cythonize >> >> >> So from the rpmlint warnings I don't know where the policy is being >> violated. Although I am not sure what "$(basename generic-name)" is >> supposed to be, are the names being used in >> "%{_sysconfdir}/alternatives/" wrong? It is hard to tell from the >> example on the wiki since I don't know what files in the example are >> "real" files and which ones are created by update-alternatives. >> -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 years, 6 months

openSUSE Factory search results for query "reproducible-builds"