Re: Bug#847366: gtk apps die with 'Couldn't open libGL.so.1'

[Cyril Brulebois]

Hi Simon,

Simon McVittie  (2017-01-21):
> Control: tags 847366 + patch
> 
> On Fri, 20 Jan 2017 at 17:45:56 +, Simon McVittie wrote:
> > Upstream say this is the wrong answer. Using Gtk without GL is *meant*
> > to work - the problem is that one of the initialization calls is
> > unconditional (upstream:
> > ) and will abort
> > if there is no GLX library available.
> 
> Patch attached, also in pkg-gnome svn, and seems to work fine (tested
> with gtk3-demo in a chroot with no Recommends installed, and Xephyr
> outside).
> 
> debian-installer developers: assuming you don't want a libgl1-udeb,
> you will need either this fix applied to gtk+3.0, or GDK_GL=disable
> in the environment whenever you run GTK apps. Either one should work.

This is great news! I was thinking about gtk2 vs. gtk3 just a few days
ago (a cron told me libgtk-3-0-udeb was installable again), and was a
bit annoyed with our recurring inability to move towards gtk3 without
the GL thing fixed (indeed, pulling libgl in d-i seemed a bit heavy…;
and there were quite a bunch of unmet dependencies in the past; patches
have existed for cdebconf + gtk3 for quite a while).

Maybe we'll be able to handle this at the beginning of the stretch
release cycle. :)


KiBi.


signature.asc
Description: Digital signature

Re: Thoughts on os-prober 2.0

[Cyril Brulebois]

Hi Colin,

and thanks for the write-up.

Colin Watson  (2017-01-21):
> I think this part could be represented as YAML without too much trouble.
> We'd have a list of probes giving the parsers they need, some
> conditions, and templates for their output, perhaps with some kind of
> include arrangement for subtests.  The engine would iterate over the
> tests, running parsers on demand, and use the first probe whose
> conditions are satisfied.  This would be easy to test: since this would
> be separate from device manipulations, we could feed it a directory tree
> and/or some simulated parser output and let it go from there.
> 
> The existing documented command-line interface would be preserved
> exactly as it is.  The only integration issue for d-i would be that we'd
> need a libyaml udeb, which shouldn't be a big deal (os-prober is only
> used quite late, when it's used in the installer environment at all).
> 
> Does anyone object to this outline plan, or have other considerations I
> haven't taken into account?  I propose to prototype this in Python (in
> my copious free time of course ...) and then translate it to C once the
> general shape of things is working.

I'm very much in favor of having maintainable and testable things, so
all of this looks good to me. There are a bunch of other areas where
having something better than just shell fragments would be better, and
maybe having python bits in the installer came up a few times in the
past, even if it wasn't entirely clear whether that would work nicely
(I think some comments were made about the python* upload frequency but
I can't recall the exact details).

IIRC partman and grub-installer are examples of items which could
benefit from this.

Anyway, I'm drifting here. Thanks so much for the heavy os-prober bug
fixing, and for the proposed plan. All in!


KiBi.


signature.asc
Description: Digital signature

Bug#852260: Missing build-dependency on palo for hppa

[James Clarke]

Source: debian-installer
Version: 20170112
Severity: wishlist
Tags: patch

Hi,
After applying #852215, building on hppa fails because palo is needed to
build the images. With the attached patch as well, I can successfully
build on hppa.

Regards,
James



-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 39367917637c4c094a1f4989bf9f76d5e7cff2d0 Mon Sep 17 00:00:00 2001
From: James Clarke 
Date: Sun, 22 Jan 2017 21:36:44 +
Subject: [PATCH] Add missing build dependency on palo on hppa

---
 debian/control | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/control b/debian/control
index 70599383c..51680f462 100644
--- a/debian/control
+++ b/debian/control
@@ -99,6 +99,8 @@ Build-Depends:
 #		For all our powerpc boot needs. Well, not really.
 	aboot (>= 0.9b-2) [alpha],
 #		A previous version didn't have netabootwrap.
+	palo [hppa],
+#		Bootloader for hppa machines, to make netboot images.
 	silo [sparc sparc64],
 #		Using silo is problematic since it needs to run as root,
 #		so images that need it are not built by default, but we
-- 
2.11.0

Bug#852215: [Debian-ports-devel] Bug#852215: FTBFS on non-release architectures

[Helge Deller]

On 22.01.2017 17:03, James Clarke wrote:
> As you know, debian-installer does not build on non-release
> architectures, since it tries to build for stretch. Some architectures
> also have some of the needed udebs in the unreleased suite, such as
> sparc-utils on sparc64. The attached patch lets me build on sparc64 even
> after a `dch --release`, and I would assume on other ports architectures
> too. Is this something you would consider applying?

I fully support James request to add this patch.

I haven't yet tested it myself, but d-i doesn't build for hppa (and
the other ports arches) simply because it doesn't pull from unstable/unreleased.
The hppa unreleased suite for example includes d-i packages for
installing the hppa boot loader (which will never be included in
the main suite itself simply because hppa isn't a release arch) and
James patch would fix that.

Please apply this patch. It doesn't influence the release architectures 
at all but helps the non-releases architectures a lot.

Thanks,
Helge

Bug#852158: Preseeding debconf/priority causes main menu to display

[Philip Hands]

Josh Triplett  writes:

> Package: main-menu
> Severity: normal
>
> I'd like to use preseeding to pre-answer some questions in the
> installer, while leaving others for the user to answer, including
> questions asked with priority "high".  Using "auto url=..." sets the
> priority to critical, so I tried including the following in my preseed
> file:
>
> d-i debconf/priority high

Not a direct answer to the question you're asking, but you can get what
you want without having to preseed the priority back down again.

The 'auto' target is a shortcut that adds priority=critical and
auto=true so if you don't want the priority setting just add 'auto=true'
as well as the url setting to the normal target (IIRC 'install'), so:

  install auto=true url=...

I can imagine that you might still want to be able to preseed the
priority without provoking the menu to appear though, so that may not
actually address your issue.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#852215: [Debian-ports-devel] Bug#852215: FTBFS on non-release architectures

[John Paul Adrian Glaubitz]

On 01/22/2017 05:21 PM, James Clarke wrote:
>> Pulling packages from unreleased into main sounds like a bad idea, those
>> architectures would better have their own unreleased and
>> differently-versioned debian-installer IMO.
> 
> It's still main, just unreleased/main rather than unstable/main. It may not be
> ideal, but 1. it has no effect on release architectures 2. the one-off change
> means porters don't have to keep a fork of debian-installer updated, which is
> effectively how it is now, and that's clearly not working out very well either
> given the lack of installer images for most ports. I've re-Cc'ed
> debian-ports-devel; perhaps others have ideas for how to resolve this.

I agree with James. unreleased simply exists to be able to keep additional
packages for Debian Ports architectures. It's not any less trustworthy than
the regular unstable archive for Debian Ports.

On the other hand, having a working Debian Installer for Debian Ports would
be a huge step forward and would open up Debian Ports to all the users which
are currently being kept back by the rather user-unfriendly way of installing
Debian for the Ports architectures.

Also, with this bug fixed, us porters can start working on the remaining issues
more easily as then we would have an easy access to build logs of the latest
builds. (Yes, we have that now as well, but the builds are always failing with
the same problem, there isn't really a point to check the build log for other
issues).

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#852215: FTBFS on non-release architectures

[James Clarke]

On 22 Jan 2017, at 16:09, Julien Cristau  wrote:
> On Sun, Jan 22, 2017 at 16:03:20 +, James Clarke wrote:
>> Package: debian-installer
>> Version: 20170112
>> Severity: wishlist
>> Tags: patch
>> X-Debbugs-Cc: debian-ports-de...@lists.alioth.debian.org
>> 
>> Hi,
>> As you know, debian-installer does not build on non-release
>> architectures, since it tries to build for stretch. Some architectures
>> also have some of the needed udebs in the unreleased suite, such as
>> sparc-utils on sparc64. The attached patch lets me build on sparc64 even
>> after a `dch --release`, and I would assume on other ports architectures
>> too. Is this something you would consider applying?
> 
> Pulling packages from unreleased into main sounds like a bad idea, those
> architectures would better have their own unreleased and
> differently-versioned debian-installer IMO.

It's still main, just unreleased/main rather than unstable/main. It may not be
ideal, but 1. it has no effect on release architectures 2. the one-off change
means porters don't have to keep a fork of debian-installer updated, which is
effectively how it is now, and that's clearly not working out very well either
given the lack of installer images for most ports. I've re-Cc'ed
debian-ports-devel; perhaps others have ideas for how to resolve this.

Regards,
James

Bug#852215: FTBFS on non-release architectures

[Julien Cristau]

On Sun, Jan 22, 2017 at 16:03:20 +, James Clarke wrote:

> Package: debian-installer
> Version: 20170112
> Severity: wishlist
> Tags: patch
> X-Debbugs-Cc: debian-ports-de...@lists.alioth.debian.org
> 
> Hi,
> As you know, debian-installer does not build on non-release
> architectures, since it tries to build for stretch. Some architectures
> also have some of the needed udebs in the unreleased suite, such as
> sparc-utils on sparc64. The attached patch lets me build on sparc64 even
> after a `dch --release`, and I would assume on other ports architectures
> too. Is this something you would consider applying?
> 
Pulling packages from unreleased into main sounds like a bad idea, those
architectures would better have their own unreleased and
differently-versioned debian-installer IMO.

Cheers,
Julien

Bug#852215: FTBFS on non-release architectures

[James Clarke]

Package: debian-installer
Version: 20170112
Severity: wishlist
Tags: patch
X-Debbugs-Cc: debian-ports-de...@lists.alioth.debian.org

Hi,
As you know, debian-installer does not build on non-release
architectures, since it tries to build for stretch. Some architectures
also have some of the needed udebs in the unreleased suite, such as
sparc-utils on sparc64. The attached patch lets me build on sparc64 even
after a `dch --release`, and I would assume on other ports architectures
too. Is this something you would consider applying?

Regards,
James



-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 2f613cea42be62b9a6ca0921fe19de70068b9448 Mon Sep 17 00:00:00 2001
From: James Clarke 
Date: Sun, 22 Jan 2017 15:45:55 +
Subject: [PATCH] Use unstable and unreleased for udebs on non-release
 architectures

---
 build/Makefile |  6 ++
 debian/rules   | 12 
 2 files changed, 18 insertions(+)

diff --git a/build/Makefile b/build/Makefile
index ff1b82bcf..0a5f3654b 100644
--- a/build/Makefile
+++ b/build/Makefile
@@ -643,8 +643,14 @@ sources.list.udeb:
 	echo "deb [trusted=yes] copy:$(shell pwd)/ $(LOCALUDEBDIR)/"; \
 	if [ "$(MIRROR)x" != "x" ]; then \
 		echo "deb $(MIRROR) $(USE_UDEBS_FROM) $(UDEB_COMPONENTS)"; \
+		if [ "$(USE_UNRELEASED)" = 1 ]; then \
+			echo "deb $(MIRROR) unreleased $(UDEB_COMPONENTS)"; \
+		fi \
 	else \
 		gen-sources.list.udeb "$(SYSTEM_SOURCES_LIST)" $(USE_UDEBS_FROM) $(UDEB_COMPONENTS) $(USE_PROPOSED_UPDATES); \
+		if [ "$(USE_UNRELEASED)" = 1 ]; then \
+			gen-sources.list.udeb "$(SYSTEM_SOURCES_LIST)" unreleased $(UDEB_COMPONENTS); \
+		fi \
 	fi) > $@
 	@if [ -e $@.local ]; then \
 		echo "Using $@.local:"; \
diff --git a/debian/rules b/debian/rules
index b3c59e991..3267b4240 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,7 @@
 #! /usr/bin/make -f
 
+RELEASE_ARCHES=amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
+
 ARCH=$(shell dpkg-architecture -qDEB_BUILD_ARCH)
 VERSION=$(shell LC_ALL=C dpkg-parsechangelog | grep ^Version: | cut -d ' ' -f 2)
 DATE=$(shell echo $(VERSION) | cut -d '.' -f 1)
@@ -10,11 +12,20 @@ USE_UDEBS_FROM=unstable
 TRANSSTATUS=
 BOOTMENU_BEEP=n
 else
+ifneq (,$(filter $(ARCH), $(RELEASE_ARCHES)))
 USE_UDEBS_FROM=stretch
+else
+USE_UDEBS_FROM=unstable
+endif
 USE_PROPOSED_UPDATES=0
 TRANSSTATUS=translation-status
 BOOTMENU_BEEP=y
 endif
+ifneq (,$(filter $(ARCH), $(RELEASE_ARCHES)))
+USE_UNRELEASED=0
+else
+USE_UNRELEASED=1
+endif
 
 ARCHIVEDIR=debian/tmp/installer-$(ARCH)
 DESTDIR=$(ARCHIVEDIR)/$(DATE)
@@ -36,6 +47,7 @@ build-images:
 	$(MAKE) -C build all_build stats release \
 		USE_UDEBS_FROM=$(USE_UDEBS_FROM) BUILD_DATE=$(DATE) \
 		USE_PROPOSED_UPDATES=$(USE_PROPOSED_UPDATES) \
+		USE_UNRELEASED=$(USE_UNRELEASED) \
 		TRANSSTATUS=$(TRANSSTATUS) BOOTMENU_BEEP=$(BOOTMENU_BEEP)
 
 build: build-arch build-indep
-- 
2.11.0

Re: dillon: additional build-depends for installation-guide

[Holger Wansing]

Hi,

Samuel Thibault  wrote:
> Hello,
> 
> Peter Palfrader, on Sun 08 Jan 2017 19:51:14 +, wrote:
> > On Sun, 08 Jan 2017, Holger Wansing wrote:
> > > I'm sorry, I have to come back to this again:
> > 
> > Applied,
> 
> Sorry again, we had to change the font to fix japanese, here is a patch.

Now that the build-depends should be fine:
I see that most manual variants are still from build date in 2016.
To be sure everything builds fine now on dillon, probably someone could
trigger a full rebuild of the manual?


Holger

-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/