Re: Bits from the Release Team (Jessie freeze info)
Hi Niels, This was quite interesting as it seems to tie in with some other projects that are already being pursued... On 21/10/13 16:42, Niels Thykier wrote: > I would love for us to have an automated system to give us a > "weather-report" on the toolchain for each architecture. It would be > nice both for us to see how ports are doing and for porters to spot and > fix problems early. That sounds a lot like the purpose of Jenkins[0], but I'm not sure if it's exactly suitable. It seems a little heavy, that someone could more easily be able to script some cron jobs for a task than learn how to use it. And Jenkins isn't available yet on all arches; some ports may not have hardware powerful enough to run it. Maybe that doesn't matter - a single Jenkins instance might be able to launch jobs via remote shells to other boxes, running the actual test suite there, or maybe just to fetch, analyse and report on the resulting log files. Ideally I'd like to see a set of command-line scripts runnable either from cron, or maybe someday by Jenkins jobs if someone wants to set that up. And packaged up for people to use at home! [0]: http://jenkins.debian.net/ > Which implies "a set of packages" being "the current version of the > overwhelming part of the archive" plus all of d-i. However, that is not > something you "just build", so having a smaller set as a basic test > would probably be way more useful. I am not aware of such a "basic test > set", so feel free to propose one. Some people have been trying to identify small sets of essential packages already, in the context of bootstrapping an architecture[1]. I wonder if that's likely to overlap with this? It encompasses toolchain and essential arch-specific packages. I imagine a healthy port should be able to bootstrap itself with only current package versions. If this was being tested regularly it could let porters know if circular dependencies are introduced, for example. [1]: https://wiki.debian.org/DebianBootstrap#Toolchain I would maybe take that a little further and say that a system is only stable if it can bootstrap itself, install and boot into the resulting system, and repeat the whole process again... > I like the "toolchain nightly" thing as well. I don't think it is > "required", but it sounds like the kind of thing that would help people > spot issues sooner rather than later! And this also ties in with the reproducible-builds project[2] (not sure if you were hinting at that before). The 'toolchain' is of particular concern because the security of the whole system depends on it. Differences in the output of builds needs to be avoided, or otherwise explained. It would help greatly if there were frequent builds happening so we could see unexpected changes occurring. [2]: https://wiki.debian.org/ReproducibleBuilds So if something can make something that fulfills all the above goals it would certainly be beneficial :) Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5266df9d.9040...@pyro.eu.org
Re: Bits from the Release Team (Jessie freeze info)
On 22/10/13 23:36, Stewart Smith wrote: > Jenkins can have slaves on remote hosts, via SSH. It runs a small java > app there, so as long as the arch has a JVM then you're pretty right. That may be useful to set up on some arches, for things where Jenkins needs direct control over CPU-intensive tasks. Building and testing d-i, for example. But for this, I would imagine only the test suite needs to run over SSH, and the master Jenkins instance just has to process the output? For the proposed test suite to be as accessible as possible to a new/upcoming port, the barrier to using it ought to be very low. A working JVM is quite a lot to ask, the current openjdk-7 is not even built for mipsel in more. mipsel buildds and porterboxes had only 1GB RAM maximum until now, and that is heavily used already for their current tasks. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: Bits from the Release Team (Jessie freeze info)
On 23/10/13 12:55, Stewart Smith wrote: > Geert Uytterhoeven writes: >> On Wed, Oct 23, 2013 at 12:36 AM, Stewart Smith >> wrote: >>> Jenkins can have slaves on remote hosts, via SSH. It runs a small java >>> app there, so as long as the arch has a JVM then you're pretty right. >> >> For whatever definition of small. I've seen it consuming 1 GiB of >> memory... > > with 'm68k' in your email address your definition of small is likely > much different than my "many years in large scale databases" small :) Come to think of it, it must take a day or more for m68k to rebuild eglibc. This is a more serious problem than resources needed by Jenkins. We can't ask them to rebuild their entire toolchain each night! For the goal of software freedom, it shouldn't be too difficult for anyone to do that, though. We should be trying to make it easier. Maybe it would be permissible for the toolchain test suite to run on a faster platform, and cross-compile, or use any sort of emulation available in Debian free packages. If it were technically feasible for each Debian port to rebuild its toolchain and some essential packages, at least once per week, I think that would be an accomplishment. And the smaller the initial set of packages required to boostrap the process, the better. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On 03/11/13 10:54, Niels Thykier wrote: > Come to think of it; maybe we should have a BTS page for each of the > ports (e.g. a pseudo package in the BTS). We've had this on kfreebsd, due it to having been a release goal: http://udd.debian.org/bugs.cgi?release=jessie_or_sid&merged=ign&fnewerval=7&kfreebsd=1&sortby=severity&sorto=desc&cseverity=1&ctags=1 It uses usertags, but someone has to set those. Porters usually set them on bugs they file; but quite often "FTBFS on kfreebsd" bugs are filed without being tagged or Cc'd to our list, so someone has to periodically look for and tag things. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527665af.2040...@pyro.eu.org
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
Hi, On 05/11/13 18:50, Don Armstrong wrote: > On Tue, 05 Nov 2013, Don Armstrong wrote: >> This sounds like a case where we should turn these usertags into fully >> fledged tags. [Or alternatively, they should just be made usertags under >> the debian-po...@lists.debian.org user or similar.] Either of those sounds good. Fully-fledged tags would be the easiest for most reporters to remember to use, but I wonder if this pollutes the tag namespace. > [Or multiple pseudopackages.] > > Something like i386.ports.debian.org or similar would work, with each > current port getting a pseudopackage, and the maintainer of the > pseudopackage being the ports list. Would that be only for generic issues with a port, not specific to a package? I doubt this would be used much. These bugs might typically be reassigned to kernel packages or eglibc anyway. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527949c5.8040...@pyro.eu.org
Re: A new metric for source package importance in ports
Hi josch! On 27/11/13 17:58, Johannes Schauer wrote: > http://mister-muffin.de/p/Gid8.txt > > One can see that now the amount of source packages which is needed to build > the > rest of the archive is only 383. So, there are 383 packages that share the same, maximum value (in this case 11657) in the second column? > Does anybody see enough value in these numbers for source package importance > in > the light of bootstrapping Debian (either for a new port or for rebuilding the > archive from scratch)? I find the list of 383 packages interesting, at least. I think this closure is what I had in mind[0] for regular testing of ports' toolchains and reproducibility of builds. Because each Debian port depends in some indirect way on the authenticity of these packages. And likewise any toolchain bugs are most critical here. I just didn't think there would be so many packages. Does the list vary by architecture? I see many odd things in here such as 'systemd' and 'redhat-cluster' which would be unavailable if trying to bootstrap a non-Linux port, for example. I also find it interesting to see openjdk-7 listed but not gcj; or even gcc-4.8. Was this computed for jessie or sid? [0]: http://lists.debian.org/5266df9d.9040...@pyro.eu.org Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529688a8.8080...@pyro.eu.org
Init system for non-Linux ports
Hi everyone, "What init system would we like to use by default on the non-Linux ports for jessie?" I hope this question is really as straightforward as it looks, and that we might come to some general agreement much more quickly than the tech-ctte bug! Here are the options I can think of - but let me know if you want something not represented here: 1. stay with sysvinit 2. switch to OpenRC unconditionally 3. switch to Upstart unconditionally 4. switch to Upstart only if Linux uses it by default, otherwise OpenRC 5. further discussion Please rank the above putting your preferred option first, as per Debian's usual Condorcet voting system. This is totally non-binding, I'm most interested in hearing people's ideas, questions, or the reasons for their choices. Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: Init system for non-Linux ports
On 28/01/14 22:31, Steven Chamberlain wrote: > 1. stay with sysvinit I know that would be the least work, but I think we should take the opportunity to switch now to one of the modern init systems. Some package maintainers specifically expressed that they don't want to maintain SysV init scripts for much longer; any other init system at least gives them one alternate syntax. > 2. switch to OpenRC unconditionally > 3. switch to Upstart unconditionally > 4. switch to Upstart only if Linux uses it by default, otherwise OpenRC > 5. further discussion My preferences at the moment would be: 2 4 1 3 5 I really appreciate the recent work toward porting libnih and Upstart, but unless Debian was *fully* behind it I don't think we'd gain much for the additional complexity. The event model seems a key difference to me. It sounds better suited to laptops, portable devices and hot-plugging, whereas for now I think the non-Linux ports still need the robustness and simplicity of a traditional dependency model, even if it lacks speed or some special features. OpenRC is *very* simple code, and BSD-licensed, which I think we could more easily extend to our needs. It works almost well enough already to boot GNU/kFreeBSD, and also inside BSD jails. I've read that it is built and somewhat usable on GNU/Hurd, though I don't know how much more work would be still needed (probably rewrite of the early rcS.d scripts). And whichever one is used for the jessie release, it maybe won't hurt to keep the other one around, built and available to play around with, but unsupported. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: [draft] Debian/Hurd porters position in the default init system debate
Hi, Since you didn't mention Upstart in this draft, may I ask your point of view on it? Is there any prospect/interest in using it on GNU/Hurd? What if it becomes the default, or the second-most popular init system in Debian? Or if it is used by GNU/kFreeBSD for jessie? The main benefit I see could be already-written job files, coming from Debian or Ubuntu, particularly if the package maintainer stops maintaining the sysvinit scripts. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ea6c64.6000...@pyro.eu.org
Re: [draft] Debian/Hurd porters position in the default init system debate
On 31/01/14 10:57, Justus Winter wrote: > 1. Up to this day, Debian/Hurd has never used the current default init > system (sysvinit) but has relied on its own init and rc system. We > are prepared to use a non-default init system in the future. This will become increasingly difficult when SysV init scripts stop being maintained... and in new packages perhaps not provided at all. > 3. We ask that the current sysvinit-compatible init scripts are left > in place, so that we can use sysvinit in the future. Some maintainers want to discontinue providing sysvinit scripts right away. Policy *may* require them to do so for jessie, but likely not for jessie+1. > 4. We acknowledge that there is a maintenance cost involved with > keeping the current init scripts. We will help maintain them as part > of our porting effort. I'd like for this work to be minimised by sharing across GNU/Hurd, kFreeBSD and even with GNU/Linux users who don't want to use the default init system. So, does this mean SysV init scripts are your preferred format? In which case it's not so important for the ports to choose the same init system, since anything can use these. But if for example you'd planned to maintain OpenRC-specific runscripts instead, that would be a reason for kFreeBSD to consider using OpenRC. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52eb9cd7.50...@pyro.eu.org
Re: Init system for non-Linux ports
On 12/02/14 10:45, Robert Millan wrote: > I'm a bit afraid that even if sysvinit itself stays mostly fine, the scripts > written for > it could turn into a bunch of bitrot. There are a few reasons to keep sysvinit scripts maintained for jessie: 1. for smoother upgrades from wheezy 2. in order to backport jessie packages to wheezy 3. for non-Linux (or non-systemd) ports So ports are not the only reason. And yet all of the above points still apply to ports; we'd have to support sysvinit even if we went with something else. I don't think it matters much what we choose, but seems we'd want to make use of legacy sysvinit compatibility - write very few scripts in specific formats (e.g. OpenRC runscripts / Upstart jobs). We probably have right up until freeze to make a preference, and perhaps by then there will be more than one fully-working init system. GNU/Hurd porters already said they aim to maintain sysvinit scripts: https://lists.debian.org/debian-hurd/2014/01/msg00051.html And there are plenty of GNU/Linux users who will want to run systems without systemd. (individuals, derivatives, quite possibly Google). Thinking ahead, package maintainers won't have such need to support sysvinit for jessie+1 so that's when we'll really have problems. Having something like OpenRC or Upstart might allow to add/override broken init scripts with native/declarative ones. Perhaps by then we'll have new ways to convert init scripts or generate them from metalanguage; or built-in support for reading each others' formats. > And AFAICS we may be able to use Upstart some time in the future but this > doesn't seem > possible right now. We could initially ask the maintainer to apply Dmitri's patches and try to keep it building on kfreebsd. And just keep it around for people to play around with and possibly get it fully working. IIRC it runs, but will need early boot scripts re-writing, equivalent to /etc/rcS.d/ > What is the current status of OpenRC? Is it usable? Pretty good as I recall; it was very easy to test using jails. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb647f.3090...@pyro.eu.org
Re: Init system for non-Linux ports
On 12/02/14 12:23, Robert Millan wrote: > If we have to support it anyway, is it really worth spending effort on > Upstart/OpenRC for Jessie? Right, sysvinit is a viable and easy option for jessie; having any other init systems working is a bonus. At least we know now that we need to concentrate on maintaining sysvinit scripts. Although, come jessie+1, I wonder how upgrades will be handled, if sysvinit scripts go away. Maybe it is preferable to have some new init system *already* in place, as default in jessie. But it's difficult to predict so far ahead. > IMHO it'd be safer to wait and see where things go. I agree, a lot could change now that GNU/Linux has chosen systemd, and we have plenty of time. In particular I wonder what Ubuntu will do, and if Upstart has a future at all. The still-ongoing GNOME/logind issue may have some impact on that. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb6bb7.5020...@pyro.eu.org
Re: Init system for non-Linux ports
On 12/02/14 13:18, Robert Millan wrote: > Or maybe backward compat? I hear some of the new init implementations > support SysV. SysV init scripts? I thought this was obvious, or maybe I misunderstand what you mean. *All* of the init systems that were discussed by the TC, even systemd (for now), can use existing SysV init scripts. This is important to know, because some (perhaps most) packages may not bother creating systemd unit files at all for jessie, and continue to fully maintain the SysV init scripts they already have. And adopting any new init system for jessie is made considerably easier by using the same init scripts as sysvinit. SysV init scripts can be overridden by creating a new runscript/job of the same name. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb7974.60...@pyro.eu.org
Re: Init system for non-Linux ports
On 12/02/14 12:40, Steven Chamberlain wrote: > In particular I wonder what Ubuntu will do, and > if Upstart has a future at all. Well, we have an announcement today from Canonical - AIUI Upstart will be discontinued after Ubuntu 14.04 LTS and they will switch to systemd: http://www.markshuttleworth.com/archives/1316 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fe6490.8040...@pyro.eu.org
Re: default init on non-Linux platforms
Apparently sysvinit scripts must be retained anyway for a smooth migration to jessie; also for easy backporting of jessie packages to wheezy, and maybe other reasons. Non-Linux ports are likely to use those SysV init scripts, though we might invoke them from something other than sysvinit. I know some maintainers would like SysV init scripts to disappear, but the earliest I think that can happen for existing packages would be jessie+1. In that case, we should try to plan for a similar migration from jessie to jessie+1. It's difficult to predict so far ahead, but if it will be a migration to OpenRC, maybe jessie should try to have OpenRC already in place, so that it will be able to use jessie+1's runscripts when they appear and be able to shut down cleanly when SysV init scripts are gone. (I think Thomas was describing the same situation in the context of sid) Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5303f898.7070...@pyro.eu.org
Re: preparing for GCC 4.9
Hi, On 08/05/14 16:25, Matthias Klose wrote: > I would like to see some partial test rebuilds (like buildd or minimal chroot > packages) for other architectures. Any possibility to setup such a test > rebuild > for some architectures by the porters? Afaics the results for the GCC > testsuite > look okish for every architecture. I rebuilt 105 source packages on kfreebsd-amd64 comprising minbase and build-essential (except for GCC itself) using GCC 4.9 and did not notice any new build failures introduced by it. I'll continue to check that the binaries compiled by GCC 4.9 are actually okay. The issue with running the GCC testsuite on kfreebsd-amd64 buildds is being fixed by FreeBSD upstream, and on Debian buildds within 1-2 weeks. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5381122c.3010...@pyro.eu.org
Re: please remove kfreebsd-any from Architecture
On 28/05/14 20:12, Steven Chamberlain wrote:
>>> gnome 2014-05-21 1:3.8+6 unsatisfied dependency on gdm3
>>> (>= 3.4)
>>> gnome-core 2014-05-21 1:3.8+6 unsatisfied dependency on gdm3
>>> (>= 3.4)
>>> xfswitch-plugin 2014-05-21 0.0.1-4 unsatisfied dependency
>>> on gdm3
>
> The arch:all metapackages don't need any changes.
xfswitch-plugin is now linux-any and just needs ftpmaster removal
> gdm3 and gnome-shell wait for each other and for the above binary
> packages to be adjusted, before they can migrate to testing:
>
>> trying to update gnome-shell from 3.8.4-8 to 3.8.4-8.1 (candidate is 16 days
>> old)
>> Updating gnome-shell makes 4 non-depending packages uninstallable on
>> kfreebsd-amd64: gdm3, gnome, gnome-core, xfswitch-plugin
>
>> trying to update gdm3 from 3.8.4-6 to 3.8.4-9 (candidate is 7 days old)
>> Updating gdm3 makes 5 non-depending packages uninstallable on
>> kfreebsd-amd64: gnome, gnome-core, gnome-shell, gnome-shell-dbg,
>> xfswitch-plugin
I think the attached diff to meta-gnome3 is all that's needed.
(One could try to argue that the 'core' bits of GNOME are still there
and to reduce gnome-shell and gdm3 dependencies to a [linux-any]. But I
think GNOME maintainers would insist that those are vital components of
gnome-core. No matter - many GNOME bits can be found already in XFCE
and MATE metapackages.)
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- meta-gnome3-3.8+6/debian/control.orig 2014-04-26 10:22:34.0 +0100
+++ meta-gnome3-3.8+6/debian/control 2014-05-28 20:40:25.825720477 +0100
@@ -16,7 +16,7 @@
Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/meta-gnome3/
Package: gnome-core
-Architecture: any
+Architecture: linux-any
Depends: libatk-adaptor (>= 2.4),
at-spi2-core (>= 2.4),
baobab (>= 3.4),
@@ -100,7 +100,7 @@
It contains the official âcoreâ modules of the GNOME desktop.
Package: gnome
-Architecture: any
+Architecture: linux-any
Depends: gnome-core (= ${binary:Version}),
desktop-base,
network-manager-gnome (>= 0.9.4) [linux-any],
Re: please remove kfreebsd-any from Architecture
Hi Emilio, On 16:01, Emilio Pozuelo Monfort wrote: > Just a reminder: there are still various things depending on the removed > packages, preventing things from migrating to testing. Do you agree it's just the two metapackages from src:meta-gnome3 that need changes, or is there anything else? http://lists.debian.org/53863f46.2050...@pyro.eu.org Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140530155724.gb28...@squeeze.pyro.eu.org
Re: gnome-terminal: FTBFS on kfreebsd & hurd archs
On 15:43, Robert Millan wrote: > I find it very strange that a terminal application needs gnome-shell. Stranger still that it is a *build* dependency; here's what happens without it: > checking whether to build the gnome-shell search provider... yes > checking for > /usr/share/dbus-1/interfaces/org.gnome.ShellSearchProvider2.xml... no > configure: error: gnome-shell search provider requested but interface > definition file not found > make: *** [debian/stamp-autotools] Error 1 > dpkg-buildpackage: error: debian/rules build gave error exit status 2 I can't imagine what feature of gnome-terminal this is used for. Maybe there's some way to split these DBus definitions out into a gnome-shell-dev package or similar, but we should find out if gnome-shell is still needed at run-time. I would imagine some Linux users of other desktops use gnome-terminal; I'd check this on popcon.d.o but it is unavailable today. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140531154459.gb31...@squeeze.pyro.eu.org
Re: gnome-terminal: FTBFS on kfreebsd & hurd archs
On 15:43, Robert Millan wrote: > I find it very strange that a terminal application needs gnome-shell. There > are > dozens of terminal applications, and so far they seem to manage without > dragging > their own desktop environment of choice with them. FWIW I just noticed there isn't an install-time dependency declared on gnome-shell, it's only needed at build time. (Yes, it's really odd that a whole desktop environment is needed on a buildd, to compile a standalone terminal emulator application). https://buildd.debian.org/status/fetch.php?pkg=gnome-terminal&arch=i386&ver=3.12.2-3&stamp=1401560257 | gdm3 [...] gnome-bluetooth gnome-common gnome-desktop3-data | gnome-doc-utils gnome-icon-theme gnome-icon-theme-symbolic gnome-pkg-tools | gnome-session gnome-session-bin gnome-session-common gnome-settings-daemon | gnome-shell gnome-shell-common gnome-themes-standard | gnome-themes-standard-data | [...] | 0 upgraded, 490 newly installed, 1 to remove and 24 not upgraded. | Need to get 163 MB/163 MB of archives. | After this operation, 578 MB of additional disk space will be used. > Which makes me wonder: Does gnome-terminal actually work without gnome-shell? > Is > this setup properly tested and supported by upstream? popcon.d.o shows 69295 gnome-terminal users but only 56045 with gnome-shell, so this question wasn't only relevant to kfreebsd. I'm assuming gnome-terminal will still run okay, or otherwise some Linux user can follow up on this. Thanks Pino for the patch. (Disabling the feature on kfreebsd/hurd is an acceptable shortcut; splitting the build dependencies out of gnome-shell also would have fixed it, but we won't need this feature at run-time on kfreebsd/hurd). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140601115004.ga1...@squeeze.pyro.eu.org
Re: please remove kfreebsd-any from Architecture
Hi Emilio, I'm confused why source packages gdm3 and gnome-shell didn't migrate at the same time as meta-gnome3. I can only see that they wait for each other; is there something else blocking this? Is some additional hint needed to allow removals? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538c50f9@pyro.eu.org
Re: gnome-terminal: FTBFS on kfreebsd & hurd archs
Andreas, Seems I need to rephrase. The kfreebsd-specific problem has been addressed. Any other problem with gnome-terminal, I don't have patience/motivation to pursue right now, due in part to: Point 1: On 02/06/14 13:13, Andreas Henriksson wrote: > On Sun, Jun 01, 2014 at 12:50:06PM +0100, Steven Chamberlain wrote: > [... random ramblings removed ...] Point 2: >> I'm assuming gnome-terminal will still run okay, or otherwise some >> Linux user can follow up on this. > [...] > > Please stop making assuptions. Point 3: > Andreas "some Linux user" Henriksson -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538c7881.1050...@pyro.eu.org
Re: please remove kfreebsd-any from Architecture
Hi Robert, On 02/06/14 14:36, Adam D. Barratt wrote: > There's also gnome-session. gnome-core depends on gnome-session, which > in turn depends on gnome-shell. We'll need to make gnome-session Architecture: linux-any and remove it. And I wonder if we could adjust gnome-core's dependency from: gnome-session (>= 3.4), to: gnome-session (>= 3.4) [linux-any], gnome-session-bin (>= 3.4) [!linux-any], That keeps it installable as a metapackage of "the remaining core bits of GNOME not needing systemd" which could be useful information. The alternative is to make it linux-any and remove it. I think these are the last bits of the dependency chain, (gnome-shell + gdm3 < gnome-core < gnome-session), except for some arch:all packages which don't matter for testing migration. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538cbab4.1040...@pyro.eu.org
Re: please remove kfreebsd-any from Architecture
Hi Emilio, On 02/06/14 19:13, Emilio Pozuelo Monfort wrote: > May I ask what was broken on gdm3 and gnome-shell to have caused all these > removals? Note that there are efforts upstream to port GNOME to BSD. Was > there a > bug or bugs in gnome-shell and/or gdm3 that led to this? Sometime during the flamewar it was claimed that they wouldn't function properly without systemd for the jessie release. I'm aware of heroic efforts by the BSDs and some GNOME developers[0] to try to keep it working - I don't this work has caught up with 3.12 yet. The 3.13.2 release notes[1] announced that a 'temporary' dependency on systemd had been introduced. [0]: http://undeadly.org/cgi?action=article&sid=20140219085851 [1]: https://mail.gnome.org/archives/gnome-announce-list/2014-May/msg00034.html But there are recent statements from Debian GNOME maintainers that they wouldn't support such a configuration either way: On Mon, 12 May 2014 11:54:43 +0200, Josselin Mouette wrote: > As far as GDM is concerned, any bug reported with systemd-shim installed > will be ignored. The bug script should probably be updated to that > effect, BTW. https://lists.debian.org/debian-devel/2014/05/msg00477.html Also related, I suspect there was pressure being exerted on the release team to try to disqualify kfreebsd as a release arch entirely. Agreeing to drop GNOME was something of a compromise I think. We still see conflicts with some GNOME maintainers even over trivial issues, making it difficult to collaborate: http://lists.debian.org/20140531155148.ga26...@fatal.se (rude answer, which still didn't address key questions asked) http://lists.debian.org/20140602121342.ga13...@fatal.se (dismissed my concerns over gnoem-terminal Build-Depends: gnome-shell [requiring whole GNOME desktop to build it] with "random ramblings removed") So I think there are mostly human rather than technical reasons. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538cc7ea.20...@pyro.eu.org
Re: Bug#757987: kfreebsd: cannot create swap space
reassign 757987 partman-basicfilesystems found 757987 partman-basicfilesystems/96 tags 757987 + patch user debian-...@lists.debian.org usertags + kfreebsd thanks Hi, partman-basicfilesystems 96 added commit.d/format_swap, which uses mkswap (a Busybox utility for formatting Linux swap space) for any type of swap partition. mkswap, and the whole format_swap script, is of no use to kfreebsd (or hurd I presume - please correct me if I'm wrong); on kfreebsd we don't need to format our swap space to use it. This patch exits early from the script on non-Linux architectures. I've used $(archdetect) here to be consistent with check.d/ext2_boot; the limitation is that this doesn't allow for a "linux-*" pattern patch, so I had to list all (2) of the non-linux architecture prefixes. I've tested this on kfreebsd-amd64, and also that swap space still gets mounted when partman is finished. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org * Skip commit.d/format_swap on kfreebsd-* and hurd-*, which don't need to format their swap partitions diff --git a/commit.d/format_swap b/commit.d/format_swap index e2dc4b0..dc72032 100755 --- a/commit.d/format_swap +++ b/commit.d/format_swap @@ -1,5 +1,17 @@ #!/bin/sh +ARCH="$(archdetect)" + +# The mkswap utility only supports Linux swap partitions; skip running +# the rest of this script on other architectures +case $ARCH in +hurd-*|kfreebsd-*) +exit 0 +;; +*) +;; +esac + . /lib/partman/lib/base.sh for dev in $DEVICES/*; do
Re: Bug#757987: kfreebsd: cannot create swap space
On 22/08/14 14:48, Samuel Thibault wrote: > hurd uses the same format as Linux, do not disable formatting swap > there. Thanks, that's surprising; glad I asked. New patch attached. Regards, -- Steven Chamberlain ste...@pyro.eu.org * Skip commit.d/format_swap on kfreebsd-*, whose swap partitions do not need to be formatted (Closes: #757987) diff --git a/commit.d/format_swap b/commit.d/format_swap index e2dc4b0..dc3ea08 100755 --- a/commit.d/format_swap +++ b/commit.d/format_swap @@ -1,5 +1,18 @@ #!/bin/sh +ARCH="$(archdetect)" + +# The mkswap utility only supports Linux-type swap partitions, used +# on Linux and Hurd; do not use it on kfreebsd which does need to +# format swap partitions +case $ARCH in +kfreebsd-*) +exit 0 +;; +*) +;; +esac + . /lib/partman/lib/base.sh for dev in $DEVICES/*; do
Re: Bug#711799: PXE error: no server is specified
Hi, Just to let hurd folks know, this bug affects their netboot images too. So I'll submit a patch that fixes both hurd and kfreebsd: $ wget http://d-i.debian.org/daily-images/hurd-i386/daily/netboot/grub2pxe $ qemu-system-i386 -net nic -net user,bootfile=grub2pxe,tftp=. qemu: fatal: Trying to execute code outside RAM or ROM at 0x656e0065 EAX=07ff158f EBX=07ff158f ECX=0001 EDX=656e0065 ESI=07f3c7d0 EDI=0007ff80 EBP=0007ff3c ESP=0007ff00 EIP=656e0065 EFL=0022 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 etc... Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5400607d.3030...@pyro.eu.org
Re: Bug#757711: netcfg: promptly kills dhclient, deconfigures interface
Hi, Please may I commit this to d-i/netcfg (assuming my d-i Git privileges include that repository). As well as kfreebsd, I expect hurd is currently affected by this bug, so this patch would also fix it there. Thanks. --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +netcfg (1.120) UNRELEASED; urgency=medium + + [ Steven Chamberlain ] + * Do not kill_dhcp_client after setting the hostname and domain, +otherwise Linux udhcpc will stop renewing its lease, and on other +platforms dhclient will de-configure the network interface +(Closes: #757711, #757988) + + -- Debian Install System Team Fri, 29 Aug 2014 22:05:47 +0100 + netcfg (1.119) unstable; urgency=medium [ Colin Watson ] diff --git a/dhcp.c b/dhcp.c index aa37bd0..5ef0dbc 100644 --- a/dhcp.c +++ b/dhcp.c @@ -614,7 +614,6 @@ int netcfg_activate_dhcp (struct debconfclient *client, struct netcfg_interface netcfg_write_loopback(); netcfg_write_interface(interface); netcfg_write_resolv(domain, interface); -kill_dhcp_client(); stop_rdnssd(); return 0; -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140829211457.ga30...@squeeze.pyro.eu.org
Re: Bug#759686: debian-installer: non-grub PXE boot images crash
Hi, I'd like to commit this debian-installer fix for kfreebsd, but also make the same change for hurd, since I know the hurd netinst image for PXE was broken in the same way. Please could hurd porters let me know if this looks okay. I haven't tested it by way of a debian-installer build on hurd, but it should definitely be an improvement. Thanks. --- a/debian/changelog +++ b/debian/changelog @@ -13,6 +13,18 @@ debian-installer (2014) UNRELEASED; urgency=low adding a syslinux-utils build-dep (Closes: #751731), no thanks to its maintainer as far as cooperation is concerned (See: #751724, #759189). + [ Steven Chamberlain ] + * On kfreebsd and hurd, which use GRUB for PXE booting, request two +additional modules in the grub-mkimage step: (Closes: #759686) +- tftp: required since GRUB 2.02 otherwise PXE boot will crash/hang +- gfxterm_background: required since GRUB 2.02 for the boot splash + image functionality to be available +- raise the grub-pc (and indirectly grub-common) build dependency to + >= 2.02~beta2~ on these architectures, because module + gfxterm_background did not exist in GRUB 2.00 +- raise the xorriso build dependency to >= 1.3.2-1~ on these + architectures, for compatibility with grub-mkrescue in GRUB 2.02 + -- Cyril Brulebois Sat, 02 Aug 2014 02:59:35 +0200 debian-installer (20140802) unstable; urgency=low --- a/debian/control +++ b/debian/control @@ -157,9 +157,9 @@ Build-Depends: # Alternative boot method for win32 platforms. makefs [kfreebsd-any], # Used to create an UFS1 filesystem from a directory tree. - grub-pc (>= 1.99-1~) [kfreebsd-i386 kfreebsd-amd64 hurd-i386], + grub-pc (>= 2.02~beta2~) [kfreebsd-i386 kfreebsd-amd64 hurd-i386], # Used as the CD-ROM's bootloader - xorriso [kfreebsd-i386 kfreebsd-amd64 hurd-i386], + xorriso (>= 1.3.2-1~) [kfreebsd-i386 kfreebsd-amd64 hurd-i386], # Used by grub-pc to create the CD-ROM images debian-ports-archive-keyring [sh4 sparc64], # Used for architectures hosted on debian-ports.org --- a/build/config/hurd.cfg +++ b/build/config/hurd.cfg @@ -33,7 +33,7 @@ GRUB_CFG_PXE=boot/hurd/grub-hurd-pxe.cfg # GRUB modules GRUB_PLATFORM=i386-pc GRUB_MODDIR=/usr/lib/grub/$(GRUB_PLATFORM) -GRUB_MODULES_PXE=pxe multiboot cpuid echo gfxterm gzio minicmd normal png vbe +GRUB_MODULES_PXE=pxe tftp multiboot cpuid echo gfxterm gfxterm_background gzio minicmd normal png vbe # Location for Xen example configuration. XENCFG = $(SOME_DEST)/$(EXTRANAME)debian.cfg --- a/build/config/kfreebsd.cfg +++ b/build/config/kfreebsd.cfg @@ -15,7 +15,7 @@ GRUB_CFG_PXE=boot/kfreebsd/grub-kfreebsd-pxe.cfg # GRUB modules GRUB_PLATFORM=i386-pc GRUB_MODDIR=/usr/lib/grub/$(GRUB_PLATFORM) -GRUB_MODULES_PXE=pxe bsd cpuid echo gfxterm gzio minicmd normal png vbe +GRUB_MODULES_PXE=pxe tftp bsd cpuid echo gfxterm gfxterm_background gzio minicmd normal png vbe # Location for Xen example configuration. XENCFG = $(SOME_DEST)/$(EXTRANAME)debian.cfg -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140829195206.ga29...@squeeze.pyro.eu.org
Re: Bug#757711: netcfg: promptly kills dhclient, deconfigures interface
Hi Philipp, On 31/08/14 07:00, Philipp Kern wrote: > On Fri, Aug 29, 2014 at 11:25:28PM +0200, Cyril Brulebois wrote: >> See: >> | commit 8802ca520d9e91542d92bbfa5b2fc412a31cf2e2 >> | Author: Matt Palmer >> | Date: Sun Jan 30 22:29:42 2011 +1100 >> | >> | IPv6 support for using rDNS to preseed hostnames >> | >> | A lot of refactoring to make the code cleaner and simpler, but the >> | IPv6-specific changes were actually relatively small. >> | >> | Rebased-and-modified-by: Philipp Kern >> >> http://anonscm.debian.org/cgit/d-i/netcfg.git/commit/?id=8802ca520d9e91542d92bbfa5b2fc412a31cf2e2 > > I did some archeology and I'll spare you the details. That kill_dhcp_client is > totally wrong where it is now, so LGTM. Thanks. Is perhaps the same true for stop_rdnssd() on the next line? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/540310fb.7040...@pyro.eu.org
Re: Bug#759686: debian-installer: non-grub PXE boot images crash
tags 759686 + pending thanks On 29/08/14 20:52, Steven Chamberlain wrote: > I'd like to commit this debian-installer fix for kfreebsd, but also > make the same change for hurd, since I know the hurd netinst image for > PXE was broken in the same way. > > Please could hurd porters let me know if this looks okay. > > I haven't tested it by way of a debian-installer build on hurd, but it > should definitely be an improvement. I've gone ahead and applied it in Git, and then in the next d-i daily build for hurd-i386 I could see the GRUB crash issue has gone away, TFTP and background splash image are working again. (It's not possible to proceed further than that due to something else wrong with the hurd-i386 GRUB configuration for PXE [$root seems to get unset in boot_one]. On kfreebsd, PXE works fully, so a solution could be borrowed from us probably). > + [ Steven Chamberlain ] > + * On kfreebsd and hurd, which use GRUB for PXE booting, request two > +additional modules in the grub-mkimage step: (Closes: #759686) > +- tftp: required since GRUB 2.02 otherwise PXE boot will crash/hang > +- gfxterm_background: required since GRUB 2.02 for the boot splash > + image functionality to be available > +- raise the grub-pc (and indirectly grub-common) build dependency to > + >= 2.02~beta2~ on these architectures, because module > + gfxterm_background did not exist in GRUB 2.00 > +- raise the xorriso build dependency to >= 1.3.2-1~ on these > + architectures, for compatibility with grub-mkrescue in GRUB 2.02 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54031667.7080...@pyro.eu.org
Re: Time to change the debian-ports "list"?
Hi, On 05/09/14 18:39, Steve McIntyre wrote: > * Remove the confusion: turn debian-ports into a separate *normal* >mailing list, announce it and let people subscribe to it [...] That sounds perfect IMHO. It could be used for general discussion about porting, upcoming new ports, or any ports that don't quite merit having their own mailing list yet. >"debian-cross-ports" or "debian-architectures" or something. I'd prefer not to have it, or have to sign up to it as a porter. It'd probably get more spam than useful mail. I can't think of a reason to mail *all* ports that wouldn't be appropriate for debian-devel-announce; or if your mail only concerns a few ports it should be convenient to cross-post to the relevant ports' lists only. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/540a0bbb.3050...@pyro.eu.org
Re: sh4 missing on packages.debian.org
On 05/09/14 18:04, John Paul Adrian Glaubitz wrote: > For example, src:glibc, has been fully built on sh4, yet: > yamato:~# apt-cache policy libc6 > libc6: > Installed: 2.19-9 > Candidate: 2.19-9 > Version table: > *** 2.19-9 0 > 100 /var/lib/dpkg/status I can only find arch:all packages from glibc/2.19-10 in: http://ftp.debian-ports.org/debian/dists/sid/main/binary-sh4/Packages.bz2 So. although the sh4 buildds have built the sh4 .debs, they're not being properly installed into that archive; you'll have to ask debian-ports.org admins about it. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/540a0ed3.9090...@pyro.eu.org
Re: Bug#760727: qtwebkit: FTBFS on kfreebsd-*: libQtWebKit.so: undefined reference to `void WTF::freeOwnedGPtr<_GError>(_GError*)'
Hi, On 07/09/14 19:32, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi Qt maintainers and KFreeBSD*/Hurd porters! I'm trying to debug this issue > and so far I couldn't come up with a solution, so if any of you can give us a > hand it would be greatly appreciated. I've already taken a look at this and I'm running a test build with the attached change. This was only my first guess, it may take a few hours to build and I'm not optimistic about it. > This is clearly a bug that only happens on !linux and it reduces to: > > /«PKGBUILDDIR»/WebKitBuild/Release/lib/libQtWebKit.so: undefined reference to > `void WTF::freeOwnedGPtr<_GError>(_GError*)' I'm not sure at this point why the issue could be specific to !linux... > which happens to be declared in: > Source/autotools/symbols.filter:11:_ZN3WTF13freeOwnedGPtrI7_GErrorEEvPT_; I wonder if there's some significance that it was templated for <_GError> whereas I think that should be a typedef to GError (without underscore)? Regards, -- Steven Chamberlain ste...@pyro.eu.org --- a/Tools/QtTestBrowser/QtTestBrowser.pro +++ b/Tools/QtTestBrowser/QtTestBrowser.pro @@ -59,3 +59,5 @@ RESOURCES += \ QtTestBrowser.qrc + +DEFINES += ENABLE_GLIB_SUPPORT=1 signature.asc Description: OpenPGP digital signature
Re: Bug#760727: qtwebkit: FTBFS on kfreebsd-*: libQtWebKit.so: undefined reference to `void WTF::freeOwnedGPtr<_GError>(_GError*)'
On 07/09/14 22:22, Steven Chamberlain wrote: > I wonder if there's some significance that it was templated for > <_GError> whereas I think that should be a typedef to GError (without > underscore)? My test build finished - the change I tried didn't help - but looking for _GError (with underscore) it seemed it was specific to GStreamer: > $ grep _GError . -R > Binary file > ./WebKitBuild/Release/Source/WebCore/obj/release/MediaPlayerPrivateGStreamer.o > matches > Binary file > ./WebKitBuild/Release/Source/WebCore/obj/release/GStreamerUtilities.o matches > Binary file > ./WebKitBuild/Release/Source/WebCore/obj/release/WebKitWebSourceGStreamer.o > matches Then I found this related upstream commit mentioned in the 2.3.3 changelog: > 242013-12-17 Alex Christensen > 25 > 26[Win] Fixed linker error with GStreamer. > 27https://bugs.webkit.org/show_bug.cgi?id=124861 > 28 > 29Reviewed by Martin Robinson. > 30 > 31* wtf/gobject/GOwnPtr.cpp: > 32(WTF::GError): > 33* wtf/gobject/GOwnPtr.h: > 34Added WTF_EXPORT_PRIVATE to freeOwnedGPtr declaration > and definition. I'm trying another test build now with this change applied: http://trac.webkit.org/changeset/160716 Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: Bug#760727: qtwebkit: FTBFS on kfreebsd-*: libQtWebKit.so: undefined reference to `void WTF::freeOwnedGPtr<_GError>(_GError*)'
Hi!
On 09/09/14 18:30, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Monday 08 September 2014 12:16:21 Steven Chamberlain wrote:
> [snip]
>> I'm trying another test build now with this change applied:
>> http://trac.webkit.org/changeset/160716
>
> I Steven! How did the build go?
That didn't work.
Actually, GOwnPtr.o didn't contain anything, no function to export -
this is obviously due to the #ifdef ENABLE_GLIB_SUPPORT - I'm now trying
with the attached patch instead. (Which is almost what I thought the
problem was in the first place, I was just looking in the wrong
.pro/.pri file).
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
From: Steven Chamberlain
Subject: properly support GStreamer on non-Linux platforms
GStreamer is enabled when building on GNU/kFreeBSD and Hurd, but support
for it was not enabled in the WTF component
Bug-Debian: http://bugs.debian.org/760727
--- a/Source/WTF/WTF.pri
+++ b/Source/WTF/WTF.pri
@@ -24,7 +24,7 @@
}
}
-linux-*:contains(DEFINES, WTF_USE_GSTREAMER=1) {
+linux-*|glibc-*|hurd-*:contains(DEFINES, WTF_USE_GSTREAMER=1) {
DEFINES += ENABLE_GLIB_SUPPORT=1
PKGCONFIG += glib-2.0 gio-2.0
}
signature.asc
Description: OpenPGP digital signature
Re: Bug#760727: qtwebkit: FTBFS on kfreebsd-*: libQtWebKit.so: undefined reference to `void WTF::freeOwnedGPtr<_GError>(_GError*)'
Having touched Source/WTF/WTF.pri, I'm now stuck at this qmake error: > cd Source/ && make -f Makefile.QtWebKit qmake_all > make[4]: Entering directory `«PKGBUILDDIR»/WebKitBuild/Release/Source' > /usr/lib/x86_64-kfreebsd-gnu/qt5/bin/qmake «PKGBUILDDIR»/Source/api.pri > CONFIG+=no_force_sse2 CONFIG+=release CONFIG-=debug CONFIG+=production_build > -o Makefile.api > Project ERROR: Module does not define version. Is it trying to regenerate makefiles because I've changed something they're generated from? But if I revert my change, it still does this. Does that imply some pre-existing problem in the build process... perhaps? *sad, confused* Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: Bug#760727: qtwebkit: FTBFS on kfreebsd-*: libQtWebKit.so: undefined reference to `void WTF::freeOwnedGPtr<_GError>(_GError*)'
On 11/09/14 16:00, Andreas Cord-Landwehr wrote: > Just set up a fresh VM with KFreeBSD-amd64 and using the previously suggested > patch [1] worked for me to fix the build, see log [2]. > PS: My setup slightly more verbose: > * KFreeBSD installed from current Debian/SID to VirtualBox > * got qtwebkit sources with "apt-get source" > * applied patches with "quilt push -a" > * used "dpkg-buildpackage -b" Thank you for testing! I'm not sure what I was doing wrong; I was seeing qmake or other errors when applying my patch in a clean source tree and trying to build. But if it really works then that's great. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54138ff6.7040...@pyro.eu.org
Re: Plan B for kfreebsd
Christoph Egger wrote: > It means we need a stable release of some sort to keep DSA provided > hardware. That's currently buildds and porterboxes. That's annoying. To provide stable/security support ourselves, it seemed we'd need an unofficial repo, and that doesn't sound like something DSA could use. Although, how is that handled for hurd-i386? I assume it has no security support, there may be some unofficial packages used; are therefore none of their machines DSA? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014120505.gd14...@squeeze.pyro.eu.org
Re: Plan B for kfreebsd
Peter Palfrader wrote: > On Tue, 11 Nov 2014, Samuel Thibault wrote: > > We are still stuck in the "not released arch => no DSA machine => not > > released arch" loop. > > Except that it's not a loop. DSA has indicated time and time again that > if an arch qualifies for a release in all other aspects, we'd be running > buildds and porterboxes close to the release. Until Christoph quoted your brilliant suggestion on IRC, I did think there were one or more loops here with no obvious way out, for us or many future ports. At least, the release team's decision seemed far-reaching, since: 0. stable RM says 'no' to a port 1.1. if there's not a 'stable' release, the buildds can't be DSA 1.2. without DSA buildds, there can be no security builds either (and vice-versa) 1.3. packages built for sid, on non-DSA buildds are not official? so would need to rebootstrap itself 2.1. testing goes away too 2.2. users/developers are left with only sid, which is obviously more broken; development gets harder, users leave 2.3. port becomes less appealing for maintainers to support, stop trying to building their packages on it 3.1. if there's no testing or stable, FTP team might not see much reason to distribute it; it moves to debian-ports.org and, I suppose never comes back 3.2. mirrors no longer carry it, most QA tools and supporting infrastructure can no longer support it 4. next release qualification, the port seems in pretty bad shape due to all of the above probably receives a 'no' again Anyway, I'm really hopeful now. weasel suggested a 'jessie-kfreebsd' suite could still be supported by FTP team. (Actually, could that be named something more generic like jessie-ports? So that another arch can try something similar? Or would it be confused too much with debian-ports.org?) Porters would try to maintain it like a stable release. Perhaps able to do make improvements that release team policy might not have allowed; like backporting something that particularly benefits that arch. Practically it would be an 'official Debian port', and we'd have all the usual things like install media. If it turns out to be in fact stable, hopefully it would be acceptable to DSA. The remaining obstacles go away. It sounds sustainable, and seems like a model for other ports to follow. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014134118.gf14...@squeeze.pyro.eu.org
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Holger Levsen wrote: > in the video there is no IP address to be seen. em0 gets a link, but thats > all. Later 'network autoconfiguration succeeded', so DHCP probably worked; the IP address isn't usually mentioned within the GUI installer, but the d-i syslog will probably explain what the problem is. > > -serial file, to write those separately as an artifact > > whatever you prefer really. I tend to somewhat prefer the latter... > optionally > output that at the end of the job... Okay I've tried to log serial console output as an artifact, if you could pull again please: https://git.steven.hosting.pyro.eu.org/jenkins.debian.net.git/?h=adc905d26d93381495a47ece2259207009f0da5e Maybe hurd also could redirect syslog there to help debug the issue you're seeing. Unless there's a convenient kernel parameter to send console messages there, you could always use preseed/early_command to modify inittab like I did here: https://anonscm.debian.org/cgit/qa/jenkins.debian.net.git/commit/?id=f85e9c3f8dcc4283120e77794a150daad930da46 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141112192613.ga19...@squeeze.pyro.eu.org
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Holger Levsen wrote: > https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_kfreebsd/432/artifact/results/serial.log > is there now and it shows how the right IP is received. I don't understand > why getting the preseed file then fails... I think we're missing some data from the end of the serial.log; probably due to some buffering, and qemu being sent SIGKILL. Please consider this change to use SIGINT for up to 10 seconds, then SIGKILL only if it's still running after that: https://git.steven.hosting.pyro.eu.org/jenkins.debian.net.git/?h=894584fca266789c8f40b4c0cad60b7909385523 Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141113134537.ge23...@squeeze.pyro.eu.org
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Hi, Holger Levsen wrote: > On Donnerstag, 13. November 2014, Steven Chamberlain wrote: > > Please consider this change to use SIGINT for up to 10 seconds, > > then SIGKILL only if it's still running after that: > > https://git.steven.hosting.pyro.eu.org/jenkins.debian.net.git/?h=894584fca266789c8f40b4c0cad60b7909385523 > > did you make this never returns false? The script will immidiatly end in that > case, iirc... Are you thinking of "-e" (exit on error)? g-i-installation.sh doesn't seem to run in that mode, actually it ignores some failing commands already during cleanup steps. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114120218.gc26...@squeeze.pyro.eu.org
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Holger Levsen wrote: > > g-i-installation.sh doesn't > > seem to run in that mode, actually it ignores some failing commands > > already during cleanup steps. > > yes, but during cleanup +e is explicitly set, I think. Aha yes it does "set +e" inside that function. But code before and after it does ignore + have to handle fatal errors itself. The code I added shouldn't return false, except maybe a race between 'ps' and 'kill' (if the process goes away in that time); but seems unlikely with the 'sleep 1' after each iteration. > Oh, well, I suppose I should either merge and see how it fails or read the > code myself before merging... ;-) Well, you were right; I didn't think to check for a "set +e" in the script, only looked for something like that at the top of the script and assumed it was safe to return false anywhere. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114123321.gg26...@squeeze.pyro.eu.org
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Hi Holger, Holger Levsen wrote: > I don't understand why getting the preseed file then fails... https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_kfreebsd/433/screenshot/full After I started at the error message long enough, it finally hit me, and it's kind of amusing. If you could please fix my silly mistake: https://git.steven.hosting.pyro.eu.org/jenkins.debian.net.git/?h=b463b29fdcf5ec4104a2df624690aac8f23481a1 Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114131949.ge26...@squeeze.pyro.eu.org
Re: Failure: g-i-installation_debian_sid_daily_hurd_lxde/71
> device-mapper: remove ioctl on failed: Device or resource busy > Unable to deactivate jenkins01-debian_sid_daily_hurd_lxde (253:3) > Unable to deactivate logical volume "debian_sid_daily_hurd_lxde" Failure of job #71 was my fault, sorry... Build #74 is more interesting: https://jenkins.debian.net/job/g-i-installation_debian_sid_daily_hurd_lxde/74/console > Warning: snapshot_008300.png snapshot_007700.png match or almost match, > ending installation. > -rw-r--r-- 1 jenkins jenkins 936 Nov 14 19:17 snapshot_007700.png > -rw-r--r-- 2 jenkins jenkins 926 Nov 14 19:40 snapshot_008300.png > System in install mode is hanging. There had been some I/O errors reported earlier, but it seems to have finished the grub-installer step before Jenkins aborted; maybe it just needs to allow more time? d-i syslog is available now: https://jenkins.debian.net/job/g-i-installation_debian_sid_daily_hurd_lxde/74/artifact/results/serial.log/*view*/ Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54666847.50...@pyro.eu.org
tasksel desktop preseed issues (was: Re: Failure: g-i-installation_debian_sid_daily_hurd_lxde/71)
Hi, There are a few tasksel-related issues revealed by Jenkins testing of sid daily d-i builds, which are now active for hurd and kfreebsd as well. We also capture d-i syslog on those arches. Firstly could someone please tell me what display manager this is? https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_hurd_lxde/70/artifact/results//snapshot_008244.png hurd-i386: https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_hurd_lxde/70/artifact/results/serial.log * AFAICT no desktop was installed, despite preseed file asking for lxde: > tasksel tasksel/first multiselect standard, desktop > tasksel tasksel/desktop multiselect lxde * standard task still seems to bring in a huge amount of dependencies via gnupg2 > gnupg-agent > pinentry-gtk2 > xserver-* kfreebsd-amd64: https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_kfreebsd/440/artifact/results/serial.log * has the same issues as above, except xfce was requested: > tasksel tasksel/first multiselect standard, desktop > tasksel tasksel/desktop multiselect xfce linux-amd64: https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_jessie_xfce/65/artifact/results//snapshot_003706.png * we seemed to get gnome3, despite preseed file asking for xfce: > tasksel tasksel/first multiselect standard, desktop > tasksel tasksel/desktop multiselect xfce Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: Failure: g-i-installation_debian_sid_daily_hurd_lxde/71
Samuel Thibault wrote: > https://jenkins.debian.net/job/g-i-installation_debian_sid_daily_hurd_lxde/74/artifact/results//snapshot_007700.png > is almost exactly like > https://jenkins.debian.net/job/g-i-installation_debian_sid_daily_hurd_lxde/74/artifact/results//snapshot_008300.png > > But that doesn't mean that nothing happened in between! Haha that is unlucky. > The difference > computation should be performed between all images from 7700 to 8200 and > 8300, not *only* 7700. I suggest an optimisation (in case comparing frames is expensive to do): compare the current frame (n) with each of n-1, n-2, n-4, n-8, ..., n-512; skip further tests as soon as any comparison yields more than x pixels difference. I suppose I'm obligated to provide the patch now! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114234621.ga28...@squeeze.pyro.eu.org
Bug#769616: tasksel: fails to preseed desktop on kfreebsd, hurd
Package: src:tasksel Version: 3.29 Severity: important Hi, (this bug may also affect linux release architectures other than i386|amd64|powerpc*, and their CD media, so severity may be higher) It was seen on kfreebsd and hurd that preseeding with: tasksel tasksel/first multiselect standard, desktop tasksel tasksel/desktop multiselect xfce no longer works, a regressions since wheezy; no desktop gets installed: https://lists.debian.org/debian-hurd/2014/11/msg00074.html The logic gets ridiculously complex, but I gather that: * tasksel/first item "desktop", used to be the only thing listed; selecting or preseeding it would previously install task-desktop as well as task-xfce-desktop (whatever was default, or preseeded as tasksel/desktop) * now, preseeding tasksel/desktop seems to work *only* if /usr/lib/tasksel/tests/desktop decides it should install a desktop; irrespective of whether tasksel/first includes "desktop" * as such, on kfreebsd, hurd and some other arches, selecting or preseeding tasksel/first with "desktop" only leads to task-desktop being installed (the parent item), but not the individual task for desktop, despite setting tasksel/desktop So I think possible ways to fix this are: 1. simply adding kfreebsd-* and hurd-* to the list of "common desktop architectures" may inadvertently fix this - that determines whether tasksel preselects the 'desktop' option by default; currently the list has only (linux-) i386|amd64|powerpc* and may explain why the bug wasn't noticed there 2. make tests/default-desktop not conditional on check_desktop_wanted, if tasksel/first has "desktop", or tasksel/desktop is preseeded 3. make tests/desktop (whether to install a desktop) answer "yes" (exit 2) if tasksel/first has "desktop", or tasksel/desktop is preseeded, overriding any guess it would make based on architecture, diskspace, RAM etc. that it does currently I'll send a patch for consideration that probably does all three in some way. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141115022053.63520.58836.report...@sid.kfreebsd-amd64.pyro.eu.org
Re: Bug#773548: unblock: bind9/1:9.9.5.dfsg-7
Hi, Cyril Brulebois wrote: > Non-linux porters may want to double check this new version isn't going > to lead to regressions on their architecture(s) though, so letting them > know through Cc (patch available below). Thanks for checking with us. Seems like only DNS resolver code was changed, I don't think d-i uses any part of that, and needs only unrelated library functions for ISC dhcpd. Still, with the updated libs d-i still completed successfully (a netboot install involving DNS resolution and using DHCP). This test-run was more than 24 hours after 1:9.9.5.dfsg-7 built on kfreebsd-amd64 so would have been using the new udebs. https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_kfreebsd/447/ Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141221152320.ga13...@squeeze.pyro.eu.org
Re: Bug#768188: Jessie Installer hangs after processing DHCPv6 stateful addressing
Cyril Brulebois wrote: > Philipp Kern (2015-02-18): > > So now I guess the question is if we revert the change that broke it: > > > > Don't kill_dhcp_client without reason (Closes: #757711, #757988) > > > > Do not kill_dhcp_client after setting the hostname and > > domain, otherwise Linux udhcpc will stop renewing its lease, and > > on other platforms dhclient will de-configure the network interface > > (Closes: #757711, #757988) > > > > At this point kFreeBSD is no longer a release architecture and the other > > platform using dhclient is Ubuntu. > > GNU/kFreeBSD people are (AFAICT) going to try and get an unofficial > release out, so pushing a regression in their way doesn't look too good > to me. Maybe using an #ifdef here to avoid killing the DHCP client on > kfreebsd, and reinstating the previous codepath on linux would be an > acceptable compromise until some evolved signal/process handling pops > up (during the stretch release cycle)? Firstly, thanks for the heads-up. We did expect that during freeze, some regressions may be introduced that affect only GNU/kFreeBSD, and we'd have to fix things up in our unofficial release, perhaps rolling packages back to an older version, or uploading a patched version with +kfreebsd suffix. So, I'm happy if you decide to revert this. At first glance, it reads like a limitation of udhcpc/dhcp6c only? Killing it sounds like a workaround (which perhaps creates other issues), and an ifdef linux also seems wrong in this context (and for Ubuntu). kill-all-dhcp could be told never to kill ISC dhclient, but that too is wrong, as this is also used to implement the 'Cancel' button in the netcfg dialogs. Maybe there is still a better solution? Or perhaps we could add something that kills *only* udhcpc/dhcp6c, could clearly annotate it as "this is a workaround for bug #768188". Then it shouldn't affect Ubuntu, or derivatives/ports using ISC DHCP at all. And if many years pass before someone comes back to look at this, they should understand why it's there. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150218220527.gc22...@squeeze.pyro.eu.org
Re: Bug#768188: Jessie Installer hangs after processing DHCPv6 stateful addressing
Philipp Kern wrote: > one-shot mode (-1) and will exit after it acquired a lease successfully. dhclient isn't doing that, at least on kfreebsd. I'm not sure that's what -1 means. It will try only once to get a lease, initially. If successful it stays running - I assumed it continues to refresh the lease - and starting in the jessie version, will also give up the lease on SIGINT (that was #757711). I think reverting to what we had before reintroduces bugs, and would break downstream Ubuntu. I think a workaround should be more targetted at udhcpc/dhcp6c. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150219112053.ga25...@squeeze.pyro.eu.org
Bug#783548: choose-mirror: lists releases that don't include this arch
Package: choose-mirror
Version: 2.62
Severity: wishlist
Tags: patch
User: debian-...@lists.debian.org
Usertags: jessie kfreebsd
Hi,
When installing kfreebsd or hurd in Expert mode, choose-mirror offers to
install "jessie - stable" and "stretch - testing" even though the
architecture being installed isn't part of those releases.
I've attached a patch that adds support for the Architectures: header,
to not mention a release if it doesn't include the current arch.
Thanks.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'oldstable')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff --git a/choose-mirror.c b/choose-mirror.c
index 65885f6..b7d4019 100644
--- a/choose-mirror.c
+++ b/choose-mirror.c
@@ -300,9 +300,9 @@ static int get_release(struct release_t *release, const char *name) {
char *command;
FILE *f = NULL;
char *wget_options, *hostname, *directory;
- char line[80];
+ char line[BUFFER_LENGTH];
char *p;
- char buf[SUITE_LENGTH];
+ char buf[BUFFER_LENGTH];
hostname = add_protocol("hostname");
debconf_get(debconf, hostname);
@@ -321,7 +321,7 @@ static int get_release(struct release_t *release, const char *name) {
}
wget_options = get_wget_options();
- command = xasprintf("wget %s %s://%s%s/dists/%s/Release -O - | grep -E '^(Suite|Codename):'",
+ command = xasprintf("wget %s %s://%s%s/dists/%s/Release -O - | grep -E '^(Suite|Codename|Architectures):'",
wget_options, protocol, hostname, directory, name);
di_log(DI_LOG_LEVEL_DEBUG, "command: %s", command);
f = popen(command, "r");
@@ -337,12 +337,14 @@ static int get_release(struct release_t *release, const char *name) {
if (line[strlen(line) - 1] == '\n')
line[strlen(line) - 1] = '\0';
if ((value = strstr(line, ": ")) != NULL) {
-strncpy(buf, value + 2, SUITE_LENGTH - 1);
-buf[SUITE_LENGTH - 1] = '\0';
+strncpy(buf, value + 2, BUFFER_LENGTH - 1);
+buf[BUFFER_LENGTH - 1] = '\0';
if (strncmp(line, "Codename:", 9) == 0)
release->name = strdup(buf);
if (strncmp(line, "Suite:", 6) == 0)
release->suite = strdup(buf);
+if (strncmp(line, "Architectures:", 14) == 0)
+ release->archs = strdup(buf);
}
}
if (release->name != NULL && strcmp(release->name, name) == 0)
@@ -354,6 +356,14 @@ static int get_release(struct release_t *release, const char *name) {
!(release->status & IS_VALID))
log_invalid_release(name, "Suite or Codename");
+ /* Does the release include this arch? */
+ if (release->archs != NULL && strstr(release->archs, ARCH_TEXT) == NULL) {
+ /* No: disregard this release */
+ log_invalid_release(name, "Architectures");
+ release->status &= ~IS_VALID;
+ release->name = NULL;
+ }
+
/* Cross-validate the Release file */
if (release->status & IS_VALID)
if (! cross_validate_release(release))
diff --git a/mirrors.h b/mirrors.h
index e592b7a..f73aefb 100644
--- a/mirrors.h
+++ b/mirrors.h
@@ -17,6 +17,12 @@ struct mirror_t {
*/
#define MANUAL_ENTRY "manual"
+/*
+ * Allow to read the full Architectures: line from a Release file,
+ * which is up to 123 bytes long at time of writing.
+ */
+#define BUFFER_LENGTH 256
+
#define SUITE_LENGTH 32
/* Stack of suites */
@@ -43,6 +49,7 @@ static const char suites[][SUITE_LENGTH] = {
struct release_t {
char *name;
char *suite;
+ char *archs;
int status;
};
Re: Guide to getting ported?
Hi, Paul Wise wrote: > Do any porters have any input on this page? > https://wiki.debian.org/GettingPorted This page seems it will be useful; I will add some bits to it. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150501233237.gc46...@pyro.eu.org
Re: Defaulting to i686 for the Debian i386 architecture
Hi,
Matthias Klose wrote:
> question to the Hurd and KFreeBSD maintainers ... change that on
> these platforms too?
I have a fanatical preference for compatibility over performance. So
I prefer not to lose support for 586, but I don't know how practical
it would be for libc maintainers to do that only for kfreebsd.
kfreebsd-i386 has 686 (with SMP) and 486 kernel flavours.
If maybe package libc0.1-i686 had to go away, then I'd still prefer we
target 586 by default. (For some reason, the kfreebsd installer is
failing to install that package when it should; I forgot to install it
on all my 686s).
I'd be curious to see numbers showing the performance impact, though.
I have some of these around for testing on; I think this device was
manufactured as 'recently' as 2006. It is similar to the Soekris which
can still be purchased new:
cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC"
586-class) 333 MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,PGE,CMOV,MMX,MMXX,3DNOW2,3DNOW
kfreebsd-i386's particular niche is supporting ancient platforms like
these and making them still useful. And that would be especially
important to me, if Debian GNU/Linux (and Ubuntu, Fedora etc.) no longer
worked on them.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Re: Fwd: Re: Bug#571136: please remove useless devices from devices.tar.gz
Hi, Marco d'Itri wrote: > On Jan 10, Cyril Brulebois wrote: > > We have a bug report with a patch by Marco against debootstrap (see > > attachment), which changes how devices are generated; I can't really > > tell how much this might affect all of you (especially with debootstrap > It is not supposed to, since both hurd and kfreebsd already used > a different method to manage /dev. Yes, the code Marco changed cannot be reached when HOST_OS is kfreebsd*, freebsd* or hurd*. kfreebsd devfs provides all the device nodes without manually creating any or using devices.tar.gz; even for more exotic use cases like BSD jails. hurd appears to have something equivalent. Thanks for letting us know. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Making Debian ports less burdensome
Hi. Packages are auto-removed from testing when they are RC-buggy. Could we do something similar in unstable, for Debian's ports? A FTBFS on any *one* release arch, delays testing migration on all arches. It makes the package RC-buggy, which could trigger its autoremoval from testing if not handled. Before release, the out-of-date package must either be fixed, or ftpmaster requested to remove it on the release arches where it FTBFS. There are some things I think we should do routinely, and I suggest we start to automate: * FTBFS bugs should be filed. Perhaps not immediately, but when a particular port is starting to delay testing migration. Porters need to actually be copied on these bugs, either to a mailing list and/or usertagged would be nice; since a lot of the time the porters simply don't get any notification. * If left unfixed, the bugs should trigger an auto-removal from unstable so that the package can migrate on the other arches. It also means the FTBFS bugs can be downgraded to non-RC, and helps packages to get back into a releaseable state. And it cleans up the archive, allowing old source packages to go away after transitions complete. * Some packages are too essential to autoremove. The testing autoremoval script has some list of those and we'd like to define something similar for each port. Then, the bulk of porting efforts can be concentrated here, where it matters most. RC bugs in these packages might be reasonable justification for a port not being part of the official release. Hopefully we'd see ports with the 'core' packages in good shape, and therefore being releaseable. Even if some of them are very lightweight, not having all the desktop environments, tasks, or OpenJDK for example. Having a stable set of build-essential packages is important for ports to get DSA-administered buildds, for developers to be able to run it, and for the port to progress further. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#816237: procps: FTBFS[!linux]: fails to compile test_process
Package: procps
Version: 2:3.3.11-3
Severity: important
Tags: patch
Hi,
procps FTBFS on kfreebsd and hurd due to:
| gcc -std=gnu99 -DHAVE_CONFIG_H -I. -include ./config.h -I. -I./include
-DLOCALEDIR=\"/usr/share/locale\" -Wdate-time -D_FORTIFY_SOURCE=2 -Iproc -g -O2
-fstack-protector-strong -Wformat -Werror=format-security -MT
lib/test_process.o -MD -MP -MF $depbase.Tpo -c -o lib/test_process.o
lib/test_process.c &&\
| mv -f $depbase.Tpo $depbase.Po
| lib/test_process.c:24:23: fatal error: sys/prctl.h: No such file or directory
| compilation terminated.
https://buildd.debian.org/status/fetch.php?pkg=procps&arch=kfreebsd-amd64&ver=2%3A3.3.11-3&stamp=1451806495
What we could do is comment out the Linux-specific include and function
call. It makes test_process rather non-functional, but it seems to not
matter because it doesn't appear to be used during the package build
anyway. I've attached a patch.
Also, the debian/*.install files needed to be updated for these
architectures. I've attached a debdiff for those, tested on
kfreebsd-amd64, but I tried to fix it for hurd-i386 also.
Thanks.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- a/lib/test_process.c
+++ b/lib/test_process.c
@@ -21,7 +21,9 @@
#include
#include
#include
+#ifdef __linux__
#include
+#endif
#include "c.h"
#define DEFAULT_SLEEPTIME 300
@@ -78,8 +80,10 @@
sigaction(SIGUSR1, &signal_action, NULL);
sigaction(SIGUSR2, &signal_action, NULL);
+#ifdef __linux__
/* set process name */
prctl(PR_SET_NAME, MY_NAME, NULL, NULL, NULL);
+#endif
while (sleep_time > 0) {
sleep_time = sleep(sleep_time);
diff -Nru procps-3.3.11/debian/procps.install.hurd procps-3.3.11/debian/procps.install.hurd
--- procps-3.3.11/debian/procps.install.hurd 2016-01-03 06:10:47.0 +
+++ procps-3.3.11/debian/procps.install.hurd 2016-02-29 00:25:59.0 +
@@ -1,4 +1,4 @@
# Files to install for hurd systems
-bin/kill bin
-bin/ps bin
+bbin/kill bin/kill.procps
+bbin/ps bin/ps.procps
bin/* /usr/bin
diff -Nru procps-3.3.11/debian/procps.install.kfreebsd procps-3.3.11/debian/procps.install.kfreebsd
--- procps-3.3.11/debian/procps.install.kfreebsd 2016-01-03 06:10:47.0 +
+++ procps-3.3.11/debian/procps.install.kfreebsd 2016-02-29 00:29:46.0 +
@@ -1,4 +1,4 @@
# Files to install for kfreebsd systems
-bin/kill bin
-bin/ps bin
+bbin/kill bin/kill.procps
+bbin/ps bin
bin/* /usr/bin
Bug#816328: light-locker: FTBFS[!linux]: unconditionally configures --with-systemd
Package: light-locker Version: 1.7.0-2 Severity: wishlist Tags: patch Hi, light-locker unconditionally configures --with-systemd, although that only makes sense on linux. Without that, it builds fine on kfreebsd and probably hurd. With that change, the libsystemd-dev build-dependency (which is listed twice BTW) is not needed any more on those platforms. Please find a debdiff attached for both these things. Thank you! -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -Nru light-locker-1.7.0/debian/control light-locker-1.7.0/debian/control --- light-locker-1.7.0/debian/control 2015-11-18 12:44:49.0 + +++ light-locker-1.7.0/debian/control 2016-02-29 22:09:16.0 + @@ -7,8 +7,8 @@ Simon Huggins Build-Depends: debhelper (>= 9), pkg-config, dh-autoreconf, liblightdm-gobject-dev (>= 1.3.5), libgtk-3-dev, libdbus-glib-1-dev, - libxss-dev, libsystemd-dev, intltool, xfce4-dev-tools, libtool, - libsystemd-dev + libxss-dev, intltool, xfce4-dev-tools, libtool, + libsystemd-dev [linux-any] Standards-Version: 3.9.6 Homepage: https://github.com/the-cavalry/light-locker/ Vcs-Svn: svn://anonscm.debian.org/pkg-xfce/goodies/trunk/light-locker diff -Nru light-locker-1.7.0/debian/rules light-locker-1.7.0/debian/rules --- light-locker-1.7.0/debian/rules 2015-07-09 16:11:26.0 +0100 +++ light-locker-1.7.0/debian/rules 2016-02-29 22:13:04.0 + @@ -3,10 +3,16 @@ export DEB_LDFLAGS_MAINT_APPEND=-Wl,--as-needed -Wl,-O1 export DEB_BUILD_MAINT_OPTIONS=hardening=+all +DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) + +ifeq ($(DEB_HOST_ARCH_OS),linux) + ARCH_OPTS := --with-systemd +endif + override_dh_auto_configure: NOCONFIGURE=1 xdt-autogen dh_auto_configure -- --disable-silent-rules \ - --with-systemd \ + $(ARCH_OPTS) \ --with-upower \ --with-console-kit \ --with-mit-ext
Bug#816334: libserialport: FTBFS[!linux]: missing _DEFAULT_SOURCE
Package: libserialport Version: 0.1.0-1 Severity: important Tags: patch Hi, libserialport FTBFS in up-to-date sid. Perhaps some recent cleanup of glibc headers triggered this, but there was a pre-existing issue here in libserialport_internal.h: 25 #ifdef __linux__ 26 /* For timeradd, timersub, timercmp. */ 27 #define _BSD_SOURCE 1 /* for glibc < 2.19 */ 28 #define _DEFAULT_SOURCE 1 /* for glibc >= 2.20 */ 29 #endif What really should be tested for is __GLIBC__, not the kernel. With the attached patch, this compiles again on kfreebsd, and probably hurd as well. Thank you! -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- a/libserialport_internal.h 2016-01-27 14:12:27.0 + +++ b/libserialport_internal.h 2016-02-29 23:30:51.701109454 + @@ -22,7 +22,7 @@ #define LIBSERIALPORT_LIBSERIALPORT_INTERNAL_H -#ifdef __linux__ +#ifdef __GLIBC__ /* For timeradd, timersub, timercmp. */ #define _BSD_SOURCE 1 /* for glibc < 2.19 */ #define _DEFAULT_SOURCE 1 /* for glibc >= 2.20 */
Bug#816352: qjackctl: FTBFS[!linux]: gethostname undeclared
Package: qjackctl Version: 0.4.1-1 Severity: important Tags: patch Hi, qjackctl stopped building on kfreebsd and hurd with upstream version 0.4.1. I've attached a patch which also explains the regression: Upstream commit 5e9eb4e32a1233ca92ec3684c357cec33a38d18b removed #include , but this source file uses gethostname() if CONFIG_X11 and CONFIG_XUNIQUE are defined. On Linux the ALSA headers include unistd.h anyway, but this broke the build on Debian GNU/kFreeBSD and Hurd. So, add this back in, guarded by those macros just in case some platforms don't have or need it. Thanks! -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash >From 3a14ba3f60579d87ebf5ff3d1e8d6954baa1df05 Mon Sep 17 00:00:00 2001 From: Steven Chamberlain Date: Tue, 1 Mar 2016 03:46:44 + Subject: [PATCH] include again Upstream commit 5e9eb4e32a1233ca92ec3684c357cec33a38d18b removed #include , but this source file uses gethostname() if CONFIG_X11 and CONFIG_XUNIQUE are defined. On Linux the ALSA headers include unistd.h anyway, but this broke the build on Debian GNU/kFreeBSD and Hurd. So, add this back in, guarded by those macros just in case some platforms don't have or need it. --- src/qjackctl.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/qjackctl.cpp b/src/qjackctl.cpp index db37ed6..342d7e3 100644 --- a/src/qjackctl.cpp +++ b/src/qjackctl.cpp @@ -65,6 +65,8 @@ const WindowFlags WindowCloseButtonHint = WindowFlags(0x0800); #ifdef CONFIG_X11 #ifdef CONFIG_XUNIQUE +#include /* for gethostname() */ + #include #include -- 1.8.4.rc3
Bug#816394: elfutils: FTBFS[!linux] with gcc-6: unused const, functions
Package: elfutils
Version: 0.165-3
Severity: important
Tags: patch
Hi,
elfutils will FTBFS on kfreebsd (and I suspect on hurd) with gcc-6,
because there is an unused const and several unused, unexported stub
functions in linux-pid-attach.c inside a code block guarded by
#ifndef __linux__
A patch is attached that removes the unused code. I tested this on
kfreebsd-amd64, where all tests pass except for the skipped ones, and
dwfl-proc-attach correctly states "dwfl_linux_proc_attach unsupported"
as before.
Thank you!
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Subject: libdwfl: clean up unused code for non-Linux GNU platforms
From: Steven Chamberlain
Date: Tue, 01 Mar 2016 13:32:37 +
For non-Linux GNU platforms (like kFreeBSD, Hurd), linux-pid-attach.c
had some stub functions that are not used or exported. Since gcc-6,
having these caused compiler errors due to -Wall -Werror:
linux-pid-attach.c:479:36: error: 'pid_thread_callbacks' defined but not used [-Werror=unused-const-variable=]
linux-pid-attach.c:474:1: error: 'pid_thread_detach' defined but not used [-Werror=unused-function]
linux-pid-attach.c:461:1: error: 'pid_detach' defined but not used [-Werror=unused-function]
linux-pid-attach.c:452:1: error: 'pid_set_initial_registers' defined but not used [-Werror=unused-function]
linux-pid-attach.c:441:1: error: 'pid_memory_read' defined but not used [-Werror=unused-function]
linux-pid-attach.c:420:1: error: 'pid_getthread' defined but not used [-Werror=unused-function]
linux-pid-attach.c:410:1: error: 'pid_next_thread' defined but not used [-Werror=unused-function]
This part of the source file is guarded by #ifndef __linux__
--- a/libdwfl/linux-pid-attach.c
+++ b/libdwfl/linux-pid-attach.c
@@ -406,27 +406,6 @@
#else /* __linux__ */
-static pid_t
-pid_next_thread (Dwfl *dwfl __attribute__ ((unused)),
- void *dwfl_arg __attribute__ ((unused)),
- void **thread_argp __attribute__ ((unused)))
-{
- errno = ENOSYS;
- __libdwfl_seterrno (DWFL_E_ERRNO);
- return -1;
-}
-
-static bool
-pid_getthread (Dwfl *dwfl __attribute__ ((unused)),
- pid_t tid __attribute__ ((unused)),
- void *dwfl_arg __attribute__ ((unused)),
- void **thread_argp __attribute__ ((unused)))
-{
- errno = ENOSYS;
- __libdwfl_seterrno (DWFL_E_ERRNO);
- return false;
-}
-
bool
internal_function
__libdwfl_ptrace_attach (pid_t tid __attribute__ ((unused)),
@@ -437,32 +416,6 @@
return false;
}
-static bool
-pid_memory_read (Dwfl *dwfl __attribute__ ((unused)),
- Dwarf_Addr addr __attribute__ ((unused)),
- Dwarf_Word *result __attribute__ ((unused)),
- void *arg __attribute__ ((unused)))
-{
- errno = ENOSYS;
- __libdwfl_seterrno (DWFL_E_ERRNO);
- return false;
-}
-
-static bool
-pid_set_initial_registers (Dwfl_Thread *thread __attribute__ ((unused)),
- void *thread_arg __attribute__ ((unused)))
-{
- errno = ENOSYS;
- __libdwfl_seterrno (DWFL_E_ERRNO);
- return false;
-}
-
-static void
-pid_detach (Dwfl *dwfl __attribute__ ((unused)),
- void *dwfl_arg __attribute__ ((unused)))
-{
-}
-
void
internal_function
__libdwfl_ptrace_detach (pid_t tid __attribute__ ((unused)),
@@ -470,22 +423,6 @@
{
}
-static void
-pid_thread_detach (Dwfl_Thread *thread __attribute__ ((unused)),
- void *thread_arg __attribute__ ((unused)))
-{
-}
-
-static const Dwfl_Thread_Callbacks pid_thread_callbacks =
-{
- pid_next_thread,
- pid_getthread,
- pid_memory_read,
- pid_set_initial_registers,
- pid_detach,
- pid_thread_detach,
-};
-
int
dwfl_linux_proc_attach (Dwfl *dwfl __attribute__ ((unused)),
pid_t pid __attribute__ ((unused)),
Re: Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure
Hi,
Andreas Beckmann wrote:
> The following tests FAILED:
> 113 - BuildDepends (Failed)
I finally figured this out!
The BuildDepends test will fail when run on a filesystem not having
sub-second granularity. So for example, it fails on kfreebsd UFS, and
whatever filesystem the hurd-i386 buildds have, and also maybe some
Linux fileystems too.
| if(EXISTS ${BuildDepends_BINARY_DIR}/Project/multi2-real.txt)
| if(${BuildDepends_BINARY_DIR}/Project/multi2-real.txt
| IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt)
| message(STATUS "multi2-real.txt is newer than multi2-stamp.txt")
| else()
| message(SEND_ERROR "Project did not initially build properly: "
| "multi2-real.txt is not newer than multi2-stamp.txt")
If multi2-real.txt and multi2-stamp.txt are created within 1 second of
each other, the test will most likely fail on those filesystems.
I think the testcase should allow something like "newer or equal to".
I don't know if there's a CMake macro to do exactly that.
By reversing the operands and the logic, it is possible to test for
"multi2-stamp.txt newer than multi2-real.txt" as a failure condition,
and therefore "multi2-real.txt newer or equal to multi2-stamp.txt" will
be regarded a success, which is exactly what we want here.
A patch is attached. I can't test it fully, because my kfreebsd systems
are not affected by this bug: they use ZFS, which does have sub-second
file timestamps. At least with this patch applied I didn't see any
regression, and on UFS... I feel lucky that this will fix it.
> 292 - RunCMake.Configure (Failed)
I didn't look at that other test failure yet...
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
Date: Wed, 06 Apr 2016 22:28:55 +0100
From: Steven Chamberlain
Subject: Tests: allow newer or equal timestamps in BuildDepends
Allow timestamps to be newer *or equal* in BuildDepends, in case the
filesystem lacks sub-second granularity (such as UFS on FreeBSD).
The test logic is changed from A > B, to !(B > A), i.e. A >= B
--- a/Tests/BuildDepends/CMakeLists.txt
+++ b/Tests/BuildDepends/CMakeLists.txt
@@ -202,12 +202,12 @@
endif()
if(EXISTS ${BuildDepends_BINARY_DIR}/Project/multi2-real.txt)
- if(${BuildDepends_BINARY_DIR}/Project/multi2-real.txt
- IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt)
-message(STATUS "multi2-real.txt is newer than multi2-stamp.txt")
- else()
+ if(${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt
+ IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-real.txt)
message(SEND_ERROR "Project did not initially build properly: "
- "multi2-real.txt is not newer than multi2-stamp.txt")
+ "multi2-real.txt timestamp is not >= multi2-stamp.txt")
+ else()
+message(STATUS "multi2-real.txt timestamp is >= multi2-stamp.txt")
endif()
else()
message(SEND_ERROR "Project did not initially build properly: "
@@ -216,12 +216,12 @@
if(TEST_MULTI3)
if(EXISTS ${BuildDepends_BINARY_DIR}/Project/multi3-real.txt)
-if(${BuildDepends_BINARY_DIR}/Project/multi3-real.txt
-IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi3-stamp.txt)
- message(STATUS "multi3-real.txt is newer than multi3-stamp.txt")
-else()
+if(${BuildDepends_BINARY_DIR}/Project/multi3-stamp.txt
+IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi3-real.txt)
message(SEND_ERROR "Project did not initially build properly: "
-"multi3-real.txt is not newer than multi3-stamp.txt")
+"multi3-real.txt timestamp is not >= multi3-stamp.txt")
+else()
+ message(STATUS "multi3-real.txt timestamp is >= multi3-stamp.txt")
endif()
else()
message(SEND_ERROR "Project did not initially build properly: "
@@ -405,12 +405,12 @@
endif()
if(EXISTS ${BuildDepends_BINARY_DIR}/Project/multi2-real.txt)
- if(${BuildDepends_BINARY_DIR}/Project/multi2-real.txt
- IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt)
-message(STATUS "multi2-real.txt is newer than multi2-stamp.txt")
- else()
+ if(${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt
+ IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-real.txt)
message(SEND_ERROR "Project did not rebuild properly: "
- "multi2-real.txt is not newer than multi2-stamp.txt")
+ "multi2-real.txt timestamp is not >= multi2-stamp.txt")
+ else()
+message(STATUS "multi2-real.txt is >= multi2-stamp.txt")
endif()
else()
message(SEND_ERROR "Project did not rebuild properly: "
@@ -419,12 +419,12 @@
if(TEST_MULTI3)
if(EXISTS ${BuildDepends_BINARY_DIR}/Project/multi3-real.txt)
-if(${BuildDepends_BINARY_DIR}/Project
Re: Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure
Hi,
Andreas Beckmann wrote:
> 292 - RunCMake.Configure (Failed)
Could someone with access to the hurd-i386 or kfreebsd porter boxes
try the attached patch please?
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- a/Tests/RunCMake/Configure/RunCMakeTest.cmake
+++ b/Tests/RunCMake/Configure/RunCMakeTest.cmake
@@ -16,7 +16,7 @@
file(WRITE "${input}" "1")
file(WRITE "${depend}" "1")
run_cmake(RerunCMake)
-execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 1) # handle 1s resolution
+execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 2) # handle 1s resolution
file(WRITE "${input}" "2")
run_cmake_command(RerunCMake-build1 ${CMAKE_COMMAND} --build .)
file(WRITE "${depend}" "2")
signature.asc
Description: Digital signature
Re: Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure
Steven Chamberlain wrote: > Could someone with access to the hurd-i386 or kfreebsd porter boxes > try the attached patch please? Here's how to run that test on its own, verbosely, in an already-built Debian build tree: $ Build/bin/cmake "-DCMAKE_MODULE_PATH=Tests/RunCMake" "-DRunCMake_GENERATOR=Unix Makefiles" "-DRunCMake_GENERATOR_PLATFORM=" "-DRunCMake_GENERATOR_TOOLSET=" "-DRunCMake_MAKE_PROGRAM=/usr/bin/make" "-DRunCMake_SOURCE_DIR=$(pwd)/Tests/RunCMake/Configure" "-DRunCMake_BINARY_DIR=$(pwd)/Build/Tests/RunCMake/Configure" "-P" "Tests/RunCMake/Configure/RunCMakeTest.cmake" Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure
Hi, > Steven Chamberlain writes: > > Could someone with access to the hurd-i386 or kfreebsd porter boxes > > try the attached patch please? Christoph Egger wrote: > Start 284: RunCMake.Configure > 284/371 Test #284: RunCMake.Configure > ...***Failed3.19 sec I have a wild idea what might be happening here. Please could you try the attached instead? You don't need to recompile the whole thing but only run the single test again with this change, if you still have the build tree around. The test was designed to detect cases of CMake running 'again' unexpectedly, after the explicit run_cmake(RerunCMake). After writing a new value "2" to CustomCMakeInput.txt, which is not a declared dependency, it is expected that CMake will not run again and copy it to the output file (CustomCMakeStamp.txt). My guess is... if the declared dependency (CustomCMakeDepend.txt) and output (CustomCMakeOutput.txt) have exactly the same timestamp, it doesn't know for sure that the output is up-to-date, so it errs on the side of running again, triggering the bug. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure
Samuel Thibault wrote: > Nothing was attached :) Sorry - attached! Christoph found that increasing some of these sleeps to 3 seconds allowed the test to pass *some* of the time. The first sleep in Tests/RunCMake/Configure/RunCMakeTest.cmake should make CustomCMakeOutput.txt newer than CustomCMakeDepend.txt The sleep in Tests/RunCMake/Configure/RerunCMake.cmake is intended to make CMakeCache.txt newer than ConfigureFileOutput.txt Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure
Samuel Thibault wrote:
> BTW, you may find
> set abort_noattach=ask-yes
>
> useful in .muttrc :)
Thanks! I will try that. And maybe more sleep, or coffee.
Patch might be attached.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- a/Tests/RunCMake/Configure/RunCMakeTest.cmake
+++ b/Tests/RunCMake/Configure/RunCMakeTest.cmake
@@ -15,6 +15,7 @@
set(output "${RunCMake_TEST_BINARY_DIR}/CustomCMakeOutput.txt")
file(WRITE "${input}" "1")
file(WRITE "${depend}" "1")
+execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 1) # handle 1s resolution
run_cmake(RerunCMake)
execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 1) # handle 1s resolution
file(WRITE "${input}" "2")
--- a/Tests/RunCMake/Configure/RerunCMake.cmake
+++ b/Tests/RunCMake/Configure/RerunCMake.cmake
@@ -9,3 +9,5 @@
file(READ ${depend} content)
file(WRITE ${output} "${content}")
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS RerunCMake.txt)
+
+execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 1) # handle 1s resolution
signature.asc
Description: Digital signature
Re: Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure
Hi,
I've tried looking at this from the other direction -- on ZFS
with high-resolution timestamps, I'm trying to find a way to reproduce
the issue as seen on the Debian buildds.
Here are timestamps in Build/Tests/RunCMake/Configure/RerunCMake-build/
right after `file(WRITE "${input}" "2")`, normally:
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:48:45.070227065 +
CustomCMakeDepend.txt
drwxr-xr-x 6 pbuilder1 build6 2016-04-07 13:48:45.070227065 + ..
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:48:45.086227203 +
CustomCMakeStamp.txt
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:48:45.087227201 +
CustomCMakeOutput.txt
-rw-r--r-- 1 pbuilder1 build 4308 2016-04-07 13:48:45.125227266 +
CMakeCache.txt
-rw-r--r-- 1 pbuilder1 build 1420 2016-04-07 13:48:45.126227116 +
cmake_install.cmake
-rw-r--r-- 1 pbuilder1 build 3940 2016-04-07 13:48:45.126227116 + Makefile
drwxr-xr-x 3 pbuilder1 build 10 2016-04-07 13:48:45.127227322 + CMakeFiles
drwxr-xr-x 3 pbuilder1 build 10 2016-04-07 13:48:45.127227322 + .
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:48:45.128227034 +
CustomCMakeInput.txt
If I change all files except CustomCMakeInput.txt to have identical
timestamps, then I can reproduce the bug as seen on the buildds:
-rw-r--r-- 1 pbuilder1 build 1420 2016-04-07 13:46:31.600236000 +
cmake_install.cmake
-rw-r--r-- 1 pbuilder1 build 3940 2016-04-07 13:46:31.600236000 + Makefile
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:31.600236000 +
CustomCMakeStamp.txt
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:31.600236000 +
CustomCMakeOutput.txt
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:31.600236000 +
CustomCMakeDepend.txt
drwxr-xr-x 3 pbuilder1 build 10 2016-04-07 13:46:31.600236000 + CMakeFiles
-rw-r--r-- 1 pbuilder1 build 4308 2016-04-07 13:46:31.600236000 +
CMakeCache.txt
drwxr-xr-x 6 pbuilder1 build6 2016-04-07 13:46:31.600236252 + ..
drwxr-xr-x 3 pbuilder1 build 10 2016-04-07 13:46:32.653236466 + .
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:32.673236479 +
CustomCMakeInput.txt
leads to:
Expected stamp '1' but got: '2'
And finally, it seems I can avoid that happening by making just the
Makefile have a newer timestamp than the others. The bug is no longer
reproducible then:
-rw-r--r-- 1 pbuilder1 build 1420 2016-04-07 13:46:51.367235000 +
cmake_install.cmake
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:51.367235000 +
CustomCMakeStamp.txt
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:51.367235000 +
CustomCMakeOutput.txt
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:51.367235000 +
CustomCMakeDepend.txt
drwxr-xr-x 3 pbuilder1 build 10 2016-04-07 13:46:51.367235000 + CMakeFiles
-rw-r--r-- 1 pbuilder1 build 4308 2016-04-07 13:46:51.367235000 +
CMakeCache.txt
drwxr-xr-x 6 pbuilder1 build6 2016-04-07 13:46:51.367235044 + ..
-rw-r--r-- 1 pbuilder1 build 3940 2016-04-07 13:46:52.0 + Makefile
drwxr-xr-x 3 pbuilder1 build 10 2016-04-07 13:46:52.437235005 + .
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:52.466234887 +
CustomCMakeInput.txt
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Re: Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure
Brad King wrote: > FYI, the IS_NEWER_THAN check actually documents that it returns true > when the times are exactly equal: Thanks for pointing that out! I suppose it is not working as expected, then, but I can't see why. kfreebsd does have st_mtim, and the code for that looks right to me: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFileTimeComparison.cxx;hb=v3.5.1#l151 I should try to find a smaller testcase to confirm this. I'll need to set up a UFS partition on a development machine so I can test properly. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: Bug#820429: libvigraimpex: FTBFS on kfreebsd-i386 and hurd-i386: Assertion failed: Sequence items differ at index 5
Hi, Emilio Pozuelo Monfort wrote: > Your package failed to build on hurd and kfreebsd-i386: > > Entering test suite GraphAlgorithmTestSuite > > Failure in GraphAlgorithmTest::testEdgeWeightComputation() > Assertion failed: Sequence items differ at index 5 [4.24264 != 4.24264] > (/«BUILDDIR»/libvigraimpex-1.10.0+git20160211.167be93+dfsg/test/graph_algorithm/test.cxx:543) > > 1 of 6 tests failed in test suite GraphAlgorithmTestSuite > Leaving test suite GraphAlgorithmTestSuite Looks like an issue of i386 floating point accuracy, just as we saw in ilmbase: https://bugs.debian.org/815712#187 I'll try to provide a patch for this soon-ish. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure
Hi,
I set up a UFS filesystem to build on, but could not reproduce the bug.
Please could someone try the attached diff? If it fails, please share
the exact error (does it fail at the -build1 step or at -build2?), and
because the `ls` I added will show the file timestamps, to help debug.
This is how I'm invoking the test on its own (10 times) :
$ m=0 ; n=0 ; for i in $(seq 1 10) ; do Build/bin/cmake
"-DCMAKE_MODULE_PATH=Tests/RunCMake" "-DRunCMake_GENERATOR=Unix Makefiles"
"-DRunCMake_GENERATOR_PLATFORM=" "-DRunCMake_GENERATOR_TOOLSET="
"-DRunCMake_MAKE_PROGRAM=/usr/bin/make"
"-DRunCMake_SOURCE_DIR=$(pwd)/Tests/RunCMake/Configure"
"-DRunCMake_BINARY_DIR=$(pwd)/Build/Tests/RunCMake/Configure" "-P"
"Tests/RunCMake/Configure/RunCMakeTest.cmake" && m=$((m+1)) ; n=$((n+1)) ; echo
"PASSED $m/$n of iterations" ; done 2>&1 | tee test.log
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- a/Tests/RunCMake/Configure/RunCMakeTest.cmake
+++ b/Tests/RunCMake/Configure/RunCMakeTest.cmake
@@ -16,9 +16,10 @@
file(WRITE "${input}" "1")
file(WRITE "${depend}" "1")
run_cmake(RerunCMake)
-execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 1) # handle 1s resolution
file(WRITE "${input}" "2")
+execute_process(COMMAND ${CMAKE_COMMAND} -E env bash -c "ls -altr --full-time ${RunCMake_TEST_BINARY_DIR}")
run_cmake_command(RerunCMake-build1 ${CMAKE_COMMAND} --build .)
+execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 1) # handle 1s resolution
file(WRITE "${depend}" "2")
run_cmake_command(RerunCMake-build2 ${CMAKE_COMMAND} --build .)
unset(RunCMake_TEST_BINARY_DIR)
signature.asc
Description: Digital signature
Bug#823684: util-linux: FTBFS[!linux]: missing uuidd
Package: util-linux Version: 2.28-1 Severity: important Tags: patch User: debian-...@lists.debian.org Usertags: kfreebsd Hi, util-linux since 2.28 FTBFS on kfreebsd and hurd, because uuidd (daemon) now depends on non-portable sys/signalfd.h Please mark the binary as [linux-any] in the uuid-runtime.install file, as in the attached patch. Thanks. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- util-linux-2.28.orig/debian/uuid-runtime.install 2016-04-12 15:10:54.0 +0100 +++ util-linux-2.28/debian/uuid-runtime.install 2016-05-07 16:18:08.467243744 +0100 @@ -1,6 +1,6 @@ #!/usr/bin/dh-exec lib/systemd/system/uuidd.* [linux-any] usr/bin/uuidgen -usr/sbin/uuidd +usr/sbin/uuidd [linux-any] usr/share/man/man1/uuidgen.* -usr/share/man/man8/uuidd.* +usr/share/man/man8/uuidd.* [linux-any]
Re: [Stretch] Status for architecture qualification
Hi, John Paul Adrian Glaubitz wrote: > I have invested lots of time and effort to get sparc64 into a usable state in > Debian. > We are close to 11.000 installed packages. Missing packages include Firefox, > Thunderbird/Icedove, golang and LibreOffice to name the most important ones. Is there some way to define 'core'[0] packages as blockers for testing migration, and arch release qualification; but other packages not? Many of these ports would be useful if just a base system was released, and preferably having stable/security updates for that part (otherwise it is difficult for users to try it, developers to work on it, or DSA to support buildds for it; all of which are limitations on ports' further growth). Trying to have *every* package build and stay built on every port, and supported for the lifetime of stable, is a lot of work without much purpose sometimes. And it's unreasonable for any one port to block testing migration of a package on all arches, unless it is something really essential. This might be done either: * in the official archive, with relaxed rules for testing migration and more frequently de-crufting of out-of-date packages; * creating a mini testing/stable suite based on debian-ports.org? where maybe only the core packages are candidates to migrate. [0]: I'd define core packages as everything needed to install, boot, and then build packages on that arch. The rebootstrap project gives us some idea of what those are; but add to that the kernel and any bootloaders. Being able to rebootstrap, should be part of the arch release qualification anyway IMHO. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#826906: uid-wrapper: FTBFS[!linux]: only supports libc.so.[0-9] filename
Package: uid-wrapper
Version: 1.2.0+dfsg1-1
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
uid-wrapper FTBFS on kfreebsd because of segfaults running every test:
| Program terminated with signal 11, Segmentation fault.
| #0 0x0008006156e1 in _dl_close () from /lib/ld-kfreebsd-x86-64.so.1
| #1 0x00080060f7d4 in _dl_catch_error () from /lib/ld-kfreebsd-x86-64.so.1
| #2 0x000800f99511 in _dlerror_run () from
/lib/x86_64-kfreebsd-gnu/libdl.so.2
| #3 0x000800f98fef in dlclose () from /lib/x86_64-kfreebsd-gnu/libdl.so.2
| #4 0x000800825281 in uwrap_destructor () at
| /home/steven/uid-wrapper-1.2.0+dfsg1/src/uid_wrapper.c:2133
| u =
| #5 0x00080060ff17 in _dl_fini () from /lib/ld-kfreebsd-x86-64.so.1
| #6 0x000800c69a78 in __run_exit_handlers () from
/lib/x86_64-kfreebsd-gnu/libc.so.0.1
| #7 0x000800c69ac5 in exit () from /lib/x86_64-kfreebsd-gnu/libc.so.0.1
| #8 0x000800c551a7 in __libc_start_main () from
/lib/x86_64-kfreebsd-gnu/libc.so.0.1
| #9 0x00400847 in _start ()
https://buildd.debian.org/status/fetch.php?pkg=uid-wrapper&arch=kfreebsd-amd64&ver=1.2.0%2Bdfsg1-1&stamp=1449681825
I found this happens because src/uid_wrapper.c doesn't detect the libc's
filename. It matches libc.so.[0-9] whereas on kfreebsd it is named
libc.so.0.1 currently.
The same problem will affect hurd too, which has libc.so.0.3 (although
there are other reasons for FTBFS on hurd).
Please consider the attached patch to detect libc.so.0.[0-9] as well.
Unless there is some neater way to do this. Thanks a lot!
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Date: Fri, 10 Jun 2016 02:06:45 +0100
From: Steven Chamberlain
Subject: support libc soname 0.x
On some glibc-based platforms, the libc soname is not an integer, such
as 0.1 on kfreebsd and 0.3 on hurd.
--- a/src/uid_wrapper.c
+++ b/src/uid_wrapper.c
@@ -407,6 +407,11 @@
if (handle != NULL) {
break;
}
+snprintf(soname, sizeof(soname), "libc.so.0.%d", i);
+handle = dlopen(soname, flags);
+if (handle != NULL) {
+ break;
+}
}
uwrap.libc.handle = handle;
Re: Bug#830894: override: initscripts:admin/optional
Hi, Michael Biebl wrote: > Afaics, there weren't any concerns raised by our -hurd@ and -bsd@ > maintainers so far. If you need more time to evaluate the change, please > speak up now. Otherwise I'd ask the ftp-masters to proceed with > implementing the change. I don't foresee any problems. I presume this doesn't affect the installer; when we start to build live images we'll ensure the necessary init system packages get installed; if any packages need to be manually specified now when debootstrapping a BSD jail, I will update the Wiki instructions (we don't actually need /sbin/init for those, so this change is probably an improvement).. Thanks for heads-up. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#854074: gcc-6: please enable PIE hardening flags by default on kfreebsd-*
Hi, Matthias Klose wrote: > [CCing porters, please also leave feedback in #835148 for non-release > architectures] Since that bug is done/closed/actioned, I've cloned a new one for this request. > On 29.09.2016 21:39, Niels Thykier wrote: > > As agreed on during the [meeting], if there are no major concerns to > > this proposal in general within a week, I shall file a bug against GCC > > requesting PIE by default on all release architectures (with backing > > porters). I think we are ready for this now; please enable PIE by default on kfreebsd-* when it is practical (or rather, allow dpkg-buildflags to enable it). Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: debian-installer now available in Ports
Hello, John Paul Adrian Glaubitz wrote: > Thus, I was wondering whether any volunteers would be willing to help building > ISO images for the various architectures. I'm already doing this for kfreebsd-amd64, but only the jessie-kfreebsd suite: http://jenkins.kfreebsd.eu/jenkins/view/cd/job/debian-cd_jessie-kfreebsd/lastBuild/console and I had to patch debian-cd before it worked. (Didn't yet find time to file bugs or submit those patches). I could probably set up similar jobs for kfreebsd-* sid now. > It's not necessary to run debian-cd on the same architecture as the > target architecture of the ISO images. I did not even realise that. So I will add kfreebsd-i386 next. I expect there might be problems trying to build linux arches from a kfreebsd host. But we should try to find out, and then maybe fix it. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: debian-installer now available in Ports
I've set up some additional jobs at
http://jenkins.kfreebsd.eu/jenkins/view/cd/
and after much trial-and-error, there are now (untested) sid netinst
images built for:
hurd-i386 kfreebsd-amd64 kfreebsd-i386 powerpc
You can find the .iso images within each job's workspace e.g.:
http://jenkins.kfreebsd.eu/jenkins/view/cd/job/debian-cd_sid_hurd-i386/ws/build/
It's building on a kfreebsd-amd64 host, in a jessie-kfreebsd chroot,
with current Git master of debian-cd, my patches for #860187 and
#860204 applied, and the attached diff against CONF.sh. I started each
build like this:
$ export CODENAME=sid
$ export ARCHES=hurd-i386
$ CONF.sh && ./build.sh
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/CONF.sh b/CONF.sh
index 99e58ad..08ffbd7 100644
--- a/CONF.sh
+++ b/CONF.sh
@@ -62,11 +62,15 @@ export BASEDIR=`pwd`
# export CDNAME=debian
# Building $codename cd set ...
-export CODENAME=stretch
+#export CODENAME=stretch
# By default use Debian installer packages from $CODENAME
if [ -z "$DI_CODENAME" ]; then
- export DI_CODENAME=$CODENAME
+ if [ "${CODENAME}" = "jessie-kfreebsd" ]; then
+ export DI_CODENAME=${CODENAME}-proposed-updates
+ else
+ export DI_CODENAME=${CODENAME}
+ fi
fi
# If you want backported d-i (e.g. by setting
# DI_CODENAME=jessie-backports, then you'll almost definitely also
@@ -86,7 +90,7 @@ fi
#export DI_WWW_HOME=default
# Version number, "2.2 r0", "2.2 r1" etc.
-export DEBVERSION="9.0"
+export DEBVERSION="unofficial"
# Official or non-official set.
# NOTE: THE "OFFICIAL" DESIGNATION IS ONLY ALLOWED FOR IMAGES AVAILABLE
@@ -119,17 +123,17 @@ fi
# images, however. Also, if you are using an NFS partition for
# some part of this, you must use this option.
# Paths to the mirrors
-export MIRROR=/srv/mirror/debian
+export MIRROR=/srv/ftp.debian.org
# Path of the temporary directory
-export TDIR=/srv/mirror/tmp
+export TDIR=/home/cd/tmp
# Path where the images will be written
-export OUT=/srv/mirror/debian-cd-test
+export OUT=/home/cd/out
# Where we keep the temporary apt stuff.
# This cannot reside on an NFS mount.
-export APTTMP=/srv/mirror/tmp/apt
+export APTTMP=$TDIR/apt
# Do I want to have NONFREE merged in the CD set
# export NONFREE=1
@@ -164,7 +168,9 @@ export CONTRIB=1
# Note that on the CDs it will not be visible where packages came from:
# from the released archive or from proposed updates archive.
# NOTE: intended to be used for pre-release testing, not for publication!
-#export PROPOSED_UPDATES=$CODENAME-proposed-updates
+if [ "${CODENAME}" = "jessie-kfreebsd" ]; then
+ export PROPOSED_UPDATES=$CODENAME-proposed-updates
+fi
# Sparc only : bootdir (location of cd.b and second.b)
# export BOOTDIR=/boot
@@ -175,7 +181,7 @@ export CONTRIB=1
# Use this to force copying the files instead of symlinking or hardlinking
# them. This is useful if your destination directories are on a different
# partition than your source files.
-# export COPYLINK=1
+export COPYLINK=1
# Options
# export MKISOFS=mkisofs
@@ -190,6 +196,12 @@ export CONTRIB=1
#export i386_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso md5,sha1"
#export amd64_MKISOFS="xorriso"
#export amd64_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso md5,sha1"
+export hurd_i386_MKISOFS="xorriso"
+export hurd_i386_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso sha256"
+export kfreebsd_i386_MKISOFS="xorriso"
+export kfreebsd_i386_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso sha256"
+export kfreebsd_amd64_MKISOFS="xorriso"
+export kfreebsd_amd64_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso sha256"
# Keyring (defaults):
#ARCHIVE_KEYRING_PACKAGE=debian-archive-keyring
@@ -233,7 +245,7 @@ ATTEMPT_FALLBACK=yes
# STICK4GB: 4GB USB stick or similar
# STICK8GB: 8GB USB stick or similar
# CUSTOM:up to you - specify a size to go with it (in 2K blocks)
-export DISKTYPE=CD
+export DISKTYPE=NETINST
#export DISKTYPE=CUSTOM
#export CUSTOMSIZE=
# If you want to over-ride this choice (e.g. to make a larger version of a given disk),
@@ -242,7 +254,7 @@ export DISKTYPE=CD
# export FORCE_CD_SIZE1= to change the size of disk 1 (only)
# Extra variants to enable. See docs/README.variants for more information.
-export VARIANTS=
+export VARIANTS=light
# We don't want certain packages to take up space on CD1...
#export EXCLUDE1=exclude
@@ -375,8 +387,8 @@ export SNAPURL=Debian=http://snapshot.debian.org/archive/debian/SNAPDATETIME/
# INSTALLER_CD=0: nothing special (default)
# INSTALLER_CD=1: just add debian-installer (use TASK=debian-installer)
# INSTALLER_CD=2: add d-i and base (use TASK=debian-installer+kernel)
-#export INSTALLER_CD=2
-#export TASK=debian-installer+ke
Re: Is the debian-doc kfreeBSD-ready?
On 11/04/12 07:34, Robert Millan wrote: > El 11 d’abril de 2012 5:24, David Prévot ha escrit: > | Debian is a free operating system (OS) for your computer. An operating > | system is the set of basic programs and utilities that make your > | computer run. Debian uses the Linux or FreeBSD kernel (the core of an > | operating system), but most of the basic OS tools come from the GNU > | project; hence the name Debian GNU/Linux or Debian GNU/kFreeBSD. > > This is saying that FreeBSD is a kernel, and that Debian uses it... What about: "Debian can use either the Linux kernel or kFreeBSD at its core, but most of the basic OS tools come from the GNU project; hence the names Debian GNU/Linux or Debian GNU/kFreeBSD." Since kFreeBSD is the the kernel's name. And it is also redundant to speak of "a kFreeBSD kernel". But when speaking of Linux it's unfortunately necessary to be specific when referring only to the kernel. And I used the word 'can' to try to leave open the idea that other kernels for Debian could exist (like Hurd) even if only the release architectures are named here. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f8567c9.5030...@pyro.eu.org
Re: Is the debian-doc kfreeBSD-ready?
On 11/04/12 19:16, Robert Millan wrote: > El 11 d’abril de 2012 14:26, Nicolas Barbier > ha escrit: >> What about using “kernel of FreeBSD” and indicating that the >> abbreviation for that is “kFreeBSD”? E.g.: >> >> “Debian can use either Linux or the kernel of FreeBSD (called >> kFreeBSD) at its core” > > I agree. However, the "called" makes it look like we're an > authoritative source (and officially, the kernel of FreeBSD doesn't > have a name of its own). Or... maybe just skip the bracketed part, because the term is already introduced in the second half of the (rather long) sentence: "Debian can use the kernel of either Linux or FreeBSD at its core, but most of the basic OS tools come from the GNU project; hence the names Debian GNU/Linux or Debian GNU/kFreeBSD." Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f85ccca.4040...@pyro.eu.org
Re: defaulting to GCC-4.7 for kfreebsd and the hurd?
On 27/04/12 13:31, Matthias Klose wrote: > I'm now planning to default to GCC 4.7 for amd64 and i386. Should kfreebsd > and > the hurd do change at the same time, or should these stay with 4.6? In case it is relevant to this decision: gcc-4.6 has been failing to build on kfreebsd-* since the enable-gnu-unique-object configure option was enabled (from 4.6.3-2) : > Error: symbol type "gnu_unique_object" is supported only by GNU targets Whereas gcc-4.7 has built okay since that option was disabled on kfreebsd-* and hurd-i386 (from 4.7.0~rc2-1). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f9a9930.7040...@pyro.eu.org
Re: Bug#669059: webkit-1.8.0-2: FTBFS on hurd-*
[I took #669059 out of CC to not clutter the open bug] On 27/04/12 22:33, Svante Signell wrote: > This is incredible: The Debian maintainer uploads a fixed version for > kFreeBSD (and partially for GNU/Hurd by adding __GLIBC__) and meanwhile > totally neglecting the additional small changes needed for a successful > build for GNU/Hurd in this bug report and in bug #664810. I wonder which > agendas they have, only architectures already in testing, and ignoring > everything else? Hi, It is a shame, but I doubt the maintainer is ignoring GNU/Hurd on purpose. #669308 simply had higher severity in the BTS, and held up testing migration for everyone, because GNU/kFreeBSD is fortunate enough to be classed as a 'release architecture' already. The patch for #669059 then would have conflicted with mine and I'm sorry for that. And the maintainer maybe didn't have time to merge/include it yet for this upload. The situation is awkward for GNU/Hurd because fixing things like webkit (with lots of dependencies waiting on it) is important towards becoming a release architecture too. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f9b1a46.8090...@pyro.eu.org
Re: Bug#669059: webkit-1.8.0-2: FTBFS on hurd-*
On 27/04/12 23:26, Svante Signell wrote: > GNU/Hurd is currently struggling to > getting into testing too, so when things like this happens, they are > _very_ unfortunate. Yes it will be very difficult, a slow climb, but once you reach that new level, everything will become much easier from there on, when FTBFS bugs on hurd-* are treated as release-critical and given a higher priority to be fixed by maintainers. And from the release publicity you would no doubt have many more interested users and developers helping you with the port by then. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f9b205e.6050...@pyro.eu.org
Re: Bug#670722: perl-base: IO::Socket::UNIX::hostpath dies on kFreeBSD
On 06/05/12 22:01, Dominic Hargreaves wrote: >>> As for GNU/Hurd, my guess is that it doesn't have that header at all... Oops, since I didn't see the file in the packages.debian.org search results, I assumed hurd-i386 didn't have it... > Good point. The test does fail on hurd-i386 too. If you're able to test this on a GNU/Hurd box you can try: # if defined(__linux__) || defined(__GNU__) || defined(__GLIBC__) Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa6e78e.2030...@pyro.eu.org
Re: Architecture qualification
On 30/05/12 13:10, Philipp Kern wrote: > I wonder how that makes a difference, even psychologically. We don't mail > failed builds for hurd-i386 to maintainers for example. Actually, when looking into kfreebsd-* issues, I find it very helpful to see hurd-i386 on buildd.d.o, along with log excerpts of build failures and past build attempts. As it is the only other non-Linux arch, info from hurd-i386 buildds is often relevant. And if I submit a patch for something, I have a habit of checking back on those pages for 'all green' even though I'm not a maintainer. Without a hurd-i386 box to test on it may be the only source of feedback. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc6585f.9030...@pyro.eu.org
Re: hurd-i386 qualification for Wheezy
On 30/05/12 10:54, Samuel Thibault wrote: > We can as well not aim at an official release, and make an unofficial > release. In my opinion that'd be already great. Sounds good, I'd love for hurd-i386 to be able to go through the motions of a release even if it's not part of the official one. Ideally I'd want to be able to download install media with jigdo, pulling packages from official mirrors (only). I'm not sure if that's possible until hurd-i386 actually enters testing? And if there are bugs / missing functionality making this not possible yet, well, that's where work is needed :) Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc65f0a.9080...@pyro.eu.org
Re: suggested fix
Hi Nicholas, On 20/06/12 12:53, Nicholas Bamber wrote: > Sorry I didn't notice the FTBS on hurd as I was concentrating on the > red. I guess I should have trusted the bug report title more. I only noticed on buildd.d.o that the failure was the same there. > However I am confused at what your are proposing. If you're not convinced, then the patch you have is fine. It would fix the immediate FTBFS on kfreebsd-* and this could be revisited later. I was only trying to kill two (or more) birds with one stone here, by accommodating GNU/Hurd, and keeping portability to some other future k*BSD port, and if the patch is forwarded upstream they might like it to fix this on other arches they support. > For a start I cannot > find a net/if_dl.h file on Hurd. I'm not sure... be warned that packages.d.o might not be indexing package contents for GNU/Hurd. (At least once before this has caught me out). For the Hurd, I thought, if the header inclusion test was AF_LINK: 1. if it supports sockaddr_dl, and has net/if_dl.h, it would be fixed 2. if it supports sockaddr_dl, but currently lacks net/if_dl.h, the new build error would make the problem clearer, and it could build in future without changes after they provide the missing net/if_dl.h 3. if it doesn't support sockaddr_dl, the AF_LINK test is wrong in _both_ places so it wouldn't be able to build anyway; we'd be no worse-off. > Secondly I am not clear if using > AF_LINK as a conditional is a good idea. Surely that would change the > code on Linux, which is surely not what we want to do. I was assuming that platforms without sockaddr_dl don't define AF_LINK. I don't see it in the Linux headers. And the FXR pages also showed a correlation between AF_LINK being defined on a platform, and the existence of a net/if_dl.h containing the definition of sockaddr_dl. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe1c16f.8090...@pyro.eu.org
Re: suggested fix
On 20/06/12 15:59, Nicholas Bamber wrote: > Based upon the feedback I have received (including #debian-hurd) I am > attaching a new debdiff. This debdiff doesn't address the main point of my original mail: sockaddr_dl and net/if_dl.h are not (k)FreeBSD-specific, so a test for FreeBSD || FreeBSD_kernel would not be appropriate. It might "work" but would only replace one portability issue with another. The new test for AF_LINK && !GNU looks even worse to me. Does GNU/Hurd _really_ define AF_LINK and yet not provide a net/if_dl.h with a definition for sockaddr_dl? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe23ac7.6020...@pyro.eu.org
Re: suggested fix
On 20/06/12 22:09, Nicholas Bamber wrote: > On 20/06/12 22:04, Steven Chamberlain wrote: >> This debdiff doesn't address the main point of my original mail: >> sockaddr_dl and net/if_dl.h are not (k)FreeBSD-specific, so a test for >> FreeBSD || FreeBSD_kernel would not be appropriate. You still didn't address that in your reply. > As I understood it you wanted the build to fail on Hurd so everyone > would know there was an AF_LINK/sockaddr_dl bug on Hurd. If there is really an issue in GNU/Hurd, such as a missing header, then yes, I'd prefer that the build fails[1], rather than add a workaround (with whatever consequences) to this package (which someone would have to remember to remove at the appropriate time, to restore the intended functionality). As it happens, if a workaround for the current FTBFS is all that's needed, the attached diff would be able to do that very cleanly. [1] Just to make sure this isn't the cause of any confusion: FTBFS on GNU/Hurd is not a blocker for Wheezy, testing migration or transitions. Regards, -- Steven Chamberlain ste...@pyro.eu.org --- pmacct-0.14.0.orig/src/isis/sockunion.c 2012-03-28 18:46:09.0 +0100 +++ pmacct-0.14.0/src/isis/sockunion.c 2012-06-20 22:32:29.672205632 +0100 @@ -596,6 +596,7 @@ return NULL; } +#if 0 /* Print sockunion structure */ static void __attribute__ ((unused)) sockunion_print (union sockunion *su) @@ -634,6 +635,7 @@ break; } } +#endif #ifdef ENABLE_IPV6 static int
Re: suggested fix
On 21/06/12 08:57, Nicholas Bamber wrote: > 3.) You seem to see it fit to willfully cause an FTBS on Hurd, to make a > point. To willfully allow an existing FTBFS on GNU/Hurd, to become a more explanatory FTBFS, which would someday go away and keep the intended functionality once the cause had been resolved in its build-deps. > So I have raised a bug: #678358 to address the underlying issue. Yes that was the nice thing to do here, thanks. > * use #if defined(AF_LINK) && !defined(__GNU__) in both places as that > is as close to a feature check as we can get I'm fine with that, as it would be consistent, and it addresses the most important point which was the original test for (k)FreeBSD being too specific. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe2f3f5.1090...@pyro.eu.org
Re: Continuous Integration of the Debian Installer?
Hi, On 13/10/12 00:11, Luca Favatella wrote: > Is there a Continuous Integration (CI) infrastructure in place for > testing the Debian Installer (d-i)? > http://en.wikipedia.org/wiki/Continuous_integration > > It would be nice testing automatically the different installation > paths (CLI vs. GUI, various setups of ZFS) for the daily images of the > d-i, especially for architectures without lots of users (e.g. > kfreebsd-*). There's probably nothing like this for GNU/kFreeBSD at the moment (that I know of). I actually had the idea to see if something like `qemu -curses` could be driven from 'expect' scripts, to navigate the menus, following some script and see that it at least completes the installer successfully, from each day's daily d-i image. This would catch most of the regressions we've seen so far. And writing extra scripts to try specific configurations/features would be much easier after that. Pre-seeding should be another way to do the same, but it is still beneficial to be testing via the text/GUI menus as well if possible. So, yes I think this would be a great idea! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5078beb0.5090...@pyro.eu.org
Re: Bug#631968: aborts on start (GNU/kFreeBSD)
Hi, On 22/10/12 12:55, Samuel Thibault wrote: > Simon McVittie, le Mon 22 Oct 2012 10:13:35 +0100, a écrit : >> (I can't help wondering why anyone would ever try to use an X11 terminal >> emulator *without* a graphical X11 session...) > > An X11 environment does *not* imply a dbus session. The only reason I tried without a 'graphical' X11 environment, is because I tried firstly to debug the crash-on-startup on a remote shell box, under xvfb instead of a real X server since there wasn't one set up. What I found is that it exits silently, in different places, depending whether a DBus session is running. It doesn't got far enough to execute any shell command given by the "-e" option. Robert Millan already bisected this to a large DBus-related commit. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/508536d8.1080...@pyro.eu.org
Re: Bug#631968: aborts on start (GNU/kFreeBSD)
reassign 631968 libglib2.0-0 found 631968 glib2.0/2.33.12+really2.32.4-2 affects 631968 gnome-terminal tags 631968 + confirmed patch thanks Hi! On 22/10/12 17:33, Simon McVittie wrote: >> I wonder whether this is to do with GDBus not supporting credentials-passing >> for authentication on kFreeBSD. It does support credentials-passing on >> FreeBSD, and it's the same kernel, so the same code ought to work; please >> try the attached patch for src:glib2.0? If successful, this can be tagged >> 'patch' and reassigned to libglib2.0-0. Thank you Simon, this is exactly the reason that gnome-terminal would fail to connect to DBus on GNU/kFreeBSD (and quits silently with exit status 1). I've just tested that your patch fixed the problem on kfreebsd-amd64; gnome-terminal now starts up and works correctly in a graphical X11 environment. The fix looks quite typical of other GNU/kFreeBSD porting issues. This probably also fixes more GNOME issues, that we didn't even know of yet. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50873685.2000...@pyro.eu.org
Re: Bug#631968: aborts on start (GNU/kFreeBSD)
affects 631968 + lightdm thanks I see that the same glib2.0 patch also fixes lightdm. On kfreebsd-amd64 I can confirm the report below that it shows only a blank screen. With this glib2.0 patch it works correctly. The issue was not filed yet in the BTS but reported recently at: http://lists.debian.org/ca+4ecjnpygh+qdxfexjdhuqoq+nvrhyw8bjzfzuynxxspy0...@mail.gmail.com Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50873d4c.6020...@pyro.eu.org
Re: python3.3 build failure on kfreebsd and the hurd
Hi, I'd say the test at Modules/posixmodule.c:114 is wrong: > #if defined(HAVE_SYS_XATTR_H) && defined(__GLIBC__) > #define USE_XATTRS > #endif Because GLIBC doesn't imply a working xattr interface (traditionally a Linux thing?). There seem to be implementations only for Linux, GNU/Hurd and as part of NetBSD Linux compatibility layer. On GNU/kFreeBSD there is only a stub for setxattr, returning -ENOSYS (not implemented). Hence there is no XATTR_SIZE_MAX defined either. For now, maybe it would be better as: > #if defined(HAVE_SYS_XATTR_H) && (defined(__linux__) || defined(__GNU__)) The other problem is that GNU/Hurd doesn't enforce a maximum size and so still doesn't define XATTR_SIZE_MAX; on NetBSD they define it like this for compatibility it seems: http://fxr.watson.org/fxr/source/sys/xattr.h?v=NETBSD5#L52 > #define XATTR_SIZE_MAX 65536 /* NetBSD does not enforce this */ So, GNU/Hurd could maybe add something like that if it helps with porting; or better still, upstream could do as Pino suggested in http://bugs.python.org/issue13669 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50997244.60...@pyro.eu.org
Re: Bug#700530: qt frames empty
Hi Julien, On 21/02/13 15:16, Julien Cristau wrote: > On Thu, Feb 21, 2013 at 00:45:04 +0000, Steven Chamberlain wrote: >> That's odd... I don't notice any such glitch with at least kcalc, kate, >> qsynth - with xorg-server/2:1.12.4-4 and qt4-x11/4:4.8.2+dfsg-11 on >> kfreebsd-amd64 (9.0, wheezy/sid not fully up-to-date). I'm using the >> Xtightvnc server if that's relevant. >> > Does Xtightvnc expose MIT-SHM? xdpyinfo would tell you. The list of extensions seems quite short, but yes MIT-SHM is mentioned (full output attached). I'll see about trying to start X 'conventionally' on that machine sometime, to compare. Can't do that until after a reboot though (it's in securelevel=1 so X/vesa can't use /dev/io currently). >> On 20/02/13 22:18, Sune Vuorela wrote: >>> The fix is surprisingly in xorg-server and can be found here: >>> http://people.debian.org/~jcristau/kbsd-peercred.diff > On Linux, the SO_PEERCRED socket option gives that information. On > FreeBSD, there's a getpeereid() libc call. GNU/Hurd has neither of these, so maybe this patch has some benefit there too? (Cc'ing debian-hurd@ because someone with such a system may want to test this patch on it.) NetBSD doesn't support these methods either, so maybe it is affected somehow. Thanks again for your work, Regards, -- Steven Chamberlain ste...@pyro.eu.org $ xdpyinfo name of display::1.0 version number:11.0 vendor string:AT&T Laboratories Cambridge vendor release number:3332 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:2 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x289, revert to Parent number of extensions:7 BIG-REQUESTS MIT-SHM MIT-SUNDRY-NONSTANDARD SHAPE SYNC XC-MISC XTEST default screen number:0 number of screens:1 screen #0: dimensions:1024x768 pixels (347x260 millimeters) resolution:75x75 dots per inch depths (1):24 root window id:0x25 depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x21 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store YES, save-unders YES largest cursor:1024x768 current input event mask:0x7a802f KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMaskLeaveWindowMask ExposureMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask number of visuals:1 default visual id: 0x22 visual: visual id:0x22 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits
Re: Hurd and the archive
On 05/05/13 16:07, Joerg Jaspert wrote: > ...released together > with all the others (probably as a technology preview)... > So, release people: How likely is it that Hurd gets added to jessie? If added as a 'technology preview', what does that mean exactly? Would Hurd-specific RC-severity bugs stall a package's transition to testing? And would it be necessary to fix all Hurd-specific RC bugs to be able to release? >From the view of maintainers I think that would be the deciding factor, because it could imply extra work. Not everyone sees the benefits of porting efforts (whereas I see it as excellent QA and promotes better software design, hence I'm in favour of inclusion). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5187de57.2000...@pyro.eu.org
Re: Hurd and the archive
On 06/05/13 20:27, Joerg Jaspert wrote: > Adding it and then keeping it out of the usual migration rules is asking > for failure from the beginning, accumulating cruft. Not a way to go, IMO. In that case would there be 150-200 RC-severity bugs introduced right away by its inclusion? (Packages which FTBFS on hurd-i386 that are already 'out of date' in sid, counting Failed + Build-Attempted) : https://buildd.debian.org/status/architecture.php?a=hurd-i386&suite=sid¬es=out-of-date This was the best figure I could think of to quantify the 'burden' of a particular arch being included in testing. For comparison, kfreebsd arches tally ~50, armel/mipsel ~50, ia64 ~60, amd64/i386 only 10-20. There is a lot of overlap though, e.g. fixing a kfreebsd build failure may fix hurd-i386. I found some mention/suggestion that for arch-specific issues, a 'technology preview' may be released even if some RC-severity bugs remain (though probably not when packages FTBFS); and relaxed criteria might be used during freeze and for stable updates: https://lists.debian.org/debian-bsd/2011/06/msg00365.html Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518810a9.9050...@pyro.eu.org
Re: Hurd and the archive
Hi Samuel, On 06/05/13 21:35, Samuel Thibault wrote: > Steven Chamberlain, le Mon 06 May 2013 21:20:57 +0100, a écrit : >> In that case would there be 150-200 RC-severity bugs introduced right >> away by its inclusion? > > I would rather say simply dropping them, as already requested in > Bug#704477. And as I said a fair amount of these are actually already > submitted as general FTBFS bugs or "upgrade libtool" bugs. If it's possible, yes outdated versions could be removed... and then look again at those figures. But it would need to happen pretty soon. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518816c4.7010...@pyro.eu.org
