Bug#1069681: less does not escape special characters when outputting the filename
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(&s, +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(&s, +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
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
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
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
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
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
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
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
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
> 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
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.
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/m
Bug#947969: ceph-mgr: indefinite queue growth causing commands to hang
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
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
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
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
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
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&revision=1415 signature.asc Description: OpenPGP digital signature
Bug#941356: less: silently hides formatting characters
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
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
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
> 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&group=avrdude and work with the upstream on the issue. Milan
Bug#909573: avrdude: Doesn't recognise ATtiny2313A
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&group=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
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
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
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
Package: wnpp Severity: wishlist Owner: Milan Kupcevic * Package name: simulide Version : 0.1.5 Upstream Author : Santiago González * 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
Package: wnpp Severity: wishlist Owner: Milan Kupcevic * Package name: simutron Version : 1.0.1 Upstream Author : Santiago González * 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
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
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,
https://anonscm.debian.org/cgit/collab-maint/avrdude.git/commit/?id=777cf870879c9d14190dcce0fdd458283e48d5c2
Bug#824815: Bootloader burning verification error
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 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 +mini328.bootloader.lock_bits
Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color
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
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
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
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
Package: wnpp Severity: wishlist Owner: Milan Kupcevic * Package name: basez Version : 1.0.1 Upstream Author : Milan Kupcevic * 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
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
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&group=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
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&item_id=41854#comment7 [1] https://savannah.nongnu.org/bugs/?func=detailitem&item_id=43338#comment1 signature.asc Description: OpenPGP digital signature
Bug#817133: [Debootloaders-yaboot] Bug#817133: closed by Milan Kupcevic (Bug#819549: fixed in yaboot 1.3.17-2)
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
Package: wnpp Severity: wishlist Owner: Milan Kupcevic * Package name: esptool Version : 0.4.6 Upstream Author : Christian Klippel , * 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
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
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
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
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'
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?
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
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 &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
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 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
Package: wnpp Severity: wishlist Owner: Milan Kupcevic Control: affects -1 yaboot * Package name: e2fslibs1.41-dev Version : 1.41.14 Upstream Author : Theodore Y. Ts'o * 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
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
On Sun, 26 Apr 2015 16:35:29 +0200 Holger Levsen 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
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 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
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
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 !
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
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)
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'
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'
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'
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'
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'
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'
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'
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 [ 10.946
Bug#781936: rootskel (d-i): G5 fans run full speed
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#781935: initramfs-tools: XServe G5 all fans run full speed
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
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#781934: XServe G5: all fans run full speed
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
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 [9.3
Bug#751346: man page for totem-audio-preview
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 +.\" +.\" 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 . +.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
On 09/08/2013 11:21 AM, Vincent Bernat wrote: > ❦ 7 septembre 2013 22:22 CEST, Milan Kupcevic : > >> 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 and ). 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]
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
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
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
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
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
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#604134: partman-base: Makes MacOS 9 incompatible partition table
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#702125: 'Invalid device' error on reboot after installation on YDL PowerStation
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#702125: 'Invalid device' error on reboot after installation on YDL PowerStation
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 -kn
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
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
On 12/20/2012 05:50 AM, Cyril Brulebois wrote: > reopen 629492 > found 629492 1.129 > thanks > > Hi Milan, > > Milan Kupcevic (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 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-installer&arch=powerpc&ver=1.129&stamp=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..
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
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 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
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#692156: Wheezy upgrade. No text, no icons and no menus. PowerPC GeForce FX 5200 Ultra
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
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 ) [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 "" [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: X.Org Serve
Bug#691264: grub-installer: Allow grub installation on IBM Power machines
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 Mon, 22 Oct 2012 17:39:07 -0400 + -- Milan Kupcevic 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" 1>&2 || { 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" 1>&2 signature.asc Description: OpenPGP digital signature
Bug#664128: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot
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
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 >> 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 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" 1>&2 || { >> +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
Bug#664128: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot
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 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 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" 1>&2 || { + 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#691216: iBook v2 G3, 800MHZ not supported?
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: grub-installer: Allow grub installation on powerpc machines if "/boot/grub" partition is present
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#664128: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot
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#684265: Still with us
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
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 -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
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#686218: cdimage.debian.org: booting powerpc netinst installer from USB-stick complains about type (Apple_HFS) of bootstrap partition (wants Apple_bootstrap)
On 08/30/2012 03:31 AM, Rick Thomas wrote: > > On Aug 29, 2012, at 11:30 PM, Milan Kupcevic wrote: > >> On 08/29/2012 08:48 PM, Rick Thomas wrote: >>> >>> When booting the Debian netinst powerpc installer from a USB flash >>> disk you may see a mesage >>>WARNING: Bootstrap partition type is wrong: "Apple_HFS" >>> type should be: "Apple_Bootstrap" >>> >>> This does not occur when booting the same iso from a physical CD-ROM. >>> >>> Ignoring the warning does not seem to cause any problems. >>> >>> Any idea what makes it do that? Can if be fixed? Should it be >>> documented if it can't be fixed? >>> >> >> The warning message is likely coming from Open Firmware. It seems that >> it expects to find a properly partitioned hard drive connected to the >> USB connector you are trying to boot from. It does not expect to find a >> hybrid CD/DVD Apple_HFS partition there. >> >> M > > Is there a way to prepare the USB stick so it will look like what the OF > is expecting? Since it doesn't seem to do any harm, I suppose it's just > a cosmetic bug, but it would be nice if it didn't complain. > We could explore it. We could format a USB stick the same way a bootable hard drive is formatted in PowerPC Macs and see what happens. M -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org