apt-setup merge request on Salsa - please comment

[Holger Wansing]

Hi guys,

we got a merge request on Salsa for apt-setup, with changings to questions/
dialogs in debian-installer regarding firmware:

https://salsa.debian.org/installer-team/apt-setup/-/merge_requests/15

Could someone please review that one?
(for example, see 
https://salsa.debian.org/installer-team/apt-setup/-/merge_requests/15#note_464848
 )

Many thanks

Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1060292: Flash-kernel add Sipeed Lichee Pi 4A - merge request

[Heinrich Schuchardt]

Merge request:

https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/54

Re: Bug#1035316: [pre-approval request] unblock: firmware-nonfree/20230210-5

[Salvatore Bonaccorso]

Hi,

On Mon, May 01, 2023 at 06:36:01PM +0200, Cyril Brulebois wrote:
> Hi,
> 
> Salvatore Bonaccorso  (2023-04-30):
> > [ Other info ]
> > As beeing the firmware-nonfree package, I'm explicitly CC'ing as well
> > Cyril on this pre-approval request.
> 
> Thanks for that.
> 
> > Furthermore the attached debdiff still contains the UNRELEASED
> > changelog entry, which will be switched for the upload.
> 
> ACK.
> 
> With both my d-i and release hats: looks good to me, please go ahead.

Thanks Cyril for the review. Just uploaded.

Regards,
Salvatore

Re: Bug#1035316: [pre-approval request] unblock: firmware-nonfree/20230210-5

[Cyril Brulebois]

Hi,

Salvatore Bonaccorso  (2023-04-30):
> [ Other info ]
> As beeing the firmware-nonfree package, I'm explicitly CC'ing as well
> Cyril on this pre-approval request.

Thanks for that.

> Furthermore the attached debdiff still contains the UNRELEASED
> changelog entry, which will be switched for the upload.

ACK.

With both my d-i and release hats: looks good to me, please go ahead.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1035316: [pre-approval request] unblock: firmware-nonfree/20230210-5

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: firmware-nonf...@packages.debian.org, k...@debian.org, 
debian-boot@lists.debian.org, debian-ker...@lists.debian.org, car...@debian.org
Control: affects -1 + src:firmware-nonfree

Dear release team,

Please unblock package firmware-nonfree

[ Reason ]
A piuparts run from Andreas found that we had broken symlink for
two firmware files in firmware-brcm80211, cf. #1035282. The reason was
that we missed a rename back in upstream 20220411, included in the
upload in Debian as 20210208-1.

[ Impact ]
Loading of firmware for Rock960 Cypress 4356 WiFi, and those using
VIM2 4356 WiFi devices would not work.

[ Tests ]
None additional done specifically to the change apart the packaging
build pipeline and verifying that the links are now correctly placed.

[ Risks ]
Adds the missing symlinks for the firmware files.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
As beeing the firmware-nonfree package, I'm explicitly CC'ing as well
Cyril on this pre-approval request.

Furthermore the attached debdiff still contains the UNRELEASED
changelog entry, which will be switched for the upload.

The upload adds as well one further additional link for
brcmfmac4356-sdio.firefly,firefly-rk3399.txt to mirror all changes
upstream did with
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=4ffcf980a535c1f26aa994ecf64a1b9d1ed6216e
.

unblock firmware-nonfree/20230210-5

Regards,
Salvatore
diff -Nru firmware-nonfree-20230210/debian/changelog 
firmware-nonfree-20230210/debian/changelog
--- firmware-nonfree-20230210/debian/changelog  2023-03-11 15:15:03.0 
+0100
+++ firmware-nonfree-20230210/debian/changelog  2023-04-30 07:31:54.0 
+0200
@@ -1,3 +1,11 @@
+firmware-nonfree (20230210-5) UNRELEASED; urgency=medium
+
+  * brcm80211: brcm: rename Rock960 NVRAM to AP6356S and link devices to it
+(Closes: #1035282)
+  * Update to linux-support 6.1.0-8
+
+ -- Salvatore Bonaccorso   Sun, 30 Apr 2023 07:31:54 +0200
+
 firmware-nonfree (20230210-4) unstable; urgency=medium
 
   * iwlwifi: Add missing files entry for iwlwifi-so-a0-hr-b0-72.ucode.
diff -Nru firmware-nonfree-20230210/debian/config/brcm80211/defines 
firmware-nonfree-20230210/debian/config/brcm80211/defines
--- firmware-nonfree-20230210/debian/config/brcm80211/defines   2023-03-11 
14:25:34.0 +0100
+++ firmware-nonfree-20230210/debian/config/brcm80211/defines   2023-04-30 
07:30:52.0 +0200
@@ -59,8 +59,10 @@
  brcm/brcmfmac4356-pcie.clm_blob
  brcm/brcmfmac4356-sdio.bin
  brcm/brcmfmac4356-sdio.clm_blob
- brcm/brcmfmac4356-sdio.vamrs,rock960.txt
+ brcm/brcmfmac4356-sdio.AP6356S.txt
+ brcm/brcmfmac4356-sdio.firefly,firefly-rk3399.txt
  brcm/brcmfmac4356-sdio.khadas,vim2.txt
+ brcm/brcmfmac4356-sdio.vamrs,rock960.txt
  brcm/brcmfmac4358-pcie.bin
  brcm/brcmfmac43602-pcie.ap.bin
  brcm/brcmfmac43602-pcie.bin
@@ -192,8 +194,8 @@
 [brcm/brcmfmac4356-pcie.gpd-win-pocket.txt_base]
 desc: Broadcom BCM4356-PCIe NVRAM for GPD Pocket and Win
 
-[brcm/brcmfmac4356-sdio.vamrs,rock960.txt_base]
-desc: Rock960 Cypress 4356 WiFi 
+[brcm/brcmfmac4356-sdio.AP6356S.txt_base]
+desc: Broadcom AP6356S WiFi module NVRAM
 
 [brcm/brcmfmac4358-pcie.bin_base]
 desc: Broadcom BCM4358 firmware
diff -Nru firmware-nonfree-20230210/debian/control 
firmware-nonfree-20230210/debian/control
--- firmware-nonfree-20230210/debian/control2023-03-11 15:15:03.0 
+0100
+++ firmware-nonfree-20230210/debian/control2023-04-30 07:31:54.0 
+0200
@@ -1407,6 +1407,11 @@
   * Broadcom BCM43569 firmware (brcm/brcmfmac43569.bin)
   * Broadcom BCM4356-PCIe NVRAM for GPD Pocket and Win
 (brcm/brcmfmac4356-pcie.gpd-win-pocket.txt)
+  * Broadcom AP6356S WiFi module NVRAM
+(brcm/brcmfmac4356-sdio.AP6356S.txt,
+brcm/brcmfmac4356-sdio.firefly,firefly-rk3399.txt,
+brcm/brcmfmac4356-sdio.khadas,vim2.txt,
+brcm/brcmfmac4356-sdio.vamrs,rock960.txt)
   * Broadcom BCM4358 firmware (brcm/brcmfmac4358-pcie.bin)
   * Broadcom BCM43602 AP-mode firmware (brcm/brcmfmac43602-pcie.ap.bin)
   * Broadcom BCM43602 firmware (brcm/brcmfmac43602-pcie.bin)
diff -Nru firmware-nonfree-20230210/debian/control.md5sum 
firmware-nonfree-20230210/debian/control.md5sum
--- firmware-nonfree-20230210/debian/control.md5sum 2023-03-11 
15:15:03.0 +0100
+++ firmware-nonfree-20230210/debian/control.md5sum 2023-04-30 
07:31:54.0 +0200
@@ -1,5 +1,5 @@
 756f19279d2cfa999df58e6455f10465  debian/bin/gencontrol.py
-2ef82c26fcd61901f230fcbd975e12c5  debian/build/version-info
+292ee54d1efa3dd0e5f82b863b8c46c6  debian/build/version-info
 29c8d86cbba7d798701946b1d990539e  debian/templates/control.binary.in
 c03e4b00d7d344da35e815e921d78018  debian/templates/control.extra.in

Re: DebianInstaller Help Request

[Cyril Brulebois]

Hello Marcus,

Marcus L. Thompson  (2021-07-21):
> I need help locating the following information:
> 
>  * what processes are called during the "remove-live-packages" routine
>which is invoked at the end of the installation process for Debian
>10; and
>  * where the relevant configuration file(s) for this aspect of the
>installer's operations may be located in the live distro iso.
> 
> Thank you.

You'll want to check with debian-live@ (in copy).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

DebianInstaller Help Request

[Marcus L. Thompson]

Good day.

I need help locating the following information:

 * what processes are called during the "remove-live-packages" routine
   which is invoked at the end of the installation process for Debian
   10; and
 * where the relevant configuration file(s) for this aspect of the
   installer's operations may be located in the live distro iso.

Thank you.

Re: Request for weblate usage in installation-guide Japanese translation (was Re: Request for weblate usage in d-i Japanese translation)

[Holger Wansing]

Hi,

YOSHINO Yoshihito  wrote (Sun, 30 May 2021 10:56:02 
+0900):
> 
> Thanks! Now ja translation for d-i reaches 100%.

Yeah! Thanks


> Likewise, I would also like to update ja translation for
> installation-guide on weblate.
> I request for debian-installation-guide weblate to activate Japanese:
> https://hosted.weblate.org/projects/debian-installation-guide/#languages

Just activated.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Request for weblate usage in installation-guide Japanese translation (was Re: Request for weblate usage in d-i Japanese translation)

[YOSHINO Yoshihito]

Hi,

On Mon, Apr 26, 2021 at 2:11 PM Holger Wansing  wrote:
>
> Am 25. April 2021 10:12:13 MESZ schrieb Holger Wansing :
> >>https://hosted.weblate.org/projects/debian-installer/#languages
> >
> >That's great.
> >Thanks for taking care of that.
> >
> >I will activate Japanese on Weblate.
>
> Done.
>
> Holger

Thanks! Now ja translation for d-i reaches 100%.

Likewise, I would also like to update ja translation for
installation-guide on weblate.
I request for debian-installation-guide weblate to activate Japanese:
https://hosted.weblate.org/projects/debian-installation-guide/#languages

Thanks in advance,
-- 
YOSHINO Yoshihito 

Feature request: battery status / reminder to turn on

[Andrew Fenn]

Hi,

Can i make a feature request to include a reminder to plug in the charger
for notebooks when installing debian. This hit me in testing bullseye where
i had forgot and the notebook shutdown halfway through the install. I saw
that it knew it was running out of power and auto shutdown so I'm assuming
the ability to tell is available at install time.

Regards,
Andrew

Re: Request for weblate usage in d-i Japanese translation

[Kentaro Hayashi]

Hi,


Thank you for syncing!

Regards,



2021年4月30日(金) 3:27 Holger Wansing :

> Hi,
>
> Kentaro Hayashi  wrote (Thu, 29 Apr 2021 21:11:25
> +0900):
> > By the way, when weblate translation artifacts merged into d-i
> periodically?
> > Does l10n-sync require an extra configuration or something for Japanese?
>
> I sync Weblate regularly into d-i's git repo at Salsa.
> As I did now today:
>
> https://salsa.debian.org/installer-team/d-i/-/commit/ece9fddc8a7b4a6ff3f5ecaf17fee0c2a034c89a
>
> Nothing special needed.
>
>
> Holger
>
>
>
> --
> Holger Wansing 
> PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
>

Re: Request for weblate usage in d-i Japanese translation

[Holger Wansing]

Hi,

Kentaro Hayashi  wrote (Thu, 29 Apr 2021 21:11:25 +0900):
> By the way, when weblate translation artifacts merged into d-i periodically?
> Does l10n-sync require an extra configuration or something for Japanese?

I sync Weblate regularly into d-i's git repo at Salsa.
As I did now today:
https://salsa.debian.org/installer-team/d-i/-/commit/ece9fddc8a7b4a6ff3f5ecaf17fee0c2a034c89a

Nothing special needed.


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Request for weblate usage in d-i Japanese translation

[Kentaro Hayashi]

2021年4月26日(月) 14:27 Holger Wansing :
>
> Am 25. April 2021 10:12:13 MESZ schrieb Holger Wansing :
> >>https://hosted.weblate.org/projects/debian-installer/#languages
> >
> >That's great.
> >Thanks for taking care of that.
> >
> >I will activate Japanese on Weblate.
>
> Done.
>
> Holger

Thank you for setting it up.

By the way, when weblate translation artifacts merged into d-i periodically?
Does l10n-sync require an extra configuration or something for Japanese?


Regards,

Re: Request for weblate usage in d-i Japanese translation

[Holger Wansing]

Am 25. April 2021 10:12:13 MESZ schrieb Holger Wansing :
>>https://hosted.weblate.org/projects/debian-installer/#languages
>
>That's great.
>Thanks for taking care of that.
>
>I will activate Japanese on Weblate.

Done.

Holger


-- 
Sent from /e/ OS on Fairphone3

Re: Request for weblate usage in d-i Japanese translation

[Holger Wansing]

Am 25. April 2021 06:46:40 MESZ schrieb YOSHINO Yoshihito 
:
>Dear d-i l10n coordinator,
>
>I am trying to update ja translation for d-i, while the previous
>translator kmuto is no longer active. He used to commit all the ja
>translation things from himself and other translators.
>Instead I would like to use weblate for possible reviews.
>So I request for d-i weblate to enable Japanese:
>https://hosted.weblate.org/projects/debian-installer/#languages

That's great.
Thanks for taking care of that.

I will activate Japanese on Weblate.

Holger

Hi,
-- 
Sent from /e/ OS on Fairphone3

Request for weblate usage in d-i Japanese translation

[YOSHINO Yoshihito]

Dear d-i l10n coordinator,

I am trying to update ja translation for d-i, while the previous
translator kmuto is no longer active. He used to commit all the ja
translation things from himself and other translators.
Instead I would like to use weblate for possible reviews.
So I request for d-i weblate to enable Japanese:
https://hosted.weblate.org/projects/debian-installer/#languages

Thanks in advance,
-- 
YOSHINO Yoshihito 

Bug#985956: Merge request submittted to initramfs-tools

[Pete Batard]

I can try to submit a pull request for linux if needed, but I may need 
some guidance.


I'm going to drop trying to submit a pull request for the linux package 
for the time being, as I can't quite seem to manage to get the required 
process to insert CONFIG_MDIO_BCM_UNIMAC=m where it should appear.


Besides, I am not sure this is needed in the first place, since BMCGENET 
Kconfig should have MDIO_BCM_UNIMAC set by default 
(https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/broadcom/Kconfig#L78)


Thus, I'm going to leave people who are more familiar with Debian linux 
configuration with the action of ensuring that mdio-bcm-unimac.ko does 
get included in the install image.


Apologies for not being to being able to help further on this...

/Pete

Bug#985956: Merge request submittted to initramfs-tools

[Pete Batard]

On 2021.04.16 14:04, Ben Hutchings wrote:

On Thu, 2021-04-15 at 17:28 +0200, Samuel Thibault wrote:

Hello,

Pete Batard, le jeu. 15 avril 2021 16:11:02 +0100, a ecrit:

Quite a few people are negatively affected by this bug, and one can expect a
lot more to be if Debian 11 goes to release without the inclusion of
mdio-bcm-unimac.ko in the netinst ARM64 ISOs.

I have created an initramfs-tools merge request to attempt to fix the
problem, which can be found at:
https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/46


AIUI initramfs-tools rules are not used to build the nic-modules
udeb, it'd rather be happening in the linux package, in
debian/installer/modules/nic-modules, which indeed doesn't include
drivers/net/mdio/.

Linux maintainers, do you know more on this issue?


Yes that's correct.  This should be fixed in both initramfs-tools (for
normal system boot) and linux (for installation).


I can try to submit a pull request for linux if needed, but I may need 
some guidance.


My take is that we want to add and explicit:

  CONFIG_MDIO_BCM_UNIMAC=m

to debian/config/arm64/config and add a:

  drivers/net/mdio/*

line to debian/installer/modules/nic-modules.

In other words, something like this patch:
https://salsa.debian.org/pbatard/linux/-/commit/855c728e4757bdcb4ceba054fc2b5b1da214b8ab

Does this approach look correct? Or do we need something different?

Regards,

/Pete

Bug#985956: Merge request submittted to initramfs-tools

[Ben Hutchings]

On Thu, 2021-04-15 at 17:28 +0200, Samuel Thibault wrote:
> Hello,
> 
> Pete Batard, le jeu. 15 avril 2021 16:11:02 +0100, a ecrit:
> > Quite a few people are negatively affected by this bug, and one can expect a
> > lot more to be if Debian 11 goes to release without the inclusion of
> > mdio-bcm-unimac.ko in the netinst ARM64 ISOs.
> > 
> > I have created an initramfs-tools merge request to attempt to fix the
> > problem, which can be found at:
> > https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/46
> 
> AIUI initramfs-tools rules are not used to build the nic-modules
> udeb, it'd rather be happening in the linux package, in
> debian/installer/modules/nic-modules, which indeed doesn't include
> drivers/net/mdio/.
> 
> Linux maintainers, do you know more on this issue?

Yes that's correct.  This should be fixed in both initramfs-tools (for
normal system boot) and linux (for installation).

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Bug#985956: Merge request submittted to initramfs-tools

[Samuel Thibault]

Hello,

Pete Batard, le jeu. 15 avril 2021 16:11:02 +0100, a ecrit:
> Quite a few people are negatively affected by this bug, and one can expect a
> lot more to be if Debian 11 goes to release without the inclusion of
> mdio-bcm-unimac.ko in the netinst ARM64 ISOs.
> 
> I have created an initramfs-tools merge request to attempt to fix the
> problem, which can be found at:
> https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/46

AIUI initramfs-tools rules are not used to build the nic-modules
udeb, it'd rather be happening in the linux package, in
debian/installer/modules/nic-modules, which indeed doesn't include
drivers/net/mdio/.

Linux maintainers, do you know more on this issue?

Samuel

Bug#985956: Merge request submittted to initramfs-tools

[Pete Batard]

Note that this is a rather critical regression (since it used to work 
fine with previous bullseye ISOs), that is currently preventing 
installation of Debian on the Raspberry Pi 4, i.e. by far the most 
widespread ARM64 platform out there.


Quite a few people are negatively affected by this bug, and one can 
expect a lot more to be if Debian 11 goes to release without the 
inclusion of mdio-bcm-unimac.ko in the netinst ARM64 ISOs.


I have created an initramfs-tools merge request to attempt to fix the 
problem, which can be found at:

https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/46

However, since I am not entirely familiar with how netinst ISO kernel 
modules are generated and picked, I can't vouch that the proposed fix, 
which consists of referencing the mdio/ subdirectory for inclusion, is 
the proper way to go...

Re: Merge request created [Re: Use isenkram to get around the firmware problem?]

[Cyril Brulebois]

Brian Potkin  (2021-03-09):
> On Mon 08 Mar 2021 at 22:41:53 +0100, Holger Wansing wrote:
> > At the bare minimum, I have created a merge request for my
> > "introduce a dialog to enter packages for firmware installation"
> > approach, so it is at least officially documented somewhere...

I have no opinions on this yet…

> It has been said before that installing packages with late_command is
> a trivial matter. So why an additional dialog to add to the
> installtion process?
> 
> https://lists.debian.org/debian-boot/2014/10/msg00320.html

… but that's really comparing apples and oranges.

Users may legitimately expect not to get a black screen after
installation (hence the need to improve over the amdgpu nightmare);
that's quite different from aversion towards systemd (in which case
“power users” can do whatever work is required to diverge from the
default).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Merge request created [Re: Use isenkram to get around the firmware problem?]

[Brian Potkin]

On Mon 08 Mar 2021 at 22:41:53 +0100, Holger Wansing wrote:

> Hi,
> 
> Holger Wansing  wrote (Sun, 7 Mar 2021 17:02:06 +0100):
> > And for the (graphics) firmware problem, isenkram is of no help as it 
> > seems, 
> > at least for Bullseye.
> 
> I have reached the end of my path on this issue.
> 
> isenkram is apparently no solution for Bullseye.
> 
> At the bare minimum, I have created a merge request for my "introduce a dialog
> to enter packages for firmware installation" approach, so it is at least 
> officially documented somewhere...

It has been said before that installing packages with late_command is
a trivial matter. So why an additional dialog to add to the installtion
process?

https://lists.debian.org/debian-boot/2014/10/msg00320.html

-- 
Brian.

Re: Merge request created [Re: Use isenkram to get around the firmware problem?]

[Cyril Brulebois]

Hallo Holger,

Holger Wansing  (2021-03-08):
> Holger Wansing  wrote (Sun, 7 Mar 2021 17:02:06 +0100):
> > And for the (graphics) firmware problem, isenkram is of no help as it 
> > seems, 
> > at least for Bullseye.
> 
> I have reached the end of my path on this issue.
> 
> isenkram is apparently no solution for Bullseye.

Nevertheless, I'd like to address you many thanks for having looked into
it! It's going to be a major time saver once I get back to d-i topics.

I might try and add some kludge specifically for amdgpu for bullseye,
and we might need to revisit the whole thing during the next release
cycle… Anyway, next window of opportunity for me is somewhen later this
month or maybe April.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Merge request created [Re: Use isenkram to get around the firmware problem?]

[Holger Wansing]

Hi,

Holger Wansing  wrote (Mon, 8 Mar 2021 22:41:53 +0100):
> At the bare minimum, I have created a merge request for my "introduce a dialog
> to enter packages for firmware installation" approach, so it is at least 
> officially documented somewhere...

Should have added a link. 
That's 
https://salsa.debian.org/installer-team/hw-detect/-/merge_requests/3


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Merge request created [Re: Use isenkram to get around the firmware problem?]

[Holger Wansing]

Hi,

Holger Wansing  wrote (Sun, 7 Mar 2021 17:02:06 +0100):
> And for the (graphics) firmware problem, isenkram is of no help as it seems, 
> at least for Bullseye.

I have reached the end of my path on this issue.

isenkram is apparently no solution for Bullseye.

At the bare minimum, I have created a merge request for my "introduce a dialog
to enter packages for firmware installation" approach, so it is at least 
officially documented somewhere...


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#946476: marked as done (debootstrap: Additional debootstrapable image (PureOS Amber) contributed as a merge request in salsa.)

[Debian Bug Tracking System]

Your message dated Thu, 27 Feb 2020 12:49:25 +
with message-id 
and subject line Bug#946476: fixed in debootstrap 1.0.119
has caused the Debian Bug report #946476,
regarding debootstrap: Additional debootstrapable image (PureOS Amber) 
contributed as a merge request in salsa.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
946476: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946476
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debootstrap
Version: 1.0.116
Severity: wishlist
Tags: patch

Dear Maintainer,

In PureOS, a Free Software Foundation approved Free Software distro
based on Debian, we use a number of Debian tools. Few are more
important than debootstrap since we use that to build images for our
laptops and phone. If we could add our system definition to
debootstrap in the scripts directory, which this merge request does;
https://salsa.debian.org/installer-team/debootstrap/merge_requests/37
we would be most grateful.

Thank you!

-- System Information:
Distributor ID: PureOS
Description:PureOS
Release:10.0
Codename:   byzantium
Architecture: x86_64

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debootstrap depends on:
ii  wget  1.20.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.16-2
ii  gnupg   2.2.17-3
ii  pureos-archive-keyring  2016.09

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: debootstrap
Source-Version: 1.0.119
Done: Hideki Yamane 

We believe that the bug you reported is fixed in the latest version of
debootstrap, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 946...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Hideki Yamane  (supplier of updated debootstrap package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 27 Feb 2020 21:16:24 +0900
Source: debootstrap
Architecture: source
Version: 1.0.119
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Hideki Yamane 
Closes: 946476 946783
Changes:
 debootstrap (1.0.119) unstable; urgency=medium
 .
   [ Hideki Yamane ]
   * Fix: specify --foreign and --unpack-tarball at the same time
 Thanks to Cel Skeggs  for the patch (Closes: #946783)
   * Add check rule for systemd-nspawn
 .
   [ Jeremiah C. Foster ]
   * Adding PureOS 'amber' to scripts dir (Closes: #946476)
Checksums-Sha1:
 9a13ee1ae54a113dc53f0dcb9da2aadb99b15e35 1919 debootstrap_1.0.119.dsc
 bfb3eaf5a1d739ecdd78cb506e540e75fdca9649 76738 debootstrap_1.0.119.tar.gz
 6a4d94c91e6a6429b58c29c47041360ca380cc57 5935 
debootstrap_1.0.119_amd64.buildinfo
Checksums-Sha256:
 9806c467aa5297f16a72121eff52f899a2861b9d617b56f056be2f7af83a3bc3 1919 
debootstrap_1.0.119.dsc
 e6bebac0ed001a1bb44aee7076871dacdd2ceb7210fd08e449d5b2526be1b3e0 76738 
debootstrap_1.0.119.tar.gz
 46463a20a992981670897d4edc9c2bfbdfd5284088c74039920c09d3513a7ce8 5935 
debootstrap_1.0.119_amd64.buildinfo
Files:
 df65e22903cee098f5e4cda3d05ffe60 1919 admin optional debootstrap_1.0.119.dsc
 d4ea6a2aae0dc4bdb156523d42653b7e 76738 admin optional 
debootstrap_1.0.119.tar.gz
 3231fb3e7c14c0b4a31e6a0eadf9a394 5935 admin optional 
debootstrap_1.0.119_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEWOEiL5aWyIWjzRBMXTKNCCqqsUAFAl5XtpIACgkQXTKNCCqq
sUAFFQ//bLXBHuht+gdIdtAY7ntDX40+nKwN2R1ocgwUCmAyERVKxKhCaqf1Qh1B
srTHZtSaSSCMsds8y9o8PDeVS9OKGR3ZELDVzJig/Q2HPdHIYEAMNW/Ov6biT5q/
bTO8rjpC49kCwseTKctOzbyxZlpMRseXGNtSyF8JQQa/zhhJoxeJ1ovtch8xlnT2
pzfLvnszafp5A1YiYZ6urVExu6ykjyd2mY4Bo8i81XsI0gYN8LmRIVoWNAw7x67P
iAEsCil7YNrOG8PQDU2YaLKXo+kXk/NTHvqF5uJ/mmk+VgUALmLTdkVUBhOiI3JA
SAVZd8fXxJ3gU3xG/jNr+TJKe+svFOsIY85NngLV0DwQtYY7ixgCUkoH2eVdz9n4
MCEMJe5lp1F38680x6jT7ThBfeSyKlPmj+mHt8tutjKxurqy5BXhJI99eSimVeNh

Bug#946476: debootstrap: Additional debootstrapable image (PureOS Amber) contributed as a merge request in salsa.

[Jeremiah C. Foster]

Package: debootstrap
Version: 1.0.116
Severity: wishlist
Tags: patch

Dear Maintainer,

In PureOS, a Free Software Foundation approved Free Software distro
based on Debian, we use a number of Debian tools. Few are more
important than debootstrap since we use that to build images for our
laptops and phone. If we could add our system definition to
debootstrap in the scripts directory, which this merge request does;
https://salsa.debian.org/installer-team/debootstrap/merge_requests/37
we would be most grateful.

Thank you!

-- System Information:
Distributor ID: PureOS
Description:PureOS
Release:10.0
Codename:   byzantium
Architecture: x86_64

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debootstrap depends on:
ii  wget  1.20.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.16-2
ii  gnupg   2.2.17-3
ii  pureos-archive-keyring  2016.09

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

-- no debconf information

Re: Request add hibmc_drm into buster aarch64 netboot image

[Ben Hutchings]

On Thu, 2019-11-07 at 13:39 +0800, She Kairui wrote:
> Hello，
> 
> I'm trying to install Debian buster on to the Huawei Kunpeng arm64 server,
> found that the installation graphic output not show up via the server BMC
> virtual console.
> 
> Because Huawei  Kunpeng arm64 server BMC chip is hibmc, the OS need
> hibmc_drm.ko to work with it, currently this kernel module is not included
> in the netboot initrd (
> http://ftp.debian.org/debian/dists/stable/main/installer-arm64/20190702+deb10u1/images/netboot/netboot.tar.gz)
> .

This module isn't even enabled in the kernel package for unstable yet!

> I have verified the BMC virtual console graphic output works well by adding
> hibmc_drm.ko into the netboot initrd.  Could you please help evaluating add
> the hibmc_drm udeb into the netboot initrd by default?
> Thanks

The selection of drivers to included in is mostly done through the
kernel package, not the installer packages.

Please open a bug against "src:linux" requesting that this driver is
built and included in the installer.  We'll fix it unstable first, and
can then possibly fix it in an update to buster.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.



signature.asc
Description: This is a digitally signed message part

Re: Request add hibmc_drm into buster aarch64 netboot image

[YunQiang Su]

She Kairui  于2019年11月7日周四 下午1:40写道：
>
> Hello，
>
> I'm trying to install Debian buster on to the Huawei Kunpeng arm64 server, 
> found that the installation graphic output not show up via the server BMC 
> virtual console.

Generally, BMC driver is used to view/modify configuration inside
normal OS, for example Linux distributions.
To view the virtual console via the embed web page, the BMC driver for
Linux is not used.

>
> Because Huawei  Kunpeng arm64 server BMC chip is hibmc, the OS need 
> hibmc_drm.ko to work with it, currently this kernel module is not included in 
> the netboot initrd 
> (http://ftp.debian.org/debian/dists/stable/main/installer-arm64/20190702+deb10u1/images/netboot/netboot.tar.gz)
>  .
>
> I have verified the BMC virtual console graphic output works well by adding 
> hibmc_drm.ko into the netboot initrd.  Could you please help evaluating add 
> the hibmc_drm udeb into the netboot initrd by default?

Is it misuage or an bad hardware design?

> Thanks
>
> --
> Kairui
>


-- 
YunQiang Su

Request add hibmc_drm into buster aarch64 netboot image

[She Kairui]

Hello，

I'm trying to install Debian buster on to the Huawei Kunpeng arm64 server,
found that the installation graphic output not show up via the server BMC
virtual console.

Because Huawei  Kunpeng arm64 server BMC chip is hibmc, the OS need
hibmc_drm.ko to work with it, currently this kernel module is not included
in the netboot initrd (
http://ftp.debian.org/debian/dists/stable/main/installer-arm64/20190702+deb10u1/images/netboot/netboot.tar.gz)
.

I have verified the BMC virtual console graphic output works well by adding
hibmc_drm.ko into the netboot initrd.  Could you please help evaluating add
the hibmc_drm udeb into the netboot initrd by default?
Thanks

--
Kairui

Bug#925182: Feature request: Support for QEMU Virtio driver for CD-ROM

[Witold Baryluk]

Package: debian-installer
Followup-For: Bug #925182

This looks to be a duplicate of #689528

Cheers.

Bug#928910: marked as done (feature request: support odroid-hc1)

[Debian Bug Tracking System]

Your message dated Sun, 12 May 2019 14:55:54 -0700
with message-id <87r293e3rp.fsf@yucca>
and subject line Re: Bug#928910: feature request: support odroid-hc1
has caused the Debian Bug report #928910,
regarding feature request: support odroid-hc1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
928910: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928910
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: flash-kernel
Version: 3.98

Would it be possible to support odroid-hc1 single board computers with
flash-kernel?

Here is how I configure the board manually:
https://wiki.debian.org/InstallingDebianOn/OdroidHC1

flash-kernel wouldn't need to deal with samsung firmware blobs, as those
get installed once and are never touched again.
To update u-boot on an sd-card it only needs to: dd iflag=dsync oflag=dsync
if=$uboot of=$device seek=63

Is any other info required for this?

Thanks, Andreas
--- End Message ---
--- Begin Message ---
Version: 0.97

On 2019-05-12, Andreas Jellinghaus wrote:
> Would it be possible to support odroid-hc1 single board computers with
> flash-kernel?

It should already supported since 0.97; see
/usr/share/flash-kernel/all.db:

  Machine: Hardkernel Odroid HC1
  Kernel-Flavors: armmp armmp-lpae
  DTB-Id: exynos5422-odroidhc1.dtb
  Boot-Script-Path: /boot/boot.scr
  U-Boot-Script-Name: bootscr.uboot-generic
  Required-Packages: u-boot-tools

If you install and run "flash-kernel" what is the output?

Do you have a boot.scr that flash-kernel is refusing to overwrite?

Are you using a vendor kernel which reports itself as a different model
string?

  $ cat /proc/device-tree/model ; echo

Which u-boot are you using? Are you using the default u-boot
environment, or did you use "saveenv" at some point?


live well,
  vagrant


signature.asc
Description: PGP signature
--- End Message ---

Bug#928910: feature request: support odroid-hc1

[Andreas Jellinghaus]

Package: flash-kernel
Version: 3.98

Would it be possible to support odroid-hc1 single board computers with
flash-kernel?

Here is how I configure the board manually:
https://wiki.debian.org/InstallingDebianOn/OdroidHC1

flash-kernel wouldn't need to deal with samsung firmware blobs, as those
get installed once and are never touched again.
To update u-boot on an sd-card it only needs to: dd iflag=dsync oflag=dsync
if=$uboot of=$device seek=63

Is any other info required for this?

Thanks, Andreas

Feature request: Support for QEMU Virtio driver for CD-ROM

[Brian Wengel]

Package: debian-installer

Version: debian-testing-amd64-DVD-1.iso, from 2019-03-16


When installing Debian as a guest in KVM/QEMU assigning the ISO to a CD-ROM
using Virtio or Virtio-SCSI as the bus type the debian-installer cannot see
the CD-ROM drive and ask for drivers.
I assume the Virtio drivers are not bundled/loaded in the installer. It
would be nice if it was :-)

In my benchmark of different bus types for CD-RO I got this read numbers:
-ata/ide: 541MB/s

-sata:  1,2GBs

-Virtio-SCSI:   3,6GB


Unfortunately I didn't test Virtio, but it should be at least just as fast
as the Virtio-SCSI
I've read from RHEL that Virtio is a little faster (at least for HDDs).

Re: [installation-guide] merge request on Italian translation

[Luca Monducci]

Hi Holger,

On 21/12/2018 17:41, Holger Wansing wrote:
> could you take a minute and look at
> https://salsa.debian.org/installer-team/installation-guide/merge_requests/3
> please?
> 
> Should we accept that change?

Slight rewording, merge request accepted.

Thanks
Luca

[installation-guide] merge request on Italian translation

[Holger Wansing]

Hi Luca,

could you take a minute and look at
https://salsa.debian.org/installer-team/installation-guide/merge_requests/3
please?


Should we accept that change?

Thanks
Holger



-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Access request to Salsa d-i and installation-guide repo

[Holger Wansing]

Hi,

Am Donnerstag, 20. Dezember 2018 schrieb Javier Fernández-Sanguino Peña:
> Dear colleagues,
> 
> Could some admin of the Salsa repo's add my user (jfs) to both the d-i and
> the installation-guide projects in Salsa?

Done.

Cheers
Holger 

-- 
Sent from my Jolla phone
http://www.jolla.com/

Access request to Salsa d-i and installation-guide repo

[Javier Fernández-Sanguino Peña]

Dear colleagues,

Could some admin of the Salsa repo's add my user (jfs) to both the d-i and
the installation-guide projects in Salsa?

I used to have access previously in Alioth but my user was not moved to the
new project. I did not needed the access before, but would need it in the
coming months to update the translation into Spanish.

Thanks!

Javier



signature.asc
Description: PGP signature

Re: Access request to Salsa for Debian Installer translations (Romanian)

[Andrei POPESCU]

On Mi, 21 nov 18, 12:32:51, Cyril Brulebois wrote:
> 
> Andrei added to the d-i group, thanks.

Many thanks,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Access request to Salsa for Debian Installer translations (Romanian)

[Cyril Brulebois]

Hi,

Holger Wansing  (2018-11-20):
> Andrei POPESCU  wrote:
> > Hello,
> > 
> > I just sent a join request on Salsa for installer-team. I would need
> > access to update the Romanian translation of d-i, assuming I will
> > have the time to work on it (been inactive the past 3 years or so).
> 
> Translation update for Romanian would be really great. Thanks (CC'ing
> kibi for group join request)

Andrei added to the d-i group, thanks.

And Holger, I've promoted you to owner, to let you deal with such
requests because I think I had little value here, only lag. And you're
the one dealing with translators anyway.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Access request to Salsa for Debian Installer translations (Romanian)

[Holger Levsen]

On Tue, Nov 20, 2018 at 09:44:50PM +0100, John Paul Adrian Glaubitz wrote:
> Isn’t it enough to just send pull requests with the translation updates?

it's maybe enough, but it's so much better and easier and joyful if
translaters can commit themselbes. Also it's pretty simple to review
these commits (and revoke commit rights *if* $whatever_bad. However, in
the >10 years where I've been involved in Debian Edu and where we handle
commit access very lightly (for translators and developers) I've never
experienced anything bad happening. And even if, git revoke is trivial.)

So why should we stop at "good enough" when we can do better?!! :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Access request to Salsa for Debian Installer translations (Romanian)

[Holger Wansing]

Hi,

John Paul Adrian Glaubitz  wrote:
> 
> 
> > On Nov 20, 2018, at 10:54 PM, Holger Wansing  wrote:
> > 
> > Hi,
> > 
> > John Paul Adrian Glaubitz  wrote:
> >> 
> >> 
> >>> On Nov 20, 2018, at 9:42 PM, Holger Wansing  wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> Andrei POPESCU  wrote:
> >>>> Hello,
> >>>> 
> >>>> I just sent a join request on Salsa for installer-team. I would need
> >>>> access to update the Romanian translation of d-i, assuming I will have
> >>>> the time to work on it (been inactive the past 3 years or so).
> >>> 
> >>> Translation update for Romanian would be really great. Thanks
> >>> (CC'ing kibi for group join request)
> >> 
> >> Isn’t it enough to just send pull requests with the translation updates?
> > 
> > I'm unsure what this means in real life:
> > translator requests to include their translation via salsa, and a team 
> > member
> > needs to accept them?
> 
> Yes, exactly this :-).

So, where is the benefit compared to the way, giving translators commit access
themself?

Of course, we limit access to the git repo, which can be considered as a pro.
But to achieve that, we need more manpower for doing the "accept pull requests"
jobs, that's the contra site.

Since manpower is always an issue on platforms like Debian, I would vote for
the "give translators commit access" way :-)


Holger




-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Access request to Salsa for Debian Installer translations (Romanian)

[John Paul Adrian Glaubitz]

> On Nov 20, 2018, at 10:54 PM, Holger Wansing  wrote:
> 
> Hi,
> 
> John Paul Adrian Glaubitz  wrote:
>> 
>> 
>>> On Nov 20, 2018, at 9:42 PM, Holger Wansing  wrote:
>>> 
>>> Hi,
>>> 
>>> Andrei POPESCU  wrote:
>>>> Hello,
>>>> 
>>>> I just sent a join request on Salsa for installer-team. I would need
>>>> access to update the Romanian translation of d-i, assuming I will have
>>>> the time to work on it (been inactive the past 3 years or so).
>>> 
>>> Translation update for Romanian would be really great. Thanks
>>> (CC'ing kibi for group join request)
>> 
>> Isn’t it enough to just send pull requests with the translation updates?
> 
> I'm unsure what this means in real life:
> translator requests to include their translation via salsa, and a team member
> needs to accept them?

Yes, exactly this :-).

Re: Access request to Salsa for Debian Installer translations (Romanian)

[Holger Wansing]

Hi,

John Paul Adrian Glaubitz  wrote:
> 
> 
> > On Nov 20, 2018, at 9:42 PM, Holger Wansing  wrote:
> > 
> > Hi,
> > 
> > Andrei POPESCU  wrote:
> >> Hello,
> >> 
> >> I just sent a join request on Salsa for installer-team. I would need
> >> access to update the Romanian translation of d-i, assuming I will have
> >> the time to work on it (been inactive the past 3 years or so).
> > 
> > Translation update for Romanian would be really great. Thanks
> > (CC'ing kibi for group join request)
> 
> Isn’t it enough to just send pull requests with the translation updates?

I'm unsure what this means in real life:
translator requests to include their translation via salsa, and a team member
needs to accept them?


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Access request to Salsa for Debian Installer translations (Romanian)

[John Paul Adrian Glaubitz]

> On Nov 20, 2018, at 9:42 PM, Holger Wansing  wrote:
> 
> Hi,
> 
> Andrei POPESCU  wrote:
>> Hello,
>> 
>> I just sent a join request on Salsa for installer-team. I would need
>> access to update the Romanian translation of d-i, assuming I will have
>> the time to work on it (been inactive the past 3 years or so).
> 
> Translation update for Romanian would be really great. Thanks
> (CC'ing kibi for group join request)

Isn’t it enough to just send pull requests with the translation updates?

Adrian

Re: Access request to Salsa for Debian Installer translations (Romanian)

[Holger Wansing]

Hi,

Andrei POPESCU  wrote:
> Hello,
> 
> I just sent a join request on Salsa for installer-team. I would need
> access to update the Romanian translation of d-i, assuming I will have
> the time to work on it (been inactive the past 3 years or so).

Translation update for Romanian would be really great. Thanks
(CC'ing kibi for group join request)


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Access request to Salsa for Debian Installer translations (Romanian)

[Andrei POPESCU]

Hello,

I just sent a join request on Salsa for installer-team. I would need
access to update the Romanian translation of d-i, assuming I will have
the time to work on it (been inactive the past 3 years or so).

Thanks,
Andrei


signature.asc
Description: PGP signature

Bug#899118: known good example request

[Vagrant Cascadian]

On 2018-05-20, Geert Stappers wrote:
> On Sun, May 20, 2018 at 09:15:38PM +0200, Karsten Merker wrote:
>> 
>> When looking at the defconfigs for several of these systems, I
>> see e.g. CONFIG_BOOTARGS settings that don't really match what I
>> would expect for systems using config_distro_bootcmd.h.
>> Three random examples:
>> 
>> - r8a77995_draak_defconfig:
>>   CONFIG_BOOTARGS="console=ttySC0,115200 rw root=/dev/nfs 
>> nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20"
>> 
>> - ls1088ardb_sdcard_qspi_defconfig:
>>   CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 
>> earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x300 
>> default_hugepagesz=2m hugepagesz=2m hugepages=256"
>> 
>> - hikey_defconfig:
>>   CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/mmcblk0p9 rw"
>> 
>
> Euh, an example of a "known good"   CONFIG_BOOTARGS

Unfortunately, it's much easier to identify "likely bad" CONFIG_BOOTARGS
than it is to identify "known good".

Anything that hard-codes root= is likely to interfere with booting from
an arbitrary root device, which is one of the things the distro_bootcmd
specification allows.


This is part of why I have uneasy feelings about globally enabling large
batches of boards, instead of selectively enabling individual boards
that have been tested and known to work with a particular flash-kernel +
u-boot + kernel configuration.


If you want to enable arbitrary boards without any testing, it would be
much simpler to do that programmatically, rather than maintaining all.db
in flash-kernel; parse all the .dtb files in the installed linux-image-*
packages, and compare against /proc/device-tree/model ... might not be
particularily fast... but certainly doable. Could use dpkg triggers or a
kernel postinst hook or something, and update the database on
installation of relevent packages.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#899118: known good example request

[Geert Stappers]

On Sun, May 20, 2018 at 09:15:38PM +0200, Karsten Merker wrote:
> 
> When looking at the defconfigs for several of these systems, I
> see e.g. CONFIG_BOOTARGS settings that don't really match what I
> would expect for systems using config_distro_bootcmd.h.
> Three random examples:
> 
> - r8a77995_draak_defconfig:
>   CONFIG_BOOTARGS="console=ttySC0,115200 rw root=/dev/nfs 
> nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20"
> 
> - ls1088ardb_sdcard_qspi_defconfig:
>   CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 
> earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x300 default_hugepagesz=2m 
> hugepagesz=2m hugepages=256"
> 
> - hikey_defconfig:
>   CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/mmcblk0p9 rw"
> 

Euh, an example of a "known good"   CONFIG_BOOTARGS

 

Groeten
Geert Stappers
-- 
Leven en laten leven

Re: block-udeb request for e2fsprogs?

[Roger Shimizu]

On Fri, Sep 1, 2017 at 12:21 AM, Theodore Ts'o <ty...@mit.edu> wrote:
> Hi,
>
> According to Britney there is a block-udeb request which will prevent
> e2fsprogs 1.43.6-1 from migrating to Testing when it has reached the
> appropriate amount of aging.  Was this left over from the Stretch
> release or is it SOP that the maintianer for packages in the Installer
> needs to request migration?  And if so, is this the right list to make
> such a request?

I guess D-I team is busy releasing buster alpha-1 images.
The block will be removed when the alpha-1 release finishes.

No need to request, just wait for a few days should be fine.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

block-udeb request for e2fsprogs?

[Theodore Ts'o]

Hi,

According to Britney there is a block-udeb request which will prevent
e2fsprogs 1.43.6-1 from migrating to Testing when it has reached the
appropriate amount of aging.  Was this left over from the Stretch
release or is it SOP that the maintianer for packages in the Installer
needs to request migration?  And if so, is this the right list to make
such a request?

Thanks,

- Ted

Re: Request to Join Project debian-installer from Christoph Biedl (cbiedl)

[Cyril Brulebois]

nore...@alioth.debian.org <nore...@alioth.debian.org> (2017-08-08):
> Christoph Biedl (cbiedl) has requested to join your project. 
> You can approve this request here: 
> https://alioth.debian.org/project/admin/users.php?group_id=30260 
> 
> Comments by the user:
> Seems like everybody is around here, so I might join the party as well.
> 
> Or something like that.

Welcome!


KiBi.


signature.asc
Description: Digital signature

Re: Request to Join Project debian-installer from Chris Boot (bootc)

[Cyril Brulebois]

nore...@alioth.debian.org <nore...@alioth.debian.org> (2017-08-07):
> Chris Boot (bootc) has requested to join your project. 
> You can approve this request here: 
> https://alioth.debian.org/project/admin/users.php?group_id=30260 
> 
> Comments by the user:
> Hi KiBi and the team, you may know me as the lunatic who wishes to take on 
> busybox... :-)

Welcome!


KiBi.


signature.asc
Description: Digital signature

Bug#860304: Patch request for U-Boot

[Heinrich Schuchardt]

I have posted a patch request to U-Boot upstream:
[U-Boot] [PATCH 1/1] odroid-c2: make fdtfile conform with README.pxe
https://lists.denx.de/pipermail/u-boot/2017-April/288581.html

Best regards

Heinrich Schuchardt

request for review of proposed changes

[Nicholas D Steeves]

Hi,

I've pushed minimal changes to the git branch "proposed" of
partman-btrfs.  Would someone please take a look at them and let me
know if they look good?  I'm sure I'm forgetting something...  That
said, the solution I'm proposing doesn't require translation ;-)

Kind regards,
Nicholas


signature.asc
Description: Digital signature

Ad request

[Lisa Kok]

Dear Admin, I'm Lisa Kok and I run Misshowtostartablog.com, a website which 
helps bloggers getting started with blogging. We would like to post a widget 
with the top 5 of this months' most popular articles of our website on your 
website, to promote our website. 
In exchange, you would receive a good monthly monetary compensation for this. 
 Would you be interested in this? 
 
 
With Regards, 
 Lisa Kok 
Marketingmanager 
Misshowtostartablog.com

Bug#751955: marked as done (initramfs-tools: Warning: error while trying to store keymap file - ignoring request to install /etc/boottime.kmap.gz)

[Debian Bug Tracking System]

Your message dated Thu, 03 Mar 2016 11:21:32 +
with message-id <e1abrk0-00028c...@franck.debian.org>
and subject line Bug#751955: fixed in console-setup 1.138
has caused the Debian Bug report #751955,
regarding initramfs-tools: Warning: error while trying to store keymap file - 
ignoring request to install /etc/boottime.kmap.gz
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
751955: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751955
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: initramfs-tools
Version: 0.115
Severity: normal
File: /usr/share/initramfs-tools/hooks/keymap

Hello,

Since one or two days, the keymap on my laptop is wrong at really early
boot when I need to input the password for my cryptsetup partion.

Today when running update-initramfs -u I saw the following message:

Warning: error while trying to store keymap file - ignoring request to install 
/etc/boottime.kmap.gz

Running "setupcon --save-keyboard" by hand here is indeed returning 1

According to the manpage, the --save-keyboard doesn't seems to exist at all

Cheers,

Laurent Bigonville

-- Package-specific info:
-- initramfs sizes
-rw-r--r--. 1 root root 18M Jun 18 10:32 /boot/initrd.img-3.14-1-amd64
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.14-1-amd64 root=/dev/mapper/soldur-root ro 
"acpi_osi=!Windows 2009" quiet selinux=1 security=selinux audit=1

-- resume
RESUME=/dev/mapper/soldur-swap_1
-- /proc/filesystems
btrfs
ext3
ext2
ext4
fuseblk
vfat

-- lsmod
Module  Size  Used by
cpuid  12663  0 
joydev 17063  0 
xt_CHECKSUM12471  1 
ipt_MASQUERADE 12594  3 
xt_tcpudp  12527  6 
ipt_REJECT 12465  4 
xt_conntrack   12681  3 
ebtable_nat12580  0 
ebtable_broute 12541  0 
bridge 97129  1 ebtable_broute
stp12437  1 bridge
llc12745  2 stp,bridge
ebtable_filter 12591  0 
ebtables   30026  3 ebtable_broute,ebtable_nat,ebtable_filter
ip6table_nat   12649  0 
nf_conntrack_ipv6  13605  1 
nf_defrag_ipv6 29262  1 nf_conntrack_ipv6
nf_nat_ipv612920  1 ip6table_nat
ip6table_mangle12540  0 
ip6table_security  12548  0 
ip6table_raw   12528  0 
ip6table_filter12540  0 
ip6_tables 26024  5 
ip6table_filter,ip6table_mangle,ip6table_security,ip6table_nat,ip6table_raw
iptable_nat12646  1 
nf_conntrack_ipv4  18455  4 
nf_defrag_ipv4 12483  1 nf_conntrack_ipv4
nf_nat_ipv412912  1 iptable_nat
nf_nat 18156  5 
ipt_MASQUERADE,nf_nat_ipv4,nf_nat_ipv6,ip6table_nat,iptable_nat
nf_conntrack   70938  9 
ipt_MASQUERADE,nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,ip6table_nat,iptable_nat,nf_conntrack_ipv4,nf_conntrack_ipv6
iptable_mangle 12536  1 
iptable_security   12544  1 
iptable_raw12524  1 
iptable_filter 12536  1 
ip_tables  21915  5 
iptable_security,iptable_filter,iptable_mangle,iptable_nat,iptable_raw
x_tables   23015  16 
iptable_security,ip6table_filter,ip6table_mangle,xt_CHECKSUM,ip_tables,xt_tcpudp,ipt_MASQUERADE,ip6table_security,xt_conntrack,iptable_filter,ip6table_raw,ebtables,ipt_REJECT,iptable_mangle,ip6_tables,iptable_raw
bnep   17388  2 
snd_hda_codec_hdmi 40955  4 
pci_stub   12429  1 
vboxpci18981  0 
vboxnetadp 25443  0 
binfmt_misc16949  1 
vboxnetflt 23324  0 
vboxdrv   261792  3 vboxnetadp,vboxnetflt,vboxpci
uinput 17372  1 
nfsd  254693  2 
auth_rpcgss51240  1 nfsd
oid_registry   12419  1 auth_rpcgss
nfs_acl12511  1 nfsd
nfs   183672  0 
lockd  79321  2 nfs,nfsd
fscache45542  1 nfs
sunrpc228923  6 nfs,nfsd,auth_rpcgss,lockd,nfs_acl
nls_utf8   12456  1 
x86_pkg_temp_thermal12951  0 
nls_cp437  16553  1 
intel_powerclamp   17159  0 
vfat   17135  1 
fat53794  1 vfat
tpm_rng12422  0 
rng_core   12688  2 tpm_rng
iTCO_wdt   12831  0 
iTCO_vendor_support12649  1 iTCO_wdt
loop   26605  0 
fuse   78839  3 
arc4   12536  2 
efi_pstore 12805  1 
uvcvideo   7

request

[Moreanu Robert - Nicolae]

i looking to resolve this problem when I want to install debian 8.2 or 8.1.
I receive this message after it's take to Grub install

" the 'grub-pc' package failed to install into /target/ "
after the operation of clean up on installing, i have a failed operations.

I don't have such expertise, please make the debian on install with more
information and what procedure to do that for the people don't have the
time to study the debian.

so.. how i could resolve this problem , any help from you, please

robert, waiting for your response

-- 

*o zi frumoasa !Robert - Nicolae  MOREANU*

Re: request

[Geert Stappers]

On Sun, Jan 17, 2016 at 03:06:14PM +0200, Moreanu Robert - Nicolae wrote:
> i looking to resolve this problem when I want to install debian 8.2 or 8.1.
> I receive this message after it's take to Grub install
> 
> " the 'grub-pc' package failed to install into /target/ "
> after the operation of clean up on installing, i have a failed operations.
> 
> I don't have such expertise, please make the debian on install with more
> information and what procedure to do that for the people don't have the
> time to study the debian.
> 
> so.. how i could resolve this problem , any help from you, please
> 
> robert, waiting for your response

The mailinglist you are addressing is about development of debian-installer,
not for user requests.


Regards
Geert Stappers
-- 
Ignoring is really harsh

Re: request

[Hendrik Boom]

On Sun, Jan 17, 2016 at 02:54:29PM +0100, Geert Stappers wrote:
> On Sun, Jan 17, 2016 at 03:06:14PM +0200, Moreanu Robert - Nicolae wrote:
> > i looking to resolve this problem when I want to install debian 8.2 or 8.1.
> > I receive this message after it's take to Grub install
> > 
> > " the 'grub-pc' package failed to install into /target/ "
> > after the operation of clean up on installing, i have a failed operations.
> > 
> > I don't have such expertise, please make the debian on install with more
> > information and what procedure to do that for the people don't have the
> > time to study the debian.
> > 
> > so.. how i could resolve this problem , any help from you, please
> > 
> > robert, waiting for your response
> 
> The mailinglist you are addressing is about development of debian-installer,
> not for user requests.

But this is clearly a request for a change in the debian installer -- 
that it provide more information on one kind of failure.  Now it may be 
legitimate to say it's infeasible, and it may well be infeasible, but 
shuttong the user up without at least suggesting where he should go is, 
well, at least impolite.

Suggesting that he submit an installation-report and that he post his 
question on debian-user would be appropriate.

-- hendrik

> 
> 
> Regards
> Geert Stappers
> -- 
> Ignoring is really harsh
> 

Re: request

[Geert Stappers]

On Sun, Jan 17, 2016 at 05:09:29AM -0500, Hendrik Boom wrote:
> On Sun, Jan 17, 2016 at 02:54:29PM +0100, Geert Stappers wrote:
> > On Sun, Jan 17, 2016 at 03:06:14PM +0200, Moreanu Robert - Nicolae wrote:
> > > 
> > > robert, waiting for your response
> > 
> > The mailinglist you are addressing is about development of debian-installer,
> > not for user requests.
> 
> But this is clearly a request for a change in the debian installer -- 
> that it provide more information on one kind of failure.  Now it may be 
> legitimate to say it's infeasible, and it may well be infeasible, but 
> shuttong the user up without at least suggesting where he should go is, 
> well, at least impolite.

> > -- 
> > Ignoring is really harsh

> Suggesting that he submit an installation-report and that he post his 
> question on debian-user would be appropriate.

 https://www.debian.org/releases/jessie/amd64/ch05s04.html.en#problem-report


Regards
Geert Stappers
-- 
Ignoring is really harsh

Bug#751955: initramfs-tools: Warning: error while trying to store keymap file - ignoring request to install /etc/boottime.kmap.gz

[Lorenz Schori]

On Fri, 18 Sep 2015 15:56:52 +0200 Clement Hermann 
wrote:
> [...]
> Not sure why this wasn't setup by default even though the other
> variables where, though.
> [...]

In my case changing keyboard layout settings in Gnome resulted in the
XKBMODEL being deleted from /etc/default/keyboard.

Steps to reproduce:
1. $ gnome-control-center
2. Go to "Region & Language"
3. In the "Input Sources" section add some random keyboard layout
4. $ grep -q XKBMODEL /etc/default/keyboard && echo fine || echo broken
   -> broken
5. # dpkg-reconfigure keyboard-configuration
6. $ grep -q XKBMODEL /etc/default/keyboard && echo fine || echo broken
   -> fine

HTH


pgpxTw05zDpPF.pgp
Description: OpenPGP digital signature

Processed: re-request block

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 805792 by 771864
Bug #805792 [cdebootstrap] cdebootstrap: support for excluding dependencies
805792 was not blocked by any bugs.
805792 was not blocking any bugs.
Added blocking bug(s) of 805792: 771864
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
805792: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805792
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: Request to Join Project debian-installer from Vagrant Cascadian (vagrant)

[Christian PERRIER]

Quoting Cyril Brulebois (k...@debian.org):

  So if it makes sense for me to have commit access, great, if not, I'll
  keep submitting patches and bug reports.
 
 I don't think both approaches are exclusive. Feel free to push stuff
 you're comfortable with, and to file bug reports with patches for stuff
 you'd appreciate peer review for.

Just one more notice : there is a kind of autobuilduploader working
on d-i git. In short, packages with pending UNRELEASED changes are
usually uploaded with these changes during the days that follow the
commit.

To be clear, I have a daily script that monitors d-i packages and
notifies me when one has unreleased changes. Then, I build and upload
the said package. The rough idea behind all this is get things tested
ASAP rather than accumulate changes and only upload when a d-i release
is being prepared.

*I do not test nor review such changes*

In case someone does not want somthing to be immediately uploaded,
please send a notice to -boot, which I read on a regular basis.




signature.asc
Description: Digital signature

Re: Request to Join Project debian-installer from Vagrant Cascadian (vagrant) Welcome

[Geert Stappers]

On Thu, May 28, 2015 at 03:04:08AM +0200, Cyril Brulebois wrote:
 nore...@alioth.debian.org nore...@alioth.debian.org (2015-05-28):
  Vagrant Cascadian (vagrant) has requested to join your project. 
 
 Approved.

Nice!

Welcome Vagrant.

Yes, I know, you were allready with us.



Groeten
Geert Stappers
Who appreciates all contributors of d-i
-- 
Leven en laten leven


signature.asc
Description: Digital signature

Re: Request to Join Project debian-installer from Vagrant Cascadian (vagrant)

[Cyril Brulebois]

Heya,

(Taking the liberty of quoting your comments to the list.)

nore...@alioth.debian.org nore...@alioth.debian.org (2015-05-28):
 Vagrant Cascadian (vagrant) has requested to join your project. 

Approved.

 Comments by the user:
 
 I wonder if it wouldn't make sense for me to have commit access to
 flash-kernel and debian-installer to streamline u-boot integration on
 armhf platforms, rather than constantly pestering about bug reports...
 on the other hand, the peer review can be useful...
 
 I'm not sure I'm ready to commit to reading all the debian-boot
 traffic yet...
 
 So if it makes sense for me to have commit access, great, if not, I'll
 keep submitting patches and bug reports.

I don't think both approaches are exclusive. Feel free to push stuff
you're comfortable with, and to file bug reports with patches for stuff
you'd appreciate peer review for.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707

[Adam D. Barratt]

On 2015-04-17 18:22, Martin Pitt wrote:

Hello Niels,

Niels Thykier [2015-04-17 17:55 +0200]:
Just to clarify, are we still intending to do a systemd update prior 
to

Jessie with -17 and then now also a p-u (i.e. for 8.1) for ecryptfs?


That's still my intent, yes, primarily to avoid people who have this
set up in wheezy already (#751707 has at least two reporters) upgrade
and find their swap partition gone and boot stuck.


After some discussion on IRC, -17 has been migrated as part of the d-i 
RC4 prep.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/23db45b6ff07d65dc43d0ec938aeb...@mowgli.jungle.funky-badger.org

Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707

[Cyril Brulebois]

Martin Pitt mp...@debian.org (2015-04-17):
 I just tried the current rc2 installer (netinst image/graphical) and
 it does not actually ask me whether I want to encrypt my home
 direction. It seems you got this option?

I tried to follow the code path in Ubuntu, which offers this option, to
track down where the offset can come from; and see whether Debian was
affected. I didn't mean to imply that Debian proposes the same option,
as it does not.

 BTW, 215-16 still didn't hit testing, so I didn't upload -17 yet. I'll
 do as soon as it migrates.

systemd| 215-16 | testing 
systemd| 215-16 | unstable

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707

[Emilio Pozuelo Monfort]

On 17/04/15 13:51, Martin Pitt wrote:
 BTW, 215-16 still didn't hit testing, so I didn't upload -17 yet. I'll
 do as soon as it migrates.

systemd| 215-16 | testing  | source, amd64, arm64, armel,
armhf, i386, mips, mipsel, powerpc, ppc64el, s390x
systemd| 215-16 | unstable | source, amd64, arm64, armel,
armhf, i386, mips, mipsel, powerpc, ppc64el, s390x, sparc

Emilio


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5530fa98.3060...@debian.org

Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707

[Martin Pitt]

Martin Pitt [2015-04-16 14:53 -0500]:
 Hello Cyril,
 
 Cyril Brulebois [2015-04-16 19:40 +0200]:
  Anyway, asking for home encryption indeed leads to swap encryption,
  through a ecryptfs-setup-swap call, which in turn triggers:

I just tried the current rc2 installer (netinst image/graphical) and
it does not actually ask me whether I want to encrypt my home
direction. It seems you got this option? If the installer calls
ecryptfs-setup-swap, then IMHO we should also fix ecryptfs-utils by
the release. If the installer doesn't offer this, but people run
ecryptfs-setup-swap manually after installation, then a post-release
fix is fine of course.

But either way I'd rather like to see the systemd fix in the release
proper, as it breaks existing installations with that config.

BTW, 215-16 still didn't hit testing, so I didn't upload -17 yet. I'll
do as soon as it migrates.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707

[Martin Pitt]

Hello all,

Cyril Brulebois [2015-04-17 14:15 +0200]:
 I tried to follow the code path in Ubuntu, which offers this option, to
 track down where the offset can come from; and see whether Debian was
 affected. I didn't mean to imply that Debian proposes the same option,
 as it does not.

Ah ok, that explains the confusion. So let's fix ecryptfs in a
post-release update, I'll file a bug with the references and
explanations.

 systemd| 215-16 | testing 
 systemd| 215-16 | unstable

-17 uploaded with the originally attached patch. The only difference
is the s/UNRELEASED/unstable/ and the timestamp in the changelog.

Thanks, and sorry for the late timing again!

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707

[Martin Pitt]

Hello Niels,

Niels Thykier [2015-04-17 17:55 +0200]:
 Just to clarify, are we still intending to do a systemd update prior to
 Jessie with -17 and then now also a p-u (i.e. for 8.1) for ecryptfs?

That's still my intent, yes, primarily to avoid people who have this
set up in wheezy already (#751707 has at least two reporters) upgrade
and find their swap partition gone and boot stuck.

 If we are /not/ pulling systemd for Jessie release next release, we can
 document the issue for the release notes (possibly as a non-standard
 setup given d-i in Debian does not create this kind of disks, if I
 understand the discussion correctly).

That's possible as well, of course. In this case you should revert to
sysvinit (or upstart) straight after upgrading, *before* you reboot
(after it's too late).

I documented the manual upgrade fix on the LP bug a while ago:
https://launchpad.net/bugs/953875 (in the description). Maybe some
bits could also be stolen from there.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150417172230.gq3...@piware.de

Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707

[Niels Thykier]

On 2015-04-17 15:44, Martin Pitt wrote:
 Hello all,
 
 Cyril Brulebois [2015-04-17 14:15 +0200]:
 I tried to follow the code path in Ubuntu, which offers this option, to
 track down where the offset can come from; and see whether Debian was
 affected. I didn't mean to imply that Debian proposes the same option,
 as it does not.
 
 Ah ok, that explains the confusion. So let's fix ecryptfs in a
 post-release update, I'll file a bug with the references and
 explanations.
 
 systemd| 215-16 | testing 
 systemd| 215-16 | unstable
 
 -17 uploaded with the originally attached patch. The only difference
 is the s/UNRELEASED/unstable/ and the timestamp in the changelog.
 
 Thanks, and sorry for the late timing again!
 
 Martin
 

Hi,

Just to clarify, are we still intending to do a systemd update prior to
Jessie with -17 and then now also a p-u (i.e. for 8.1) for ecryptfs?

If we are /not/ pulling systemd for Jessie release next release, we can
document the issue for the release notes (possibly as a non-standard
setup given d-i in Debian does not create this kind of disks, if I
understand the discussion correctly).

Thanks,
~Niels


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55312cee.5000...@thykier.net

Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707

[Cyril Brulebois]

(Cc: debian-boot@ added.)

Martin Pitt mp...@debian.org (2015-04-16):
 Hello release team,

(With my d-i release manager hat.)

 yesterday I discovered that systemd breaks a common way of setting up
 plain cryptsetup partitions. Turns out that this has already been
 known for a while, but the impact wasn't appreciated enough:
 
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751707
 
 What happens is that systemd's cryptsetup integration ignores the
 offset= parameter in crypttab and instead uses the whole device. So
 if you had a swap or other partition underneath in order to identify
 the partition via UUID or label instead of an unreliable hardcoded
 device name, switching to systemd destroys the underlying metadata,
 and causes a boot hang as crypttab now refers to a nonexisting
 UUID/label. This is quite a common way to set up encrypted swap, the
 way that ecryptfs' own swap setup tool does it (the Ubuntu installer
 calls that if you select encrypt my home directory; I'm not sure
 whether Debian's installer does the same).

Grepping for hash= in partman-* d-i packages led to partman-crypto,
which seems responsible for this (no surprise here):
  
http://anonscm.debian.org/cgit/d-i/partman-crypto.git/tree/finish.d/crypto_config

There's no offset= there.

Looking into partman-* in Ubuntu vivid, it turns out that one of them
look at user-setup, and that's where the following is defined:
| Template: user-setup/encrypt-home
| Type: boolean
| Default: false
| # :sl2:
| _Description: Encrypt your home directory?
`---[ debian/user-setup-udeb.templates ]---

which is then used in user-setup-apply where there's a lot more
(encryption-related) code than in Debian, which e.g. calls adduser with
an option to encrypt home, which then calls some commands from the
ecryptfs-utils package, but I don't see any offset in the
ecryptfs-setup-private script.

Anyway, asking for home encryption indeed leads to swap encryption,
through a ecryptfs-setup-swap call, which in turn triggers:
|echo cryptswap$i UUID=$uuid /dev/urandom 
swap,offset=1024,cipher=aes-xts-plain64  /etc/crypttab
`---[ src/utils/ecryptfs-setup-swap ]---

The same file in the Debian package has no offset, so I guess that means
Debian is rather safe.

 IMHO this qualifies as data loss, and we cannot repair this
 automatically after the damage happened. So I'd really like to fix
 this in jessie, and I upgraded it to RC.
 
 The patch is quite straightforward. It got a first review by upstream,
 I made it a bit more defensive since the first version, and it'll
 probably land today. I attached my test script to the upstream bug [1]
 which allows you to play around with various offset= options and
 verify that it doesn't destroy the initial part of the partition.
 
 I realize this is a somewhat awkward timing as we want to deep-freeze
 in two days, and this means an udeb change (although only formally as
 there are no effective changes in udev). 215-16 should go into testing
 tonight, and I'm prepared to upload 215-17 with that fix right after
 that with urgency=high.
 
 What would you recommend how to proceed?

Provided a review by the release team, I'm OK with letting this go into
testing between D-I Jessie RC3 (to be released at the end of this week)
and a possible extra debian-installer upload (before the release).

I'm not exactly entirely sure how to deal with D-I for Jessie past RC3
anyway:
 - Do nothing?
 - BinNMU to make sure it's built against last-migrated components?
 - Sourceful upload in case there's any changes staged in git during the
   last week? (I hope that won't be necessary.)


Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707

[Martin Pitt]

Hello Cyril,

Cyril Brulebois [2015-04-16 19:40 +0200]:
 Anyway, asking for home encryption indeed leads to swap encryption,
 through a ecryptfs-setup-swap call, which in turn triggers:
 |echo cryptswap$i UUID=$uuid /dev/urandom 
 swap,offset=1024,cipher=aes-xts-plain64  /etc/crypttab
 `---[ src/utils/ecryptfs-setup-swap ]---
 
 The same file in the Debian package has no offset, so I guess that means
 Debian is rather safe.

Well, it actually means that it's even more broken :-( If you don't
specify an offset at all, then you can only boot this system once.
Then your partition will be overwritten with random data entirely, and
the next time you won't have any matching UUID any more, and you again
get a hanging boot (this affects sysvinit and upstart too). I. e. you
will have exactly the same effect.

So to properly fix this, we need:

 (1) the fix to add the offset=:
 https://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/840

 (Updating the used cipher would also be a good idea, but not
 essential)

 This fix alone is sufficient under sysvinit and upstart.

 (2) this systemd fix to actually respect offset= when booting under
 systemd.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707

[Cyril Brulebois]

Martin Pitt mp...@debian.org (2015-04-16):
 Hello Cyril,
 
 Cyril Brulebois [2015-04-16 19:40 +0200]:
  Anyway, asking for home encryption indeed leads to swap encryption,
  through a ecryptfs-setup-swap call, which in turn triggers:
  |echo cryptswap$i UUID=$uuid /dev/urandom 
  swap,offset=1024,cipher=aes-xts-plain64  /etc/crypttab
  `---[ src/utils/ecryptfs-setup-swap ]---
  
  The same file in the Debian package has no offset, so I guess that means
  Debian is rather safe.
 
 Well, it actually means that it's even more broken :-( If you don't
 specify an offset at all, then you can only boot this system once.
 Then your partition will be overwritten with random data entirely, and
 the next time you won't have any matching UUID any more, and you again
 get a hanging boot (this affects sysvinit and upstart too). I. e. you
 will have exactly the same effect.
 
 So to properly fix this, we need:
 
  (1) the fix to add the offset=:
  https://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/840
 
  (Updating the used cipher would also be a good idea, but not
  essential)
 
  This fix alone is sufficient under sysvinit and upstart.
 
  (2) this systemd fix to actually respect offset= when booting under
  systemd.

Huh? Last I checked, guided encrypted LVM just works…

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707

[Lennart Sorensen]

On Thu, Apr 16, 2015 at 10:05:17PM +0200, Cyril Brulebois wrote:
 Martin Pitt mp...@debian.org (2015-04-16):
  Hello Cyril,
  
  Cyril Brulebois [2015-04-16 19:40 +0200]:
   Anyway, asking for home encryption indeed leads to swap encryption,
   through a ecryptfs-setup-swap call, which in turn triggers:
   |echo cryptswap$i UUID=$uuid /dev/urandom 
   swap,offset=1024,cipher=aes-xts-plain64  /etc/crypttab
   `---[ src/utils/ecryptfs-setup-swap ]---
   
   The same file in the Debian package has no offset, so I guess that means
   Debian is rather safe.
  
  Well, it actually means that it's even more broken :-( If you don't
  specify an offset at all, then you can only boot this system once.
  Then your partition will be overwritten with random data entirely, and
  the next time you won't have any matching UUID any more, and you again
  get a hanging boot (this affects sysvinit and upstart too). I. e. you
  will have exactly the same effect.
  
  So to properly fix this, we need:
  
   (1) the fix to add the offset=:
   https://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/840
  
   (Updating the used cipher would also be a good idea, but not
   essential)
  
   This fix alone is sufficient under sysvinit and upstart.
  
   (2) this systemd fix to actually respect offset= when booting under
   systemd.
 
 Huh? Last I checked, guided encrypted LVM just works…

Worked for me about a month ago.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150416205818.gu29...@csclub.uwaterloo.ca

Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707

[Martin Pitt]

Cyril Brulebois [2015-04-16 22:05 +0200]:
 Huh? Last I checked, guided encrypted LVM just works…

Yes, that's fine -- this creates an encrypted PV which then contains
unencrypted root, swap, and home partitions. This error happens if you
don't encrypt the full disk (with cryptsetup/LUKS), but just encrypt
your home directory (with ecryptfs). The latter will create an
encrypted swap partition with a random key, otherwise you'd find part
of your /home data in your swap partition.

Martin

P. S.  Swap partitions, will you please just die. Most systems don't
need them any more, and those who do are better of with the
swapspace package or similar. But that's waay out of reach for
Jessie :-)

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

Feature Request

[nik]

Hello,

1st...

I thank you all for this installer, great work.

But I have a small feature request, regarding the crypto setup in the 
installer.


Although the installer offers many opportunities, but important details 
would be desirable (in terms of security) if you could add them.


- A choice of hash algorithms (SHA-512, RIPEMD160 ... etc., in order to 
always have the best possible choice)
- Arbitrary iterations (default: 1000, but more would increase the 
security dramatically)


thx in advance

Hallo,

als Erstes...

Ich danke allen für diesen Installer, großartige Arbeit.

Aber ich habe eine kleine Feature Anfrage, bezüglich des crypto setup 
im Installer.


Zwar bietet der Installer sehr viele Möglichkeiten, doch wichtige 
Details wären wünschenswert (hinsichtlich der Sicherheit), wenn man 
diese hinzufügen könnte.


- Eine Wahl der Hash Algorithmen (SHA-512, RIPEMD160 ... etc., um stets 
die bestmögliche Wahl zu haben)
- Frei wählbare Iterationen (Standard: 1000, jedoch mehr würde die 
sicherheit dramatisch steigern)


danke schonmal


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5483d458.2080...@googlemail.com

Bug#763072: How/Where to file a feature request

[Philippe Clérié]

On 09/27/2014 01:27 PM, Lisi Reisz wrote:

On Saturday 27 September 2014 17:57:06 Philippe Clérié wrote:

Thanks for the tips.

Bug filed as #763072.

--
Philippe

--
The trouble with common sense it that it is so uncommon.
Anonymous


I have looked at the bug report, and I would suggest that it may be
misphrased.  Keyboard selection is already in the installer.  I always choose
a standard UK keyboard and would struggle to install without it.  What is
missing apparently is the actual one you want.  Keyboard selection comes
after language selection.  Presumably (and I am guessing here) you choose US
English and are just given a US keyboard but the wrong one, rather than the
list of keyboards to select from that we British English choosers get.

Lisi




You know, you have forced me to re-evaluate what I thought I knew.

It appears that the Debian installer _does not_ have a Keymap variant 
selection dialog, even in expert mode. Even dpkg-reconfigure 
keyboard-configuration does not seem to do anything, while in Ubuntu you 
get to do some more customization of the keyboard.


I had always assumed that the Ubuntu installer was the same as Debian's 
but with some more options activated. When filing the bug I thought it 
would be a one liner kind of change. That may not be the case.


Your description of the process above is correct. After choosing the 
language (en) and the location (US), Debian presents the [Configure the 
keyboard] dialog, with the header Keymap to use:. The first selection 
in my case is American English, and below that keymaps, for just about 
every other country/language, including British English. What I would 
like is to be presented a choice of layouts after selecting that keymap.


Having said that, my original phrasing seems to reflect exactly what I 
am asking for, and none of my assumptions are apparent (I think?). But I 
am copying the bug report just in case.


--
Philippe

--
The trouble with common sense it that it is so uncommon.
Anonymous


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54298d7a.5000...@gcal.net

Bug#763072: How/Where to file a feature request

[Brian]

On Mon 29 Sep 2014 at 12:48:58 -0400, Philippe Clérié wrote:

 On 09/27/2014 01:27 PM, Lisi Reisz wrote:
 
 I have looked at the bug report, and I would suggest that it may be
 misphrased.  Keyboard selection is already in the installer.  I always choose
 a standard UK keyboard and would struggle to install without it.  What is
 missing apparently is the actual one you want.  Keyboard selection comes
 after language selection.  Presumably (and I am guessing here) you choose US
 English and are just given a US keyboard but the wrong one, rather than the
 list of keyboards to select from that we British English choosers get.
 
 Lisi
 
 
 
 You know, you have forced me to re-evaluate what I thought I knew.
 
 It appears that the Debian installer _does not_ have a Keymap
 variant selection dialog, even in expert mode. Even dpkg-reconfigure
 keyboard-configuration does not seem to do anything, while in Ubuntu
 you get to do some more customization of the keyboard.

You may want to evaluate keeping your report open in the light of reading
#698322:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698322


With 'dpkg-reconfigure keyboard-configuration' I see two international
keyboard layouts. Both are under Englis (US).


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/29092014191428.8d2b952b0...@desktop.copernicus.demon.co.uk

Re: Request for test of d-i beta1 announcement, please review and translate [was: Re: Debian Installer 7.0 Beta1 release]

[Cyril Brulebois]

Francesca Ciceri madame...@debian.org (08/08/2012):
 [cc-ing debian-boot: I totally forgot to do it in my first mail, sorry!]

[Please avoid M-F-T: yourlist, that breaks group-reply, which isn't nice
on such topics.]

 Thank you very much for the patch: I've just applied it.  I've also
 slightly reworded the final part (and the title as well) to stress
 more the request for help concept.  Thanks to you and Holger, now it
 seems quite good to me!
 
 New version available here:
 http://anonscm.debian.org/viewvc/publicity/announcements/en/2012/2012-08-09-dibeta1.wml?view=markup
 
 
 @debian-boot: as zack suggested we've drafted an announcement asking for
 help in testing the d-i beta release. I'd like to send it out tomorrow,
 can you please have a look at it, and give me your ack/nack?

It looks good to me. I'm lagging behind on recent -boot@ mails, but
there's at least a common issue to be added to errata: firmware loading.
Not sure it's been fully diagnosed yet.

But I guess the announcement can be sent as is. Thanks.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Request for test of d-i beta1 announcement, please review and translate [was: Re: Debian Installer 7.0 Beta1 release]

[Francesca Ciceri]

[cc-ing debian-boot: I totally forgot to do it in my first mail, sorry!]

On Wed, Aug 08, 2012 at 10:02:41AM +0300, Andrei POPESCU wrote:
 Hi,
 
 See attached a very intrusive patch.
 

Thank you very much for the patch: I've just applied it.
I've also slightly reworded the final part (and the title as well) to
stress more the request for help concept. 
Thanks to you and Holger, now it seems quite good to me!

New version available here:
http://anonscm.debian.org/viewvc/publicity/announcements/en/2012/2012-08-09-dibeta1.wml?view=markup


@debian-boot: as zack suggested we've drafted an announcement asking for
help in testing the d-i beta release. I'd like to send it out tomorrow,
can you please have a look at it, and give me your ack/nack?


Cheers,
Francesca

-- 
Nostra patria è il mondo intero
e nostra legge è la libertà
ed un pensiero
ribelle in cor ci sta. P.Gori


signature.asc
Description: Digital signature

Re: Freeze exception request: aptitude 0.6.9-1

[Cyril Brulebois]

Hello,

Daniel Hartwig mand...@gmail.com (02/07/2012):
 The main bugs concerning this are: 121313, 282408, 302784, 434502,
 576212, 590686, 639789.  A quick look at those bugs should indicate
 that aptitude's current behaviour has long been considered quite
 unusable.

thanks for your work on aptitude, it's been in need for love for a long
time.

 At the end of this command any requested package may or may not have
 been installed.  In particular, libc6 may have been installed but
 obviously some version other than the requested notaversion.  The
 only way to determine the state of packages after this is to inspect
 each, a rather tedious and error-prone operation.
 
 With 0.6.9 any requested package or version which is not found will
 cause the program to exit with non-zero status *before* making changes
 to the system.  The entire set of command-line arguments must
 constitute a unique, valid package system operation; if there is any
 ambiguity or error in the arguments the program will not proceed.  It
 is not considered sensible to allow a user to restore the old
 behaviour of ignoring non-existing packages/versions.

Grepping my d-i directory (contained many d-i related package checkouts)
I see:
packages/pkgsel/debian/postinst:in-target sh -c debconf-apt-progress 
--from 50 --to 100 --logstderr -- aptitude -q --without-recommends -y -o 
DPkg::options=--force-confnew '$upgrade_type' || aptfailed
packages/pkgsel/debian/postinst:in-target sh -c debconf-apt-progress 
--from 900 --to 950 --logstderr -- aptitude -q -y install -- $RET || aptfailed

I'm not sure if your changes could trigger regressions in there (e.g.
because a buggy command line was more or less working, except for a few
faulty packages).

 The net result is the program is a much better command-line citizen.
 If the exit status is 0 then it is reliable to assume that all
 requested actions have been completed [subject to interaction with
 --assume-yes and the problem resolver].

This is very much appealing, I must admit, even though I fear bad
regressions. Especially on the d-i side… Given we'd like to release beta
1 those days, letting aptitude 0.6.9-1 stay a while in unstable wouldn't
help get it tested through d-i beta 1, meaning postponing that to either
a beta 2 or rc 1. :( (which would still mean getting changes too late in
the release process)

 The new version is available on mentors.d.n, we will not upload
 however unless granted a freeze exception.

Having it uploaded to experimental would be an idea for the time being,
so that people can (in an opt-in fashion) test it.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Freeze exception request: aptitude 0.6.9-1

[Daniel Hartwig]

On 9 July 2012 07:45, Cyril Brulebois k...@debian.org wrote:
 The new version is available on mentors.d.n, we will not upload
 however unless granted a freeze exception.

 Having it uploaded to experimental would be an idea for the time being,
 so that people can (in an opt-in fashion) test it.

I have updated aptitude on mentors to target experimental with version
0.6.9-1~exp1.  To ease review, this is the only change at this point.

If a sponsor could take a look and please upload.

http://mentors.debian.net/package/aptitude

http://mentors.debian.net/debian/pool/main/a/aptitude/aptitude_0.6.9-1~exp1.dsc

Regards


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/can3verfn92ck9vdsyiopvev4hqykibphajjxmwy9keezxvr...@mail.gmail.com

Re: Freeze exception request: aptitude 0.6.9-1

[Daniel Hartwig]

On 9 July 2012 07:45, Cyril Brulebois k...@debian.org wrote:
 Grepping my d-i directory (contained many d-i related package checkouts)

Thanks for pointing this out, I had not identified d-i packages when
searching for Depends: aptitude.  I had assumed that d-i was using
apt-get and it's more predictable interface.

 I see:
 packages/pkgsel/debian/postinst:in-target sh -c debconf-apt-progress 
 --from 50 --to 100 --logstderr -- aptitude -q --without-recommends -y -o 
 DPkg::options=--force-confnew '$upgrade_type' || aptfailed
 packages/pkgsel/debian/postinst:in-target sh -c debconf-apt-progress 
 --from 900 --to 950 --logstderr -- aptitude -q -y install -- $RET || 
 aptfailed

 I'm not sure if your changes could trigger regressions in there (e.g.
 because a buggy command line was more or less working, except for a few
 faulty packages).

 The net result is the program is a much better command-line citizen.
 If the exit status is 0 then it is reliable to assume that all
 requested actions have been completed [subject to interaction with
 --assume-yes and the problem resolver].

 This is very much appealing, I must admit, even though I fear bad
 regressions. Especially on the d-i side…

Yes, the convenience of having most packages install even though a few
failed to download may have been very overlooked in the past.

I note that tasksel is invoked between the two runs of aptitude in
pkgsel.  With tasksel recently switching to apt-get it too will fail
just as (the proposed) aptitude when there are download or install
errors.  If we consider the new tasksel and aptitude as similar in
this case, then the only (?!) new problem is if virtual and/or
non-existent packages are listed in pkgsel/include; previously these
would be ignored, now this is an unavoidable error.

Are there other areas where d-i uses aptitude?

 Given we'd like to release beta
 1 those days, letting aptitude 0.6.9-1 stay a while in unstable wouldn't
 help get it tested through d-i beta 1, meaning postponing that to either
 a beta 2 or rc 1. :(

 (which would still mean getting changes too late in
 the release process)

If this remains the case (given my previous comments on tasksel) then
I will rather take a look at preparing an in-between version without
the CLI changes (except fix for #434502).

In any event, I have updated the version on mentors to target
experimental and asked sponsors for an upload.

http://mentors.debian.net/package/aptitude

Thanks for looking at my rather verbose request.

Regards


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAN3veRecs+CQT=w8h3lqg4ugtswfm7mojbrl_4cwd_otqk4...@mail.gmail.com

Bug#675438: task-galician: Request to change packages for galician environment

[Jorge Barreiro Gonzalez]

Package: task-galician
Version: 3.09
Severity: normal

The most up to date and accurate spell checking dictionary for the galician
language is the hunspell one, so I'd like the package hunspell-gl-es to be
added as a dependency. But maybe it fits better in the task-galician-desktop,
due to its dependencies...

Also, the package util-linux-locales contains some Galician translations, so
I think it should be added here too.

-- System Information:
Debian Release: 6.0.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.31-1-686 (SMP w/1 CPU core)
Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120601073833.5123.66560.report...@cobertoria.findomundo.net

Re: An Asian Request Deal .

[Wen Liang Xiong]

Hello,

Hello, how are you ?. My applogy I am contacting you through email; it is 
because it serves as the fastest and more convenient way to get to you. Am in 
search of a strong business relationship and partner for business project.

I got your email base on your name search from a list of complete directory 
database record.First, I need to seek your consent before I proceed.This 
project involves a huge specific amount I can't mention here for security 
reasons. It involves a transaction from my bank in Hong Kong, as a Chinese,we 
are bound by laws here.

If you feel you can have this handled or give a thought to this, kindly let me 
know, in order for me to send you an attached complete comprehensive details of 
this transaction.

Regards,
Wen Liang Xiong


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1s1hvo-0004jo...@server2.xinhongkong.com

Request to support KDE as first-class citizen in Debian and add GNOME3 as technical-preview

[Alexey Eromenko]

[second post]

Hello,

The debian-installer defaults to GNOME, which is a bit sad for KDE users alike.
Currently d-i supports KDE, but on the standard Debian DVD media
bootloader, it is buried quite deep.
I'd like to see KDE and GNOME supported on an equal footing in Debian.

openSUSE's Yast gives equal footing to top-tier desktop environments.
[ ]-KDE4
[ ]-GNOME


[ ]-Extra environments

One advantage is that both KDE and GNOME are supported on the same level.
Another advantage is that it allows to put 'technical preview' into
stable distro.

openSUSE 11.0 had a though choice - KDE3 (mature) or KDE 4.0 (which
was immature at the time)
So they added both options:
[ ]-KDE3
[ ]-KDE4[ ]-GNOME

Fedora 9 didn't had the KDE3 option, so many frustrated KDE users
moved to openSUSE during early KDE4 fiasco.

The same problem now happens with Debian Wheezy which will have to
decide for GNOME3 or GNOME2.
But with improved d-i it would be possible to include *both*, and call
GNOME3 'technical preview'.

Wheezy could look like:
[ ]-KDE
[ ]-GNOME2
[ ]-GNOME3 (technical preview)

[Extra environments] button

GNOME3 largely shares the problem of early KDE4 -- too big change to
swallow by many (GNOME2) users.
I understand this will toss packages on the DVDs, but still it looks
like a good idea.

Thanks in advance,
--
-Alexey Eromenko Technologov


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOJ6w=ELmFWtmDyyD_b77yd1RW_bQ2ZN=9vchkny8mjx4hy...@mail.gmail.com

Re: Request to support KDE as first-class citizen in Debian and add GNOME3 as technical-preview

[Cyril Brulebois]

Alexey Eromenko al4...@gmail.com (04/01/2012):
 [second post]

Bleh, don't do that.

 Wheezy could look like:
 [ ]-KDE
 [ ]-GNOME2
 [ ]-GNOME3 (technical preview)

Reality check: GNOME2 is gone. And GNOME3 is not a technical preview.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Request to support KDE as first-class citizen in Debian and add GNOME3 as technical-preview

[Alexey Eromenko]

Hello,

The debian-installer defaults to GNOME, which is a bit sad for KDE users alike.
Currently d-i supports KDE, but on the standard Debian DVD media
bootloader, it is buried quite deep.
I'd like to see KDE and GNOME supported on an equal footing in Debian.

openSUSE's Yast gives equal footing to top-tier desktop environments.
[ ]-KDE4
[ ]-GNOME


[ ]-Extra environments

One advantage is that both KDE and GNOME are supported on the same level.
Another advantage is that it allows to put 'technical preview' into
stable distro.

openSUSE 11.0 had a though choice - KDE3 (mature) or KDE 4.0 (which
was immature at the time)
So they added both options:
[ ]-KDE3
[ ]-KDE4[ ]-GNOME

Fedora 9 didn't had the KDE3 option, so many frustrated KDE users
moved to openSUSE during early KDE4 fiasco.

The same problem now happens with Debian Wheezy which will have to
decide for GNOME3 or GNOME2.
But with improved d-i it would be possible to include *both*, and call
GNOME3 'technical preview'.

Wheezy could look like:
[ ]-KDE
[ ]-GNOME2
[ ]-GNOME3 (technical preview)

[Extra environments] button

GNOME3 largely shares the problem of early KDE4 -- too big change to
swallow by many (GNOME2) users.
I understand this will toss packages on the DVDs, but still it looks
like a good idea.

Thanks in advance,--
-Alexey Eromenko Technologov


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOJ6w=hj+ac50pkutr_hqtthzrz5m5sgyosrcmdpfcedp1k...@mail.gmail.com

Bug#651413: Double slash in wget request

[Dmitri Medvedev]

Package: choose-mirror
Version: Unknown

While installing (using default graphical installator) Debian Squeeze 6.0.3
AMD64 (using debian-6.0.3-amd64-netinst.iso) on virtual machine running on
VirtualBox 4.1.6r74713 on my Windows 7 Pro working machine, I've experienced
an error in the installer while choosing a mirror: 'Bad archive mirror'. I
switched to the console 4 and noticed an error saying:

Dec 7 15:25:19 choose-mirror[30452]: DEBUG: command: wget -q
http://ftp.us.debian.org/debian//dists/squeeze/Release -O - | grep -E
'^(Suite|Codename):'
Dec 7 15:25:38 choose-mirror[30452]: WARNING **: mirror does not support the
specified release (squeeze)


Notice double slash in the wget URL before dists sub-directory. That happens
for any other country as well, I've tried US, Bulgarian, Estonian, some random
mirrors as well, and error appears everywhere.

BTW, Thanks a lot for the best distro!
---
WBR,
Dmitri




-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111208121220.m36...@mail.stv.ee

Bug#651413: Double slash in wget request

[Joey Hess]

Dmitri Medvedev wrote:
 While installing (using default graphical installator) Debian Squeeze 6.0.3
 AMD64 (using debian-6.0.3-amd64-netinst.iso) on virtual machine running on
 VirtualBox 4.1.6r74713 on my Windows 7 Pro working machine, I've experienced
 an error in the installer while choosing a mirror: 'Bad archive mirror'. I
 switched to the console 4 and noticed an error saying:
 
 Dec 7 15:25:19 choose-mirror[30452]: DEBUG: command: wget -q
 http://ftp.us.debian.org/debian//dists/squeeze/Release -O - | grep -E
 '^(Suite|Codename):'
 Dec 7 15:25:38 choose-mirror[30452]: WARNING **: mirror does not support the
 specified release (squeeze)

I see a doubled slash, but no indication it has anything to do with the
problem you experienced.

joey@wren:~ wget -q http://ftp.us.debian.org/debian//dists/squeeze/Release -O 
- | grep -E '^(Suite|Codename):'
Suite: stable
Codename: squeeze

Do you have a broken proxy, or something else that makes // not work?
Do you have any reason to think this was not just a transient network problem?

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#651413: Double slash in wget request

[Lennart Sorensen]

On Thu, Dec 08, 2011 at 03:14:45PM -0400, Joey Hess wrote:
 I see a doubled slash, but no indication it has anything to do with the
 problem you experienced.
 
 joey@wren:~ wget -q http://ftp.us.debian.org/debian//dists/squeeze/Release 
 -O - | grep -E '^(Suite|Codename):'
 Suite: stable
 Codename: squeeze
 
 Do you have a broken proxy, or something else that makes // not work?
 Do you have any reason to think this was not just a transient network problem?

I saw this recently too when a machine in fact did not have a working network 
link.

Too bad the error couldn't be Network connection failed rather than
invalid release on mirror.

I guess since grep is what gives a return code there isn't any easy to
way to know what wget thought of the request.

-- 
Len Sorensen



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20111208192646.ge9...@caffeine.csclub.uwaterloo.ca

Bug#651413: Double slash in wget request

[Joey Hess]

Lennart Sorensen wrote:
 On Thu, Dec 08, 2011 at 03:14:45PM -0400, Joey Hess wrote:
  I see a doubled slash, but no indication it has anything to do with the
  problem you experienced.
  
  joey@wren:~ wget -q http://ftp.us.debian.org/debian//dists/squeeze/Release 
  -O - | grep -E '^(Suite|Codename):'
  Suite: stable
  Codename: squeeze
  
  Do you have a broken proxy, or something else that makes // not work?
  Do you have any reason to think this was not just a transient network 
  problem?
 
 I saw this recently too when a machine in fact did not have a working network 
 link.
 
 Too bad the error couldn't be Network connection failed rather than
 invalid release on mirror.
 
 I guess since grep is what gives a return code there isn't any easy to
 way to know what wget thought of the request.

This could be fixed by running wget, checking its exit status, and
displaying a network error message, and only then parsing the Release file
(probably in C code) and displaying the current message.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#651413: Double slash in wget request

[Lennart Sorensen]

On Thu, Dec 08, 2011 at 04:06:07PM -0400, Joey Hess wrote:
 This could be fixed by running wget, checking its exit status, and
 displaying a network error message, and only then parsing the Release file
 (probably in C code) and displaying the current message.

That would certainly make it a lot less confusing.

I also keep hearing complaints about not having ping in the installer
for checking network connectivity when things aren't working. :)

But that would add a whole bunch of bytes to the installer size.

-- 
Len Sorensen



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20111208201244.gf9...@caffeine.csclub.uwaterloo.ca

Re: Bug#651413: Double slash in wget request

[Philipp Kern]

On Thu, Dec 08, 2011 at 03:12:44PM -0500, Lennart Sorensen wrote:
 I also keep hearing complaints about not having ping in the installer
 for checking network connectivity when things aren't working. :)
 But that would add a whole bunch of bytes to the installer size.

Yeah, count me in.  And no, wget is not a sane replacement to check if
there's connectivity.  On the other hand we added a bloated wpa
supplicant with crypto libs without any effort to get it trimmed (yet),
so those few bytes for ping shouldn't really matter IMO.[1]

Kind regards,
Philipp Kern

[1] And yeah, I'm aware that it all adds up.  Still, knowing that my
gateway is actually reachable and it's just HTTP that's broken,
is a massive help in a bunch of cases.
-- 
 .''`.  Philipp KernDebian Developer
: :' :  http://philkern.de Stable Release Manager
`. `'   xmpp:p...@0x539.de Wanna-Build Admin
  `-finger pkern/k...@db.debian.org


signature.asc
Description: Digital signature

Bug#571958: Request for development. Windows PC and Cross Platform Mobile Menu Library

[Miglen]

Dear Sir/Madam,


Can you help us with the following project?

Description

We are looking for the development of a data driven icon based menu
component that looks great and works seamlessly on PC, Windows Mobile,
iOS, Android and WebOS platforms.

The menu features we need are;
1) a main menu bar of icons on the horizontal axis (sensitive to device 
re-orientation)
2) a sub menu bar of icons on the vertical axis that is dynamic based on the 
context of the horizontal menu
3) menu bar options visible in display expand and contract to use all screen 
real estate available with menu's being scrollable if contracted on a small 
screen to allow access to all menu options
4) menu options expand/collapse within the menu bar to show/hide child options
5) lowest level menu items invoke functions that may be for example to act on a 
canvas that forms the rest of the screen, invoke pop up windows/forms, use 
feature of device such as camera or geo location, interact with another system 
or webservice

Non functionally the menu bar code must
1) Be able to run as a cached application on each device/platform
2) Load in under 3 seconds of first accessing the mobile application from a URL
3) Change orientation if the device changes orientation
4) Hide any browser frame so the appearance is of a native application
5) Work without the need to load plug ins or provide permissions to run
6) Have configurable style of background
7) Support float over text


-- 
Best regards,
 Miglen Angelova d...@armcode.com











-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2217835777.20110901153...@regmoney.com

Bug#633299: debian-installer: Feature request: please support tmpfs filesystems in partitioner

[Roger Leigh]

Package: debian-installer
Version: 20110106+squeeze3
Severity: normal

Hi,

This was briefly discussed on #debian-boot.  I'm writing this report
to record that.

The recent changes to support /run in wheezy/unstable have added
the following mounts:

tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=10%,mode=755 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5m 0 0
tmpfs /run/shm tmpfs rw,nosuid,nodev,relatime,size=20% 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,relatime,size=20% 0 0

Like the UTC=yes parameter the installer sets in /etc/default/rcS
to configure the hardware clock, these filesystems may be enabled
or disabled by setting

RAMLOCK=yes
RAMSHM=yes
RAMTMP=yes

in /etc/default/rcS.  Currently, the initscripts defaults these all to
yes.  However, it may make sense for the installer to give the user
the option of disabling them.  /run is always mounted (not
configurable).

Additionally, the mount options and size of the tmpfs may be
configured by adding an entry to /etc/fstab, such as shown above.
If not present, defaults from /lib/init/tmpfs.sh will be used instead
(the fstab settings supersede the defaults).

I was thinking of how this could be cleanly added into the installer,
and the best idea I've come up with so far is to add it directly into
the partitioner, so you don't need to provide any special support for
the feature (such as asking additional questions).  If support for the
tmpfs filesystem was added (similar to how LVM and RAID are
supported), one could add a tmpfs mount to the filesystem list, which
would then permit configuration of its size, mount options etc. using
the existing interface.  It could default to having entries for /run,
/run/lock, /run/shm and /tmp, and this would permit the user to modify
them or delete them entirely.  If deleted, you could then set
RAMxxx=no in /etc/default/tmpfs.  And if the options differ from the
default, you can then write an fstab entry for the mount.  The
interface would also permit the addition of new tmpfs mounts as well.
It would also be possible to only expose this in expert mode, if
desirable, so that normal installs wouldn't have increased
complexity, and the package defaults would simply be used instead.

We made the options in /etc/default/rcS and /etc/fstab configurable
in this way so that it fitted in with how the installer was already
configuring things, but equally this was already how the package
was set up (RAMLOCK was repurposed from /var/lock to /run/lock, and
fstab was already used to store options; RAMSHM and RAMTMP are
simply extending the existing conventions in use).


Regards,
Roger



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110709111018.20468.21255.report...@ravenclaw.codelibre.net