Bug#1069681: less does not escape special characters when outputting the filename

[Milan Kupcevic]

Hi Salvatore,

On 5/2/24 10:45, Salvatore Bonaccorso wrote:
[...]


I did ponder about it and trying to add this fix as well for the
upcoming less DSA, but it won't go apply for the older releases and
the issue is compared minor enough.

I think I will go ahead with the two CVE fixes only.

Take a look at the attached patch. It applies and fixes the bookworm and 
bullseye versions. It seems the buster version is not vulnerable to this 
particular issue.



MilanDate:   Tue Apr 23 10:54:50 2024 -0700
Author: Mark Nudelman 
Author: Milan Kupcevic 
Origin: upstream, https://github.com/gwsw/less/commit/2a642a07d86f7f9484db18cd748bc521e71c997f
Bug-Debian: https://bugs.debian.org/1069681
Applied-Upstream: 654
Subject: Fix incorrect display when filename contains control chars.

---
 output.c | 12 ++--
 prompt.c | 17 -
 2 files changed, 22 insertions(+), 7 deletions(-)

--- a/output.c
+++ b/output.c
@@ -31,6 +31,7 @@
 extern int screen_trashed;
 extern int is_tty;
 extern int oldbot;
+extern int utf_mode;
 
 #if MSDOS_COMPILER==WIN32C || MSDOS_COMPILER==BORLANDC || MSDOS_COMPILER==DJGPPC
 extern int ctldisp;
@@ -562,6 +563,7 @@
 	PARG *parg;
 {
 	char *s;
+	char *es;
 	int col;
 
 	col = 0;
@@ -578,11 +580,17 @@
 			{
 			case 's':
 s = parg->p_string;
+es = s + strlen(s);
 parg++;
 while (*s != '\0')
 {
-	putchr(*s++);
-	col++;
+	LWCHAR ch = step_char(, +1, es);
+	constant char *ps = utf_mode ? prutfchar(ch) : prchar(ch);
+	while (*ps != '\0')
+	{
+		putchr(*ps++);
+		col++;
+	}
 }
 break;
 			case 'd':
--- a/prompt.c
+++ b/prompt.c
@@ -29,6 +29,7 @@
 extern int sc_height;
 extern int jump_sline;
 extern int less_is_more;
+extern int utf_mode;
 extern IFILE curr_ifile;
 #if EDITOR
 extern char *editor;
@@ -83,13 +84,17 @@
 ap_str(s)
 	char *s;
 {
-	int len;
-
-	len = (int) strlen(s);
-	if (mp + len >= message + PROMPT_SIZE)
-		len = (int) (message + PROMPT_SIZE - mp - 1);
-	strncpy(mp, s, len);
-	mp += len;
+	char *es = s + strlen(s);
+	while (*s != '\0')
+	{
+	LWCHAR ch = step_char(, +1, es);
+	constant char *ps = utf_mode ? prutfchar(ch) : prchar(ch);
+	size_t plen = strlen(ps);
+	if (mp + plen >= message + PROMPT_SIZE)
+	break;
+	strcpy(mp, ps);
+	mp += plen;
+	}
 	*mp = '\0';
 }
 

Bug#1063501: building curl from source fails the island test

[Milan Kupcevic]

On 4/20/24 15:59, Johannes Schauer Marin Rodrigues wrote:

Quoting Milan Kupcevic (2024-04-20 21:46:14)

On 4/20/24 15:05, Johannes Schauer Marin Rodrigues wrote: [...]

Quoting Milan Kupcevic (2024-04-20 20:50:27)

This package builds just fine either on or off an island. The "pre-built
artifacts" is actually the build support provided by the upstream for their
official release package. It is nice to rebuild the build support, but is not
required nor always desired.


what is your reasoning to not rebuild them and to instead use the pre-built
artifacts from the release package?

Would anything break?



Stunt lines injected in the building scripts would be very undesirable.


How about using the upstream git instead of the release tarball as the base for
the packaging?




I would rather stick with the official release tarballs as they get 
signed with the upstream developer's key.


Milan

Bug#1064293: Bug#1068938: less: diff for NMU version 590-2.1

[Milan Kupcevic]

On 4/19/24 11:31, Salvatore Bonaccorso wrote:

Control: tags 1064293 + patch
Control: tags 1064293 + pending
Control: tags 1068938 + patch
Control: tags 1068938 + pending


Dear maintainer,

I've prepared an NMU for less (versioned as 590-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

As well pushed in a separte branch on salsa, which can be merged if
accepted to unstable:

https://salsa.debian.org/debian/less/-/tree/sid-2024-security-fixes?ref_type=heads

Regards.
Salvatore



ACK.

Thank you Salvatore; much appreciated.

Milan

Bug#1063501: building curl from source fails the island test

[Milan Kupcevic]

Hi Josch,

On 4/20/24 15:05, Johannes Schauer Marin Rodrigues wrote:
[...]

Quoting Milan Kupcevic (2024-04-20 20:50:27)

This package builds just fine either on or off an island. The "pre-built
artifacts" is actually the build support provided by the upstream for their
official release package. It is nice to rebuild the build support, but is not
required nor always desired.


what is your reasoning to not rebuild them and to instead use the pre-built
artifacts from the release package?

Would anything break?




Stunt lines injected in the building scripts would be very undesirable.

Milan

Bug#1063501: building curl from source fails the island test

[Milan Kupcevic]

Hi Josch,

This package builds just fine either on or off an island. The "pre-built 
artifacts" is actually the build support provided by the upstream for 
their official release package. It is nice to rebuild the build support, 
but is not required nor always desired.


Milan


On 2/8/24 18:24, Johannes Schauer Marin Rodrigues wrote:

Source: less
Version: 590-2
Severity: serious
Tags: patch

Hi,

the current curl packaging uses pre-built artifacts from the upstream
tarball without regenerating them. Attempting to regenerate them by
running "make -f Makefile.aut" proceeds to call curl to download stuff
from ftp://ftp.unicode.org. To fix this, I added a build dependency on
unicode-data and symlinked the relevant files in the source tree to the
files shipped by the unicode-data package. While I was at it, my patch
also regenerates all the other files which were so far just copypasted
from the upstream tarball without verifying whether they can really be
built using Debian main. This is the patch:

diff -Nru less-590/debian/control less-590/debian/control
--- less-590/debian/control 2023-03-12 15:49:03.0 +0100
+++ less-590/debian/control 2024-02-08 23:12:54.0 +0100
@@ -4,7 +4,8 @@
  Maintainer: Milan Kupcevic 
  Build-Depends:
   debhelper (>= 12),
- libncurses-dev
+ libncurses-dev,
+ unicode-data
  Standards-Version: 4.6.2
  Vcs-Git: https://salsa.debian.org/debian/less.git
  Vcs-Browser: https://salsa.debian.org/debian/less
diff -Nru less-590/debian/rules less-590/debian/rules
--- less-590/debian/rules   2023-02-12 11:17:35.0 +0100
+++ less-590/debian/rules   2024-02-08 23:16:58.0 +0100
@@ -12,3 +12,20 @@
dh_auto_configure -- \
  --with-regex=gnu \
  --with-editor=/usr/bin/editor
+
+execute_before_dh_auto_build:
+   mkdir -p unicode
+   ln -s /usr/share/unicode/UnicodeData.txt unicode/UnicodeData.txt
+   ln -s /usr/share/unicode/EastAsianWidth.txt unicode/EastAsianWidth.txt
+   make -f Makefile.aut
+
+execute_before_dh_auto_clean:
+   set -e; for t in "" echo key; do mv "less$$t.nro" "less$$t.bak"; done
+   make -f Makefile.aut clean
+   rm -f *.nro *.man help.c funcs.h defines.h.in configure
+   rm -f unicode/UnicodeData.txt unicode/EastAsianWidth.txt
+   [ ! -d unicode ] || rmdir unicode
+   set -e; for t in "" echo key; do mv "less$$t.bak" "less$$t.nro"; touch 
"less$$t.nro.VER" "less$$t.nro"; done
+
+execute_before_dh_auto_install:
+   make -f Makefile.aut distfiles


The stunt with preserving the *.nro files is necessary because the upstream
tarball does not ship the *.nro.VER files which are then made into *.nro files
by replacing @@VERSION@@ and @@DATE@@ with their respective values. Technically
this is a case where the original source is missing from the Debian tarball but
this replacement is probably trivial enough to not be a DFSG violation.

The patch could be made much simpler if you were using a tarball from the
upstream git instead of the distribution tarball which is missing sources but
you probably have your reasons for doing it this way.

Thanks!

cheers, josch

Bug#1061136: RM: simulide [armel armhf riscv64 arm64 mips64el ppc64el s390x] -- ROM; ANAIS; upstream supporting amd64 and i386 only

[Milan Kupcevic]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:simulide

New release version is reducing supported architectures down to 
amd64 and i386 only.

Milan

Bug#979090: Legally problematic GPL-3+ readline dependency

[Milan Kupcevic]

On 1/27/23 12:04, Bastian Germann wrote:

Control: severity -1 serious
Control: retitle -1 avrdude: inaccurate copyright file

There are more problems:
The doc's GFDL license is not mentioned and seems to be the variant 
without NIV.

This is considered a non-free license by Debian. Please ask upstream for a
license change or drop the files from the source package.



Hi Bastian,

I was not able to identify any invariant sections in documentation. As 
far as I can see this document [0] is free and is eligible for Debian 
main in accordance with General Resolution 2006/001 [1]


Milan

[0] 
https://sources.debian.org/src/avrdude/6.3-20171130%252Bsvn1429-2/doc/avrdude.texi

[1] https://www.debian.org/vote/2006/vote_001

Bug#983719: esptool: Version 3.0 fixes critical bugs

[Milan Kupcevic]

Hi Faidon,

First of all thank you for your work on esptool update. I'm currently 
using my available time to work on avrdude for bookworm. If you wish to 
co-maintain esptool package feel free to add yourself to uploaders of 
this package.


I agree with your assessment. The best course at this point is to upload 
the updated package version together with the newly introduced 
dependencies to sid and let the system to auto-remove the old package 
from bookworm.


As soon as bookworm gets released we can make the updated esptool 
available via bookworm-backports.


Milan


On 2/21/23 07:16, Faidon Liambotis wrote:

Control: retitle -1 Package is severely outdated
Control: severity -1 serious

This package is severely outdated. esptool v2.8, as currently packaged
in Debian, was released in October 2019, almost 3.5 years ago. Upstream
has regularly released newer versions every few months in the meantime,
with the latest being v4.5, released last week.

Newer versions bring a myriad of fixes, as well as equally importantly,
support for newer chips that can be found in the wild.

As I've also reported in #948096, esptool in Debian is crippled right
now by not including any flasher stubs, limiting its usefulness. The
removal was justified at the time, but some of the underlying reasons
have been resolved for a long time now for several of the supported
chips, and only require simple patches to be applied to restore.

(Also note: the packaging and DFSG-ness can be simplified quite a bit,
since the binary blobs are now split into JSON files in the build tree,
that can be cleaned up with Files-Excluded, removing the need for
modifying the source through the uupdate script.)

Given how outdated the source is, and the lack of responses from the
maintainer in the BTS, I do not believe the package is fit for the next
release, therefore I'm elevating the severity to RC.

I should note that while the package seems to meet the criteria for
Salvaging (DevRef 5.12) I don't currently have the bandwidth to maintain
it properly in the long run either. I'm happy to do a one-off NMU to
bring it to a more decent shape, however.

Best,
Faidon

Bug#985095: RFP: python3-reedsolo -- reed solomon encoder/decoder

[Milan Kupcevic]

Package: wnpp
Severity: wishlist

* Package name: python3-reedsolo
  Version : 1.5.4
  Upstream Author : Tomer Filiba 
* URL : https://github.com/tomerfiliba/reedsolomon
* License : CC0
  Programming Lang: Python
  Description : reed solomon encoder/decoder

A pure-python universal errors-and-erasures Reed-Solomon Codec, based on
the wonderful tutorial at Wikiversity, written by "Bobmath" and "LRQ3000".

Bug#950519: : gzip: please default to -n

[Milan Kupcevic]

> Package: gzip
> Version: 1.9-3
> Severity: wishlist
> 
> Hi!
> I've run ran into an Y2038 problem when compressing a file with a timestamp
> after that date.  It's a yet another reason to drop including the timestamp
> into .gz files -- something that no other popular compressor does.
> 
> It makes the output unreproducible for the same input.  This results in
> having to manually add -n in thousands of places.
> 
> Then, it breaks logrotate:
> error: Compressing program wrote following message to stderr when compressing 
> log /var/log/exim4/mainlog.1:
> gzip: stdin: warning: file timestamp out of range for gzip format
> error: failed to compress log /var/log/exim4/mainlog.1
> error: Compressing program wrote following message to stderr when compressing 
> log /var/log/syslog.1:
> gzip: stdin: warning: file timestamp out of range for gzip format
> error: failed to compress log /var/log/syslog.1
> 
> We're working on Y2038 bugs all around the kernel, glibc, etc.  The time
> such a fix would be strictly required for gzip is 18 years from now... but
> why not flip the switch already?


Hi Adam,

Gzip can store a timestamp in the range from 1970-01-01 00:00:01 UTC
through 2106-02-07 06:28:15 UTC. If you are having trouble with
timestamps after 2038-01-19 03:14:07 UTC but not later than 2106-02-07
06:28:15 UTC, that is likely due to a limitation present at some other
place i.e. glibc, gcc, filesystem, kernel ...

Milan

Bug#983373: gzip-win32: Link gzip.exe with static libssp library

[Milan Kupcevic]

Package: gzip-win32
Version: 1.10-2
Severity: serious
Affects: win32-loader
Tags: d-i pending
Owner: Milan Kupcevic 
Submitter: Thomas Gaugler 


Merge request opened 6 months ago by Thomas Gaugler:

I noticed that gzip-win32 1.10-2 depends on the libssp-0.dll dynamic link 
library.
Therefore gzip.exe is no longer able to run standalone within win32-loader.exe.
wine also exhibits the issue:

$ wine gzip.exe
0009:err:module:import_dll Library libssp-0.dll (which is needed by 
L"Z:\\tmp\\gzip.exe") not found
0009:err:module:attach_dlls Importing dlls for L"Z:\\tmp\\gzip.exe" failed, 
status c135

The proposed patch links gzip.exe with the static libssp library.


From: Thomas Gaugler 
Date: Wed, 5 Aug 2020 20:32:39 +0200
Subject: [PATCH] Link gzip.exe with static libssp library

---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 2861a82..a82aacf 100755
--- a/debian/rules
+++ b/debian/rules
@@ -76,7 +76,7 @@ configure-indep-stamp: reconf-stamp
dh_testdir
mkdir -p builddir-indep
cd builddir-indep && ../configure --host=i686-w64-mingw32 \
-   LIBS="-Wl,--as-needed -lssp" --disable-silent-rules
+   LIBS="-l:libssp.a" --disable-silent-rules
:>$@
 
 build: build-stamp build-indep-stamp
-- 
2.20.1

Bug#976917: simavr: FTBFS on ppc64el: obj-powerpc64le-linux-gnu/avr_adc.d:5: *** missing separator. Stop.

[Milan Kupcevic]

tags 976917 unreproducible moreinfo
severity 976917 normal
thanks


On 12/9/20 3:41 AM, Lucas Nussbaum wrote:
[...]
> 
> During a rebuild of all packages in sid, your package failed to build
> on ppc64el. At the same time, it did not fail on amd64.
> 
> I'm marking this bug as severity:serious since your package currently has
> ppc64el binary packages in unstable (so this is a regression).
> 
[...]
>> obj-powerpc64le-linux-gnu/avr_adc.d:5: *** missing separator.  Stop.



Hi Lucas,

Your make reports a "missing separator" in line 5 of a dependency file
which was produced on your build machine by gcc -MMD while running gcc
10.2.1-1.

Given that I was not able to reproduce this bug in Debian testing with
gcc 10.2.1-1 nor in Debian sid with gcc 10.2.1-3 on two different
ppc64el machines, I'm downgrading severity of this bug to normal and
tagging it as unreproducible.

Please find attached build log and buildinfo files for comparison and
let me know if you are able to reproduce this bug in your environment.


Milan
 dpkg-buildpackage -us -uc -ui
dpkg-buildpackage: info: source package simavr
dpkg-buildpackage: info: source version 1.6+dfsg-3
dpkg-buildpackage: info: source distribution sid
dpkg-buildpackage: info: source changed by Milan Kupcevic 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture ppc64el
 fakeroot debian/rules clean
dh clean
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/home/milan/simavr-1.6+dfsg'
rm -f examples.tar
rm -f debian/examples/board_simduino/ATmegaBOOT_168_atmega328.ihex
dh_auto_clean
make -j16 clean
make[2]: Entering directory '/home/milan/simavr-1.6+dfsg'
make -C simavr clean
make[3]: Entering directory '/home/milan/simavr-1.6+dfsg/simavr'
rm -rf obj-powerpc64le-linux-gnu
rm -rf run_avr *.a *.so *.exe
rm -f sim_core_*.h
make[3]: Leaving directory '/home/milan/simavr-1.6+dfsg/simavr'
make -C tests clean
make[3]: Entering directory '/home/milan/simavr-1.6+dfsg/tests'
rm -rf obj-powerpc64le-linux-gnu
rm -f *.axf *.vcd
make[3]: Leaving directory '/home/milan/simavr-1.6+dfsg/tests'
make -C examples clean
make[3]: Entering directory '/home/milan/simavr-1.6+dfsg/examples'
for bi in board_ds1338 board_hd44780 board_i2ctest board_ledramp board_simduino 
board_ssd1306 board_timer_64led; do make -C $bi clean; done
make[4]: Entering directory '/home/milan/simavr-1.6+dfsg/examples/board_ds1338'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.hex *.a *.axf ds1338demo *.vcd .*.swo .*.swp .*.swm .*.swn
make[4]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples/board_ds1338'
make[4]: Entering directory '/home/milan/simavr-1.6+dfsg/examples/board_hd44780'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.hex *.a *.axf charlcd *.vcd .*.swo .*.swp .*.swm .*.swn
make[4]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples/board_hd44780'
make[4]: Entering directory '/home/milan/simavr-1.6+dfsg/examples/board_i2ctest'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.hex *.a *.axf i2ctest *.vcd .*.swo .*.swp .*.swm .*.swn
make[4]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples/board_i2ctest'
make[4]: Entering directory '/home/milan/simavr-1.6+dfsg/examples/board_ledramp'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.a *.axf ledramp *.vcd *.hex
make[4]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples/board_ledramp'
make[4]: Entering directory 
'/home/milan/simavr-1.6+dfsg/examples/board_simduino'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.a *.axf simduino *.vcd *.hex
make[4]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples/board_simduino'
make[4]: Entering directory '/home/milan/simavr-1.6+dfsg/examples/board_ssd1306'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.hex *.a *.axf ssd1306demo *.vcd .*.swo .*.swp .*.swm .*.swn
make[4]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples/board_ssd1306'
make[4]: Entering directory 
'/home/milan/simavr-1.6+dfsg/examples/board_timer_64led'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.a *.axf timer_64led *.vcd *.hex
make[4]: Leaving directory 
'/home/milan/simavr-1.6+dfsg/examples/board_timer_64led'
make[3]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples'
make -C examples/parts clean
make[3]: Entering directory '/home/milan/simavr-1.6+dfsg/examples/parts'
rm -rf obj-powerpc64le-linux-gnu
rm -rf *.hex *.a *.axf *.vcd .*.swo .*.swp .*.swm .*.swn *.so *.o
make[3]: Leaving directory '/home/milan/simavr-1.6+dfsg/examples/parts'
make -C doc clean
make[3]: Entering directory '/home/milan/simavr-1.6+dfsg/doc'
rm -f .tags*
rm -rf fresh/
make[3]: Leaving directory '/home/milan/simavr-1.6+dfsg/doc'
make[2]: Leaving directory '/home/milan/simavr-1.6+dfsg'
make[1]: Leaving directory '/home/milan/simavr-1.6+dfsg'
   dh_clean
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building simavr using existing ./simavr_1.6+dfsg.orig.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building simavr in

Bug#947969: ceph-mgr: indefinite queue growth causing commands to hang

[Milan Kupcevic]

On 2020-01-02 15:54, Bernd Zeimetz wrote:

> 
> any idea if this affects 14.2.4?
> 


Reports are pointing to 14.2.5, so far.

Also see https://tracker.ceph.com/issues/43317


Milan

Bug#947969: ceph-mgr: indefinite queue growth causing commands to hang

[Milan Kupcevic]

Package: ceph-mgr
Version: 14.2.5-1
Severity: serious
Tags: upstream
Forwarded: https://tracker.ceph.com/issues/43364

ceph-mgr queue on large clusters grows indefinitely pushing cpu utilization
to 100% and causing command execution to hang. For more info see:
  
  https://tracker.ceph.com/issues/43364


Milan

Bug#907123: ceph 14.2.4 in unstable

[Milan Kupcevic]

On 2019-12-27 16:14, Thomas Goirand wrote:
> On 12/26/19 1:49 AM, Bernd Zeimetz wrote:
>> Hi Milan,
>>
>> I gave you access to the salsa team as requested.


Sounds good.


>>
>> Please coordinate what you want to work on with Thomas (zigo@d.o) and me.
>>
>> Right now things like arch-all and various architectures do not build at
>> all.. I think we might even need to drop some as they just don't have
>> enough memory for whatever gcc/g++ is doing there.
>>
>> Bernd
> 
> Hi Bernd,
> 
> Thanks a lot for your work.
> 
> I'd be IMO fine if we drop armel, armhf and mipsel, for the server side
> of things. I don't see how one could reliable setup a cluster with this
> type of CPUs in production anyway.
> 


I've seen BeagleBone Black and Raspberry Pi mini cluster setups used in
classroom environment for educational purposes. We should provide them,
if possible.

As for failing builds on arm architectures it probably does not make
sense to push for ARM NEON on armel as it targets hardware with no float
acceleration. Debian's target on armel is --with-arch=armv5te
--with-float=soft.

On the other hand the armhf arch on Debian is specifically targeting
hardware with float acceleration. Default target is --with-arch=armv7-a
--with-fpu=vfpv3-d16 --with-float=hard. NEON is more likely to be
available on this one.

NEON is safely available on arm64, aarch64-linux-gnu

See https://en.wikipedia.org/wiki/ARM_architecture#Advanced_SIMD_(NEON)
for more info.


Milan



signature.asc
Description: OpenPGP digital signature

Bug#947457: critical bluestore data corruption

[Milan Kupcevic]

Package: ceph-osd
Version: 14.2.4-4
Severity: grave
Tags: upstream fixed-upstream

A critical bluestore data corruption bug[0][1] affecting OSDs configured with
separate db and/or wal devices has been introduced in 14.2.3 and is affecting
both 14.2.3 and 14.2.4 upstream releases[2]. This bug has been fixed in
upstream version 14.2.5. Fix is simple[4] and can be easily applied/backported
to Debian release 14.2.4.

[0] https://tracker.ceph.com/issues/42223
[1] https://github.com/ceph/ceph/pull/31621
[2] 
https://lists.ceph.io/hyperkitty/list/ceph-annou...@ceph.io/message/X6TNSDQK5DVKO6XFJW3DMJAJV63PLDYM/
[3] https://ceph.io/releases/v14-2-5-nautilus-released/
[4] https://github.com/ceph/ceph/commit/117c8b5ca0130e02be98848b6c323812e271af27

Bug#907123: ceph 14.2.4 in unstable

[Milan Kupcevic]

On 2019-12-24 08:40, Bernd Zeimetz wrote:
> Version: 14.2.4-1
> 
> Hi,
> 
> ceph 14.2.4 is in unstable.


This is a great news.


> Maintaining two different versions of ceph is absolutely a no-go. There
> are not even enough ressources to maintain one version as well as it
> should be.


I agree.


> 
> What will happen - after ceph migrated to testing - is a backport to buster.
> 


Excellent.


> If you want to help, please test hte packages and look into build issues.
> 


I will look into it.


Could you please push the uploaded version commits to the package salsa
repository?


Milan

Bug#942289: avrdude: Upstream commit 1415 breaks ft245r bitbang devices using DEFAULT_USB interface

[Milan Kupcevic]

On 10/13/19 8:16 PM, Stanley Pinchak wrote:
> 
> I recently upgraded avrdude from debian version 6.3-5.  After 
> upgrading I was unable to use my default programmer, arduino-ft232r 
> without setting a -P port parameter on the command line.  Upstream 
> patch 8580 modified ft245r.c to allow selection of a particular ftdi 
> device based on the serial number of the device. Unfortunately this 
> patch has broken the ability for avrdude to automatically select the 
> first ftdi port for ft245r devices, which include arduino-ft232r.
> 


This feature was introduced with upstream[0] svn commit 1415. Please
engage the upstream development project and explain the problem and
possible solutions. In the meantime I'm setting severity of this bug
report to wishlist and tagging it as an upstream issue.


Milan


[0] http://svn.savannah.gnu.org/viewvc/avrdude?view=revision=1415



signature.asc
Description: OpenPGP digital signature

Bug#941356: less: silently hides formatting characters

[Milan Kupcevic]

On 9/29/19 7:56 AM, Adam Borowski wrote:
> 
> [Severity set to important as this regression breaks scripts and most
> file formats, making the cause not even show up on "git diff" etc.]


I have not seen git developers being bothered by this change, so far.


> Hi, since v494 (released upstream in 2017 but not uploaded to Debian until a
> few days ago), control characters with the Unicode "category" property of Cf
> are ignored instead of being displayed as <1234> as before.


It seems this was a deliberate upstream change. Please engage the
upstream development project if you want to argue about their decision.
In the meantime I'm setting severity of this bug report to wishlist and
tagging it as an upstream issue.


Milan



signature.asc
Description: OpenPGP digital signature

Bug#935481: stretch-pu: package basez/1.6-3

[Milan Kupcevic]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi Stable Release Managers,

The basez version released in stretch is affected by bug #931041 and is 
consequently not properly decoding base64url stream. This bug has been 
fixed in sid, testing and buster-pu. I'm about to upload fixed 
basez/1.6-3+deb9u1 package for stretch. See attached debdiff.

Milan
diff -Nru basez-1.6/debian/changelog basez-1.6/debian/changelog
--- basez-1.6/debian/changelog  2016-10-27 09:33:37.0 -0400
+++ basez-1.6/debian/changelog  2019-08-22 22:07:39.0 -0400
@@ -1,3 +1,9 @@
+basez (1.6-3+deb9u1) stretch; urgency=medium
+
+  * Properly decode base64url encoded strings (closes: #931041)
+
+ -- Milan Kupcevic   Thu, 22 Aug 2019 22:07:39 -0400
+
 basez (1.6-3) unstable; urgency=medium
 
   * Remove configure getconf libs.
diff -Nru basez-1.6/debian/patches/base64url-decode-bug-931041 
basez-1.6/debian/patches/base64url-decode-bug-931041
--- basez-1.6/debian/patches/base64url-decode-bug-9310411969-12-31 
19:00:00.0 -0500
+++ basez-1.6/debian/patches/base64url-decode-bug-9310412019-08-03 
23:29:13.0 -0400
@@ -0,0 +1,16 @@
+Description: properly decode base64url encoded strings
+Author: Milan Kupcevic 
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931041
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/base64.c
 b/base64.c
+@@ -188,7 +188,7 @@
+   bout[0] = bout[0] | c[bin[1]] >> 4;
+   }
+ 
+-  switch(c64d[bin[2]])
++  switch(c[bin[2]])
+   {
+ case 0xfe:
+   if(bin[3] == '=')
diff -Nru basez-1.6/debian/patches/series basez-1.6/debian/patches/series
--- basez-1.6/debian/patches/series 1969-12-31 19:00:00.0 -0500
+++ basez-1.6/debian/patches/series 2019-08-03 22:15:31.0 -0400
@@ -0,0 +1 @@
+base64url-decode-bug-931041

Bug#934537: buster-pu: package basez/1.6-3+deb10u1

[Milan Kupcevic]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi Stable Release Managers,

The basez version released in buster is affected by bug #931041 and is 
consequently not properly decoding base64url stream. This bug has been 
fixed in sid and testing. I've prepared fixed basez/1.6-3+deb10u1 package 
for buster. See attached debdiff.

Milan
diff -Nru basez-1.6/debian/changelog basez-1.6/debian/changelog
--- basez-1.6/debian/changelog  2016-10-27 09:33:37.0 -0400
+++ basez-1.6/debian/changelog  2019-08-11 18:59:28.0 -0400
@@ -1,3 +1,9 @@
+basez (1.6-3+deb10u1) buster; urgency=medium
+
+  * Properly decode base64url encoded strings (closes: #931041)
+
+ -- Milan Kupcevic   Sun, 11 Aug 2019 18:59:28 -0400
+
 basez (1.6-3) unstable; urgency=medium
 
   * Remove configure getconf libs.
diff -Nru basez-1.6/debian/patches/base64url-decode-bug-931041 
basez-1.6/debian/patches/base64url-decode-bug-931041
--- basez-1.6/debian/patches/base64url-decode-bug-9310411969-12-31 
19:00:00.0 -0500
+++ basez-1.6/debian/patches/base64url-decode-bug-9310412019-08-03 
23:29:13.0 -0400
@@ -0,0 +1,16 @@
+Description: properly decode base64url encoded strings
+Author: Milan Kupcevic 
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931041
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/base64.c
 b/base64.c
+@@ -188,7 +188,7 @@
+   bout[0] = bout[0] | c[bin[1]] >> 4;
+   }
+ 
+-  switch(c64d[bin[2]])
++  switch(c[bin[2]])
+   {
+ case 0xfe:
+   if(bin[3] == '=')
diff -Nru basez-1.6/debian/patches/series basez-1.6/debian/patches/series
--- basez-1.6/debian/patches/series 1969-12-31 19:00:00.0 -0500
+++ basez-1.6/debian/patches/series 2019-08-03 22:15:31.0 -0400
@@ -0,0 +1 @@
+base64url-decode-bug-931041

Bug#781895: avrdude: writing fuse from file does not work

[Milan Kupcevic]

> Package: avrdude
> Version: 6.1-2
> Severity: normal
> 
> Before I noticed the "m" format to set fuses from immediate
> commandline values, I tried to set them (using an Arduino-as-ISP) from
> a binary file obtained by reading them (-U hfuse:r:hfuse.dump:b).
> Using "-U hfuse:w:hfuse.dump:b" just fails:
> 
> $ avrdude -p m32u4 -c stk500v1 -b 19200 -P 
> /dev/serial/by-id/usb-Arduino__www.arduino.cc__Arduino_Uno_6493534323335151A211-if00
>  -U hfuse:w:hfuse.dump:b


Please file a bug report at:

http://savannah.nongnu.org/bugs/?func=additem=avrdude

and work with the upstream on the issue.


Milan

Bug#909573: avrdude: Doesn't recognise ATtiny2313A

[Milan Kupcevic]

On 9/25/18 9:44 AM, Paul "LeoNerd" Evans wrote:
> Package: avrdude
> Version: 6.3-4+b1
> Severity: normal
> 
> The ATtiny2313A chip has the same programming details and signature as
> the ATtiny2313, but is not recognised by avrdude:
> 
>   $ avrdude -p attiny2313a ...
>   avrdude: AVR Part "attiny2313a" not found.
> 
> This can be easily remidied:
> 
>   part parent "t2313"
>   id   = "t2313a";
>   desc = "ATtiny2313A";
>   ;
> 
> This may not seem important, but I find it very useful that `avrdude -p`
> takes the same names for the chips as `avr-gcc -mmcu=`, and my Makefiles
> are built on this idea. It has worked up until the ATtiny2313A (whose
> libc header files I need to use as they contain some bugfixes and better
> names for registers, on an otherwise-identical chip).
> 
> Likewise while I'm here, the ATtiny84A has an identical problem,
> similarly fixed by
> 
>   part parent "t84"
>   id   = "t84a";
>   desc = "ATtiny84A";
>   ;
> 
> There are likely to be many more "A" variants that should be aliased
> like these.
> 



Please file a bug report at:

http://savannah.nongnu.org/bugs/?func=additem=avrdude

and work with the upstream on the issue.


Milan

Bug#907123: [Ceph-maintainers] Bug#907123: Ceph Mimic v13.2.x long term stable release series

[Milan Kupcevic]

On 09/03/2018 02:06 PM, Gaudenz Steinlin wrote:

[ ... ]

>>
>>
>> Please update ceph package to Mimic v13.2.x long term stable release
>> series.[0]
> 
> Thanks for your report. I'm aware of the new release. As an upgrade from
> Jewel to Mimic directly is not supported I would like to first get at
> least one usable version of Luminous into the Debian archive. This way
> we can point users at least to packages on snapshots.debian.org for the
> Upgrade from Stretch to Buster.
> 
> I'm currently working on this. The progress can be seen in the
> luminous/wip-gaudenz branch on salsa.debian.org.
> 
> The ceph maintainers team currently only consists of myself. I would be
> happy to have more people on the team. Are you interested?
> 


Hi Gaudenz,


I'm mostly interested in Mimic and am willing to work on packaging.

We would benefit greatly of having Ceph Luminous and Ceph Mimic in
Debian at the same time. This would simplify upgrade workflow and
potentially enable interested people to work on packaging of Mimic as
soon as possible.

Please let me know what is your position on this. Are you willing to
upload the Luminous as ceph12 and let me and potentially other
interested people to work on packaging of ceph13?


Milan



signature.asc
Description: OpenPGP digital signature

Bug#907123: Ceph Mimic v13.2.x long term stable release series

[Milan Kupcevic]

Package: ceph
Version: 10.2.5-7.2
Severity: normal


Please update ceph package to Mimic v13.2.x long term stable release series.[0]

Milan

[0] http://docs.ceph.com/docs/master/releases/mimic/

Bug#881075: upstream version 0.7.2

[Milan Kupcevic]

Package: dfu-programmer
Version: 0.6.1-1
Severity: normal

Upstream version 0.7.2 of the dfu-programmer has been available for some time
already[0]. Could we please have this package up to date?

Milan

[0] https://sourceforge.net/projects/dfu-programmer/files/dfu-programmer/

Bug#874315: ITP: simulide -- real time electronic circuit simulator

[Milan Kupcevic]

Package: wnpp
Severity: wishlist
Owner: Milan Kupcevic <mi...@debian.org>

* Package name: simulide
  Version : 0.1.5
  Upstream Author : Santiago González <santig...@gmail.com>
* URL : https://sourceforge.net/projects/simulide/
* License : GPL-3
  Programming Lang: C++
  Description : real time electronic circuit simulator

SimulIDE is a simple real time electronic circuit simulator.
It's intended for general purpose electronics and microcontroller
simulation, supporting PIC and AVR.
PIC simulation is provided by gpsim and AVR simulation by simavr.

Intended for hobbist or students to learn and experiment with simple
circuits.

https://sourceforge.net/p/simulide/svnrepo/HEAD/tree/branches/simulide_0.1.5-RC/

Bug#874316: ITP: simutron -- AVR simulator IDE

[Milan Kupcevic]

Package: wnpp
Severity: wishlist
Owner: Milan Kupcevic <mi...@debian.org>

* Package name: simutron
  Version : 1.0.1
  Upstream Author : Santiago González <santig...@gmail.com>
* URL : https://sourceforge.net/projects/simutron/
* License : GPL-3
  Programming Lang: C++
  Description : AVR simulator IDE

Simple environment to run and debug firmware for AVR 8-bit
microprocessors.
Able to run arduino firmware.
Internally this program uses the open source Simavr AVR Processor
Simulator (https://github.com/buserror/simavr ) and wraps all its
functions in a GUI shell. Setups for firmware debugging scenarios can be
created dynamically. Able to run 16MHz MCU with decent set of external
parts in real time.

https://sourceforge.net/p/simutron/code/HEAD/tree/branches/RB-1.0.1/

Bug#568156: ITP: simavr - a lean and mean AVR simulator

[Milan Kupcevic]

retitle 568156 ITP: simavr - a lean and mean AVR simulator
owner 568156 !
thanks


New upstream URL:

https://github.com/buserror/simavr

Bug#867822: pbuilder: pdebuild cannot build source-only packages

[Milan Kupcevic]

On Sun, 9 Jul 2017 19:48:41 +0100 James Clarke  wrote:

[...]

> 
> I have yet to hear a convincing argument in favour of supporting
> --debbuildopts -S, but that doesn't mean there isn't one, so I'm open
> to being convinced otherwise (and I'm sure Mattia is too).
> 

Because dpkg-buildpackage and debuild fully support the "-S" option.

Pdebuild used to do it fine, it fails now.


Milan



signature.asc
Description: OpenPGP digital signature

Bug#868925: avrdude: FTBFS: configure.ac:33: error: version mismatch. This is Automake 1.15.1,

[Milan Kupcevic]

https://anonscm.debian.org/cgit/collab-maint/avrdude.git/commit/?id=777cf870879c9d14190dcce0fdd458283e48d5c2

Bug#824815: Bootloader burning verification error

[Milan Kupcevic]

The attached patch reflects the mask change avrdude uses when reading
efuse and lock values. I'm getting ready to NMU arduino to fix this
issue for stretch.

Milan
Description: avrdude fuse read mask change
Author: Milan Kupcevic <mi...@debian.org>
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824815
Forwarded: not-needed
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/hardware/arduino/boards.txt
+++ b/hardware/arduino/boards.txt
@@ -8,11 +8,11 @@
 uno.upload.speed=115200
 uno.bootloader.low_fuses=0xff
 uno.bootloader.high_fuses=0xde
-uno.bootloader.extended_fuses=0x05
+uno.bootloader.extended_fuses=0xfd
 uno.bootloader.path=optiboot
 uno.bootloader.file=optiboot_atmega328.hex
-uno.bootloader.unlock_bits=0x3F
-uno.bootloader.lock_bits=0x0F
+uno.bootloader.unlock_bits=0xff
+uno.bootloader.lock_bits=0xcf
 uno.build.mcu=atmega328p
 uno.build.f_cpu=1600L
 uno.build.core=arduino
@@ -28,11 +28,11 @@
 
 atmega328.bootloader.low_fuses=0xFF
 atmega328.bootloader.high_fuses=0xDA
-atmega328.bootloader.extended_fuses=0x05
+atmega328.bootloader.extended_fuses=0xfd
 atmega328.bootloader.path=atmega
 atmega328.bootloader.file=ATmegaBOOT_168_atmega328.hex
-atmega328.bootloader.unlock_bits=0x3F
-atmega328.bootloader.lock_bits=0x0F
+atmega328.bootloader.unlock_bits=0xff
+atmega328.bootloader.lock_bits=0xcf
 
 atmega328.build.mcu=atmega328p
 atmega328.build.f_cpu=1600L
@@ -49,11 +49,11 @@
 
 diecimila.bootloader.low_fuses=0xff
 diecimila.bootloader.high_fuses=0xdd
-diecimila.bootloader.extended_fuses=0x00
+diecimila.bootloader.extended_fuses=0xf8
 diecimila.bootloader.path=atmega
 diecimila.bootloader.file=ATmegaBOOT_168_diecimila.hex
-diecimila.bootloader.unlock_bits=0x3F
-diecimila.bootloader.lock_bits=0x0F
+diecimila.bootloader.unlock_bits=0xff
+diecimila.bootloader.lock_bits=0xcf
 
 diecimila.build.mcu=atmega168
 diecimila.build.f_cpu=1600L
@@ -70,11 +70,11 @@
 
 nano328.bootloader.low_fuses=0xFF
 nano328.bootloader.high_fuses=0xDA
-nano328.bootloader.extended_fuses=0x05
+nano328.bootloader.extended_fuses=0xfd
 nano328.bootloader.path=atmega
 nano328.bootloader.file=ATmegaBOOT_168_atmega328.hex
-nano328.bootloader.unlock_bits=0x3F
-nano328.bootloader.lock_bits=0x0F
+nano328.bootloader.unlock_bits=0xff
+nano328.bootloader.lock_bits=0xcf
 
 nano328.build.mcu=atmega328p
 nano328.build.f_cpu=1600L
@@ -91,11 +91,11 @@
 
 nano.bootloader.low_fuses=0xff
 nano.bootloader.high_fuses=0xdd
-nano.bootloader.extended_fuses=0x00
+nano.bootloader.extended_fuses=0xf8
 nano.bootloader.path=atmega
 nano.bootloader.file=ATmegaBOOT_168_diecimila.hex
-nano.bootloader.unlock_bits=0x3F
-nano.bootloader.lock_bits=0x0F
+nano.bootloader.unlock_bits=0xff
+nano.bootloader.lock_bits=0xcf
 
 nano.build.mcu=atmega168
 nano.build.f_cpu=1600L
@@ -115,8 +115,8 @@
 mega2560.bootloader.extended_fuses=0xFD
 mega2560.bootloader.path=stk500v2
 mega2560.bootloader.file=stk500boot_v2_mega2560.hex
-mega2560.bootloader.unlock_bits=0x3F
-mega2560.bootloader.lock_bits=0x0F
+mega2560.bootloader.unlock_bits=0xff
+mega2560.bootloader.lock_bits=0xcf
 
 mega2560.build.mcu=atmega2560
 mega2560.build.f_cpu=1600L
@@ -136,8 +136,8 @@
 mega.bootloader.extended_fuses=0xF5
 mega.bootloader.path=atmega
 mega.bootloader.file=ATmegaBOOT_168_atmega1280.hex
-mega.bootloader.unlock_bits=0x3F
-mega.bootloader.lock_bits=0x0F
+mega.bootloader.unlock_bits=0xff
+mega.bootloader.lock_bits=0xcf
 
 mega.build.mcu=atmega1280
 mega.build.f_cpu=1600L
@@ -156,8 +156,8 @@
 leonardo.bootloader.extended_fuses=0xcb
 leonardo.bootloader.path=caterina
 leonardo.bootloader.file=Caterina-Leonardo.hex
-leonardo.bootloader.unlock_bits=0x3F
-leonardo.bootloader.lock_bits=0x2F
+leonardo.bootloader.unlock_bits=0xff
+leonardo.bootloader.lock_bits=0xef
 leonardo.build.mcu=atmega32u4
 leonardo.build.f_cpu=1600L
 leonardo.build.vid=0x2341
@@ -177,8 +177,8 @@
 esplora.bootloader.extended_fuses=0xcb
 esplora.bootloader.path=caterina
 esplora.bootloader.file=Caterina-Esplora.hex
-esplora.bootloader.unlock_bits=0x3F
-esplora.bootloader.lock_bits=0x2F
+esplora.bootloader.unlock_bits=0xff
+esplora.bootloader.lock_bits=0xef
 esplora.build.mcu=atmega32u4
 esplora.build.f_cpu=1600L
 esplora.build.vid=0x2341
@@ -198,8 +198,8 @@
 micro.bootloader.extended_fuses=0xcb
 micro.bootloader.path=caterina
 micro.bootloader.file=Caterina-Micro.hex
-micro.bootloader.unlock_bits=0x3F
-micro.bootloader.lock_bits=0x2F
+micro.bootloader.unlock_bits=0xff
+micro.bootloader.lock_bits=0xef
 micro.build.mcu=atmega32u4
 micro.build.f_cpu=1600L
 micro.build.vid=0x2341
@@ -217,11 +217,11 @@
 
 mini328.bootloader.low_fuses=0xff
 mini328.bootloader.high_fuses=0xd8
-mini328.bootloader.extended_fuses=0x05
+mini328.bootloader.extended_fuses=0xfd
 mini328.bootloader.path=optiboot
 mini328.bootloader.file=optiboot_atmega328-Mini.hex
-mini328.bootloader.unlock_bits=0x3F
-mini328.bootloader.lock_bits=0x0F
+mini328.bootloader.unlock_bits=0xff
+m

Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color

[Milan Kupcevic]

On Tue, 31 May 2016 11:54:54 +0100 Ben Hutchings 
wrote:
> On Tue, 2016-05-31 at 07:23 +0200, Geert Stappers wrote:

[...]

> > I don't know what PowerPC hardware is available these days.
> [...]
> 
> Looking at who's participating in OpenPOWER, I think it's mostly
> servers now. (There are still low-end PowerPC chips going into
> embedded systems, but I don't believe Debian has ever supported them.
> We require Open Firmware.) It looks like a lot of those are custom-
> made for large HPC and cloud customers, but Tyan has some that are
> generally available, like this:
> http://www.tyan.com/campaign/openpower/
> 
> There are some PowerPC systems available for remote use by developers:
> http://developers.openpowerfoundation.org/explore
> 


This Tyan development reference platform offer looks interesting.

And still, the most appealing option for an individual Free software
developer to put their hands on a fully functional big-endian machine is
to get a PowerPC Mac, YDL PowerStation or Pegasos II from ebay and
install Debian on it.

IBM Power machines are mostly out of reach to individuals, price-wise
and formal-customer-agreement-requirement-wise.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#825110: yaboot vs grub: metadata_csum and 64bit ext4

[Milan Kupcevic]

tags 825110 + pending
unblock 825110 by 610206
thanks

On 05/31/2016 04:35 AM, Mathieu Malaterre wrote:
> Here is the short explanation on why I played with the `pending` tag.
> ,
> Switching from yaboot to grub for d-i is a great news. However I
> feared two things, with the current applied patch for #825110 we are
> currently restricting users solely for yaboot user 

This patch just allows yaboot to read files, it does not restrict grub
in any way.

> (I did not understand why the switch was done only for 'powerpc' and 'ppc64' 
> was
> skipped).

Yaboot does not get installed on ppc64 nor on ppc64el.

> This would also need to be reverted once we fully move to grub only in d-i.

There is a lot of stuff to do to get to that point.


Milan



signature.asc
Description: OpenPGP digital signature

Bug#825110: /pci@f400000/ata-6@d/@0:3,/boot/vmlinux: Unknown or corrupt

[Milan Kupcevic]

On 05/30/2016 12:20 PM, Lennart Sorensen wrote:
> On Mon, May 30, 2016 at 12:17:19AM -0400, Milan Kupcevic wrote:
>> affects 825110 yaboot
>> tags 825110 pending
>> thanks
>>
>> Yaboot is not able to load files from a partition with metadata_csum and 
>> 64bit ext4 features enabled.
> 

[...]

> Of course if ext4 is being created by default in 64bit mode these days
> (I have no idea), then the installer may need to be taught to not do
> that for whatever filesystem /boot is going in.
> 

It seems ext4 is being created by default with 64bit and metadata_csum
features since stretch beta 6 d-i release. A separate /boot partition
formatted as ext3 would be a solution; as it was for some time before
yaboot got support for ext4.

Instead of doing separate /boot we might be better off to adjust
newworld partition recipe to accommodate grub installation while
disabling d-i 64bit and metadata_csum features on powerpc to allow for
installation of yaboot.[0] Once we transition to grub we can get rid of
yaboot-installer together with ext4 feature limitations. Mathieu is
volunteering to do some work in this regard.[1]

Milan

[0]
https://anonscm.debian.org/cgit/d-i/partman-ext3.git/commit/?id=f87dc92157262de1ad8dd3f2343436f08271b4dc
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610206#14







signature.asc
Description: OpenPGP digital signature

Bug#825110: /pci@f400000/ata-6@d/@0:3,/boot/vmlinux: Unknown or corrupt

[Milan Kupcevic]

affects 825110 yaboot
tags 825110 pending
thanks

Yaboot is not able to load files from a partition with metadata_csum and 64bit 
ext4 features enabled.

Milan

Bug#825470: ITP: basez -- base 16/32/64 encode/decode data to standard output

[Milan Kupcevic]

Package: wnpp
Severity: wishlist
Owner: Milan Kupcevic <mi...@debian.org>

* Package name: basez
  Version : 1.0.1
  Upstream Author : Milan Kupcevic <mi...@quarkline.net>
* URL : http://www.quarkline.net/basez/
* License : GPL
  Programming Lang: C
  Description : base 16/32/64 encode/decode data to standard output

BaseZ encodes/decodes base16, base32, base32hex, base64 or base64url data 
stream per RFC 4648; MIME base64 Content-Transfer-Encoding per RFC 2045; or 
PEM Printable Encoding per RFC 1421

Bug#824815: Bootloader burning verification error

[Milan Kupcevic]

Package: arduino
Version: 2:1.0.5+dfsg2-4
Severity: important
Control: tags -1 patch


Since avrdude version 6.2 efuse bitmask has been changed for ATmega168
and ATmega328, arduino has not been able to burn bootloaders to the
boards with the mentioned microcontrollers.

Please update arduino efuse values accordingly.

A patch with necessary updates is attached.

Milan
diff --git a/hardware/arduino/boards.txt b/hardware/arduino/boards.txt
index de9f4ef..0769116 100644
--- a/hardware/arduino/boards.txt
+++ b/hardware/arduino/boards.txt
@@ -8,7 +8,7 @@ uno.upload.maximum_size=32256
 uno.upload.speed=115200
 uno.bootloader.low_fuses=0xff
 uno.bootloader.high_fuses=0xde
-uno.bootloader.extended_fuses=0x05
+uno.bootloader.extended_fuses=0xfd
 uno.bootloader.path=optiboot
 uno.bootloader.file=optiboot_atmega328.hex
 uno.bootloader.unlock_bits=0x3F
@@ -28,7 +28,7 @@ atmega328.upload.speed=57600
 
 atmega328.bootloader.low_fuses=0xFF
 atmega328.bootloader.high_fuses=0xDA
-atmega328.bootloader.extended_fuses=0x05
+atmega328.bootloader.extended_fuses=0xfd
 atmega328.bootloader.path=atmega
 atmega328.bootloader.file=ATmegaBOOT_168_atmega328.hex
 atmega328.bootloader.unlock_bits=0x3F
@@ -49,7 +49,7 @@ diecimila.upload.speed=19200
 
 diecimila.bootloader.low_fuses=0xff
 diecimila.bootloader.high_fuses=0xdd
-diecimila.bootloader.extended_fuses=0x00
+diecimila.bootloader.extended_fuses=0xf8
 diecimila.bootloader.path=atmega
 diecimila.bootloader.file=ATmegaBOOT_168_diecimila.hex
 diecimila.bootloader.unlock_bits=0x3F
@@ -70,7 +70,7 @@ nano328.upload.speed=57600
 
 nano328.bootloader.low_fuses=0xFF
 nano328.bootloader.high_fuses=0xDA
-nano328.bootloader.extended_fuses=0x05
+nano328.bootloader.extended_fuses=0xfd
 nano328.bootloader.path=atmega
 nano328.bootloader.file=ATmegaBOOT_168_atmega328.hex
 nano328.bootloader.unlock_bits=0x3F
@@ -91,7 +91,7 @@ nano.upload.speed=19200
 
 nano.bootloader.low_fuses=0xff
 nano.bootloader.high_fuses=0xdd
-nano.bootloader.extended_fuses=0x00
+nano.bootloader.extended_fuses=0xf8
 nano.bootloader.path=atmega
 nano.bootloader.file=ATmegaBOOT_168_diecimila.hex
 nano.bootloader.unlock_bits=0x3F
@@ -217,7 +217,7 @@ mini328.upload.speed=115200
 
 mini328.bootloader.low_fuses=0xff
 mini328.bootloader.high_fuses=0xd8
-mini328.bootloader.extended_fuses=0x05
+mini328.bootloader.extended_fuses=0xfd
 mini328.bootloader.path=optiboot
 mini328.bootloader.file=optiboot_atmega328-Mini.hex
 mini328.bootloader.unlock_bits=0x3F
@@ -238,7 +238,7 @@ mini.upload.speed=19200
 
 mini.bootloader.low_fuses=0xff
 mini.bootloader.high_fuses=0xdd
-mini.bootloader.extended_fuses=0x00
+mini.bootloader.extended_fuses=0xf8
 mini.bootloader.path=atmega
 mini.bootloader.file=ATmegaBOOT_168_ng.hex
 mini.bootloader.unlock_bits=0x3F
@@ -259,7 +259,7 @@ ethernet.upload.speed=115200
 
 ethernet.bootloader.low_fuses=0xff
 ethernet.bootloader.high_fuses=0xde
-ethernet.bootloader.extended_fuses=0x05
+ethernet.bootloader.extended_fuses=0xfd
 ethernet.bootloader.path=optiboot
 ethernet.bootloader.file=optiboot_atmega328.hex
 ethernet.bootloader.unlock_bits=0x3F
@@ -280,7 +280,7 @@ fio.upload.speed=57600
 
 fio.bootloader.low_fuses=0xFF
 fio.bootloader.high_fuses=0xDA
-fio.bootloader.extended_fuses=0x05
+fio.bootloader.extended_fuses=0xfd
 fio.bootloader.path=arduino:atmega
 fio.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
 fio.bootloader.unlock_bits=0x3F
@@ -302,7 +302,7 @@ bt328.upload.disable_flushing=true
 
 bt328.bootloader.low_fuses=0xff
 bt328.bootloader.high_fuses=0xd8
-bt328.bootloader.extended_fuses=0x05
+bt328.bootloader.extended_fuses=0xfd
 bt328.bootloader.path=bt
 bt328.bootloader.file=ATmegaBOOT_168_atmega328_bt.hex
 bt328.bootloader.unlock_bits=0x3F
@@ -324,7 +324,7 @@ bt.upload.disable_flushing=true
 
 bt.bootloader.low_fuses=0xff
 bt.bootloader.high_fuses=0xdd
-bt.bootloader.extended_fuses=0x00
+bt.bootloader.extended_fuses=0xf8
 bt.bootloader.path=bt
 bt.bootloader.file=ATmegaBOOT_168.hex
 bt.bootloader.unlock_bits=0x3F
@@ -366,7 +366,7 @@ lilypad328.upload.speed=57600
 
 lilypad328.bootloader.low_fuses=0xFF
 lilypad328.bootloader.high_fuses=0xDA
-lilypad328.bootloader.extended_fuses=0x05
+lilypad328.bootloader.extended_fuses=0xfd
 lilypad328.bootloader.path=atmega
 lilypad328.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
 lilypad328.bootloader.unlock_bits=0x3F
@@ -387,7 +387,7 @@ lilypad.upload.speed=19200
 
 lilypad.bootloader.low_fuses=0xe2
 lilypad.bootloader.high_fuses=0xdd
-lilypad.bootloader.extended_fuses=0x00
+lilypad.bootloader.extended_fuses=0xf8
 lilypad.bootloader.path=lilypad
 lilypad.bootloader.file=LilyPadBOOT_168.hex
 lilypad.bootloader.unlock_bits=0x3F
@@ -408,7 +408,7 @@ pro5v328.upload.speed=57600
 
 pro5v328.bootloader.low_fuses=0xFF
 pro5v328.bootloader.high_fuses=0xDA
-pro5v328.bootloader.extended_fuses=0x05
+pro5v328.bootloader.extended_fuses=0xfd
 pro5v328.bootloader.path=atmega
 pro5v328.bootloader.file=ATmegaBOOT_168_atmega328.hex
 pro5v328.bootloader.unlock_bits=0x3F
@@ 

Bug#819328: avrdude: arduino pro mini reset problem

[Milan Kupcevic]

Control: severity -1 wishlist


Hi Michal,


On 03/28/2016 12:44 PM, Michal Suchanek wrote:

[...]

> 
> I fixed the reset problem with pro mini by inverting the DTR handling in
> arduino.c
> 

[...]

> Ideally an extra argument would be added to switch which method is tried
> first.


This looks like a new feature. Please file a bug report at:

http://savannah.nongnu.org/bugs/?func=additem=avrdude

and work with the upstream on the issue.


Milan




signature.asc
Description: OpenPGP digital signature

Bug#810401: avrdude: please switch to libusb 1.0

[Milan Kupcevic]

Control: forwarded -1 https://savannah.nongnu.org/bugs/?43338
Control: block 810366 by -1


On 01/08/2016 01:35 PM, Aurelien Jarno wrote:

[...]

> 
> If avrdude supports the new libusb 1.0 library, please consider
> switching the build-depends from libusb-dev to libusb-1.0-0-dev. If not
> please inform upstream that porting the software to the new API is
> recommended.
> 


So far the upstream relies on "0.1 API compatibility wrapper".[0] The
libusb 0.1 API "is required by AVRDUDE in order to work with USB".[1]

Milan


[0] https://savannah.nongnu.org/bugs/?func=detailitem_id=41854#comment7
[1] https://savannah.nongnu.org/bugs/?func=detailitem_id=43338#comment1





signature.asc
Description: OpenPGP digital signature

Bug#817133: [Debootloaders-yaboot] Bug#817133: closed by Milan Kupcevic <mi...@debian.org> (Bug#819549: fixed in yaboot 1.3.17-2)

[Milan Kupcevic]

On 04/05/2016 12:11 PM, Risto Suominen wrote:
> I can confirm that it works now in daily build 20160405-3 on both platforms.
> 


Thanks Risto,

Milan



signature.asc
Description: OpenPGP digital signature

Bug#811905: ITP: esptool -- create and flash firmware files to ESP8266 chip

[Milan Kupcevic]

Package: wnpp
Severity: wishlist
Owner: Milan Kupcevic <mi...@debian.org>

* Package name: esptool
  Version : 0.4.6
  Upstream Author : Christian Klippel <c...@atelier-klippel.de>, 
* URL : https://github.com/igrr/esptool-ck/
* License : GPL-2
  Programming Lang: C
  Description : create and flash firmware files to ESP8266 chip

Esptool reads the compiled program in ELF format, extracts code and data 
sections, and either dumps a section to a file or assembles the firmware file 
from several segments. Esptool also communicates with the ESP8266 bootloader to 
upload firmware files to flash. Esptool can automatically put the board into 
UART bootloader mode using a variety of methods.

Bug#809002: avrdude 6.1 -> 6.2 regression: lock byte verification error

[Milan Kupcevic]

Package: avrdude
Version: 6.2-1
Severity: important
Control: affects -1 arduino


Setting lock bits with avrdude version 6.1 woks as expected while
version 6.2 yields verification error:


  @$> avrdude -patmega328p -cstk500v2 -Pusb -e -Ulock:w:0x3f:m

  [ ... ]

  avrdude: verifying ...
  avrdude: verification error, first mismatch at byte 0x
   0xff != 0x3f
  avrdude: verification error; content mismatch

  avrdude: safemode: Fuses OK (E:FD, H:DE, L:FF)

  avrdude done.  Thank you.



I'm getting the same regression with both AVRISP mkII and AVR Dragon
programmers on ATmega328p, ATmega32U4 and ATmega2560 microcontrollers.




signature.asc
Description: OpenPGP digital signature

Bug#793556: jessie-pu: package mkvmlinuz/37+deb8u1

[Milan Kupcevic]

On 12/13/2015 05:21 PM, Adam D. Barratt wrote:
> Control: tags -1 -moreinfo +confirmed
> 
> On Sun, 2015-12-13 at 13:01 -0500, Milan Kupcevic wrote:
>> Hi Adam,
>>
>> We've got third party confirmations and requests[0][1] for this fix.
>> Should I upload mkvmlinuz/37+deb8u1 to s-p-u?
> 
> I was rather hoping that your poking of debian-kernel might elicit some
> response, but apparently not. Please go ahead.
> 

Thanks. Uploaded.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#793556: jessie-pu: package mkvmlinuz/37+deb8u1

[Milan Kupcevic]

Hi Adam,

We've got third party confirmations and requests[0][1] for this fix.
Should I upload mkvmlinuz/37+deb8u1 to s-p-u?

Milan


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793556#28
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741642#56



signature.asc
Description: OpenPGP digital signature

Bug#793556: jessie-pu: package mkvmlinuz/37+deb8u1

[Milan Kupcevic]

On 12/08/2015 01:10 PM, Gerhard Pircher wrote:

[ ... ]

> It has been verified that the bugfix in version mkvmlinuz/37+deb8u1
> fixes this problem. Thus I would to ask, if this new mkvmlinuz
> version will be available anytime soon in Debian stable?
> 

I'm waiting for release managers decision at this point.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

On 12/08/2015 06:30 PM, John Paul Adrian Glaubitz wrote:
> On Fri, Apr 10, 2015 at 05:39:50PM -0400, Milan Kupcevic wrote:
>  > The module landed in sid D-I. It gets loaded automatically as it is not
>> blacklisted in D-I. I've been able to boot and run the installer on an
>> XServe G4 DP, a G4 Mac Mini, and a Pegasos II. All three machines have
>> radeon cards.
>  
> This reddit user got different results which rather support my stance:
> 
>> https://www.reddit.com/r/debian/3vyn0p/
> 


Hi John,

The module in question gets loaded and is used in D-I only. Pay
attention to the case you are pointing at: the graphics does not work on
boot/reboot into an installed system. At this point this module plays no
role because it is blacklisted in the main system. This user is having
some other issues unrelated to this module.

M





signature.asc
Description: OpenPGP digital signature

Bug#741642: mkvmlinuz: How to easily use mkvmlinuz/38 on Jessie?

[Milan Kupcevic]

On 07/22/2015 11:47 AM, intervenant0 gilles charabot wrote:
 
 Dear Maintainer, To avoid the consequences of the bug#741642, I want
 to use mkvmlinuz/38, but it isn't inside Jessie repository and isn't
 yet inside jessie-backports repository and when I tried to download
 the patch with :
 
 # cd /usr/sbin
 
 # wget
 https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=40;att=1;bug=741642;filename=mkvmlinuz-run-parts-fix.patch

  I have nothing new inside /usr/sbin to apply patch.
 
 If possible can you backports mkvmlinuz/38 to Jessie, so upgrade
 Wheezy to Jessie be more easier for me and others.
 

Hi Gilles,

Watch bug #793556 for progress on inclusion of this bugfix into
Jessie.[0] In the meantime you can download mkvmlinuz[1] version 38 and
install it on your machine before upgrading to Jessie to secure smooth
upgrade.

Milan


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793556
[1]
http://ftp.fr.debian.org/debian/pool/main/m/mkvmlinuz/mkvmlinuz_38_powerpc.deb




signature.asc
Description: OpenPGP digital signature

Bug#793556: jessie-pu: package mkvmlinuz/37+deb8u1

[Milan Kupcevic]

On 07/25/2015 06:38 AM, Adam D. Barratt wrote:
 Control: tags -1 + moreinfo
 
 On Fri, 2015-07-24 at 22:32 -0400, Milan Kupcevic wrote:
 mkvmlinuz/37+deb8u1 is fixing bug #741642 already fixed in sid/testing 
 to allow for smooth upgrade from wheezy to jessie. See attached diff.

  changelog |6 ++
  kernel-image/postinst |2 ++
  kernel-image/postrm   |2 ++
 
 --- mkvmlinuz-37/debian/kernel-image/postinst   2012-06-28 21:01:13.0 
 -0400
 +++ mkvmlinuz-37+deb8u1/debian/kernel-image/postinst2015-07-23 
 22:45:48.0 -0400
 @@ -1,5 +1,7 @@
  #!/bin/sh
  
 +echo 2
 
 Will the mkvmlinuz invocation later in the postinst ever possibly
 produce output on stdout?


The db_get debconf call does communicate with debconf through
stdin/stdout by design. That is why nothing else should use stdin nor
stdout at stake for not to interfere with such communication. The
violation actually comes from 'run-parts --report' itself, not from the
hook.

Wheezy kernel package has been using 'run-parts --verbose' to run the
hooks. This worked fine as run-parts printed out to stderr only. Jessie
kernel package is using 'run-parts --report' instead where output
depends on the behavior of the hook in question. See run-parts manual
for the exact --report run-parts option description.

I'm dealing with this problem by printing out a newline character to
stderr from the hook itself, therefore pushing run-parts to output the
hook's name to stderr, thus causing run-parts to leave the debconf
communication alone.

This fix is as minimalist as you possibly could get for a bug fix in a
stable release.

CC: debian-kernel to get possible input from there


 
 While I can see the intent behind the above (forcing run-parts
 --report to output the script name to stderr rather than stdout), it
 wasn't immediately obvious. The kernel handbook (in
 https://kernel-handbook.alioth.debian.org/ch-update-hooks.html ),
 suggests exec /dev/null 2, which seems much more idiomatic.
 


The kernel-handbook suggestion won't fix this issue because run-parts
interprets debconf communication as hook output and decides that it has
to print out the hook script name to the same place, thus interfering
with debconf communication and causing the error described in bug
reports #791868 and #741642.


Milan





signature.asc
Description: OpenPGP digital signature

Bug#793556: jessie-pu: package mkvmlinuz/37+deb8u1

[Milan Kupcevic]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

mkvmlinuz/37+deb8u1 is fixing bug #741642 already fixed in sid/testing 
to allow for smooth upgrade from wheezy to jessie. See attached diff.

 changelog |6 ++
 kernel-image/postinst |2 ++
 kernel-image/postrm   |2 ++
 3 files changed, 10 insertions(+)

-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: powerpc (ppc64)

Kernel: Linux 3.16.0-4-powerpc64 (SMP w/4 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru mkvmlinuz-37/debian/changelog mkvmlinuz-37+deb8u1/debian/changelog
--- mkvmlinuz-37/debian/changelog	2015-04-10 07:14:08.0 -0400
+++ mkvmlinuz-37+deb8u1/debian/changelog	2015-07-23 23:40:49.0 -0400
@@ -1,3 +1,9 @@
+mkvmlinuz (37+deb8u1) stable; urgency=medium
+
+  * Push run-parts output to stderr. (Closes: #741642)
+
+ -- Milan Kupcevic mi...@physics.harvard.edu  Thu, 23 Jul 2015 23:00:46 -0400
+
 mkvmlinuz (37) unstable; urgency=medium
 
   * Include only necessary modules to further reduce vmlinuz size on Pegasos. 
diff -Nru mkvmlinuz-37/debian/kernel-image/postinst mkvmlinuz-37+deb8u1/debian/kernel-image/postinst
--- mkvmlinuz-37/debian/kernel-image/postinst	2012-06-28 21:01:13.0 -0400
+++ mkvmlinuz-37+deb8u1/debian/kernel-image/postinst	2015-07-23 22:45:48.0 -0400
@@ -1,5 +1,7 @@
 #!/bin/sh
 
+echo 2
+
 set -e
 
 . /usr/share/debconf/confmodule
diff -Nru mkvmlinuz-37/debian/kernel-image/postrm mkvmlinuz-37+deb8u1/debian/kernel-image/postrm
--- mkvmlinuz-37/debian/kernel-image/postrm	2012-06-28 21:01:13.0 -0400
+++ mkvmlinuz-37+deb8u1/debian/kernel-image/postrm	2015-07-23 22:45:48.0 -0400
@@ -1,5 +1,7 @@
 #!/bin/sh
 
+echo 2
+
 set -e
 
 . /usr/share/debconf/confmodule

Bug#792751: ITP: e2fslibs1.41-dev -- legacy ext2/ext3/ext4 file system development libraries

[Milan Kupcevic]

Package: wnpp
Severity: wishlist
Owner: Milan Kupcevic mi...@physics.harvard.edu
Control: affects -1 yaboot

* Package name: e2fslibs1.41-dev
  Version : 1.41.14
  Upstream Author : Theodore Y. Ts'o ty...@mit.edu
* URL : http://e2fsprogs.sourceforge.net
* License : GPL, LGPL, BSD, MIT/X
  Programming Lang: C
  Description : legacy ext2/ext3/ext4 file system development libraries

The ext2, ext3 and ext4 file systems are successors of the original ext
(extended) file system. They are the main file system types used for
hard disks on Debian and other Linux systems.

This legacy package contains headers and static ext2fs, e2p and com_err 
libraries. 

This package is intended solely for the purpose of compiling yaboot 
against it.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#792084: FTBFS: Fails to build from source

[Milan Kupcevic]

Package: yaboot
Version: 1.3.16-4
Severity: serious
Tags: sid stretch help


Yaboot 1.3.16 and yaboot 1.3.17 fail to build with current version of
e2fslibs. Last upload was built against e2fslibs 1.42.2 with some non
trivial patching but it won't work with any later version.

Introducing back legacy static e2fslibs version 1.41.x for the sole
purpose of building yaboot against it would be one way to get around
this problem.





signature.asc
Description: OpenPGP digital signature

Bug#741642: upgrade from wheezy to jessie on a PowerMac G4 Silver

[Milan Kupcevic]

On Sun, 26 Apr 2015 16:35:29 +0200 Holger Levsen hol...@layer-acht.org
wrote:

[...]

 
 I've upgraded my old PowerMac from wheezy to jessie, which failed 
 like shown below.


[...]

 (/boot/initrd.img-3.16.0-4-powerpc) -- doing nothing at 
 /var/lib/dpkg/info/linux-image-3.16.0-4-powerpc.postinst line 263. 
 /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating
 /boot/initrd.img-3.16.0-4-powerpc 
 run-parts:
 /etc/kernel/postinst.d/mkvmlinuz exited with return code 20


The run-parts --report option in linux-image-{version}.postinst is
causing run-parts to output a file name to stdout, thus interfere with
an ongoing communication happening between mkvmlinuz and debconf which
is facilitated through stdin/stdout.

The attached mkvmlinuz patch secures a smooth upgrade from wheezy to
jessie by getting run-parts to output to stderr, not to stdout.


diff -Nru ./debian/kernel-image/postinst ../mkvmlinuz-38/debian/kernel-image/postinst
--- ./debian/kernel-image/postinst	2012-06-28 21:01:13.0 -0400
+++ ../mkvmlinuz-38/debian/kernel-image/postinst	2015-07-09 00:00:02.617843623 -0400
@@ -1,5 +1,7 @@
 #!/bin/sh
 
+echo 2
+
 set -e
 
 . /usr/share/debconf/confmodule
diff -Nru ./debian/kernel-image/postrm ../mkvmlinuz-38/debian/kernel-image/postrm
--- ./debian/kernel-image/postrm	2012-06-28 21:01:13.0 -0400
+++ ../mkvmlinuz-38/debian/kernel-image/postrm	2015-07-09 00:00:18.697817011 -0400
@@ -1,5 +1,7 @@
 #!/bin/sh
 
+echo 2
+
 set -e
 
 . /usr/share/debconf/confmodule

Bug#774845: yaboot 1.3.17 is out

[Milan Kupcevic]

tags 774845 + help d-i
block 322540 by 774845
block 719479 by 774845
block 641852 by 774845
block 697813 by 774845
block 784387 by 774845
block 697813 by 774845
thanks


On Thu, 8 Jan 2015 11:58:09 +0100 Mathieu Malaterre ma...@debian.org
wrote:
 Package: yaboot
 
 It would be nice to package newer yaboot release. It fixes:
 
 Key features are:
 
 Better netboot
 IPv6 support for netboot
 Bug fixes for iscsi and pSeries
 Removal of old dead code
 Now builds with -Werror
 


Yaboot upstream development is dead for several years already. While it
was possible to make it work with e2fslibs 1.42.2 with some patching,
linking to any later version won't work.

It is probably not worth investing any more time and efforts to maintain
this package. I would rather spend my Debian time to help bring
grub-ieee1275 into Stretch d-i than to continue reanimating this dead
animal.

While there is a valid rationale to ask FTP Masters to remove Yaboot
package from sid, I'm tagging this bug with 'help' to give a chance for
possible takers to provide help or take it over.

Milan




signature.asc
Description: OpenPGP digital signature

Bug#784387: yaboot: ofpath returns the wrong path, breaking yaboot.conf

[Milan Kupcevic]

On 05/05/2015 07:07 PM, Asumu Takikawa wrote:
 
 ofpath returns the wrong result, causing the /etc/yaboot.conf file to have an
 unbootable device path. I encountered this while trying to install Jessie on
 a Powermac G5.
 
 Here is the wrong output (from my now-booting system):
 
   $ /usr/sbin/ofpath /dev/sda2
   /ht@0,f200/pci@9/k2-sata-root@c/@/@0:2


Could you try if the attached patch fixes this issue?

Milan
--- a/ybin/ofpath
+++ b/ybin/ofpath
@@ -220,7 +220,10 @@
 IEEE1394_ID=`cat /sys/block/$DEVNODE/device/ieee1394_id 2/dev/null`
 IEEE1394_ID=${IEEE1394_ID%%:*}
 
-PLUG_ID=$(ls -dv $SYS_PATH/host* 2/dev/null | grep -n /host$HOST_ID$)
+PLUG_ID=$(ls -dv $SYS_PATH/*/host* 2/dev/null | grep -n /host$HOST_ID$)
+[ -z $PLUG_ID ]  {
+  PLUG_ID=$(ls -dv $SYS_PATH/host* 2/dev/null | grep -n /host$HOST_ID$)
+}
 PLUG_ID=$((${PLUG_ID%%:*}-1))
 
 PART=${PARTITION:+:$PARTITION}

Bug#545874: yabootfconfig fails on LVM

[Milan Kupcevic]

tags 545874 + upstream wontfix
thanks


Yaboot has got no native support for LVM. Please bring this question to
the upstream developers.

Milan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783982: D-i: preseed from floppy no longer works !

[Milan Kupcevic]

On 05/01/2015 06:09 PM, Alexey Eromenko wrote:

[...]

 
 Debian 8 (mini-)kernel (inside amd64-DVD) does NOT see /dev/fd0 ! 
 (part of debian-installer); This works just fine with Debian 6 and 7
 ! Post-install Debian 8 kernel _does_ see /dev/fd0, can loop-mount
 and can read files from it. (after installing from Debian 8
 amd64-DVD), so no problem here.
 
 The natural question: Are those kernels different ? (I always
 assumed it is the *same* kernel) It seems the mini-kernel does not
 provide me with /proc/config.gz, so I have no clue what's included
 and what's excluded. How can I check ?
 

The kernel is the same but the number of modules included in d-i
initrd.gz is reduced to bare minimum needed for d-i to boot up. The list
of included modules is different on cdrom d-i image, netboot d-i image,
and hd-media d-i image.

One way to check it out would be to unpack the d-i image initrd.gz and
look what is in there. The /proc/config.gz would not help as it would
provide info about what is compiled, but not what is included in d-i.

The fact that floppy works in final installation likely means the module
is in fact compiled but not included in d-i image.

Therefore, the way to go would be to figure out which module is needed
to provide access to floppy on your platform and then work with kernel
team on inclusion of the module in in the d-i initrd.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#782352: unblock: mkvmlinuz/37

[Milan Kupcevic]

Control: tags -1 - moreinfo

Hi,

On 04/12/2015 04:19 PM, Ivo De Decker wrote:
 Control: tags -1 confirmed moreinfo
 
 Hi,
 
 On Fri, Apr 10, 2015 at 02:09:16PM -0400, Milan Kupcevic wrote:
 About to upload mkvmlinuz/37 fixing bug #782278
 Pegasos II won't boot after kernel upgrade
 
 Please go ahead and remove the moreinfo tag from this bug once the upload is
 in unstable.
 


The mkvmlinuz/37 has landed in sid.


Milan




signature.asc
Description: OpenPGP digital signature

Bug#782352: unblock: mkvmlinuz/37 (pre-approval)

[Milan Kupcevic]

Control: retitle -1 Bug#782352: unblock: mkvmlinuz/37 (pre-approval)


Should we go ahead with upload of mkvmlinuz/37?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

On 04/09/2015 08:21 AM, Ben Hutchings wrote:
[...]

 
 It isn't reverted.  All I've done is to add radeonfb.ko to the drivers
 that are included *in the installer*.
 
 Neither radeon.ko nor xserver-xorg-video-radeon are included in the
 installer, so how could they possibly be used?  If you though those
 should be used in the installer, you should have told people that
 earlier.
 
 As it is, I think that the installer should be able to work using
 radeonfb.ko and xserver-xorg-video-fbdev, though I'm not sure whether
 radeonfb.ko will be loaded automatically.
 
 Ben.
 

The module landed in sid D-I. It gets loaded automatically as it is not
blacklisted in D-I. I've been able to boot and run the installer on an
XServe G4 DP, a G4 Mac Mini, and a Pegasos II. All three machines have
radeon cards.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

On 04/10/2015 06:05 PM, Ben Hutchings wrote:
 On Fri, 2015-04-10 at 17:39 -0400, Milan Kupcevic wrote:
 On 04/09/2015 08:21 AM, Ben Hutchings wrote:
 [...]


 It isn't reverted.  All I've done is to add radeonfb.ko to the drivers
 that are included *in the installer*.

 Neither radeon.ko nor xserver-xorg-video-radeon are included in the
 installer, so how could they possibly be used?  If you though those
 should be used in the installer, you should have told people that
 earlier.

 As it is, I think that the installer should be able to work using
 radeonfb.ko and xserver-xorg-video-fbdev, though I'm not sure whether
 radeonfb.ko will be loaded automatically.

 Ben.


 The module landed in sid D-I. It gets loaded automatically as it is not
 blacklisted in D-I. I've been able to boot and run the installer on an
 XServe G4 DP, a G4 Mac Mini, and a Pegasos II. All three machines have
 radeon cards.
 
 Using the graphical or text-based installer?
 
 Ben.
 

Using text-based installer. I do not remember when I last time saw
graphical installer on PowerPC platform. As far as I know there is no
graphical installer on this platform for very long time. It seems no one
is even trying to make it work.

Milan






signature.asc
Description: OpenPGP digital signature

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

On 04/09/2015 12:29 PM, Ben Hutchings wrote:
 
 Let's try to keep this civil, please.
 
 Ben.
 


Sorry, my reaction to personal attacks was too harsh. Will stick to
technical issues and ignore any personal slurs from now on.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

On 04/09/2015 04:08 AM, John Paul Adrian Glaubitz wrote:
 On 04/09/2015 12:38 AM, Milan Kupcevic wrote:
 Well, yes. As you could see from the bug report you linked above,
  compiling radeonfb into the kernel broke X on basically all
 Radeon cards.

 
 It seems that radeonfb was compiled into the kernel since the dawn
 of time.
 
 On the powerpc Debian kernel, yes, on the other architectures, no.
 radeonfb has been deprecated long time ago and should no longer be
 used.
 
 The only reason it was compiled into the powerpc kernel without anyone
 complaining is the fact that the xf86-video-ati (= Radeon X.Org) driver
 in Wheezy was still old enough [1] to support userland mode-setting
 which was dropped upstream in version 7.0.0 almost three years ago [2].
 
 This is no longer true in Jessie and therefore we have to use radeon,
 not radeonfb. Otherwise you won't get any X display.

What did you do to ensure the radeon module is included in debian installer?

 
 The reason is that the radeon KMS module does not work once
 radoenfb has been loaded once. Even if you unload radeonfb later,
 the radeon module will still refuse to work meaning X will not be
 usable.

 
 This is good to know.
 
 I did thorough testing for the bug report you linked above which is
 why I am a bit surprised you could convince Ben so easily to partly
 revert my change. I think I also explained in the other bug tracker
 that you have to use KMS these days as UMS is being phased out.
 

There is no revert of your change at all. We are just trying to add a
module to debian installer to enable installation on machines with no
native offb support, the machines you have skipped in your thorough
testing. Any input on the best way to achieve this is welcome.

 Well, I think this can be answered straight-forward: radeonfb is
 the wrong solution as radeonfb does not support X which means you
 can use the text-based installer only. But I guess you never
 tested that as you stated in your bug report.


How is that X display in debian installer on PowerPC platform working
for you?

 The proper fix for your problem is not to revert my previous fix
 but to use the proper driver, thus reopening.

 
 There was no my previous fix, just reporting about the state of
 the things in RC1 and RC2. I'm trying to help as I have access to
 more than a few power and powerpc machines.
 
 Sure, but please ask people in the future before you are asking for
 changes which you don't understand. 

Your understanding of the consequences of your changes is trully stellar.

 I also have tons of different
 hardware available here, including several powerpc machines and
 way beyond that (m68k, sh4, mips etc).
 b
 I think you should at least discuss such changes with some more people
 before you ask for them to be integrated. 

Well, I've asked, no one complained until you showed up. The resulting
discussion spreads very interesting scent.

 For anyone who follows X.Org
 and kernel development, it is common knowledge that all the non-KMS
 drivers in the kernel are being deprecated and that you should no
 longer use them. This also applies to X.Org.
 
 It would be nice if you could CC me in the future if you are having
 issues with non-x86 hardware, especially anything that's powerpc,
 Macintosh, or - like in this case - Amiga-related hardware.

Are you sure you want to know about every non-x86 issue I face on daily
basis?


M



signature.asc
Description: OpenPGP digital signature

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

On 04/08/2015 04:02 PM, John Paul Adrian Glaubitz wrote:
 Control: reopen -1
 
 On 04/08/2015 09:51 PM, Milan Kupcevic wrote:
 In Wheezy and in Jessie RC1 radenfb was compiled in the kernel 
 itself while debian installer worked fine on this machine.
 
 Well, yes. As you could see from the bug report you linked above, 
 compiling radeonfb into the kernel broke X on basically all Radeon 
 cards.
 

It seems that radeonfb was compiled into the kernel since the dawn of time.

 The reason is that the radeon KMS module does not work once radoenfb 
 has been loaded once. Even if you unload radeonfb later, the radeon 
 module will still refuse to work meaning X will not be usable.
 

This is good to know.

 If you want to use X, you **have** to use the radeon KMS driver as 
 the xf86-video-radeon driver does no longer support UMS modesetting 
 which means no matter what you do, you will **never** be able to run 
 X once radeonfb is loaded until next reboot.
 

Okay.

 Neither radeon nor radeonfb driver is included in RC2 debian 
 installer.
 
 Well, yes, we forgot to include radeon, true.
 

[...]

 
 Whether we want to include radeonfb module or radeon KMS module in 
 debian installer is question open to discussion.
 
 Well, I think this can be answered straight-forward: radeonfb is the 
 wrong solution as radeonfb does not support X which means you can use
 the text-based installer only. But I guess you never tested that as
 you stated in your bug report.
 
 The proper fix for your problem is not to revert my previous fix but
  to use the proper driver, thus reopening.
 

There was no my previous fix, just reporting about the state of the
things in RC1 and RC2. I'm trying to help as I have access to more than
a few power and powerpc machines.

As for the proper driver, I'm all for it. We are lucky to have you
around to take care of these issues. I'm looking forward to download and
install final Jessie release on many machines with no problems at all.

Milan





signature.asc
Description: OpenPGP digital signature

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

On 04/08/2015 02:03 PM, John Paul Adrian Glaubitz wrote:
 Hi Milan!
 
 I just stumbled across this bug report and was actually wondering why
 your Pegasos-II board won't work properly with the radeon KMS driver.
 
 As far as I know, the Radeon 9250 found on the Pegasos-II board is fully
 supported by the radeon KMS driver, so I'd expect it to work out-of
 the-box. I always had the opinion that radeonfb was deprecated in
 favor of the KMS driver and therefore the latter is the one you should
 be using.
 
 Maybe it's a good idea to report any issues with the KMS driver to the
 radeon upstream developers?
 

In Wheezy and in Jessie RC1 radenfb was compiled in the kernel itself
while debian installer worked fine on this machine.

Neither radeon nor radeonfb driver is included in RC2 debian installer.
OpenFirmware frame buffer never worked on Pegasos machines so I had to
use serial port to install RC2. After successful installation, the
machine boots up and uses radeon KMS installed on its HD.

Whether we want to include radeonfb module or radeon KMS module in
debian installer is question open to discussion.


Milan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

Package: src:linux
Version: 3.16.7-ckt7-1
Severity: important
Tags: d-i jessie


The last line seen on the screen after installer CD boots is 
'returning from prom_init'.  This is a regression introduced in 
d-i rc2 which persist in daily builds.

Connecting serial terminal and booting with 'console=ttyS0,9600' allows 
successful installation of jessie.  (with some hiccups that warrant a 
separate bug report to mkvmlinuz).

I'm aware that fix for bug #748398 actually introduced this regression.
The radeonfb is currently compiled as module which is not included in the 
installer. I hope that including the radeonfb module in the installer will fix 
this issue.

This report was generated on the same machine after successful installation.

Could you please add radeonfb module to debian installer?

Milan


-- Package-specific info:
** Version:
Linux version 3.16.0-4-powerpc (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 Debian 3.16.7-ckt7-1 (2015-03-01)

** Command line:
root=/dev/sda2

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[9.107171] [drm] Connector 0:
[9.107180] [drm]   VGA-1
[9.107193] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[9.107206] [drm]   Encoders:
[9.107216] [drm] CRT1: INTERNAL_DAC1
[9.107227] [drm] Connector 1:
[9.107237] [drm]   DVI-I-1
[9.107246] [drm]   HPD1
[9.107258] [drm]   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[9.107269] [drm]   Encoders:
[9.107279] [drm] CRT2: INTERNAL_DAC2
[9.107290] [drm] DFP1: INTERNAL_TMDS1
[9.138249] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
[9.222863] [drm] fb mappable at 0xC004
[9.222913] [drm] vram apper at 0xC000
[9.222924] [drm] size 5242880
[9.222934] [drm] fb depth is 24
[9.222944] [drm]pitch is 5120
[9.275221] Console: switching to colour frame buffer device 160x64
[9.316086] radeon 0001:01:08.0: fb0: radeondrmfb frame buffer device
[9.316398] radeon 0001:01:08.0: registered panic notifier
[9.320300] [drm] Initialized radeon 2.39.0 20080528 for 0001:01:08.0 on 
minor 0
[9.679644] Adding 3012180k swap on /dev/sda3.  Priority:-1 extents:1 
across:3012180k FS
[9.722815] EXT4-fs (sda1): mounting ext2 file system using the ext4 
subsystem
[9.732480] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
[9.872623] snd_via82xx_modem: probe of :00:0c.6 failed with error -13
[9.873912] snd_via82xx :00:0c.5: enabling device ( - 0001)
[   10.234992] systemd-journald[133]: Received request to flush runtime journal 
from PID 1
[   10.425400] via-rhine :00:0d.0: enabling device ( - 0003)
[   10.460940] via-rhine :00:0d.0 eth0: VIA Rhine II at 0xf1ffe900, 
00:0b:2f:43:fb:04, IRQ 9
[   10.462200] via-rhine :00:0d.0 eth0: MII PHY found at address 16, status 
0x786d advertising 01e1 Link c5e1
[   10.480763] uhci_hcd :00:0c.2: UHCI Host Controller
[   10.481103] uhci_hcd :00:0c.2: new USB bus registered, assigned bus 
number 1
[   10.481482] uhci_hcd :00:0c.2: detected 2 ports
[   10.481768] uhci_hcd :00:0c.2: irq 9, io base 0x1040
[   10.482306] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[   10.482646] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   10.496172] usb usb1: Product: UHCI Host Controller
[   10.509022] usb usb1: Manufacturer: Linux 3.16.0-4-powerpc uhci_hcd
[   10.521857] usb usb1: SerialNumber: :00:0c.2
[   10.587163] hub 1-0:1.0: USB hub found
[   10.587190] hub 1-0:1.0: 2 ports detected
[   10.587827] ehci-pci :00:05.2: EHCI Host Controller
[   10.587850] ehci-pci :00:05.2: new USB bus registered, assigned bus 
number 2
[   10.588018] ehci-pci :00:05.2: irq 9, io mem 0x80002800
[   10.596335] ehci-pci :00:05.2: USB 2.0 started, EHCI 1.00
[   10.596575] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[   10.596581] usb usb2: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   10.596585] usb usb2: Product: EHCI Host Controller
[   10.596589] usb usb2: Manufacturer: Linux 3.16.0-4-powerpc ehci_hcd
[   10.596593] usb usb2: SerialNumber: :00:05.2
[   10.597535] hub 2-0:1.0: USB hub found
[   10.597685] hub 2-0:1.0: 5 ports detected
[   10.598436] uhci_hcd :00:0c.3: UHCI Host Controller
[   10.598457] uhci_hcd :00:0c.3: new USB bus registered, assigned bus 
number 3
[   10.598473] uhci_hcd :00:0c.3: detected 2 ports
[   10.598522] uhci_hcd :00:0c.3: irq 9, io base 0x1060
[   10.598731] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[   10.598737] usb usb3: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   10.598741] usb usb3: Product: UHCI Host Controller
[   10.598744] usb usb3: Manufacturer: Linux 3.16.0-4-powerpc uhci_hcd
[   10.598748] usb usb3: SerialNumber: :00:0c.3
[   10.599440] hub 3-0:1.0: USB hub found
[   10.599573] hub 3-0:1.0: 2 ports detected
[   

Bug#781936: rootskel (d-i): G5 fans run full speed

[Milan Kupcevic]

Bug fix is pending upload: 

http://anonscm.debian.org/cgit/d-i/rootskel.git/commit/?id=73d613f581ae06b35ca21119f914210571cb7b11

Milan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#781934: XServe G5 all fans run full speed

[Milan Kupcevic]

Package: src:linux
Version: 3.16.7-ckt7-1
Severity: important


Installing jessie makes XServe G5 fans run full speed all the time.



-- Package-specific info:
** Version:
Linux version 3.16.0-4-powerpc64 (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)

** Command line:
root=UUID=47e08bf5-e62c-4488-9715-ecc20f04b351 ro 

** Not tainted

** Kernel log:
[6.514122] systemd[1]: Starting system-getty.slice.
[6.534961] systemd[1]: Created slice system-getty.slice.
[6.544965] systemd[1]: Starting Create list of required static device nodes 
for the current kernel...
[6.575941] systemd[1]: Mounting Debug File System...
[6.597499] systemd[1]: Mounting POSIX Message Queue File System...
[6.619313] systemd[1]: Mounting Huge Pages File System...
[6.673770] systemd[1]: Starting Load Kernel Modules...
[6.698216] systemd[1]: Starting udev Coldplug all Devices...
[6.765327] systemd[1]: Started Set Up Additional Binary Formats.
[6.775556] systemd[1]: Starting Journal Service...
[6.807087] systemd[1]: Started Journal Service.
[7.344876] lp: driver loaded but no devices found
[7.621376] systemd-udevd[171]: starting version 215
[8.488202] [drm] Initialized drm 1.1.0 20060810
[8.733873] systemd-udevd[185]: renamed network interface eth0 to eth2
[8.753893] systemd-udevd[186]: renamed network interface eth1 to eth3
[9.000653] [drm] radeon kernel modesetting enabled.
[9.010302] checking generic (9c008000 96000) vs hw (9800 800)
[9.010309] fb: switching to radeondrmfb from OFfb ATY,BlueSt
[9.024617] Console: switching to colour dummy device 80x25
[9.025144] radeon 0001:06:03.0: enabling device (0086 - 0087)
[9.025601] [drm] initializing kernel modesetting (RV100 0x1002:0x5159 
0x1002:0x0908).
[9.026603] [drm] register mmio base: 0x9008
[9.026623] [drm] register mmio size: 65536
[9.163941] [drm] Not an x86 BIOS ROM, not using.
[9.173981] [drm] Using device-tree clock info
[9.174005] radeon 0001:06:03.0: VRAM: 128M 0x9800 - 
0x9FFF (64M used)
[9.174014] radeon 0001:06:03.0: GTT: 512M 0x7800 - 
0x97FF
[9.178774] [drm] Detected VRAM RAM=128M, BAR=128M
[9.178792] [drm] RAM width 64bits DDR
[9.178972] [TTM] Zone  kernel: Available graphics memory: 2040832 kiB
[9.178980] [TTM] Initializing pool allocator
[9.179111] [drm] radeon: 64M of VRAM memory ready
[9.179123] [drm] radeon: 512M of GTT memory ready.
[9.179181] [drm] GART: num cpu pages 8192, num gpu pages 131072
[9.201437] [drm] PCI GART of 512M enabled (table at 0x6218).
[9.201655] radeon 0001:06:03.0: WB disabled
[9.201676] radeon 0001:06:03.0: fence driver on ring 0 use gpu addr 
0x7800 and cpu addr 0xc00164ad
[9.201692] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[9.201697] [drm] Driver supports precise vblank timestamp query.
[9.201765] [drm] radeon: irq initialized.
[9.201809] [drm] Loading R100 Microcode
[9.237575] radeon 0001:06:03.0: firmware: failed to load radeon/R100_cp.bin 
(-2)
[9.237648] [drm:r100_cp_init] *ERROR* Failed to load firmware!
[9.237657] radeon 0001:06:03.0: failed initializing CP (-2).
[9.237664] radeon 0001:06:03.0: Disabling GPU acceleration
[9.237692] [drm] radeon: cp finalized
[9.238134] i2c i2c-5: therm_pm72: attach_adapter method is deprecated
[9.238146] i2c i2c-5: Please use another way to instantiate your i2c_client
[9.238212] i2c i2c-6: therm_pm72: attach_adapter method is deprecated
[9.238219] i2c i2c-6: Please use another way to instantiate your i2c_client
[9.238272] i2c i2c-7: therm_pm72: attach_adapter method is deprecated
[9.238279] i2c i2c-7: Please use another way to instantiate your i2c_client
[9.238334] i2c i2c-8: therm_pm72: attach_adapter method is deprecated
[9.238341] i2c i2c-8: Please use another way to instantiate your i2c_client
[9.246611] [drm] Connector Table: 1 (generic)
[9.246652] [drm] No TMDS info found in BIOS
[9.246663] [drm] No TV DAC info found in BIOS
[9.246944] [drm] Radeon Display Connectors
[9.246950] [drm] Connector 0:
[9.246954] [drm]   DVI-I-1
[9.246958] [drm]   HPD1
[9.246964] [drm]   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[9.246968] [drm]   Encoders:
[9.246973] [drm] DFP1: INTERNAL_TMDS1
[9.246977] [drm] CRT2: INTERNAL_DAC2
[9.246982] [drm] Connector 1:
[9.246986] [drm]   VGA-1
[9.246991] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[9.247004] [drm]   Encoders:
[9.247005] [drm] CRT1: INTERNAL_DAC1
[9.247006] [drm] Connector 2:
[9.247006] [drm]   SVIDEO-1
[9.247007] [drm]   Encoders:
[9.247008] [drm] TV1: INTERNAL_DAC2
[9.345904] [drm] fb mappable at 0x9804
[9.345923] [drm] vram apper at 0x9800
[

Bug#781935: initramfs-tools: XServe G5 all fans run full speed

[Milan Kupcevic]

tags 781935 + patch
thanks

diff --git a/hooks/thermal b/hooks/thermal
index 93f5100..0b755e0 100755
--- a/hooks/thermal
+++ b/hooks/thermal
@@ -32,8 +32,11 @@ powerpc|ppc64)
 	MODEL=${MODEL##*: }
 
 	case $MODEL in
-	  RackMac3,1|PowerMac7,2|PowerMac7,3)
-	force_load therm_pm72
+	  RackMac3,1)
+	force_load windfarm_rm31
+	;;
+	  PowerMac7,2|PowerMac7,3)
+	force_load windfarm_pm72
 	;;
 	  PowerMac8,1|PowerMac8,2)
 	force_load windfarm_pm81
@@ -60,6 +63,15 @@ powerpc|ppc64)
 	manual_add_modules windfarm_smu_controls
 	manual_add_modules windfarm_smu_sat
 	manual_add_modules windfarm_smu_sensors
+	manual_add_modules windfarm_ad7417_sensor
+	manual_add_modules windfarm_fcu_controls
+	manual_add_modules windfarm_lm87_sensor
+	manual_add_modules windfarm_pm112
+	manual_add_modules windfarm_pm121
+	manual_add_modules windfarm_pm72
+	manual_add_modules windfarm_pm81
+	manual_add_modules windfarm_pm91
+	manual_add_modules windfarm_rm31
 	;;
 i386|amd64|ia64)
 	manual_add_modules fan

Bug#781934: XServe G5: all fans run full speed

[Milan Kupcevic]

The therm_pm72 module is obsolete. It does not do thermal management anymore. 
I've compiled windfarm_rm31 and windfarm_pm72 modules and successfully tested 
on an XServe G5 (RackMac3,1) and a Power Mac G5 (PowerMac7,3). 

Milan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#781934: XServe G5: all fans run full speed

[Milan Kupcevic]

tags 781934 + patch
thanks

Index: linux/debian/config/kernelarch-powerpc/config
===
--- linux/debian/config/kernelarch-powerpc/config	(revision 22467)
+++ linux/debian/config/kernelarch-powerpc/config	(working copy)
@@ -389,8 +389,10 @@
 CONFIG_MAC_EMUMOUSEBTN=y
 CONFIG_THERM_WINDTUNNEL=m
 CONFIG_THERM_ADT746X=m
-CONFIG_THERM_PM72=m
+# CONFIG_THERM_PM72 is not set
 CONFIG_WINDFARM=m
+CONFIG_WINDFARM_RM31=m
+CONFIG_WINDFARM_PM72=m
 CONFIG_WINDFARM_PM81=m
 CONFIG_WINDFARM_PM91=m
 CONFIG_WINDFARM_PM112=m
Index: linux/debian/config/kernelarch-powerpc/config-arch-64-be
===
--- linux/debian/config/kernelarch-powerpc/config-arch-64-be	(revision 22467)
+++ linux/debian/config/kernelarch-powerpc/config-arch-64-be	(working copy)
@@ -66,9 +66,12 @@
 ## file: drivers/macintosh/Kconfig
 ##
 CONFIG_WINDFARM=m
+CONFIG_WINDFARM_RM31=m
+CONFIG_WINDFARM_PM72=m
 CONFIG_WINDFARM_PM81=m
 CONFIG_WINDFARM_PM91=m
 CONFIG_WINDFARM_PM112=m
+CONFIG_WINDFARM_PM121=m
 
 ##
 ## file: drivers/net/ethernet/pasemi/Kconfig
Index: linux/debian/installer/powerpc/modules/powerpc-powerpc64/fancontrol-modules
===
--- linux/debian/installer/powerpc/modules/powerpc-powerpc64/fancontrol-modules	(revision 22467)
+++ linux/debian/installer/powerpc/modules/powerpc-powerpc64/fancontrol-modules	(working copy)
@@ -1,5 +1,4 @@
 i2c-powermac ?
-therm_pm72 ?
 windfarm_core ?
 windfarm_cpufreq_clamp ?
 windfarm_lm75_sensor ?
@@ -9,6 +8,12 @@
 windfarm_pm112 ?
 windfarm_pm81 ?
 windfarm_pm91 ?
+windfarm_pm72 ?
+windfarm_rm31 ?
 windfarm_smu_controls ?
 windfarm_smu_sat ?
 windfarm_smu_sensors ?
+windfarm_ad7417_sensor ?
+windfarm_fcu_controls ?
+windfarm_lm87_sensor ?
+windfarm_pid ?

Bug#751346: man page for totem-audio-preview

[Milan Kupcevic]

Package: totem
Tags: patch

A patch adding totem-audio-preview man page is attached.

Milan

diff -Nru ./data/Makefile.am ../totem-3.12.1/data/Makefile.am
--- ./data/Makefile.am	2014-03-23 09:13:08.0 -0400
+++ ../totem-3.12.1/data/Makefile.am	2014-06-11 17:18:07.239050365 -0400
@@ -9,7 +9,7 @@
 EXTRA_DIST += $(bugreport_SCRIPTS)
 
 # Man pages
-man_MANS = totem.1 totem-video-thumbnailer.1
+man_MANS = totem.1 totem-video-thumbnailer.1 totem-audio-preview.1
 totem-video-thumbnailer.1: totem-video-thumbnailer.pod
 	$(AM_V_GEN) pod2man -c  -s 1 -q none -n totem-video-thumbnailer -r GNOME $  $@
 EXTRA_DIST += \
diff -Nru ./data/Makefile.in ../totem-3.12.1/data/Makefile.in
--- ./data/Makefile.in	2014-04-30 05:41:21.0 -0400
+++ ../totem-3.12.1/data/Makefile.in	2014-06-11 17:18:22.475050195 -0400
@@ -488,7 +488,7 @@
 bugreport_SCRIPTS = totem-bugreport.py
 
 # Man pages
-man_MANS = totem.1 totem-video-thumbnailer.1
+man_MANS = totem.1 totem-video-thumbnailer.1 totem-audio-preview.1
 
 # UI files and images
 stuffdir = $(pkgdatadir)
diff -Nru ./data/totem-audio-preview.1 ../totem-3.12.1/data/totem-audio-preview.1
--- ./data/totem-audio-preview.1	1969-12-31 19:00:00.0 -0500
+++ ../totem-3.12.1/data/totem-audio-preview.1	2014-06-10 21:31:04.220334100 -0400
@@ -0,0 +1,49 @@
+.\ Copyright (C) 2014 Milan Kupcevic mi...@physics.harvard.edu
+.\
+.\ This file is free software; you may redistribute it and/or modify
+.\ it under the terms of the GNU General Public License as
+.\ published by the Free Software Foundation; either version 2,
+.\ or (at your option) any later version.
+.\
+.\ This file is distributed in the hope that it will be useful, but
+.\ WITHOUT ANY WARRANTY; without even the implied warranty of
+.\ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+.\ GNU General Public License for more details.
+.\
+.\ You should have received a copy of the GNU General Public License 
+.\ along with this; if not write to the Free Software Foundation, Inc.
+.\ 59 Temple Place, Suite 330, Boston, MA 02111-1307  USA
+.TH totem\-audio\-preview 1 2014\-06\-08 GNOME User Commands
+.SH NAME
+totem\-audio\-preview \- play audio files
+.SH SYNOPSIS
+.B totem\-audio\-preview
+.RI [ OPTION ]...   [ FILE ]...
+.SH DESCRIPTION
+.B totem\-audio\-preview 
+is primarily used by GNOME applications for audio preview purposes.
+.SH OPTIONS
+.TP
+.B \-h, \-\-help
+Display help.
+.TP
+.B \-\-help-gst
+Display GStreamer options.
+.TP
+.B \-m, \-\-mimetype
+Display supported mime\-types.
+.TP
+.B \-\-g\-fatal\-warnings
+Make all warnings fatal.
+.PP
+When no FILE is specified, read standard input.
+.SH AUTHOR
+.B totem\-audio\-preview 
+was written by Bastien Nocera had...@hadess.net.
+.PP 
+This manual page was written by Milan Kupcevic for the Debian Project.
+.SH SEE ALSO
+.PP
+.BR \%totem\-video\-thumbnailer (1),
+.BR \%totem (1), 
+.BR \%nautilus (1)

Bug#722094: RFS: avra/1.3.0-1 [ITA] -- assembler for Atmel AVR microcontrollers

[Milan Kupcevic]

On 09/08/2013 11:21 AM, Vincent Bernat wrote:
  ❦  7 septembre 2013 22:22 CEST, Milan Kupcevic mi...@physics.harvard.edu :
 
 I am looking for a sponsor for my package avra

   Package name: avra
   Version : 1.3.0-1
   URL : http://avra.sf.net
   License : GPL-2+
   Section : electronics

 It builds this binary package:

   avra  - Assembler for Atmel AVR microcontrollers
 
 Hi Milan!
 

Hi Vincent:

 The package looks good.
 
 The short description should not start with a capital (in
 debian/control).

Done.

 
 Please, convert debian/copyright to DEP-5. This is not a mandatory step
 for Debian policy but this is something that I require to sponsor
 packages. 

Done.

 Moreover, this file is currently incomplete. You should update
 the years, add copyright information for debian/* files 

Done.

 and it seems you are not one of the copyright holders. 

Well, while transforming the package to 3.0 quilt I rewrote all the
content in almost all the files in debian/*, and added new files. There
is hardly any content left of previous maintainers. Moreover, out of
three patches I'm the author of two, and I back-ported the code from the
upstream for the third patch.

 There are some other copyright holders, like in src/device.c and examples/*.
 
 src/stab.h is Copyright (c) 1990 by Sun Microsystems, Inc. I think it is
 not covered by GPLv2 since it was only released a year later. Its
 content is present in other headers (like a.out.h and stab.h). Since
 it is an header, it is believed that they are not copyrightable. Just
 document those facts (not copyrightable and content available in two
 other header files) to be safe.
 

Done.


Vincent,

Thank you for quick review, quick response, and for doing this important
service for Debian. Please review the newly uploaded package again.


Milan




signature.asc
Description: OpenPGP digital signature

Bug#722094: RFS: avra/1.3.0-1 [ITA]

[Milan Kupcevic]

Package: sponsorship-requests
Severity: normal

I am looking for a sponsor for my package avra

  Package name: avra
  Version : 1.3.0-1
  URL : http://avra.sf.net
  License : GPL-2+
  Section : electronics

It builds this binary package:

  avra  - Assembler for Atmel AVR microcontrollers

To access further information about this package, please visit the
following URL:

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


Alternatively, one can download the package with dget using this command:

  dget -x http://mentors.debian.net/debian/pool/main/a/avra/avra_1.3.0-1.dsc

More information about avra can be obtained from http://avra.sf.net

Changes since the last upload:

  * New upstream release (closes: #588507)
- fixes invalid comment characters (closes: #668631)
  * New maintainer (closes: #691906)
  * Update source format to 3.0 (quilt)
  * Update standards version to 3.9.4
  * Bump debhelper compatibility to 9
  * Update debian/rules, debian/watch, debian/avra.examples, debian/avra.1,
debian/avra.manpages, debian/avra.install, debian/avra.docs
  * Remove Vcs-Git and Vcs-Browser control fields.
  * Backport support for ATtiny20 with AVR8L.
  * Add support and header files for ATtiny4, ATtiny5, ATtiny9 and ATtiny10


Regards,

Milan Kupcevic



signature.asc
Description: OpenPGP digital signature

Bug#717511: Kernel does not start up on Pegasos-2

[Milan Kupcevic]

On 07/22/2013 02:42 PM, Ben Hutchings wrote:

On Mon, Jul 22, 2013 at 09:59:18PM +0400, Pavel Fedin wrote:

Hello, Milan.

22 июля 2013 г., 5:23:34, you wrote:



User did not let installer to create default partition layout but
manually created incorrect one, or installed on a previously created
partitions and used ext4 and ext3 file-systems.


  Yes, exactly. Actually i agree, there's little to blame in Installer.
Only  one  small  thing  -  nobody  told me that my layout (previously
worked) became incorrect. Perhaps Installer should warn about it ?
  Or, we can consider one more corner case. What if i install the whole
OS to a single EXT2 partition ? Yes, again, i agree, you may ask Why,
EXT2  is  outdated  and  there's cool new EXT4. I have already said -
this is corner case.


Maybe the installer could warn about a likely broken partition
layout after you choose manual layout.  It doesn't seem right
that if you want to customise layout at all you must remember
any machine-specific constraints.

Also, this constraint is not documented in the installation manual.




Reassigning to installation-guide-powerpc and partman-ext3.


Milan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#717511: Kernel does not start up on Pegasos-2

[Milan Kupcevic]

Control: notfound 717511 yaboot-installer/1.1.26

On 07/21/2013 08:49 PM, Ben Hutchings wrote:

On Sun, 2013-07-21 at 20:36 -0400, Milan Kupcevic wrote:

Control: notfound -1 yaboot-installer/1.1.26

On 07/21/2013 04:55 PM, Ben Hutchings wrote:

Control: reassign -1 yaboot-installer 1.1.26

On Mon, 2013-07-22 at 00:38 +0400, Pavel Fedin wrote:
[...]

   So,  it's  not  kernel's  fault. It seems to be installer fault which
does  not generate correct vmlinuz image when not using separate /boot
partition.  vmlinux,  i  know,  is another thing. It's a plain image
meant to be ran from GRUB or yaboot. It cannot be run from OFW.
   So,  we  can  close  this,  probably with a notification to Installer
guys.


There is no need to close it.  I'm reassigning to the relevant part of
the installer.




The particular partition/file-system layout reported in this bug report
cannot work.

This platform does not have a boot loader at all.


Sorry, I misunderstood.

[...]

Installer correctly creates ext2 boot partition and ext4 root partition.

[...]

Then how did this go wrong?



User did not let installer to create default partition layout but 
manually created incorrect one, or installed on a previously created 
partitions and used ext4 and ext3 file-systems.


Milan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#691906: ITA: avra -- Assembler for Atmel AVR microcontrollers

[Milan Kupcevic]

Control: retitle -1 ITA: avra -- Assembler for Atmel AVR microcontrollers
Control: owner -1 !


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#332227: partconf: Exclude CD/DVD drives from partition search

[Milan Kupcevic]

Control: reassign -1 partconf
Control: tag -1 +wheezy +pending
Control: severity -1 serious


Hi Cyril,

Patch [0] supplied by Frank Fegert fixes this bug. Can we push partconf
1.41 with this fix in Wheezy r1? It will allow installation of Debian on
VIOS virtual drives in LPAR's of IBM Power machines.

Milan

[0] http://lists.gnu.org/archive/html/bug-parted/2013-02/msg7.html



signature.asc
Description: OpenPGP digital signature

Bug#517396: cdimage.debian.org: Lenny ppc netinstall cd misses grub-of

[Milan Kupcevic]

Just for the record: wheezy installs fine on Pegasos II machines,
without grub.

Milan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#702125: 'Invalid device' error on reboot after installation on YDL PowerStation

[Milan Kupcevic]

Package: installation-reports
Severity: important

-- Package-specific info:

Boot method: CD
Image version: official netinst wheezy RC1 for powerpc
Date: Sat Mar  2 16:13:10 EST 2013

Machine: Quad-Core YDL PowerStation
Partitions: 

  Partition Table for /dev/sda
  
   ---Starting  Ending-Start Number of
   # Flags Head Sect  Cyl   ID  Head Sect  Cyl SectorSectors
  -- -   -    - --- ---
   1  0x80   641 0 0x41  127   32 32048   14336
   2  0x0001 4 0x83   63   32 33554   16384   137422848
   3  0x00  127   31 33554 0x05  127   32 35002   137441278 5931010
   4  0x0000 0 0x0000 0   0   0
   5  0x0001 33555 0x82  127   32 35002   2 5931008


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[E]

Comments/Problems:

The installation itself went with no errors, but on reboot I've got this error
message:

  Welcome to yaboot version 1.3.16
  Enter help to get some basic usage information
  boot: Linux
  Please wait, loading kernel...
  /ht/pci@1/obsidian@1/scsi@0/sd@0,0:2,/boot/vmlinux: Unable to open file, 
Invalid device
  boot:


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION=Debian GNU/Linux installer
DISTRIB_RELEASE=7.0 (wheezy) - installer build 20130211
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian 3.2.0-4-powerpc64 #1 SMP Debian 3.2.35-2 ppc64 GNU/Linux
lspci -knn: :f0:0b.0 PCI bridge [0604]: Apple Inc. CPC945 PCIe Bridge 
[106b:005b]
lspci -knn: :f1:00.0 VGA compatible controller [0300]: Advanced Micro 
Devices [AMD] nee ATI RV535 [Radeon X1650 Series] [1002:71c7] (rev 9e)
lspci -knn: Subsystem: PC Partner Limited Device [174b:0840]
lspci -knn: :f1:00.1 Display controller [0380]: Advanced Micro Devices 
[AMD] nee ATI RV535 [Radeon X1650 Series] [1002:71e7] (rev 9e)
lspci -knn: Subsystem: PC Partner Limited Device [174b:0841]
lspci -knn: 0001:00:01.0 PCI bridge [0604]: Broadcom BCM5780 [HT2000] PCI-X 
bridge [1166:0130] (rev b0)
lspci -knn: 0001:00:02.0 PCI bridge [0604]: Broadcom BCM5780 [HT2000] PCI-X 
bridge [1166:0130] (rev b0)
lspci -knn: 0001:00:03.0 PCI bridge [0604]: Broadcom BCM5780 [HT2000] 
PCI-Express Bridge [1166:0132] (rev b0)
lspci -knn: 0001:00:04.0 PCI bridge [0604]: Broadcom BCM5780 [HT2000] 
PCI-Express Bridge [1166:0132] (rev b0)
lspci -knn: 0001:00:05.0 PCI bridge [0604]: Broadcom BCM5780 [HT2000] 
PCI-Express Bridge [1166:0132] (rev b0)
lspci -knn: 0001:00:06.0 PCI bridge [0604]: Broadcom BCM5780 [HT2000] 
PCI-Express Bridge [1166:0132] (rev b0)
lspci -knn: 0001:00:07.0 PCI bridge [0604]: Advanced Micro Devices [AMD] 
AMD-8111 PCI [1022:7460] (rev 07)
lspci -knn: 0001:00:08.0 ISA bridge [0601]: Advanced Micro Devices [AMD] 
AMD-8111 LPC [1022:7468] (rev 05)
lspci -knn: 0001:00:08.1 IDE interface [0101]: Advanced Micro Devices [AMD] 
AMD-8111 IDE [1022:7469] (rev 03)
lspci -knn: Kernel driver in use: pata_amd
lspci -knn: 0001:01:01.0 RAID bus controller [0104]: IBM Obsidian chipset SCSI 
controller [1014:02bd] (rev 01)
lspci -knn: Subsystem: IBM Device [1014:02c1]
lspci -knn: Kernel driver in use: ipr
lspci -knn: 0001:02:04.0 Ethernet controller [0200]: Broadcom Corporation 
NetXtreme BCM5780 Gigabit Ethernet [14e4:166a] (rev 10)
lspci -knn: Subsystem: IBM Device [1014:0329]
lspci -knn: Kernel driver in use: tg3
lspci -knn: 0001:02:04.1 Ethernet controller [0200]: Broadcom Corporation 
NetXtreme BCM5780 Gigabit Ethernet [14e4:166a] (rev 10)
lspci -knn: Subsystem: IBM Device [1014:0329]
lspci -knn: Kernel driver in use: tg3
lspci -knn: 0001:05:00.0 PCI bridge [0604]: Texas Instruments 
XIO2000(A)/XIO2200A PCI Express-to-PCI Bridge [104c:8231] (rev 03)
lspci -knn: 0001:06:01.0 USB controller [0c03]: NEC Corporation USB [1033:0035] 
(rev 43)
lspci -knn: Subsystem: NEC Corporation USB [1033:0035]
lspci -knn: Kernel driver in use: ohci_hcd
lspci -knn: 0001:06:01.1 USB controller [0c03]: NEC Corporation USB [1033:0035] 
(rev 43)
lspci -knn:

Bug#702125: 'Invalid device' error on reboot after installation on YDL PowerStation

[Milan Kupcevic]

Control: reassign -1 yaboot-installer 1.1.25
Control: tag -1 wheezy pending


On 03/02/2013 05:45 PM, Milan Kupcevic wrote:
 
   Welcome to yaboot version 1.3.16
   Enter help to get some basic usage information
   boot: Linux
   Please wait, loading kernel...
   /ht/pci@1/obsidian@1/scsi@0/sd@0,0:2,/boot/vmlinux: Unable to open file, 
 Invalid device
   boot:
 
 

This bug was fixed in yaboot-installer 1.1.26.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#604134: partman-base: Makes MacOS 9 incompatible partition table

[Milan Kupcevic]

Control: reassign -1 installation-guide-powerpc
Control: tag -1 pending

Documented in Debian Installation Guide, sections Pre-Partitioning for
Multi-Boot Systems and Mac OS X Partitioning.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Milan Kupcevic]

On 02/06/2013 10:38 AM, Daniel Baumann wrote:
 On 02/06/2013 12:55 AM, Don Armstrong wrote:
 Is it the intention of the Release Managers not to accept a newer
 version of syslinux into wheezy? [That is, if the CTTE were to decide
 to require some fix to d-i, we'd also have to override the RMs?]
 
 jftr, i never did nor intended to ask for having syslinux 5 in wheezy.
 what i care about is having it in unstable (for reasons said earlier).
 

Well, the d-i development is happening in sid. Therefore, this upload
disrupted the development process of syslinux dependent d-i components
that have to end up, but are not yet in wheezy.

Milan




signature.asc
Description: OpenPGP digital signature

Bug#629492: Installing on dual-processor PowerPC system (ex. QuickSilver PowerMac G4) installs non-SMP kernel

[Milan Kupcevic]

On 12/20/2012 05:50 AM, Cyril Brulebois wrote:
 reopen 629492
 found 629492 1.129
 thanks
 
 Hi Milan,
 
 Milan Kupcevic mi...@physics.harvard.edu (06/11/2012):
 reassign 629492 base-installer
 tags + pending
 thanks
 
 diff --git a/debian/changelog b/debian/changelog
 index 7712e5e..c015a71 100644
 --- a/debian/changelog
 +++ b/debian/changelog
 @@ -1,3 +1,9 @@
 +base-installer (1.129) UNRELEASED; urgency=low
 +
 +  * Properly recognize PowerPC SMP machines. Closes: #629492
 +
 + -- Milan Kupcevic mi...@physics.harvard.edu  Tue, 06 Nov 2012 11:21:07 
 -0500
 +
  base-installer (1.128) unstable; urgency=low
  
* Add support for armhf/vexpress.
 diff --git a/kernel/powerpc.sh b/kernel/powerpc.sh
 index d8f09d0..b2b9b93 100644
 --- a/kernel/powerpc.sh
 +++ b/kernel/powerpc.sh
 @@ -29,7 +29,7 @@ arch_check_usable_kernel () {
  }
  
  arch_get_kernel () {
 -CPUS=$(grep -ci ^processor $CPUINFO) || CPUS=1
 +CPUS=$(ls /proc/device-tree/cpus/ | grep -ci @[0-9]) || CPUS=1
  if [ $CPUS ]  [ $CPUS -gt 1 ]  \
 [ $1 != powerpc64 ]  [ $1 != prep ] ; then
  SMP=-smp
 
 this was merged into base-installer 1.129, and seems to be responsible
 for the build failure, in the test suite:
 
 FAIL powerpc/powermac_newworld.test arch_get_kernel want 
 'linux-image-powerpc', got 'linux-image-powerpc-smp linux-image-powerpc'
 powerpc: 113 passes, 1 failures.
 
 (https://buildd.debian.org/status/fetch.php?pkg=base-installerarch=powerpcver=1.129stamp=1355061770)
 
 It looks to me like this is just a matter of registering the smp
 flavour as one of the possible value for kernel-2.6 in
 kernel/tests/powerpc/powermac_newworld.test (it's already known as a
 usable flavour anyway), but a confirmation would be nice.
 

Hi Cyril,

The trouble was that there was no support for this kind of processor(s)
detection in the test suite. I just did a commit to base-installer with
test suite support for Open Firmware /cpus directory and added a smp
test. Now the package builds fine and passes all tests in my pbuilder.

M








signature.asc
Description: OpenPGP digital signature

Bug#695058: NO SIGNAL monitor problem..

[Milan Kupcevic]

On 12/03/2012 04:28 PM, Jack Wilborn wrote:
 I forgot to add that I have an 'NVIDIA GeForce card.  I wonder if the
 change to a VGA display via a cable change is part of the problem.  I
 also wonder if there is some way to get control of the machine before it
 completes the restart or boot.  It responds to CTL-ALT-DEL keys and
 reboots, but is there any other combination that will just give me
 control in a command line?

If it is a dual head graphic card try to connect the monitor to the
other connector.

There may be a phantom TV port on this card (with no actual TV connector
on it) which gets chosen as the output. You can disable the TV part by
passing video=TV-1:d or video=TV-2:d to kernel. You can add these
options to append field in yaboot.conf

Example:

image=/boot/vmlinux
label=Linux
read-only
initrd=/boot/initrd.img
append=video=TV-1:d



Boot the machine using install DVD. On boot prompt type:

 rescue64

choose the apropriate options until you get the Enter rescue mode
screen, then chose your root partition and choose to execute shell in
the root filesystem.

You will have the familiar command line environment.

You can edit yaboot.conf using vi or nano to add wanted options to
append field.

You can install openssh-server with intention to log into the machine
using ssh after reboot.

Type exit, and choose reboot.


Milan



signature.asc
Description: OpenPGP digital signature

Bug#629492: Installing on dual-processor PowerPC system (ex. QuickSilver PowerMac G4) installs non-SMP kernel

[Milan Kupcevic]

reassign 629492 base-installer
tags + pending
thanks
diff --git a/debian/changelog b/debian/changelog
index 7712e5e..c015a71 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+base-installer (1.129) UNRELEASED; urgency=low
+
+  * Properly recognize PowerPC SMP machines. Closes: #629492
+
+ -- Milan Kupcevic mi...@physics.harvard.edu  Tue, 06 Nov 2012 11:21:07 -0500
+
 base-installer (1.128) unstable; urgency=low
 
   * Add support for armhf/vexpress.
diff --git a/kernel/powerpc.sh b/kernel/powerpc.sh
index d8f09d0..b2b9b93 100644
--- a/kernel/powerpc.sh
+++ b/kernel/powerpc.sh
@@ -29,7 +29,7 @@ arch_check_usable_kernel () {
 }
 
 arch_get_kernel () {
-	CPUS=$(grep -ci ^processor $CPUINFO) || CPUS=1
+	CPUS=$(ls /proc/device-tree/cpus/ | grep -ci @[0-9]) || CPUS=1
 	if [ $CPUS ]  [ $CPUS -gt 1 ]  \
 	   [ $1 != powerpc64 ]  [ $1 != prep ] ; then
 		SMP=-smp

Bug#692156: Wheezy upgrade. No text, no icons and no menus. PowerPC GeForce FX 5200 Ultra

[Milan Kupcevic]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.1-3
Severity: important

After wheezy/testing upgrade, icons and text are no longer displayed in X. 
Upgrade history log is attached.

M


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Jun 27 15:51 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 2052584 Sep 30 09:23 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
:f0:10.0 VGA compatible controller [0300]: NVIDIA Corporation NV34 [GeForce 
FX 5200 Ultra] [10de:0321] (rev a1)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 3.2.0-3-powerpc64 (Debian 3.2.23-1) 
(debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 SMP 
Mon Jul 23 08:03:56 UTC 2012

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 24069 Jul 18 11:56 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 21725 Nov  2 13:23 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[19.340] 
X.Org X Server 1.12.4
Release Date: 2012-08-27
[19.340] X Protocol Version 11, Revision 0
[19.340] Build Operating System: Linux 2.6.32-5-powerpc64 ppc Debian
[19.340] Current Operating System: Linux milan-power-dev 3.2.0-3-powerpc64 
#1 SMP Mon Jul 23 08:03:56 UTC 2012 ppc64
[19.340] Kernel command line: 
root=UUID=30ddf11f-3200-4d7b-8ed9-86eef49f76ea ro 
[19.340] Build Date: 30 September 2012  01:13:33PM
[19.340] xorg-server 2:1.12.4-1 (Julien Cristau jcris...@debian.org) 
[19.340] Current version of pixman: 0.26.0
[19.340]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[19.340] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[19.340] (==) Log file: /var/log/Xorg.0.log, Time: Fri Nov  2 13:23:04 
2012
[19.385] (==) Using system config directory /usr/share/X11/xorg.conf.d
[19.402] (==) No Layout section.  Using the first Screen section.
[19.402] (==) No screen section available. Using defaults.
[19.402] (**) |--Screen Default Screen Section (0)
[19.402] (**) |   |--Monitor default monitor
[19.404] (==) No monitor specified for screen Default Screen Section.
Using a default monitor configuration.
[19.404] (==) Automatically adding devices
[19.404] (==) Automatically enabling devices
[19.473] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
[19.473]Entry deleted from font path.
[19.591] (WW) The directory 
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType does not exist.
[19.591]Entry deleted from font path.
[19.591] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[19.591] (==) ModulePath set to /usr/lib/xorg/modules
[19.591] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[19.601] (II) Loader magic: 0x2091c574
[19.641] (II) Module ABI versions:
[19.641]X.Org ANSI C Emulation: 0.4
[19.641]X.Org Video Driver: 12.1
[19.641]X.Org XInput driver : 16.0
[19.641]X.Org Server Extension : 6.0
[19.643] (--) PCI:*(0:240:16:0) 10de:0321:10de:0010 rev 161, Mem @ 
0x9100/16777216, 0x9800/134217728, BIOS @ 0x/131072
[19.643] (II) LoadModule: extmod
[19.963] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
[19.982] (II) Module extmod: vendor=X.Org Foundation
[19.982]compiled for 1.12.4, module version = 1.0.0
[19.982]Module class: X.Org Server Extension
[19.982]ABI class: X.Org Server Extension, version 6.0
[19.982] (II) Loading extension SELinux
[19.982] (II) Loading extension MIT-SCREEN-SAVER
[19.982] (II) Loading extension XFree86-VidModeExtension
[19.982] (II) Loading extension XFree86-DGA
[19.982] (II) Loading extension DPMS
[19.982] (II) Loading extension XVideo
[19.982] (II) Loading extension XVideo-MotionCompensation
[19.983] (II) Loading extension X-Resource
[19.983] (II) LoadModule: dbe
[19.983] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
[19.998] (II) Module dbe: vendor=X.Org Foundation
[19.998]compiled for 1.12.4, module version = 1.0.0
[19.998]Module class: X.Org Server Extension
[19.999]ABI class: 

Bug#692156: Wheezy upgrade. No text, no icons and no menus. PowerPC GeForce FX 5200 Ultra

[Milan Kupcevic]

On 11/02/2012 02:54 PM, Debian Bug Tracking System wrote:
 
 If you wish to submit further information on this problem, please
 send it to 692...@bugs.debian.org.
 

Even though there are no menus, icons and text in X, I can start xterm
by pressing alt+F2 and typing 'xterm'. Text is displayed fine inside the
xterm window. 3D rendering seems to work fine. Gears of glxgears are
displayed perfectly well. It renders 189 FPS in full screen.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#692156: Wheezy upgrade. No text, no icons and no menus. PowerPC GeForce FX 5200 Ultra

[Milan Kupcevic]

On 11/02/2012 03:30 PM, Sven Joachim wrote:
 On 2012-11-02 20:19 +0100, Milan Kupcevic wrote:

 Even though there are no menus, icons and text in X, I can start xterm
 by pressing alt+F2 and typing 'xterm'. Text is displayed fine inside the
 xterm window. 3D rendering seems to work fine. Gears of glxgears are
 displayed perfectly well. It renders 189 FPS in full screen.
 
 Even though glxgears works fine, the 3D driver is known to cause severe
 display corruption on GeForce FX 5200¹.  Does it help to disable it?
 E.g. run echo LIBGL_ALWAYS_SOFTWARE=1  /etc/environment and restart
 your display manager to do so.
 

No. It does not help. Text, icons and menus are still not displayed at
all. LIBGL_ALWAYS_SOFTWARE=1 degraded 3D rendering performance to 13 FPS
in full screen.

Just want to note that I had working wheezy desktop machine which got
unusable after 'apt-get upgrade'. Can we get the same default
functionality we had before the upgrade? It was running fine with Gnome
Classic, but now it does not.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#691264: grub-installer: Allow grub installation on IBM Power machines

[Milan Kupcevic]

tags 691264 pending
thanks

On 10/23/2012 02:32 PM, Lennart Sorensen wrote:
 On Tue, Oct 23, 2012 at 02:03:46PM -0400, Milan Kupcevic wrote:
 Partitioning recipe for IBM Power machines already creates PReP
 partition for yaboot. If we do check for PReP partition in addition to
 /boot/grub to allow grub installer it will make grub the default
 bootloader on IBM Power machines for wheezy.

Actually, we can enable grub-installer on IBM Power machines in wheezy.
Yaboot-installer will stay the default option because it has higher
menu-item priority. Grub-installer will become an optional item that
user can choose in expert installation mode. In this case the current
partitioning recipe will work for grub, too.


 This would be great if we are sure that d-i installs grub with no
 issues. I did not test it, so I'm not quite sure.
 
 It does seem a bit late for wheezy.  And at least yaboot now seems to
 be a version that might actually work.  I seem to recall some issues
 with ofpathname, but I can't quite remember what they were right now or
 whether they were fixed or not.  A quick check says that yes indeed in
 wheezy the ofpathname issue (bug 607001) was fixed.
 
 Actually given grub is 1.99 in wheezy I think it is safe to say it
 won't work in a number of cases.  2.00 fixed some endianess issues with
 software raid among other things that matter to powerpc, which is why
 I am running grub 2.00 and not 1.99 now.  The older versions were OK
 with the old mdraid format, but not the 1.x format which is of course
 now the default in debian's installer.
 

diff --git a/debian/changelog b/debian/changelog
index 204cc11..cf478cd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,8 +2,9 @@ grub-installer (1.83) UNRELEASED; urgency=low
 
   * Allow grub installation on PowerPC machines if /boot/grub partition
 is present. Closes: #664128
+  * Allow grub installation on IBM Power machines. Closes: #691264
 
- -- Milan Kupcevic mi...@physics.harvard.edu  Mon, 22 Oct 2012 17:39:07 -0400
+ -- Milan Kupcevic mi...@physics.harvard.edu  Wed, 24 Oct 2012 09:22:28 -0400
 
 grub-installer (1.82) unstable; urgency=low
 
diff --git a/debian/isinstallable b/debian/isinstallable
index 89fadb7..c86173f 100755
--- a/debian/isinstallable
+++ b/debian/isinstallable
@@ -15,6 +15,8 @@ case $ARCH in
 		exit 1
 	fi
 	;;
+powerpc/chrp|powerpc/chrp_rs6k|powerpc/chrp_ibm|powerpc/cell)
+	;;
 powerpc/*)
 	mount | grep on /target/boot/grub 12 || {
 		log GRUB requires OF bootable partition mounted at /boot/grub on PowerPC systems
diff --git a/grub-installer b/grub-installer
index 7056f11..d709de0 100755
--- a/grub-installer
+++ b/grub-installer
@@ -225,6 +225,8 @@ bootfstype=$(findfstype /boot)
 [ -n $bootfstype ] || bootfstype=$(findfstype /)
 
 case $ARCH in
+powerpc/chrp|powerpc/chrp_rs6k|powerpc/chrp_ibm|powerpc/cell)
+;;
 powerpc/*)
   offs=$(findfs /boot/grub)
   [ -n $offs ] || error GRUB requires that the OF partition is mounted in /boot/grub 12


signature.asc
Description: OpenPGP digital signature

Bug#691216: iBook v2 G3, 800MHZ not supported?

[Milan Kupcevic]

On 10/22/2012 10:57 PM, tsch...@nexgo.de wrote:
 Package: installation-reports
 
 Boot method: netinst : CD (external drive), root directory (first disk HFS+) 
 and TFTP
 Image versions : 
 1.) debian-wheezy-DI-b3-powerpc-netinst.iso, and 
 2.a) 
 http://ftp.nl.debian.org/debian/dists/squeeze/main/installer-powerpc/current/images/powerpc/netboot/
  and 
 2.b) Debian GNU/Linux 6.0.6 Squeeze - Official powerpc DVD Binary-1 
 20120929-17:11 (chksums OK) 
 and 
 3.) files fron netinst : lenny  (5.10 for ppc)
 
 Date: 22.10.2012 - 23.10.2012
 
 Machine: iBook v2 G3, 800MHZ, FW, USB, RJ11, RJ45, 384 MB RAM, internal 
 cd-rom defect, OSX 10.3.9 (on second partition).
 Processor: G3, 800MHZ
 Memory: 384 MB SDRAM
 Partitions: 
 /dev/disk0s10 (root directory (first disk HFS+))
 /dev/disk0s10 (OSX)
 pdisk -dump :
 1: @ 64 for 23, type = 0x1
 2: @ 120 for 36, type = 0x
 3: @ 176 for 21, type = 0x701
 4: @ 232 for 34, type = 0xf8ff
 
 
 Output of lspci -knn (or lspci -nn):
 
 Base System Installation Checklist:
 [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
 
 Initial boot:   [E]
 Detect network card:[ ]
 Configure network:  [ ]
 Detect CD:  [ ]
 Load installer modules: [ ]
 Detect hard drives: [ ]
 Partition hard drives:  [ ]
 Install base system:[ ]
 Clock/timezone setup:   [ ]
 User/password setup:[ ]
 Install tasks:  [ ]
 Install boot loader:[ ]
 Overall install:[ ]
 
 Comments/Problems:
 after two lines of boot a No trespassing sign appears vmlinux-files maybe 
 corrupted/not adopted for G3
 No Idea, I installed some Linux (ubuntu some years ago without problems 
 (external CD-Rom activated via OpenFirmware)) 
 
 
 Thomas Schenk
 
 

Try to start wheezy installer from an external FireWire CD/DVD drive or
a USB memory stick. For more insights see:

http://lists.debian.org/503bee2b.10...@physics.harvard.edu

and

http://lists.debian.org/4fdd55cc.7020...@physics.harvard.edu


Milan




signature.asc
Description: OpenPGP digital signature

Bug#664128: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot

[Milan Kupcevic]

On 10/23/2012 09:52 AM, Daniel Kahn Gillmor wrote:
 On 10/22/2012 05:55 PM, Milan Kupcevic wrote:
 We can allow d-i grub installation on powerpc machines for wheezy, but
 not make it default.
 
  [...]
 
 Manual creation of the appropriate partition in d-i (/boot/grub) will
 enable grub installation in wheezy d-i. Thus, we will be able to
 experiment with d-i grub installation on powerpc machines.
 
 ok, this sounds like a good step to me.  Are you saying this is present
 in the current wheezy beta3 ?
 


No. It will eventually hit the daily builds soon. See attachment.


Milan



commit cf2fc86abf0fd34963afb49047c21e94a2cde40e
Author: Milan Kupcevic mi...@physics.harvard.edu
Date:   Mon Oct 22 17:46:06 2012 -0400

Allow grub installation on PowerPC machines

* Allow grub installation on PowerPC machines if /boot/grub partition
  is present. Closes: #664128

diff --git a/debian/changelog b/debian/changelog
index 9105cdb..204cc11 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+grub-installer (1.83) UNRELEASED; urgency=low
+
+  * Allow grub installation on PowerPC machines if /boot/grub partition
+is present. Closes: #664128
+
+ -- Milan Kupcevic mi...@physics.harvard.edu  Mon, 22 Oct 2012 17:39:07 -0400
+
 grub-installer (1.82) unstable; urgency=low
 
   [ Updated translations ]
diff --git a/debian/isinstallable b/debian/isinstallable
index e66bac1..89fadb7 100755
--- a/debian/isinstallable
+++ b/debian/isinstallable
@@ -15,11 +15,11 @@ case $ARCH in
 		exit 1
 	fi
 	;;
-powerpc/chrp_pegasos)
-	;;
 powerpc/*)
-	log GRUB not yet usable on PowerPC systems other than Pegasos/Efika
-	exit 1
+	mount | grep on /target/boot/grub 12 || {
+		log GRUB requires OF bootable partition mounted at /boot/grub on PowerPC systems
+		exit 1
+	}
 	;;
 mipsel/loongson-2f)
 	;;


signature.asc
Description: OpenPGP digital signature

Bug#664128: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot

[Milan Kupcevic]

clone 664128 -1
retitle -1 Allow grub installation on IBM Power machines
thanks

On 10/23/2012 11:36 AM, Lennart Sorensen wrote:
 On Tue, Oct 23, 2012 at 10:18:00AM -0400, Milan Kupcevic wrote:
 On 10/23/2012 09:52 AM, Daniel Kahn Gillmor wrote:
 On 10/22/2012 05:55 PM, Milan Kupcevic wrote:
 We can allow d-i grub installation on powerpc machines for wheezy, but
 not make it default.

  [...]

 Manual creation of the appropriate partition in d-i (/boot/grub) will
 enable grub installation in wheezy d-i. Thus, we will be able to
 experiment with d-i grub installation on powerpc machines.

 ok, this sounds like a good step to me.  Are you saying this is present
 in the current wheezy beta3 ?



 No. It will eventually hit the daily builds soon. See attachment.


 Milan



 
 commit cf2fc86abf0fd34963afb49047c21e94a2cde40e
 Author: Milan Kupcevic mi...@physics.harvard.edu
 Date:   Mon Oct 22 17:46:06 2012 -0400

 Allow grub installation on PowerPC machines
 
 * Allow grub installation on PowerPC machines if /boot/grub partition
   is present. Closes: #664128

 diff --git a/debian/changelog b/debian/changelog
 index 9105cdb..204cc11 100644
 --- a/debian/changelog
 +++ b/debian/changelog
 @@ -1,3 +1,10 @@
 +grub-installer (1.83) UNRELEASED; urgency=low
 +
 +  * Allow grub installation on PowerPC machines if /boot/grub partition
 +is present. Closes: #664128
 +
 + -- Milan Kupcevic mi...@physics.harvard.edu  Mon, 22 Oct 2012 17:39:07 
 -0400
 +
  grub-installer (1.82) unstable; urgency=low
  
[ Updated translations ]
 diff --git a/debian/isinstallable b/debian/isinstallable
 index e66bac1..89fadb7 100755
 --- a/debian/isinstallable
 +++ b/debian/isinstallable
 @@ -15,11 +15,11 @@ case $ARCH in
  exit 1
  fi
  ;;
 -powerpc/chrp_pegasos)
 -;;
  powerpc/*)
 -log GRUB not yet usable on PowerPC systems other than Pegasos/Efika
 -exit 1
 +mount | grep on /target/boot/grub 12 || {
 +log GRUB requires OF bootable partition mounted at /boot/grub 
 on PowerPC systems
 +exit 1
 +}
  ;;
  mipsel/loongson-2f)
  ;;
 
 And that would be wrong.  That is NOT how grub works on IBM powerpc
 machines.  That is true of powermac and possible a few other types.
 
 The IBM OF does NOT support filesystems.  It executes the ELF binary in
 the PReP partition, which can not be mounted.  

IBM Firmware does support filesystems, just not the same filesystems as
Macs and Pegasos. IBM Firmware likes FAT and iso9660, Mac wants HFS,
while Pegasos works with ext2, AFFS, and iso9660.

If you put a bootloader on FAT filesystem you could put other meta
information in /ppc/bootinfo.txt file so that IBM Firmware and other IBM
boot management tools can get full textual description and optionally an
icon of the bootable OS. It would make it possible to dual boot Linux
(GRUB) and AIX while choosing which one you want to boot using standard
IBM tools (ie Multiboot menu). We will see if we want to go this way or
we want to keep resetting firmware variables using '/sbin/nvsetenv' on
Linux and 'bootlist' on AIX when we want to reboot into the other OS.

 grub-install simply dd's
 the grub core image into that partition and that's it.  When creating the
 image it passes and argument to the grub-mkimage to set which partition
 to look at to get the grub modules and config files since in the IBM
 case it won't be the boot partition (since it has no filesystem).
 

Yaboot installer installs yaboot on IBM Power machines exactly the same way.

 So please don't make such a wrong change.  You will just make life harder
 for IBM users.

This will not make life harder nor easier for IBM users. Grub
installation was not offered on IBM Power machines by d-i until now, and
will not be offered after this particular change.

 
 The correct thing to check for on an IBM is that a PReP boot type
 partition exists.  That is all.  It can not be mounted.
 
 For example:
 
 root@rceng03:~# parted
 GNU Parted 2.3
 Using /dev/sda
 Welcome to GNU Parted! Type 'help' to view a list of commands.
 (parted) print
 Model: IBM MBE2147RC (scsi)
 Disk /dev/sda: 147GB
 Sector size (logical/physical): 512B/512B
 Partition Table: msdos
 
 Number  Start   End SizeType File system  Flags
  1  1049kB  8389kB  7340kB  primary   boot, prep
  2  8389kB  10.0GB  10.0GB  primary   raid
  3  10.0GB  147GB   137GB   primary   raid
 
 In this case the setup is RAID1 across sd[abc]2 for / and RAID5 across
 sd[abc]3 for LVM.
 
 grub is happily installed to /dev/sda1 (and sdb1 and sdc1 as well for
 redundancy) using grub-install.  This works.
 

Thank you for providing information about your experience with grub on
IBM Power machines. After wheezy release we will go forward with
transition from yaboot to grub. Your experience will be valuable for
further discussion about d-i issues

Bug#664128: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot

[Milan Kupcevic]

tags 691264 -pending
thanks

On 10/23/2012 01:33 PM, Lennart Sorensen wrote:
 On Tue, Oct 23, 2012 at 01:06:06PM -0400, Milan Kupcevic wrote:
 IBM Firmware does support filesystems, just not the same filesystems as
 Macs and Pegasos. IBM Firmware likes FAT and iso9660, Mac wants HFS,
 while Pegasos works with ext2, AFFS, and iso9660.

 If you put a bootloader on FAT filesystem you could put other meta
 information in /ppc/bootinfo.txt file so that IBM Firmware and other IBM
 boot management tools can get full textual description and optionally an
 icon of the bootable OS. It would make it possible to dual boot Linux
 (GRUB) and AIX while choosing which one you want to boot using standard
 IBM tools (ie Multiboot menu). We will see if we want to go this way or
 we want to keep resetting firmware variables using '/sbin/nvsetenv' on
 Linux and 'bootlist' on AIX when we want to reboot into the other OS.
 
 I have never got it to work with a fat filesystem.  I have tried on a
 p710 and a p520.  Maybe it worked on older ones.
 
 Yaboot installer installs yaboot on IBM Power machines exactly the same way.

 This will not make life harder nor easier for IBM users. Grub
 installation was not offered on IBM Power machines by d-i until now, and
 will not be offered after this particular change.
 
 Well it looks like it will if you happen to create the /boot/grub
 partition, except it won't work that way.  So the error message will
 tell you to do something that won't work.

Partitioning recipe for IBM Power machines already creates PReP
partition for yaboot. If we do check for PReP partition in addition to
/boot/grub to allow grub installer it will make grub the default
bootloader on IBM Power machines for wheezy.

This would be great if we are sure that d-i installs grub with no
issues. I did not test it, so I'm not quite sure.

 
 Thank you for providing information about your experience with grub on
 IBM Power machines. After wheezy release we will go forward with
 transition from yaboot to grub. Your experience will be valuable for
 further discussion about d-i issues on IBM Power machines.
 
 I will certainly try to help test it at that time.
 
 The way I am using it is what grub-install expects on IBM powerpc at
 this time.
 
 I would love to see a working example where you use FAT on an IBM powerpc,
 because I haven't found any reference to it in any of the documentation
 or anywhere else, and it has never worked when I tried it.  The
 openfirmware syntax where you specify a file on a filesystem simply
 never worked on either machine I have here.  Seems to work fine on
 Macs though.
 
 I will look up the bootinfo.txt though.  Maybe that will provide some
 hints.  Could make grub simpler to work with.
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#664128: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot

[Milan Kupcevic]

On 03/15/2012 03:05 PM, Daniel Kahn Gillmor wrote:
 
 Please have debian-installer on powerpc default to grub-ieee1275
 instead of yaboot.
 

We can allow d-i grub installation on powerpc machines for wheezy, but
not make it default.

 Differences in the setup:
 
 yaboot expects a ~1MiB bootstrap partition in an apple-formatted disk
 that is openfirmware-visible.  This partition isn't mounted on the
 running host, but is managed/updated when the admin runs ybin.
 
 grub-ieee1275 expects a larger bootstrap partition (~10MiB should be
 fine) in an apple-formatted disk that is openfirmware-visible.  This
 partition should have a plain HFS (not HFS+) filesystem on it, and
 should be mounted by the host at /boot/grub.
 

To transition fully to grub on powerpc machines we will have to change
partitioning recipes for CHRP IBM, CHRP Pegasos and NewWorld Mac
machines. This will have to wait for jessie.

Manual creation of the appropriate partition in d-i (/boot/grub) will
enable grub installation in wheezy d-i. Thus, we will be able to
experiment with d-i grub installation on powerpc machines.

 Users of grub-ieee1275 probably therefore also want to have hfsprogs
 installed on their system for /sbin/fsck.hfs so that routine filesystem
 checks at boot time can proceed for the filesystem mounted at
 /boot/grub.

I agree.

 
 I'm also happy to test powerpc d-i images that use grub-ieee1275 if you
 need testers.

Do you have access to any IBM Power machines?


Milan



signature.asc
Description: OpenPGP digital signature

Bug#664128: grub-installer: Allow grub installation on powerpc machines if /boot/grub partition is present

[Milan Kupcevic]

clone 664128 -1 -2 -3 -4 -5
reassign 664128 grub-installer
retitle 664128 Allow grub installation on powerpc machines if /boot/grub 
partition is present
tags 664128 pending
reassign -1 grub-installer
retitle -1 Provide instruction for Pegasos/Efika users to enable auto-boot in OF
reassign -2 partman-auto
retitle -2 Create OF boot partition and mount it at /boot/grub on CHRP IBM 
machines
reassign -3 partman-auto
retitle -3 Resize current boot partition and mount it at /boot/grub on NewWorld 
Mac machines
reassign -4 partman-auto
retitle -4 Create OF boot partition and mount it at /boot/grub on CHRP 
Pegasos/Efika
retitle -5 Install hfsprogs on powerpc machines by default
thanks


Creating non-exhaustive list of bugs/tasks to transition from yaboot to grub on 
powerpc machines.

Milan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#684265: Still with us

[Milan Kupcevic]

On 09/24/2012 05:04 AM, Rick Thomas wrote:
 
 On Sep 13, 2012, at 2:58 PM, Rick Thomas wrote:
 


 1) It seems likely that adding a udeb for fuse-modules will allow
 os-prober to identify other Linux OS root partitions and get them
 added to the boot-loader config file... But only as long as those
 partitions are not LVM partitions.

 I have not performed definitive experiments to verify either half of
 this assertion, but the evidence so far does point in that direction. 
 When can I expect the udeb for fuse fix to be included in an
 upcoming daily iso?  I'll be happy to test it when it's available.

 
 I tried a test installation with the following:
 
 Debian GNU/Linux testing Wheezy - Official Snapshot amd64 NETINST
  Binary-1 20120923-03:20
 
 which seems to have the necessary module:
 
 $ find /mnt -name '*fuse*' -print
 /mnt/pool/main/f/fuse
 /mnt/pool/main/f/fuse/fuse-udeb_2.9.1-1_amd64.udeb
 /mnt/pool/main/f/fuse/libfuse2_2.9.0-2_amd64.deb
 /mnt/pool/main/f/fuse/libfuse2-udeb_2.9.1-1_amd64.udeb
 /mnt/pool/main/l/linux/fuse-modules-3.2.0-4-amd64-di_3.2.29-1_amd64.udeb
 
 
 However, it still doesn't find the other OS partitions...
 
 They are located in /dev/mapper/monk-root2 and /dev/mapper/monk-root3. 
 The partition being installed to is in /dev/mapper/monk-root.
 
 I'm attaching the (gzipped) installer logs.
 
 Rick
 

Please file a separate debian-installer bug report for problems related
to finding other OS's on LVM partitions.

Milan




signature.asc
Description: OpenPGP digital signature

Bug#684265: Debian Installer 7.0 Beta2 release bug #684265

[Milan Kupcevic]

On 09/13/2012 01:41 AM, Christian PERRIER wrote:
 Quoting Rick Thomas (rbtho...@pobox.com):

 On Sep 12, 2012, at 4:21 PM, Rick Thomas wrote:

 I have not tried running os-prober from the alt-F2 console
 during the install, to see if it gives different results. I'll do
 that and report back.  Any hints of things I should be looking out
 for?

 Here's the stderr/stdout output when os-prober is run in the
 installer environment:

 umount: can't umount /var/lib/os-prober/mount: Invalid argument
 grub-probe: error: no such disk.
 grub-probe: error: no such disk.
 grub-probe: error: no such disk.
 
 Could be something like #686314. Can you try (in the installer) to do
 the workaround found there (loading the fuse module)?
 

Definitely, os-prober needs fuse module to work properly. D-i is trying
to load the fuse module but it is not available in the d-i environment.

Here is d-i log extract:

Sep 11 02:15:31 anna-install: Installing ufs-modules
Sep 11 02:15:31 anna-install: Installing btrfs-modules
Sep 11 02:15:31 anna-install: Installing fuse-modules
Sep 11 02:15:31 os-prober: unknown udeb fuse-modules

When I load the fuse module manually os-prober works fine.

Therefore solution for bug reports 684265, 686314, 686631, 687286 is to
create fuse-modules udeb package. Patch is available here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684265#35

Other problems related to listing other OS's in grub menu, that may or
may not be related to os-prober, are described in bug reports 587397,
603107, 608025, 608219, 609251.

If you see similar problems related to LVM please file a separate bug
report.

Milan




signature.asc
Description: OpenPGP digital signature

Bug#684265: linux: d-i, os-prober need fuse module to detect other OS's

[Milan Kupcevic]

tags 684265 patch
thanks

Debian installer os-prober needs fuse module to look into various
partitions for already installed operating systems.

Patch is attached.

Milan
Index: debian/installer/package-list
===
--- debian/installer/package-list	(revision 19377)
+++ debian/installer/package-list	(working copy)
@@ -332,6 +332,12 @@
  This package contains core modules for the kernel, that will almost 
  always be needed.
 
+Package: fuse-modules
+Depends: kernel-image
+Priority: standard
+Description: FUSE support modules
+ This package contains filesystem in userspace support modules.
+
 Package: acpi-modules
 Depends: kernel-image
 Priority: extra
Index: debian/installer/modules/fuse-modules
===
--- debian/installer/modules/fuse-modules	(revision 0)
+++ debian/installer/modules/fuse-modules	(revision 0)
@@ -0,0 +1 @@
+fuse


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#678066: Proposal to simplify PowerPC CD/DVD boot options

[Milan Kupcevic]

On 08/29/2012 07:58 PM, Rick Thomas wrote:
 
 On Aug 29, 2012, at 4:25 PM, Rick Thomas wrote:
 

 I just tried booting a PowerMac G4 with the Wheezy installer image
 built on 20120826-03:23 (details of where I downloaded it from, etc
 available on request).

 The G4 is a 32-bit machine, but it seems to be offering me the choices
 for a 64 bit machine.

 Before the boot: prompt it said (among other things)
install 64-bit processor (G5 or POWER3/4/5/6/7)
install32   32-bit processor (G4 or earlier)

 and when I entered tab at the boot: prompt I saw the list of options
install   expert  rescue
auto  install32   expert32
rescue32  auto32


At this point you can still type: install32

 If I just hit ret at the boot: prompt it looks like it's trying to
 boot the 64-bit kernel, which (of course) fails on the G4.

 The only unusual thing about this is that I'm booting from a USB stick
 using Open Firmware, rather than from a physical CD-ROM.  Should that
 make any difference?

When you load yaboot binary directly from Open Firmware you are skipping
blessed stage one boot loader script. That is making the difference.

 
 I just tried booting that installer from a physical CD-ROM on the G4.  I
 got the expected (32-bit) messages.
 
 So, I guess booting from a CD sets something in the OF environment that
 isn't being set when booting from a USB stick?
 

By default, PowerPC Macs boot from a CD/DVD drive by loading an Apple
specific blessed file located in an Apple_HFS partition. The blessed
file is a stage one boot loader. It is a file containing Open Firmware
commands that are figuring out whether they run on 32-bit or 64-bit
machine, followed by a boot command that loads yaboot binary while
passing appropriate arguments to it.

If yaboot binary gets loaded without arguments it will offer both 64-bit
and 32-bit options, but default to 64-bit.

 
 Is there a fix for this, or is it an un-common enough use-case to just
 need to be documented as a limitation.
 

The on-screen instructions are correct. Thus, the manual could just say
something like this: When the machine boots, follow the on screen
instruction.


Milan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org