March 2016 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] boo#970624 - Package Request: RetroFE
by Dominique Leuenberger / DimStar 13 Mar '16

13 Mar '16

Dear Packager community, A user filed a request for a new package: RetroFE Any volunteer here to pick this up, dig in to the request and provide the package? I'm sure there is somebody out there that wants to scratch that little itch - but don't get lost in hours and hours of gaming arcade games without submitting the package in the end please :) Have a fun day packaging! Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] 'cleaning up' @OBS build of systemd v228 (from Base:System) for opensuse Leap 42.1 ?
by PGNet Dev 11 Mar '16

11 Mar '16

For my needs, Leap release's systemd is too old; TW is not an option for production here. Ideally, I want a current systemd on stable Leap core. To that end, I've managed to get a systemd v228 backport built @ OBS for openSUSE Leap core, https://build.opensuse.org/project/show/home:pgnd:Base:System It installs & boots, lsb_release -rd Description: openSUSE Leap 42.1 (x86_64) Release: 42.1 uname -rm 4.4.5-1.g09dee88-default x86_64 systemctl --version systemd 228 +PAM +AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN This is atm a Xen DomU guest. The build's admittedly currently a bit of a kludge, and there are a number of complaints in dmesg output dmesg | egrep -i "error|fail" | egrep -vi "command line|gssp|log level" [ 0.232413] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM [ 0.232422] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge. [ 5.846273] systemd[1]: systemd-readahead-replay.service: Cannot add dependency job, ignoring: Unit systemd-readahead-replay.service failed to load: No such file or directory. [ 5.846323] systemd[1]: systemd-readahead-collect.service: Cannot add dependency job, ignoring: Unit systemd-readahead-collect.service failed to load: No such file or directory. [ 6.006526] systemd-vconsole-setup[484]: Assertion 'close_nointr(fd) != -EBADF' failed at src/basic/fd-util.c:67, function safe_close(). Aborting. [ 6.041166] systemd[1]: Failed to start Setup Virtual Console. [ 6.046267] systemd[1]: systemd-vconsole-setup.service: Unit entered failed state. [ 6.046281] systemd[1]: systemd-vconsole-setup.service: Failed with result 'signal'. [ 7.618032] systemd-vconsole-setup[632]: Assertion 'close_nointr(fd) != -EBADF' failed at src/basic/fd-util.c:67, function safe_close(). Aborting. [ 7.621518] systemd-vconsole-setup[633]: Assertion 'close_nointr(fd) != -EBADF' failed at src/basic/fd-util.c:67, function safe_close(). Aborting. [ 7.646422] systemd-vconsole-setup[634]: Assertion 'close_nointr(fd) != -EBADF' failed at src/basic/fd-util.c:67, function safe_close(). Aborting. [ 18.346488] systemd[1559]: Failed to enqueue exit.target job: Transaction contains conflicting jobs 'stop' and 'start' for exit.target. Probably contradicting requirement dependencies configured. [ 18.398372] systemd[1575]: Failed to enqueue exit.target job: Transaction contains conflicting jobs 'stop' and 'start' for systemd-exit.service. Probably contradicting requirement dependencies configured. [ 18.443546] systemd[1591]: Failed to enqueue exit.target job: Transaction contains conflicting jobs 'stop' and 'start' for systemd-exit.service. Probably contradicting requirement dependencies configured. [ 18.487434] systemd[1606]: Failed to enqueue exit.target job: Transaction contains conflicting jobs 'stop' and 'start' for systemd-exit.service. Probably contradicting requirement dependencies configured. [ 18.530717] systemd[1621]: Failed to enqueue exit.target job: Transaction contains conflicting jobs 'stop' and 'start' for exit.target. Probably contradicting requirement dependencies configured. [ 362.999814] systemd[2815]: Failed to enqueue exit.target job: Transaction contains conflicting jobs 'stop' and 'start' for shutdown.target. Probably contradicting requirement dependencies configured. none of which are boot-fatal, or have caused any problems on the running guest -- that I've noticed. Yet. The project branches pkgs mainly from Base:System, with a couple additional repos sourced. I'd like to get this build as "clean & robust" as possible for eventual production use, here and for any others interested. Any suggestions re: general cleanup of the project? Glaring problems or omissions? Thanks. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] polkit-unauthorized-privilege
by Andrei Borzenkov 10 Mar '16

10 Mar '16

Where list of allowed privileges is kept? User tries to rebuild current systemd for Leap but keeps hitting [ 261s] systemd.x86_64: E: polkit-unauthorized-privilege (Badness: 10000) org.freedesktop.machine1.host-login (auth_admin:auth_admin:yes) [ 261s] The package allows unprivileged users to carry out privileged operations [ 261s] without authentication. This could cause security problems if not done [ 261s] carefully. If the package is intended for inclusion in any SUSE product please [ 261s] open a bug report to request review of the package by the security team Is there any way to work around it? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3

[opensuse-packaging] Re: [opensuse-factory] Abandoned packages in devel:languages:python3
by Bruno Friedmann 07 Mar '16

07 Mar '16

On lundi, 7 mars 2016 13.46:42 h CET Todd Rme wrote: > Several packages in devel:languages:python3 are not building due to > incompatibilities with the current version of their dependencies. > These packages are apparently abandoned upstream, having no upstream > activity in at least a year. With the release of upcoming switch to > python 3.5, these will likely stop working entirely. You mean you will create a Staging repo and test 3.5 build and fix there, or for the sake of the community, you just want to go the hardway and destroy dlp3 ? Now a question arise, we (community) have to bother still about python2 and python3 equivalence ? So if a fix is made in python3 package, how to backport this one to the python dlp repo? Did we still have to manually work on 2 specs 2 sources in 2 differents repositories, or there's a plan to merge everything back and use only two spec but one source? If Fedora is able to build all its python package with only one spec why we are not able? > I would like to remove them from the repo one week from today (next > Monday). So if you need these packages, please either copy them to > your home repo or patch them to get them working properly. Hard to do when they already have been removed no? > The packages: > > python3-PyAVM - no release or upstream activity in one year > python3-South - no release or upstream activity in more than a year, > upstream website is gone Those two were building and working perfectly on a TW. I use them everyday ... > python3-pyramid_handlers - no release or upstream activity in 3 years > python3-pyramid_zcml - no release or upstream activity in one year You want to do this next week, but you already remove them. Some code still work as expected, perhaps that's how some others define mature? Please reinstance those package and bring me as bugowner and maintainer as I've asked those status during first submit. It would be also cool to warn people on -packaging list next time ;-) At least to drive interested people to the right thread. Okay we can't for the moment use the wiki to create a page, and build a constructive discussion about the plan, communicate about it in advance, and get feedback. I'm certain your plan seems perfect from your point of view, but reality is not. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Lost packages in d:l:p3
by Bruno Friedmann 07 Mar '16

07 Mar '16

Suddenly I saw that there's (at least) 2 missing package in devel:languages:python3 python3-pyramid_zcml python3-pyramid_handlers They have been there since a few months. and now they didn't exist anymore. I've tried with the web interface to check at which time and why they disappear without success. Is there a efficient way to ask api.opensuse.org with osc ? -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 5

[opensuse-packaging] Bruno -- FGLRX Patches?
by Chris Punches 07 Mar '16

07 Mar '16

Bruno, Hey, you don't know me but I'm working with a team of people to get fglrx working/patched across several distros. We have heard that you have this building with modern kernels and Xorg versions, particularly Crimson, and could use some help analyzing the patches you are using to get it to work. We have some work done on a set of patches of our but think we can save a great deal of time and troubleshooting by reaching out to whoever is writing the patches for fglrx in OpenSUSE based on its success. I could take the patches apart and go line by line but this will take much longer without someone explaining which parts are SUSE-specific or which parts fix what problems-- we're not sure if you're the right guy to reach out to, but I see you are listed as the package mantainer -- if you could please point me to the author of the patches used for that package I'd greatly appreciate it. We are looking for a recent Crimson/fglrx, recent kernel, recent xorg combination or any information/pitfalls or patch breakdown we can get our hands on. We have spent quite a bit of time trying to track down the right people for the SUSE packages on IRC to not much avail and I literally have a team of about 8 people doing almost nothing but wait for your reply to this email lol -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 4

[opensuse-packaging] Making mapserver 6 and 7 co-installable
by Bruno Friedmann 05 Mar '16

05 Mar '16

Hi dear rpm'ers! Since always, having an upgrade in Mapserver ( mapserver.org ) can be a real pain when the syntax of the mapfile change creating breakage in serving your map. Making the changes take always a maximum of time. And sometimes you could have an old project that will be retired in two months, when you want to start a new one on the newer version right now ;-) Wouldn't be a dream to have both the newer and old (still bugfix and security release) available at the same time ? Read below, this become near a reality. Last week, during TOSprint in Paris organized by osgeo, I've been enough lucky to spend my time with upstream mapserver. And the request of being able to have all the supported version would be a nice to have from upstream point of view. I've took the challenge ;-) Here's the news. Starting with the bad ones, mapscript part is lacking maintainers, and/or fundings. It should be considered already deprecated, and in a near future if there's no changes it could be move to /dev/null. If you use it, especially in a professional context I would like to invite you to take contact with mapserver. Due to this lack of maintenance, mapscript modules (java,perl,php,python) are not able to have a versionned lib. As such there's no way to have 2 mapscript installed from differents versions. The good news, actually I've been able to build mapserver6 (6.4.3) and mapserver7 (7.0.1) packages which works smoothly here. https://build.opensuse.org/package/show/home:bruno_friedmann:branches:Appli… https://build.opensuse.org/package/show/home:bruno_friedmann:branches:Appli… Before sending them to Application:Geo I would propose a period of review to the above project. Getting your feedback there: use this mailing list or obs comment/bug link is important. I'm not 100% satisfied by the java mascript naming libjavamapscript I would prefer to move it to java-mapscript like the others module, but rpmlint on certain plateform like 13.2 just tag it with 10000 badness :-( If you have a better idea for implementation, don't hesitate to speaking, or best, branch and sr ;-) Thanks for your attention. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 4