Bug#742808: FTR, remaining work for non-root xserver
Hello! I asked on IRC about remaining work and I'm posting this here for the record. 21:47 < bigon> https://bugs.freedesktop.org/show_bug.cgi?id=83849 21:48 < bigon> and then we probably need to move the debconf question that generates Xwrapper.config from the current package to the xserver one to be correct (On top of the patches already posted in the bug report set as a blocker for this one I guess.) Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212211603.ga1...@fatal.se
Bug#748203: file conflicts when building with patches
Hello! The xorg-setuid-wrapper.patch installs usr/bin/X in xserver-xorg-core package, but this file is already shipped by xserver-xorg package apparently. dpkg: error processing archive /var/cache/pbuilder/result/xserver-xorg-core_1.16.1.901-1.1_amd64.deb (--install): trying to overwrite '/usr/bin/X', which is also in package xserver-xorg 1:7.7+7 This is just a friendly reminder to not forget about Conflicts/Replaces once this is ready to go Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212214811.ga2...@fatal.se
Bug#257062: Need any help testing? I have an i8xx in my workstation.
Hi! I have this controller in my workstation and use it daily. $ lspci -d 8086:1132 - :00:02.0 VGA compatible controller: Intel Corp. 82815 CGC [Chipset Graphics Controller] (rev 02) (prog-if 00 [VGA]) Subsystem: IBM: Unknown device 01e2 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- I'm willing to help test any changes if thats needed. Just drop me a mail with instructions and I'll try to help out as much as possible. Thanks for your great work! Regards, Andreas Henriksson
Bug#257062: Need any help testing? I have an i8xx in my workstation.
On Tue, Jul 20, 2004 at 01:53:38AM -0500, Branden Robinson wrote: > > Can you have a look at the X Strike Force HACKING document, particularly > the part of it that talks about building the package from source, and let > us know if you think you can undertake this task? > > http://necrotic.deadbeast.net/xsf/XFree86/HACKING.txt > Hi! Thanks for your mail. I've read the hacking-document and built the xfree86 packages from source. On the other hand I have no clue how to add the new driver. I'm not familiar with the build-system at all and generally know very little about XFree86. ;( I have looked at both the freedesktop.org i915 driver which was mentioned earlier in this bugreport and the xfree86.org driver in cvs that's supposed to support i9xx. Are they the same? Doesn't look like that judging from the different files in each directory. http://freedesktop.org/cgi-bin/viewcvs.cgi/mesa/Mesa/src/mesa/drivers/dri/ http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/drivers/i810/ I was hoping to get some help from the xfree86.org side on the build system but now I don't know if I can use anything from xfree86.org If anyone could help me out on how to add the driver that would be great. I'll investigate further later on but don't really know if I'll manage this task on my own... Regards, Andreas Henriksson
Bug#798594: xserver-xorg-core: tries to overwrite Xwrapper.config.5.gz from x11-common 1:7.7+9
Package: xserver-xorg-core Version: 2:1.17.2-2 Severity: important Dear Maintainer, While upgrading to xserver-xorg-core from experimental I ran into the following issue. Seems to be a missing Replaces: Unpacking xserver-xorg-core (2:1.17.2-2) over (2:1.17.2-1.1) ... dpkg: error processing archive /var/cache/apt/archives/xserver-xorg-core_2%3a1.17.2-2_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man5/Xwrapper.config.5.gz', which is also in package x11-common 1:7.7+9 Regards, Andreas Henriksson
Bug#852614: mesa: Please enable the etnaviv gallium driver on arm
Hello Andreas Boll, thanks for your quick followup. On Thu, Jan 26, 2017 at 01:00:11PM +0100, Andreas Boll wrote: > Sure, but we need to enable etnaviv support in libdrm first. Ok, right. > > On which arm architectures should we enable etnaviv? armel/armhf/arm64 armhf would be the most revelant architecture right now. Soon (if not already) arm64 will likely also be relevant (as the etnaviv driver will grow more support for GC* variants and very old information I have from etnaviv guys is that they thought it would be relatively easy to support the variant that was going to be shipped with imx8, which is arm64). Could go either way on armel I guess, not sure anyone cares. > I guess only on armhf since the kernel has enabled DRM_ETNAVIV only on > armhf. There might be practical issues like kernel config that might not make it possible to enable it on arm64. I don't know. Maybe the kernel settings should be fixed rather than adhering to it though (the etnaviv driver is enabled in the kernel because I asked for it and someone volunteered to enable it in the config, so we might just have to ask for it to be enabled on arm64). > > Do we need to enable the imx gallium driver too? I think so, yes. Regards, Andreas Henriksson
Bug#444457: upstream patch works for me.
Hello! I can reproduce the problem (in another way) on Debian "unstable" (amd64). I can also confirm that the patch[1] posted in the upstream bug report fixes the problem for me. [1]: https://bugs.freedesktop.org/attachment.cgi?id=11896 -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#914911: x11-apps: reproducible build (usrmerge): Embeds full path to mktemp found via PATH
Package: x11-apps Version: 7.7+7 Severity: normal Tags: patch User: m...@linux.it Usertags: usrmerge Dear Maintainer, The reproducible build spotted a difference in your package when built on a usrmerged system vs a non-merged system: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/x11-apps.html It seems x11perfcomp contains the full path of 'mktemp' found via AC_PROG_PATH during build. Since PATH defaults to contain /usr/bin before /bin the found path will be /usr/bin/mktemp on a usrmerged system, since both paths are essentially the same thing there. This is however not desirable on a non-merged system where it needs to be /bin/mktemp. The attached patch fixes the problem by explicitly specifying the default path via MKTEMP environment variable as documented in AC_PROG_PATH documentation. (This is likely a good idea either way, since otherwise hypothetical problems could happen for users building on their system with /usr/local/bin/... or ~/bin/) Regards, Andreas Henriksson -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (400, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages x11-apps depends on: ii libc62.27-8 ii libpng16-16 1.6.34-2 ii libsm6 2:1.2.2-1+b3 ii libx11-6 2:1.6.7-1 ii libxaw7 2:1.0.13-1+b2 ii libxcursor1 1:1.1.15-2 ii libxext6 2:1.3.3-1+b2 ii libxft2 2.3.2-2 ii libxkbfile1 1:1.0.9-2 ii libxmu6 2:1.1.2-2 ii libxmuu1 2:1.1.2-2 ii libxrender1 1:0.9.10-1 ii libxt6 1:1.1.5-1 ii man-db 2.8.4-3 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages x11-apps recommends: pn xbitmaps Versions of packages x11-apps suggests: ii mesa-utils 8.4.0-1 diff -Nru x11-apps-7.7+7/debian/changelog x11-apps-7.7+7+nmu1/debian/changelog --- x11-apps-7.7+7/debian/changelog 2018-03-18 17:07:42.0 +0100 +++ x11-apps-7.7+7+nmu1/debian/changelog2018-11-28 15:22:57.0 +0100 @@ -1,3 +1,10 @@ +x11-apps (7.7+7+nmu1) UNRELEASED; urgency=medium + + * Explicitly set mktemp path via MKTEMP to make build reproducible + on usrmerged vs non-merged systems. (Closes: #-1) + + -- Andreas Henriksson Wed, 28 Nov 2018 15:22:57 +0100 + x11-apps (7.7+7) unstable; urgency=medium * Switch all xorg.freedesktop.org URLs in packaging to https. diff -Nru x11-apps-7.7+7/debian/rules x11-apps-7.7+7+nmu1/debian/rules --- x11-apps-7.7+7/debian/rules 2015-04-30 23:56:55.0 +0200 +++ x11-apps-7.7+7+nmu1/debian/rules2018-11-28 15:22:50.0 +0100 @@ -16,6 +16,12 @@ CONFIG_STAMPS = $(addprefix $(STAMP_DIR)/configure-, $(SUBDIRS)) BUILD_STAMPS = $(addprefix $(STAMP_DIR)/build-,$(SUBDIRS)) +# Make build reprocudible by explicitly setting the path for mktemp. +# AC_PATH_PROG will find /usr/bin/mktemp on usrmerged systems, +# which is undesirable on non-merged systems. The full path +# of mktemp is embedded in the built x11perfcomp script. +export MKTEMP=/bin/mktemp + %: dh $@ --with quilt,autoreconf --parallel
Bug#914911: x11-apps: reproducible build (usrmerge): Embeds full path to mktemp found via PATH
On Wed, Nov 28, 2018 at 03:44:01PM +0100, Andreas Henriksson wrote:
> Package: x11-apps
> Version: 7.7+7
> Severity: normal
> Tags: patch
[...]
Got some feedback. Improved patch attached.
Regards,
Andreas Henriksson
diff -Nru x11-apps-7.7+7/debian/changelog x11-apps-7.7+7+nmu1/debian/changelog
--- x11-apps-7.7+7/debian/changelog 2018-03-18 17:07:42.0 +0100
+++ x11-apps-7.7+7+nmu1/debian/changelog2018-11-28 16:05:57.0
+0100
@@ -1,3 +1,11 @@
+x11-apps (7.7+7+nmu1) UNRELEASED; urgency=medium
+
+ * Pass MKTEMP=/bin/mktemp to configure to fix reproducible build
+on merged-usr vs non-merged systems (x11perfcomp embeds the path).
+(Closes: #914911)
+
+ -- Andreas Henriksson Wed, 28 Nov 2018 16:05:57 +0100
+
x11-apps (7.7+7) unstable; urgency=medium
* Switch all xorg.freedesktop.org URLs in packaging to https.
diff -Nru x11-apps-7.7+7/debian/rules x11-apps-7.7+7+nmu1/debian/rules
--- x11-apps-7.7+7/debian/rules 2015-04-30 23:56:55.0 +0200
+++ x11-apps-7.7+7+nmu1/debian/rules2018-11-28 16:05:51.0 +0100
@@ -30,7 +30,8 @@
dh_auto_configure -D$* -B$*-build -- \
--libdir=\$${prefix}/lib \
--disable-silent-rules \
- MANCONF="/etc/manpath.config"
+ MANCONF="/etc/manpath.config" \
+ MKTEMP=/bin/mktemp
>$@
override_dh_auto_build: $(BUILD_STAMPS)
Re: gdm3: does not start after fresh stretch install
Control: reassign -1 xserver-xorg-video-all Control: retitle -1 gdm3 does not start on fresh stretch install in vbox Hello Daniel Pocock, Thanks for your bug report. On Thu, Jan 12, 2017 at 08:53:19AM +0100, Daniel Pocock wrote: > Package: gdm3 > > Version: 3.22.1-1 > > Severity: serious (Please note that you fubared the pseudo header so only Package was considered.) > > > I installed stretch using the 2017-01-12 netinst installer ISO (in a > VirtualBox VM) and then I installed gnome with > > > apt-get install gnome > > > The desktop fails to appear, the console just flickers continuously. That means you don't have a working graphics stack and gdm can't start (and keeps failing when it gets restarted after crashing). > > I logged in over ssh and tried various things. Eventually I tried > > >apt-get install xserver-xorg-legacy > > > and now it runs and I see the GNOME login screen. The xserver-xorg-legacy is definitely not a dependency of gdm3. (I don't have it installed on my system for example.) Reading the package description makes me think you're using some legacy X driver which needs to depend on this package itself. Could you please provide the /var/log/Xorg.0.log file from your system so Debian X maintainers can see which driver you're actually using? Please also note that gdm itself uses wayland by default, so if it's falling back on Xorg you likely have a system which has non-functional KMS (Kernel Mode Setting). This is likely something you want to have fixed for the future. > > The same problem/solution was observed by another user in this discussion: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801749#25 > > although that bug report appears to be discussing various gdm3 startup > issues so I'm opening this new bug report to focus on this specific issue. Since I'm not sure exactly which package is missing the dependency I'm reassigning it to the meta-package for now. Hopefully once you've provided the X log, the X maintainers can reassign it to the proper package. Possibly it might not even be up to any x driver, but maybe it's just related to using virtualbox. Since vbox guest addons isn't installed by default that's problematic but maybe it's those that needs to have a dependency on xserver-xorg-legacy. Regards, Andreas Henriksson
Bug#852614: mesa: Please enable the etnaviv gallium driver on arm
Source: mesa Version: 17.0.0~rc1-1 Severity: wishlist Dear Maintainer, There's a new (arm) gallium driver in mesa 17 called etnaviv for Vivante GC* GPUs, notably used on the Wandboard (which is an officially supported board by debian: https://www.debian.org/releases/stable/armhf/ch02s01.html.en#armhf-armmp-supported-platforms ) Please consider enabling and shipping it! Regards, Andreas Henriksson PS. A mesa 17 backport to stretch (with etnaviv enabled) would be nice.
Bug#969614: pipewire 0.3 now in experimental, please prep for transition
Hello, The new version 0.3 of pipewire has now landed in experimental. Please prepare your package for the new version and upload it to experimental once ready so we can make progress on #966535. Thanks! Regards, Andreas Henriksson
