Bug#1061402: ITP: ly -- a TUI display manager
Package: wnpp Severity: wishlist Owner: matt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ly Version : 0.6.0 Upstream Author : https://github.com/fairyglade * URL : https://github.com/fairyglade/ly * License : (wtfpl) Programming Lang: (C) Description : a TUI display manager lightweight TUI (ncurses-like) display manager for Linux and BSD. this package is useful to me because it's a tui display manager instead of a graphical display manager, it does not have dependencies for any other packages, I use it, emptty can be considered similar because it's not a graphical display manger however, it's a tui display manager instead of a cli display manager, I plan on maintaining it by compiling the latest package, I would need a need a sponsor
Bug#1061399: ITP: streamlink-twitch-gui -- A multi-platform Twitch.tv browser for Streamlink
Package: wnpp Severity: wishlist Owner: matt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: streamlink-twitch-gui Version : 2.4.1 Upstream Author : Sebastian Meyer * URL : https://streamlink.github.io/streamlink-twitch-gui/ * License : (MIT/X,) Programming Lang: (JavaScript) Description : A multi-platform Twitch.tv browser for Streamlink A graphical user interface on top of the Streamlink command line interface. Built with NW.js, a web application platform powered by Chromium and Node.js. - this package is useful to me because I don't need to open the browser to watch a twitch stream, it does not have dependencies for any other packages, I use it, gnome-twitch has similar functionality but is unmaintained and lacks features that streamlink-twitch-gui has example hiding vods, - I plan on maintaining it by compiling the latest package or use the appimage they provide, I would need a need a sponsor
Bug#1061336: ITP: chatterino -- Chatterino is a chat client for Twitch chat. It aims to be an
Package: wnpp Severity: wishlist Owner: matt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: chatterino Version : 2.4.6 Upstream Author : https://github.com/chatterino/chatterino2 * URL : https://chatterino.com/ * URL : * License : (MIT) Programming Lang: (C++) Description : Chatterino is a chat client for Twitch chat. Chatterino is a chat client for Twitch chat. It aims to be an improved/extended version of the Twitch web chat. - this package is useful to me because I don't need to open the browser to look at chat, it does not have dependencies for any other packages, I use it, gnome-twitch has similar functionality but is unmaintained and lacks features that chatterino has example banning seeing certain emotes, - I plan on maintaining it by compiling the latest package or use the deb they provide, inside a packaging team I would need a need a sponsor
Bug#1053415: ITP: vaticinator -- Python 'fortune' implementation/library
Package: wnpp Severity: wishlist Owner: Matt Barry X-Debbugs-Cc: debian-devel@lists.debian.org, m...@hazelmollusk.org * Package name: vaticinator Version : 0.0.4 Upstream Contact: Matt Barry * URL : https://github.com/hazelmollusk/vaticinator * License : MIT Programming Lang: Python Description : Python 'fortune' implementation/library The vaticinator package provides a Python reimplemention of the 'fortune' program. The 'vaticinator' command supports most/all of the functionality of the original; also provided is a library of reusable fortune cookie functionality.
Bug#1040047: ITP: discord -- All-in-one voice and text chat for gamers
Package: wnpp Severity: wishlist Owner: matt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: discord Version : 0.0.27 Upstream Author : https://discord.com * URL : https://discord.com/ * License : (custom) Programming Lang: (electron) Description : All-in-one voice and text chat for gamers Discord is a VoIP and instant messaging social platform. most foss servers have one example mint it is useful to ask for help there no there is nothing depending on this package it's standalone yes I do use it if there are other packages I don't believe that there are other packages that have similar functions .sh file that if there is a update download the update inside a packaging team the package team is discord it's self I am not looking for co maintainers yes because this is my first package
ITP: discord a modern voice & text chat app
Package: discord
Severity: ITP
Package name: discord
Version: 0.0.27
Upstream Author: https://discord.com
URL: https://discord.com
License: custom
Description: All-in-one voice and text chat for gamers
Copyright: https://discord.com/terms#7 depends=('libnotify' 'libxss' 'nspr'
'nss' 'gtk3') optdepends=('libpulse: Pulseaudio support' 'ibappindicator:
Systray indicator support' 'xdg-utils: Open files') source=("
https://dl.discordapp.net/apps/linux/$pkgver/$pkgname-$pkgver.deb";
"LICENSE-$pkgver.html::https://discordapp.com/terms";
"OSS-LICENSES-$pkgver.html::https://discordapp.com/licenses";)
sha512sums=('285a0119b4740402a3fa94d3679a52bc8d883413ee32187e90087960a4d34aaf316788d2708bbccafe3f995c2b99767b45bc4b7c731704ef887a8de1b3d3926f'
'1f6e773b9c971aebd5391c22c5e2deea7aa222e0fda240aefbe91c4eb526305972d17302d1f5eb806a9d308c7f029ae8a0549f61d8c2adb53e4fe4ba9cd60a61'
'2adc1404b49930a419eb6c5fbb0c64ebd0a5d797e54357539a093cc99355b10e9c002750dd6d8ab84156593b7cbc8884c1b7e396ac0c2c2b59fcbda2368ebd1a
Please let me know if you need any more info
ITP: discord a modern voice & text chat a
Package:discord
Severity: ITP
Package name: discord
Version: 0.0.27
Upstream Author: https://discord.com
URL: https://discord.com
License: custom
Description: All-in-one voice and text chat for gamers
Copyright: https://discord.com/terms#7 depends=('libnotify' 'libxss' 'nspr'
'nss' 'gtk3') optdepends=('libpulse: Pulseaudio support' 'ibappindicator:
Systray indicator support' 'xdg-utils: Open files') source=("
https://dl.discordapp.net/apps/linux/$pkgver/$pkgname-$pkgver.deb";
"LICENSE-$pkgver.html::https://discordapp.com/terms";
"OSS-LICENSES-$pkgver.html::https://discordapp.com/licenses";)
sha512sums=('285a0119b4740402a3fa94d3679a52bc8d883413ee32187e90087960a4d34aaf316788d2708bbccafe3f995c2b99767b45bc4b7c731704ef887a8de1b3d3926f'
'1f6e773b9c971aebd5391c22c5e2deea7aa222e0fda240aefbe91c4eb526305972d17302d1f5eb806a9d308c7f029ae8a0549f61d8c2adb53e4fe4ba9cd60a61'
'2adc1404b49930a419eb6c5fbb0c64ebd0a5d797e54357539a093cc99355b10e9c002750dd6d8ab84156593b7cbc8884c1b7e396ac0c2c2b59fcbda2368ebd1a
Please let me know if you need any more info
he/him
https://www.mattquintanilla.xyz/
-BEGIN PGP PUBLIC KEY BLOCK-
mQGNBGQZ3X0BDADSBAxrzn8C8pdCeovyCXnOJXkHazh14emOJoCdHQfeJe2EAn1q
QrPGySoD/KmB2UwaTI268pCbZvcWRHll+41Mp3iio0eHwuv6f5rSLv/0x406CkpK
BG7ZMmIW4N83O4dwNa7zZ5pnGjy9Qz57kPYZQJZV3MWPu4XDF57AYFImiZHttptK
4L3I8/rYqzLeI8R95/xs7DL/WoYQCs8F71JTsLEdZHpyrKhWHCGsHKpHhrGla8OH
w8xu4mVKptaq2uEWiBixfN7b5OIgVxYeAzzlB7yEpDTh3fxV24bvqel/SYhVFfdk
2XOcMTZj440FHukGcId9Kxy2wkONuzUQhfqwwhJOTm8lshI7dEtcuBYv4dryfxMd
j4QiSiiExBG7PSRQPZM+7B7LDfYUnHE/+kcnn7DkYyRulzt9CmNV2HR+nW6muVUl
d1mDB+XNF1ZCbEizd81Q037c15bQjlgNG/gWt8+iV9rtANEQDDo/1BcPwqLVFLZ6
G0La/Ry/VLPgAn0AEQEAAbQfbWF0dCA8bWF0dEBtYXR0cXVpbnRhbmlsbGEueHl6
PokB1AQTAQoAPhYhBFkPBLpKtqhISdj0TREQgaYmNzt8BQJkGd19AhsDBQkDwmcA
BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEBEQgaYmNzt8z74MAK6JCEaVAHcw
9eiioXUUQnPdXcEHC6w8SLraWmYHXrv6c62AGIpFTNigE/CdQzhkQOQK+nBM7e4a
h9lPydfF7HuOFKuW3ACF8aihTsEJMXexy7jMwWBe1YxLLzpJlCF5tIbJg4hBWjYc
prhvJBODyrLcrFQhN/ZlLTkJopzD4NZFbfjKkr9rar47z1mwjqOPsE1s5G5fW9SW
8IN+WZb88G6Ij5Yi+Kn3zpvks1QmGCrjYpjRoUbGLNQy6x0F6LP6m06rwe7XfoDP
GMy95VEoLBbSaXBnEWAt0zMqUM4aJMy0BjQC5rH9YK9Zrh8jap3dwXgeXZIUek/y
1F3TujlzWY/UQk0R5I5cl9KTf5Ui2IMxthxTsJdLMPNhXYNw0h1bbQKD1WtJNrDC
FtnZnhai00gpvW8rejrn35cCRlqgF/xbbshkyeWg1HdoOv90VuOrmJrvufJubsxw
K4KTQ5FCEsGiDBD0XbQayJyjScLUymXd0+hVigAX758tLw2JPAx3R7kBjQRkGd19
AQwA/yGbTn9M7FOf5CwFqWog2V+cf838yebTUOQ7/XP1CCIWcwqNVmkrv2ITpyhT
tYaoDSMGWFyATZD2QWkrR8mW/ykf7OyYJLiszbOqRuaiaxnJ5OHiu7PF6G1JxnFb
Yl6loHNkLSmyzINoHPIGpVP4H961lKTchRzZoqJOeq3YPBFVNxASHOk6nki2vZ/d
SDTGQB86JKfXl77jXBQQNb7zhVFvYbbjjWojX/oTwgJ+FkwWC3lXj0EKqaXDqogI
4CjgpYKYM+m84CMwFMiup2C0KR0lc32VdzA0nMSEbPlbZvqvQc1uazDyFMOKaBxu
psctcXrFyPo1vTH28FxlwrqS83fPvDuhFiqOZvD7cCt1r5JTHAv1rs0pzVUNL4vZ
xK3gpfd1x4HFONsxSxFVvMZOX02Oas7yX9VuoRBVit2kweP2isuosicysTZ4rVmB
ohaHxLQvfNWF0CHUOtQhS5TvpGShxKv7KZsKL0Va06LpC8uyxUBUupbwYuIXcOQe
lK5FABEBAAGJAbwEGAEKACYWIQRZDwS6SraoSEnY9E0REIGmJjc7fAUCZBndfQIb
DAUJA8JnAAAKCRAREIGmJjc7fOdeC/0aXJD59G5Nuj3zTEbC4uReeOJ6M0acY6Av
qeWKHyQDMPGNbvfodM7Y0YvMMX/7pMn+vHC7lmfwMrJun1Kbm3kO/+T3Ce3IowKe
tcIcvILKLuLaX+9b7f8UIGOF9skCq6Q59fPYSIPhOsk5qi47LijAoGmWjFecx+Nz
axvQwl8FgyytvGm3DwMbBScXLZ9CzdhymnFEBjRSXdSM2qTp3u8JaVMx0G7uxXmn
HAkVkBM18Jdm6f/inGFxz4nc+rl9fh1cm0+E3uG3VD68RRR4DJiOh1m7XMDTS4rs
dNgWrOdLZL29/JbCqZ1u5TQ31a20N3UbZDS7ecMMWTb8ZHSiKyBJe3Xi+clhM5P2
eXzra/gfqYTFmqQc8rDUyIDjQrzPM+tlbRKI5e2Gt60NbNvh6pNfZ2TARK2dah4o
UpVMiKdkEAXv3J2gCFxmpoIpM3PqjKH2KR8KgPBuxm6omTIOIdcSwLrkHlZ7vDJS
C0kqE4tqqff7X+VkRDKk0snjIAaUbDQ= =Dv2U -END PGP PUBLIC KEY BLOCK-
(970) 889-4559
Package:discord ITP: discord a modern voice & text chat app
Package:discord
Severity: ITP
Package name: discord
Version: 0.0.27
Upstream Author: https://discord.com
URL: https://discord.com
License: custom
Description: All-in-one voice and text chat for gamers
Copyright: https://discord.com/terms#7 depends=('libnotify' 'libxss' 'nspr'
'nss' 'gtk3') optdepends=('libpulse: Pulseaudio support' 'ibappindicator:
Systray indicator support' 'xdg-utils: Open files') source=("
https://dl.discordapp.net/apps/linux/$pkgver/$pkgname-$pkgver.deb";
"LICENSE-$pkgver.html::https://discordapp.com/terms";
"OSS-LICENSES-$pkgver.html::https://discordapp.com/licenses";)
sha512sums=('285a0119b4740402a3fa94d3679a52bc8d883413ee32187e90087960a4d34aaf316788d2708bbccafe3f995c2b99767b45bc4b7c731704ef887a8de1b3d3926f'
'1f6e773b9c971aebd5391c22c5e2deea7aa222e0fda240aefbe91c4eb526305972d17302d1f5eb806a9d308c7f029ae8a0549f61d8c2adb53e4fe4ba9cd60a61'
'2adc1404b49930a419eb6c5fbb0c64ebd0a5d797e54357539a093cc99355b10e9c002750dd6d8ab84156593b7cbc8884c1b7e396ac0c2c2b59fcbda2368ebd1a
Please let me know if you need any more info
he/him
https://www.mattquintanilla.xyz/
-BEGIN PGP PUBLIC KEY BLOCK-
mQGNBGQZ3X0BDADSBAxrzn8C8pdCeovyCXnOJXkHazh14emOJoCdHQfeJe2EAn1q
QrPGySoD/KmB2UwaTI268pCbZvcWRHll+41Mp3iio0eHwuv6f5rSLv/0x406CkpK
BG7ZMmIW4N83O4dwNa7zZ5pnGjy9Qz57kPYZQJZV3MWPu4XDF57AYFImiZHttptK
4L3I8/rYqzLeI8R95/xs7DL/WoYQCs8F71JTsLEdZHpyrKhWHCGsHKpHhrGla8OH
w8xu4mVKptaq2uEWiBixfN7b5OIgVxYeAzzlB7yEpDTh3fxV24bvqel/SYhVFfdk
2XOcMTZj440FHukGcId9Kxy2wkONuzUQhfqwwhJOTm8lshI7dEtcuBYv4dryfxMd
j4QiSiiExBG7PSRQPZM+7B7LDfYUnHE/+kcnn7DkYyRulzt9CmNV2HR+nW6muVUl
d1mDB+XNF1ZCbEizd81Q037c15bQjlgNG/gWt8+iV9rtANEQDDo/1BcPwqLVFLZ6
G0La/Ry/VLPgAn0AEQEAAbQfbWF0dCA8bWF0dEBtYXR0cXVpbnRhbmlsbGEueHl6
PokB1AQTAQoAPhYhBFkPBLpKtqhISdj0TREQgaYmNzt8BQJkGd19AhsDBQkDwmcA
BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEBEQgaYmNzt8z74MAK6JCEaVAHcw
9eiioXUUQnPdXcEHC6w8SLraWmYHXrv6c62AGIpFTNigE/CdQzhkQOQK+nBM7e4a
h9lPydfF7HuOFKuW3ACF8aihTsEJMXexy7jMwWBe1YxLLzpJlCF5tIbJg4hBWjYc
prhvJBODyrLcrFQhN/ZlLTkJopzD4NZFbfjKkr9rar47z1mwjqOPsE1s5G5fW9SW
8IN+WZb88G6Ij5Yi+Kn3zpvks1QmGCrjYpjRoUbGLNQy6x0F6LP6m06rwe7XfoDP
GMy95VEoLBbSaXBnEWAt0zMqUM4aJMy0BjQC5rH9YK9Zrh8jap3dwXgeXZIUek/y
1F3TujlzWY/UQk0R5I5cl9KTf5Ui2IMxthxTsJdLMPNhXYNw0h1bbQKD1WtJNrDC
FtnZnhai00gpvW8rejrn35cCRlqgF/xbbshkyeWg1HdoOv90VuOrmJrvufJubsxw
K4KTQ5FCEsGiDBD0XbQayJyjScLUymXd0+hVigAX758tLw2JPAx3R7kBjQRkGd19
AQwA/yGbTn9M7FOf5CwFqWog2V+cf838yebTUOQ7/XP1CCIWcwqNVmkrv2ITpyhT
tYaoDSMGWFyATZD2QWkrR8mW/ykf7OyYJLiszbOqRuaiaxnJ5OHiu7PF6G1JxnFb
Yl6loHNkLSmyzINoHPIGpVP4H961lKTchRzZoqJOeq3YPBFVNxASHOk6nki2vZ/d
SDTGQB86JKfXl77jXBQQNb7zhVFvYbbjjWojX/oTwgJ+FkwWC3lXj0EKqaXDqogI
4CjgpYKYM+m84CMwFMiup2C0KR0lc32VdzA0nMSEbPlbZvqvQc1uazDyFMOKaBxu
psctcXrFyPo1vTH28FxlwrqS83fPvDuhFiqOZvD7cCt1r5JTHAv1rs0pzVUNL4vZ
xK3gpfd1x4HFONsxSxFVvMZOX02Oas7yX9VuoRBVit2kweP2isuosicysTZ4rVmB
ohaHxLQvfNWF0CHUOtQhS5TvpGShxKv7KZsKL0Va06LpC8uyxUBUupbwYuIXcOQe
lK5FABEBAAGJAbwEGAEKACYWIQRZDwS6SraoSEnY9E0REIGmJjc7fAUCZBndfQIb
DAUJA8JnAAAKCRAREIGmJjc7fOdeC/0aXJD59G5Nuj3zTEbC4uReeOJ6M0acY6Av
qeWKHyQDMPGNbvfodM7Y0YvMMX/7pMn+vHC7lmfwMrJun1Kbm3kO/+T3Ce3IowKe
tcIcvILKLuLaX+9b7f8UIGOF9skCq6Q59fPYSIPhOsk5qi47LijAoGmWjFecx+Nz
axvQwl8FgyytvGm3DwMbBScXLZ9CzdhymnFEBjRSXdSM2qTp3u8JaVMx0G7uxXmn
HAkVkBM18Jdm6f/inGFxz4nc+rl9fh1cm0+E3uG3VD68RRR4DJiOh1m7XMDTS4rs
dNgWrOdLZL29/JbCqZ1u5TQ31a20N3UbZDS7ecMMWTb8ZHSiKyBJe3Xi+clhM5P2
eXzra/gfqYTFmqQc8rDUyIDjQrzPM+tlbRKI5e2Gt60NbNvh6pNfZ2TARK2dah4o
UpVMiKdkEAXv3J2gCFxmpoIpM3PqjKH2KR8KgPBuxm6omTIOIdcSwLrkHlZ7vDJS
C0kqE4tqqff7X+VkRDKk0snjIAaUbDQ= =Dv2U -END PGP PUBLIC KEY BLOCK-
(970) 889-4559
Package name discord ITP: discord a modern voice & text chat app
Package : discord
Severity: ITP
Package name: discord
Version: 0.0.27
Upstream Author: https://discord.com
URL: https://discord.com
License: custom
Description: All-in-one voice and text chat for gamers
Copyright: https://discord.com/terms#7 depends=('libnotify' 'libxss' 'nspr'
'nss' 'gtk3') optdepends=('libpulse: Pulseaudio support' 'ibappindicator:
Systray indicator support' 'xdg-utils: Open files') source=("
https://dl.discordapp.net/apps/linux/$pkgver/$pkgname-$pkgver.deb";
"LICENSE-$pkgver.html::https://discordapp.com/terms";
"OSS-LICENSES-$pkgver.html::https://discordapp.com/licenses";)
sha512sums=('285a0119b4740402a3fa94d3679a52bc8d883413ee32187e90087960a4d34aaf316788d2708bbccafe3f995c2b99767b45bc4b7c731704ef887a8de1b3d3926f'
'1f6e773b9c971aebd5391c22c5e2deea7aa222e0fda240aefbe91c4eb526305972d17302d1f5eb806a9d308c7f029ae8a0549f61d8c2adb53e4fe4ba9cd60a61'
'2adc1404b49930a419eb6c5fbb0c64ebd0a5d797e54357539a093cc99355b10e9c002750dd6d8ab84156593b7cbc8884c1b7e396ac0c2c2b59fcbda2368ebd1a
Please let me know if you need any more info
Matt Quintanilla
he/him
https://www.mattquintanilla.xyz/
-BEGIN PGP PUBLIC KEY BLOCK-
mQGNBGQZ3X0BDADSBAxrzn8C8pdCeovyCXnOJXkHazh14emOJoCdHQfeJe2EAn1q
QrPGySoD/KmB2UwaTI268pCbZvcWRHll+41Mp3iio0eHwuv6f5rSLv/0x406CkpK
BG7ZMmIW4N83O4dwNa7zZ5pnGjy9Qz57kPYZQJZV3MWPu4XDF57AYFImiZHttptK
4L3I8/rYqzLeI8R95/xs7DL/WoYQCs8F71JTsLEdZHpyrKhWHCGsHKpHhrGla8OH
w8xu4mVKptaq2uEWiBixfN7b5OIgVxYeAzzlB7yEpDTh3fxV24bvqel/SYhVFfdk
2XOcMTZj440FHukGcId9Kxy2wkONuzUQhfqwwhJOTm8lshI7dEtcuBYv4dryfxMd
j4QiSiiExBG7PSRQPZM+7B7LDfYUnHE/+kcnn7DkYyRulzt9CmNV2HR+nW6muVUl
d1mDB+XNF1ZCbEizd81Q037c15bQjlgNG/gWt8+iV9rtANEQDDo/1BcPwqLVFLZ6
G0La/Ry/VLPgAn0AEQEAAbQfbWF0dCA8bWF0dEBtYXR0cXVpbnRhbmlsbGEueHl6
PokB1AQTAQoAPhYhBFkPBLpKtqhISdj0TREQgaYmNzt8BQJkGd19AhsDBQkDwmcA
BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEBEQgaYmNzt8z74MAK6JCEaVAHcw
9eiioXUUQnPdXcEHC6w8SLraWmYHXrv6c62AGIpFTNigE/CdQzhkQOQK+nBM7e4a
h9lPydfF7HuOFKuW3ACF8aihTsEJMXexy7jMwWBe1YxLLzpJlCF5tIbJg4hBWjYc
prhvJBODyrLcrFQhN/ZlLTkJopzD4NZFbfjKkr9rar47z1mwjqOPsE1s5G5fW9SW
8IN+WZb88G6Ij5Yi+Kn3zpvks1QmGCrjYpjRoUbGLNQy6x0F6LP6m06rwe7XfoDP
GMy95VEoLBbSaXBnEWAt0zMqUM4aJMy0BjQC5rH9YK9Zrh8jap3dwXgeXZIUek/y
1F3TujlzWY/UQk0R5I5cl9KTf5Ui2IMxthxTsJdLMPNhXYNw0h1bbQKD1WtJNrDC
FtnZnhai00gpvW8rejrn35cCRlqgF/xbbshkyeWg1HdoOv90VuOrmJrvufJubsxw
K4KTQ5FCEsGiDBD0XbQayJyjScLUymXd0+hVigAX758tLw2JPAx3R7kBjQRkGd19
AQwA/yGbTn9M7FOf5CwFqWog2V+cf838yebTUOQ7/XP1CCIWcwqNVmkrv2ITpyhT
tYaoDSMGWFyATZD2QWkrR8mW/ykf7OyYJLiszbOqRuaiaxnJ5OHiu7PF6G1JxnFb
Yl6loHNkLSmyzINoHPIGpVP4H961lKTchRzZoqJOeq3YPBFVNxASHOk6nki2vZ/d
SDTGQB86JKfXl77jXBQQNb7zhVFvYbbjjWojX/oTwgJ+FkwWC3lXj0EKqaXDqogI
4CjgpYKYM+m84CMwFMiup2C0KR0lc32VdzA0nMSEbPlbZvqvQc1uazDyFMOKaBxu
psctcXrFyPo1vTH28FxlwrqS83fPvDuhFiqOZvD7cCt1r5JTHAv1rs0pzVUNL4vZ
xK3gpfd1x4HFONsxSxFVvMZOX02Oas7yX9VuoRBVit2kweP2isuosicysTZ4rVmB
ohaHxLQvfNWF0CHUOtQhS5TvpGShxKv7KZsKL0Va06LpC8uyxUBUupbwYuIXcOQe
lK5FABEBAAGJAbwEGAEKACYWIQRZDwS6SraoSEnY9E0REIGmJjc7fAUCZBndfQIb
DAUJA8JnAAAKCRAREIGmJjc7fOdeC/0aXJD59G5Nuj3zTEbC4uReeOJ6M0acY6Av
qeWKHyQDMPGNbvfodM7Y0YvMMX/7pMn+vHC7lmfwMrJun1Kbm3kO/+T3Ce3IowKe
tcIcvILKLuLaX+9b7f8UIGOF9skCq6Q59fPYSIPhOsk5qi47LijAoGmWjFecx+Nz
axvQwl8FgyytvGm3DwMbBScXLZ9CzdhymnFEBjRSXdSM2qTp3u8JaVMx0G7uxXmn
HAkVkBM18Jdm6f/inGFxz4nc+rl9fh1cm0+E3uG3VD68RRR4DJiOh1m7XMDTS4rs
dNgWrOdLZL29/JbCqZ1u5TQ31a20N3UbZDS7ecMMWTb8ZHSiKyBJe3Xi+clhM5P2
eXzra/gfqYTFmqQc8rDUyIDjQrzPM+tlbRKI5e2Gt60NbNvh6pNfZ2TARK2dah4o
UpVMiKdkEAXv3J2gCFxmpoIpM3PqjKH2KR8KgPBuxm6omTIOIdcSwLrkHlZ7vDJS
C0kqE4tqqff7X+VkRDKk0snjIAaUbDQ= =Dv2U -END PGP PUBLIC KEY BLOCK-
(970) 889-4559
Package name discord ITP: discord a modern voice & text chat app
Package name : discord
Severity: ITP
Package name: discord
Version: 0.0.27
Upstream Author: https://discord.com
URL: https://discord.com
License: custom
Description: All-in-one voice and text chat for gamers
Copyright: https://discord.com/terms#7 depends=('libnotify' 'libxss' 'nspr'
'nss' 'gtk3') optdepends=('libpulse: Pulseaudio support' 'ibappindicator:
Systray indicator support' 'xdg-utils: Open files') source=("
https://dl.discordapp.net/apps/linux/$pkgver/$pkgname-$pkgver.deb";
"LICENSE-$pkgver.html::https://discordapp.com/terms";
"OSS-LICENSES-$pkgver.html::https://discordapp.com/licenses";)
sha512sums=('285a0119b4740402a3fa94d3679a52bc8d883413ee32187e90087960a4d34aaf316788d2708bbccafe3f995c2b99767b45bc4b7c731704ef887a8de1b3d3926f'
'1f6e773b9c971aebd5391c22c5e2deea7aa222e0fda240aefbe91c4eb526305972d17302d1f5eb806a9d308c7f029ae8a0549f61d8c2adb53e4fe4ba9cd60a61'
'2adc1404b49930a419eb6c5fbb0c64ebd0a5d797e54357539a093cc99355b10e9c002750dd6d8ab84156593b7cbc8884c1b7e396ac0c2c2b59fcbda2368ebd1a
Please let me know if you need any more info
Matt Quintanilla
he/him
https://www.mattquintanilla.xyz/
ITP :discord All-in-one voice and text chat for gamers
Package name: discord Version: 0.0.27 Upstream Author: https://discord.com URL: https://discord.com License: custom Description: All-in-one voice and text chat for gamers Copyright: https://discord.com/terms#7 Let me know if you need any more info Matt Quintanilla he/him https://www.mattquintanilla.xyz/ signature.asc Description: PGP signature
Re: Bug#1016130: ITP: asdf -- multiple language runtime version manager
On Sun, 2022-08-07 at 08:04 -0700, Russ Allbery wrote: > Matt Barry writes: > > > I'm not really opposed to using asdf-vm if that prevents genuine > > ambiguity. Are any of these packages a) packaged for Debian, b) > > provide > > a binary called 'asdf'? > > python-asdf, cl-asdf, and asdftool are all packaged for Debian. None > of > them so far as I can tell produce a binary called asdf, but cl-asdf > does > have an info page named asdf, so there's some potential for confusion > there. (cl-asdf and python-asdf narrowly avoid having a conflict > over > info pages already.) Thanks, that's good to know; I think that at the very least naming this package asdf-vm makes sense. Cheers, Matt
Re: Bug#1016130: ITP: asdf -- multiple language runtime version manager
On Fri, 2022-07-29 at 13:22 +0100, Dagfinn Ilmari Mannsåker wrote: > Ole Streicher writes: > > > The URL is asdf-vm.com > > > > Maybe this could be called "asdf-vm" according to the upstream > > name? > > "asdf" also refers to the Advanced Scientific Data Format, > > https://github.com/asdf-format/. > > Also Common Lisp's Another System Definition Facility, > https://asdf.common-lisp.dev/ I'm not really opposed to using asdf-vm if that prevents genuine ambiguity. Are any of these packages a) packaged for Debian, b) provide a binary called 'asdf'? Cheers, Matt signature.asc Description: This is a digitally signed message part
Bug#1016130: ITP: asdf -- multiple language runtime version manager
Package: wnpp Severity: wishlist Owner: Matt Barry X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: asdf Version : 0.10.2 Upstream Author : Akash Manohar J * URL : https://asdf-vm.org * License : MIT Programming Lang: Bash Description : multiple language runtime version manager asdf is a CLI tool that can manage multiple language runtime versions on a per-project basis. It is like gvm, nvm, rbenv and pyenv (and more) all in one! Simply install your language's plugin!
Re: adduser default for sgid home directories
On Mon, 2022-07-25 at 14:37 +0100, Colin Watson wrote: > On Sun, Jul 24, 2022 at 12:34:31PM -0400, Matt Barry wrote: > > Anyway, its been released at this point, so the issue is moot :) > > Regardless of the rest of the discussion, this isn't entirely true. > Yes, people following unstable will have already seen the NEWS entry > and > apt-listchanges won't show it again for that version, but it's still > possible to edit it retroactively so that (for example) people > upgrading > between stable releases see improved text. That can sometimes be > worthwhile. > That is a good point, and probably something we should plan to do. signature.asc Description: This is a digitally signed message part
Re: adduser default for sgid home directories
On Mon, 2022-07-25 at 09:33 +0200, Bjørn Mork wrote: > Philipp Kern writes: > > On 25.07.22 08:46, Bjørn Mork wrote: > > > > > > obviously false. "No change" is always less surprising than any > > > change, > > > whatever the rationale is. > > > > It can also be unsurprising from an end-user's perspective. For > > someone new to the system. So that line of argument does not really > > hold. > > True. Good point. > > I was reading this as "unsuprising to the reader (system operator)", > but > I see that it could mean "unsusprising to the system users". Which > would make more sense. I apologize for the ambiguity; I did mean primarily for the end-user, who would likely a) assume their documents are private, and b) not expect any setgid weirdness. It is also unsurprising for users of other distributions, perhaps, which mostly use 0700. I take your point about any change being surprising.. but we wouldn't need a NEWS entry for that ;) > Is there a limit to the size of these entries which makes it hard to > be > more precise? None; this announcement was actually quite long. But the feedback is appreciated. Cheers, Matt signature.asc Description: This is a digitally signed message part
Re: adduser default for sgid home directories
Hello, On Sun, 2022-07-24 at 15:09 +0100, RL wrote: > Marc Haber writes: > > > ... Here is what the adduser team considers possible > > documentation for this, and we itend to include this in NEWS.Debian > > as a > > rationale for the change. > > As a user who reads NEWS.Debian (via apt-listchanges) i found the > text > didnt give me the answers i was looking for. I wanted to know: It is a bit long, but this discussion has come up a number of times over the years, so for the people interested in the details, we felt it was better to have a well-documented rationale. > > - what had changed (and when) This was the first line of the NEWS. "The default for DIR_MODE has been set to 0700 for this release. Detailed explanation follows." So: there is the change; no need to keep reading unless you're interested in the details. > - why has a change been made I think this is explained in excruciating detail. The short version (from NEWS): "mode 0700 provides both the most secure, unsurprising default" > - how the change might affects my existing/new systems - eg do i need > to > manually do something to adopt it? > - how/if i can customise/revert/use the new changes? > For the vast majority of users, nothing needs to be changed. If you run a multi-user system, nothing about your existing users will change, but new users created with adduser will have the new permissions. If you do not want this, the method for changing it back is well documented. > I also found the end of the draft was written almost combatively - as > a > user i dont really care about bug reports or whether developers > argued > on a mailing list: i just want to know the facts and whether i need > to > do anything different as a result. A more neutral phrasing would be > better and would also go out-of-date slower. I am sorry you read it that way; as I said, we felt that an extended description of the change (and some of its history, for people wondering why this change is happening) was appropriate. Certainly no combativeness was intended. > > Most NEWS files suffer from this to some extent but i was hoping for > something with less about bug reports and more like: > > > "adduser version 3.122 has changed > pp (DIR_MODE setting in /etc/ ) from aaa to bbb (one of these > is > 0700 i think, but i couldnt tell which?). Respectfully, the NEWS is not THAT unclear. Perhaps a better opening would have been: The default mode for users created with adduser is now 0700. If you don't know what that means and/or don't know what the default was, you can ignore this change. (but that alone would leave questions unanswered, for people that have followed the issue) Anyway, its been released at this point, so the issue is moot :) -- Cheers, Matt signature.asc Description: This is a digitally signed message part
Bug#1015279: ITP: python-pywayland -- provides Python bindings to the Wayland library
Package: wnpp Severity: wishlist Owner: Matt Barry X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pywayland Version : 0.4.13 Upstream Author : Sean Vig * URL : https://pywayland.readthedocs.io/en/latest/ * License : Apache Programming Lang: Python Description : provides Python bindings to the Wayland library PyWayland provides Python bindings to the Wayland library, using pure Python by making calls through the CFFI module. I plan to maintain this within the Python Team.
Bug#1015278: ITP: python-pywlroots -- Python binding to the wlroots library using cffi
Package: wnpp Severity: wishlist Owner: Matt Barry X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pywlroots Version : 0.15.18 Upstream Author : Sean Vig * URL : https://github.com/flacjacket/pywlroots * License : UIUC (NCSA) Programming Lang: Python Description : Python binding to the wlroots library using cffi A Python binding to the wlroots library using cffi. The library uses pywayland to provide the Wayland bindings and python-xkbcommon to provide wlroots keyboard functionality.
Bug#1015267: ITP: qtile -- A full-featured, hackable tiling window manager written and configured in Python
Package: wnpp Severity: wishlist Owner: Matt Barry X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: qtile Version : 0.21.0 Upstream Author : Aldo Cortesi * URL : https://www.qtile.org/ * License : MIT Programming Lang: Python Description : A full-featured, hackable tiling window manager written and configured in Python Simple, small and extensible. It's easy to write your own layouts, widgets and commands. Runs as an X11 WM or a Wayland compositor. Command shell that allows all aspects of Qtile to be managed and inspected. Complete remote scriptability - write scripts to set up workspaces, manipulate windows, update status bar widgets and more. Qtile's remote scriptability makes it one of the most thoroughly unit-tested window managers around. I plan to maintain this under the auspices of the Python Team.
Re: [adduser] default group for 'dynamically allocated system users'
Hi, On Thu, 2022-07-07 at 08:48 +0200, Marc Haber wrote: > > > > > > Can you come up with a better default for users created with > > > adduser > > > --system without requesting a dedicated group? > > > > One idea worth considering, imho, is what the reporter [0] > > suggests: > > make --group the default for --system. > > I don't like that idea at all, it'll introduce an avalanche of new > groups. That should be in the responsibility of the individual > package > maintainer. >From users-and-groups.txt.gz: LSB 1.3 lists daemon as legacy, and says: "The 'daemon' UID/GID was used as an unprivileged UID/GID for daemons to execute under in order to limit their access to the system. Generally daemons should now run under individual UID/GIDs in order to further partition daemons from one another." Users have to have *some* gid (you can add a non-existent one manually in the passwd database, but no tools will allow it). Whether is "nogroup" or "daemon" is irrelevant, security-wise; only an unshared (or deliberately shared) resource is an improvement. I don't love the idea of adding hundreds of new system users (it is hundreds, not thousands), but I don't see additional alternatives. Then again, also from users-and-groups.txt.gz: (Technically speaking, it does no harm for a file to be owned by group nogroup as long as the ownership confers no additional privileges, that is if the group and other permission bits are equal. However, this is sloppy practice and should be avoided.) So.. the status quo is at least acknowledged. It would nice if we could confirm that nobody is at any point *relying* on 'nogroup', but that seems likely to be true. Leaving it as is simply puts the decision back on maintainers to decide whether 'nogroup' is acceptable in their case. > > Sysadmin hat, I can think of situations > > where having a dedicated service group is useful (eg. giving r/o > > access > > to logs). > > We do have the adm group for that. Which grants blanket access, whereas a service group could offer a more precise access level. (This is however not a strong argument in favor of changing the current default, imho.) Cheers, Matt
Re: [adduser] default group for 'dynamically allocated system users'
Hi! On Mon, 2022-07-04 at 09:12 +0200, Marc Haber wrote: > Hi, > > adduser has been putting newly created 'dynamically allocated system > users' (adduser --system) into the nogroup group. It is also > documented to do so. There is an ancient bug report complaining about > this, and I think this is a valid complaint. However, > /usr/share/doc/base-passwd/users-and-groups.txt.gz says that no files > should ever be owned by nogroup, making adduser do the right thing in > its current state. > > Can you come up with a better default for users created with adduser > --system without requesting a dedicated group? One idea worth considering, imho, is what the reporter [0] suggests: make --group the default for --system. This will add one group for every system user (that is currently created without --group).. not unreasonable overhead for slightly improved security posture. Sysadmin hat, I can think of situations where having a dedicated service group is useful (eg. giving r/o access to logs). Having two unrelated services share a GID is just an unnecessary risk; probably should not be the default. > > Greetings > Marc Cheers, Matt [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693218 signature.asc Description: This is a digitally signed message part
Helping Ukraine with Debian
Hi! Has anyone thought about how to help out Ukraine by using Debian? Thinking about humanitarian relief and and other possibilities for communications. Is there any way I may be able to help out by remoting in? Any one got any verifiable contacts please? Thank you so much, Matt Grant
Re: Seeking feedback on a meta package builder
On Thu, Jun 10, 2021 at 8:01 AM Raphael Hertzog wrote: > > > > PS: I already hate the "mdbp" name after having it typed so many times. > > > > I'm not attached to either. Any suggestions? > > sbp for "standardized build package" is easier to type but not necessarily > nicer. > > "justadeb" or "gimmeadeb" or "buildadeb" because I just want a .deb (and I > don't care how it gets built!). > vendeb - vending machine for .deb > "deblord" or "debring" - the lord of the ring to tie all package builders > together > omegabuild - the last build system (also sort of a joke about being far from alpha software.) -m
Re: Heads up: persistent journal has been enabled in systemd
On Thu, Feb 6, 2020 at 11:03 AM Matthias Klumpp wrote: > > >From personal experience, all that's needed to switch to the journal > for an admin is to re-learn a couple of commands and be open to a bit > of change. I so far found nothing that I could do with rsyslog to be > impossible with the journal. Additionally you don't have to guess where logs are being sent for a particular service: systemd: journalctl --since=-1h -u puppet non-systemd: grep puppet /var/log/* though that is inefficient and would possibly miss some data or give false positives. -m
Re: Heads up: persistent journal has been enabled in systemd
On Wed, Feb 5, 2020 at 3:03 PM Dmitry Smirnov wrote: > > Anyway the big disadvantage of changing default is that now random Debian > systems will have no traditional logging interface (rsyslog) and we're all > will be forced to adapt to the new interface in the absence of old one on > some systems... > >From Michael's initial email: "Depending on how it goes, I might ask the ftp-masters to lower the priority of rsyslog from important to optional, so it would no longer be installed by default on new bullseye installations." As of right now, the only change is to enable persistent journal logs. Text logs will still be there with the current systemd upload. -m
Re: Heads up: persistent journal has been enabled in systemd
On Tue, Feb 4, 2020 at 5:15 PM Scott Kitterman wrote: > > On Tuesday, February 4, 2020 5:22:15 PM EST Vincent Bernat wrote: > > ❦ 4 février 2020 11:30 -08, Russ Allbery : > > >> As a heavy user or Rsyslog features I feel that switching default > > >> logging system yields no benefits to say the least. > > > > > > As a heavy user, perhaps you're not the target audience for a default? > > > You're going to install rsyslog no matter what, since you know it well and > > > use it heavily. The only effect of this change on you will be a one-line > > > change to whatever you use for configuration management for new > > > systems. > > > > rsyslog even knows how to directly pull logs from the journal, which > > gives you access to stuff not logged to syslog (stdout/stderr of service > > files, applications logging directly to journal), as well to structured > > logs (comm pid, user, unit and more when the service supports journald > > directly). > > For those of us who aren't customizers of Debian's logging function, it'd be > nice to have a clearer understanding of what this changes means. > > Today, when, for example, I want to investigate something email related, I > look in /var/log/mail.log. Random email related journal commands: journalctl -u postfix journalctl -f -u postfix journalctl -b -u postfix the -u is for the unit name. the -b is for since boot. man journalctl for details. Other specialized log files for their special > purposes. For data not covered by a specialized log, I look in /var/log/ > syslog. > > Will the specialized log files still be there? I suppose it depends. Do the processes write to /dev/log or manually write to files? Will the net effect be that I > just need to look in /var/log/journal (or something similar) instead of in / > var/log/syslog? The contents of /var/log/journal will be binary files that journalctl will read. IIRC. Is the persistent journal a text file or will I need > specialized tools to interact with it? specialized: journalctl. -m > > Scott K
Re: Git Packaging Round 2: When to Salsa
On Wed, Sep 25, 2019 at 4:09 PM Bernd Zeimetz wrote: > > > There are a number of ways forward: > > > >[...] > > 5) Make no recommendations in this space > > Why do all things need a recommendation? List the possible places to > host a repository with their advantages/disadvantages. If somebody is > not able to decide where to put a package based on that, they might not > be able to maintain it anyway. > Having sensible recommendations reduces the barrier to entry. Even if you provide a list with all the pros/cons there is still a decision to be made. Every decision that needs to be made is a barrier. Reading and understanding, research and applying context, contemplating and making decisions. I'm not suggesting that maintainers don't (eventually) understand all of the relevant details and particulars. Sometimes not forcing them to drink from the fire hose right away could be considered polite. -m
Re: Handling of entropy during boot
On Wed, Jan 9, 2019 at 12:13 PM Theodore Y. Ts'o wrote: > On Wed, Jan 09, 2019 at 09:58:22AM +0100, Stefan Fritsch wrote: > > > > There have been a number of bug reports and blog posts about this, > despite > > buster not being release yet. So it's not that uncommon. > > Pointers, please? Let's see them and investigate. https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912616 There's lots of chatter in the systemd github isses, too. I've been bitten by both ssh taking forever and puppet timing out on VMs. I'll need to investigate about virtio-rng. I've got an embedded x86-64 system where lightdm starts quickly when I am plugged into an ethernet connection, but takes about 8 minutes when the ethernet is disconnected. I am very suspicious of the low entropy in this case, too. -m
Bug#915966: ITP: cargo-outdated -- Display when Rust dependencies are out of date
Package: wnpp Severity: wishlist Owner: Matt Kraai * Package name: cargo-outdated Version : 0.7.1 Upstream Author : Kevin K. * URL : https://github.com/kbknapp/cargo-outdated * License : MIT Programming Lang: Rust Description : Cargo subcommand for displaying when Rust dependencies are out of date cargo-outdated displays when Rust crates have newer dependencies available. cargo-outdated is useful when developing Rust crates to determine if newer versions of their dependencies are available so that they can be upgraded to. I use it. I plan to maintain it as part of the Debian Rust Maintainers team.
Bug#915740: ITP: cargo-lichking -- Display info about licensing of Rust dependencies
Package: wnpp Severity: wishlist Owner: Matt Kraai * Package name: cargo-lichking Version : 0.7.0 Upstream Author : Wim Looman * URL : https://github.com/Nemo157/cargo-lichking * License : MIT or Apache-2.0 Programming Lang: Rust Description : Display info about licensing of Rust dependencies cargo-lichking is a cargo subcommand that checks licensing Rust dependencies. I use it to determine whether the licenses of the crates used by a Rust crate are compatible. I don't know of any other packages providing similar functionality. I plan to maintain it as part of the Debian Rust Maintainers team.
DEP-14 Git branch names?
Greetings Devel, In November of 2014 Raphael Hertzog posted [0] to -devel about a proposal (DEP-14) for recommended git branch names. The links he referenced are: http://dep.debian.net/deps/dep14 http://anonscm.debian.org/viewvc/dep/web/deps/dep14.mdwn and are both dead. Did DEP-14 find any traction with developers? I've searched a bit and can't find any hint of a "resolution" after the discussion or a current working link. Thanks for any commentary, -m [0] https://lists.debian.org/debian-devel/2014/11/msg00444.html
Re: Accepted drupal7 7.32-1+deb8u10 (source all) into oldstable-proposed-updates->oldstable-new, oldstable-proposed-updates
unsubscrube On 3/10/2018 6:18 PM, Gunnar Wolf wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 24 Feb 2018 01:06:57 -0600 Source: drupal7 Binary: drupal7 Architecture: source all Version: 7.32-1+deb8u10 Distribution: jessie-security Urgency: high Maintainer: Luigi Gangitano Changed-By: Gunnar Wolf Description: drupal7- fully-featured content management framework Closes: 891150 891152 891153 891154 Changes: drupal7 (7.32-1+deb8u10) jessie-security; urgency=high . * Fixes multiple security vulnerabilities, grouped under Drupal's SA-CORE-2018-001 (CVEs yet unassigned): - External link injection on 404 pages when linking to the current page (Closes: #891154) - jQuery vulnerability with untrusted domains (Closes: #891153) - Private file access bypass (Closes: #891152) - JavaScript cross-site scripting prevention is incomplete (Closes: #891150) Checksums-Sha1: eae0fea90d6e695a2977d074d653d3b2e3afa0f2 1915 drupal7_7.32-1+deb8u10.dsc 07205490873a9e2ee71015105242471f22f04e03 203464 drupal7_7.32-1+deb8u10.debian.tar.xz bb81220b8a9dd183d900174cdce3f1e95b7bb85b 2470428 drupal7_7.32-1+deb8u10_all.deb 6f616bdcca1e94d0ce9281b76d9f1695724d7c28 8581 drupal7_7.32-1+deb8u10_amd64.buildinfo Checksums-Sha256: 63f2e73915750d0459987c1180ffd64be12140cb33c6d4de4512c51e8b362d7f 1915 drupal7_7.32-1+deb8u10.dsc 64e6a3f0bdb5b712e6baef113e07821b68149db948cb0351b269ad62602f78e7 203464 drupal7_7.32-1+deb8u10.debian.tar.xz 01b22847c274954ab80d6641449feac10c4084ec2747aa1b1046a6eb39160df9 2470428 drupal7_7.32-1+deb8u10_all.deb d1f1e59aeadce1b3dbd37da206fb3eaf23daff51f3174b7a6eb76bc09b81a2fb 8581 drupal7_7.32-1+deb8u10_amd64.buildinfo Files: c415847e5d547e0b30d6867b3dc5e03e 1915 web extra drupal7_7.32-1+deb8u10.dsc 6b546c8dde289dbde9cf33f0c0719a42 203464 web extra drupal7_7.32-1+deb8u10.debian.tar.xz 975ab41fb6df1a6430e4c5ba38f24f2e 2470428 web extra drupal7_7.32-1+deb8u10_all.deb 0fd5847b9b75374d2458d642612495cb 8581 web extra drupal7_7.32-1+deb8u10_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEq0HBxor9ZoygRev4ZzoD5MHbkh8FAlqRENwACgkQZzoD5MHb kh9mVxAApeLeACgYPmOWhmY28M2gGx4+slvlI5ZxBYiIJflX2ksOd9aIRP52GhrJ n7E5lVsfeOyoKSlH5YfIKGAfBePCNZRep8YyErUbvmwvDd5276fHBdg60/0EEj/S TwIu7saxlCsFq7tw8w6ftl2sMMb5W/KtEDAxeCGeUmlArk2Hh9SgX0+x+pmudRXv HD86fFFoHmlkLYJLFeu4LouoZvriAW5arp1Ysg0oO3QMgkczA7c8KYMk074enaMQ vmldEjql5MrwZ9PwTOIfWnTqaYK25tO3qTEn6iPNiH/+RKkYKbtBdfYcrXN9Db1L c5SI7DbsNAgPR2dL3NrDbEgID1e6zCekloLKNnki8Xp11/ZZj6KE3qRzgaXCjinM NHfS+yF2EQuoaE+PqakItvfSbgWeODg1A5yr0p7vjHnkpkpqsIJ+zHmhUA7wgcWi +cN/yl8d1fT2iZU3lp4XfwSDRsC406RaFeWbjB4LgOJtf4ogku1RxPtYhts9GGwS kepKza6hpWQ0hgyyjbA7tC67pcF4FQ/WhZQMojpjzYZZZza0CUDloNvfU//Tdpsb 7QG7jckJgN+X0DforTyQUv5JeupGrqaTBS5Q6p84Qvo73O+a/Pa9czjZPXdnTan9 jES5FgA++A++Vg5NGtL9WVpKdUaOvE1ivK1dR68Q664xtveydxk= =GrLL -END PGP SIGNATURE-
Re: Debian part of a version number when epoch is bumped
On Wed, Feb 14, 2018 at 2:15 PM, Michael Stone wrote: > On Wed, Feb 14, 2018 at 09:05:05PM +0100, Vincent Bernat wrote: > >> In the example above, while in Wheezy, the dependency was perfectly >> correct. It became wrong because of the epoch bump (for no obvious >> reason). For software we distribute ourselves, this change can be caught >> at some point before the release (or by automation, like you suggest), >> but for people packaging stuff outside Debian, this can be far more >> painful. >> > > It isn't clear how getting rid of epochs would prevent crazy versioning. > You'd have just as much trouble with 1.8-really1.7-again1.8-fooledyou1.7 > How about introducing an Upstream-Version field? It can go up or down (forwards or backwards, newer or older) independent of the Debian (package) version. ITP Package foo Version: 1.0-1 Then a new upload # error... Package foo Version: 2.0-1 (really 1.5) Current corrections: Package foo Version: 1:1.5-1 or Version 2.0-really1.5-1 Instead use a new field to correct: Package foo Version: 2.0-2 Upstream-Version: 1.5-1 debian/changelog foo (2.0-2 Upstream:1.5-1) unstable; urgency=low The Depends in the control can then look for Upstream-Version and use that if it is set and fail back to Version if there is no Upstream-Version. Just an idea. -m
Re: Debian part of a version number when epoch is bumped
On Mon, Feb 5, 2018 at 9:43 AM, Jeremy Bicha wrote: > > The maintainer thinks the 1:1.0.51-12 version number would be "ugly" The maintainer would not be wrong. -m
Re: Why do we list individual copyright holders?
On Tue, Jan 16, 2018 at 10:53 AM, Ian Jackson < ijack...@chiark.greenend.org.uk> wrote: > > But I'm a hardy soul who is quite prepared to see a warning and decide > to ignore it :-). > > My view is that the purpose of a warning is to alert you to something, > so you can decide what to do about it. What is the difference between "warn" and "info", then? -m
Release Critical Kernel bug - Lenovo E550 laptop locks up repeatedly running systemctl daemon-reload
Hi! On kernel 4.14.13-1 linux-image-4.14.0-3-amd64 Debian Sid my Lenonvo Laptop will relaibaly lock up executing systemctl daemon-reload. Under Debian stretch kernel linux-image-4.9.0-5-amd64 4.9.65-3+deb9u2 this does not happen. I hae attached a picture of the kernel panic on the console. My guess as a developer this is a release critical show stopper bug. IMG_20180117_193509.jpg <https://drive.google.com/a/mattgrant.net.nz/file/d/1_sJLdzToo8fxL4vtMbLtaAeoduNd7pXL/view?usp=drive_web> This is 100% repeatable. Thank you! Matt Grant
Re: Call for volunteers: FTP Team
On Thu, Aug 17, 2017 at 4:02 PM, Jonathan Carter (highvoltage) < j...@debian.org> wrote: > On 17/08/2017 20:11, Joerg Jaspert wrote: > > it has been quite a while since the last call for volunteers, so here is > > an update: Yeah, we still need people, and we want you. Well, that is, > > if you are a Debian Developer, for this. If you are not and want to > > help, read the last paragraph please. > > If someone hypothetically joins, are they allowed to rename the FTP team > to something that doesn't include "FTP"? > Archive Team. Or the A-Team for short. The only Debian team with a theme song. -m
Re: Naming of network devices - how to improve it in buster
On Wed, Jul 12, 2017 at 11:47 AM, Michael Biebl wrote: > Am 12.07.2017 um 17:35 schrieb Marc Haber: > > My finger memory will still type tcpdump -i eth0 before the brain can > > intervene ten years from now. > > thankfully tcpdump (and lots of other tools) have nice shell completion. > tcpdump -i works great her. > > Agreed. However, I'd still rather deal with names like /dev/sda and eth0 than /dev/disk/by-id/ata-SanDisk_SSD_U100_252GB_122339300522 and en. It is kind of like using people's first names as opposed to their Social Security Number (in US) or other form of national identification. I know when I can use the name Matt and I know who it refers to, even if another Matt enters the room. I'm comfortable with eth0 being the name, even when another interface appears. I completely understand, and largely agree with, the need for persistent naming - but I think we are selling ourselves and our users short by not pressing harder for network interface aliases. It seems to be too useful of a solution for this problem. -m
Re: Naming of network devices - how to improve it in buster
On Tue, Jul 11, 2017 at 10:12 AM, Samuel Thibault wrote: > Matt Zagrabelny, on mar. 11 juil. 2017 09:53:58 -0500, wrote: > > Relatedly, network device name lengths are limited to the length of > some > > arbitrarily-sized struct field in the kernel ABI, > > > > Feature request to bump the size of of interface names struct? Any > reason to > > not do so? > > One reason is that it's already compiled in a lot of applications > through the IFNAMSIZ and IF_NAMESIZE macros (8155 and 939 results in > codesearch), so a lot of software would suddently break on interfaces > with long names until recompiled. > > Thanks for the input. This particular thread isn't the first time I've heard commentary regarding the interface name size in the kernel data structure. I'm not sure what a sensible limit is, but 16 (or 15) seems a little on the small side. Even Cisco has longer names than the Linux limit: echo -n "TenGigabitEthernet1/0/24" | wc -c 24 -m > Samuel > >
Re: Naming of network devices - how to improve it in buster
On Tue, Jul 11, 2017 at 9:18 AM, Simon McVittie wrote: > On Tue, 11 Jul 2017 at 13:45:25 +0200, Bjørn Mork wrote: > > I got to ask: Why? We do not have stable names for e.g. disks. Why do > > we need it for network devices? > > We do have stable names for disks: look in /dev/disk/by-* and you'll see > a bewildering variety of ways to refer to the same disk or partition. > > The thing that is different for network devices is that network > devices are not files (device nodes), so udev cannot create a symlink > /dev/network/by-mac/01:23:45:67:89:ab -> /dev/network/eth0 or whatever. > Network devices are (as far as I know) the only class of device managed by > udev that is not backed by a device node, which means udev cannot provide > multiple equivalent names for the same device, and is forced to choose > exactly one of those names, and rename the device if the chosen name > is not the kernel-generated one. That is why naming network devices is, > and has always been, more controversial than naming disks: they are the > one device class in Linux that violates the Unix design rule-of-thumb > "everything is a file". > Is there any (technical) reason why there isn't a kernel mechanism for an "alias" for interfaces that is roughly equivalent to symlinks for files? > If network devices were files, udev wouldn't have a configurable > NamePolicy to rename them: it would just provide symlinks for all the > possible naming policies, and let the sysadmin use any, all or none of > those names when configuring tools like ifupdown. Unfortunately, that > isn't possible. > > Relatedly, network device name lengths are limited to the length of some > arbitrarily-sized struct field in the kernel ABI, Feature request to bump the size of of interface names struct? Any reason to not do so? I know that kernel solutions to our problems isn't a quick fix, but it seems that having interface aliases would allow both camps to be happy. Sorry if the answers to these questions is obvious. -m
Re: Can we kill net-tools, please?
On Tue, Dec 27, 2016 at 9:08 PM, Wookey wrote: I am (vaguely) aware of > something caled 'ip' which does a similar job but have no idea how to > use it. Here are the few sub-commands I use regularly. Their abbreviated form and unabridged form, and the legacy command: ip a ip address show ifconfig -a ip r ip route show route -n ip n ip neigh show arp -n -m
Bug#845131: ITP: snap-telemetry-plugins -- Plugins for snap-telemetry to enhance and extend its capabilities
Package: wnpp Severity: wishlist Owner: matt jones * Package name: snap-telemetry-plugins-full Version : 1.0.0 Upstream Author : Snap Community * URL : http://snap-telemetry.io/ * License : Apache Version 2.0 Programming Lang: Go Description : Plugins for snap-telemetry to enhance and extend its capabilities A group of plugins that are designed to be used wth the snap-telelmetry package. http://snap-telemetry.io/plugins.html This package is dependent upon the ITP package snap-telemetry #844786 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844786 For now I will be maintaining this myself but I welcome help. At some point I may look at creating a team devoted to monitoring-telemetry that will maintain these two packages for starters. This is depependent upon the time I have. At the least I will maintain this package and the snap-telemetry package.
Bug#844786: ITP: snap -- The open telemetry framework
Package: wnpp Severity: wishlist Owner: matt jones * Package name: snap Version : 1.0.0 Upstream Author : Intel * URL : http://snap-telemetry.io/ * License : Apache License Version 2.0 Programming Lang: Go Description : The open telemetry framework Snap is an open telemetry framework designed to simplify the collection, processing and publishing of system data through a single API. The goals of this project are to: - Empower systems to expose a consistent set of telemetry data - Simplify telemetry ingestion across ubiquitous storage systems - Allow flexible processing of telemetry data on agent (e.g. filtering and decoration) - Provide powerful clustered control of telemetry workflows across small or large clusters I would like to bring this in Debian proper as I work full-time with various telemetry projects and would like better support for telemetry and monitoring based off of it within Debain rather than relying on external sources or builds. At some point if my time allows I would like to create a new team around monitoring telemetry to maintain this package and others that could be associated with or provide additional functionality/capability. For now I will be the maintainer of it.
Re: Bug#830983: ITP: field -- extracts a list of fields from a file
On Wed, Jul 13, 2016 at 1:14 PM, Lars Wirzenius wrote: > On Wed, Jul 13, 2016 at 01:08:25PM -0500, Matt Zagrabelny wrote: >> Perhaps moreutils? >> >> The utilities provided therein are (partially) written in perl. So it >> is out of place in that regards - but certainly not a show stopping >> road block. >> >> Joey Hess is the maintainer according to: >> >> apt-cache show moreutils | grep '^Maintainer:' >> Maintainer: Joey Hess > > That's obsolete information. Indeed! :) I thought I was performing the command on a sid machine, but it was jessie. Oops! -m
Re: Bug#830983: ITP: field -- extracts a list of fields from a file
On Wed, Jul 13, 2016 at 12:50 PM, Trevor Bramwell wrote: > On Wed, Jul 13, 2016 at 07:39:32PM +0200, Geert Stappers wrote: >> Such has having the 'field' codo in an existing Debian package. > > If you would be so kind as to point me to the right package this should > be included in, I'd be happy to discuss it with the maintainer and close > this bug. Perhaps moreutils? The utilities provided therein are (partially) written in perl. So it is out of place in that regards - but certainly not a show stopping road block. Joey Hess is the maintainer according to: apt-cache show moreutils | grep '^Maintainer:' Maintainer: Joey Hess -m
Re: [Pkg-javascript-devel] Bug#817092: Bug#817092: this browserified
Hi -- Forgive me for jumping in I've been MIA for about a year, life issues and all that :/. I think the issue in this instance has less to do with compiled files, and sending patches. And this case can be resolved by simply applying the rule which states that the output of preprocessors does not constitute source within the meaning of DFSG #2, to the current situation. Unless I am very much mistaken, the output of a preprocesser has never been considered source under DFSG #2. The reason for this is quite simple. If preprocessor output was considered source within the meaning of the DFSG, a hostile actor in the distribution chain could nullify the freedom to modify for downstream recipients of the DFSG covered work. As I recall the OSD makes this explicit but that was only codifying existing practice at the time. And the FSD which predates the DFSG also makes this explicit. Which only goes to show how widespread agreement on the preprocessor question was at that time. As far as I am aware nothing has changed in this regard since then. A javascript browserifying program seems to fill the classic function of a preprocessor. According to the Grunt developers grunt provides "Automation, performing repetitive tasks like minification, compilation, unit testing and linting.", compare that with the cpp(1) man page "The C preprocessor, is a macro processor that is used *automatically*, by the C compiler to *transform* your program before compilation." (emphasis added) The fact that javascript is not a compiled language makes no difference in the analysis. The point is minifyed/browserifyed javascript has been through a process which transforms the code, this process is intended to aid execution. Programers skilled in javascript by and large do not modify the output of this process directly. Therefore browserifyed javascript is the output of a preprocessor. The output of a preprocessor is not source within the meaning of the DFSG. Therefore browserifyed javascript is not source within the meaning of DFSG #2. Magnitudo demonstrandum est. Or at least it seems that way to me. But the final descion will be made in due course by the usual procedure. I just hope that i have made a useful contribution by attempting to pose the right analogy. Thanks /Matt --
Re: experimental syslog-ng
On Fri, Jun 10, 2016 at 2:46 PM, Ansgar Burchardt <"Ansgar Burchardt"@43-1.org> wrote: >> At least the following mirrors' Packages.xz file shows the older >> 3.6.1+git version: > > The package failed to build, see [1]. Ahhh. Thanks! -m
experimental syslog-ng
Greetings, It appears that the version of syslog-ng for mirrors of ftp.us.debian.org's experimental repository is still at version 3.6.1+git20141206-g4d90138-4+b1, while tracker.d.o is reporting that the experimental version is at 3.7.1-3, and has been since Thu, 08 Oct 2015 21:51:09 +0200. At least the following mirrors' Packages.xz file shows the older 3.6.1+git version: 64.50.236.52 (OSU) 128.61.240.89 (GATech) 128.30.2.26 (MIT) Any ideas why this is the case? Thanks for any feedback! -m
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, Jun 8, 2016 at 12:40 PM, Alexander Wirt wrote: > On Wed, 08 Jun 2016, Jonathan Dowland wrote: > >> On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: >> > I am also not very keen on using a system with a "open core / enterprise" >> > model. For such a crucial service I would really prefer a real open source >> > system. But maybe I am alone with that oppinion. >> >> You are not alone, but please do not call Gitlab CE not "real open source". > I do for every software which forces me to sign things like: > https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/legal/individual_contributor_license_agreement.md > > Thats far away from what I call open source. I also don't want to end with > things like: > > Debian needs feature X but it is already in the e.nterprise version. We make > a patch and for commercial reasons it never gets merged (they already sell it > in the enterprise version). Which means we will have to fork the software and > keep those patches forever. Been there done that. For me, that isn't > acceptable. That is the nature of free software, though. Any given upstream might be unwilling to merge some useful patch for whatever reason they choose. If enough of those patches don't get merged, then a fork may be likely. This already happens in the FOSS community without any commercial or proprietary interests. Given that, I still prefer software that doesn't have a proprietary licensed "enterprise" version as well as a free software version. -m
Re: Bug#815675: ITP: ftpbackup -- Script to backups your data from a Debian system to a ftp space
On Wed, Feb 24, 2016 at 8:53 AM, Jonathan Dowland wrote: > On Wed, Feb 24, 2016 at 03:29:35PM +0100, Jakub Wilk wrote: >> To avoid unpleasant situations like this, I recommend to never combine roles >> of upstream and Debian maintainer. > > An interesting idea in theory, but it would break down when you consider > team-maintained packages. I find the idea interesting, as well. I believe the concept also breaks down for native, and native-like, packages. DDs are (perhaps?) the ones most likely to see software needs in the Debian ecosystem. Suppose DD-A sees a need and writes useful software DebFoo for Debian. Would they be permitted to package it, or would DD-B need to package it? Food for thought. -m
Re: init script, installed but not activated
On Tue, Oct 6, 2015 at 3:16 PM, Antonio Terceiro wrote: > On Tue, Oct 06, 2015 at 10:47:28PM +0300, Hleb Valoshka wrote: >> Hi all. >> >> I'm packaging web server for ruby called unicorn. The package installs >> sysv init script, I want to make it installed but not activated >> because unicorn itself is useless, user should configure it and >> activate it with "update-rc.d unicorn enable". Or it may installed as >> dependency for rainbows, so it's clear that it should not run. >> >> So I need something like "dh_systemd_enable --no-enable", existing >> options for dh_installinit like "--no-start" or >> "--update-rcd-params=..." does not work such way, so we need to >> introduce workarounds in postinstall script. >> >> Any suggestions? > > for sysvinit you need to code that manually in the initscript. several > packages have their initscripts source /etc/default/$package, and check > for some variable that says whether the service should start on boot or > not. I believe that practice is now frowned upon since update-rc.d has a disable verb. -m
Re: aptitude has Priority: standard, why?
On Tue, Mar 31, 2015 at 9:32 AM, The Wanderer wrote: > Repeatedly over the years - I'd almost say consistently - I've seen > aptitude report that a requested package change (install, remove, or > some combination) would result in an invalid or conflicting dependency > situation, and suggest a solution which involves _not making the change > which was requested_. > > If the requested configuration is, in fact, contradictory, then this is > of course reasonable. However, in most if not all such cases, requesting > the same change of apt-get produces a workable dependency solution > immediately. > > Sometimes (when I've bothered to stick with it long enough), telling > aptitude "no, try again" a few dozen times (and rejecting "solutions" > which would downgrade or remove dozens, if not hundreds, of packages > along the way) will eventually get it to suggest a solution which will > make that change without extraneous side effects - which may or may not > be the same as the one provided by apt-get. > > But as long as aptitude continues to take this brain-dead approach to > dependency resolution, necessitating digging through obviously-bad > suggestions before finding something as reasonable as what apt-get > provides easily, it is IMO not viable for actual use - except perhaps by > people who already know completely what they are doing and how to > override aptitude's suggestions. I've grepped debian-devel, but cannot find an email that was sent to the list some months ago about tweaks to /etc/apt/apt.conf (IIRC) to make aptitude behave more sanely. Thus, I believe there are a couple of knobs to turn to make aptitude behave more expectedly. Cheers, -m -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caolfk3vm0kzvee-bypj6yjaqfwp-ma5ybn1k7y1w-cbev1c...@mail.gmail.com
Re: Bug#769511: Info received (Bug#769511: netscript-2.4: installation fails)
OK, Tracked this one down. Its caused by /etc/init.d/networking being left there when ifupdown is removed. Could you please fix this? I am marking bug as important and assigning to your package ifupdown. Work around is for me to document that ifupdown needs to be purged so that netscript-2.4 will install cleanly. I am also CCing debian-devel list for suggestions. Regards, Matt Grant On Sat, 2014-11-15 at 01:57 +, Debian Bug Tracking System wrote: > Thank you for the additional information you have supplied regarding > this Bug report. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Matthew Grant > > If you wish to submit further information on this problem, please > send it to 769...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > -- Matt Grant, Debian and Linux Systems Administration and Consulting Mobile: 021 0267 0578 Email: m...@mattgrant.net.nz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1419146788.25817.6.ca...@mattgrant.net.nz
Re: Being part of a community and behaving
Hi Pat, On Thu, Nov 13, 2014 at 4:25 PM, Patrick Ouellette wrote: > On Thu, Nov 13, 2014 at 11:06:08PM +0100, Matthias Klumpp wrote: >> >> > For the record, I really don't care about the init system per-say. I am >> > more annoyed with the systemd insistence on logging to binary files than >> > anything. Log files should be plain text. That's a loaded statement. >> Rsyslog is srill installed by default (and I guess that won't change >> soon), so you now have even better textlogs. > I did not ask for evangelization about how wonderful binary logs are, > nor for a lesson on how to get the info out of systemd with the > systemctl command. You shouldn't be surprised that there is dialogue surrounding it. -m -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOLfK3XTG3ZT-AQHaem+kbsS7OueuCiSwgYZoYt+T=2qpgdB=g...@mail.gmail.com
Bug#768156: general: dpkg frontend inconsistent
Hi Holger, On 5 Nov 2014 16:53, "Holger Levsen" wrote: > which tool did you use (how) to upgrade? I also experienced this when upgrading a system from squeeze to wheezy a few days ago. I followed the upgrade instructions in wheezy's release notes, i.e. using apt-get. I'll have a look through the logs to see if I can spot a pattern. Thanks -- Matt Wheeler http://funkyh.at
Re: ITNMU nfdump
On Mon, Oct 13, 2014 at 2:27 PM, Jaakko Niemi wrote: > Hello, > > I'm planning to NMU nfdump, and have been unable to contact the maintainer > (his > MTA says I'm a spammer). Has anyone else been in contact with Erik lately? I packaged up nfsen a while ago (maybe 16 months) and asked Erik about sponsoring it. He replied with some feedback for the package, but that was the last of our email exchange. > On longer term, I'm planning to adopt the package, Super! -m -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caolfk3whzbm_pi0fomx6pzy1wrflaqjrkb3_tgbeykys2pz...@mail.gmail.com
Re: daemon user naming scheme
On Tue, Aug 26, 2014 at 12:10 PM, Matthias Urlichs wrote: > adduser tango --uid $UID --gid $GID typo? adduser _tango --uid $UID --gid $GID -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caolfk3x04x2iv0rzd9e5zpjwtpepgdtp++nj6mwm9zhnoma...@mail.gmail.com
Re: Automatization
Hi Diogene, This question would have been better aimed at debian-u...@lists.debian.org, debian-devel is for discussing the development of Debian, not support. However, preseeding is covered in the installation guide [0] and on the wiki [1] Depending on your installation method you can modify the install media to include a preseed file to fully automate the install, or by pointing the standard installer at your preseeding file when you boot from it and then leaving it to do the rest for you. [0] https://www.debian.org/releases/stable/i386/apb.html [1] https://wiki.debian.org/DebianInstaller/Preseed On 22 August 2014 12:43, Diogene Laerce wrote: > Hi, > > Is it possible to automatize the installation process of Debian ? I mean > being able to install without user intervention ? > > Thank you, > > -- > “One original thought is worth a thousand mindless quotings.” > “Le vrai n'est pas plus sûr que le probable.” > > Diogene Laerce > > -- Matt Wheeler http://funkyh.at -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAG93HwHMeC_6iE6hwMhOj=MfSaUngy2+qKBv=ljrwrx6qcu...@mail.gmail.com
Re: Let's shrink Packages.xz
On Fri, Jul 25, 2014 at 6:50 AM, Ian Jackson wrote: >> Reducing the size of Packages.xz by 11% or 22% would leave room for quite >> a lot of small packages while not making the problem any worse than it is >> today. > > But the problem with lots of small packages is not that the > Packages.xz has too many bytes. > > It's that the packaging tools, UIs (for users and developers), and > humans, need to think about too many packages. > > This makes packaging tools slow, UIs cluttered, and humans confused. What is "too many" packages? It seems that the UI would need to be able to handle an arbitrary number of packages. There have been many thousands of packages since Woody/Sarge. -m -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caolfk3xaxcftk57cd-qcudwnl1xwr84ebuougg_9qagqto0...@mail.gmail.com
systemd: nfs-common and rpcbind unit files to fix systemd NFS issues properly
Hi All! Emailing this to save systemd folks NFS grief... NOTE: This all needs to be actioned for Jessie release Also Note this fixes bugs #748074 (rpcbind) and #622394 (nfs-common) We don't need a socket activated rpcbind, but using socket activation for NFS RPC daemons using upstream systemd unit files is recommended as it removes need for editing /etc/default/nfs-common, and is already tested way of doing NFS RPC under systemd. Cheers, Matt Grant Package: nfs-common Version: 1:1.2.8-6 Followup-For: Bug #622394 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? When running under systemd: o NFS mounts from /etc/fstab do not work. o NFS exports also fail due to rpcbind not starting before nfs-common and nfs- kernel-server systemd is the new default system init for linux. The above should just work. * What exactly did you do (or not do) that was effective (or ineffective)? Created my own /etc/tmpfiles.d/rpcbind.conf: #Type PathMode UID GID Age Argument d /run/rpcbind 0755 root root - - f /run/rpcbind/rpcbind.xdr 0600 root root - - f /run/rpcbind/portmap.xdr 0600 root root - - and /lib/systemd/system file (I did this one in /etc/systemd/system): --- [Unit] Description=RPC bind portmap service After=systemd-tmpfiles-setup.service Wants=remote-fs-pre.target Before=remote-fs-pre.target DefaultDependencies=no [Service] ExecStart=/sbin/rpcbind -f -w KillMode=process Restart=on-failure [Install] WantedBy=sysinit.target Alias=portmap and enabled above unit: # systemctl enable rpcbind.service Did for nfs-common to make NFS rpc support to start at correct time: Created /etc/systemd/system/nfs-common.service (can be put in /lib/systemd/system [Unit] Description=NFS Common daemons Wants=remote-fs-pre.target DefaultDependencies=no [Service] Type=oneshot RemainAfterExit=yes ExecStart=/etc/init.d/nfs-common start ExecStop=/etc/init.d/nfs-common stop [Install] WantedBy=sysinit.target - # systemctl enable nfs-common * What was the outcome of this action? Rpc Bind starting correctly, with registration state saving over restart, NFS service working normally # systemctl status rpcbind rpcbind.service - RPC bind portmap service Loaded: loaded (/etc/systemd/system/rpcbind.service; enabled) Drop-In: /run/systemd/generator/rpcbind.service.d └─50-rpcbind-$portmap.conf Active: active (running) since Wed 2014-05-14 10:38:13 NZST; 13min ago Main PID: 5066 (rpcbind) CGroup: name=systemd:/system/rpcbind.service └─5066 /sbin/rpcbind -f -w May 14 10:38:13 moriah systemd[1]: Started RPC bind portmap service. # systemctl status nfs-common nfs-common.service - NFS Common daemons Loaded: loaded (/etc/systemd/system/nfs-common.service; enabled) Active: active (exited) since Wed 2014-05-14 10:35:01 NZST; 19min ago Main PID: 259 (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/nfs-common.service Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. All the NFS RPC daemons have port activation in latest nfs-utils upstream, and service files. Please consider using these as the socket activation saves haing to manually configure which NFS RPC daemons are needed. -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 132 tcp 2049 nfs 133 tcp 2049 nfs 134 tcp 2049 nfs 1002272 tcp 2049 1002273 tcp 2049 132 udp 2049 nfs 133 udp 2049 nfs 134 udp 2049 nfs 1002272 udp 2049 1002273 udp 2049 1000211 udp 38783 nlockmgr 1000213 udp 38783 nlockmgr 1000214 udp 38783 nlockmgr 1000211 tcp 49538 nlockmgr 1000213 tcp 49538 nlockmgr 1000214 tcp 49538 nlockmgr 151 udp 58915 mountd 151 tcp 40052 mountd 152 udp 40524 mountd 152 tcp 60384 mountd 153 udp 55957 mountd 153 tcp 49758 mountd -- /etc/default/nfs-common -- NEED_STATD= STATDOPTS= NEED_IDMAPD=yes NEED_GSSD=yes RPCGSSDOPTS="" -- /etc/idmapd.conf -- [General] Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs Domain = internal.anathoth.net Local-Realms = ANATHOTH.NET [Translation] Method = nsswitch [Mapping] Nobody-User = nobody Nobody-Group = nogroup -- /etc/fstab -- #shalom:/src/media/src nfs noauto,defaults,user,exec 0 0 #shalom:/home /media/home nfs noauto,defaults,user,exec 0
Forming racoon/ipsec-tools maintainers group
Hi All! Just emailing to tell you I have not forgotten this. This Easter I will have the time to organise this and 'turn the crank handles'. Cheers, Matt Grant -- Matt Grant, Debian and Linux Systems Administration and Consulting Mobile: 021 0267 0578 Email: m...@mattgrant.net.nz signature.asc Description: This is a digitally signed message part
Deprecating/removing racoon/ipsec-tools from Debian GNU/Linux and racoon from Debian/kfreebsd
Hi! I am the maintainer of the raccon/ipsec-tools packages and I want to review their relevance in modern Debian. Systemd package support is the thing that pushed me over the edge about this. There are no systemd unit files at all for ipsec-tools/racoon that I know of. Please advise me otherwise, and I will look at putting them in the current package. Proposal: Deprecating/removing racoon/ipsec-tools from Debian GNU/Linux and racoon from Debian/kfreebsd. Strongswan/Openswan are maintained and have a superset of the racoon functionality, can run on Debian kFreeBSD with setkey still being available to manipulate kernel IPSEC as root - there would be no old racoon daemon running as root The issues are: 1) Security. The racoon daemon has to run as root, with a lot of the default GCC security flags turned off. 2) Maintenance and Porting. It is officially maintained as part of NetBSD, but there is always a lot of work to get the code to compile on Linux, especially if it is a later version of GCC than in Net BSD. Quite often there are obscure API/binary ABI issues that are difficult to solve due to the new code tending to be *BSD specific. 3) Linux setkey ioctl interface that ipsec-tools/racoon use is deprecated. ip xfrm encapsulates the full functionality of setkey using the new Netlink IPSEC API, and Openswan/Strongswan do so to. 4) On Debian kFreeBSD, Strongswan/Openswan support the BSD setkey ioctls, thus can be substituted for racoon, and operate more securely. 5) IPSEC protocols. racoon only does IKEv1, Strongswan/Openswan do IKEv1 and IKEv2 Against deprecation/removal: 1) racoon is what is used in MacOSX, and it is good to be compatible. 2) Keeping compatibility with old installs, not breaking IPSEC on upgrade. 3) racoon is designed from the get-go to work with IPv6 Mobile IP functionality. Strongswan/Openswan can be used for MIPv6, but there are some issues that have to be solved still. 4) racoon/setkey are native IPSEC implementations across FreeBSD, NetBSD, Mac OSX, and Linux, and thus having it available give a 'just works' IPSEC option. My main concern as maintainer are the security issues, with an old code base running as root. NB: racoon-tool was an effort to provide basic FreeSWAN like functionality when racoon/setkey where the one true way to use the then new Linux in kernel IPSEC stack. Openswan and StrongSWAN are descended from FreeSWAN, thus racoon-tool functionality is 99% fulfilled by using Strongswan/Freeswan. I am willing to co-maintain this package with other developers and maintainers. My belief is that there is likely a Debian kFreeBSD developer/maintainer out there who would like to do this, and do a lot of the work :-) Could you please supply your comments and feed back on this. Best Regards, Matt Grant, Debian Developer signature.asc Description: This is a digitally signed message part
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
Hi! Actually, I would love to cleanly modify ifupdown with a lot of the experience I have gained from netscript, and working on actual routers. Making it not so onerous would not be that much work, and it would have far better behaviour once improvements are made. I am putting myself forward for this as with the systemd update netscript-2.4 needs to be 'bodged' in a bit to make it work. I will do this, but getting ifupdown with a better operational method and feature set will make it far easier to use for the server case as well. Cheers, Matt Grant On Fri, 2014-03-28 at 15:08 -0700, Russ Allbery wrote: > Josselin Mouette writes: > > Le vendredi 28 mars 2014 à 11:55 -0700, Russ Allbery a écrit : > > >> I realize that doing that well is not horribly challenging, but that is > >> the most common server use case (and even desktop), and ifupdown does > >> it quite well. > > > Come on. We all use ifupdown on our servers just because it is the > > default and works well enough. Bringing up a pair of static IPs and a > > bonding link is not very challenging. But we shouldn’t judge a network > > management tool based on how to achieve the simplest task: any tool will > > do that. Even Red Hat’s /etc/sysconfig/network-scripts, despite its > > horrible design and antique syntax, works well enough for most of its > > users. > > > And in the desktop case, I disagree that ifupdown does the job. User > > applications want to be notified of the network’s status, and it > > requires more than what ifupdown can offer. > > That sounds like vehement agreement with what I just said. :) > > Having used both, ifupdown, despite its problems, is certainly better than > the Red Hat approach in /etc/sysconfig. > > >> I don't want to lose that, and I don't want to add a bunch of > >> complexity in order to satisfy that case. I think there will always be > >> a place for a very *simple* system to handle that case with some pre > >> and post hooks for things like iptables rule installation. > > > This is one of the possible scopes of systemd-networkd. But I think it > > is being designed more for cases like the initramfs, where you cannot > > have a full-blown networking management tool like NM. > > It's quite possible that systemd-networkd will eventually become a good > tool to do this. It just isn't now. Now would be a wonderful time for > people who care to get involved, if they feel like that would be a good > long-term solution, since it would be much easier to design a conversion > path from existing ifupdown systems at this early stage in the project. > > -- > Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1396044965.17962.5.ca...@moriah.internal.anathoth.net
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
Hi Andrew, I am willing to co-maintain it with you and evolve it. Previously I have worked professionally as a router programmer, and have contributed to Quagga/Zebra OSPF. > Please also note that's there's no point in rewriting ifupdown from > scratch to provide the same interface; the existing code is good enough > for what it does currently, it just needs to be improved. > Unfortunately, I don't have enough time currently to implement > functionality I'd like to, or to fix some issues which bother me and > other people. OK, I agree with this to. Too much does depend on it to rip it out. It has to be kept backwards compatible. Some good work has been done since wheezy (or squeeze) dropping the need for Linux 2.2.x sub-interface names like 'eth0:0' being required to bring up extra interface addresses. Are they still required for kFreeBSD and GNU/HURD? We do need to keep old /etc/network/interfaces files working :-) Would interface state file business be a good place to look at first? I believe I have some good ideas on how it should be done. It would be good to wiki them first, and other possible design changes, and see what others have to contribute. >From netscript, I have split the iptables stuff in netscript-2.4 into its own package netscript-ipfilter. That is the most important stuff in there now, and has to be stand alone from network configuration to benefit most systems. Its a better alternative to eg iptables-persistent as it keeps a saved history of so many versions, and provides roll back support, 'helper' chains for IPv6/IPv4 ICMP filtering, border router address checking etc (more important now everyone is getting an IPv6 subnet, no NAT). Not to knock anything, other systems may be better depending on your tastes for firewall/packet filtering. Nftables are coming to replace iptables in the kernel. Lets get some more sense into ifupdown, making it more versatile and take the corners off it operationally. I'd like to be able to send netscript to its grave in a few years :-) Regards, Matt Grant -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1396004493.16475.72.ca...@moriah.internal.anathoth.net
Ifupdown dysfunctional, is a Provides: interface possible please?
Hi! I am the developer of netscript-2.4, an alternative network configuration system for Debian written in /bin/bash - quite old. First of all, though, my stuff is not the glorious gloopiest best. I have split the iptables stuff out to netscript-ipfilter, better than iptables-persistent I must say though! But I still persist with it as I find some things about ifupdown rather not good. eg: web: -root- [~] # ip link 1: lo: mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000 link/ether 52:54:00:97:5a:d6 brd ff:ff:ff:ff:ff:ff web: -root- [~] # ip link set dev eth0 down web: -root- [~] # ifup eth0 ifup: interface eth0 already configured web: -root- [~] # ip link show dev eth0 2: eth0: mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000 link/ether 52:54:00:97:5a:d6 brd ff:ff:ff:ff:ff:ff web: -root- [~] # Eh what??? ifupdown also cannot add an additional address/subnet to an interface without shutting the interface down and restarting it. Kernel allows it, why not? My package does provide command line compatibility though, and gives ifupdown as a Provides: I have found that the version dependency of resolvconf on ifupdown (>= 0.7.5) breaks the Provides on my package... Also, there is quite some scripting glue going on down in udev... Have a look at /lib/udev/net.agent ifupdown also has a whole forest of shell scripts for it in other packages as well. Very similar to sysvinit/systemd stuff we have already gone through. One thing that put me off ifupdown quite some time ago was finding that configured bridges made NFS client mounts on the host wait... who would implement a bridge with interface listen/wait/STP functionality on a pure work station or server? Sounds like a router/firewall, and they should not be nfs mounting by their nature and functionality ... Real corner case stuff. I sincerely would like to work with the ifupdown maintainer and systemd/udev crew to work all this out. A basic level/interface of functionality for replaceable network configuration packages would be nice. I KNOW MY STUFF COULD/SHOULD BE BETTER! Maybe I should reimplement a lot of it using only what is provided by perl-base and /bin/sh, but lets get some sense here please. I also compatibility for upgrades is required, but how compatible does any intentional replacement for ifupdown have to be, especially if the system a firewall or a router? Regards, Matt Grant -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1395991395.16475.25.ca...@moriah.internal.anathoth.net
Re: Idea for apt-get : getting source code instead getting binaries
On Thu, Mar 6, 2014 at 9:33 AM, Solal Rastier wrote: > Hello! I've an idea for a new apt-get package style : > > Developer side : > -The developer create a ./install script in the source code. > -The install script executes all commands necessary for install the software. > Also, it getting dependancies, etc. > -The developer create a tarball (.tar.bzip2) and rename the file name. > Instead of software.tar.bzip2 , that's software.deb > -The developer distribute the software.deb > > Apt-get side : > -The apt-get tool download software.deb from the Debian repository. > -The program is installed with dpkg > > Dpkg side : > -dpkg rename the software.deb software.tar.bzip2 > -tar uncompress the software.tar.bzip2 > -cd go into the "software" folder > -./install execute install script Maybe I'm missing something: apt-get source foo apt-get build-dep foo Do those commands do what you are needing? -m -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caolfk3x-kesuqo+ozbeuu5ddbng9fxgaw1az5dadgo4vb9j...@mail.gmail.com
Re: Bug#738839: ITP: mps -- Poor Man's Spotify - Search and stream music
On Thu, Feb 13, 2014 at 12:31 PM, Holger Levsen wrote: > Hi, > > On Donnerstag, 13. Februar 2014, Jakub Wilk wrote: >> https://en.wiktionary.org/wiki/poor_man%27s > > I knew that :) I still don't think it's appropriate nor helpful to describe > software with these attributes. (Hints: free software is always free as in > gratis, and men, well, men^wmeh.) Packager is using upstream description. From their website, https://github.com/np1/mps Poor Man's Spotify - Search and stream music In English, the phrase doesn't carry a negative connotation. It is a clever way to replace something expensive with something less expensive. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOLfK3UKj9cpRywnvAFRopNL3QmdoUwJfqqiMRSegqgAyFFQ=q...@mail.gmail.com
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Wed, Feb 12, 2014 at 1:02 PM, Kevin Chadwick wrote: > On Wed, 12 Feb 2014 11:25:14 -0500 > Paul Tagliamonte wrote: > >> > If they have decided on systemd as default [...] >> >> https://lists.debian.org/debian-devel-announce/2014/02/msg5.html >> >> Can we please end this thread? > > Sure but perhaps you could save me the trouble to say if there is a > general outline of the factors that the decision made was based upon > perhaops somewhere in the ctte mailing list archive. Or a round up > published before voting. > > Don't tell me it was just a vote with licensing issues being taken by > many over real issues as some sites seem to be saying. Do voters give > their primary reasons? Kevin, This is what I found. Hopefully it is useful. Russ' reasoning: https://lists.debian.org/debian-ctte/2013/12/msg00234.html Colin's reasoning: https://lists.debian.org/debian-ctte/2013/12/msg00296.html Ian's reasoning: https://lists.debian.org/debian-ctte/2013/12/msg00182.html Bdale's reasoning: https://lists.debian.org/debian-ctte/2014/01/msg00067.html Digging through the mailing list archives to find the remaining CTTE member's reasoning is left as an exercise to the reader. :) -mz PS. I'm looking forward to this thread ending - sorry for adding to it! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3w2x+zz+o8ykfpif4d1vsvurl4dqyrndfzsaxkpyu7...@mail.gmail.com
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, Feb 11, 2014 at 10:26 AM, Matthias Urlichs wrote: > Hi, > > vita...@yourcmc.ru: >> Because I want logs to be plaintext in my system, not binary. >> > Why? (Seriously.) To use standard text based tools, eg. grep. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOLfK3X6Zpz=ysi8-yxypgdohohqfxevt2zhrasd9uaw5tv...@mail.gmail.com
Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]
On Tue, Dec 31, 2013 at 8:54 AM, Clint Adams wrote: > On Sun, Dec 29, 2013 at 03:50:06AM +0100, David Weinehall wrote: >> Apart from the termination clause, the GPLv2 is far more concise, >> I don't see tivoization as a problem (it's the software I want to >> protect, not anyone's combination of it with hardware), nor do I care >> about compatibility with Apache 2.0 -- I do, however, care about >> compatibility with GPL v2, which GPL v3 isn't. > > So your doomsday scenario is that if you license something > GPLv2+, someone might fork and modify it to be GPLv3+, I was under the impression that forks couldn't change licenses. Is the scenario which Clint describes (legally) possible? -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3uoxx+f0_ca9lwe-n6p50y-cb4gs683w6cvfqvydw4...@mail.gmail.com
Re: Proposal: let’s have a GR about the init system
On Fri, Oct 25, 2013 at 10:45 AM, Thomas Goirand wrote: > On 10/25/2013 11:02 PM, Thorsten Glaser wrote: >>> Supporting two different init systems is something I don't think >>> *anyone* wants to get into. Remember they use different files, so this >> >> Erm, we already support sysv-rc, file-rc, systemd, upstart… >> so my favourite GR outcome would just say that Debian fully >> commits to continue doing that. > > Plus if we choose Upstart or Systemd, then that's effectively what we > are going to do (I mean, we'd have to support 2 init systems, because of > Hurd & kFreeBSD). popcon.debian.org has some data about the usage of said architectures/kernels: amd64: 92600 i386: 63099 hurd-i386: 25 kfreebsd-amd64: 68 kfreebsd-i386: 53 Holding up development of our Linux architecture for the 0.1% isn't serving the majority of Debian's users well. I know popcon isn't perfect, but its margin of error is acceptable for talking about the gross disparity in number of users between Linux and Hurd/kFreeBSD. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOLfK3V_E=+l6fy6k7qseze6n_faacwskse1q1lct8_hxc2...@mail.gmail.com
Re: Replacing unrar-free with unar wrapper
Hi, On Wed, Sep 25, 2013 at 09:39:12AM +0200, Dominik George wrote: > I think I will send a first patch against unar's Vcs-Git in the course > of today. Besides, I would really like to hear the unar maintainer's > thoughts ☺. I'm one of the unar package maintainers and would be happy to include a wrapper for unar that provides an unrar-like interface. Thanks for working on this. -- Matt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130925231136.ga18...@ftbfs.org
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On Tue, Jul 30, 2013 at 3:57 PM, Russ Allbery wrote: > Christoph Anton Mitterer writes: > >> - The system hostname (and domainname if any) should ALWAYS be >> resolvable, whether a network is up or not, regardless of which. >> (Assuming that lo is always up, if not, many things break anyway.) > > This principal (and the general UNIX tradition of putting the local host > and IP address in /etc/hosts) has caused us no end of problems, since that > information inevitably gets out of date when systems are moved around or > re-IP'd. We now do not put the local hostname anywhere in /etc/hosts, and > I believe that's the correct configuration for any system with stable DNS > and network. Russ, Does not the Wheezy installer still place hostname.domain.name entries in /etc/hosts for said hostname? Or do you mean some entity other than Debian when you say, "we", or is "now" after the Wheezy release? Cheers, -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3vaz9x-xz4mruhmb_q6sjbndzgx7kedkownhvklhmq...@mail.gmail.com
Re: Debian naming scheme
On Mon, Jun 17, 2013 at 12:59 PM, Nikolas Kallis wrote: > Hello, > > > > I think Debian should stop releasing products as I.E 'Debian 7.0', and > instead release them simply as I.E 'Debian 7', where its Debian version > would be 7.0. > > It makes it hard for me writing documentation for applications that run on > Debian when I have to write it supports I.E 'Debian (7.0, 7.1)'. Could your documentation state, 'Debian 7.X' ? -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOLfK3WHo+Wr=lzbumlcb1wpicxtuuzksft2spdg331cdwk...@mail.gmail.com
Re: Debian systemd survey
On Wed, May 22, 2013 at 3:30 PM, Russ Allbery wrote: > Martin Wuertele writes: > >> Seems like you haven't realised yet: only if a maintainer makes >> controversal decisions and several others disagree such a case comes >> before the CTTE. > > Having decisions appealed to the CTTE is not a punishment. It just > indicates that a decision is controversial and the project was unable to > reach a consensus. It's not always possible (and indeed not always wise) > to avoid controversial decisions. > >> Having choices ending up twice within relatively short time before the >> CTTE should give the maintainer a hint. > > It is, for example, probably a hint that the maintainer is working on > something important that a lot of people care deeply about and therefore > have strong opinions about. Well said. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3wxeoscjz06nkqg1qtompftkegp3sb05tz5onng5en...@mail.gmail.com
Re: epoch fix?
On Tue, May 7, 2013 at 5:19 PM, Thorsten Glaser wrote: > Matt Zagrabelny d.umn.edu> writes: > >> Use the mechanism of "really": > > That is *much* *much* *much* *much* *much* *much* *much* *much* *much* > *much* *much* *much* *much* *much* *much* *much* more ugly than epochs > and actually a prime example of why we *want* them. epochs never go away - AIUI. They detract from meaningful information in the version string. I am not a proponent of "+really" - I agree that they are ugly, but they do go away. I wanted to suggest a mechanism for working around unnecessary epochs. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOLfK3VqiQ7A=fzmcydqpy8oumq3tft6f7yu1nxkp3mg7hq...@mail.gmail.com
Re: epoch fix?
On Tue, May 7, 2013 at 5:08 PM, Noel David Torres Taño wrote: > On Martes, 7 de mayo de 2013 22:55:39 Matt Zagrabelny wrote: >> If so, could we add a field to debian/control such as >> "Supersede-Epoch". If set to 'yes', then dpkg considers this package >> to have an epoch of infinity for version comparisons. After the next >> stable is released with this version of the package, then the >> maintainer could remove the control line "Supersede-Epoch" so that >> epochs and dpkg behave as before. > > What if between the time you supersede in unstable and it disappears with > oldstable (several years after) you need again to create an epoch? Use the mechanism of "really": % apt-cache policy libglib2.0-dev libglib2.0-dev: Installed: 2.33.12+really2.32.4-5 Candidate: 2.33.12+really2.32.4-5 Version table: 2.36.1-1 0 1 http://ftp.us.debian.org/debian/ experimental/main amd64 Packages *** 2.33.12+really2.32.4-5 0 500 http://ftp.us.debian.org/debian/ stable/main amd64 Packages 500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages 500 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOLfK3XWHp4VcQWH_kcQUpFXtpgoDkcFEUC+wV4y=g1vra9...@mail.gmail.com
epoch fix?
Hello world, I've grepped the d-d list, but didn't find any threads regarding fixing epochs in package versions. First, is there a consensus or quorum that believes that unnecessary epochs is undesirable? If so, could we add a field to debian/control such as "Supersede-Epoch". If set to 'yes', then dpkg considers this package to have an epoch of infinity for version comparisons. After the next stable is released with this version of the package, then the maintainer could remove the control line "Supersede-Epoch" so that epochs and dpkg behave as before. Comments appreciated. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3xkblw0plu2g0ytmtj7rpnejobs3xwh25dbm0p+atg...@mail.gmail.com
Bug#705897: ITP: dateutils -- nifty command line date and time utilities
Package: wnpp Severity: wishlist Owner: Matthew Fischer * Package name: dateutils Version : 0.2.4 Upstream Author : Sebastian Freundt * URL : http://www.fresse.org/dateutils * License : BSD Programming Lang: C Description : nifty command line date and time utilities Dateutils are a bunch of tools that revolve around fiddling with dates and times in the command line with a strong focus on use cases that arise when dealing with large amounts of financial data. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51744fee.9040...@canonical.com
Re: Bug#705015: ITP: ie7-js -- help Internet Explorer behave like a standards-compliant browser
On Mon, Apr 8, 2013 at 2:29 PM, John Paul Adrian Glaubitz wrote: > On 04/08/2013 09:23 PM, David Prévot wrote: >> >> The purpose would be to provide it, via a libjs-ie7, in order to be used >> as a third party in other packages like spip. As such, I intend to >> maintain it under the Debian Javascript umbrella. > > > And how would I use it on Debian when there is no Internet Explorer 7 > available for non-Windows platforms? Wine? I believe the HTTP server serves the .js to all clients (including IE7.) In other words, this is a server solution for badly behaving clients. Correct me if I am wrong. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOLfK3WJtiDDvthFo+5o-Xd6yBuwxd5d7X2HofROoFqrKQM=e...@mail.gmail.com
Bug#703816: ITP: unyaffs -- Extracts files from a YAFFS2 file system image
Package: wnpp Severity: wishlist Owner: Matthew Fischer * Package name: unyaffs Version : 0.9.5 Upstream Author : Bernhard Ehlers * URL : https://github.com/ehlers/unyaffs * License : GPL-2+ Programming Lang: C Description : Extracts files from a YAFFS2 file system image Unyaffs is a program to extract files from a YAFFS2 file system image. Currently it can only extract images created by mkyaffs2image. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/514e7abc.4010...@canonical.com
Re: Debian logo svg file is not loadable in Inkscape
On Thu, Jan 24, 2013 at 9:51 AM, Christoph Anton Mitterer wrote: > On Thu, 2013-01-24 at 16:35 +0100, Filippo Rusconi wrote: >> fails to load in the much-respected SVG-based graphics editor Inkscape >> (which I use daily and which works fine also for svg files not >> produced by itself). > In mine it loads, version 0.48.3.1-1.3. Curious. I am using the same version (0.48.3.1-1.3) and get the specified failure in the original post. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3xaumqe0eiq_0tfy5ryd0tsz6j8h_dgfrcg_oawyvt...@mail.gmail.com
Re: GFDL in main
On Wed, Dec 12, 2012 at 3:48 AM, Jakub Wilk wrote: > * Serafeim Zanikolas , 2012-12-12, 10:30: > >> If I understand correctly, the way to go is to split every problematic >> source package in two different source packages, one for main (shipping >> programs) and another for non-free (shipping documentation), with the main >> package suggesting the non-free one. > > > First one should ask upstream if they are willing to relicense the > documentation. If they are not, then removing the documentation or moving it > into a non-free package is the only option left. A point of clarification: Relicensing can include an additional license, thus making the documentation dual (or multi) licensed. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOLfK3U=7Vkhudr5JDWahH_sBCjz9C=kvpzo_mqnqfds8ko...@mail.gmail.com
Re: Ubuntu have done it again,
On Fri, Dec 7, 2012 at 5:21 PM, Steve Langasek wrote: > On Sat, Dec 08, 2012 at 12:09:10AM +0100, Svante Signell wrote: >> this time installing surveillance code. > >> http://linux.slashdot.org/story/12/12/07/1527225/rms-speaks-out-against-ubuntu >> http://www.fsf.org/blogs/rms/ubuntu-spyware-what-to-do > >> Any reason Debian should be so closely linked to Ubuntu? > > Curses! My plan to make Debian's default init system phone home has been > foiled! It was probably those meddling kids and their dog. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3vqnqchir5_roxmijhxbntwc7wo-ftos_q66uo0wz6...@mail.gmail.com
Re: debian mate
Hi Michael, On Tue, Nov 20, 2012 at 9:03 PM, Michael Schmitt wrote: > Am 20.11.2012 23:14, schrieb Carlos Alberto Lopez Perez: > >> On 20/11/12 22:55, Michael Schmitt wrote: >>> >>> If one likes Gnome2.x or MATE or not is a question of taste, to >>> acknowledge that many users are just mad about Gnome3 is a fact. To >>> offer no real sane upgrade-path for those users is... dunno how to say >>> it in another way, it is just insane! I did invest some time with >>> thinking about all of this including talking to some MATE folks and >>> current squeeze-gnome-users, and again thinking and thinking... imho it >>> must be done everything possible to try to circumvent that imho probable >>> desaster for the desktop users. Especially when I think of the real >>> *average next door users* not the techie guys who may be happy (or at >>> least not cry to loud about it) to invest some time tweaking their Xfce >>> or KDE to behave more or less like their old gnome2 did. And if you >>> really insist, I can give you detailed reports about what kind of >>> problems those users have with the current DEs in Debian including >>> gnome3, but I don't want to bloat this mail anymore. I just can >>> guarantee you now, the panel in gnome3-fallback being black is not one >>> of them. ;) >>> >>> From my point of view, as said I can't comment much on the technical >>> aspects here. I can just ask those who may have the ability to do so, to >>> do it in a fair way, with as less prejudice as possible. Again, for the >>> users that will have an issue with the current envisioned upgrade-path. >>> For those users not so keen about adding a third-party repo to their >>> sources.list, those users not knowing about the possibility to do so, >>> those users that will get pissed. >>> >>> regards >>> Michael >>> >>> P.S.: I know there is already work in progress for MATE for jessie, I >>> just think that is too late. But I don't want to trip on anyones toes >>> here >> >> AFAIK is completely impossible that Debian ships MATE for Wheezy. Wheezy >> has been frozen time ago and by policy no new packages are allowed in >> the archive for testing during the freeze. > > So much for the general rules... but exceptions ARE possible! And I just try > to make a case here about how important it might be! > > >> If you want a "classical" desktop your main options are: gnome3-classic, >> XFCE and LXDE. You have also cinnamon on sid (it won't make to wheezy) > > It is *not* about me and I know already all available options in all > possible flavors and directions available as of today for wheezy. I'm guessing that by the time wheezy is released MATE will be in unstable and the wheezy-backports won't be far behind. It is a sensible compromise. Remember, Debian is more that just a Desktop operating system. Let's work within policy and be respectful to those who are working hard to get the release ready. Cheers, -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3xq2cntrywk1lgjslglrhxv1yrfrbshoahrn3lprr_...@mail.gmail.com
Re: Help me DTRT with upstream naming
On Fri, Sep 7, 2012 at 8:33 PM, The Fungi wrote: > On 2012-09-07 16:40:07 -0700 (-0700), Russ Allbery wrote: > [...] >> The problem is that the software is called wallet, both the >> software itself and the primary client binary that users invoke. >> [...] I don't think there's another UNIX/Linux binary of that >> name. But, of course, it's still not a very unique name. [...] >> (see the recent node discussion), but on the other hand it's going >> to be a big pain for me and for users > [...] > > Frequently invoked console/text utilities have a good excuse for > taking up short, easily typed and easily remembered words in the > executable path namespace. That strikes me as the real reason to > avoid having programs commonly launched from a GUI icon of some sort > polluting that namespace--they aren't frequently called from the > CLI. > > If your users are used to entering "wallet blah" and there's no > wallet command in another package already, I'd be in favor of > leaving it as is. Spending most of my life in a CLI, I'm not at all > fond of typing one mile-long-hyphenated-command-name after another. That is what tab completion is for. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3xy+4tk9aya89rezateq0bqsnyxckk92g3sx0gsqpc...@mail.gmail.com
Re: tasksel: Default desktop: Gnome→Xfce
On Fri, Aug 3, 2012 at 4:52 PM, Arno Töll wrote: > Hi, > > On 03.08.2012 23:28, Michael Biebl wrote: >> Seriously, I'd just drop our CD1 installs and only provide a net-install >> image and a DVD image for desktop installations. > > Is there any serious survey how established DVD drives (and writers) are > these days? CD images might be obsolete some day, but we should be sure > (virtually) nobody notices once we drop it. I don't know about serious surveys, but flash drives are ubiquitous and have large storage. Some (many?) laptops don't have optical drives either. For D-I, I would pick the most common USB flash drive size (perhaps 2.0 GB) and target that. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3u2er-v1xcyuzptmjskn_amiikcpa_kmgbfjnbp4mf...@mail.gmail.com
Re: Have NetworkManager disabled by default when...
On Wed, Jul 18, 2012 at 3:46 PM, Michael Biebl wrote: > On 18.07.2012 22:32, Wookey wrote: > >> wicd is easy to disable as it has a ENABLE/DISABLE option in >> /etc/defaults. N-M doesn't so you either have to remove it properly or >> resort to nobbling the init script. > > Nope, you don't have to "nobble" the init script. > Use "update-rc.d network-manager disable". > That's the proper interface to disable sysv services from starting. > Those /etc/defaults ENABLE switches are a hack > > Why are people not a aware of that update-rc.d interface? Is this a > general documentation problem? I've been under the impression that future upgrades to the package would re-enable the symlinks whereas /etc/default is not touched by upgrades. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOLfK3W3F=-kwd5mdn-a03ulai3rk8trggx-op7bh2g0jyr...@mail.gmail.com
Re: Packaging entirely via git
On Tue, Jun 12, 2012 at 2:48 PM, Luis Alejandro Martínez Faneyth wrote: > El 12/06/12 12:40, Enrico Weigelt escribió: >> >> Hi folks, >> >> >> is there already a way for maintaining debian packages entirely >> with git - without the orig tarball ? I use something like this in the gbp.conf: [DEFAULT] builder = /home/mzagrabe/bin/git-pdebuild upstream-branch = master debian-branch = debian upstream-tag= v%(version)s -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3v28jvwwcen57+ouszs4mcdhdurgzu7ifun2jxg+1z...@mail.gmail.com
Re: Node.js and it's future in debian
On Thu, May 3, 2012 at 12:35 PM, Patrick Ouellette wrote: > On Thu, May 03, 2012 at 01:10:24PM +0200, Vincent Bernat wrote: >> >> As said many times, node is an interpreter used in shebang. Using a >> different name would just upset its user base. Debian will be seen, >> again, as the one harming a community, like this may happen in the >> Ruby community because of lack of understanding on how we work. >> Outside of Debian, nobody will understand why a package related to >> HAM radio hinders the use of one of the trendiest package (in the >> top 5 of most watched and forked repository in GitHub). > > So every time something is the hot new trend it has the right to usurp > an established package's binary namespace? I'm not asking this to be > argumentative, I really want to know if this is your intention. Not speaking for Vincent, here is my take: A namespace is something that is distinctive and specific. "Node" is neither. As it stands, it is foolish for both projects to use such name(s). All that being said, it would be nice to come to a "good" (or the "best" possible) solution. Those are subjective terms and that is why the arguments are revolving around popularity, ease of transitions, and the "best" interests for (the majority of) Debian's users. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOLfK3X=suoOLi-6gR=godx1fh8m8qdc3vuh7yxd7kdrakh...@mail.gmail.com
Bug#666961: ITP: milter-regex -- sendmail milter plugin for regular expression filtering
Package: wnpp Severity: wishlist Owner: Matt Zagrabelny * Package name: milter-regex Version : 1.9 Upstream Author : Daniel Hartmeier * URL : http://www.benzedrine.cx/milter-regex.html * License : BSD Programming Lang: C Description : sendmail milter plugin for regular expression filtering The milter-regex plugin can be used with the milter API of sendmail(8) to filter mails using regular expressions matching SMTP envelope parameters and mail headers and body. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120402211057.28334.66276.report...@achilles.d.umn.edu
Re: NM without X (general: users vs developers)
On Fri, Mar 23, 2012 at 5:49 PM, Svante Signell wrote: > On Fri, 2012-03-23 at 22:29 +, Jon Dowland wrote: >> This is completely off-topic for -devel. Please take it to debian-user >> if you want to continue. > > No it is not, this is as important as the systemd/upstart/sysvint\ > issue, now being discussed on Debian devel. The general question is: > How much tolerance do we as users have towards the developers lack of > listening to their users, not their own Freud happiness. As an > example: How much has gnome3 contributed to _users_ experiences, I'm > using the fall-back solution, due to lack of alternatives right now. I don't contribute as much as I'd like to Debian and thus my view of d-devel might be wrong, but this mailing list is for developers who need to communicate with developers. Not a place for users to air their grievances. If you have coding solutions, please offer them or if you need development advice, then ask. Otherwise, no one is soliciting opinions about NM or gnome3. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOLfK3UKjm65Dtcje=wsv0bkj+uuhp_tuo14eh0r5ecrtdr...@mail.gmail.com
Re: On init in Debian
On Fri, Mar 23, 2012 at 9:39 AM, Ritesh Raj Sarraf wrote: > Today, on my typical laptop, boot is not the most important task. It > is better to have something well working, fixable (being mere shell > scripts and that's what your friend is also pointing). sysvinit serves > this purpose well. booting is just one of the things systemd/upstart changes. I was working with a daemon yesterday (conserver-server, FWIW) and I performed: invoke-rc.d conserver-server restart This did not *successfully* restart the daemon. The daemon spawned some ssh tunnels. These were forked off and had a parent PID of 1, did not terminate, and caused a the daemon to not start correctly. It is my understanding that systemd (not sure about upstart) would correctly handle scenarios like this (by using cgroups.) Switching gears... If systemd becomes as widespread as pulseaudio (is becoming), we may not have much of a choice about using it or not using it. If a critical mass of upstreams use it, we will be somewhat forced to use it. In 3-5 years instead of talking about sysvinit replacements and the mechanics involved, we will be talking about how to retrofit our packages to work around (or without) systemd. Cheers, -matt zagrabelny -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3wjmrcomksb4quq5w7fuqmlbx08+++nafebxyjkgcp...@mail.gmail.com
Re: Unofficial repositories on 'debian' domains
On Mon, Mar 5, 2012 at 11:55 AM, Reinhard Tartler wrote: > On Mon, Mar 5, 2012 at 6:32 PM, Matt Zagrabelny wrote: >> On Mon, Mar 5, 2012 at 9:45 AM, Reinhard Tartler wrote: >>> On Mon, Mar 5, 2012 at 11:52 AM, Milan P. Stanic wrote: >>>> For me d-m.o was (and still is) valuable resource. >>>> Some codecs missing in Debian packages because of the policy (I don't >>>> blame Debian for that) and in that case d-m.o is best option for me >>>> because I don't want/have time to package it from the source. >>> >>> Out of curiousity, what codecs do you miss in the official debian packages? >> >> libdvdcss2 > > This is not a codec but a software package that cracks an encryption > algorithm. It has been packaged for debian proper, uploaded and got > rejected by ftp-master. BTW, the reason did not involve patents, > AFAIUI. I understand that it is not a codec. ;) Nevertheless, it is a package that I find myself installing on just about any workstation with a DVD drive. > As an alternative source, the libdvdread3 package used to ship a > /usr/share/doc/libdvdread3/install-css.sh script, which fetched a > libdvdcss2 packages from debian-unofficial.org. From a packaging and > maintenance POV, that package is in a much better state. Too bad that > the libdvdread maintainer removed that really handy script. What then is the "recommended" way of installing a the decryption library for DVD/CSS? I mean, from what I've read in this thread, d-m.o is not cooperative with d.o regarding packages, what is the recommended way of installing that libdvdcss2? Cheers, -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3wwy8k2agk-y307zbncroydamxitmpe_576s_nd8me...@mail.gmail.com
Re: Unofficial repositories on 'debian' domains
On Mon, Mar 5, 2012 at 9:45 AM, Reinhard Tartler wrote: > On Mon, Mar 5, 2012 at 11:52 AM, Milan P. Stanic wrote: >> For me d-m.o was (and still is) valuable resource. >> Some codecs missing in Debian packages because of the policy (I don't >> blame Debian for that) and in that case d-m.o is best option for me >> because I don't want/have time to package it from the source. > > Out of curiousity, what codecs do you miss in the official debian packages? libdvdcss2 This may have been mentioned elsewhere in this thread, but a wiki page under wiki.debian.org instructs users to use d-m.o as a repository to get various codecs. http://wiki.debian.org/MultimediaCodecs Obviously wikis need to be taken with a grain of salt, but anything (including wiki.d.o) under the debian.org domain feels somewhat official and can lead users without the requisite knowledge to heed said advice. If there are users out there who can distill their knowledge regarding codecs and improve the wiki page, then that would be much appreciated. Thanks! -matt zagrabelny -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3xqxeg-zjzcekbmo3mbto-9cqyscpmuevzfkq-rwza...@mail.gmail.com
Re: upstart: please update to latest upstream version
On Tue, Feb 28, 2012 at 12:22 PM, Russ Allbery wrote: > I, for one, have even more of a problem > contributing to FSF projects that require copyright assignment than I > would contributing to upstart. Hi Russ, Would you comment on why you have issues with the FSF contributor agreement? Thanks, -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOLfK3Uoxi069Q=rhh5qbbfcjnal5on9f1eg_jtzjuvovb5...@mail.gmail.com
Re: Bug#655230: ITP: pushkey -- ITP: pushkey - Pushes your ssh key to a remote location. It tries to create a .ssh folder remotley then it adds your ssh key to authorized_keys.
Hi Al, On Mon, Jan 9, 2012 at 7:12 PM, Al wrote: > OK I guess I am partially incorrect, however if .ssh or authorized_keys is > wrong permission, ssh-copy-id doesn't fix it.. > I set .ssh folder to 777 and ssh-copy-id did not change it. That is the sane behavior here. The utilities that come in the openssh-client package do not set .ssh to 777, they set it to 600, hence if it is set to 777, then someone *manually* did that. That person should then manually fix it. It would be illogical for some other program to "fix" the perms. A manual correction is the proper place for it. Also, pushkey is doing more than what it name implies. The name implies that a key would get pushed, however: 1) a key gets created 2) it gets pushed 3) directory mode is changed I wouldn't expect, nor want, 3 and possibly 1. I don't think anyone is going to: "apt-get install pushkey" When there is already a tool to copy keys around. I know that push key will generate a key, but that goes against the grain of the UNIX philosophy of having tools do one job and do it well. It seems best to stick with: ssh-keygen (once in a great while) ssh-copy-id system (whenever you need to ssh to a new system) I don't think anyone will advocate for "pushkey", it seems rather unnecessary. Respectfully, -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3u8tkbk2nfsy-joqeb-n5ehw0jztsv9pq0ugr7_++v...@mail.gmail.com
Re: Move all to /usr
On Tue, Oct 11, 2011 at 11:09 AM, Ivan Shmakov wrote:
> Saving a dozen of bytes in ${PATH} doesn't seem like an
> astonishing idea, anyway. What's the point, then?
There are good arguments in the following link (Marco provided it with
his initial email.)
https://fedoraproject.org/wiki/Features/UsrMove
-mz
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAOLfK3VOVgfKeRb=0vs3rzbbticnb5lszkyprpzog9eocdc...@mail.gmail.com
Re: alternative dependency ordering - with respect of packages in main
Hi Bruce, >> > I hope Debian would honour the Social Contract and put the needs of the >> > users ahead of software freeness concerns in that case. >> >> Do we have a name for the DFSG equivalent of Godwin's Law? Because you >> just failed it. > > Well, that's disappointing... called a Nazi for daring to explore the > possibilities. I think you misread what Steve was saying. When you were calling out those who are concerned about software free-ness, you were calling them "Nazis". Steve was not calling you a Nazi. Anyhow... If we don't have software free-ness, we don't really have much of a social contract. -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3wimovdqj7bryziw5jix1cs+bezebs-rbydqzbv+py...@mail.gmail.com
