Bug#931195: flash-kernel: Add entry for Olimex A64-Olinuxino
Package: flash-kernel Followup-For: Bug #931195 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 2 months have passed by with this issue solved in git but no release. What is missing for a release to happen? - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl8Fpx8ACgkQLHwxRsGg ASH8Ew/+O8SMz/QFjWAx+3JMjYicg7t+/oB4JqrFLowzG05HwlRIyEknYLOH+sHm /CdmvR+t5f14oA3xekj3zH5FCg/8TlZibEK3AbYNv2KjjfIg46w1dU0jhn3/Z+iH S/VWndmmX50qogr2or++JdMj615LxxZuaw0Swu3pIf+GlTjsswcsX2q2g6hl1BAD oRJzj8D3huCNVuwKB1iWs5Q9Pum9lYzqDdOpJs72w0Wkp8L9ySotQaA+BSRTpV4H xOfXoOKYUS+WAdr8vXtkw5tlalJTAT5mis7CCUxkUmwtfPMue4en7qfojgfHYrGe dqiuUQCuzGylqQEtbyF+GktycuNvloXulM5H+sQCcdXULPNr0o7BmU3xLHjbWYol 1TDPJvfNOHbXlL4kLON6jBNFPJ2Uf3230HELUSL9tNQpVJ9M4tvVe7I8SJEG6Yy0 U4JuiguHQUTXKP8h5NtuipWnqVrzCvT/k7P4MHCa9chTZfa3Wi0cd2ZIFqmfSa45 +65zyrkTCNVGZp83bFpNMqYvjT6jcZ1maFSpXvZblb6pv15pMmfV7MGvjbmyBgUx U6rphI2VY650HAju++YrQkcFHlXYPV1D3cAwBOga6D7dtXzyBMazoBEtf3QNbYf/ 44UQIqfy1oaw/QJ2rcTKPkiw1JyASjP4zTOkUv7wAWlVzw88mbM= =7261 -END PGP SIGNATURE-
Re: "Debian GNU/Linux Installation Guide" needs examples
Quoting Richard Owlett (2020-06-14 12:52:10) > Reading > [https://packages.debian.org/buster/mate-desktop-environment] indicates > that not installing "suggested" will achieve my *specified* goal. [...] > Append "recommends=false" in 2 trials Suggested and recommended packages are different things. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Completely switch graphical installer to fonts-noto?
[ I am not subscribed: please cc me on replies ] Quoting Cyril Brulebois (2020-03-28 18:09:51) > Steve McIntyre (2020-03-28): > > Hey folks, > > > > On Sat, Mar 28, 2020 at 05:52:26PM +0100, Cyril Brulebois wrote: > > >Holger Wansing (2020-03-27): > > >> > > >> So, what's the opinion of the team: is there any interest to move to > > >> fonts-noto? > > > > > >Besides the first topic you mentioned, and the idea of putting all our > > >eggs in the same basket (possibly meaning less maintenance for us, > > >and/or maybe more pressure on the maintainers of a newly-critical > > >component), the big question is what users will think of the changes. > > > > > >I suppose the best way to approach this would be to ask e.g. translators > > >for each language to compare the rendering before/after, and have them > > >tell us what they think (maybe by setting up a poll). I suspect this > > >might be a rather time consuming task… > > > > Maybe just do it, and announce it as a big change for the next alpha > > release? > > This would be an easy way to publish updated installation images for > people to toy with, and compare with the previous alpha. And I think > that'd be a sensible approach (at least that's what I had in mind). > > Gathering the results and drawing a conclusion is what worries me a > little. I understand your concern, and I agree that it makes sense to check with native speakers of the languages involved. My worry was how to make it easy to compare, and I think Holgers image can help with that (I still need to fumble with it to see how best to use it). If I get something working, I will try share it with Debian friends in India to try get a feel for how it might be sensible to proceed more generally. Or maybe I will simply take it one locale at a time, get in touch with each, and have them help evaluate, just as you suggest :-) [ I am not subscribed: please cc me on replies ] - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Completely switch graphical installer to fonts-noto?
[ I am not subscribed: please cc me on replies ] Quoting Jonas Smedegaard (2020-03-28 18:45:56) > Holger Wansing wrote: > > However, I did some tests, and I managed to get a netboot-gtk > > mini.iso image built with only this font packages: > > fonts-android-udeb (apparently needed for CJK languages) > > fonts-noto-unhinted-udeb @Holger: If you can (easily - perhaps you already computed it for above?) provide me a list of the actual fonts used in your experimental build, then I can make a build of fonts-noto targeted experimental where those fonts (except the CJK ones) are added to fonts-noto-hinted-udeb. Then it should be possible (hopefully even relatively easy) to check if size requirements are reasonable. [ I am not subscribed: please cc me on replies ] - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Completely switch graphical installer to fonts-noto?
[ I am not subscribed: please cc me on replies ] Quoting Steve McIntyre (2020-03-28 17:58:54) > On Sat, Mar 28, 2020 at 05:52:26PM +0100, Cyril Brulebois wrote: > >Holger Wansing (2020-03-27): > >> > >> So, what's the opinion of the team: is there any interest to move > >> to fonts-noto? > > > >Besides the first topic you mentioned, and the idea of putting all > >our eggs in the same basket (possibly meaning less maintenance for > >us, and/or maybe more pressure on the maintainers of a newly-critical > >component), the big question is what users will think of the changes. > > > >I suppose the best way to approach this would be to ask e.g. > >translators for each language to compare the rendering before/after, > >and have them tell us what they think (maybe by setting up a poll). I > >suspect this might be a rather time consuming task… > > Maybe just do it, and announce it as a big change for the next alpha > release? Thanks for Cc'im me, Steve - I forgot to mention I am not subscribed. Holger Wansing wrote: > However, I did some tests, and I managed to get a netboot-gtk mini.iso > image built with only this font packages: > fonts-android-udeb (apparently needed for CJK languages) > fonts-noto-unhinted-udeb The CJK fonts are _not_ optimized for embedded use. What I recommend is to switch all _except_ CJK locales to use fonts-noto-hinted-udeb + fonts-noto-unhinted-udeb. That should be far less bloated, and can be reduced further by including only the fonts actually used. The package names for the udeb packages are misleading (only reasons not renaming are a) the annoying delay waiting for NEW processing and b) bothering you installer team folks with adjusting for such rename). Really the two packages contain this: fonts-noto-hinted-udeb: Unhinted fonts actually used by the installer fonts-noto-unhinted-udeb: Unhinted other fonts (including hieroglyphs) Holger Wansing wrote: > I'm unsure, if switching completely to Google fonts (fonts-noto is a > Google project, right?) is what we want, thinking about monopolism... Correct, the Noto project is funded by Google (as mentioned in the package long descriptions). I share your scepticism towards Google in general, but do not recognize any reason for concern here specifically. Maybe if you shared your concerns in more detail, I am happy to reflect on them. [ I am not subscribed: please cc me on replies ] - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#954948: [d-i bullseye alpha2] Sinhala font missing
Quoting Holger Wansing (2020-03-27 11:23:46) > many thanks for the quick fix! You're quite welcome! Since the very purpose of fonts-noto is large coverage and usage in embedded devices (e.g. stripping kerning values), I suspect that it may be beneficial to use also for other locales. Please do tell if there is interest in that, and how I can help there. (I tried in the past on my own, but ran into issues with documented test routines for fonts being obsolete/broken - so I would need a bit of guidance to help) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#929752: Changing quote signs in GPL allowed? [Was: Bug#929752: installation-guide: left quotes in gpl.xml are not correctly rendered in pdf ]
Quoting Holger Wansing (2019-08-06 20:30:56)
> [Adding debian-devel for a bigger audience]
>
>
> Hi,
>
> Holger Wansing wrote:
> > Control: retitle -1 Replace grave accents/single quotes by
> > in gpl.xml
> >
> > Samuel Thibault wrote:
> > > Hello,
> > >
> > > Changwoo Ryu, le jeu. 30 mai 2019 22:22:05 +0900, a ecrit:
> > > > In en/appendix/gpl.xml, ordinary double quotes (") and grave
> > > > accent character (`) are used for left single/double quotes. But
> > > > they are not correctly rendered in pdf.
> > > >
> > > > See the English PDF at
> > > > https://www.debian.org/releases/stable/amd64/install.pdf.en.
> > > > Opening double quotes are rendered as right double quotes. And
> > > > grave accents are rendered just as grave accents, not a left
> > > > single quotes.
> > >
> > > AIUI we should just replace "" and `' in the xml file with
> > > .
>
> I was about to commit these changes, however it came to my mind if
> such changes to the GPL are allowed?
>
> At least the English variant of the GPL is 'official' and is not to be
> changed, so what about changing the quoting signs into
> entities?
Some very narrow interpretation of "not to be changed" disallow making
the text into a PDF at all, as it is not bit-by-bit identical.
GNU GPL-1, GPL-2, and GPL-3 however all permit "verbatim copies" which I
can only interpret as permitting changes to punctuation and whitespace.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#929986: flash-kernel: configfile wrongly handled by both debconf and ucf
Package: flash-kernel Version: 3.99 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Editing by hand the configfile /etc/default/flash-kernel and then running "dpkg-reconfigure flash-kernel" bogusly presents string "quiet" regardless of actual content in the configfile. Pressing enter without editing does _not_ apply "quiet" but does nothing. Editing and pressing enter triggers a ucf tristate dialogue. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlz2uAwACgkQLHwxRsGg ASH78A/+J4cGGKOqlTJEMLSFFbJb9eDB+eiCDrnMYwnUilwuTXZHtZXn0XQJPVMR em5Qk617rC4hyBy0kR8MI/sCRzSlNBo02BF8TRuuFTDyk6frrA/iFC/oyCSmfyL7 Kn4AuL+g9fwPZJllS0GL/aL3tyK16qx1hKss1lnoq57GCRmdtNpKuREEykObIWeZ ndjvJyzWB7TLrW7b4SA3eUzxfpZSX/R3ZveJPaudCTTuehefMFPp+04ECcA9+xxt l2vyYz3FjdXDTJwNkwfBKzzobUAFUEponap0MCYNZcmB8Dk7pJ8rEKET/r6fJH5o Euab3YpcoFoIdOzhVrbJpOXnEv9mbZZWT/CpYKE1KFvnPiSy/+UoX2egaqxI7qJG D0oiHZzhJlVf/KZNaFPgkvXcvqgSCo6uk8LbgFH45w0iQqpsYofOj0HanTLrwto/ G1n9zISGwUqJ9bjXlek4O1hyj/UenGu1UiwnKdbMdZ6sh447c3cZTF9A+8fVs+F5 T7SHScd82+Hic6qWNuD5VDZS0jFUDPI6LOGcSnvHfxLOidJcoHxT/N+yFeM2Bw23 H5XU38aIx3OfnLjK7BhwBGAkUHoKcwBgtcjvkh7036q9p3mCWWOpFra7FdB74GuQ 6sDkdT27yrUK2Q50s8RdmgwWYf3RYy78Pe4Q7o4skM7Y8A5a5yE= =yXrk -END PGP SIGNATURE-
Bug#916822: u-boot-sunxi: A20-OLinuXino-Lime2 Rev. K cannot load linux
control: reassign -1 u-boot-sunxi control: retitle: u-boot-sunxi: A20-OLinuXino-Lime2 Rev. K cannot load linux Reassigning to package u-boot, since (if I read the provided log messages correctly) the failure is in u-boot before even loading linux at all. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#926071: flash-kernel: Please add an entry for Olimex A64 Teres-I
Package: flash-kernel Version: 3.97 Severity: wishlist Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please add below patch to flash-kernel, to support the A64 Teres-I board found in Olimex's Teres-I DIY laptop. Mainline linux 4.16 and newer includes the referenced DTB. Mainline u-boot does not yet support this board, but the 2 known patchsets against mainline u-boot both work fine with the bootscr.uboot-generic script. - Jonas diff --git a/db/all.db b/db/all.db index b97afd4..992ccb9 100644 - --- a/db/all.db +++ b/db/all.db @@ -1280,6 +1280,13 @@ DTB-Id: sun8i-a33-olinuxino.dtb U-Boot-Script-Name: bootscr.sunxi Required-Packages: u-boot-tools +Machine: Olimex A64 Teres-I +Kernel-Flavors: arm64 +DTB-Id: sun50i-a64-teres-i.dtb +Boot-Script-Path: /boot/boot.scr +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + Machine: OMAP4 Panda board Method: generic U-Boot-Kernel-Address: 0x80008000 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlygnhQACgkQLHwxRsGg ASHWNA/+K185iPeXWnr3Iuh+IVNd4aS1mAPKJaW9x8KTtNjIuIygGA58WFP4k1+9 sUXkAiRxNs6K63l6XopeS2ijJjnhbsPocj5ZRAjBOEEBZZNjPA3fPlpOiJ8n8Fzp N/LU+9ud9FusT4U3lCp1h+815fAr6LKnGxvB90kg3aloAOVUwot+eSEPTTADKWsN ZnWIQOLPsz8R8aISL6hlBA3/Mn1za7H8aCiwuEETc3P6OfitSI8qrlxWrQXpGrH/ uRbrP1K2mBqNFvWK+ETq+q61Ol+eNfaxDIpvAiFEdQzBOvtuIcP4cbhGDzk042TX 4pf6rJu7uQ+Nv51/JufRle8mUvQiroI/kSp1zMxdVtywgJxXwbYPmCQOOvzD+qqA 7bBp6Qsy44absIfjJAXn4TnzoyY0X90A6RW+lQuvBhlw7FCoqHE8oFk5RWyjnDep 0ZydyFkRoEyAnjnA2W/w8KS4d9ydkPV5+bywlPOvC1ccWOs5D5XA2hJF54XZI8r7 0pebuyYWWK9y4eD8hNXRsh8QgEVRFKXa56YMs17uLWL79q5jETnRTH5W9wfb8RxI t7k5ji0lbXgBzvtgBHCp5iocLoPfqsO7WM8Qxv+63z+CgvAkxF5o+Z4mET51MObi HwPWhPT6jLiFxc3gqbwLQ+nDl54eLBlbrzNZDsCiCHTAGG2owCE= =yDMc -END PGP SIGNATURE-
Bug#916822: installation-reports: A20-OLinuXino-Lime2 Rev. K: Fails to boot installer from SD card
Package: installation-reports Followup-For: Bug #916822 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This bugreport seems relevant to reassign to package u-boot, since (if I read the provided log messages correctly) that the failure is in u-boot before even loading linux at all. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlx35C8ACgkQLHwxRsGg ASFgABAAoO6i6dSEhcOU+iThZlrgWLX0wnEYjRxdoicKpKUYffmu5WRLsgqtFSaK M4LFRbytxiKihb9qtA3qI6I9Y0ieuXtHYh3lhipadN1lH8mWJ0YWsjcRoCaWUrZc eeMrV0lUKbSBgyY1MEw7fst8CpwnrE1oFoe65zksWkQlfHA76byTnE8FA+VoW4b8 hl2rKvxgLBoY1ZwNjj5uapGoc8IHcD1NKIhfTT2qo8jzzcQbaE8egt6N+yAyZpQv NNw99gngx/sUGpNqdWdy8tLGx4187lGhMgh+iSZ+VgoLyJbgcz1sYGesHPm8fUXU u5D0SPeMam56jKsIMnWOXC48SOUxa71P1YQYP0VNBv/13A+pRprikzPNGpD+HXSi D1QgfTWMsMTUJ3OCWQIF4Z3m723X/7BMiIbUx67ooCuAaK2JfBFlXwPBjaWykWrv rCxaQfY18ubcDZeetj3LUI75eDxtUPwzQWCsfGXJNsbFoalBWdAzpYqQ7RtMd3fp XXh7KtYymiYoQYVWnE++VjAMPxeKyk/QN2Shm1mtaGC1A+qcwNjCAqSp9RvlAvUT zZGqUQVpBz8hRrpPQ2ux0yzAaIB/S+915qCY/rBAf1BmPKRzSwXJNs/CuvQMlTT4 m5xHoCk8UTNB2RZWkzq0wdhE/L8Zz4dVOKJs2BLtxkTuti2U+7s= =t5l/ -END PGP SIGNATURE-
Bug#917274: task-german: depends on transitional dummy package aspell-de-alt (should be aspell-de-1901)
Package: task-german Version: 1:2-31 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package task-german depends on aspell-de-alt, which describes itself as a "dummy transitional package" which can be safely removed. task-german should instead depend (directly) on aspell-de-1901. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlwiFykACgkQLHwxRsGg ASEYuRAArc4n/jFb525qH2mqu8Q8zbIZt323/jW7kkRuWz2OmXv8ZLuSuNXg+vLK K8M+HLi3UQB54v9Wh7JgQ1QWFRo/jobgwRmBWT+l+Jv2HAfwrKFABkjvcEBE70VG Ggo7Fi0I++y1BD37FQudiWviTdqLuYnfxCLWCM0EaTkhxpREiIe5pNfspuu1n9mU fwvTdVhUAB2aGXXjVlx97tsOZSx3FrqIm3W3fbIJF/gE+Nl52ceNsC5BmoJaPYbJ HWgwruWKqa7+kBcUs0+FMCHLqLAluJPVnUdViRWTUHdeMnTs6wqIZXt6mbX56rjD TKcLu1VLjUHmxWKdmi3Py8lsV/2nLajvDncWdaLQN6UEwGhuxk4+9DbOjP65vtEv Rnvv0ufb3zwmg9gnagfXDU1KxFpK//rCtj33aLVK2ttyESKy8x4ufyonPYXHQsdt 7t0606H7QQBytzun8fmdmoqx8SaNcYLDtytL7A8BI+alhejKUZW/+d8v1NyQ8W7z RrUInUe1bWjzfpcy2HXewZevFpFbI6VIjiFCv0opKOJmKPabnsrAH192sz0cWJhO bC0E1iBW/EkFf6Zghs/KUR90w0PplAfkk+XGDbzX2CWPvGdW6OADvA8AUdTMl1Fx kOaBV8k6zMTn3sSdkfom0KCafKSH46NVVgXsuMBm/XFFQuGNyDA= =JVoX -END PGP SIGNATURE-
Bug#915825: [G-I] installer completely broken for Gujarati, missing font
[re-adding bugreport as cc] Quoting Holger Wansing (2018-12-07 14:26:52) > Jonas Smedegaard wrote: > > Quoting Holger Wansing (2018-12-07 08:39:23) > > > With commit > > > "Replace ttf-freefont-udeb by fonts-freefont-udeb as the former has been > > > removed from unstable (and thus testing)." under > > > https://salsa.debian.org/installer-team/debian-installer/commit/94507f32b36ce050a3f45777b75dce793db3e614 > > > things changed for fonts apparently. > > > Gujarati is no longer usable, all glyphs are replaced by TOFU placeholder > > > signs. > > > > > > Jonas Smedegaard proposed to switch to noto-fonts as an alternative. > > > He uploaded a new version of that udeb to unstable just some days ago, > > > thus it is only in unstable ATM. > > > So I tried that and built a netboot-gtk image locally with this patch > > > implemented and with the noto-fonts-unhinted-udeb as a localudeb: > > [...] > > > And this brings Gujarati back to the G-I. > > > > > > That leads to the assumption, that the gu glyphs seem to be missing in > > > the new fonts-freefont package. > > > > Please file a separate bugreport against fonts-freefont to track that. > > Basically I filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911705 > for this purpose. > Does this not work? > Maybe the bug title can be renamed to represent this better? Ah, sorry: Seems there is nothing wrong with your bug filing. Instead, it seems the tracker interface skips that bug for some reason (perhaps treats udeb packages as irrelevant?): https://tracker.debian.org/pkg/fonts-freefont > Yesterday I filed one more bugreport against the debian-installer > package (on kibi's recommendation) to track this problem for the > installer build process. > > Do you still think, there is some need for one more bugreport? (Please > note, I am still new in this world of debian development, so maybe I > am missing something.) Nope, it looks like you did a great job! ...uhm, except for contacting me privately now: Please move to discrete conversation only when there is need for discretion: Debian explicitly promise to not hide problems, so the (common for some) notion of "didn't want to bother others with this seemungly minor detail" does not apply. Feel free to use your own judgement - but I recommend to at least notice prominently at top of your email when changing recipients in the middle of a conversation. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#915825: [G-I] installer completely broken for Gujarati, missing font
Quoting Holger Wansing (2018-12-07 08:39:23) > With commit > "Replace ttf-freefont-udeb by fonts-freefont-udeb as the former has been > removed from unstable (and thus testing)." under > https://salsa.debian.org/installer-team/debian-installer/commit/94507f32b36ce050a3f45777b75dce793db3e614 > things changed for fonts apparently. > Gujarati is no longer usable, all glyphs are replaced by TOFU placeholder > signs. > > Jonas Smedegaard proposed to switch to noto-fonts as an alternative. > He uploaded a new version of that udeb to unstable just some days ago, > thus it is only in unstable ATM. > So I tried that and built a netboot-gtk image locally with this patch > implemented and with the noto-fonts-unhinted-udeb as a localudeb: [...] > And this brings Gujarati back to the G-I. > > That leads to the assumption, that the gu glyphs seem to be missing in > the new fonts-freefont package. Please file a separate bugreport against fonts-freefont to track that. > I need to mention, that the above patch (adding another udeb to the > build) increases the netboot-gtk image (amd64) from 69 to 85 MB! > Therefore that's probably not an acceptable solution as it is. > But I think Jonas would be able move the relevant glyphs to another > udeb maybe, so that we don't need the whole fonts-noto-unhinted-udeb > in the build? Yes, as soon as (or if at all) I installer team confirms they are ok using Noto Gujarati, I include that font in fonts-noto-hinted-udeb. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: [Pkg-fonts-devel] Bug#911705: #911705 [l10n|gu] debian-installer: fonts broken for Gujarati
Quoting Holger Wansing (2018-12-02 15:43:57) > Holger Wansing wrote: > > Holger Wansing wrote: > > > Holger Wansing wrote: > > > > Package: fonts-freefont-udeb > > > > Severity: normal > > > > > > > > > > > > I just noticed that Gujarati is no longer unusable, because of > > > > broken font (all characters replaced by placeholder, see > > > > attached screenshot). > > > > > > > > This seems to be related to the new fonts-freefont-udeb package, > > > > which replaced ttf-freefont-udeb: > > > > When I use the ttf-freefont-udeb package from Stretch as > > > > localudeb to build the netboot-gtk target here locally, Gujarati > > > > fonts seem to be fine again (see second screenshot). > > > Any chance we can get this fixed for Buster? Perhaps someone in debian-in can help answer above? An alternative is for Gujarati to use fonts-noto. If relevant, then I'd be happy to extend the fonts-noto udeb as needed, but it needs someone who actually understand Gujarati to proof-read if using Noto is not inferior to the previous Freefont display, and it needs someone (you, Holger?) to help generate something for those Gujarati experts to proof-read. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#792283: closed by Nicolas Braud-Santoni <nico...@braud-santoni.eu> (Bug#792283: task-xfce-desktop: should only recommend (not depend on) xfce4)
This bug is not solved by GStreamer 0.10 becoming obsolete: That was mentioned only s an _example_. The underlying problem here is that the task package depends on a metapackage, which subjectively picks a collection of related but not _always_ needed pacages. Please lower the package releation from depends to recommends. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private pgpNUKzCNsKLg.pgp Description: PGP signature
Re: testing fonts for gtk UI
Quoting Cyril Brulebois (2017-10-31 20:00:12) > Cyril Brulebois <k...@debian.org> (2017-10-31): >> You could just kick qemu and iterate over selecting a locale, taking >> a screenshot, hitting Tab the appropriate amount of time, then Enter >> to go back to the language selection. Ugly, but should work. > > Meh. Of course there's much simpler/more robust than toying with going > back to the language selection menu: > > Loop over i from 0 to 75 (ish): > start the graphical installer (qemu, libvirt, whatever) > send Home > send i times Down > send Enter > screenshot > > > Clearly not perfect but should just work reliably. Thanks for trying - I really appreciate the effort. Unfortunately that went pretty much over my head :-( I will try make sense of it... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Re: testing fonts for gtk UI
Quoting Cyril Brulebois (2017-10-30 17:07:17) > Jonas Smedegaard <d...@jones.dk> (2017-10-29): >> The Noto font might be interesting to use in the graphical >> debian-installer to have a uniform visual presentation across >> locales. Since bug#837926 Noto is used for Sinhala and I curious to >> explore how useful same font might be for other locales. >> >> I tried follow https://wiki.debian.org/DebianInstaller/GUIFonts - the >> scripts at the bottom - but they seem outdated or insufficient: >> Current g-i ISO do not not contain the program gtk_font_tester. >> >> Can someone help me how to create font samples nowadays? > > I'm not sure I understand your question exactly, but if you want to > toy with other fonts than what's currently used depending on the > language, have a look at the rootskel-gtk package. > > It provides gtk-set-font, which you can tweak, either at runtime (easy > but not persistent), or in the rootskel-gtk source package (but then > you'll need to rebuild d-i to include it, using build/localudebs). Thanks. Is it documented somewhere how to use rootskel-gtk to loop through multiple locales making screendumps for each locale? Or anything similar, automated, which I might use as starting point? I am not familiar with working interactively with debian-installer. which seems a requirement (apparently rootskel exist as udeb only). That's why I prefer something scripted as starting point that I can adapt for my experiments of replacing fonts. What would be ideal for me as starting point is something like this: <https://wiki.debian.org/DebianInstaller/GUIFonts#Creating_screenshots> (as mentioned previously, above specificall seems to be obsolete.) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
testing fonts for gtk UI
Hi, The Noto font might be interesting to use in the graphical debian-installer to have a uniform visual presentation across locales. Since bug#837926 Noto is used for Sinhala and I curious to explore how useful same font might be for other locales. I tried follow https://wiki.debian.org/DebianInstaller/GUIFonts - the scripts at the bottom - but they seem outdated or insufficient: Current g-i ISO do not not contain the program gtk_font_tester. Can someone help me how to create font samples nowadays? Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script
Quoting Christian PERRIER (2016-11-19 12:17:00) > Quoting Jonas Smedegaard (d...@jones.dk): > > > > Another is in one of the D-I packages : changing the file that > > > mentions what fonts are used depending on the locale. This is not yet > > > committed as I now have to remember what package we're talking about..:-) > > > > Old: fonts-lklug-sinhala-udeb > > > > New: fonts-noto-hinted-udeb package > > *that* I found. The place I'm looking for is a file that says "if > you're using a Sinhala locale, then load this font". From memory that > might be rootskel-gtk Ah, ok. gtk-common, perhaps? http://sources.debian.net/src/debian-installer/20161031/build/pkg-lists/gtk-common/?hl=22#L22 I found above at https://codesearch.debian.org/ with this expression: (?i:sinhal) package:debian-installer (to cover upper/lower case, and both Sinhala and Sinhalese) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script
Quoting Christian PERRIER (2016-11-19 07:23:20) > Quoting Harshula (harsh...@debian.org): > > On 18/11/16 22:12, Jonas Smedegaard wrote: > > > Quoting Christian Perrier (2016-11-18 09:11:00) > > > > >> Chagning the D-I font to Noto for all languages hasn't been > > >> validated...and the current font is well tested and accepted. > > >> > > >> So, as a consequence, I'd prefer a udeb that would be suited for > > >> Sinhala. > > > > > > Makes sense. > > > > > > udeb package fonts-noto-hinted-udeb now, since 20161116-1, contains only > > > fonts relevant for debian-installer - i.e. for now only Sinhala fonts. > > > > Thanks!! That was very quick. > > > I now need to figure out where to make other changes. > > One is in the installer build files (in the debian-installer package > itself) and is committed to git. > > Another is in one of the D-I packages : changing the file that > mentions what fonts are used depending on the locale. This is not yet > committed as I now have to remember what package we're talking about..:-) Old: fonts-lklug-sinhala-udeb New: fonts-noto-hinted-udeb package - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script
Quoting Christian Perrier (2016-11-18 09:11:00) > Le 17/11/2016 à 15:32, Jonas Smedegaard a écrit : >> Quoting Harshula (2016-11-17 14:58:33) >>> On 19/09/16 02:07, Christian PERRIER wrote: >>>> I'd be happy to do this, however the fonts-noto-hinted-udeb package >>>> is 5 megabytes in size while the former fonts-lklug-sinhala-udeb >>>> package is only 67kilobytes. >> I can create a udeb specifically for Sinhala. Or I can create a udeb >> for each single font part of the Noto deb. What do the >> debian-installer team consider useful? > Chagning the D-I font to Noto for all languages hasn't been > validated...and the current font is well tested and accepted. > > So, as a consequence, I'd prefer a udeb that would be suited for > Sinhala. Makes sense. udeb package fonts-noto-hinted-udeb now, since 20161116-1, contains only fonts relevant for debian-installer - i.e. for now only Sinhala fonts. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#844644: debian-installer: debootstrap fails with error 127: line 617: : Permission denied
Package: debian-installer Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Using weekly netinst image downloaded today, failed right after partitioning for full-disk-encryption, reporting that debootstrap returned error 127. Last messages on screen 4 were these: INFO: Menu item 'bootstrap-base' selected sh: apt_dest: unknown operand /usr/sbin/debootstrap: line 617: : Permission denied Target host was a HP 15-g041so Notebook PC. Target disk was connected via USB. - Jonas -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJYLfv8AAoJECx8MUbBoAEhsOMQAKF5ZwagtoDqjPTOYr60bX1F GF4jSi9/7IlUHvgveBjfRzrujxaXeB3DalSCR8F+WSWwMo8PiiUcOjvWZ2Y67PeM yCMiTHux+NHmQxreUD6UPzESjvDrrq2MlsudDhgHEHE6PwMZWakbpCwwKnPpuYvC JSRqW7iVW8OvvmX50pK6q/W2h/94zvTHidYNvPu5r1jXHOr2oRXOnKi5kCrvBFZh SupG8YpjNpphiz+Pdr16UMQYp7bF2W6U9+thWQfadBxI9n136nJDF8MnSiFVk4u/ l+jj4jn5pcA0mZzkF1F9Yb7SojMq4k1a319Il/ZohSgxv8N0Xh1kpRdCwLdneDBq WnTCF7BOpotDny/9j6E29A4BWBUqwVbi0Lna3BMyLWYkdJ2OdJGpR/tzotl68jKB XnhlBQrciC62o4ewFRjuG8dJ1Mdh6TT7LhLckWxFr4fqRu2haucNKAaiB9SrE2F7 NEhaGWAO+LY1Icmlvyq/lfpnRTiqa99xga3Ill3m9Lsfc8a3wUxC03OP9tUF+uBv UsMjfwkeiJlSKt0xfQkUKP6DN6iVMQKjpJs5V0u21mUAeOToTwmeY+HSHRH/bEbl Kitxc2QzgGcubStZPzx89K4FIbmv4Si5zpoPpwmOs4fWFHewNb5uB4ti9pPvSDFw tDaD/TWNEANZdBzwGKpK =vFpj -END PGP SIGNATURE-
Bug#844641: debian-installer: message about security erase does not wrap, loosing essential part at end
Package: debian-installer Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On weekly snapshot of Stretch netinst image downloaded today, choosing an install in danish with full disk encryption, I notice that at the screen informing about the many hour long security wipe of the target disk the message below the bar is not wrapped - and (at least in danish) the important part of the message is cut off: "... Dette trin kan springes over ved a" In english: "... This step can be skipped b" - Jonas - -- System Information: Debian Release: stretch/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJYLfdXAAoJECx8MUbBoAEhnPIP/jCnQLHmw1Ti0ADXNLAf57GX xOsWHfMT0/rVK1WVlqlWBtXjaGAEqJ8JzFppiGVmNTKEOzjhKf87VcqbEaUgdhCF C+V7ubwVP69+XNNLGELXsvpEG704DG7FPn/yN9h0GU2066qNNGKWc8ZRkXSaJRqA 5pjWN/pxOKg7HF4eL4LRVPosZ1P5zcrykPuDbtiiFsvJhQS4lWF+NhcMFgwYoPY8 EzjKZvYcfYiyv5yuG8AWjt4JTEVB77hQgS9AIgF8v9IU4v0oN1ZZ2eN7V4ugnYAJ 2TVQWId0Kp1XZJecRiUbz736xl8sZgZGR6z+uepwUP0AqWhc0Ixlvi9r06iWDoqJ XJzQBjra4pOhjPwJPd/x7idkJdkXL65sW49VrUJaHBBwH1DXB09CWa+moS99ZClz RxNbl7pl9K9k1gkdxvzWgcZ4kghn5vYcQnnNMDlMvyJt3mP4HZAb/vNnf2HMrzWW FOfcbJmlwE4RLXvDKvXH3Oi/rqSZKAprTjgqk9yE74IQswDmq8NWybXpk8E8mI33 ijdL+gkSY7gbG57qtQePKFG+oquL3m4mG26Gqfd1CNQkC549gbeOvWajlKRKDqcm jQF/haozVydHsiNLjJWJ/URqaHJPFWfql0wBTuS9JBslUfpdXrjt3/VnoLepXEOy ALYY98tyLYPhVE9liIL9 =TIAR -END PGP SIGNATURE-
Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script
Quoting Harshula (2016-11-17 14:58:33) > On 19/09/16 02:07, Christian PERRIER wrote: >> I'd be happy to do this, however the fonts-noto-hinted-udeb package >> is 5 megabytes in size while the former fonts-lklug-sinhala-udeb >> package is only 67kilobytes. >> >> Size is somehow constrained in Debian Installer, so I'd prefer >> getting more input and advice before replacing >> fonts-lklug-sinhala-udeb byt fonts-notohinted-udeb in D-I > > Perhaps the Noto maintainers might consider splitting Noto into script > based debs. IIRC, that's what was done in Fedora. I'd be happy to improve the usefulnes of the Noto package(s), but will need more guidance. I suspect easiest approach would be for debian-installer to use Noto generally - i.e. replace not only the font for Sinhala but (I guess) a larger range of region-specific fonts. If debian-installer installs locale-specific fonts only when needed, or there are reasons to not shift generally to Noto, then indeed there is a benefit in creating udeb packages for smaller regions. I can create a udeb specifically for Sinhala. Or I can create a udeb for each single font part of the Noto deb. What do the debian-installer team consider useful? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#807312: src:debian-installer: please provide binary package for use by debian-installer-netboot-images
Package: src:debian-installer Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, debian-installer-netboot-images currently violates Debian Policy by fetching debian-installer images over the network during install - see bug#807168. I believe¹ that debian-installer produces those pieces needed by debian-installer-netboot-images, and suspect that providing in a binary package the pieces needed for debian-installer-netboot-images could (at least partially) solve bug#807168. This bug marked important (not wishlist) as bug#807168 is RC. Regards, - Jonas ¹ See https://lists.debian.org/2015164804.ge26...@mraw.org and surrounding thread. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWZU0YAAoJECx8MUbBoAEhmcIQAJaMsY4l1KoZevz+MwRwSn1c ai22Z7M+NZ7+KZmUcWVV8z7sT5bwzXSq6HiVCX3BWyrNa+6MVrtENzTdXegB85yv iMdHwauEpqou9vdYLENwjyrQ8klWpxbDtSiSyuc+8whMWo/3eoVDu5c2NEQGzFeJ TzlM0NkACImmZdUwa6x0g3xsKuMax+cbk+5fSkL+N7Ct2aTBx7O89PzCvvAqAfvt sRg/mgaLhETlGdJoOBLX4xRb2IdDF0co2jq4T+IWjeO24BDULuFoil5duFUeR3cA atXFP9hTQBRyvJzV88caWFA48GcmqZXnD2bQfR5K8xwE96JbjycG0ZhcFhgyXUih wq96ot1WHED08dnzhLwnkbNO/KYsWp8UbPuBx8felyqXOaDmdSjpCawH7+y515+J ImCrMxyyVVUFEpf5is4sDmlq1L6yQrPR+8PIRcCGa+ajtMzZ1z0Sr+oMtwa1+nu+ 9/QCk4Wk6aVz/aMRI8J3nKQ1RyVDuYHbvzZkkZqaLGVND7FiKmGqC35anKybhGSu h2aZ5M6BxOZJnf0erl0MOTlAdBngUlOodnr+9G9vxcIkboh754vH7lnUs4iY1qmP 3wz8vzcvWj9x8cx8dTazosLxCRQ80yB5gXCttJ6Dw+cECLp3jR3qqQ+WKNPujIVN XvPqemCl53luYOB/BBda =gUgp -END PGP SIGNATURE-
Bug#807168: debian-installer-netboot-images: required resources not declared as build-dependencies (fetches via network)
Quoting Didier 'OdyX' Raboud (2015-12-07 12:52:26) > Control: tags -1 +wontfix > > Le dimanche, 6 décembre 2015, 18.02:48 Jonas Smedegaard a écrit : >> debian-installer-netboot-images source package is less than 6k in >> size. Clearly the main part of the resulting binary packages come >> from fetching resources over the network (apparently using wget). >> Debian Policy includes the following in §4.2: >>> If build-time dependencies are specified, it must be possible to >>> build the package and produce working binaries on a system with only >>> essential and build-essential packages installed and also those >>> required to satisfy the build-time relationships (including any >>> implied relationships). >> >> I can only interpret above as disallowing fetching resources over the >> network using wget. > > d-i-n-i does (it's own) trust-path checking upon download, and it's > doing so because there's (currently) no way to have these files local > through Build-Depends. > > The specificity of the resulting packages is that they are arch-all > while containing arch-specific files. Their value comes from the fact > that you can install netboot images for all Debian architectures > (through arch:all packages) on any Debian architecture, without having > to add add these archs through multiarch. > > So the alternative would be to build these arch:all packages in the > debian-installer build-arch target, but that wouldn't pass the > incoming processing, as far as I know, as dak currently considers that > there will be only one arch:all changes file per source. > > Now talkin' crazy; we could also (ab)use byhand processing to produce > these packages on the archive side; but using the archive to produce > packages isn't really something we want to dive into. Thanks for clarifying. > So, the situation is known to not be Policy-compliant, but at least > there's trust-path checking. In this specific case, I value the > existance of these packages in their current form higher than Policy- > compliance, thereby tagging +wontfix. But I'm open to ideas! > > What would you propose? Seems to me the underlying issue is that those parts fetched with wget is not provided in any binary package. Does that sound correct to you? I have filed bug#807312 about that, and marked it as blocking this one. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#807312: src:debian-installer: please provide binary package for use by debian-installer-netboot-images
Quoting Ansgar Burchardt (2015-12-07 14:50:32)
> Jonas Smedegaard <d...@jones.dk> writes:
>> debian-installer-netboot-images currently violates Debian Policy by
>> fetching debian-installer images over the network during install -
>> see bug#807168.
>>
>> I believe¹ that debian-installer produces those pieces needed by
>> debian-installer-netboot-images, and suspect that providing in a
>> binary package the pieces needed for debian-installer-netboot-images
>> could (at least partially) solve bug#807168.
>>
>> This bug marked important (not wishlist) as bug#807168 is RC.
>
> I don't think its so easy: d-i-n-i are arch:all packages, but need
> binaries for all architectures. To get these as build-dependencies we
> would need cross-arch build-deps which we don't have so far.
>
> Alternatively building a subset of arch:all packages on every
> architecture would also work, but that would require (at least)
> support for the buildd network building arch:all packages on
> package-specific architectures ("Build-Architecture-Indep" might find
> relevant threads).
Sorry, but I don't understand the requirement to change infrastructure.
I think I understand how such infrastructure change can be beneficial
for more complex issues, and then also could serve for a more elegant
solution to this issue, but as I see it debian-installer can (today,
with current infrastructure) build binary arch-all package
debian-installer-netboot-parts-amd64 on amd64,
debian-installer-netboot-parts-arm64 on arm64, and so on.
What am I missing?
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#807312: src:debian-installer: please provide binary package for use by debian-installer-netboot-images
Quoting Jonas Smedegaard (2015-12-07 15:13:51)
> Quoting Ansgar Burchardt (2015-12-07 14:50:32)
> > Jonas Smedegaard <d...@jones.dk> writes:
> >> debian-installer-netboot-images currently violates Debian Policy by
> >> fetching debian-installer images over the network during install -
> >> see bug#807168.
> >>
> >> I believe¹ that debian-installer produces those pieces needed by
> >> debian-installer-netboot-images, and suspect that providing in a
> >> binary package the pieces needed for debian-installer-netboot-images
> >> could (at least partially) solve bug#807168.
> >>
> >> This bug marked important (not wishlist) as bug#807168 is RC.
> >
> > I don't think its so easy: d-i-n-i are arch:all packages, but need
> > binaries for all architectures. To get these as build-dependencies we
> > would need cross-arch build-deps which we don't have so far.
> >
> > Alternatively building a subset of arch:all packages on every
> > architecture would also work, but that would require (at least)
> > support for the buildd network building arch:all packages on
> > package-specific architectures ("Build-Architecture-Indep" might find
> > relevant threads).
>
> Sorry, but I don't understand the requirement to change infrastructure.
> I think I understand how such infrastructure change can be beneficial
> for more complex issues, and then also could serve for a more elegant
> solution to this issue, but as I see it debian-installer can (today,
> with current infrastructure) build binary arch-all package
> debian-installer-netboot-parts-amd64 on amd64,
> debian-installer-netboot-parts-arm64 on arm64, and so on.
>
> What am I missing?
and then right when I hit "send", it occured to me: arch-independent
packages cannot be built on specific archs only (which is exactly what
you already wrote, in slightly different words). I understand the
problem now.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#807312: src:debian-installer: please provide binary package for use by debian-installer-netboot-images
Quoting Cyril Brulebois (2015-12-07 15:49:42) > Jonas Smedegaard <d...@jones.dk> (2015-12-07): >> debian-installer-netboot-images currently violates Debian Policy by >> fetching debian-installer images over the network during install - >> see bug#807168. > > You do realize that debian-installer suffers from the very same issue, > right? It does not surpise me, but I didn't know for certain, as I am not knowledgeable about the inner workings of debian-installer. Is this Policy violation already tracked as a bug to (eventually) fix? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#807168: debian-installer-netboot-images: required resources not declared as build-dependencies (fetches via network)
Source: debian-installer-netboot-images Version: 20150422+deb8u2 Severity: serious Justification: Policy 4.2 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 debian-installer-netboot-images source package is less than 6k in size. Clearly the main part of the resulting binary packages come from fetching resources over the network (apparently using wget). Debian Policy includes the following in §4.2: > If build-time dependencies are specified, it must be possible to build > the package and produce working binaries on a system with only > essential and build-essential packages installed and also those > required to satisfy the build-time relationships (including any > implied relationships). I can only interpret above as disallowing fetching resources over the network using wget. Kind regards, - Jonas - -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWZCrtAAoJECx8MUbBoAEh/9AP/jvT+CdfkcpSd7iM81kJfXik eckvuOlGT7yAbthtD08r7c0bXSggJRmCVo2Yw8SKJywvaCdRfXqUu74B2en2EQPi oWOWeOTTSgDzhFyO06FcGYk4MK4EsthRJH6dUW+djOW1ovqQODfZC3uhfNwzvLjt ygxqgDK5p4mWQOgcpHxBzclR8+LlXtu7RsXNtPEqDeIqLHr3NaKInW9nMEmm030d PTRgw26h9qe47njlNPGgfKPYbwnZdzLLBils0429AmvRStu/OTXgLcwUkaIXs3dX URwoCzJ8X6F3jJUZo7trX1nrkGdyCE3k2VfT9kavWxiAlvoHd4rtWaqdheHDfVW7 xJgXNZAZ8pQC4Quy09/iOTcQqIpJHd7JmZyaxzTuxf27mHdAc3SCJVd2Kx85uIft MjGlKdt5LakMQ56NggYsbFeaEU+fyKDU46a8c79uKwK6zW7s892JJAeX0/4hTqq1 BAEueBwpzAl743jKhnwWjM5qvhn0L589WmOJ/zjsURXSmYZ4s8tYyAHN+1nB/HDZ YUpaaJ2LeLCRTI5hdcl2V3ePTf1SXXdgSo8pXBsq5PfzUu217OZrmkBumJ+gEm/A cTVtHFKbpYa1xcPQVLAEDnNmmSl16WIuQnlO1opUvPISFdxwTquSY5NrnpqINVoh 08U2a4CkHfyTofdKLB9t =bP2q -END PGP SIGNATURE-
Re: Which pseudo-package do ARM netboot image slices belong to?
Quoting Karsten Merker (2015-11-12 21:10:42)
> On Wed, Nov 11, 2015 at 05:07:45PM +0100, Cyril Brulebois wrote:
> > Jonas Smedegaard <d...@jones.dk> (2015-11-10):
> > > I've hit a bug¹ in a non-package part of Debian, identified that it is
> > > tied to variations not in package releases but web-facing parts of
> > > official Debian:
> > > http://ftp.de.debian.org/debian/dists/stretch/main/installer-armhf/$timestamp/images/netboot/SD-card-images/
> > >
> > > I filed a bugreport against the pseudo-package seeming most appropriate,
> > > but then got no (maintainer) response for a week. That delay might be
> > > perfectly fine (I often have far worse reaction time myself), but made
> > > me wonder: Did I file it wrongly, so that the bug isn't "heard"?
> > >
> > > Which pseudo-package do ARM netboot image slices belong to?
> > >
> > > or more generally:
> > >
> > > Is there some way of verifying which pseudo-package(s) is(/are)
> > > appropriate for targeting a bugreport, when web address is known?
> > >
> > > For real packages where I have located a file involved, I can verify if
> > > a proper package is targeted by use of "dpkg -L ..." or "apt-file search
> > > ..." or similar tools. Do we have similar ways to check (preferrably
> > > without needing login to specific Debian hosts) which pseudo-package
> > > some official area of Debian web services belong to? E.g. a public list
> > > of which team has write access to which parts of our web-facing
> > > services?
> > >
> > > I am aware of https://www.debian.org/Bugs/pseudo-packages but that's
> > > comparable to grep'ing package descriptions to pinpoint where a bug
> > > belongs, nowhere as accurate a verification as "dpkg -L ..." or
> > > "apt-file search ...".
> >
> > Karsten, Ian, and other arm people,
> >
> > This makes me wonder whether those sd card images should be packaged and
> > shipped somehow (through d-i-n-i or elsewhere), instead of just being
> > published through the installer-* directories.
> >
> > What's your take on this?
>
> Hello,
>
> personally I don't think that packaging the images would bring us
> an advantage that is worth the costs.
>
> Adding them to debian-installer-netboot-images would IMHO not
> really fit - d-i-n-i provides files for serving over the network
> ("real" netboot stuff, i.e. TFTP/PXE boot), while the SD-card
> images are the ARM equivalent of the i386/amd64 mini.iso, which
> we also don't package in d-i-n-i. Besides that, finding the
> proper package to report bugs against via "dpkg -L" or "apt-file
> search" also doesn't work with the binary packages generated by
> d-i-n-i, because their actual content - against which one would
> want to file a bug - is not built by d-i-n-i but by
> src:debian-installer. This could of course be changed by
> integrating d-i-n-i into the d-i build system and making the
> packages children of d-i, but from my personal point of view I
> don't see much need for that.
I agree that easy locating how to file bug is not a big benefit: That
can be addressed by adding contact info at the bottom of the web page
serving the images.
A real benefit of shipping SD card images as binary packages would be
ease of trusted bootstrapping:
Imagine Bob, a cautious but non-geekie person. He hires an expert to
carefully inspect his laptop to ensure that it is really truly running
only Debian, no other code is installed. He then wants to install
Debian on another host. He would then need to hire an expert yet again,
because he cannot - easily and secured by APT - get install media for
another machine, but needs to use different more technical trust paths
of manually downloading and verifying stuff from the big bad internet.
If d-i images was available as binary packages, then FreedomBox could
offer an install service for custom-configured laptop setups,
dynamically injecting preseeding file into a trusted installer image.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: d-i hangs after "Detecting hardware" and emits E: Unimplemented function
Quoting Karsten Merker (2015-11-14 01:02:54) > On Fri, Nov 13, 2015 at 02:23:40PM +0100, Jonas Smedegaard wrote: > > Quoting Karsten Merker (2015-11-12 21:32:27) > > > Jonas Smedegaard <d...@jones.dk> wrote: > > > [d-i on an Allwinner A20-based Olimex LIME2] > > >> Board boots, asks for locale, and informs that it detects hardware, > > >> but then (apparently) hangs, and after a little while emits this: > > >> > > >> E: Unimplemented function > > > > > > Hello, > > > > > > several people seem to have had similar effects on different hardware, > > > so it does not seem to be a problem that is specific to > > > Allwinner-based systems. According to the following bugs/threads, > > > possible candidates for the source of the issue could be the kernel or > > > udev: > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804351#45 > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804351#50 > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803476 > > > > > > https://lists.debian.org/debian-arm/2015/11/msg00021.html > > > > Interesting! > > > > The bisection in https://bugs.debian.org/803476#15 matches my more vague > > tests: Success with Stretch debian-installer 20150911 and package > > snapshot 20151002T213032Z which pulls udev-udeb 226-3. Later snapshot > > complains with kernel mismatch, and next debian-installer release > > 20151023 is the one failing as reported here. > > > > I will try test if debian-installer 20151023 works with an older package > > snapshot (and, as mentioned before, get some debug info). > > Hello, > > just a short status update: I have worked on debugging the issue > further and I think that I have found a bug in ethdetect, but > that needs some further analysis. I'll try to dedicate some more > time to the issue on the weekend. Sounds promising! Please tell me how, if you think I can help test it. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: d-i hangs after "Detecting hardware" and emits E: Unimplemented function
Quoting Karsten Merker (2015-11-12 21:32:27) > Control: reassign -1 src:debian-installer Thanks for reassigning, Karsten. As mentioned on d-devel, I intend to try gather debugging info, but haven't found time yet for doing that. [more comments below...] > Jonas Smedegaard <d...@jones.dk> wrote: > [d-i on an Allwinner A20-based Olimex LIME2] >> Board boots, asks for locale, and informs that it detects hardware, >> but then (apparently) hangs, and after a little while emits this: >> >> E: Unimplemented function > > Hello, > > several people seem to have had similar effects on different hardware, > so it does not seem to be a problem that is specific to > Allwinner-based systems. According to the following bugs/threads, > possible candidates for the source of the issue could be the kernel or > udev: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804351#45 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804351#50 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803476 > > https://lists.debian.org/debian-arm/2015/11/msg00021.html Interesting! The bisection in https://bugs.debian.org/803476#15 matches my more vague tests: Success with Stretch debian-installer 20150911 and package snapshot 20151002T213032Z which pulls udev-udeb 226-3. Later snapshot complains with kernel mismatch, and next debian-installer release 20151023 is the one failing as reported here. I will try test if debian-installer 20151023 works with an older package snapshot (and, as mentioned before, get some debug info). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Which pseudo-package do ARM netboot image slices belong to?
Quoting Cyril Brulebois (2015-11-11 17:07:45) > Jonas Smedegaard <d...@jones.dk> (2015-11-10): >> I've hit a bug¹ in a non-package part of Debian, identified that it >> is tied to variations not in package releases but web-facing parts of >> official Debian: >> http://ftp.de.debian.org/debian/dists/stretch/main/installer-armhf/$timestamp/images/netboot/SD-card-images/ >> >> I filed a bugreport against the pseudo-package seeming most >> appropriate, but then got no (maintainer) response for a week. That >> delay might be perfectly fine (I often have far worse reaction time >> myself), but made me wonder: Did I file it wrongly, so that the bug >> isn't "heard"? >> >> Which pseudo-package do ARM netboot image slices belong to? [...] > Karsten, Ian, and other arm people, > > This makes me wonder whether those sd card images should be packaged and > shipped somehow (through d-i-n-i or elsewhere), instead of just being > published through the installer-* directories. > > What's your take on this? Ohh, that'd be great - also to ease ability for anyone to inspect how those images was created. Until (eventually) packaged, can someone help point to the code to create those images? @Cyril: Regarding the concrete bug, i'll reassign the bugreport to debian-installer when I get around to collect the required additional debugging info... @Paul: Thanks for your info! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: [Pkg-fonts-devel] Migrating from fonts-droid to fonts-noto
Quoting Vasudev Kamath (2015-11-10 09:39:36) > Christian PERRIER <bubu...@debian.org> writes: > >> Quoting Vasudev Kamath (vasu...@copyninja.info): >> >>>> Is this change going to impact the fonts-android-udeb binary >>>> package which is now being used within the Debian Installer? >>> >>> No, as of now upstream git repository of android source provides 2 >>> fallback variants DroidSansFallback and DroidSansFallbackFull along >>> with DroidSansMono. So this should not be a problem. >> >> >> I think that Kibi's point is more asking "will you rename the udeb >> package", which would then require a change in the D-I build >> scripts > > Ah okay. No I will not rename the package. > > Only change I'm thinking to do is change the font shipped by udeb, > currently it ships DroidSansFallback. I'm thinking of changing it to > DroidSansFallbackFull will this cause any problems?. Seems change of font within that udeb can be done in independent of and thus tracked as a separate bug than the issue of migrating non-fallback fonts to Noto. I.e. need not delay the transition and need only be discussed with those directly involved - no need for distro-wide discussion of that :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#771699: Provide A Preseed Option For Ignoring The Valid-Until Field of InRelease Files
Quoting Cyril Brulebois (2015-11-02 17:20:04) > Having toyed with V-U a bit recently, I think I see the issue rather > clearly now, and the details above seem to make it clear that > debootstrap should probably be a bit more cautious about this. [...] > I've added this to my (not really ever-growing but yet non-empty) d-i > to-do list, and I'll do the BTS dance (cloning and reassigning to > debootstrap etc.) if I don't receive any negative feedback about the > analysis above. I only stumbled upon V-U last night when hitting bug#803769, so am sure you are better versed in this than me, but if it makes you sleep better at night then you hereby have my blessing for moving on with your (snipped) draft agenda for this :-) I can offer to debug should that be needed (see bug#803769 for a summary of my capabilities in that regard). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#771699: Provide A Preseed Option For Ignoring The Valid-Until Field of InRelease Files
Hi, Cyril Brulebois <k...@debian.org> wrote: > I don't have the right setup handy right now to test this. Could you > please at least tell us whether that's something that should be dealt > with at debootstrap time and/or in some other places? (It's not > entirely clear where you draw the line between installer only and > target image since many apt calls happens within /target). When using snapshot.debian.org (e.g. to work around bug#803769) it seems debootstrap ignores expiry (which is arguably a bug in itself): Only midway through the install process does it fail asking to retry, and retrying succeeds after running either of these commands: a) date -s $some-old-enough-data b) echo 'Acquire::Check-Valid-Until "false";' > /target/etc/apt/apt.conf.d/99ignore-repo-exiry As I understand this issue and your question, Cyril, the answer is therefore that such flag currently (with arguably buggy debootstrap) only need to affect the later APT calls within /target. Regards, and thanks a lot for all the great work on the installer, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#799006: di-netboot-assistant: should suggest isc-dhcp-server (not bogus dhcp3-server)
Package: di-netboot-assistant Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package currently suggests dhcp3-server which does not exist. It should instead suggest isc-dhcp-server. - Jonas - -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJV9zjXAAoJECx8MUbBoAEhLh4P/At7hKqdMAMnZuaH45SEdTV5 VoDNJyzCrIyWggFtPck2lI4WLc6NF2JS1sBvvWIPC5nA8siW74D3xlQacc/uVeVL z/GoJbewapJt9oIhzlI1pKjj/ijpQ/EGVNPIb9Eyj0SaLq2USgFHsi8NgXLFWczG BBJ1vErSAnxGpI0rqmzBa/AXLBhGvvIfRBZYjYnbmu8Yd8xLPlGkoSVrgK7OyACk m6sEkGI3q9pm2t8rkJSkDyPDJVkxrAn0NL5UUCLwd4GO62DdEZPWEjNH8nkQkGMV VvArW7aFf82nR2S+vupfcDWOE+mer1Kuq+LwXkS44n3I1UzBSM62LgqqFvvyQ7ea 9CSVJQ5BvIEzKHSbZdRzsuKPy7J5/YsoA6/7se8R83DqcgV0+qMsquA6rsfJ5Cs0 vHFbJKdsQLlhD1rDH6fui2UPT/eyQkDmsjsg9qCJtQx6xOA1rmdDYU0fmUMBZS5O RUq6eArHN57u669vNF4IlaZjgvSAE4qvDUWqx1SjzCi20rLN28wyQprmOUS1pLsA hzZod9iufRU8gWzlFTu3IKBQ/xDQC8wruzMLtmvqviukJo+3khFgsR1/Z8u5O/5m UoYjQlJi+ckYL94QKRiYGSknpHi3G8kUNFxMHr+DHUj3uVHdEmTwp1yPXuyQU5lA dcfptsMjlW1I/EwXkbjl =MT5X -END PGP SIGNATURE-
Bug#792283: task-xfce-desktop: should only recommend (not depend on) xfce4
Quoting Cyril Brulebois (2015-07-13 16:46:11) Jonas Smedegaard d...@jones.dk (2015-07-13): Package: task-xfce-desktop Version: 3.32 Severity: important task-xfce-desktop depends on xfce4. While that may seem the very purpose of this package, it causes problem when e.g. wanting the XFCE desktop environment but not GStreamer0.10. See bug#774282 for the concrete issue caused by this IMO too strict relationship. Similarly, the relationship with lightdm should probably be relaxed. Let's ask pkg-xfce-devel@… Excellent idea :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#792283: task-xfce-desktop: should only recommend (not depend on) xfce4
Package: task-xfce-desktop Version: 3.32 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 task-xfce-desktop depends on xfce4. While that may seem the very purpose of this package, it causes problem when e.g. wanting the XFCE desktop environment but not GStreamer0.10. See bug#774282 for the concrete issue caused by this IMO too strict relationship. Similarly, the relationship with lightdm should probably be relaxed. Kind regards, - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVo80hAAoJECx8MUbBoAEh048P/3r6o63kqYi+MQNajh8ToOoh DooPn6UF3xKjleOTNdiaTKFsUW8oty7Swx+fnxQzoa/T+cjzEnc3WGJtyL3JH4IH e7CG9NBoIuO06AzzeXlPnHv/i/xZBylKusCl8DIzfy2Oyb8xC84m/7T5dXBvB/6B r35X7RzQXtF2jESjcF3j1JO5bbuSxF/SX9mClLgU4/6j8fq51sDETMTvBjrjqw1K 03qIaeZQt8mPXla0J8bcCY/pcOn/7uHfQguGbqCjMi9iGKFW5HDZkGNut/+FWQnG Kwqe9rGz5SIEO5W6X4E3B1/l+IuUGfy0JxerjLkwjQpwk35xqrz2u5yqjr3kLofB DioLaZ+2cmK+7ElBCZJ3uTpUh+cQ1XB3TG2Qu4j8l1pC/8iHOlmhTWCGLw5EMqxy bfYwibbuphkowTxnhAtKK+MvatPU6KMGNC9ZechxzBQbVuLhbHRxcNrF0zYfpuJ/ 0+pH46Uwc8qLWUeeOHakJzfbT+QwxwB+nsbzWWfZqm8a97jHO58rSurYK3TmJbn2 5KNHfFA4J1iZ3FyxCvU2i4PRkWvFoMn5HOkBfBzDDy9VwbeIe6DHgBb+G1fCoxUZ eKhy73iMDDIKeeSmPCx9O/tpcw7ZLxax7zvP+Zrt2amiztB0QE1W7TJ/wrsFx1tA ImQxu2Qel8O++cf9Hnci =gOHD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150713143725.24508.77898.report...@auryn.jones.dk
Bug#668001: please help test proposed patch for bug#668001
August 8th, Debian began supporting¹ choice among several init systems. August 21st, Debian changed² default init. To me, flexibility is an important feature of Debian. I am excited that Debian extends its flexibility to cover several init systems. Others agree, apparently³: Among those testing our system while this new flexibility is in place, ~20% use a non-default init system. For fresh installs, picking a non-default init requires a workaround: First install default init system, then replace with your own choice. Remember to also check for and purge any cruft pulled in by that detour. October 17th a fix was proposed at https://bugs.debian.org/668001#20. @Testers of Debian: Please test debootstrap with that patch applied and report your experiences, good and bad, to 668...@bugs.debian.org. @Debian-installer team: Please reconsider applying that patch. If not targeted Jessie then in another suite: Any degree of adoption eases ability to test, which in turn eases ability to adopt further. Kind regards, - Jonas ¹ Package sysvinit stopped being flagged as essential, causing package managers to no longer treat alternative choices as breach of Policy. That changes entered unstable 2014-08-06 and testing 2014-08-12. ² Package init switched to favor systemd-sysv over sysvinit-core. That changes entered unstable 2014-08-21 and testing 2014-08-26. ³ According to https://qa.debian.org/popcon-graph.php?packages=sysvinit-core+systemd-sysvfrom_date=2014-07-24hlght_date=2014-08-26 -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#668001: please help test proposed patch for bug#668001
Hi Cyril, Quoting Cyril Brulebois (2014-11-25 18:31:33) Jonas Smedegaard d...@jones.dk (2014-11-25): August 8th, Debian began supporting¹ choice among several init systems. August 21st, Debian changed² default init. To me, flexibility is an important feature of Debian. I am excited that Debian extends its flexibility to cover several init systems. Others agree, apparently³: Among those testing our system while this new flexibility is in place, ~20% use a non-default init system. For fresh installs, picking a non-default init requires a workaround: First install default init system, then replace with your own choice. Remember to also check for and purge any cruft pulled in by that detour. October 17th a fix was proposed at https://bugs.debian.org/668001#20. @Testers of Debian: Please test debootstrap with that patch applied and report your experiences, good and bad, to 668...@bugs.debian.org. @Debian-installer team: Please reconsider applying that patch. If not targeted Jessie then in another suite: Any degree of adoption eases ability to test, which in turn eases ability to adopt further. I'm not sure why people seem to believe that broadcasting a call for tests through their blog, Planet Debian, various Debian mailing lists, etc. is going to change anything here. You don't follow how raising exposure to a bugreport have the potential to boost contributions getting that bug resolved? I've already mentioned that having debootstrap stop pulling an init system might make sense at some point. In the meanwhile, debootstrap is not going to receive any patching in the dependency resolving area. Thanks for clarifying. I guess now (reading again a couple times very slowly) that you are referring to this late in the release cycle in https://bugs.debian.org/668001#28. I am sorry that until now I read that as simply go away, too late! Quite possibly I was distracted by the mud you threw right after that in same sentence. I find no pleasure digesting mud so only read that sentence quickly at first. Just to be clear: Are you saying that the patch is perfect and just - as already more than adequately pointed out by you (except evidently still so for think-headed folks like me) - will not under any possible circumstances be touched _before_ Jessie is released, but _after_ the release will be applied as-is with no need for further testing nor discussion from your peer Debian developers or anyone else? If so, then why not release it now for experimental? If because you are too busy releasing Debian, would you perhaps be ok with me doing so as an NMU? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#668001: please help test proposed patch for bug#668001
Quoting Cyril Brulebois (2014-11-25 19:50:48) Jonas Smedegaard d...@jones.dk (2014-11-25): Quoting Cyril Brulebois (2014-11-25 18:31:33) I'm not sure why people seem to believe that broadcasting a call for tests through their blog, Planet Debian, various Debian mailing lists, etc. is going to change anything here. You don't follow how raising exposure to a bugreport have the potential to boost contributions getting that bug resolved? Since the decision was made that no, it won't be touched for jessie, no, I frankly do not follow. Why do you talk about Jessie? I do not talk about Jessie, I talk about a bug in Debian and how we can fix it. I believe that the only time I mentioned Jessie in this thread (till now) was in a sentence where I explicitly propose to *not* target that suite if needed to move forward with this bug. Do you understand my question now? I've already mentioned that having debootstrap stop pulling an init system might make sense at some point. In the meanwhile, debootstrap is not going to receive any patching in the dependency resolving area. Thanks for clarifying. I guess [...] that you are referring to this late in the release cycle in https://bugs.debian.org/668001#28. [mutual apologies snipped] Quite possibly I was distracted by the mud you threw right after that in same sentence. I find no pleasure digesting mud so only read that sentence quickly at first. I'm sorry you see mud throwing in my considering this a non-problem, I really don't follow you there either. What I call throwing mud is your introducing dislikes of systemd when that's not what the bug is about. (Heck, the title of the bug is even the opposite - stemming from the era past 4 months ago when systemd was not the default). Back to my question: Did I guess correctly that your this late in the release cycle in https://bugs.debian.org/668001#28 is what you mean by already mentioned? (Again, let me emphasize that I am talking about a bug, not a release and no specific init system). Just to be clear: Are you saying that the patch is perfect and just - as already more than adequately pointed out by you (except evidently still so for think-headed folks like me) - will not under any possible circumstances be touched _before_ Jessie is released, but _after_ the release will be applied as-is with no need for further testing nor discussion from your peer Debian developers or anyone else? No, I didn't write that either. Please stop making up stuff. It won't be considered for jessie, that's all. Either?!? So I guessed wrong further up, or what? Sorry if that's the case - it was unintentional. Perhaps it helps if you spell out to me what you are talking about, instead of only making remarks that $stuff has already been discussed $enough. Seems _your_ $stuff is init-specific and _your_ $enough is suite-specific, and you then impose that on my $stuff and $enough which are different ones. Seems you are reading between the lines of what I wrote and then get upset when I do the same. You mention Jessie again - that's besides the point! If so, then why not release it now for experimental? If because you are too busy releasing Debian, would you perhaps be ok with me doing so as an NMU? To be crystal clear: no, this patch needs to be considered, reviewed, whatever, and not randomly uploaded to experimental. Feel free to ping this bug report once jessie is released. You have made it quite clear that you do not believe putting more attention to this bug is going to change anything here. How then do _you_ propose to get it considered, reviewed, whatever? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#668001: please help test proposed patch for bug#668001
Quoting Cyril Brulebois (2014-11-26 00:31:18) I'll probably stop replying here since I feel like I'm repeating myself over and over and over and over again. You didn't repeat youself. Thanks for spelling out your opinions to me. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Old-timer installer, task-sysvinit?
[sent again - to proper address this time] [NB! This post sent to debian-boot - please follow up there] Quoting Erich Schubert (2014-11-23 09:50:12) 1. There is a wide consensus that Debian continues to allow other init systems. 2. The installer (currently) does install systemd. 3. The installer CAN be used to install sysvinit via preseeding (and admins should know how to use preseeding to install systems...) I believe third point above is inaccurate: Debian-installer has hooks to pass hints to packages (debconf preseeding) and hooks to execute shell scripts. What is currently possible is only the latter: Spawn a shell script late in the install process to replace init-related packages already installed by debian-installer. Please Cc me, I am not subscribed here. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#759424: di-netboot-assistant: please update package for jessie / new syslinux
Quoting Cyril Brulebois (2014-11-23 12:49:58) Jonas Smedegaard d...@jones.dk (2014-11-21): Attached is a patch believed to fix all issues related to new syslinux: * Lookup pxelinux.0 in /usr/lib/PXELINUX (not only /usr/lib/syslinux). * Lookup only BIOS binaries (not accidentally include EFI binaries). * Install core modules at tftpd root dir. * Keep vesamenu and menu modules in sync with PXELINUX. thank you both for providing patches to di-netboot-assistant; is there any chance you could submit a branch or patch series against its git repository (git://anonscm.debian.org/d-i/netboot-assistant.git)? Of course I could try and split up your patches into atomic commits, but I guess it'd be better if knowledgeable could document patches. There's of course the part where Andreas had to patch a bit more what Jonas provided, so cross-checking each other would be nice. Sure thing: I will prepare git commits. I am puzzled why you needed that change, Andreas. Perhaps it depend on the versions of syslinux involved. I tested on Jessie, with stable, testing and daily for amd64 and i386 - what did you test? Or perhaps it is related to choice and configuration of tftpd. I use tftpd-hpa with TFTP_OPTIONS=--blocksize 1468 -v -v -v -v --secure and adapting di-netboot-assistant to use /srv/tftp. Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Old-timer installer, task-sysvinit?
Quoting Cyril Brulebois (2014-11-23 13:13:05) Jonas Smedegaard d...@jones.dk (2014-11-23): Quoting Erich Schubert (2014-11-23 09:50:12) 1. There is a wide consensus that Debian continues to allow other init systems. 2. The installer (currently) does install systemd. 3. The installer CAN be used to install sysvinit via preseeding (and admins should know how to use preseeding to install systems...) I believe third point above is inaccurate: Debian-installer has hooks to pass hints to packages (debconf preseeding) and hooks to execute shell scripts. What is currently possible is only the latter: Spawn a shell script late in the install process to replace init-related packages already installed by debian-installer. Well, I'm really unsure what you're calling inaccurate in the third point. It is that preseeding is the mechanism used - but I may indeed be wrong: I assumed the term preseeding meant debconf preseeding, but realize now that indeed both https://wiki.debian.org/DebianInstaller/Preseed and e.g. https://www.debian.org/releases/stable/i386/apbs01.html.en uses the term without direct ties to debconf. Both those documents do, however, describe [not-only-debconf] preseeding as a way to set answers to questions asked during the installation process. I consider preseeding to be feeding answers to questions before asked. Executing shell scripts is something else, IMO. You likely disagree. I think I've mentioned that a few times already, but here's yet another reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001#60 Yes. And thanks for pointing to that at several occasions recently. That's preseeding, that gives a system running sysvinit-core at the first boot without any further interaction, replacing systemd bits by sysvinit ones after the initial debootstrap. Ok, I understand now that preseeding not only means answering questions before asked, but also non-declarative automation. That's new to me. If you're unhappy about the initial systemd installation, that's too bad, because we're not going to change debootstrap, especially not at this late stage of the release cycle, to behave differently depending on the target distribution. The current script covers all suites from etch (etch, lenny, squeeze, wheey, jessie, and now stretch), and it'd really be nice if that could stay the case. I am unhappy about the need for messing non-declaratively with debian-installer in order to override default choice of init system. It is nice that debian-installer provides hooks to do dangerous things, but I find it worrisome that changing init system involves use of that. There won't any more debconf, udeb, or whatever addition going to happen. It means additional work (nobody has been doing that for a whole release cycle), more maintenance, and… it's just too late. Why do you say for a whole release cycle? Only late in the release cycle did init system become changeable without violating policy (removing core packages). Please cc me on replies. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#759424: di-netboot-assistant: please update package for jessie / new syslinux
Quoting Jonas Smedegaard (2014-11-23 13:05:36) Quoting Cyril Brulebois (2014-11-23 12:49:58) Jonas Smedegaard d...@jones.dk (2014-11-21): Attached is a patch believed to fix all issues related to new syslinux: * Lookup pxelinux.0 in /usr/lib/PXELINUX (not only /usr/lib/syslinux). * Lookup only BIOS binaries (not accidentally include EFI binaries). * Install core modules at tftpd root dir. * Keep vesamenu and menu modules in sync with PXELINUX. thank you both for providing patches to di-netboot-assistant; is there any chance you could submit a branch or patch series against its git repository (git://anonscm.debian.org/d-i/netboot-assistant.git)? Of course I could try and split up your patches into atomic commits, but I guess it'd be better if knowledgeable could document patches. There's of course the part where Andreas had to patch a bit more what Jonas provided, so cross-checking each other would be nice. Sure thing: I will prepare git commits. I am puzzled why you needed that change, Andreas. Perhaps it depend on the versions of syslinux involved. I tested on Jessie, with stable, testing and daily for amd64 and i386 - what did you test? Or perhaps it is related to choice and configuration of tftpd. I use tftpd-hpa with TFTP_OPTIONS=--blocksize 1468 -v -v -v -v --secure and adapting di-netboot-assistant to use /srv/tftp. @Andreas: If you configured your tftpd to treat debian-installer subdir as root dir for tftpd, then you should move/copy those three files yourself: This script currently has configurable TFTP_ROOT but hardcoded debian-installer subdir - making that configurable too is independent from this bug. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#759424: di-netboot-assistant: please update package for jessie / new syslinux
Quoting Jonas Smedegaard (2014-11-23 13:05:36)
Quoting Cyril Brulebois (2014-11-23 12:49:58)
Jonas Smedegaard d...@jones.dk (2014-11-21):
Attached is a patch believed to fix all issues related to new
syslinux:
* Lookup pxelinux.0 in /usr/lib/PXELINUX (not only
/usr/lib/syslinux).
* Lookup only BIOS binaries (not accidentally include EFI
binaries).
* Install core modules at tftpd root dir.
* Keep vesamenu and menu modules in sync with PXELINUX.
thank you both for providing patches to di-netboot-assistant; is
there any chance you could submit a branch or patch series against
its git repository
(git://anonscm.debian.org/d-i/netboot-assistant.git)?
Of course I could try and split up your patches into atomic commits,
but I guess it'd be better if knowledgeable could document patches.
There's of course the part where Andreas had to patch a bit more what
Jonas provided, so cross-checking each other would be nice.
Sure thing: I will prepare git commits.
I now have a fork of your git locally, and attached patches were
produced using git format-patch --minimal origin/master - not sure if
that's what you prefer, else please guide me.
My patches do not incorporate Andreas' addition, as I believe it to be
wrong. I could be wrong, of course, and am open to further input.
Hope this all helps,
- Jonas
--
* Jonas Smedegaard - idealist Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
From e4b2ab5cd4e09daf72d51ee5b35b3a8b8b5e92d9 Mon Sep 17 00:00:00 2001
From: Jonas Smedegaard d...@jones.dk
Date: Sun, 23 Nov 2014 16:01:15 +0100
Subject: [PATCH 5/5] Handle core PXELINUX modules introduced in recent
PXELINUX, required to be served at tftp root dir.
---
di-netboot-assistant | 10 ++
1 file changed, 10 insertions(+)
diff --git a/di-netboot-assistant b/di-netboot-assistant
index d581507..e21112e 100755
--- a/di-netboot-assistant
+++ b/di-netboot-assistant
@@ -276,6 +276,13 @@ copy_syslinux_bin() {
done
# Smooth transition to vesamenu
[ ! -f $c32_dir/menu.c32 ] ln -s vesamenu.c32 $c32_dir/menu.c32
+ # Add core modules at root (see https://bugs.debian.org/756275#49)
+ if [ $TFTP_ROOT/debian-installer/ = $dst ]; then
+ for f in ldlinux.c32 libcom32.c32 libutil.c32; do
+ srcf=$(find_file $f $src)
+ [ -z $srcf ] || cp -np $srcf $TFTP_ROOT/$f
+ done
+ fi
return 0
}
@@ -925,6 +932,9 @@ setup_syslinux() {
vesamenu.c32|menu.c32)
cp -pft $(dirname $f) $TFTP_ROOT/debian-installer/pxelinux.cfg/$(basename $f)
;;
+ ldlinux.c32|libcom32.c32|libutil.c32)
+ cp -pft $(dirname $f) $TFTP_ROOT/$(basename $f)
+ ;;
*)
echo W: Unusual PXELINUX module \$f\ may not work. 12
continue
--
2.1.3
From 8e3ffac22d2888ed0094ed3a172257836250ccbf Mon Sep 17 00:00:00 2001
From: Jonas Smedegaard d...@jones.dk
Date: Sun, 23 Nov 2014 15:45:48 +0100
Subject: [PATCH 4/5] Update PXELINUX modules to be in sync with PXELINUX
itself.
---
di-netboot-assistant | 12
1 file changed, 12 insertions(+)
diff --git a/di-netboot-assistant b/di-netboot-assistant
index 7b93e11..d581507 100755
--- a/di-netboot-assistant
+++ b/di-netboot-assistant
@@ -919,6 +919,18 @@ setup_syslinux() {
if ! copy_syslinux_bin $expand_dir $TFTP_ROOT/debian-installer/ ; then
echo E: No PXELinux menu installed. Please file a bug. 12
fi
+ # ensure only a single PXELINUX version is used for all its modules
+ for f in $(find $expand_dir -type f -name '*.c32'); do
+ case $(basename $f) in
+ vesamenu.c32|menu.c32)
+ cp -pft $(dirname $f) $TFTP_ROOT/debian-installer/pxelinux.cfg/$(basename $f)
+ ;;
+ *)
+ echo W: Unusual PXELINUX module \$f\ may not work. 12
+ continue
+ ;;
+ esac
+ done
for f in $(find $expand_dir -type f -a \( -name default -o -name boot.txt -o -name '*.cfg' \) ); do
mv $f $f.ORIG
--
2.1.3
From 0a3af696406e8cb5e6f695d43118696d940ca2b9 Mon Sep 17 00:00:00 2001
From: Jonas Smedegaard d...@jones.dk
Date: Sun, 23 Nov 2014 13:11:08 +0100
Subject: [PATCH 1/5] Extend find_file() to support multiple paths (and fix
order of arguments in comment while at it).
---
di-netboot-assistant | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/di-netboot-assistant b/di-netboot-assistant
index 88c06f7..f85e381 100755
--- a/di-netboot-assistant
+++ b/di-netboot-assistant
@@ -200,12 +200,13 @@ print_do_not_edit_header() {
# #
# find_file()
# Return the name of the first file matching criteria.
-# Parameters: dir name
+# Parameters: name dir [dir...]
# Returns: (STRING) file
# #
find_file() {
if [ $1 -a $2 ]; then
- find $2 -type f -name $1 | head -n 1
+ local name=$1; shift
+ find $@ -type f -name $name | head -n 1
else
echo
fi
--
2.1.3
From 3a7aac0058e7b643f91315c85863b4310c8828e2 Mon Sep 17 00:00
Re: Old-timer installer, task-sysvinit?
Quoting Wouter Verhelst (2014-11-23 14:15:27) On Sun, Nov 23, 2014 at 02:02:57PM +0100, Jonas Smedegaard wrote: Quoting Cyril Brulebois (2014-11-23 13:13:05) Well, I'm really unsure what you're calling inaccurate in the third point. It is that preseeding is the mechanism used - but I may indeed be wrong: I assumed the term preseeding meant debconf preseeding, but realize now that indeed both https://wiki.debian.org/DebianInstaller/Preseed and e.g. https://www.debian.org/releases/stable/i386/apbs01.html.en uses the term without direct ties to debconf. Both those documents do, however, describe [not-only-debconf] preseeding as a way to set answers to questions asked during the installation process. I consider preseeding to be feeding answers to questions before asked. Executing shell scripts is something else, IMO. You likely disagree. Implementation details, but: Debian-installer uses (c)debconf throughout, so debconf preseeding and installer preseeding are really one and the same thing. What you and I call debconf preseeding is then not the same thing. What I am talking about (now lacking a name for) is what you can feed to debconf-set-selections. Debian-installer extends that by providing a few debconf templates that are never shown to the user, but that *are* read by the installer and acted upon. Some of those are the early_command and late_command templates, which the installers assumes will contain shell snippets that it must execute. So yes, it's running shell scripts, but yes, it's also feeding answers to questions (albeit questions that will *not* be asked). You can only feed declarative info to debconf-set-selections - e.g. can (even machine automated) resolve the package to bug about it if any data fed like that causes problems on the system operated on. You cannot do that for any user-written shell code. Please cc me on replies. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Old-timer installer, task-sysvinit?
Quoting Cyril Brulebois (2014-11-23 14:31:00) Jonas Smedegaard d...@jones.dk (2014-11-23): If you're unhappy about the initial systemd installation, that's too bad, because we're not going to change debootstrap, especially not at this late stage of the release cycle, to behave differently depending on the target distribution. The current script covers all suites from etch (etch, lenny, squeeze, wheey, jessie, and now stretch), and it'd really be nice if that could stay the case. I am unhappy about the need for messing non-declaratively with debian-installer in order to override default choice of init system. It is nice that debian-installer provides hooks to do dangerous things, but I find it worrisome that changing init system involves use of that. I'm not sure why you're considering or calling preseeding “dangerous”. Use of a root shell can turn a Debian system into a non-Debian system (by messing with the system in ways not following our defined rules). Blame is on the user for doing so. Typos are unsupported. Use of declarative hints should make it hard to do the same. I would expect it to be treated as a bug if some hint wreaks havoc without at least popping up a strong warning first. Blame is on Debian. We support _using_ our system through the interfaces we provide - but some interfaces are less governed by us, hence more dangerous to use. I consider it more dangerous to tell users to operate a root shell than have them type declarative hints. Both gets processed as root, but the latter is far less likely for typos or misunderstandings to wreak havoc. There won't any more debconf, udeb, or whatever addition going to happen. It means additional work (nobody has been doing that for a whole release cycle), more maintenance, and… it's just too late. Why do you say for a whole release cycle? Only late in the release cycle did init system become changeable without violating policy (removing core packages). Init systems have been a hot topic for most of the release cycle, with #727708 being finally referred to the tech-ctte in october 2013, meaning more than a year ago. Until 4 months ago, choosing a non-default init system required typing YES, I KNOW WHAT I AM DOING or something similar, due to requiring removal of a essential package. It is therefore no surprise to me that the idea of avoiding init from debootstrap comes up now rather than a year ago (for starters, that package didn't exist back then). It looks to me that people demanding so badly that debootstrap and/or d-i accomodates for their init system of choice should have started sending patches (to make init systems interchangeable or to support “choice” in debootstrap/d-i/etc.) way ahead of the freeze. Way ahead of the freeze we talked about changing default init. I assumed that was similar to change of syslog daemon - i.e. if you want something else than the default (which is in Debian and stable and does not conflict with other things you also want) then you can have that through ordinary standard Debian ways. Only few months ago did I realize that this default is different from other default packages, in that you cannot pick alternatives through standard package selection interfaces, but must use a free-form root shell. Only now, today, do I realize that I am not even welcome to help work on creating workaround declarative interfaces - only option is shut up, get in line it seems. I dearly hope I misunderstood you there. Oh, and please, I do not demand anything here. We are just talking :-) Please cc me on replies, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#759424: di-netboot-assistant: please update package for jessie / new syslinux
Package: di-netboot-assistant
Followup-For: Bug #759424
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Attached is a patch believed to fix all issues related to new syslinux:
* Lookup pxelinux.0 in /usr/lib/PXELINUX (not only /usr/lib/syslinux).
* Lookup only BIOS binaries (not accidentally include EFI binaries).
* Install core modules at tftpd root dir.
* Keep vesamenu and menu modules in sync with PXELINUX.
- Jonas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQF8BAEBCgBmBQJUbnZLXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWlDkH/2evg6qc0Jf8Ho/BHtNw8uEZ
MVMUq4+xD+ziLDSSVKfFCfn17SnypXLxPzDBVQ4SoLv1W6+AnTHs5ExaQ2KzgJZy
9qJueFkpDGBY0G6A/IUqjwTEvmN5L0FS4MxjACbswNIlCnkvnlixVnhxNonF5kS5
q6fkbJ+M9XZNYxaMJN9croUV7KsnOGZhVJg6Rk7Mu3FUv4xzhY3+U0HHV1by2TI3
H9qNvC1/DVJ/8oGgFgu39G5cDdSMW8kyhebE5r6X+HP7g8zJT4EYIfeaP+gBQO0g
ZYU0GUw0fshmEKmosXw77EUtvAcXQzfytprDsMEVrP179dTHW1Q5RjfW7ggYrWE=
=m57Q
-END PGP SIGNATURE-
--- di-netboot-assistant.orig 2013-07-13 10:31:11.0 +0200
+++ di-netboot-assistant 2014-11-20 22:50:18.151437802 +0100
@@ -200,12 +200,13 @@
# #
# find_file()
# Return the name of the first file matching criteria.
-# Parameters: dir name
+# Parameters: name dir [dir...]
# Returns: (STRING) file
# #
find_file() {
if [ $1 -a $2 ]; then
- find $2 -type f -name $1 | head -n 1
+ local name=$1; shift
+ find $@ -type f -name $name | head -n 1
else
echo
fi
@@ -241,7 +242,14 @@
[ ! $src -o ! $dst ] return 1
- newbin=$(find_file pxelinux.0 $src 2/dev/null)
+ if [ $SYSLINUX = $src ]; then
+ # avoid recent SYSLINUX EFI binaries incompatible with PXELINUX
+ [ ! -d $src/modules/bios ] || src=$src/modules/bios
+ # recent SYSLINUX ships PXELINUX at separate location
+ newbin=$(find_file pxelinux.0 /usr/lib/PXELINUX $SYSLINUX 2/dev/null)
+ else
+ newbin=$(find_file pxelinux.0 $src 2/dev/null)
+ fi
[ ! -f $dst/pxelinux.0 -a ! -f $newbin ] return 1
pxe_new_ver=$(pxelinux_version $newbin)
@@ -253,7 +261,11 @@
echo I: Upgrading PXELinux ($pxe_cur_ver to $pxe_new_ver)
for f in pxelinux.0 menu.c32 vesamenu.c32; do
- srcf=$(find_file $f $src)
+ if [ pxelinux.0 = $f ]; then
+ srcf=$newbin
+ else
+ srcf=$(find_file $f $src)
+ fi
[ ${f#*c32} ] || f=pxelinux.cfg/$f
[ -L $dst/$f ] rm $dst/$f
if [ -f $srcf ]; then
@@ -264,6 +276,13 @@
done
# Smooth transition to vesamenu
[ ! -f $c32_dir/menu.c32 ] ln -s vesamenu.c32 $c32_dir/menu.c32
+ # Add core modules at root (see https://bugs.debian.org/756275#49)
+ if [ $TFTP_ROOT/debian-installer/ = $dst ]; then
+ for f in ldlinux.c32 libcom32.c32 libutil.c32; do
+ srcf=$(find_file $f $src)
+ [ -z $srcf ] || cp -np $srcf $TFTP_ROOT/$f
+ done
+ fi
return 0
}
@@ -907,6 +926,21 @@
if ! copy_syslinux_bin $expand_dir $TFTP_ROOT/debian-installer/ ; then
echo E: No PXELinux menu installed. Please file a bug. 12
fi
+ # ensure only a single PXELINUX version is used for all its modules
+ for f in $(find $expand_dir -type f -name '*.c32'); do
+ case $(basename $f) in
+ vesamenu.c32|menu.c32)
+ cp -pft $(dirname $f) $TFTP_ROOT/debian-installer/pxelinux.cfg/$(basename $f)
+ ;;
+ ldlinux.c32|libcom32.c32|libutil.c32)
+ cp -pft $(dirname $f) $TFTP_ROOT/$(basename $f)
+ ;;
+ *)
+ echo W: Unusual PXELINUX module \$f\ may not work. 12
+ continue
+ ;;
+ esac
+ done
for f in $(find $expand_dir -type f -a \( -name default -o -name boot.txt -o -name '*.cfg' \) ); do
mv $f $f.ORIG
Bug#767773: tasksel: task-german should include iswiss
Source: tasksel Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Seems most sensible to me that package task-german recommends iswiss, similar to how task-english recommends both american and british. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQF8BAEBCgBmBQJUVma2XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0 RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWwKwH/i27ZQH5kSXXMjSMcshd3sab yuClpL5s3Z2ROmZylc0flEyAz4ug7p8hnhHj0HBLlt86hlfaGBy8FvWHOoDSekVy Bqp+krZ8RoRNlL3HpzNcmvwu2BPftacPkPmqXKJO8h9x/jxHfz3ueDSdDWvR3pAZ fnyJrc4iov7CpWZayix/26af2NCd9PRpNFQsHmb5gmQ5EcA5XyNBp41LDGXfkAID CFKAKG0gfycVt8TupOHI5Hcy4cbvyDfgStYjtVCQL6hsfEC0CfN9nhUeHL2I/7oU DGYV4gv941vPnHoKgeus2DcHUkzLzNsLC4Osqe9Ab8QPeCX7Y2gSyybnuDGJvbE= =xkFy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141102171537.25293.4943.report...@bastian.jones.dk
Bug#767779: task-danish: please include and favor myspell-da in task-danish-desktop
Package: task-danish Version: 3.29 Severity: normal Tags: l10n -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Both hunspell-da and myspell-da satisfies the functionality of a danish dictionary usable with Iceweasel, Icedove and LibreOffice. Difference between those packages are, I believe (I will update long description of myspell-da package when verified) than myspell-da uses a larger dictionary and has a stronger copyleft license - the latter likely the reason why the dataset have not been reused for hunspell-da). Icedove-l10n-da already favor myspell-da, currently leading to different package being installed depending on order of packages getting resolved. Please therefore add myspell-da as favored alternative to hunspell-da. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQF8BAEBCgBmBQJUVnD2XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0 RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWeqsIAKIzpcOvdAuAh1edFqHHOrlV 3VrwP8t7xABqgf1suC6r0xoCDst8ZTHXHsmI+Bfded3x2LaTSmnhSL6R0kF7iE6+ q2D2ij4LCiDbO84C33ePxqcKUAE2qPDYuKl7WSJrjheB8H23sP5mKXvA5tiNYaBH 5HwlQLIIq+iRA+yOMx/YoXaMAIHWDtVxra7jZTocRAnfijnkZqP6Th9/eQCvsJRk 02/Cld+4exLLv9kt7r+wEDd1NSReppT1WX73mJLgN46rK8j6PfEAr8WYBz/Qw9mi qQQeMmoM+zuAjSYu+Vo9ENYAqaqy96k7R6020o0sH85L7uj/2js1t2fXlAyVT4I= =gZTF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141102175921.25599.17026.report...@bastian.jones.dk
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Quoting Andreas Tille (2014-10-16 08:47:19) On Wed, Oct 15, 2014 at 07:49:32PM +0200, Bas Wijnen wrote: On occasion, I've needed a single-use system; something that boots up into an application and that shuts down when that application exits. (Having the full power of Debian in the background is a nice feature, but mostly unused.) For example, for dancing rehearsal I want the instructors to be able to switch their computer on and have the sound program start up without any interaction. It isn't hard to set this up, but if I want to tell other dancing instructors how to do this, it requires more steps than I would like. I've tried making custom live CDs, with a special package that does these things. Would this use case also be a reason for creating a personal blend? Or even an official one? Jonas has answered this question. I'd like to add that I'm no fan of personal things since you spoil the idea of forming a team around the idea. I could perfectly imagine such a Blend and every specific application is a separate task (in the Blends slang). So you can assemble those people with the goal to run one dedicated application. And I fully agree with Andreas: I assumed you were talking about Debian Blends as defined at https://wiki.debian.org/DebianPureBlends#Terminology and that you therefore really a generally reusable Blend (sparked by personal _needs_ which I see as a perfectly fine drive for creating a Debian Blend). I am sorry if I twisted your meaning. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Quoting Bas Wijnen (2014-10-15 19:49:32) On occasion, I've needed a single-use system; something that boots up into an application and that shuts down when that application exits. (Having the full power of Debian in the background is a nice feature, but mostly unused.) For example, for dancing rehearsal I want the instructors to be able to switch their computer on and have the sound program start up without any interaction. It isn't hard to set this up, but if I want to tell other dancing instructors how to do this, it requires more steps than I would like. I've tried making custom live CDs, with a special package that does these things. Would this use case also be a reason for creating a personal blend? Or even an official one? What would be the easiest way for people to install a non-official blend? Should I create my own installer? Should the installer be changed to allow entering a URL (for an external apt source) before it presents the list of available blends? (I think this might be a good idea, but it shouldn't be in there by default; only when the user selects back on the blend selection menu. Or perhaps there can be a button in that menu for opening the dialog, but if it's for adding any apt repository, the blends dialog is not the right place for it.) That sounds like an excellent idea for a Blend! You raise a bunch of questions on how that idea should be implemented and work out in details - but that has is open for you as driver of a Blend to figure out. If you do decide to start create above as a Blend, and would be interested in collaborating (with me), please do count me in! I have fumbled with a few ideas in the past that seems to fit perfectly to above (e.g. a dead-simple videophone PhoneHome dialing a hardcoded number, or a party jukebox with a touch keyboard (no avoid spilling liquids into a real keyboard, or a gaming box to pacify visiting kids, or...). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)
Quoting Bas Wijnen (2014-10-14 19:19:36) I have heard about [Blends] for quite a while, indeed, but I must say that I never entirely understood what they are. I'm guessing I'm not alone in this. So let me write what I think they are, and then you can correct me. I've read the explanation on the wiki, but I'm still not sure if I understand it right. [snip] This is the canonical definition: https://wiki.debian.org/DebianPureBlends#Terminology If that's the text you found confusing, please do help by elaborating what was confusing about it. Well, Blends and the desktop situation could be considered orthogonal. Do all blends work well with all desktop environments? No. I can see how some blends would focus to make things work perfectly with one of them only. In such a case, it makes sense to omit the desktop selection after such a blend is selected, or at least let the blend define the default. Good point! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#758116: Please be verbose whether you would like to get your Blend promoted by tasksel
[dropping persons from recipients, and adding bug#311188 ] Quoting Steven Chamberlain (2014-08-28 14:05:22) On 28/08/14 00:53, Holger Levsen wrote: On Mittwoch, 27. August 2014, Mike Gabriel wrote: I guess this only makes sense if a Debian Edu machine (standalone) can be installed via Debian's normal D-I, right? why? and why limit this to stabalone? Do the regular Debian Edu installers do some special configuration before the tasksel stage? Might this be too late in the installer to correctly install at least some of the machine types? The package debian-edu-install ships /etc/init.d/xdebian-edu-firstboot, registers debconf question debian-edu-install/run-firstboot, and checks for magic file /etc/debian-edu/xdebian-edu-firstboot.. The package debian.edu-config ships a range of CFEngine scripts and /usr/share/debian-edu-config/tools/run-at-firstboot. Above mechanisms stay dormant, however, unless triggered correctly - i.e. when installed on a normal system, nothing (bad) happens[1]. One answer to your question could therefore be a simple no. [1] https://bugs.debian.org/bug=311188#217 ...another more descriptive, I believe, answer could be You don't really have a Debian Edu system when installing it on a Debian system. I believe that second elaborated view is the reason for Mike's question. To me it is far from perfectly sense to offer Debian Edu in debian-installer to get some educational software - I would expect to get a Debian Edu system. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#758116: Please be verbose whether you would like to get your Blend promoted by tasksel
[ replying only to bug + list - hope all are subscribed ] Quoting JOSEFSSON Erik (2014-08-26 16:27:43) Hello! (sorry for top posting) Feeling sorry is no use. Consider at least strip fullquote next time. DebianParl is a blend that could also be in taskel, no? https://wiki.debian.org/DebianParl DebianParl is a blend, yes, but currently not defined by metapackage(s) so cannot technically be included in tasksel. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Reverting to GNOME for jessie's default desktop
Quoting David Weinehall (2014-08-10 22:59:45) On Fri, Aug 08, 2014 at 11:10:50AM +0200, Jonas Smedegaard wrote: The issue here really is how big is it? rather than hos many disks [of which kind] does it fit onto?. unable to fit on a single image is not only about use of said storage devices for installation, but also an indication more generally of how much data needs to be transfered on average for a usable installation. Quite a few places in the World have poor and/or expensive internet access. Larger default desktop will hurt the most in developing countries: non-techies gets discourages to use Debian at all, or when using it may apply security fixes less often. In all cases where I'm stuck with expensive (and/or slow) Internet I sure as hell pick the netinst image and download the minimum set of packages I need, rather than a whole CD image on the offhand chance that I might need everything on it (which is exceedingly unlikely). [remark about actual CD use rather than desktop size measure snipped] So, as long as GNOME fits on the first installation CD I see no reason not to prefer it over XFCE. I do: I see a reason to netinst a 0.629xCD size desktop install rather than a 0.829xCD size desktop when bandwidth is costly. (numbers above are made up - just to illustrate that I am talking about the size of the desktops, not actual concrete CDs or DVDs or Blueray disks. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Reverting to GNOME for jessie's default desktop
Quoting Olav Vitters (2014-08-11 11:21:14) On Fri, Aug 08, 2014 at 11:10:50AM +0200, Jonas Smedegaard wrote: Quite a few places in the World have poor and/or expensive internet access. Larger default desktop will hurt the most in developing countries: non-techies gets discourages to use Debian at all, or when using it may apply security fixes less often. How poor is poor? Poor enough that they bother visitors coming from different places in the World asking them to please consider bring install data by sneakernet (e.g. on CDs but could just as well be floppies or uSD storage embedded in iPhones - physical media type not important). I call it bother not because I have experienced actually being bothered by such request, but because I have experienced being treated like a king in India and Indonesia yet asked that - surprising to me - requst. I've been participating since having a theoretical 64KB/s cable connection, which in practice only did 3-5KB/s (provider: BART in Rotterdam)! A cd would take about 24 hours to download (net install was sometimes unreliable, so I preferred a cd). Having a poor connection means you get creative. I shared the cd's I downloaded, used rewritable to push the cost down, etc. How poor was that example of poor? I've checked http://explorer.netindex.com/maps which shows the Speed test results across the world. According to that site, the minimal speed I can see in various African countries is at least 0.75 Mbps. Much higher than the speed I was used to. How expensive is such average speed? Not measured in dollar, but measured in something more locally tangible, like work hours? Always having a slow connection changes means you're tolerance level is different. I used to download a cd in 24 hours. Nowadays the same takes maybe 35 seconds. Still you are talking about cost in time. Few I have met in developing countries were poor measured in time available. I don't get the doom and gloom unless you're more clear. Please elaborate what is unclear. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Reverting to GNOME for jessie's default desktop
Quoting Gunnar Wolf (2014-08-08 05:34:29) One of the reasons put forward for switching to Xfce was size on the installation images; could you (and/or debian-cd) address this? Specifically: 1) Would you want the default CD/DVD image to use a GNOME even if GNOME was unable to fit on a single image? 2) Would the GNOME team consider a less-complete DE for cases where image size is a restriction? ...And I'd like us to consider this point as well: How important are CD images nowadays? Who has a CD that cannot read a DVD? Will they be able to use on said machine a modern desktop environment as resource-demanding as, say, i3 or fvwm? The issue here really is how big is it? rather than hos many disks [of which kind] does it fit onto?. unable to fit on a single image is not only about use of said storage devices for installation, but also an indication more generally of how much data needs to be transfered on average for a usable installation. Quite a few places in the World have poor and/or expensive internet access. Larger default desktop will hurt the most in developing countries: non-techies gets discourages to use Debian at all, or when using it may apply security fixes less often. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Reverting to GNOME for jessie's default desktop
Quoting Gunnar Wolf (2014-08-08 15:00:35) Jens Schüßler dijo [Fri, Aug 08, 2014 at 10:37:33AM +0200]: ...And I'd like us to consider this point as well: How important are CD images nowadays? Who has a CD that cannot read a DVD? You may visit some poorer people in the world. But hey, if they want CD-bread, why don't they just eat DVD-cake. Both Jens and Jonas answer with this assertion. Yes, I don't know most of the developing world — But I do live in a developing country (Mexico), and know quite well several countries in Latin America (including, say, Bolivia, Ecuador and Central America, where I have been to several times, and follow their communities' work). Yes, we do have quite a bit of outdated computers. But again, I said, half-jokingly, that computers with CD readers and without a DVD reader will not have enough power for a full desktop environment, such as i3 or fvwm. The last computer I had with a CD-but-not-DVD unit was in the 2003-2005 period. And yes, many such computers are currently in use. And it would be a disservice not to provide CDs anymore. But that criteria should not be what guides our default for installation; a CD might not be able to have the full GNOME environment, but the computer using the CD would not be able to use it anyway. I wonder if you still missed my point: Concern is not if computers are capable of reading DVDs, but the *bandwith* burden of installing and maintaining a larger desktop versus a smaller one. We can ship only netinst images - completely drop CD and DVD and Blueray, and I still find it problematic to favor GNOME over Xfce - due to its size - which just happens to be expressed in discussions as can it fit on a single CD?. The _default_ Debian desktop is what we implicitly recommend for our non-technical users, no matter the wealth of alternative offers we have. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Reverting to GNOME for jessie's default desktop
Quoting Olav Vitters (2014-08-08 15:51:13) On Fri, Aug 08, 2014 at 03:26:20PM +0200, Jonas Smedegaard wrote: I wonder if you still missed my point: Concern is not if computers are capable of reading DVDs, but the *bandwith* burden of installing and maintaining a larger desktop versus a smaller one. This feels like shifting goalposts. The initial change to XFCE mentioned the install size and that for some countries. A reply was given specifically on this matter from someone with knowledge on various affected countries. It was mentioned that install size is not so much of a concern. Now suddenly it is about bandwidth usage? That is not what was said initially. Seems you are talking about other posts than mine. What I said initially I still stand by. Did you read that? Further, I'd like to see you provide more details on the higher bandwidth usage that GNOME apparently has vs XFCE and how much it impacts these countries. The following is on a wheezy chroot: root@bastian:/# aptitude install task-gnome-desktop The following NEW packages will be installed: [...] Need to get 370 MB of archives. After unpacking 1099 MB will be used. root@bastian:/# aptitude install task-xfce-desktop The following NEW packages will be installed: [...] Need to get 115 MB of archives. After unpacking 348 MB will be used. Desktop needing 370MB versus 115MB seems pretty significant to me. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Reverting to GNOME for jessie's default desktop
Quoting Samuel Thibault (2014-08-08 16:19:28) Jonas Smedegaard, le Fri 08 Aug 2014 16:11:58 +0200, a écrit : The following is on a wheezy chroot: root@bastian:/# aptitude install task-gnome-desktop The following NEW packages will be installed: [...] Need to get 370 MB of archives. After unpacking 1099 MB will be used. root@bastian:/# aptitude install task-xfce-desktop The following NEW packages will be installed: [...] Need to get 115 MB of archives. After unpacking 348 MB will be used. Desktop needing 370MB versus 115MB seems pretty significant to me. Actually it's 1.1GiB versus 348MiB. But that is barring the rest of the desktop. If the concern was e.g. price of harddisk to install on, then the finally used disk space be the measure. ...but the concern I raised is bandwidth for packages to be installed - which over-simplified can be expressed as does it fit on a CD?. Numbers for Sid (in a chroot for task package, not for a full install), is 389MB versus 101MB. More precise measurements can be found in the installation manual, for which we also install task-desktop etc. which ends up with 3.2GiB for Gnome KDE, 2.3GiB for XFCE, 2GiB for LXDE. I believe (but haven't checked) that installation manual don't document bandwidth needs - in the past users could simply assume a single desktop fits on first CD. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: blends install preseeding?
Quoting Paul Wise (2014-03-03 16:31:06) I noticed on the wiki that the DebianParl blend is working on install preseeding. I think this is a particularly interesting approach that might be interesting for more blends to adopt. https://wiki.debian.org/DebianParl#Profiles https://parl.debian.net/desktop/email/ Thanks for taking an interest in DebianParl - even before I've made much fuzz about it myself. I have now updated those preseeding profiles to reference their source: git://git.debian.org/parl/blends One thing I noticed is that the firmware-linux package is non-free and thus should probably not be installed by default without user consent. Better would be a debconf dialogue asking if the user would like to include the formware-linux package - with No thanks as default. That would however involve injection of more code into the debian-installer session than can fit in a preseeding file, I suspect. I'd love to learn that I am wrong and it can already be handled by debian-installer - I would also be interested in helping implement it, but I have too much on my plate already currently :-/ What I might do instead is give up on firmware-linux and for more more specific firmware check if any was used during install (e.g. using firmware-* netboot image or feeding firmware udebs from a separate USB stick) and if so install correspondent firmware packages (without asking). Looking at your preseed/late_command, I noticed that you did something I wanted to do, marking packages as auto-installed. I filed #730162 and #739938 about this issue. It appears there is a clear need for this feature since now a blend is doing it. I wonder where the fix belongs, perhaps in debootstrap? Ohh - you did something I wanted to do: File appropriate bugreports! My plan is that each tweak has a bugreports tracking its obliteration. You just eased my initiating that plan: Bugreports now added to source. To work around lack of this feature in d-i we are using this hack right now for our installs at work. It is more generic but more hacky than the approach taken by DebianParl. Your approach seem *too* generic for my taste (and possibly the reason bug#730162 was rejected): I don't want *all* apt-install installation flagged as auto-installed (and then partly reverted by fixating another way). I only want supposedly auto-installed packages flagged as such. What I mean by supposedly? Possibly all non-leaf packages, but pretty certain it includes all libraries and base packages. Another related but inverse issue, now that we are talking about it, is that of recommended packages missed: libuuid1 recommends uuid-runtime, and bash recommends bash-completion, neither of which are installed by default. You already filed a bugreport for that one too, Paul? ...and the bash skeleton supports the root user but custom files are installed instead. I intend to work around that e.g. in DebianParl, so expect a bugreport on that when I get around to it (if someone haven't beaten me to it). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Wheezy release: CDs are not big enough any more...
On 12-05-14 at 11:22am, Marco d'Itri wrote: On May 14, Jonas Smedegaard d...@jones.dk wrote: It is my impression from my visits in the Fall (although I do not have any hard data to support it) that in India and Indonesia network access is generally so slow that even if computers have DVD drives the common media downloaded and used is CD. This does not look like a great argument: when your internet access is really slow then you either download one image and share it between user (and then it does not matter if it is a CD or DVD, since the incremental cost per user is negligible), or you just download the netinstall image to minimize the number of bytes you need to download from the network to what you strictly need (yes, I did a few modem netinstalls...). Yes, computer resources and software can be dealt with more sensibly and efficient than is currently practiced at many places in the World. Yes, I have also installed whole networks via 28.8 modem quite some years ago. But question was if people are known to routinely try to install desktop systems with only a CD and no networking, and I shared my insight on that. I wish people would collaborate more. I wish people would care more about efficient use of resources. I did not claim that there was great sense behind that usage pattern, but I do claim that it is reality in some parts of the World. But until let's make Debian easy available also for those who are not yet as wise and clever as ourselves. Let's keep providing CDs as install medium, because it is still relevant for some (and, I vaguely feel, not only exotically few) real use cases to install non-bloated desktop at places with flaky/expensive Internet. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Wheezy release: CDs are not big enough any more...
On 12-05-13 at 10:26pm, Lisandro Damián Nicanor Pérez Meyer wrote: On Dom 13 May 2012 21:40:10 Marco d'Itri escribió: [snip] Does anybody actually know that people routinely try to install desktop systems with only a CD and no networking, and why? What is the use case for this? Cheap DVD readers have been around for over 10 years now. Actually, I was going to ask exactly that. To the best of my knowledge, CDROM players have been out of stock for a while (more than two years?) Normally people will buy a DVDROM player. Well, at least here in Argentina :-/ It is my impression from my visits in the Fall (although I do not have any hard data to support it) that in India and Indonesia network access is generally so slow that even if computers have DVD drives the common media downloaded and used is CD. Could it be reasonable to drop graphical desktops environments for one-CD installs? If you want a GDE, get the DVD. Or two or more CDs. If those interested in the big desktop environments are ok using DVD, what is then the problem in putting light desktop environment on CD1? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#631390: debootstrap bug#631390 maybe tied to APT/fakeroot bug#630591?
Hi, As subject says, maybe this issue is tied to APT/fakeroot bug#630591? For d-shlibs I found a workaround of fakeroot apt-cache ... by replacing with fakeroot apt-cache --no-generate ... which is supported at least as far back as Lenny. Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#604100: tasksel: Please readd netatalk to file-server task: protocol not _too_ old
On Sat, Nov 20, 2010 at 01:20:35PM +0100, Samuel Thibault wrote: Jonas Smedegaard, le Sat 20 Nov 2010 07:05:45 +0100, a écrit : Maybe this is carefully thought out, I don't know. I don't know since there is no reference to a bugreport or anywhere else this have been discussed. Here is the start of the discussion: http://lists.debian.org/debian-devel/2010/10/msg00313.html Note that the perl needed for netatalk can be moderated by the fact that the standard task will install perl anyway. Thanks for the reference. Still seems weird to me to drop netatalk: What is the purpose of file-server task if not serving files in a heterogenous network? I mean - _specific_ file serving tasks are done by selecting a specific fileserver, no? Seems that those in favor of ditching it have no interest in heterogenous file-sharing at all, judging from those posting to the subthread. Is this late change targeted squeeze? For Squeeze+1 - if anyone cares - I intend to split file-sharing from printing routines (which are the ones depending on Perl) and switching to backgrounding the daemon startup by default as is done in Samba. Those seem to be the only real complaints against netatalk - the one about netatalk being obsolete is bogus IMHO! I strongly recommend you guys to reconsider! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#604100: tasksel: Please readd netatalk to file-server task: protocol not _too_ old
On Sat, Nov 20, 2010 at 03:35:56PM -0400, Joey Hess wrote: Jonas Smedegaard wrote: Even if the historical underlying network protocol, Appletalk, have been abandoned by Apple for quite some time, netatalk also works on top of tcp, and is is in active use among Macintosh users, I believe: It is an essential part of the backup routine time machine. Doing so seems to involve: * Rebuilding netatalk with ssl support (impossible to do in debian due to license incompatability; #565969) Unneeded for recent versions of MacOS X: Recent netatalk supports newer encryption scheme DHX2 which do not require OpenSSL and thus is enabled in Debian builds. You may notice that bug#565969 has been closed :-) * Manually configuring avahi to advertise the netatalk server (bug #566114 asks that this be done by default) (And avahi was never installed as part of the file-server task.) True for timemachine, not for plain filesharing. * Creating a magic file (.com.apple.timemachine.supported) to make time machine deign to use the volume. True for timemachine, not for plain filesharing. * Hope and pray, since all the documentation about people doing this seems to date from 2007-2008, and who knows what has broken since then. Possibly true for timemachine, not for plain filesharing. This does not seem to be at a level of integration suitable for tasksel. Probably one or two steps could be skipped to use netatalk as a generic file server for OS X, without time machine. But since OS X can use both NFS and SMB as a client, apparently trivially, supporting a third protocol in the file-server task seems unnecessary. (BTW, time machine can also be used with NFS and SMB.) I mentioned timemachine to point out that Apple Filesharing seems not in the process of being phased out by Apple, even if MacOS X also supports alien filesharing protocols. There are benefits using a native filesharing protocol, similar to the benefits of using ext[2-4] locally instead of vfat. So my argument stand: If the purpose of the file-server task is to offer support for heterogenous filesharing, then I recommend to keep including netatalk. It actually makes *better* sense to do now than with Etch due to the DHX2 encryption added after the Etch release! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#604100: tasksel: Please readd netatalk to file-server task: protocol not _too_ old
Package: tasksel Version: 2.85 Severity: normal Hi, I notice netatalk being dropped from file-server task in 2.85. Maybe this is carefully thought out, I don't know. I don't know since there is no reference to a bugreport or anywhere else this have been discussed. I am the current package maintainer of netatalk, and find it somewhat odd that you judge it as irrelevant due to being old. Well, smb is old too, so I suspect the real qualifier is if it is commonly in active use. Even if the historical underlying network protocol, Appletalk, have been abandoned by Apple for quite some time, netatalk also works on top of tcp, and is is in active use among Macintosh users, I believe: It is an essential part of the backup routine time machine. So please consider reenabling netatalk in the file-server task. And please consider involving the package maintainer of packages you consider dropping in the future :-) Kind regards, - Jonas -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.36-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tasksel depends on: ii aptitude 0.6.3-3.2 terminal-based package manager (te ii debconf [debconf-2.0] 1.5.36 Debian configuration management sy ii liblocale-gettext-perl1.05-6 Using libc functions for internati ii tasksel-data 2.85 Official tasks used for installati tasksel recommends no packages. tasksel suggests no packages. -- debconf information: tasksel/title: tasksel/desktop: gnome tasksel/first: tasksel/tasks: -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101120060545.19505.798.report...@localhost.localdomain
Re: discover-data_2.2010.10.14_i386.changes is NEW
Hi Petter and others, On Sun, Oct 17, 2010 at 12:14:03PM +0200, Petter Reinholdtsen wrote: On Sonntag, 17. Oktober 2010, Holger Levsen wrote: would you mind reuploading the package, at least with reverting the debhelper compatibility change? probably also the python depends change... ? Why would you want to change this? I have no problem with that, but it is completely useless to change it back. The debhelper change lift the built compat level from a obsolete version to a supported version without changing the binary package at all (I ran debdiff to verify this), and adding the python suggests keep lintian happy without changing the package behavoiur. Both changes were done to get rid of lintian warnings, and dropping them will reintroduce the lintian warnings without changing the binary package in any way that affect installations (the only binary package difference is 'Suggests: python' in the control file). Related to this, although not directly (discover-data does not use CDBS): Beware that testing binary results on sid may not reveal all possible problems. In particular, bumping debhelper compat level from 6 to 7 for packages using CDBS may show no difference when building on sid and still fail in certain situations if rebuilding on Lenny, due to CDBS only fully supporting debhelper compat level 7 since 0.4.85. Release managers are known to treat FTBFS-on-stable bugreports as non-RC, and you may similarly not care about backporting, but Debian Policy is suite-agnostic in its requiring correct package dependencies. Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Preparing linux-2.6 2.6.18-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 21 Sep 2006 12:58:14 +0200 Frederik Schueler wrote: On Wed, Sep 20, 2006 at 06:16:32PM -0700, Steve Langasek wrote: On Wed, Sep 20, 2006 at 03:38:50PM +0200, Frederik Schueler wrote: Second: this release contains ALL binary firmware blobs shipped upstream, even those we kept pruning since the day Herbert Xu removed them the first time in 2004. What in the world? Why would you do that anyway? because removing firmwares without an adequate alternative means not considering the needs of our users which rely on these firmware blobs to run their hardware, and thus IMHO conflicts with section 4 of the social contract. Neither is introducing regressions in the freeness of our kernel packages relative to sarge. pruning the firmware without an alternative was wrong in the first place, this step just fixes that error. Indeed, taking such a step is likely to lead many voters to think that the only way to prevent the kernel team from filling our kernel packages with as much non-free code as they can stuff into it is by voting down any GRs that would relax our stance on firmware. *THAT* would cause release delays. This would be a gross overreaction, and if this happens, I will opt for moving linux-2.6 to non-free until the firmware issue is sorted out *completely* with upstream and the hardware vendors. I honestly believe that moving linux-2.6 to non-free hurts our users more than stripping non-free parts of the Debian-precompiled kernel. Also, section 4 of the SC talks equally about users and free software, not users above free software. Then again, you can argue that binary blobs are not software, so the section is really about users above anything but what you choose to define as software... :-P But wait: If our main concern is our users and free software, and binary blobs are not software, then users of binary blobs are not *our* users, and we don't favor them. Let the flamewar continue - I promise to not respond any more to this thread! - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFEotBn7DbMsAkQLgRAkrCAJ4kUA9DTfb5zrvubPi53l7lj5XLLQCghZrE AD90Dz26w+U6YnopxCwWrCs= =CWri -END PGP SIGNATURE-
Re: Preparing linux-2.6 2.6.18-1
On Fri, 22 Sep 2006 11:16:02 +0200 Frederik Schueler wrote: On Thu, Sep 21, 2006 at 02:53:21PM +0200, Jonas Smedegaard wrote: I honestly believe that moving linux-2.6 to non-free hurts our users more than stripping non-free parts of the Debian-precompiled kernel. of course. Also, section 4 of the SC talks equally about users and free software, not users above free software. And free software above the needs of our users neither. And exactly this is what it is all about: find a way to satisfy BOTH priorities, not just one. No. It is about the definition of our users. If our users are dependent on non-free software, then we indirectly say in our social contract that free and non-free software is of equal concern to us. (I deliberately take the example of non-free software instead of of firmware, to simplify my argument) I claim that our users does not include users of non-free software. I would even say that such users are free-riders of free software, if their use is dependent on our system which is 100% free software. working together with upstream and the vendors to fix the issue is what we should do, I agree. That is exactly what we should do. Just as we should work together with the GNU people to fix what we consider problems with their free documentation license. But until those issues are solved, we need to rip out any and all parts of our system that we become aware of is in violation with our own rules. not ripping the blobs aout of the kernel and forgetting about their existence. I see no contradiction between working with upstream and ripping out bobs (until hopefully upstream is convinced in each case). I think none wants to forget. Guess which Distribution users who made a poor buying choice will not use again. Whatever you're hinting at, it sounds like their users, not ours. If we lose users due to removing questionable stuff from our distribution, then those users were, in my opinion, never really ours. They really truly wanted a different kind of system, and just ended up with ours due to misunderstanding or accident or whatever. - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgpKgeoOlcQwy.pgp Description: PGP signature
Re: Preparing linux-2.6 2.6.18-1
Arrgh! Please ignore my post a moment ago. In a moment of carelessness I forgot my promise of throwing no more flames in this thread :-( - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgp2nsQFlR3u6.pgp Description: PGP signature
Re: [Yaird-devel] RFC: swap on a LVM volume in debian-installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 22 Jun 2006 22:46:59 +0200 David Härdeman wrote: in debian-installer, there is a package - partman-auto-lvm - which can setup an entire disk to be used for the debian installation with the use of lvm for most partitions. Currently it sets up one boot partition, one swap partition and one lvm PV which is used for the rest of the partitions (usually root and possibly home depending on the recipe used). I'm currently considering whether to change partman-auto-lvm so that the swap partition is created as a lvm lv rather than a separate partition, and I'd like to ask for some comments and feedback before doing so. I believe newest release of yaird properly supports suspend-to-disk, including possibly different driver requirements than for the rootfs. I do not use suspend-to-disk myself, so welcome any feedback, positive and negative, on wether it actually works in all possible scenarios. If I somehow misunderstood the intend of this thread (and yaird being included in it), I apologize: Please then spell it out more clearly for me :-) You can update info directly[1] or report your findings to [EMAIL PROTECTED] Hope that this helps, - Jonas [1] http://wiki.debian.org/InitrdReplacementOptions - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEomatn7DbMsAkQLgRAkAGAJ9lt0+uhEsLKIRXRSn+0vSbtQ56OQCfe5yL L7CY7fyvIj2AQQKLO33Tgyc= =COzl -END PGP SIGNATURE-
Re: libapt-pkg-perl and libconfig-inifiles-perl perl dependency problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25-09-2004 19:17, Konstantinos Margaritis wrote: | So, please try to remove the perl dependencies from these packages Done for libconfig-inifiles-perl! Or more precisely: changed from (auto-included) perl to perl-base (to please lintian). ~ - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ ~ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBVdKTn7DbMsAkQLgRApeuAJ9sY2IJXg17qvfOyda72+8OwLcHnACeJiMY phi9vlRtFp+vZJdn21fxLYY= =HOmp -END PGP SIGNATURE-
Re: List of possible XkbModel entries per locale
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17-08-2004 23:25, Konstantinos Margaritis wrote: | Hi, I'd like to make a complete list of every X keyboard config for each locale. Hi Konstantinos, d-boot and d-edu! Please when crossposting (which seems relevant in this case) include a note on where you want responses targeted, in order to avoid a complete thread crossposted (which does _not_ seem fruitful to me). I have responded to d-i18n, and suggest others to do the same. Kind regards, ~ - Jonas P.S. Please Cc me if responding to this message, as I am not member of (all of) the lists. - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ ~ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBIwHan7DbMsAkQLgRAiHhAKCYe699a2GZnPd2YhHEBKl5R4rg8gCgmApq tmgVNUD595ctcAZ44sg/HAI= =WKrd -END PGP SIGNATURE-
