Re: Technical issue with this list
Hello, TL;DR: please could the listmaster unsubscribe ike_laugh...@hotmail.com? Thanks! Fioddor Superconcentrado wrote: > This email is to report that whenever I write to this list, I get this > message. This is because ike_laugh...@hotmail.com is subscribed to the list, and that person's emails are configured to be forwarded to the non-existent address ic8...@hey.com The email provider (hotmail / outlook.com) bounces the undeliverable mails back to the original sender (in this case, Fioddor). This is also wrong behaviour of outlook.com, I think. (It should have bounced it to the Debian mailing list server, which would filter the bounce messages and eventually unsubscribe that person automatically). A bounce like this would also have happened if the outlook.com spam filter had accepted the email but the hey.com spam filter rejected it (which happens quite often, also because of SPF, or DKIM, etc.). This shows why email servers that forward emails to another address (at another provider) is often a bad idea! Hence why I wrote that the GSoC project for FreedomBox should also resist implementing this particular "feature" :) Kind regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: [Freedombox-discuss] [GSoC21] Interest in FreedomBox email project
Hi Fioddor, Fioddor Superconcentrado wrote: > Please, upload your proposal to Google's webapp for GSoC21 ASAP. > > Find also the application tasks detailed in > https://wiki.debian.org/FreedomBox/TODO/GSoC2021. Since you have scant time > left and you're familiar with email tech I believe the analysis document > would be safer to do, in your case. I managed to upload my final proposal to the GSoC portal in time, and have published a research document at: https://wiki.debian.org/FreedomBox/Design/DraftEmailConfiguration Many thanks! Kind regards, -- Steven Chamberlain signature.asc Description: Digital signature ___ Freedombox-discuss mailing list Freedombox-discuss@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] [GSoC21] Interest in FreedomBox email project
Hi Petter, Petter Reinholdtsen wrote: > [hjenkins] > > Yes. Since it needs some database, MariaDB or whatever; having a choice > > would be good. > > Given that the FreedomBox already provide user information using the > LDAP database, I suspect LDAP is a better choice. Thanks for pointing that out. LDAP (assuming it is using LMDB underneath) should be easily performant enough, both Exim and Postfix can use it, and if someone wants to set up a larger email server alongside FreedomBox, they can query the LDAP database over a network. Kind regards, -- Steven Chamberlain signature.asc Description: Digital signature ___ Freedombox-discuss mailing list Freedombox-discuss@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] [GSoC21] Interest in FreedomBox email project
hjenkins wrote: > >Do you mean, using PostgreSQL to store configuration (e.g. the lists of > >domains and email accounts on the system)? > > Yes. Since it needs some database, MariaDB or whatever; having a choice > would be good. Do you think a DBMS like MariaDB/PostgreSQL is definitely needed?* In traditional UNIX, the accounts database on most systems is the text file /etc/passwd, and this seems performant enough even with 500 users or so, and therefore most people never bother configuring LDAP or anything else (some alternatives are mentioned in nsswitch.conf(5)). > There already exist open-source conversion tools, such that you can export > an existing dataset and import it to a different backend in another format. I would mention that Postfix has the interesting postmap(1) utility to "compile" text files of key-value pairs into BerkeleyDB-like databases with indices. That still may be not worth doing unless you have 50 users or more. Exim has plenty of options for key-value databases too. Text files are the most popular form, but are sometimes noticably slow (you can maybe see this if you run `exim -qf -d` when there many messages in the queue, although network latencies are usually much bigger). * actually, if we want SpamAssassin to do Bayesian filtering, then a DBMS might be needed for that anyway, due to the size of the dataset and the need for fast indices when querying it. Maybe there good are reasons to use a DBMS other than performance? Fioddor Superconcentrado wrote: > Formally, our target are home servers (family and friends). Small > organisations are benefiting from FreedomBox, but if requirements are > incompatible, go for the small SoC computers. I would like to make home servers the target of my proposal. But FreedomBox can (already) offer benefits to organisations with more users: * The ability to migrate easily. Many commercial offerings set arbitrary limits on e.g. the number of accounts or set their pricing based on those, so they also make it deliberately hard to migrate to something else. If an organisation "outgrows" FreedomBox, they should be able to copy their mailboxes and configuration to another system, without the inconvenience of all users having to reconfigure their email software, and we should even provide documentation on how to do that. (This way, we may get fewer bug reports that email on the FreedomBox is too slow with 1000 users :) ). * The ability to integrate. If a FreedomBox administrator needs a bigger email server, we should not prevent them from continuing to administer user accounts on the FreedomBox whilst actually hosting email on a separate server. (This could be an argument to use MariaDB/PostgreSQL for that, but it should not be the only reason. Maybe it makes our testing easier.) The standard / minimal working email setup should hopefully be clear from our specification, so that an administrator can replicate it, and make informed choices on e.g. using a different MTA for performance reasons. An application like RoundCube doesn't really care if mails are stored locally or anywhere else, that just needs to be configurable. Kind regards, -- Steven Chamberlain signature.asc Description: Digital signature ___ Freedombox-discuss mailing list Freedombox-discuss@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] [GSoC21] Interest in FreedomBox email project
Hi! hjenkins wrote: > I'd suggest that the later portions of setting up an e-mail server, those > which cannot readily be tested except in a full deployment of an e-mail > server, might be good early priorities. I agree... > For scalability, which is important in some use cases, allowing Postgres > backends is good. I have some scripts for setting up the Postgres DB > somewhere; let me know if/when you want a copy. Do you mean, using PostgreSQL to store configuration (e.g. the lists of domains and email accounts on the system)? Are there FreedomBox deployments that are really so big (e.g. 100 users or more)? That would be really interesting, because I would really like FreedomBox to be usable for schools and local communities. But I thought the most common use case at the moment is that just one user runs it on very limited hardware (where PostgreSQL may consume too much RAM). I'd be very interested to know how common smaller/larger installations are. Kind regards, -- Steven Chamberlain signature.asc Description: Digital signature ___ Freedombox-discuss mailing list Freedombox-discuss@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] [GSoC21] Interest in FreedomBox email project
Hi Fioddor, I appreciate very much your comments, especially so fast. I will take these into account in the final proposal. It is surprising for me, that I was a very big fan of Extreme Programming (where a "big design up-front" is discouraged) and yet you are right, my proposal sounds like the classic waterfall model! (Maybe I am learning bad habits now from the university?). Actually, I had some reasons to prefer this approach. The project is quite special in that it involves a lot of systems administration and not just code, actually I would like to solve it with as little code as possible. I will surely explain my choices in more detail in the final proposal, and find a way to produce some working prototypes earlier on in the schedule, as you suggest. Thanks again! Kind regards, -- Steven Chamberlain signature.asc Description: Digital signature ___ Freedombox-discuss mailing list Freedombox-discuss@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/freedombox-discuss
[Freedombox-discuss] [GSoC21] Interest in FreedomBox email project
Hello, FreedomBox developers! I, Steven, would like to apply for this GSoC project, as a student, for a couple of reasons. For one, I am looking for such a project as part of my bachelor computer science studies this summer. But most of all, I'd like to tackle the dominance of proprietary control panels for web and email hosting, which are free software sold to people as a commercial product. I think, if we don't make email hosting simple for end-users, many people will (either directly or indirectly) keep using those commercial products and never get the full benefit of using free software. My original project idea (because I thought in GSoC, the students were supposed to come up with idea themselves, but apparently that's rarely the case) was for a different subproblem but it can still be found at: https://lists.debian.org/debian-outreach/2021/03/msg1.html But I'd also be happy to produce the email system that was asked for. I administer my own email server since many years. As a freelancer, I've set up email servers for others using Exim and Postfix with SpamAssassin, Dovecot, etc. and I run the email server of my local hackerspace too. And I have practical experience of the proprietary cPanel/WHM and Plesk, so I know how users' accounts, domains and mailboxes are modelled there. Since I'm already a DD, I would not have many questions about Debian infrastructure or packaging, but I would rather have questions about plinth and how best to design the tests. My draft proposal is the following: 1. Carry out an exhaustive study of use cases, such as using FreedomBox on minimal hardware, or in a cloud, with IPv4/6 or connected only via Tor, and as a sole user of the system or shared by a small community. Deliverable could be case studies and the results of a survey of FreedomBox users, potential users, and developers. 2a. Design a model of how email addresses should map to domains and mailboxes, leaving enough flexibility as deemed necessary in phase 1. This should include research on how other (including proprietary) products or services do this, because easy migration is essential for wider adoption. This shall be delivered in the form of an (amendable) proposed specification on the Wiki. 2b. Design a user interface so that users can administer their email configuration via plinth according to their needs as found in phase 1. 3a. Design and implement tests for the email setup according to the specification in phase 2a, including the correct functioning of spam and anti-virus filters and of DKIM and SPF for inbound and outgoing mail. 3b. Design and implement tests for the user interface, to ensure that changes to configuration via plinth have the intended effect on the behaviour of the email system. 4a. Implement, in the form of a series of pull requests, that which was designed in phase 2a, so that FreedomBox has a working email service and that the tests from phase 3a now pass. 4b. Implement, in the form of a series of pull requests, that which was designed in phase 2b, so that the FreedomBox user interface allows making changes to configuration as foreseen in phase 1 so that tests from phase 3b. 5. Obtain feedback and solicit testing by those who answered the survey in phase 1. Create bug reports for anything too complicated to deal with in the timeframe of the GSoC project. Development shall be very much test-driven, as can be seen from the ordering above. I also chose to tackle the problem starting from a very broad perspective, to avoid implementing something and finding out later that it doesn't adapt well to some other use case. This also gives flexibility to leave out some optional features e.g. ClamAV if I run out time, but it should be easy enough for someone else to implement that with help of the specification. Sorry, this was rather long! Thanks for your consideration and maybe your feedback. Regards, -- Steven Chamberlain signature.asc Description: Digital signature ___ Freedombox-discuss mailing list Freedombox-discuss@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/freedombox-discuss
GSoC Proposal: helping cPanel/WHM users migrate to free software
Hello! I'd like to propose something for this year's GSoC, something I've had the idea to make for several years now, and something I would really like to become a reality. My goal is to have an easy migration path for users of cPanel/WHM, which is a proprietary web hosting control panel for Linux servers, to using entirely free software on a free operating system. cPanel/WHM makes it easy to perform basic administration tasks on a Linux (CentOS) server. Core components are all free software: Apache Web Server, PHP, Dovecot, the Exim mail server and Roundcube webmail. But for its 70 million users, cPanel/WHM is not free: the monthly license fee has increased multiple times since 2019, enough to force many smaller website owners to shut down or look for alternatives. And since Red Hat also plan to cease investment in CentOS stable releases, some web hosting providers are in doubt about the future of that ecosystem. For all those people, I'd like to welcome them to Debian! We provide a free operating system, bundling the same software mentioned above, and the Debian LTS team supports each release for 5 years. Migration can be a very difficult process, though. Website code might make assumptions about filesystem paths, expect PHP to be configured in a certain way, and depend on MySQL databases being moved as well. Email users expect their forwarders and webmail settings not to change when they move to a new server. DNS configuration needs to be handled, too. Concretely: I should create a tool to import cPanel/WHM website backups and deploy them in a Debian environment. As much of the original functionality as possible must be preserved, including the easy web- based administration, which may be the most technically difficult part of the project. Already, Debian Edu, Freedombox and OpenWRT offer some potential solutions for that, which should be explored. What's maybe unusual about me is, although I'm a DD since almost 5 years, I'm studying for a Bachelor Computer Science degree since only 3 years. This means, I didn't have much free time recently to do anything useful for Debian. But now I can do something about that! Because a compulsory part of my course is to produce a practical project related to cloud IT. I propose to use Google Cloud Platform as a test-bed to develop a cPanel/WHM-compatible cloud image, based on Debian, and including the necessary tools to migrate out of an cPanel/WHM hosting environment. I think this is an important step, because cloud computing provides the most resource-efficient hosting platform available today, and many cPanel/WHM-based hosting environments aren't making full use of it yet. But in order to avoid creating vendor lock-in, I should equally support self-hosting (such as FreedomBox) or private clouds (which may be based on Docker). And I shouldn't make my solution Debian-specific, but where possible, it should work on at least Ubuntu as well. However I end up implementing this, one of the most important deliverables would be a good documentation. So that, when a website owner decides to migrate from cPanel/WHM, they can be informed of this option to migrate to entirely free software, be given clear instructions how to do that, and be connected with user groups and other established support channels around Debian. Please let me know how that sounds! Many thanks! Regards, -- Steven Chamberlain (@StevenC99 in IRC) signature.asc Description: Digital signature
Re: Seeking peers for keyserver.trifence.ch
Hi, Marcel! Marcel Waldvogel wrote: > I started running a keyserver (again) after some 20 years of break > (then still running the first generation of public keyservers) and am > looking for peers, to remain in sync. [...] I deployed my first SKS keyserver today and would love to see if synchronisation is working. It would be great if you can peer with me: sks.pyro.eu.org 11370 # Steven Chamberlain 0xDF4717BA98C27F299BA7183369F30763DFEFC134 Presuming it is working, it should remain online for a long time: The same server is part of the NTP timeserver pool as well since a few years. Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: kfreebsd-10_10.3~svn300087-7_source.changes REJECTED
Hello, Jess, Jessica Clarke wrote: > I suspect you're falling afoul of the fact that, although I made the orig > tarball reproducible [...] Actually, in this case, I did change the contents of the tarball. I believe I should have changed the source version as well. I think convention is to add something like +ds1 or +repack1. Since I had a little bit of free time this week I have this roadmap: * Update kfreebsd-10 package to gcc-9 (done). * Add version 10.3 man pages into kfreebsd-source-10.3. * Build man pages related to kernel headers from src:kfreebsd-kernel-headers instead of src:freebsd-manpages; that way the man pages are in sync with the actual version of the headers, but mainly: if k-k-h builds some arch-indep package, then k-k-h could go back into sid, so that bootstrapping becomes possible again. (Then maybe Helmut could keep it on jenkins.d.n). * Similarly, get freebsd-utils back into sid. * Update the debian/copyright file for kfreebsd-10, then kfreebsd-11. * Get kfreebsd-11 through the NEW queue *maybe* Although I'm only really focusing on kfreebsd-10 at first, to get kbsd bootstrappable and debootstrappable *at all* with the least effort. The switch to a newer kernel is way bigger project than I probably have time for. But maybe then someone else feels like doing it! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#955210: kernel-wedge: regression causes kfreebsd-10 FTBFS
Hi! Ben Hutchings wrote: > Sorry about that. I knew this was a relatively risky change, but > thought I had test cases covering everything. No problem. The refactoring is much appreciated, and it is understandable when regressions happen somewhere in this labyrinth of sh/bash/perl. > Would you mind adding a regression test for this case? Good idea, I've done this now. (By substituting $moddir with a symlink to $moddir for all test cases; having separate test series for $moddir-is-symlink and $moddir-not-symlink would have been complicated). Cyril Brulebois wrote: > Feel free to push/upload as you see fit; thanks. Thanks, I will do that. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#955210: kernel-wedge: regression causes kfreebsd-10 FTBFS
Hi! Ben Hutchings wrote: > Sorry about that. I knew this was a relatively risky change, but > thought I had test cases covering everything. No problem. The refactoring is much appreciated, and it is understandable when regressions happen somewhere in this labyrinth of sh/bash/perl. > Would you mind adding a regression test for this case? Good idea, I've done this now. (By substituting $moddir with a symlink to $moddir for all test cases; having separate test series for $moddir-is-symlink and $moddir-not-symlink would have been complicated). Cyril Brulebois wrote: > Feel free to push/upload as you see fit; thanks. Thanks, I will do that. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: Bug#955210: kernel-wedge: regression causes kfreebsd-10 FTBFS
Hi! Ben Hutchings wrote: > Sorry about that. I knew this was a relatively risky change, but > thought I had test cases covering everything. No problem. The refactoring is much appreciated, and it is understandable when regressions happen somewhere in this labyrinth of sh/bash/perl. > Would you mind adding a regression test for this case? Good idea, I've done this now. (By substituting $moddir with a symlink to $moddir for all test cases; having separate test series for $moddir-is-symlink and $moddir-not-symlink would have been complicated). Cyril Brulebois wrote: > Feel free to push/upload as you see fit; thanks. Thanks, I will do that. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#954344: debian installer don't sets PermitRootLogin to yes in ssh config when no regular user are created
Hello Ilya, Илья Пащук wrote: > if I add key to root's authorized_keys file with default debian sshd > configuration, what I will get? I think the default setting is: PermitRootLogin prohibit-password so if you add a key to authorized_keys (and chmod -R go-rwx /root/.ssh) then you should be able to log in. Maybe a better feature for the installer, would be if it asked you for an SSH key for the default user (or for the root user)? Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#954344: debian installer don't sets PermitRootLogin to yes in ssh config when no regular user are created
Hello Ilya, Илья Пащук wrote: > if I add key to root's authorized_keys file with default debian sshd > configuration, what I will get? I think the default setting is: PermitRootLogin prohibit-password so if you add a key to authorized_keys (and chmod -R go-rwx /root/.ssh) then you should be able to log in. Maybe a better feature for the installer, would be if it asked you for an SSH key for the default user (or for the root user)? Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#955210: kernel-wedge: regression causes kfreebsd-10 FTBFS
tags -1 + patch
thanks
From 03477bf089926f7a599bbe89f67df53080b69bfa Mon Sep 17 00:00:00 2001
From: Steven Chamberlain
Date: Sat, 28 Mar 2020 18:12:35 +
Subject: [PATCH] preprocess: If source directory is a symlink, follow it
Closes: #955210
---
commands/preprocess | 9 +
debian/changelog| 7 +++
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/commands/preprocess b/commands/preprocess
index b60c0d7..0c77e52 100755
--- a/commands/preprocess
+++ b/commands/preprocess
@@ -25,15 +25,16 @@ my %loaded;
sub find_all_modules {
my ($moddir) = @_;
- File::Find::find(
- sub {
+ File::Find::find({
+ follow => 1, # If $moddir is a symlink, follow it.
+ wanted => sub {
if (/\.ko$/) {
push @module_files,
File::Spec->abs2rel($File::Find::name,
$moddir);
}
- },
- $moddir);
+ }
+ }, $moddir);
if ($os eq 'linux') {
if (open(my $builtin, "$moddir/modules.builtin")) {
diff --git a/debian/changelog b/debian/changelog
index cf26ea1..46ffe4c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+kernel-wedge (2.103) UNRELEASED; urgency=medium
+
+ * preprocess: If source directory is a symlink, follow it
+(Closes: #955210)
+
+ -- Steven Chamberlain Sat, 28 Mar 2020 18:08:28 +
+
kernel-wedge (2.102) unstable; urgency=medium
* debian/tests: Correct expected exit code for preprocess missingdir case
--
2.1.4
signature.asc
Description: Digital signature
Bug#955210: kernel-wedge: regression causes kfreebsd-10 FTBFS
tags -1 + patch
thanks
From 03477bf089926f7a599bbe89f67df53080b69bfa Mon Sep 17 00:00:00 2001
From: Steven Chamberlain
Date: Sat, 28 Mar 2020 18:12:35 +
Subject: [PATCH] preprocess: If source directory is a symlink, follow it
Closes: #955210
---
commands/preprocess | 9 +
debian/changelog| 7 +++
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/commands/preprocess b/commands/preprocess
index b60c0d7..0c77e52 100755
--- a/commands/preprocess
+++ b/commands/preprocess
@@ -25,15 +25,16 @@ my %loaded;
sub find_all_modules {
my ($moddir) = @_;
- File::Find::find(
- sub {
+ File::Find::find({
+ follow => 1, # If $moddir is a symlink, follow it.
+ wanted => sub {
if (/\.ko$/) {
push @module_files,
File::Spec->abs2rel($File::Find::name,
$moddir);
}
- },
- $moddir);
+ }
+ }, $moddir);
if ($os eq 'linux') {
if (open(my $builtin, "$moddir/modules.builtin")) {
diff --git a/debian/changelog b/debian/changelog
index cf26ea1..46ffe4c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+kernel-wedge (2.103) UNRELEASED; urgency=medium
+
+ * preprocess: If source directory is a symlink, follow it
+(Closes: #955210)
+
+ -- Steven Chamberlain Sat, 28 Mar 2020 18:08:28 +
+
kernel-wedge (2.102) unstable; urgency=medium
* debian/tests: Correct expected exit code for preprocess missingdir case
--
2.1.4
signature.asc
Description: Digital signature
Re: Bug#955210: kernel-wedge: regression causes kfreebsd-10 FTBFS
tags -1 + patch
thanks
From 03477bf089926f7a599bbe89f67df53080b69bfa Mon Sep 17 00:00:00 2001
From: Steven Chamberlain
Date: Sat, 28 Mar 2020 18:12:35 +
Subject: [PATCH] preprocess: If source directory is a symlink, follow it
Closes: #955210
---
commands/preprocess | 9 +
debian/changelog| 7 +++
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/commands/preprocess b/commands/preprocess
index b60c0d7..0c77e52 100755
--- a/commands/preprocess
+++ b/commands/preprocess
@@ -25,15 +25,16 @@ my %loaded;
sub find_all_modules {
my ($moddir) = @_;
- File::Find::find(
- sub {
+ File::Find::find({
+ follow => 1, # If $moddir is a symlink, follow it.
+ wanted => sub {
if (/\.ko$/) {
push @module_files,
File::Spec->abs2rel($File::Find::name,
$moddir);
}
- },
- $moddir);
+ }
+ }, $moddir);
if ($os eq 'linux') {
if (open(my $builtin, "$moddir/modules.builtin")) {
diff --git a/debian/changelog b/debian/changelog
index cf26ea1..46ffe4c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+kernel-wedge (2.103) UNRELEASED; urgency=medium
+
+ * preprocess: If source directory is a symlink, follow it
+(Closes: #955210)
+
+ -- Steven Chamberlain Sat, 28 Mar 2020 18:08:28 +
+
kernel-wedge (2.102) unstable; urgency=medium
* debian/tests: Correct expected exit code for preprocess missingdir case
--
2.1.4
signature.asc
Description: Digital signature
Bug#955210: kernel-wedge: regression causes kfreebsd-10 FTBFS
Package: kernel-wedge Version: 2.102 Severity: important X-Debbugs-Cc: debian-...@lists.debian.org Hi, kfreebsd-10 FTBFS, due to probably this change in kernel-wedge: https://salsa.debian.org/installer-team/kernel-wedge/-/commit/3827f1ee9f53540b104c592a8a2695f78d8629ed The kfreebsd-10 build process produces kernel modules including lpt.ko and ppi.ko under: debian/kfreebsd-image-10.3-0-amd64/lib/modules/10.3-0-amd64/ As of kernel-wedge=2.102, the preprocess step fails to find any modules: KW_DEFCONFIG_DIR=debian/installer KW_CONFIG_DIR=debian/installer/amd64 \ perl -w /usr/share/kernel-wedge/commands/preprocess \ debian/installer/amd64/modules/kfreebsd-amd64/parport-modules \ debian/kfreebsd-image-10.3-0-amd64/lib/modules/10.3-0-amd64 missing module lpt missing module ppi but I notice that when adding a trailing slash to the second parameter ($moddir), then it does work again: KW_DEFCONFIG_DIR=debian/installer KW_CONFIG_DIR=debian/installer/amd64 \ perl -w /usr/share/kernel-wedge/commands/preprocess \ debian/installer/amd64/modules/kfreebsd-amd64/parport-modules \ debian/kfreebsd-image-10.3-0-amd64/lib/modules/10.3-0-amd64/ lpt.ko ppi.ko Note that debian/kfreebsd-image-10.3-0-amd64/lib/modules/10.3-0-amd64 is a symlink, to ../../boot/modules/10.3-0-amd64 I think this has to do with a basename() somewhere removing the "10.3-0-amd64" from the end of the path, so that it searches for .ko files under: debian/kfreebsd-image-10.3-0-amd64/lib/modules/ instead. Thanks! -- System Information: Debian Release: 8.0 APT prefers stable-kfreebsd-proposed-updates APT policy: (500, 'stable-kfreebsd-proposed-updates'), (500, 'stable-kfreebsd') 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) signature.asc Description: Digital signature
Bug#955210: kernel-wedge: regression causes kfreebsd-10 FTBFS
Package: kernel-wedge Version: 2.102 Severity: important X-Debbugs-Cc: debian-bsd@lists.debian.org Hi, kfreebsd-10 FTBFS, due to probably this change in kernel-wedge: https://salsa.debian.org/installer-team/kernel-wedge/-/commit/3827f1ee9f53540b104c592a8a2695f78d8629ed The kfreebsd-10 build process produces kernel modules including lpt.ko and ppi.ko under: debian/kfreebsd-image-10.3-0-amd64/lib/modules/10.3-0-amd64/ As of kernel-wedge=2.102, the preprocess step fails to find any modules: KW_DEFCONFIG_DIR=debian/installer KW_CONFIG_DIR=debian/installer/amd64 \ perl -w /usr/share/kernel-wedge/commands/preprocess \ debian/installer/amd64/modules/kfreebsd-amd64/parport-modules \ debian/kfreebsd-image-10.3-0-amd64/lib/modules/10.3-0-amd64 missing module lpt missing module ppi but I notice that when adding a trailing slash to the second parameter ($moddir), then it does work again: KW_DEFCONFIG_DIR=debian/installer KW_CONFIG_DIR=debian/installer/amd64 \ perl -w /usr/share/kernel-wedge/commands/preprocess \ debian/installer/amd64/modules/kfreebsd-amd64/parport-modules \ debian/kfreebsd-image-10.3-0-amd64/lib/modules/10.3-0-amd64/ lpt.ko ppi.ko Note that debian/kfreebsd-image-10.3-0-amd64/lib/modules/10.3-0-amd64 is a symlink, to ../../boot/modules/10.3-0-amd64 I think this has to do with a basename() somewhere removing the "10.3-0-amd64" from the end of the path, so that it searches for .ko files under: debian/kfreebsd-image-10.3-0-amd64/lib/modules/ instead. Thanks! -- System Information: Debian Release: 8.0 APT prefers stable-kfreebsd-proposed-updates APT policy: (500, 'stable-kfreebsd-proposed-updates'), (500, 'stable-kfreebsd') 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) signature.asc Description: Digital signature
Bug#955210: kernel-wedge: regression causes kfreebsd-10 FTBFS
Package: kernel-wedge Version: 2.102 Severity: important X-Debbugs-Cc: debian-...@lists.debian.org Hi, kfreebsd-10 FTBFS, due to probably this change in kernel-wedge: https://salsa.debian.org/installer-team/kernel-wedge/-/commit/3827f1ee9f53540b104c592a8a2695f78d8629ed The kfreebsd-10 build process produces kernel modules including lpt.ko and ppi.ko under: debian/kfreebsd-image-10.3-0-amd64/lib/modules/10.3-0-amd64/ As of kernel-wedge=2.102, the preprocess step fails to find any modules: KW_DEFCONFIG_DIR=debian/installer KW_CONFIG_DIR=debian/installer/amd64 \ perl -w /usr/share/kernel-wedge/commands/preprocess \ debian/installer/amd64/modules/kfreebsd-amd64/parport-modules \ debian/kfreebsd-image-10.3-0-amd64/lib/modules/10.3-0-amd64 missing module lpt missing module ppi but I notice that when adding a trailing slash to the second parameter ($moddir), then it does work again: KW_DEFCONFIG_DIR=debian/installer KW_CONFIG_DIR=debian/installer/amd64 \ perl -w /usr/share/kernel-wedge/commands/preprocess \ debian/installer/amd64/modules/kfreebsd-amd64/parport-modules \ debian/kfreebsd-image-10.3-0-amd64/lib/modules/10.3-0-amd64/ lpt.ko ppi.ko Note that debian/kfreebsd-image-10.3-0-amd64/lib/modules/10.3-0-amd64 is a symlink, to ../../boot/modules/10.3-0-amd64 I think this has to do with a basename() somewhere removing the "10.3-0-amd64" from the end of the path, so that it searches for .ko files under: debian/kfreebsd-image-10.3-0-amd64/lib/modules/ instead. Thanks! -- System Information: Debian Release: 8.0 APT prefers stable-kfreebsd-proposed-updates APT policy: (500, 'stable-kfreebsd-proposed-updates'), (500, 'stable-kfreebsd') 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) signature.asc Description: Digital signature
Bug#955166: FTBFS with gcc-9: undefined reference to bsd_getopt, etc.
Package: src:kfreebsd-10
Version: 10.3~svn300087-5
Severity: serious
Tags: patch
kfreebsd-10 FTBFS with gcc-9 due to:
| gcc-9 -D_GNU_SOURCE -isystem /usr/include/freebsd
-I/home/build/kfreebsd-10-10.3~svn300087/flavor-10.3-0-amd64/sys/modules/aic7xxx/aicasm
-I../../../dev/aic7xxx/aicasm -std=gnu99 -fstack-protector -Wno-pointer-sign
-Wno-missing-prototypes -ldb -lbsd -o aicasm aicasm.o aicasm_symbol.o
aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o -ll
| /usr/bin/ld: aicasm.o: in function `main':
| aicasm.c:(.text+0x4a1): undefined reference to `bsd_getopt'
| /usr/bin/ld: aicasm_symbol.o: in function `symtable_open':
| aicasm_symbol.c:(.text+0x220): undefined reference to `__db185_open'
| collect2: error: ld returned 1 exit status
| *** [aicasm] Error code 1
The linker invocation now adds the "--as-needed" parameter by default,
before -ldb and -lbsd, and furthermore those libraries were linked in
before the object files which use their functions:
| /usr/lib/gcc/x86_64-kfreebsd-gnu/9/collect2 -plugin
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-kfreebsd-gnu/9/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccgJKsnR.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr -m elf_x86_64_fbsd --hash-style=gnu --as-needed -dynamic-linker
/lib/ld-kfreebsd-x86-64.so.1 -pie -o aicasm
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu/Scrt1.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu/crti.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/crtbeginS.o
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../../lib -L/lib/x86_64-kfreebsd-gnu
-L/lib/../lib -L/usr/lib/x86_64-kfreebsd-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../.. -ldb -lbsd a
icasm.o aicasm_symbol.o aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o
aicasm_macro_scan.o -ll -lgcc --push-state --as-needed -lgcc_s --pop-state -lc
-lgcc --push-state --as-needed -lgcc_s --pop-state
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/crtendS.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu/crtn.o
As a result, those libraries would not be linked in at all. Object
files aicasm.o, aicasm_symbol.o subsequently cannot find find the
required functions.
I've fixed this by using LDADD within the Makefile, instead of
LDFLAGS within our debian/rules, to add the library dependencies.
Now the library dependencies are added after the object files,
as they should be.
-- System Information:
Debian Release: 8.0
APT prefers stable-kfreebsd-proposed-updates
APT policy: (500, 'stable-kfreebsd-proposed-updates'), (500,
'stable-kfreebsd')
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, 27 Mar 2020 21:26:21 +0000
From: Steven Chamberlain
Subject: Add extra libs required to build aicasm
--- a/sys/dev/aic7xxx/aicasm/Makefile
+++ b/sys/dev/aic7xxx/aicasm/Makefile
@@ -14,7 +14,7 @@ GENHDRS= aicasm_gram.h aicasm_macro_gram
SRCS= ${GENHDRS} ${CSRCS} ${YSRCS} ${LSRCS}
CLEANFILES+= ${GENHDRS} ${YSRCS:R:C/(.*)/\1.output/g}
DPADD= ${LIBL}
-LDADD= -ll
+LDADD= -ldb -lbsd -ll
WARNS?=0
# Correct path for kernel builds
Bug#955166: FTBFS with gcc-9: undefined reference to bsd_getopt, etc.
Package: src:kfreebsd-10
Version: 10.3~svn300087-5
Severity: serious
Tags: patch
kfreebsd-10 FTBFS with gcc-9 due to:
| gcc-9 -D_GNU_SOURCE -isystem /usr/include/freebsd
-I/home/build/kfreebsd-10-10.3~svn300087/flavor-10.3-0-amd64/sys/modules/aic7xxx/aicasm
-I../../../dev/aic7xxx/aicasm -std=gnu99 -fstack-protector -Wno-pointer-sign
-Wno-missing-prototypes -ldb -lbsd -o aicasm aicasm.o aicasm_symbol.o
aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o -ll
| /usr/bin/ld: aicasm.o: in function `main':
| aicasm.c:(.text+0x4a1): undefined reference to `bsd_getopt'
| /usr/bin/ld: aicasm_symbol.o: in function `symtable_open':
| aicasm_symbol.c:(.text+0x220): undefined reference to `__db185_open'
| collect2: error: ld returned 1 exit status
| *** [aicasm] Error code 1
The linker invocation now adds the "--as-needed" parameter by default,
before -ldb and -lbsd, and furthermore those libraries were linked in
before the object files which use their functions:
| /usr/lib/gcc/x86_64-kfreebsd-gnu/9/collect2 -plugin
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-kfreebsd-gnu/9/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccgJKsnR.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr -m elf_x86_64_fbsd --hash-style=gnu --as-needed -dynamic-linker
/lib/ld-kfreebsd-x86-64.so.1 -pie -o aicasm
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu/Scrt1.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu/crti.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/crtbeginS.o
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../../lib -L/lib/x86_64-kfreebsd-gnu
-L/lib/../lib -L/usr/lib/x86_64-kfreebsd-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../.. -ldb -lbsd a
icasm.o aicasm_symbol.o aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o
aicasm_macro_scan.o -ll -lgcc --push-state --as-needed -lgcc_s --pop-state -lc
-lgcc --push-state --as-needed -lgcc_s --pop-state
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/crtendS.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu/crtn.o
As a result, those libraries would not be linked in at all. Object
files aicasm.o, aicasm_symbol.o subsequently cannot find find the
required functions.
I've fixed this by using LDADD within the Makefile, instead of
LDFLAGS within our debian/rules, to add the library dependencies.
Now the library dependencies are added after the object files,
as they should be.
-- System Information:
Debian Release: 8.0
APT prefers stable-kfreebsd-proposed-updates
APT policy: (500, 'stable-kfreebsd-proposed-updates'), (500,
'stable-kfreebsd')
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, 27 Mar 2020 21:26:21 +0000
From: Steven Chamberlain
Subject: Add extra libs required to build aicasm
--- a/sys/dev/aic7xxx/aicasm/Makefile
+++ b/sys/dev/aic7xxx/aicasm/Makefile
@@ -14,7 +14,7 @@ GENHDRS= aicasm_gram.h aicasm_macro_gram
SRCS= ${GENHDRS} ${CSRCS} ${YSRCS} ${LSRCS}
CLEANFILES+= ${GENHDRS} ${YSRCS:R:C/(.*)/\1.output/g}
DPADD= ${LIBL}
-LDADD= -ll
+LDADD= -ldb -lbsd -ll
WARNS?=0
# Correct path for kernel builds
Bug#955166: FTBFS with gcc-9: undefined reference to bsd_getopt, etc.
Package: src:kfreebsd-10
Version: 10.3~svn300087-5
Severity: serious
Tags: patch
kfreebsd-10 FTBFS with gcc-9 due to:
| gcc-9 -D_GNU_SOURCE -isystem /usr/include/freebsd
-I/home/build/kfreebsd-10-10.3~svn300087/flavor-10.3-0-amd64/sys/modules/aic7xxx/aicasm
-I../../../dev/aic7xxx/aicasm -std=gnu99 -fstack-protector -Wno-pointer-sign
-Wno-missing-prototypes -ldb -lbsd -o aicasm aicasm.o aicasm_symbol.o
aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o -ll
| /usr/bin/ld: aicasm.o: in function `main':
| aicasm.c:(.text+0x4a1): undefined reference to `bsd_getopt'
| /usr/bin/ld: aicasm_symbol.o: in function `symtable_open':
| aicasm_symbol.c:(.text+0x220): undefined reference to `__db185_open'
| collect2: error: ld returned 1 exit status
| *** [aicasm] Error code 1
The linker invocation now adds the "--as-needed" parameter by default,
before -ldb and -lbsd, and furthermore those libraries were linked in
before the object files which use their functions:
| /usr/lib/gcc/x86_64-kfreebsd-gnu/9/collect2 -plugin
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-kfreebsd-gnu/9/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccgJKsnR.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr -m elf_x86_64_fbsd --hash-style=gnu --as-needed -dynamic-linker
/lib/ld-kfreebsd-x86-64.so.1 -pie -o aicasm
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu/Scrt1.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu/crti.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/crtbeginS.o
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../../lib -L/lib/x86_64-kfreebsd-gnu
-L/lib/../lib -L/usr/lib/x86_64-kfreebsd-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../.. -ldb -lbsd a
icasm.o aicasm_symbol.o aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o
aicasm_macro_scan.o -ll -lgcc --push-state --as-needed -lgcc_s --pop-state -lc
-lgcc --push-state --as-needed -lgcc_s --pop-state
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/crtendS.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu/crtn.o
As a result, those libraries would not be linked in at all. Object
files aicasm.o, aicasm_symbol.o subsequently cannot find find the
required functions.
I've fixed this by using LDADD within the Makefile, instead of
LDFLAGS within our debian/rules, to add the library dependencies.
Now the library dependencies are added after the object files,
as they should be.
-- System Information:
Debian Release: 8.0
APT prefers stable-kfreebsd-proposed-updates
APT policy: (500, 'stable-kfreebsd-proposed-updates'), (500,
'stable-kfreebsd')
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, 27 Mar 2020 21:26:21 +0000
From: Steven Chamberlain
Subject: Add extra libs required to build aicasm
--- a/sys/dev/aic7xxx/aicasm/Makefile
+++ b/sys/dev/aic7xxx/aicasm/Makefile
@@ -14,7 +14,7 @@ GENHDRS= aicasm_gram.h aicasm_macro_gram
SRCS= ${GENHDRS} ${CSRCS} ${YSRCS} ${LSRCS}
CLEANFILES+= ${GENHDRS} ${YSRCS:R:C/(.*)/\1.output/g}
DPADD= ${LIBL}
-LDADD= -ll
+LDADD= -ldb -lbsd -ll
WARNS?=0
# Correct path for kernel builds
Re: Where is iso install image for kfreebsd ?
Hello! SUGIMOTO Norimitsu wrote: > I don't found a debian installer iso image for kfreebsd. > https://d-i.debian.org/daily-images/kfreebsd-amd64/ > > Please let me know which ISO file should be used > to install kfreebsd. http://jenkins.kfreebsd.tw/jenkins/view/cd/job/debian-cd_jessie-kfreebsd_kfreebsd-amd64/ws/build/debian-unofficial-kfreebsd-amd64-NETINST-1.iso SHA256: 6fb8700dd6a6e9a20b8aefbef90ede0d896b6a9aa0903f8a2a8fa6a59aee4fa7 http://jenkins.kfreebsd.tw/jenkins/view/cd/job/debian-cd_jessie-kfreebsd_kfreebsd-i386/ws/build/debian-unofficial-kfreebsd-i386-NETINST-1.iso SHA256: d9173e2728cdda54f5d561139b5f95b5d5f4dc2664923c5e9ff01578469a85a4 Those images I built in December 2017, based on Debian jessie. I hope they work for you! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: Request for kFreeBSD (and Hurd) porters
Hi, Svante Signell wrote: > The Debian GNU/kFreeBSD port recently obtained a buildd building > packages for the sid distribution, kamp. Thank you very much for your > effort making this happening jrtc27 :) Thanks very much for this James! It was a really nice surprise to see packages building again. May I ask who has provided the hardware/hosting? And what is the DNS hostname of the machine? (kamp.buildd.org does not resolve for me). Also, how are the i386 builds done: is that a kfreebsd-i386 chroot on a kfreebsd-amd64 system? Or is it a separate VM running "natively" on the 32-bit kernel? By the way, since 4 days or so many packages are Built but not Installed in the archive. Is that because a DD must manually check and sign them? Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Accepted kfreebsd-kernel-headers 10.3~7 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 28 Jul 2018 12:47:29 + Source: kfreebsd-kernel-headers Binary: kfreebsd-kernel-headers Architecture: source Version: 10.3~7 Distribution: unstable Urgency: medium Maintainer: GNU/kFreeBSD Maintainers Changed-By: Steven Chamberlain Description: kfreebsd-kernel-headers - kFreeBSD headers for development Changes: kfreebsd-kernel-headers (10.3~7) unstable; urgency=medium . * Migrate packaging SVN to Git * Update my email address in Uploaders * Bump Standards-Version to 4.1.5; no change needed * Retroactively clean up whitespace in changelog * Use architecture.mk instead of dpkg-architecture * Use pkg-info.mk instead of dpkg-parsechangelog * Add a generic debian/.gitignore file Checksums-Sha1: d9bef53e3ff8a54f01f0c2dfc060f6143b640ffe 1747 kfreebsd-kernel-headers_10.3~7.dsc 3c251dc20a04761f00f444080cfe5bffa7cee335 46604 kfreebsd-kernel-headers_10.3~7.tar.xz 1c0b1622cd7a9f531d91f7480e03ba28b5ca6306 4359 kfreebsd-kernel-headers_10.3~7_source.buildinfo Checksums-Sha256: 5a402c7dc98306f69e8ea37f2cc770e7c45e963ee4cd2d9e8313345046840e51 1747 kfreebsd-kernel-headers_10.3~7.dsc b4c6a56b19b31fea24817acbb0a3f9f7fe215a3b3769d71920f9729d3e3201a1 46604 kfreebsd-kernel-headers_10.3~7.tar.xz 5dc9d14d4c2202df1b6edba9f237ff80b641ff73787a42d673e17c18439e9d9b 4359 kfreebsd-kernel-headers_10.3~7_source.buildinfo Files: ebac396aa06c8def3462c14ba838ce43 1747 kernel standard kfreebsd-kernel-headers_10.3~7.dsc 5e1070effd5b7ecaca5c3fa7aea44bf8 46604 kernel standard kfreebsd-kernel-headers_10.3~7.tar.xz 45ede07d6cfa24d3890ca664d45ece7b 4359 kernel standard kfreebsd-kernel-headers_10.3~7_source.buildinfo -BEGIN PGP SIGNATURE- iQGcBAEBCAAGBQJbXd9rAAoJEBk7UPmvlsusHPcL/2Gpng6vfoYUeX/FU2GDLU+v nIDQzLMfhuphGet2rBSBFvkwUpRJGaV50RxRhzeCd0xQK9XU+ZdEud6tnF2Mbp24 l+pDcJtbJ7b+0Wb6LMCxlAGDOAZIIhHjHdRPnKh+S8v7/i5HgoFOU+9vSehgWhvQ j1XpO649JED9bXpXBjv+bdgzlPuv1EY5/CbNzz/ImGQmvI/nED5UD5pEYO5BtcO2 /3AKZFo4E+f+m4HVJOWrE49Xfopu1t9vVUd3IRnsMm2Mdyc7fKoKZDBTQ2TwfXWu 9RUQIfAM9GAxooIktcG8G+aNyJ7NDPDFG8QLi1eDIoxM4m9vGe/RD7rQeFvZiNzw ANkPa1PpIhWhYKcBFQPqARSGHa7Jj9pp6Vf4uQcYGUwLsoMC8xC6fsrL/w4SibPd A2RNkct38eRHEr+0ItKkTlKaSJNzwJjwhha9sgMTO9c68wkbJOZbBSU2C6fov89y rx+4cAx+WXZYrg5BjzMq2Xw/vFslkgSF3cMbCOSLAA== =iS3j -END PGP SIGNATURE-
Bug#893886: partman-auto: increase max size of /boot on amd64+i386?
Source: partman-auto Version: 144 Severity: wishlist X-Debbugs-Cc: vor...@debian.org Hello, I get lots of user feedback from Ubuntu users that /boot is "too small" and quickly becomes full. That's been the case for at least 3 years. https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1357093 There are a few aspects to this: 1. if a user chooses full-disk encryption, the size of /boot is not adjustable; only by manually creating that, dm-crypt and LVM instead, but that's not easy. 2. it's really painful to enlarge /boot once a dm-crypt partition is created alongside it and filled with user data. 3. users of Software Center / Synaptic install kernel upgrades, but usually aren't that aware that old, unneeded kernels remain installed; the GUIs have no autoremove function, and autoremove can sometimes remove things a novice user didn't intend. Some aspects are Ubuntu-specific: 4. they bump the ABI number in every kernel update, IIRC something related to the signing machinery for Secure Boot. (vorlon@ in Cc can maybe explain?) 5. they store both signed and unsigned kernel images in /boot, so each installed kernel ABI version requires more disk space. Thinking ahead, the latter two points might also apply to Debian someday. The kernel itself and initrds may also become bigger over the next years. If that happens, and users have an installed system with full-disk encryption, they may be unable to increase the size of /boot, and so be obstructed from upgrading to the next Debian (or Ubuntu) release, or the one after. That the actual, root causes persist in Ubuntu after 3 years, despite a huge install base, good user support channels and paid developers, is slightly sad, but makes me think it merits working around (or preemptive action in the case of Debian), even at the expense of 256MB disk space. So in recipes-amd64-efi, is it feasible we double the max. size of /boot from 256MB to 512MB? "640K ought to be enough for everyone." Thanks for consideration, Regards, -- Steven Chamberlain signature.asc Description: Digital signature
Bug#893886: partman-auto: increase max size of /boot on amd64+i386?
Source: partman-auto Version: 144 Severity: wishlist X-Debbugs-Cc: vor...@debian.org Hello, I get lots of user feedback from Ubuntu users that /boot is "too small" and quickly becomes full. That's been the case for at least 3 years. https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1357093 There are a few aspects to this: 1. if a user chooses full-disk encryption, the size of /boot is not adjustable; only by manually creating that, dm-crypt and LVM instead, but that's not easy. 2. it's really painful to enlarge /boot once a dm-crypt partition is created alongside it and filled with user data. 3. users of Software Center / Synaptic install kernel upgrades, but usually aren't that aware that old, unneeded kernels remain installed; the GUIs have no autoremove function, and autoremove can sometimes remove things a novice user didn't intend. Some aspects are Ubuntu-specific: 4. they bump the ABI number in every kernel update, IIRC something related to the signing machinery for Secure Boot. (vorlon@ in Cc can maybe explain?) 5. they store both signed and unsigned kernel images in /boot, so each installed kernel ABI version requires more disk space. Thinking ahead, the latter two points might also apply to Debian someday. The kernel itself and initrds may also become bigger over the next years. If that happens, and users have an installed system with full-disk encryption, they may be unable to increase the size of /boot, and so be obstructed from upgrading to the next Debian (or Ubuntu) release, or the one after. That the actual, root causes persist in Ubuntu after 3 years, despite a huge install base, good user support channels and paid developers, is slightly sad, but makes me think it merits working around (or preemptive action in the case of Debian), even at the expense of 256MB disk space. So in recipes-amd64-efi, is it feasible we double the max. size of /boot from 256MB to 512MB? "640K ought to be enough for everyone." Thanks for consideration, Regards, -- Steven Chamberlain signature.asc Description: Digital signature
Bug#778642: xfce4-power-manager-plugins: Serious memory leak in libxfce4powermanager.so
Hi, I can reproduce the bug in Debian jessie by running the power-manager-plugin applet on a laptop only using wall power and having a fully-charged battery. In the past 30 days the system's OOM-killer has twice killed the applet, despite this machine having ~6 GiB RAM otherwise free. I've tried also with Phil Davidov's 0002-memory-leak-fix.patch (thanks!), which may have helped fixed some memory leaks, but apparently not all of them. The upstream bug report https://bugzilla.xfce.org/show_bug.cgi?id=12367 points to a glib2 upstream commit/backport: http://pkgs.fedoraproject.org/cgit/rpms/glib2.git/commit/?h=f23=58034b4a48df078e37b55a13bbb855f7615c18b5 The version of glib2.0 in Debian stretch has that patch already applied, but jessie does not. Applying that patch against glib2.0 in jessie, I actually *still* see the resident size of my power-manager-plugin applet increasing over time. I'm unfortunately unable to run valgrind on this machine. Regards, -- Steven Chamberlain stev...@debian.org signature.asc Description: Digital signature
Re: Future of kFreeBSD in Debian unstable
Hi Ansgar, Ansgar Burchardt wrote: > however with the kFreeBSD buildds gone, we would also need at least some > people willing to maintain buildds (this is limited to Debian Developers > as long as the port lives on ftp.debian.org). Assuming I could find/maintain a couple of VMs to build kfreebsd sid, how exactly could the .debs be uploaded to ftp.d.o? Are they simply uploaded with ftp/scp along with a .changes/.buildinfo, just like a binNMU or source package upload? Would the buildds need their own GPG keys, added into some keyring also? That's possible even for non-DSA maintained buildds? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: Who is still here?
Hello, Sorry for this late response. I've been away for a long time. I've not been able to do any development work, or even keep up with emails on the lists. Sorry. I'm actually still using GNU/kFreeBSD in some places, find it very useful, and perceive it has advantages over Debian GNU/Linux. I've no objection to the current infrastructure going away. I'd be more interested in starting fresh with new ideas, such as: if Debian starts to do reproducible building or use cloud providers, we could try to do the same; or when a new live system or installer appears, we could try to port to it. Restarting GNU/kFreeBSD development would be a long-term project, it may take 2-5 years to see a new release. If I do find time to work on this, my first thought would be to archive the most important parts: source code in the "glibc-bsd" Subversion repository, including the kernel and packaging of libraries and utilities. The Debian-provided Subversion infrastructure will likely go away in favour of salsa.debian.org (GitLab), so I'd like to restart the discussion on changing to Git. This could be a nice opportunity to bring in new contributors. GitLab might be friendlier to newcomers, or to those who already tried to contribute but we didn't have a good workflow to integrate their work. I think GNU/kFreeBSD wouldn't survive as ~3 people doing the bulk of the development work. But there is hope, if we find ways of making it easier for other people to work on it, and then if there's enough interest. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#769761: mercurial: does not support SNI on for https: URLs
Hi, Upstream's patch works with mercurial/3.1.2-2+deb8u4 in oldstable: https://www.mercurial-scm.org/repo/hg/rev/bf07c19b4c82 Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#862059: closed by Ximin Luo <infini...@debian.org> (Re: sbuild: please sign buildinfo files)
Hi Ximin, Thanks for figuring this out. Indeed the recent buildinfos are being signed but I didn't yet figure out how/why. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#810470: libusb: superseded by libusb-1.0
Hi, openocd/0.10.0-1 gained a new dependency on libusb-dev (libusb 0.1); but the latter is destined for removal from the archive. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#868929: kfreebsd-10: FTBFS: ../../../compat/ia32/ia32_genassym.c:1:0: error: code model kernel does not support PIC mode
severity 868929 important thanks (linux-)amd64 is not in this package's Architectures: field, therefore FTBFS on that arch cannot be a RC bug? (Though I'd be interested in fixing it someday). Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#868929: kfreebsd-10: FTBFS: ../../../compat/ia32/ia32_genassym.c:1:0: error: code model kernel does not support PIC mode
severity 868929 important thanks (linux-)amd64 is not in this package's Architectures: field, therefore FTBFS on that arch cannot be a RC bug? (Though I'd be interested in fixing it someday). Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#868929: kfreebsd-10: FTBFS: ../../../compat/ia32/ia32_genassym.c:1:0: error: code model kernel does not support PIC mode
severity 868929 important thanks (linux-)amd64 is not in this package's Architectures: field, therefore FTBFS on that arch cannot be a RC bug? (Though I'd be interested in fixing it someday). Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: [Debconf-discuss] printing boarding passes?
Hi, Front desk can print documents for you, if you save them to a USB stick. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature ___ Debconf-discuss mailing list Debconf-discuss@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-discuss
[tor-relays] Tor exit nodes attacking SSH?
Hi, I often run my SSH sessions via Tor using tsocks. But today I see: @@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a. Further investigation shows that this happens for any destination IP address, even where there's no SSH service running: $ tsocks ssh -vC root@8.8.8.8 OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016 debug1: Reading configuration data /home/steven/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to 8.8.8.8 [8.8.8.8] port 22. debug1: Connection established. debug1: identity file /home/steven/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_rsa-cert type -1 debug1: identity file /home/steven/.ssh/id_dsa type 2 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 debug1: Remote protocol version 2.0, remote software version dropbear_2015.67 debug1: no match: dropbear_2015.67 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-sha2-256 z...@openssh.com debug1: kex: client->server aes128-ctr hmac-sha2-256 z...@openssh.com debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: RSA e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a The authenticity of host '8.8.8.8 (8.8.8.8)' can't be established. RSA key fingerprint is e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a. Are you sure you want to continue connecting (yes/no)? : I could be wrong, but I think this "dropbear" service is most likely something malicious, running on one or more Tor exit nodes, attempting to collect passwords of people logging in this way. If a user ignored the error (or trusts the fingerprint without verifying), their password, and further activity on the shell could all be captured by the attacker. Since Tor makes my client connections anonymous, and the dropbear is seen even for hosts that don't provide an SSH service, makes me think this attack is indiscriminate, not targetted only at me or my servers. The first time you connect to some machine, be careful to verify the fingerprint through independent means. Pay attention to notices like this of changed key fingerprints. And if you haven't already, disable PasswordAuthentication to something that cannot be intercepted (like authorization of private RSA/ECDSA keys). Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [Debconf-discuss] Any ARM embedded folks care to chat?
A few of us are gathered in the lower level of the garden, around the power pole. debacle has with him a Pyra Handheld prototype, based on TI's OMAP5. It runs Debian. I previously dabbled with the image-building tools for it, specifically looking to make the rootfs image reproducible! Hope to see you soon! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature ___ Debconf-discuss mailing list Debconf-discuss@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-discuss
Re: [Debconf-discuss] Mobile SIMs for Montreal
So I have moved the FAQ here and expanded it: https://wiki.debconf.org/wiki/DebConf17/Sim-card-information Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature ___ Debconf-discuss mailing list Debconf-discuss@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-discuss
Bug#719913: ikiwiki: error setting wiki theme if libxml-writer-perl not installed
Simon McVittie wrote: > On Tue, 20 Jun 2017 at 23:11:47 +0100, Simon McVittie wrote: > > This appears to be a bug in the osm plugin > > I believe this should avoid it: > http://source.ikiwiki.branchable.com/?p=source.git;a=commitdiff;h=5a84cd308d817c9e509e5f4baf514a3681f48dc1 Thanks! That's exactly what it was (although the osm plugin is disabled). This fix works for ikiwiki/3.20170111 in sid/stretch. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#719913: ikiwiki: error setting wiki theme if libxml-writer-perl not installed
tag 719913 -moreinfo -unreproducible thanks Hi, On first install of ikiwiki, I logged into the web interface, wanted to adjust the site URL and Save Changes. This requires a Rebuild, which fails with: | Error: Can't locate XML/Writer.pm in @INC (you may need to install the | XML::Writer module) (@INC contains: /var/www/.ikiwiki /etc/perl | /usr/local/lib/x86_64-kfreebsd-gnu/perl/5.24.1 | /usr/local/share/perl/5.24.1 /usr/lib/x86_64-kfreebsd-gnu/perl5/5.24 | /usr/share/perl5 /usr/lib/x86_64-kfreebsd-gnu/perl/5.24 | /usr/share/perl/5.24 /usr/local/lib/site_perl | /usr/lib/x86_64-kfreebsd-gnu/perl-base) at (eval 481) line 2. BEGIN | failed--compilation aborted at (eval 481) line 2. I don't know if there's a strong reason against libxml-writer-perl being a Recommends or a Depends. But the user experience of a first-timer or novice user is suboptimal without it. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: firefox-esr: no longer using system nspr, nss, sqlite?
Mike Hommey wrote: > Look at the build dependencies in debian/control.in, specifically the > versions, and the versions of the mentioned libraries in jessie and > stretch. Yep, the required versions are not there. Okay, intentional then. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
firefox-esr: no longer using system nspr, nss, sqlite?
Hi, firefox-esr since 52.2.0esr-1 is no longer using the system libs for nspr, nss, sqlite; was that an intentional change? This affects at least sid (where DIST="stretch"): https://buildd.debian.org/status/fetch.php?pkg=firefox-esr=amd64=52.2.0esr-1=1497417448=0 (see "NSPR selection... source-tree", or grep for USE_SYSTEM_ ) and I expect it would affect the backports in jessie-security too (but I don't know how/where to find build logs, to check that). Maybe it should have been ifneq in debian/rules? | ifeq (,$(filter wheezy jessie stretch,$(DIST))) | SYSTEM_LIBS += nspr nss sqlite | endif | #ifeq (,$(filter wheezy jessie,$(DIST))) | SYSTEM_LIBS += vpx | endif Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: "Ask HN: What do you want to see in Ubuntu 17.10?"
Oh, regarding the Ubuntu installer: please configure the keyboard layout _before _prompting for the LUKS passphrase! and don't prompt for eCryptfs-protected /home, when LUKS is already configured. (Or remove support for this completely). If the user configured a network connection already, it would be nice if the latest packages were fetched (rather installing old ones from the install media, and upgrading in a later step). Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: "Ask HN: What do you want to see in Ubuntu 17.10?"
I would certainly reiterate this: https://news.ycombinator.com/item?id=14003253 Some versions of Ubuntu (at least trusty, xenial) have the added "feature" to keep older kernel versions when installing new ones. It kind of makes sense to keep at least the previous one (in case of a regression), but keeping every new patch-version is too much. Debian doesn't do this (except when the ABI version or upstream version is new, I think). apt-get autoremove is supposed to remove the unneeded ones, but apparently does not. (And users can't be expected to remember this either). On Ubuntu this can fill /boot every few weeks. In a user group today I've helped two Ubuntu users who'd run into this problem and been unable to install new packages/updates as a result. In the past months I've seen this about 10 times on all manner of *buntu systems. (It's a very popular OS around here, apart from this problem!). Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#862059: sbuild: please sign buildinfo files
Package: sbuild
Version: 0.73.0-4
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: infrastructure
Hello,
dpkg-buildpackage typically generates a .changes and .buildinfo file,
and signs both (since at least dpkg 1.18.19).
But when using sbuild, dpkg-buildpackage inside of the build chroot does
not do the signing, but rather sbuild signs the .changes file afterward.
Please could that code be updated to also sign the .buildinfo (if one
was created).
I have not tested the attached patch (yet?) but it explains the issue at
least. Here is typical output where only the .changes file gets signed:
>
> Finished at 20170314-2338
> Build needed 00:00:43, 5660k disc space
> Signature with key 'F2F4A5FC' requested:
> signfile /home/buildd/build/hello_2.10-1+b1_amd64.changes F2F4A5FC
>
> Successfully signed changes file
The relevance/importance of this is that official Debian package builds
produce .buildinfo files now, and dak archives them, but they are not
being signed yet.
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
Init: sysvinit (via /sbin/init)
diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index 9a767a2..b196812 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -2668,6 +2668,21 @@ sub get_changes {
return $changes;
}
+sub get_buildinfo {
+my $self=shift;
+my $buildinfo;
+
+if ($self->get_conf('BUILD_ARCH_ANY')) {
+ $buildinfo = $self->get('Package_SVersion') . '_' . $self->get('Host Arch') . '.buildinfo';
+} elsif ($self->get_conf('BUILD_ARCH_ALL')) {
+ $buildinfo = $self->get('Package_SVersion') . "_all.buildinfo";
+} elsif ($self->get_conf('BUILD_SOURCE')) {
+ $buildinfo = $self->get('Package_SVersion') . "_source.buildinfo";
+}
+
+return $buildinfo;
+}
+
sub check_space {
my $self = shift;
my @files = @_;
@@ -3169,6 +3184,7 @@ sub close_build_log {
my $key_id = $self->get_conf('KEY_ID');
my $build_dir = $self->get_conf('BUILD_DIR');
my $changes;
+ my $buildinfo;
$self->log(sprintf("Signature with key '%s' requested:\n", $key_id));
$changes = $self->get_changes();
if (!defined($changes)) {
@@ -3176,6 +3192,10 @@ sub close_build_log {
} else {
system('debsign', '--re-sign', "-k$key_id", '--', "$build_dir/$changes");
}
+ $buildinfo = $self->get_buildinfo();
+ if (defined($buildinfo) && stat($buildinfo)) {
+ system('debsign', '--re-sign', "-k$key_id", '--', "$build_dir/$buildinfo");
+ }
if ($self->get_conf('SOURCE_ONLY_CHANGES')) {
my $so_changes = $build_dir . '/' . $self->get('Package_SVersion') . "_source.changes";
if (-r $so_changes) {
Bug#862059: sbuild: please sign buildinfo files
Package: sbuild
Version: 0.73.0-4
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: infrastructure
Hello,
dpkg-buildpackage typically generates a .changes and .buildinfo file,
and signs both (since at least dpkg 1.18.19).
But when using sbuild, dpkg-buildpackage inside of the build chroot does
not do the signing, but rather sbuild signs the .changes file afterward.
Please could that code be updated to also sign the .buildinfo (if one
was created).
I have not tested the attached patch (yet?) but it explains the issue at
least. Here is typical output where only the .changes file gets signed:
>
> Finished at 20170314-2338
> Build needed 00:00:43, 5660k disc space
> Signature with key 'F2F4A5FC' requested:
> signfile /home/buildd/build/hello_2.10-1+b1_amd64.changes F2F4A5FC
>
> Successfully signed changes file
The relevance/importance of this is that official Debian package builds
produce .buildinfo files now, and dak archives them, but they are not
being signed yet.
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
Init: sysvinit (via /sbin/init)
diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index 9a767a2..b196812 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -2668,6 +2668,21 @@ sub get_changes {
return $changes;
}
+sub get_buildinfo {
+my $self=shift;
+my $buildinfo;
+
+if ($self->get_conf('BUILD_ARCH_ANY')) {
+ $buildinfo = $self->get('Package_SVersion') . '_' . $self->get('Host Arch') . '.buildinfo';
+} elsif ($self->get_conf('BUILD_ARCH_ALL')) {
+ $buildinfo = $self->get('Package_SVersion') . "_all.buildinfo";
+} elsif ($self->get_conf('BUILD_SOURCE')) {
+ $buildinfo = $self->get('Package_SVersion') . "_source.buildinfo";
+}
+
+return $buildinfo;
+}
+
sub check_space {
my $self = shift;
my @files = @_;
@@ -3169,6 +3184,7 @@ sub close_build_log {
my $key_id = $self->get_conf('KEY_ID');
my $build_dir = $self->get_conf('BUILD_DIR');
my $changes;
+ my $buildinfo;
$self->log(sprintf("Signature with key '%s' requested:\n", $key_id));
$changes = $self->get_changes();
if (!defined($changes)) {
@@ -3176,6 +3192,10 @@ sub close_build_log {
} else {
system('debsign', '--re-sign', "-k$key_id", '--', "$build_dir/$changes");
}
+ $buildinfo = $self->get_buildinfo();
+ if (defined($buildinfo) && stat($buildinfo)) {
+ system('debsign', '--re-sign', "-k$key_id", '--', "$build_dir/$buildinfo");
+ }
if ($self->get_conf('SOURCE_ONLY_CHANGES')) {
my $so_changes = $build_dir . '/' . $self->get('Package_SVersion') . "_source.changes";
if (-r $so_changes) {
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
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+kernel
+export INSTALLER_CD
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+kernel
+export INSTALLER_CD
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+kernel
+export INSTALLER_CD
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+kernel
+export INSTALLER_CD
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+kernel
+export INSTALLER_CD
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+kernel
+export INSTALLER_CD
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+kernel
+export INSTALLER_CD
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+kernel
+export INSTALLER_CD
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+kernel
+export INSTALLER_CD
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+kernel
+export INSTALLER_CD
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+kernel
+export INSTALLER_CD
Bug#860204: debian-cd: Fix update_tasks on non-Linux arches
Source: debian-cd
Version: 3.1.20
Tags: patch
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-bsd@lists.debian.org
Hi!
tools/update_tasks was failing for me on kfreebsd, with:
update_tasks: Can't determine arch
In the filename of the coreutils .deb, the architecture part
may contain a hyphen in the case of hurd-i386 or kfreebsd-*.
But it currently only matches alpha or numeric.
Patch is attached. Thanks!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
From c0104be3e511052c5cab4d561b5887abd4b4dd89 Mon Sep 17 00:00:00 2001
From: Steven Chamberlain <ste...@pyro.eu.org>
Date: Wed, 12 Apr 2017 20:05:15 +0100
Subject: [PATCH] Fix update_tasks on non-Linux arches
In the filename of the coreutils .deb, the architecture part
may also contain a hyphen in the case of hurd-i386 or
kfreebsd-*
---
tools/update_tasks | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/update_tasks b/tools/update_tasks
index b9fe207..03e03ac 100755
--- a/tools/update_tasks
+++ b/tools/update_tasks
@@ -44,7 +44,7 @@ if (defined($ENV{'FORCE_SID_TASKSEL'}) and $ENV{'FORCE_SID_TASKSEL'} eq '1') {
# is a non -all package) to determine a valid arch for the rest of
# this script
my $coreutils_deb = `$basedir/tools/which_deb $mirror $codename coreutils binary`;
-if ($coreutils_deb =~ m/_([[:alnum:]]+)\.deb/) {
+if ($coreutils_deb =~ m/_([[:alnum:]-]+)\.deb/) {
$arch = $1;
} else {
die "update_tasks: Can't determine arch!\n";
--
1.8.4.rc3
signature.asc
Description: Digital signature
Bug#860204: debian-cd: Fix update_tasks on non-Linux arches
Source: debian-cd
Version: 3.1.20
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-...@lists.debian.org
Hi!
tools/update_tasks was failing for me on kfreebsd, with:
update_tasks: Can't determine arch
In the filename of the coreutils .deb, the architecture part
may contain a hyphen in the case of hurd-i386 or kfreebsd-*.
But it currently only matches alpha or numeric.
Patch is attached. Thanks!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
From c0104be3e511052c5cab4d561b5887abd4b4dd89 Mon Sep 17 00:00:00 2001
From: Steven Chamberlain <ste...@pyro.eu.org>
Date: Wed, 12 Apr 2017 20:05:15 +0100
Subject: [PATCH] Fix update_tasks on non-Linux arches
In the filename of the coreutils .deb, the architecture part
may also contain a hyphen in the case of hurd-i386 or
kfreebsd-*
---
tools/update_tasks | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/update_tasks b/tools/update_tasks
index b9fe207..03e03ac 100755
--- a/tools/update_tasks
+++ b/tools/update_tasks
@@ -44,7 +44,7 @@ if (defined($ENV{'FORCE_SID_TASKSEL'}) and $ENV{'FORCE_SID_TASKSEL'} eq '1') {
# is a non -all package) to determine a valid arch for the rest of
# this script
my $coreutils_deb = `$basedir/tools/which_deb $mirror $codename coreutils binary`;
-if ($coreutils_deb =~ m/_([[:alnum:]]+)\.deb/) {
+if ($coreutils_deb =~ m/_([[:alnum:]-]+)\.deb/) {
$arch = $1;
} else {
die "update_tasks: Can't determine arch!\n";
--
1.8.4.rc3
signature.asc
Description: Digital signature
Bug#860204: debian-cd: Fix update_tasks on non-Linux arches
Source: debian-cd
Version: 3.1.20
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-...@lists.debian.org
Hi!
tools/update_tasks was failing for me on kfreebsd, with:
update_tasks: Can't determine arch
In the filename of the coreutils .deb, the architecture part
may contain a hyphen in the case of hurd-i386 or kfreebsd-*.
But it currently only matches alpha or numeric.
Patch is attached. Thanks!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
From c0104be3e511052c5cab4d561b5887abd4b4dd89 Mon Sep 17 00:00:00 2001
From: Steven Chamberlain <ste...@pyro.eu.org>
Date: Wed, 12 Apr 2017 20:05:15 +0100
Subject: [PATCH] Fix update_tasks on non-Linux arches
In the filename of the coreutils .deb, the architecture part
may also contain a hyphen in the case of hurd-i386 or
kfreebsd-*
---
tools/update_tasks | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/update_tasks b/tools/update_tasks
index b9fe207..03e03ac 100755
--- a/tools/update_tasks
+++ b/tools/update_tasks
@@ -44,7 +44,7 @@ if (defined($ENV{'FORCE_SID_TASKSEL'}) and $ENV{'FORCE_SID_TASKSEL'} eq '1') {
# is a non -all package) to determine a valid arch for the rest of
# this script
my $coreutils_deb = `$basedir/tools/which_deb $mirror $codename coreutils binary`;
-if ($coreutils_deb =~ m/_([[:alnum:]]+)\.deb/) {
+if ($coreutils_deb =~ m/_([[:alnum:]-]+)\.deb/) {
$arch = $1;
} else {
die "update_tasks: Can't determine arch!\n";
--
1.8.4.rc3
signature.asc
Description: Digital signature
Bug#860187: debian-cd: Fix which_deb handling of non-Linux arches
Source: debian-cd
Version: 3.1.20
Tags: patch
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-bsd@lists.debian.org
Hi!
When which_deb finds "*i386" or "*amd64" entries in the ARCHES list,
it will wrongly change them to "i386" to "amd64" respectively (which
is wrong in the case of kfreebsd-* or hurd-*).
My attached patch makes the same changes here that were already made to
identical code in generate_di_list, to fix #758512 (commits
771f754516b161f248c132ee9d698e33a6330de0 and
2ef5d3288cdc772cdcbb7b5d11192305dd05b063).
Thanks!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
From 544806f93e860f01f6f1167af2b4462074479af7 Mon Sep 17 00:00:00 2001
From: Steven Chamberlain <stev...@debian.org>
Date: Wed, 12 Apr 2017 17:19:28 +0100
Subject: [PATCH] Fix which_deb handling of non-Linux arches
When which_deb finds "*i386" or "*amd64" entries in the ARCHES list,
it will wrongly change them to "i386" to "amd64" respectively (which
is wrong in the case of kfreebsd-* or hurd-*).
Make the same changes here that were already made to identical code in
generate_di_list, to fix #758512 (commits
771f754516b161f248c132ee9d698e33a6330de0 and
2ef5d3288cdc772cdcbb7b5d11192305dd05b063).
---
tools/which_deb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/which_deb b/tools/which_deb
index d5a5a94..e23c721 100755
--- a/tools/which_deb
+++ b/tools/which_deb
@@ -29,9 +29,9 @@ if (!defined ($output)) {
# Give preference to i386 and amd64, if specified
my @ARCHES;
if ( $ENV{ARCHES} ) {
-push @ARCHES, 'i386' if $ENV{ARCHES} =~ /i386/;
-push @ARCHES, 'amd64' if $ENV{ARCHES} =~ /amd64/;
-push @ARCHES, grep { !/source|i386|amd64/ } split /\s+/, $ENV{ARCHES};
+push @ARCHES, 'i386' if $ENV{ARCHES} =~ /(^|\s)i386(\s|$)/;
+push @ARCHES, 'amd64' if $ENV{ARCHES} =~ /(^|\s)amd64(\s|$)/;
+push @ARCHES, grep { !/^(source|i386|amd64)$/ } split /\s+/, $ENV{ARCHES};
}
# We seem to be building a source-only CD. Check for whatever binary
--
1.8.4.rc3
signature.asc
Description: Digital signature
Bug#860187: debian-cd: Fix which_deb handling of non-Linux arches
Source: debian-cd
Version: 3.1.20
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-...@lists.debian.org
Hi!
When which_deb finds "*i386" or "*amd64" entries in the ARCHES list,
it will wrongly change them to "i386" to "amd64" respectively (which
is wrong in the case of kfreebsd-* or hurd-*).
My attached patch makes the same changes here that were already made to
identical code in generate_di_list, to fix #758512 (commits
771f754516b161f248c132ee9d698e33a6330de0 and
2ef5d3288cdc772cdcbb7b5d11192305dd05b063).
Thanks!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
From 544806f93e860f01f6f1167af2b4462074479af7 Mon Sep 17 00:00:00 2001
From: Steven Chamberlain <stev...@debian.org>
Date: Wed, 12 Apr 2017 17:19:28 +0100
Subject: [PATCH] Fix which_deb handling of non-Linux arches
When which_deb finds "*i386" or "*amd64" entries in the ARCHES list,
it will wrongly change them to "i386" to "amd64" respectively (which
is wrong in the case of kfreebsd-* or hurd-*).
Make the same changes here that were already made to identical code in
generate_di_list, to fix #758512 (commits
771f754516b161f248c132ee9d698e33a6330de0 and
2ef5d3288cdc772cdcbb7b5d11192305dd05b063).
---
tools/which_deb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/which_deb b/tools/which_deb
index d5a5a94..e23c721 100755
--- a/tools/which_deb
+++ b/tools/which_deb
@@ -29,9 +29,9 @@ if (!defined ($output)) {
# Give preference to i386 and amd64, if specified
my @ARCHES;
if ( $ENV{ARCHES} ) {
-push @ARCHES, 'i386' if $ENV{ARCHES} =~ /i386/;
-push @ARCHES, 'amd64' if $ENV{ARCHES} =~ /amd64/;
-push @ARCHES, grep { !/source|i386|amd64/ } split /\s+/, $ENV{ARCHES};
+push @ARCHES, 'i386' if $ENV{ARCHES} =~ /(^|\s)i386(\s|$)/;
+push @ARCHES, 'amd64' if $ENV{ARCHES} =~ /(^|\s)amd64(\s|$)/;
+push @ARCHES, grep { !/^(source|i386|amd64)$/ } split /\s+/, $ENV{ARCHES};
}
# We seem to be building a source-only CD. Check for whatever binary
--
1.8.4.rc3
signature.asc
Description: Digital signature
Bug#860187: debian-cd: Fix which_deb handling of non-Linux arches
Source: debian-cd
Version: 3.1.20
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-...@lists.debian.org
Hi!
When which_deb finds "*i386" or "*amd64" entries in the ARCHES list,
it will wrongly change them to "i386" to "amd64" respectively (which
is wrong in the case of kfreebsd-* or hurd-*).
My attached patch makes the same changes here that were already made to
identical code in generate_di_list, to fix #758512 (commits
771f754516b161f248c132ee9d698e33a6330de0 and
2ef5d3288cdc772cdcbb7b5d11192305dd05b063).
Thanks!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
From 544806f93e860f01f6f1167af2b4462074479af7 Mon Sep 17 00:00:00 2001
From: Steven Chamberlain <stev...@debian.org>
Date: Wed, 12 Apr 2017 17:19:28 +0100
Subject: [PATCH] Fix which_deb handling of non-Linux arches
When which_deb finds "*i386" or "*amd64" entries in the ARCHES list,
it will wrongly change them to "i386" to "amd64" respectively (which
is wrong in the case of kfreebsd-* or hurd-*).
Make the same changes here that were already made to identical code in
generate_di_list, to fix #758512 (commits
771f754516b161f248c132ee9d698e33a6330de0 and
2ef5d3288cdc772cdcbb7b5d11192305dd05b063).
---
tools/which_deb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/which_deb b/tools/which_deb
index d5a5a94..e23c721 100755
--- a/tools/which_deb
+++ b/tools/which_deb
@@ -29,9 +29,9 @@ if (!defined ($output)) {
# Give preference to i386 and amd64, if specified
my @ARCHES;
if ( $ENV{ARCHES} ) {
-push @ARCHES, 'i386' if $ENV{ARCHES} =~ /i386/;
-push @ARCHES, 'amd64' if $ENV{ARCHES} =~ /amd64/;
-push @ARCHES, grep { !/source|i386|amd64/ } split /\s+/, $ENV{ARCHES};
+push @ARCHES, 'i386' if $ENV{ARCHES} =~ /(^|\s)i386(\s|$)/;
+push @ARCHES, 'amd64' if $ENV{ARCHES} =~ /(^|\s)amd64(\s|$)/;
+push @ARCHES, grep { !/^(source|i386|amd64)$/ } split /\s+/, $ENV{ARCHES};
}
# We seem to be building a source-only CD. Check for whatever binary
--
1.8.4.rc3
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
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
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
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
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
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
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
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
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
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
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: [Debconf-discuss] US laptop ban and DebConf
Hi, This thread started out okay, and some practical advice followed. But it's already gone the way of a recent thread on debian-private. For that I came up with this procmail rule: :0: * ^List-Id:.*debian-private.lists\.debian\.org * ^Subject:.*\[off\-topic\] $HOME/.maildir/.Trash/ To avoid having to unsubscribe from debconf-discuss, I now suggest: :0: * ^List-Id:.*debconf-discuss.lists\.debconf\.org * ^Subject:.*US laptop ban and DebConf $HOME/.maildir/.Trash/ Steve Langasek wrote: > On Tue, Mar 21, 2017 at 10:34:10PM +0100, Thomas Goirand wrote: > > Respectfully... > > > Could we please keep politics out of any Debian list? > > No. > > Have a nice day. It's really sad, that I need to start doing things like this now: :0: * ^(From|To):.*vorlon.debian\.org $HOME/.maildir/.Trash/ since mails like these are harming my productivity and motivation recently. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature ___ Debconf-discuss mailing list Debconf-discuss@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-discuss
Bug#858377: libblkmaker: doesn't support current bitcoin block version
Package: libblkmaker Version: 0.5.3-1 Severity: grave Tags: fixed-upstream Hi, The version of libblkmaker in sid/stretch supports bitcoin blocks up to version 4 only: http://sources.debian.net/src/libblkmaker/0.5.3-1/blkmaker.h/#L15 But since early 2016, the tip of the blockchain uses predemonantly versions 0x2000 or later: https://data.bitcoinity.org/bitcoin/block_version/5y?c=block_version=a That seems to make bfgminer unusable; it looks at the tip of the bitcoin blockchain and throws the error, failing to start: "Unrecognized block version, and not allowed to reduce or force it" The current Git master of libblkmaker added support for this: https://github.com/bitcoin/libblkmaker/commit/ae7055df8bbb72dd42dcb6a8d1440ca87da6b0f3 https://github.com/bitcoin/libblkmaker/commit/0d8212c1dcf9dab28d749c08bd107ce0f06d45e3 but I found that bfgminer would still not work unless it also sets BMM_VERFORCE in tmpl->mutations I'm not entirely familiar with any of the above-mentioned software but hopefully the upstream author luke-kr (in Cc:) could comment on these issues. Many 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 Init: sysvinit (via /sbin/init)
Bug#858377: libblkmaker: doesn't support current bitcoin block version
Package: libblkmaker Version: 0.5.3-1 Severity: grave Tags: fixed-upstream Hi, The version of libblkmaker in sid/stretch supports bitcoin blocks up to version 4 only: http://sources.debian.net/src/libblkmaker/0.5.3-1/blkmaker.h/#L15 But since early 2016, the tip of the blockchain uses predemonantly versions 0x2000 or later: https://data.bitcoinity.org/bitcoin/block_version/5y?c=block_version=a That seems to make bfgminer unusable; it looks at the tip of the bitcoin blockchain and throws the error, failing to start: "Unrecognized block version, and not allowed to reduce or force it" The current Git master of libblkmaker added support for this: https://github.com/bitcoin/libblkmaker/commit/ae7055df8bbb72dd42dcb6a8d1440ca87da6b0f3 https://github.com/bitcoin/libblkmaker/commit/0d8212c1dcf9dab28d749c08bd107ce0f06d45e3 but I found that bfgminer would still not work unless it also sets BMM_VERFORCE in tmpl->mutations I'm not entirely familiar with any of the above-mentioned software but hopefully the upstream author luke-kr (in Cc:) could comment on these issues. Many 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 Init: sysvinit (via /sbin/init)
Re: [Debconf-discuss] US laptop ban and DebConf
martin f krafft wrote: > Do not fly via the US. That's my plan also, but: the article suggests that at least Royal Jordanian Airlines would impose the restriction on flights to Montreal despite *not* landing in the US. I don't believe the media coverage; but if this really does happen, hopefully everyone can find a flight/airline avoiding such restrictions. My ideas would be using KLM (direct from Europe) or Wizz Air (via Rejkjavik :) Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature ___ Debconf-discuss mailing list Debconf-discuss@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-discuss
Re: GNU/KFreeBSD on Sun Microsystems X2200 M2 AMD 64bit
Hello, (please make sure to use debian-bsd@lists.debian.org for these kinds of questions/discussion) pdb wrote: > i would like to know if i can install GNU/KFreeBSD on my Sun Microsystems > X2200 M2 AMD 64 bit Quad Core 2.3 Ghz I would really like one of those myself! It should be a good choice for running kfreebsd-amd64, but there are two important things to check: * Ethernet chipset Earlier Sun Fire (v20z) used a Broadcom chipset requiring non-free microcode, that means the FreeBSD kernel supports it but the (free software) Debian kernel does not. I think the X2200 M2 has the same. That would make it difficult to install kfreebsd. A good solution is to install an Intel PCIe dual/quad Gigabit NIC and use that instead of the built-in Ethernet ports (this is not so expensive). * SATA/RAID chipset This server sometimes comes with an LSI SAS/SATA RAID controller (PCIe card), which should be okay (but you have to configure RAID via the BIOS, you would not be able to reconfigure that within kfreebsd). Otherwise, the server may only come with onboard NVIDIA SATA, and I don't know how well that works with kfreebsd (probably okay). Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: arc4random weakness
Steven Chamberlain wrote: > Please consider switching to ChaCha20 in the long term (kern/182610), > but right now, at least increase the amount of early keystream that is > discarded. Many, many thanks delphij+so for applying the latter change so quickly! Also it is great to see INHERIT_ZERO was added to mmap(2)! (It will avoid the overhead of a getpid(2) syscall on every call to arc4random_buf(3) to determine if reseeding is needed. That wasn't guaranteed reliable anyway; if you have forked twice, then by chance/manipulation the new pid *could* be the same as the ancestor's). Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: arc4random weakness (was: WikiLeaks CIA Exploits: FreeBSD References Within)
From this document (TOP SECRET//SI//NOFORN): https://wikileaks.org/ciav7p1/cms/files/NOD%20Cryptographic%20Requirements%20v1.1%20TOP%20SECRET.pdf version 1.0 said: | 8. (S//NF) [...] If RC4 is used, at least the first 1024 | bytes of the cryptostream must be discarded and may not be used and that is exactly what FreeBSD's libc and in-kernel arc4random implementations do. version 1.1 received input from another agency: | (C//SI//REL FVEY) Coordinated with NSA/CES. and a new requirement was introduced: | (TS//SI) 5.9: Added additional information about proper use of RC4. | 9. (TS//SI) Further than stated above, if RC4 is used the first 3072 | bytes of the cryptostream must be discarded and may not be used. I think you should take that to mean, the NSA has, or suspects someone else to have, a practical attack on RC4 when being used as FreeBSD does currently. The document seems 4-5 years old already as it prohibits use of RC4 at all from 2014 onward. Please consider switching to ChaCha20 in the long term (kern/182610), but right now, at least increase the amount of early keystream that is discarded. Many thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org diff -Nru a/head/lib/libc/gen/arc4random.c b/head/lib/libc/gen/arc4random.c --- a/head/lib/libc/gen/arc4random.c 2016-10-12 14:56:14.834409000 +0100 +++ b/head/lib/libc/gen/arc4random.c 2017-03-13 21:57:16.532833171 + @@ -160,7 +160,7 @@ * Discard early keystream, as per recommendations in: * "(Not So) Random Shuffles of RC4" by Ilya Mironov. */ - for (i = 0; i < 1024; i++) + for (i = 0; i < 3072; i++) (void)arc4_getbyte(); arc4_count = 160; } diff -Nru a/head/sys/libkern/arc4random.c b/head/sys/libkern/arc4random.c --- a/head/sys/libkern/arc4random.c 2016-11-25 17:20:23.862538000 + +++ b/head/sys/libkern/arc4random.c 2017-03-13 21:58:45.985402563 + @@ -84,11 +84,11 @@ /* * Throw away the first N words of output, as suggested in the * paper "Weaknesses in the Key Scheduling Algorithm of RC4" - * by Fluher, Mantin, and Shamir. (N = 256 in our case.) + * by Fluher, Mantin, and Shamir. (N = 768 in our case.) * * http://dl.acm.org/citation.cfm?id=646557.694759 */ - for (n = 0; n < 256*4; n++) + for (n = 0; n < 768*4; n++) arc4_randbyte(arc4); mtx_unlock(>mtx); signature.asc Description: Digital signature
Bug#856688: dh_auto_configure: wrong CMAKE_SYSTEM_NAME for kfreebsd cross-builds
Package: debhelper Version: 10.2.5 Tags: patch Hi, When cross-building a kfreebsd host system, dh_auto_configure invokes cmake something like this: cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_SYSTEM_NAME=FreeBSD -DCMAKE_SYSTEM_PROCESSOR=i686 -DCMAKE_C_COMPILER=i686-kfreebsd-gnu-gcc -DCMAKE_CXX_COMPILER=i686-kfreebsd-gnu-g\+\+ -DPKG_CONFIG_EXECUTABLE=/usr/bin/i686-kfreebsd-gnu-pkg-config -DCMAKE_INSTALL_LIBDIR=lib/i386-kfreebsd-gnu but here, CMAKE_SYSTEM_NAME is not the correct value, it should rather be the GNU variant "kFreeBSD", not just "FreeBSD". The very simple patch for this is attached. 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 Init: sysvinit (via /sbin/init) diff --git a/Debian/Debhelper/Buildsystem/cmake.pm b/Debian/Debhelper/Buildsystem/cmake.pm index 338f65e..e9a6bbb 100644 --- a/Debian/Debhelper/Buildsystem/cmake.pm +++ b/Debian/Debhelper/Buildsystem/cmake.pm @@ -21,7 +21,7 @@ my @STANDARD_CMAKE_FLAGS = qw( my %DEB_HOST2CMAKE_SYSTEM = ( 'linux'=> 'Linux', - 'kfreebsd' => 'FreeBSD', + 'kfreebsd' => 'kFreeBSD', 'hurd' => 'GNU', ); diff --git a/debian/changelog b/debian/changelog index 2078897..d96cd5a 100644 --- a/debian/changelog +++ b/debian/changelog @@ -11,6 +11,10 @@ debhelper (10.2.6) UNRELEASED; urgency=medium of the order of the fields in a given paragraph of debian/control. (Closes: #847138) + [ Steven Chamberlain ] + * When cross-compiling for GNU/kFreeBSD host systems, set +CMAKE_SYSTEM_NAME to the correct value "kFreeBSD", not "FreeBSD". + -- Helmut Grohne <hel...@subdivi.de> Sat, 18 Feb 2017 17:49:08 + debhelper (10.2.5) unstable; urgency=medium
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Control: tags -1 - patch I've no more desire to work on this bug, sorry. Thanks for the feedback that was given, but it has already been more effort than I have time or patience to contribute. For what should be essentially, s/md5/sha256/ in a few places, the required procedures and personal interactions beyond that, is just too much. That is the real "debacle"; it is not surprising to me now, that this did not happen yet in 10 years, or that no enthusiastic new contributor had already done this. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Control: tags -1 - patch I've no more desire to work on this bug, sorry. Thanks for the feedback that was given, but it has already been more effort than I have time or patience to contribute. For what should be essentially, s/md5/sha256/ in a few places, the required procedures and personal interactions beyond that, is just too much. That is the real "debacle"; it is not surprising to me now, that this did not happen yet in 10 years, or that no enthusiastic new contributor had already done this. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Control: tags -1 - patch I've no more desire to work on this bug, sorry. Thanks for the feedback that was given, but it has already been more effort than I have time or patience to contribute. For what should be essentially, s/md5/sha256/ in a few places, the required procedures and personal interactions beyond that, is just too much. That is the real "debacle"; it is not surprising to me now, that this did not happen yet in 10 years, or that no enthusiastic new contributor had already done this. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Bastian Blank wrote: > On Tue, Feb 28, 2017 at 10:00:01PM +0000, Steven Chamberlain wrote: > > That differs from the latest version of my patch, and from what I sent > > earlier today to the release team when asking about a potential unblock: > > https://lists.debian.org/debian-release/2017/02/msg01033.html > > This happens if you send incomplete patches and do uncoordinated unblock > requests. Maybe you just volunteered to do that, then. You even said before you "don't have time" to write the cdebootstrap patch, so I offered one, and the anna patch, the libdebian-installer patch, all this after the initial discovery, triage and write-up. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Bastian Blank wrote: > On Tue, Feb 28, 2017 at 10:00:01PM +0000, Steven Chamberlain wrote: > > That differs from the latest version of my patch, and from what I sent > > earlier today to the release team when asking about a potential unblock: > > https://lists.debian.org/debian-release/2017/02/msg01033.html > > This happens if you send incomplete patches and do uncoordinated unblock > requests. Maybe you just volunteered to do that, then. You even said before you "don't have time" to write the cdebootstrap patch, so I offered one, and the anna patch, the libdebian-installer patch, all this after the initial discovery, triage and write-up. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Bastian Blank wrote: > On Tue, Feb 28, 2017 at 10:00:01PM +0000, Steven Chamberlain wrote: > > That differs from the latest version of my patch, and from what I sent > > earlier today to the release team when asking about a potential unblock: > > https://lists.debian.org/debian-release/2017/02/msg01033.html > > This happens if you send incomplete patches and do uncoordinated unblock > requests. Maybe you just volunteered to do that, then. You even said before you "don't have time" to write the cdebootstrap patch, so I offered one, and the anna patch, the libdebian-installer patch, all this after the initial discovery, triage and write-up. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Bastian Blank wrote: > Adopted and commited to > https://anonscm.debian.org/git/d-i/libdebian-installer.git, branch > sha256 That differs from the latest version of my patch, and from what I sent earlier today to the release team when asking about a potential unblock: https://lists.debian.org/debian-release/2017/02/msg01033.html I think we should wait for them to answer before doing anything else. Based on KiBi's feedback I thought it better to swap sum[0] and sum[1], and remove the SHA1 parsing also. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Bastian Blank wrote: > Adopted and commited to > https://anonscm.debian.org/git/d-i/libdebian-installer.git, branch > sha256 That differs from the latest version of my patch, and from what I sent earlier today to the release team when asking about a potential unblock: https://lists.debian.org/debian-release/2017/02/msg01033.html I think we should wait for them to answer before doing anything else. Based on KiBi's feedback I thought it better to swap sum[0] and sum[1], and remove the SHA1 parsing also. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs
Bastian Blank wrote: > Adopted and commited to > https://anonscm.debian.org/git/d-i/libdebian-installer.git, branch > sha256 That differs from the latest version of my patch, and from what I sent earlier today to the release team when asking about a potential unblock: https://lists.debian.org/debian-release/2017/02/msg01033.html I think we should wait for them to answer before doing anything else. Based on KiBi's feedback I thought it better to swap sum[0] and sum[1], and remove the SHA1 parsing also. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856405: unblock: libdebian-installer/0.109 and others
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: debian-boot@lists.debian.org Hi! Attached are proposed debdiffs for anna, cdebootstrap and their dependency libdebian-installer (Bug #856210). Would the release team be willing to grant unblocks for these? (It would also require an ACK from the d-i release manager). In the installer, net-retriever verifies the Release file with SHA256, but anna only validates the .udeb files with MD5, which was surprising. The .udeb files are extracted and then their contents may be executed with full privileges during the install (Bug #856211). netboot images typically fetch .udeb files over unsecured HTTP. Other install media bundles those so they need not be downloaded, but it could still happen if networking is configured during the install and a network mirror has newer versions of any required .udeb files. (Some .udeb files are retrieved later, after installing the base system). If not already considered a grave security flaw, it might be during the lifetime of stretch (-2022?). Even if fixed in a point release, any install media created before then would remain vulnerable. cdebootstrap - not used by the installer, but available in stretch - only verifies Release files using MD5 (Bug #856215), which is an unintended regression since jessie. The changes to libdebian-installer are ABI-compatible, such that only reverse-dependencies that use the md5sum field should be affected (thought to be just anna and cdebootstrap). They would FTBFS until patched, and already-built binaries would report a "md5sum mismatch" if they used this new version of the library at run-time, since the new SHA256 hashes would not match the MD5 hashes they expect. unblock libdebian-installer/0.109 unblock anna/1.58 unblock cdebootstrap/0.7.7 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 Init: sysvinit (via /sbin/init) diff -Nru libdebian-installer-0.108/debian/changelog libdebian-installer-0.109/debian/changelog --- libdebian-installer-0.108/debian/changelog 2016-08-30 05:45:17.0 +0100 +++ libdebian-installer-0.109/debian/changelog 2017-02-28 16:36:45.0 + @@ -1,3 +1,15 @@ +libdebian-installer (0.109) unstable; urgency=high + + * In structs di_release and di_package, replace md5sum member with a +sha256 member. This is ABI-compatible, but reverse-dependencies +will fail if they still try to verify with MD5 (Closes: #856212). + * Parse SHA256 fields instead of MD5Sum fields in Packages files. + * Parse SHA256 fields instead of MD5Sum fields in Release files. + * No longer try to parse SHA1 field, which is no longer present in +Release files as of stretch. + + -- Steven Chamberlain <stev...@debian.org> Tue, 28 Feb 2017 16:36:45 + + libdebian-installer (0.108) unstable; urgency=medium [ Helmut Grohne ] diff -Nru libdebian-installer-0.108/include/debian-installer/package.h libdebian-installer-0.109/include/debian-installer/package.h --- libdebian-installer-0.108/include/debian-installer/package.h 2011-03-03 02:00:33.0 + +++ libdebian-installer-0.109/include/debian-installer/package.h 2017-02-28 16:33:59.0 + @@ -112,7 +112,7 @@ di_slist depends; /**< Any different dependency types */ char *filename; /**< Filename field */ size_t size; /**< Size field */ - char *md5sum; /**< MD5Sum field */ + char *sha256; /**< SHA256 field */ char *short_description; /**< Description field, first part*/ char *description;/**< Description field, second part */ unsigned int resolver;/**< @internal */ diff -Nru libdebian-installer-0.108/include/debian-installer/package_internal.h libdebian-installer-0.109/include/debian-installer/package_internal.h --- libdebian-installer-0.108/include/debian-installer/package_internal.h 2011-03-03 02:00:33.0 + +++ libdebian-installer-0.109/include/debian-installer/package_internal.h 2017-02-28 16:33:59.0 + @@ -52,7 +52,7 @@ internal_di_package_parser_field_enhances, internal_di_package_parser_field_filename, internal_di_package_parser_field_size, - internal_di_package_parser_field_md5sum, + internal_di_package_parser_field_sha256, internal_di_package_parser_field_description; /** diff -Nru libdebian-installer-0.108/include/debian-installer/release.h libdebian-installer-
Bug#856405: unblock: libdebian-installer/0.109 and others
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: debian-b...@lists.debian.org Hi! Attached are proposed debdiffs for anna, cdebootstrap and their dependency libdebian-installer (Bug #856210). Would the release team be willing to grant unblocks for these? (It would also require an ACK from the d-i release manager). In the installer, net-retriever verifies the Release file with SHA256, but anna only validates the .udeb files with MD5, which was surprising. The .udeb files are extracted and then their contents may be executed with full privileges during the install (Bug #856211). netboot images typically fetch .udeb files over unsecured HTTP. Other install media bundles those so they need not be downloaded, but it could still happen if networking is configured during the install and a network mirror has newer versions of any required .udeb files. (Some .udeb files are retrieved later, after installing the base system). If not already considered a grave security flaw, it might be during the lifetime of stretch (-2022?). Even if fixed in a point release, any install media created before then would remain vulnerable. cdebootstrap - not used by the installer, but available in stretch - only verifies Release files using MD5 (Bug #856215), which is an unintended regression since jessie. The changes to libdebian-installer are ABI-compatible, such that only reverse-dependencies that use the md5sum field should be affected (thought to be just anna and cdebootstrap). They would FTBFS until patched, and already-built binaries would report a "md5sum mismatch" if they used this new version of the library at run-time, since the new SHA256 hashes would not match the MD5 hashes they expect. unblock libdebian-installer/0.109 unblock anna/1.58 unblock cdebootstrap/0.7.7 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 Init: sysvinit (via /sbin/init) diff -Nru libdebian-installer-0.108/debian/changelog libdebian-installer-0.109/debian/changelog --- libdebian-installer-0.108/debian/changelog 2016-08-30 05:45:17.0 +0100 +++ libdebian-installer-0.109/debian/changelog 2017-02-28 16:36:45.0 + @@ -1,3 +1,15 @@ +libdebian-installer (0.109) unstable; urgency=high + + * In structs di_release and di_package, replace md5sum member with a +sha256 member. This is ABI-compatible, but reverse-dependencies +will fail if they still try to verify with MD5 (Closes: #856212). + * Parse SHA256 fields instead of MD5Sum fields in Packages files. + * Parse SHA256 fields instead of MD5Sum fields in Release files. + * No longer try to parse SHA1 field, which is no longer present in +Release files as of stretch. + + -- Steven Chamberlain <stev...@debian.org> Tue, 28 Feb 2017 16:36:45 + + libdebian-installer (0.108) unstable; urgency=medium [ Helmut Grohne ] diff -Nru libdebian-installer-0.108/include/debian-installer/package.h libdebian-installer-0.109/include/debian-installer/package.h --- libdebian-installer-0.108/include/debian-installer/package.h 2011-03-03 02:00:33.0 + +++ libdebian-installer-0.109/include/debian-installer/package.h 2017-02-28 16:33:59.0 + @@ -112,7 +112,7 @@ di_slist depends; /**< Any different dependency types */ char *filename; /**< Filename field */ size_t size; /**< Size field */ - char *md5sum; /**< MD5Sum field */ + char *sha256; /**< SHA256 field */ char *short_description; /**< Description field, first part*/ char *description;/**< Description field, second part */ unsigned int resolver;/**< @internal */ diff -Nru libdebian-installer-0.108/include/debian-installer/package_internal.h libdebian-installer-0.109/include/debian-installer/package_internal.h --- libdebian-installer-0.108/include/debian-installer/package_internal.h 2011-03-03 02:00:33.0 + +++ libdebian-installer-0.109/include/debian-installer/package_internal.h 2017-02-28 16:33:59.0 + @@ -52,7 +52,7 @@ internal_di_package_parser_field_enhances, internal_di_package_parser_field_filename, internal_di_package_parser_field_size, - internal_di_package_parser_field_md5sum, + internal_di_package_parser_field_sha256, internal_di_package_parser_field_description; /** diff -Nru libdebian-installer-0.108/include/debian-installer/release.h libdebian-installer-
Bug#856405: unblock: libdebian-installer/0.109 and others
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: debian-b...@lists.debian.org Hi! Attached are proposed debdiffs for anna, cdebootstrap and their dependency libdebian-installer (Bug #856210). Would the release team be willing to grant unblocks for these? (It would also require an ACK from the d-i release manager). In the installer, net-retriever verifies the Release file with SHA256, but anna only validates the .udeb files with MD5, which was surprising. The .udeb files are extracted and then their contents may be executed with full privileges during the install (Bug #856211). netboot images typically fetch .udeb files over unsecured HTTP. Other install media bundles those so they need not be downloaded, but it could still happen if networking is configured during the install and a network mirror has newer versions of any required .udeb files. (Some .udeb files are retrieved later, after installing the base system). If not already considered a grave security flaw, it might be during the lifetime of stretch (-2022?). Even if fixed in a point release, any install media created before then would remain vulnerable. cdebootstrap - not used by the installer, but available in stretch - only verifies Release files using MD5 (Bug #856215), which is an unintended regression since jessie. The changes to libdebian-installer are ABI-compatible, such that only reverse-dependencies that use the md5sum field should be affected (thought to be just anna and cdebootstrap). They would FTBFS until patched, and already-built binaries would report a "md5sum mismatch" if they used this new version of the library at run-time, since the new SHA256 hashes would not match the MD5 hashes they expect. unblock libdebian-installer/0.109 unblock anna/1.58 unblock cdebootstrap/0.7.7 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 Init: sysvinit (via /sbin/init) diff -Nru libdebian-installer-0.108/debian/changelog libdebian-installer-0.109/debian/changelog --- libdebian-installer-0.108/debian/changelog 2016-08-30 05:45:17.0 +0100 +++ libdebian-installer-0.109/debian/changelog 2017-02-28 16:36:45.0 + @@ -1,3 +1,15 @@ +libdebian-installer (0.109) unstable; urgency=high + + * In structs di_release and di_package, replace md5sum member with a +sha256 member. This is ABI-compatible, but reverse-dependencies +will fail if they still try to verify with MD5 (Closes: #856212). + * Parse SHA256 fields instead of MD5Sum fields in Packages files. + * Parse SHA256 fields instead of MD5Sum fields in Release files. + * No longer try to parse SHA1 field, which is no longer present in +Release files as of stretch. + + -- Steven Chamberlain <stev...@debian.org> Tue, 28 Feb 2017 16:36:45 + + libdebian-installer (0.108) unstable; urgency=medium [ Helmut Grohne ] diff -Nru libdebian-installer-0.108/include/debian-installer/package.h libdebian-installer-0.109/include/debian-installer/package.h --- libdebian-installer-0.108/include/debian-installer/package.h 2011-03-03 02:00:33.0 + +++ libdebian-installer-0.109/include/debian-installer/package.h 2017-02-28 16:33:59.0 + @@ -112,7 +112,7 @@ di_slist depends; /**< Any different dependency types */ char *filename; /**< Filename field */ size_t size; /**< Size field */ - char *md5sum; /**< MD5Sum field */ + char *sha256; /**< SHA256 field */ char *short_description; /**< Description field, first part*/ char *description;/**< Description field, second part */ unsigned int resolver;/**< @internal */ diff -Nru libdebian-installer-0.108/include/debian-installer/package_internal.h libdebian-installer-0.109/include/debian-installer/package_internal.h --- libdebian-installer-0.108/include/debian-installer/package_internal.h 2011-03-03 02:00:33.0 + +++ libdebian-installer-0.109/include/debian-installer/package_internal.h 2017-02-28 16:33:59.0 + @@ -52,7 +52,7 @@ internal_di_package_parser_field_enhances, internal_di_package_parser_field_filename, internal_di_package_parser_field_size, - internal_di_package_parser_field_md5sum, + internal_di_package_parser_field_sha256, internal_di_package_parser_field_description; /** diff -Nru libdebian-installer-0.108/include/debian-installer/release.h libdebian-installer-
Bug#856212: cdebootstrap: please implement SHA256 verification of .deb files
Control: tags -1 + patch
Hi,
The attached patch is based on having
libdebian-installer_bug856210_v3.patch applied:
* libdebian-installer4-dev would not change its name
* sum[1] is already empty/unusable
* sum[0] would become the sha256 field
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/debian/changelog b/debian/changelog
index c73f96e..96b0eee 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+cdebootstrap (0.7.7) UNRELEASED; urgency=medium
+
+ * Team upload.
+ * Implement SHA256 verification of .deb files (Closes: #856212).
+ * Implement SHA256 verification of Packages files.
+- (Build-)Depend on libdebian-installer4-dev >= 0.109 which provides
+ those sha256 fields
+ * Remove support for SHA1 hashes, since they are no longer published
+in Release files, and the full length of them was not previously
+being checked against the expected values (Closes: #856213).
+ * Disallow fallback to MD5-only verification (Closes: #856215).
+
+ -- Steven Chamberlain <stev...@debian.org> Mon, 27 Feb 2017 15:53:40 +
+
cdebootstrap (0.7.6) unstable; urgency=medium
* Make generation of tar reproducible. (closes: #37)
diff --git a/debian/control b/debian/control
index 49bb110..6996ce5 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends:
libbz2-dev,
libcurl4-gnutls-dev,
libdebconfclient0-dev (>= 0.40),
- libdebian-installer4-dev (>= 0.81~),
+ libdebian-installer4-dev (>= 0.109~),
liblzma-dev,
pkg-config,
zlib1g-dev
diff --git a/src/check.c b/src/check.c
index 34e96da..c41d9e4 100644
--- a/src/check.c
+++ b/src/check.c
@@ -32,6 +32,9 @@
#include "frontend.h"
#include "suite.h"
+/* Length of a SHA256 hash in hex representation */
+#define SHA256_HEX_LENGTH 64
+
static int check_sum (const char *target, const char *exec, const char *sum, const char *message)
{
int ret;
@@ -51,14 +54,14 @@ static int check_sum (const char *target, const char *exec, const char *sum, con
if (ret)
return 1;
- if (!strncmp (buf, sum, 32))
+ if (!strncmp (buf, sum, SHA256_HEX_LENGTH))
return 0;
return 1;
}
int check_deb (const char *target, di_package *p, const char *message)
{
- return check_sum (target, "md5sum", p->md5sum, message);
+ return check_sum (target, "sha256sum", p->sha256, message);
}
int check_packages (const char *target, const char *ext, di_release *rel)
@@ -72,14 +75,12 @@ int check_packages (const char *target, const char *ext, di_release *rel)
snprintf (buf_file, sizeof (buf_file), "main/binary-%s/Packages%s", arch, ext);
key.string = (char *) buf_file;
key.size = strlen (buf_file);
- item = di_hash_table_lookup (rel->md5sum, );
+ item = di_hash_table_lookup (rel->sha256, );
if (!item)
log_text (DI_LOG_LEVEL_ERROR, "Can't find checksum for Packages file");
- if (item->sum[1])
-return check_sum (target, "sha1sum", item->sum[1], buf_name);
if (item->sum[0])
-return check_sum (target, "md5sum", item->sum[0], buf_name);
+return check_sum (target, "sha256sum", item->sum[0], buf_name);
return 1;
}
signature.asc
Description: Digital signature
Bug#856212: cdebootstrap: please implement SHA256 verification of .deb files
Control: tags -1 + patch
Hi,
The attached patch is based on having
libdebian-installer_bug856210_v3.patch applied:
* libdebian-installer4-dev would not change its name
* sum[1] is already empty/unusable
* sum[0] would become the sha256 field
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/debian/changelog b/debian/changelog
index c73f96e..96b0eee 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+cdebootstrap (0.7.7) UNRELEASED; urgency=medium
+
+ * Team upload.
+ * Implement SHA256 verification of .deb files (Closes: #856212).
+ * Implement SHA256 verification of Packages files.
+- (Build-)Depend on libdebian-installer4-dev >= 0.109 which provides
+ those sha256 fields
+ * Remove support for SHA1 hashes, since they are no longer published
+in Release files, and the full length of them was not previously
+being checked against the expected values (Closes: #856213).
+ * Disallow fallback to MD5-only verification (Closes: #856215).
+
+ -- Steven Chamberlain <stev...@debian.org> Mon, 27 Feb 2017 15:53:40 +
+
cdebootstrap (0.7.6) unstable; urgency=medium
* Make generation of tar reproducible. (closes: #37)
diff --git a/debian/control b/debian/control
index 49bb110..6996ce5 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends:
libbz2-dev,
libcurl4-gnutls-dev,
libdebconfclient0-dev (>= 0.40),
- libdebian-installer4-dev (>= 0.81~),
+ libdebian-installer4-dev (>= 0.109~),
liblzma-dev,
pkg-config,
zlib1g-dev
diff --git a/src/check.c b/src/check.c
index 34e96da..c41d9e4 100644
--- a/src/check.c
+++ b/src/check.c
@@ -32,6 +32,9 @@
#include "frontend.h"
#include "suite.h"
+/* Length of a SHA256 hash in hex representation */
+#define SHA256_HEX_LENGTH 64
+
static int check_sum (const char *target, const char *exec, const char *sum, const char *message)
{
int ret;
@@ -51,14 +54,14 @@ static int check_sum (const char *target, const char *exec, const char *sum, con
if (ret)
return 1;
- if (!strncmp (buf, sum, 32))
+ if (!strncmp (buf, sum, SHA256_HEX_LENGTH))
return 0;
return 1;
}
int check_deb (const char *target, di_package *p, const char *message)
{
- return check_sum (target, "md5sum", p->md5sum, message);
+ return check_sum (target, "sha256sum", p->sha256, message);
}
int check_packages (const char *target, const char *ext, di_release *rel)
@@ -72,14 +75,12 @@ int check_packages (const char *target, const char *ext, di_release *rel)
snprintf (buf_file, sizeof (buf_file), "main/binary-%s/Packages%s", arch, ext);
key.string = (char *) buf_file;
key.size = strlen (buf_file);
- item = di_hash_table_lookup (rel->md5sum, );
+ item = di_hash_table_lookup (rel->sha256, );
if (!item)
log_text (DI_LOG_LEVEL_ERROR, "Can't find checksum for Packages file");
- if (item->sum[1])
-return check_sum (target, "sha1sum", item->sum[1], buf_name);
if (item->sum[0])
-return check_sum (target, "md5sum", item->sum[0], buf_name);
+return check_sum (target, "sha256sum", item->sum[0], buf_name);
return 1;
}
signature.asc
Description: Digital signature
