http://bugzilla.opensuse.org/show_bug.cgi?id=1047218
Bug ID: 1047218
Summary: trackerbug: packages do not build reproducibly from
including build time
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: All
OS: SUSE Other
Status: CONFIRMED
Severity: Normal
Priority: P5 - None
Component: Development
Assignee: bwiedemann(a)suse.com
Reporter: bwiedemann(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: Development
Blocker: ---
See also https://reproducible-builds.org/
and https://reproducible-builds.org/specs/source-date-epoch/
When packages include the current time of build
it results in binaries that differ on every build
and thus trigger rebuilds of depending packages
and are published to mirrors and users
when actually nothing really changed.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1088738
Bug ID: 1088738
Summary: xhost setting fails to have affect in
/etc/gdm/Xsession --- "no protocol specified"
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Major
Priority: P5 - None
Component: GNOME
Assignee: bnc-team-gnome(a)forge.provo.novell.com
Reporter: noah(a)chromakey.io
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
line 154 xhost+ si:localuser ... needs to be in
/etc/X11/xinit/xinitrc.d/what-ever.sh ...
... or maybe somewhere else all I know is that in Xsession it fails to have any
affect ... effectively breaking the X11 gnome access for remote logins/ssh/etc.
I'd expect a lot of bug reports of people angry, confused .. and complaining
about "no protocol specified" errors.
Thanks!
-noah
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1051881
Bug ID: 1051881
Summary: clang can't find libc.so with -m32
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: martin.liska(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Running:
$ clang --version
clang version 4.0.1 (tags/RELEASE_401/final 305264)
$ cat a.c
int main() {}
$ clang -m32 a.c
/usr/bin/ld: skipping incompatible
/usr/bin/../lib64/gcc/x86_64-suse-linux/7/../../../libc.so when searching for
-lc
/lib/libc.so.6: error adding symbols: File format not recognized
clang-4.0.1: error: linker command failed with exit code 1 (use -v to see
invocation)
I've noticed we have openSUSE specific patches:
https://build.opensuse.org/package/view_file/openSUSE:Factory/llvm4/clang-r…https://build.opensuse.org/package/view_file/openSUSE:Factory/llvm4/assume-…
But it does not work properly with -m32. Note the code in DetectDistro.cpp
checks for /etc/SuSE-release, which is legacy. One should use /etc/os-release.
I can fix that after we resolve this issue.
Thanks,
Martin
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1089823
Bug ID: 1089823
Summary: YaST can silently fail to run snapper during
installation
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.0
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Installation
Assignee: yast2-maintainers(a)suse.de
Reporter: fvogt(a)suse.com
QA Contact: jsrain(a)suse.com
Found By: ---
Blocker: ---
Created attachment 767377
--> http://bugzilla.suse.com/attachment.cgi?id=767377&action=edit
y2logs
Installation with the live media and snapshots enabled fails:
https://openqa.opensuse.org/tests/657353#step/await_install/21
This is because snapper is not installed in the installation system, so the
snapper installation-helper is missing.
So YaST needs to add a hard dependency there.
The bigger issue is that YaST didn't care that the binary is not present though
(found in y2log-3):
[libstorage] ActiongraphImpl.cc:584 Commit Action "Mounting /dev/vda2 at /"
[sid:59, first]
[libstorage] SystemCmd.cc:67 constructor
SystemCmd("/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2'
--description 'first root filesystem'")
[libstorage] SystemCmd.cc:186 SystemCmd
Executing:"/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2'
--description 'first root filesystem'"
[libstorage] SystemCmd.cc:187 timestamp [295.985073], 2018-04-17 02:15:45 GMT,
2018-04-16 22:15:45 EDT
[libstorage] SystemCmd.cc:660 Adding Line 1 "/bin/sh:
/usr/lib/snapper/installation-helper: No such file or directory"
[libstorage] SystemCmd.cc:626 pid:4219 added lines:1 stderr:true
[libstorage] SystemCmd.cc:492 THROW: Command not found:
"/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2'
--description 'first root filesystem'"
[libstorage] SystemCmd.cc:416 stopwatch 0.010977s for
"/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2'
--description 'first root filesystem'"
[libstorage] SystemCmd.cc:436 system() Returns:127
[libstorage] SystemCmd.cc:678 stderr:/bin/sh:
/usr/lib/snapper/installation-helper: No such file or directory
[libstorage] SystemCmd.cc:67 constructor SystemCmd("/sbin/udevadm settle
--timeout=20")
As can be seen, YaST notices the error but ignores it. Similar output for step
2.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=952198
Bug ID: 952198
Summary: django-admin does not work, django-admin.py does
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 42.1 RC1 1
Hardware: x86-64
OS: openSUSE 42.1
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Development
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: o.kurz(a)gmx.de
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
observation:
The django tutorial
https://docs.djangoproject.com/en/1.8/intro/tutorial01/
suggests to use the tool "django-admin" with django >= v1.7 which is also
available in Leap but does not work. "django-admin.py" also exists and works
ok.
steps to reproduce:
- "zypper in python-Django python-sqlite" # confirm uninstallation of blocker
package
- "django-admin startproject mysite"
- observe error with python traceback
problem:
unknown so far. Is ist maybe related that python-Django (still) uses python2?
workaround:
- Use django-admin.py which works flawlessly, e.g. example project can be
configured and run:
"django-admin.py startproject mysite && python manage.py migrate && python
manage.py runserver", connect with webbrowser to http://localhost:8000.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1100677
Bug ID: 1100677
Summary: trackerbug: packages do not build reproducibly from
compile-time CPU-detection
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: openSUSE Factory
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Development
Assignee: bwiedemann(a)suse.com
Reporter: bwiedemann(a)suse.com
QA Contact: qa-bugs(a)suse.de
Depends on: 1100520
Blocks: 1081754
Found By: Development
Blocker: ---
e.g. bug 1100520
compiler options -march=native and -mtune=native
make the resulting machine code depend on the build system's CPU
which breaks reproducible builds.
affects at least: glucat form python-annoy legion trigger-rally
This is already fixed in: clpeak higan kyotocabinet
one common approach seems to do
sed -i "s|-march=native||g" $FILE
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1084017
Bug ID: 1084017
Summary: YaST in Leap 15 fails to set boot flags correctly
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.0
Hardware: x86-64
OS: Other
Status: NEW
Severity: Major
Priority: P5 - None
Component: YaST2
Assignee: yast2-maintainers(a)suse.de
Reporter: Larry.Finger(a)lwfinger.net
QA Contact: jsrain(a)suse.com
Found By: ---
Blocker: ---
Created attachment 762755
--> http://bugzilla.suse.com/attachment.cgi?id=762755&action=edit
Compressed YaST2 logs
My system has a GPT partitioning scheme and does not use EFI. I also put the
boot block at the start of the active partition, and have generic boot code in
the MBR. The active partition is indicated with the legacy_boot flag.
A partial df for the system is:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 60213124 9954072 47170668 18% /
/dev/sda6 53826316 32795236 20576144 62% /var/tmp
/dev/sda7 51255784 20631016 28050216 43% /TW
/dev/sda4 60344404 22760752 36522788 39% /Leap42.3
/dev/sda5 711705020 393141448 282387980 59% /home
tmpfs 809360 20 809340 1% /run/user/1000
Looking at the partitions with parted:
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: ATA Samsung SSD 850 (scsi)
Disk /dev/sda: 1024GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot
Number Start End Size File system Name Flags
1 1049kB 9437kB 8389kB bios_grub
2 9437kB 16.8GB 16.8GB linux-swap(v1) swap
3 16.8GB 79.7GB 62.9GB ext4
4 79.7GB 143GB 62.9GB ext4 msftdata
5 143GB 883GB 741GB ext4 msftdata
6 883GB 939GB 56.1GB ext4 msftdata
8 939GB 971GB 31.5GB ext4
7 971GB 1024GB 53.5GB ext4 legacy_boot, msftdata
(parted) quit
In this case, partition number 7 will be booted. Running YaST => System => Boot
Loader changes nothing. If I want the automatic boot to choose Leap 15.0, I
need to manually toggle the legacy_boot flag on partitions 7 and 3.
Attached is a compressed copy of the /var/log/YaST2/ directory.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1027519
Bug ID: 1027519
Summary: Xen: Missing upstream bug fixes
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Xen
Assignee: xen-bugs(a)suse.de
Reporter: carnold(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
There are upstream patches fixing bugs needed for this version of Xen.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1048337
Bug ID: 1048337
Summary: yast2-slide-show need to adjust the install path for
new product builder
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: YaST2
Assignee: yast2-maintainers(a)suse.de
Reporter: mlin(a)suse.com
QA Contact: jsrain(a)suse.com
CC: adrian(a)suse.com
Found By: ---
Blocker: ---
I've tested this in the staging project, I hot-patched yast2-slide-show then
all files are located at /usr/lib/skelcd/CD1 for new product builder, since
DATADIR is obsoleted already then new product builder doesn't have process
those files. you can find testdvd build log at
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:…
so the main question: is product builder still support slideshow? if so where
is the right path it should be?
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=980292
Bug ID: 980292
Summary: Yast shouldn't allow running two instances of module
at once
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: YaST2
Assignee: yast2-maintainers(a)suse.de
Reporter: hguo(a)suse.com
QA Contact: jsrain(a)suse.com
Found By: ---
Blocker: ---
It's very easy to mistakenly double click on a module icon in Yast2, causing
two instances of the module to be started, and there's absolutely no point in
using more than one instance of any yast module.
Please disallow double click on yast2, and prevent more than one instance of
module to be started.
--
You are receiving this mail because:
You are on the CC list for the bug.