December 2015 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 954556] New: After upgrading from 13.2 to Leap 42.1, Mercurial chokes on files locally deleted and ignored, but changed on the remote
by bugzilla_noreply＠novell.com 12 Jul '19

12 Jul '19

http://bugzilla.opensuse.org/show_bug.cgi?id=954556 Bug ID: 954556 Summary: After upgrading from 13.2 to Leap 42.1, Mercurial chokes on files locally deleted and ignored, but changed on the remote Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: x86-64 URL: http://users.skynet.be/antoine.mechelynck/vim/vim-tony mec.bundle.bz2 OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: antoine.mechelynck(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I'm not sure if this bug is in the correct Component. It concerns a difference between the Mercurial versions for openSUSE 13.2 and openSUSE Leap 42.1. I'll describe below the problems I had (in a Mercurial repository with local changes) after upgrading to Leap 42.1, and how I solved them (probably not ideally), in the hope that something can be found to make life easier to anyone else running into the same (or a sufficiently similar) problem. FWIW I've uploaded at http://users.skynet.be/antoine.mechelynck/vim/vim-tonymec.bundle.bz2 a full bundle of my local Vim repository, including a clone of the Mercurial mirror at https://bitbucket.org/vim-mirror/vim with local changes. The bundle is 8.8 MiB for a repository occupying about 151 MiB so I didn't attach it to this bug. The tip before I upgraded to Leap 42.1 was the merge commit about 30 changesets from the present tip. The earlier changesets (0 to 7225) are probably not as interesting but I didn't know how else to let you look at it from my point of view. It might be possible to inspect the bundle without unpacking it, by declaring it as a "repository" by means of the -R argument to Mercurial. This past weekend I upgraded to Leap 42.1 and a few hours ago "hg in" displayed 27 new changesets. I tried to "fetch" them but instead of saying "remote changed runtime/doc/tags which local deleted" and asking me if I wanted to download the changes or keep deleted, Mercurial errored out with the new changesets applied, the "old" merge still current, no new merge done, and a message saying that it could not proceed because of a locally ignored file changed on the remote (the deleted file in question). I goofed around some, updated (not easily) to 0 and back to tip, including a couple of manual merges for which Mercurial invoked vimdiff as my preferred merge tool, and finally added one monstrous changeset by hg addremove followed by hg commit. Those "added" files are IIUC files ignored by my locally modified .hgignore on the other unnamed branch. After that I could finally merge my local changes with the monstrous changeset I had just added on top of Bram's official tip. After that I notice that "hg diff" on the locally deleted file does not give the same output as it used to before the upgrade to Leap. Previously it showed a diff between the remote version of the file and /dev/null, which was longish and looked messy, but, well, I used to think that was the way of things, at least with that version of Mercurial. Now it just says: diff --git a/runtime/doc/tags b/runtime/doc/tags deleted file mode 100644 which I find much neater even if it is not visually reversible. I am practically certain that what I did was not the "ideal" thing to do, but it is the best I could find to work around this change of behaviour and still get a working directory tree with which I could compile Bram's version with my local changes (which consist of one feature added and one disabled in src/feature.h, plus .hgignore lines for runtime/doc/tags which is regenerated by "make install" anyway, and for some directories and files not present on the remote, e.g. "shadow" directories allowing me to compile a Huge and a Tiny build in parallel from the same source with different config settings passed as environment variables). I hope Mercurial won't choke again the next time new changesets are added at the remote and I try to apply them. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 956262] New: cobbler dependencies.
by bugzilla_noreply＠novell.com 11 Jul '19

11 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=956262 Bug ID: 956262 Summary: cobbler dependencies. Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: osynge(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- The applications: cobbler-2.6.6-3.8.noarch cobbler-web-2.6.6-3.8.noarch Are separately packaged hence "cobbler" should not depend on apache. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 935339] New: gpgme fails to cleanly uninstall: install-info: No such file or directory for /usr/share/info/gpgme.info.gz
by bugzilla_noreply＠novell.com 05 Jul '19

05 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=935339 Bug ID: 935339 Summary: gpgme fails to cleanly uninstall: install-info: No such file or directory for /usr/share/info/gpgme.info.gz Classification: openSUSE Product: openSUSE Factory Version: 201505* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: gp(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Uninstalling gpgme, I get the following: 1 package to remove. After the operation, 355.3 KiB will be freed. Continue? [y/n/? shows all options] (y): y (1/1) Removing gpgme-1.5.5-1.1 .........................................................................................................[done] Additional rpm output: install-info: No such file or directory for /usr/share/info/gpgme.info.gz warning: %postun(gpgme-1.5.5-1.1.x86_64) scriptlet failed, exit status 1 # rpm -ql gpgme | grep info /usr/share/info/gpgme.info-1.gz /usr/share/info/gpgme.info-2.gz /usr/share/info/gpgme.info.gz This looks similar to bug #929415 and may have the same fix? -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 925561] New: NetworkManager should provide a way to designate any connection as a mobile data connection
by bugzilla_noreply＠novell.com 03 Jul '19

03 Jul '19

http://bugzilla.opensuse.org/show_bug.cgi?id=925561 Bug ID: 925561 Summary: NetworkManager should provide a way to designate any connection as a mobile data connection Classification: openSUSE Product: openSUSE Factory Version: 201503* Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Enhancement Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: jrhodes(a)redpointsoftware.com.au QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Apper has an option in it's settings regarding when to automatically download and install updates. Under this setting there's an option "unless I am on a mobile data connection", which supposedly ensures that Apper doesn't download software updates while connected to a mobile (or metered) network. Unfortunately there doesn't appear to be any way in NetworkManager to designate a wireless or wired connection as being a mobile connection, i.e. a connection provided by a wireless hotspot or USB tethered phone. I'd really like to set Apper to automatically download and install updates as soon as they are available (I'm running on openSUSE Tumbleweed, which I believe is just Factory now?), but I can't do this because I occasionally have my laptop connected to my 4G hotspot, and I don't want to risk having packages download over 4G. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 914681] New: jing doesn't find Saxon extension
by bugzilla_noreply＠novell.com 01 Jul '19

01 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=914681 Bug ID: 914681 Summary: jing doesn't find Saxon extension Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: Other OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: thomas.schraitle(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The jing package is used to validate an XML document with a RNG schema. When installing the jing package and running it without any options, you get: ----------------- $ rpm -q jing jing-20091111-19.1.3.noarch $ jing /usr/bin/build-classpath: error: Could not find saxon Java extension for this JVM /usr/bin/build-classpath: error: Some specified jars were not found Jing version 20091111 usage: java com.thaiopensource.relaxng.util.Driver [-i] [-c] [-s] [-t] [-C catalogFile] [-e encoding] RNGFile XMLFile... RELAX NG is a schema language for XML See http://relaxng.org/ for more information. ----------------- After investigating it, the respective line is this: BASE_JARS="jing xerces-j2 xml-commons-apis saxon xml-commons-resolver" This contains the list of all JAR files which is used by jing. However, "saxon" doesn't exist anymore, it should be "saxon6". The above line should be therefor look like this: BASE_JARS="jing xerces-j2 xml-commons-apis saxon6 xml-commons-resolver" -- You are receiving this mail because: You are on the CC list for the bug.

1 19

[Bug 941235] New: Upgrading to python-virtualenv-12.0.7-2.1 fails: cpio: rename
by bugzilla_noreply＠novell.com 01 Jul '19

01 Jul '19

http://bugzilla.opensuse.org/show_bug.cgi?id=941235 Bug ID: 941235 Summary: Upgrading to python-virtualenv-12.0.7-2.1 fails: cpio: rename Classification: openSUSE Product: openSUSE Factory Version: 201505* Hardware: All OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: robert.munteanu(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When upgrading to Tumbleweed 20150807 I get the following error: (1/1) Installing: python-virtualenv-12.0.7-2.1 ...............................................................................[error] Installation of python-virtualenv-12.0.7-2.1 failed: Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /usr/lib/python2.7/site-packages/virtualenv-1 2.0.7-py2.7.egg-info: cpio: rename error: python-virtualenv-12.0.7-2.1.noarch: install failed error: python-virtualenv-12.0.7-1.3.noarch: erase skipped Installed version is $ rpm -q python-virtualenv python-virtualenv-12.0.7-1.3.noarch -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 947161] New: Attempt the goal to have a default setup without any -32bit packages installed
by bugzilla_noreply＠novell.com 24 Jun '19

24 Jun '19

http://bugzilla.opensuse.org/show_bug.cgi?id=947161 Bug ID: 947161 Summary: Attempt the goal to have a default setup without any -32bit packages installed Classification: openSUSE Product: openSUSE Factory Version: 201505* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- A standard x86_64 machine should not have to pull in any -32bit packages. Those are compatibility layers, generally provided for backwards compatibility with binary-only modules. The goal is to eliminate the installation of *-32bit by default (the goal is NOT to eliminate the presence of the *-32bit packages!) This might actually solve issues like ug 799367 as well -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 901115] New: yast2-network overwrites postfix configuration
by bugzilla_noreply＠novell.com 05 Jun '19

05 Jun '19

http://bugzilla.suse.com/show_bug.cgi?id=901115 Bug ID: 901115 Summary: yast2-network overwrites postfix configuration Classification: openSUSE Product: openSUSE Factory Version: 201410* Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: lmb(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 609975 --> http://bugzilla.suse.com/attachment.cgi?id=609975&action=edit main.cf mods caused by yast2 network After a long time, I used yast2-network to change something in the network configuration of my node. (Changed the hostname.) As a result, my postfix main.cf was overwritten and rendered unusuable. I'm entirely unsure why some of these parameters were touched - why would it unset mailbox_command, set mailbox_transport, unset relay_host? Yes, this was facilitated by me having /etc/sysconfig/mail:MAIL_CREATE_CONFIG="yes" at the default value, but normally, none of the yast2 tools overwrites manually modified files silently, without even creating an in-place backup. Especially since this looks as if unrelated parameters were touched. I might have understood rewriting "mydestination", but the other parameters make absolutely no sense. I'm attaching the diff here - I restored the main.cf from backup. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 917431] New: less doesn't open gzip'ed files unpacked anymore
by bugzilla_noreply＠novell.com 13 May '19

13 May '19

http://bugzilla.suse.com/show_bug.cgi?id=917431 Bug ID: 917431 Summary: less doesn't open gzip'ed files unpacked anymore Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: stephan.barth(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When looking at files with less like ARCHIVES.gz it unpacked it automatically. Since the recent updates this doesn't work anymore: # less ARCHIVES.gz "ARCHIVES.gz" may be a binary file. See it anyway? I tried to debug it a bit with "set -x", which didn't help. The funny thing is, that after issuing "set +x" less works as expected again. Using su (to root for example) breaks it again. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 606436] New: Incorrect VTY charset?
by bugzilla_noreply＠novell.com 09 May '19

09 May '19

http://bugzilla.novell.com/show_bug.cgi?id=606436 http://bugzilla.novell.com/show_bug.cgi?id=606436#c0 Summary: Incorrect VTY charset? Classification: openSUSE Product: openSUSE 11.3 Version: Milestone 6 Platform: All OS/Version: openSUSE 11.3 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: nice(a)titanic.nyme.hu QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/5332 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2 I installed openSUSE 11.3 Milestone 6 in the hungarian language. Interestingly when using the text-mode virtual terminals, (at least) two letters of the hungarian alphabet are displayed incorrectly: I get õ instead of ő, and û instead of ű. This is the same as displaying a hungarian text file (written in iso-8859-2) using iso-8859-1. Isn't it unicode? Or are just the characters wrongly positioned in the charset table? Also see: http://bugzilla.novell.com/show_bug.cgi?id=605575 Reproducible: Always Steps to Reproduce: 1. 2. 3. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 10