Re: How long it takes to update metadata.ftp-master.debian.org for packages from stable-security ?
https://lists.debian.org/debian-www/2015/01/msg00034.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490848 This problem has existed since 2015 and I will follow to see what the outcome of this bug will be. Thanks! 樂
Re: How long it takes to update metadata.ftp-master.debian.org for packages from stable-security ?
On Sun, Jun 2, 2024 at 11:50 AM Computer Enthusiastic wrote: > > Hello everyone, > > The gstreamer1.0-alsa has been updated recently: > > $ apt -a list gstreamer1.0-alsa > Listing... Done > gstreamer1.0-alsa/stable-security,now 1.22.0-3+deb12u2 amd64 > [installed,automatic] > gstreamer1.0-alsa/stable 1.22.0-3+deb12u1 amd64 > > When I try to get the Debian changelog from > metadata.ftp-master.debian.org, it is not available: > > $ apt-get changelog gstreamer1.0-alsa > Err:1 https://metadata.ftp-master.debian.org gst-plugins-base1.0 > 1.22.0-3+deb12u2 Changelog >Changelog unavailable for gst-plugins-base1.0=1.22.0-3+deb12u2 (404 > Not Found [IP: 146.75.54.132 443]) > E: Failed to fetch > https://metadata.ftp-master.debian.org/changelogs/main/g/gst-plugins-base1.0/gst-plugins-base1.0_1.22.0-3%2bdeb12u2_changelog > Changelog unavailable for gst-plugins-base1.0=1.22.0-3+deb12u2 (404 > Not Found [IP: 146.75.54.132 443]) > > I was wondering how long it takes to update > metadata.ftp-master.debian.org for packages from stable-security repository: > a) Is there a fixed amount of time or a timeout ? > b) Is this an automatic process ? > c) Does it require manual intervention? > > I read in the Debian documentation [1][2] that the stable-security.d.o. > repository runs in parallel with stable.d.o. > > Thanks for any answer and/or reference to further documentation. > > -- > [1] > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security > [2] > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-building > It occurs with other packages like nodejs. apt changelog nodejs Err:1 https://metadata.ftp-master.debian.org nodejs 18.19.0+dfsg-6~deb12u1 Changelog Changelog unavailable for nodejs=18.19.0+dfsg-6~deb12u1 (404 Not Found [IP: 2a04:4e42:16::644 443]) E: Falhou ao buscar https://metadata.ftp-master.debian.org/changelogs/main/n/nodejs/nodejs_18.19.0%2bdfsg-6%7edeb12u1_changelo g Changelog unavailable for nodejs=18.19.0+dfsg-6~deb12u1 (404 Not Found [IP: 2a04:4e42:16::644 443]) -- Cheers, Leandro Cunha
Re: Debian 10 "buster" moved to archive.debian.org
Hi, On Fri, May 24, 2024 at 10:28 PM Otto Kekäläinen wrote: > > Hi! > > So just to clarify, are you saying that a copy of > https://security.debian.org/debian-security/dists/buster/ will never > be archived at https://archive.debian.org/debian-security/dists/ like > previous releases have been so far? > > This is not about getting *new security updates*, but purely a > question of how moving Buster to archival works and how e.g. CI > systems that test upgrades from Buster should work. > > I see that e.g. > https://deb.debian.org/debian/dists/buster/main/binary-armel and > https://deb.debian.org/debian/dists/buster-updates/main/binary-armel > no longer exists, but have been archived at > https://archive.debian.org/debian/dists/buster/main/binary-armel/ and > https://archive.debian.org/debian/dists/buster-updates/main/binary-armel/. > > The > https://security.debian.org/debian-security/dists/buster/updates/main/binary-armel > is now gone, is the intent for it to show up on archive.debian.org in > some form? True, you're right, the buster is missing from https://archive.debian.org/debian-security/dists/ and I'm waiting for a response from the people who take care of this repository about this. I think they forgot to migrate. -- Cheers, Leandro Cunha
Re: About i386 support
Andrey, On Tue, May 21, 2024 at 3:31 AM Andrey Rakhmatullin wrote: > > On Mon, May 20, 2024 at 07:16:54PM -0300, Leandro Cunha wrote: > > > > > which is good news. The end of support for 32 bits will not > > > > > affect the lives of almost anyone who has machines purchased after > > > > > 2011 and who bought them after that > > > > > > > > Does this also mean he support for armhf will be dropped ? > > > There is no "end of support for 32 bits" yet so no. > > When you refer to 32 bits you are referring to i386 (see the subject), > No, please don't, this confuses people. > > -- > WBR, wRAR I agree that it can be confusing, but I mentioned that we are specifically talking about this architecture (i386) that is in the subject of the email and to avoid confusion. -- Cheers, Leandro Cunha -BEGIN PGP PUBLIC KEY BLOCK- mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh 0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7 ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3 k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx /m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C +DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4 hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08 iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X 7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00 4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9 WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O +SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW fNdY6Ns= =rdCA -END PGP PUBLIC KEY BLOCK-
Re: About i386 support
On Mon, May 20, 2024 at 6:11 PM Andrey Rakhmatullin wrote: > > On Mon, May 20, 2024 at 10:57:58PM +0200, William Bonnet wrote: > > > which is good news. The end of support for 32 bits will not > > > affect the lives of almost anyone who has machines purchased after > > > 2011 and who bought them after that > > > > Does this also mean he support for armhf will be dropped ? > There is no "end of support for 32 bits" yet so no. > > > -- > WBR, wRAR When you refer to 32 bits you are referring to i386 (see the subject), they are different architectures. [1] https://en.wikipedia.org/wiki/I386 -- Cheers, Leandro Cunha
Re: About i386 support
Hello, On Mon, May 20, 2024 at 5:15 PM Paul Gevers wrote: > > Hi, > > On 20-05-2024 4:50 p.m., Ben Hutchings wrote: > > There is a tension here between the interests of (a) users that want to > > run proprietary i386 binaries on 64-bit CPUs, and (b) those who want to > > keep using 32-bit CPUs. If i386 is meant for group (a) then the > > baseline should be raised to include the features that 64-bit CPUs > > provide, but if it's also for group (b) then this mustn't happen. > > The Release Team expects the Debian i386 official port to go to (a). > > Paul, wearing his Release Team hat. LOL, I hope so too... However, the future stable version will feature RISC-V (at least it's expected), which is good news. The end of support for 32 bits will not affect the lives of almost anyone who has machines purchased after 2011 and who bought them after that, which I know was the year I bought a machine starting to use Debian 1 year later. Another interesting development that is underway and is inherent to the topic would be the time_t transition (the 2038 problem). -- Cheers, Leandro Cunha
Re: Debian 10 "buster" moved to archive.debian.org
Hi Otto, In Buster's case, it would be becoming an ELTS soon and would have to use Freexian's repositories. It would no longer be the security team with DLAs that would take care of CVEs for ELTS, but the Frexian team. So much so that if I look at the links below I didn't find anything (about security) for versions with extended support. https://archive.debian.org/debian/dists/ https://security.debian.org/debian-security/dists/ This point you mentioned is relevant. I will be following the finally of this conversation. Look, I hope I helped in some way and I realize that many users don't know the Freexian repositories. [1] https://www.freexian.com/lts/php/docs/access-apt-repositories [2] https://wiki.debian.org/LTS/Extended Cheers, Leandro Cunha
Re: About i386 support
Hi, Looking at projects like Arch, Manjaro, Ubuntu, Fedora and other operating system projects developed to use Linux as the kernel, we realize that none of them provide ISO for 32 bits. A brief search led me to Debian as the only one I've seen so far ( https://www.debian.org/releases/bookworm/debian-installer) and that's a few years old. I don't see a future in 32 bits at the moment and I may be bold in saying that I see a future in ARM 64 technologies for laptops and even being able to exist in desktops as well. There are already some Lenovo laptops and even MacBooks with this technology (arm 64). Processors like the Qualcomm Snapdragon 8cx Gen 3 and Apple M3 have also attracted attention. Leandro Cunha
Re: dash and mutt
Hi, Em sex., 19 de abr. de 2024, 04:46, Marco d'Itri escreveu: > On Apr 19, José Luis González González wrote: > > > I even tried to reach dash maintainer privately and he is not even on > > the package's field (queried by dpkg), there's someone who is obviosly > > fake instead: Andrej Shadura > I have met Andrej a few times and I am quite sure that he is real. > Or maybe I am part of the plot as well? How can you know? > > > If this is not solved I will cease to stop using Debian and Debian will > > die. > OK, good luck with your next operating system. > > -- > ciao, > Marco > Look, I don't understand why you call him fake. He even speaks at Debian events. I talked to DDs who also know him personally. Ser https://youtu.be/si7_O6h8aBQ?si=kW2eOM0uvvFBTvsj >
Re: xz backdoor
Hi, On Sat, Mar 30, 2024 at 7:00 PM Santiago Ruano Rincón wrote: > > > > Em 30 de março de 2024 13:00:26 GMT-03:00, Marco d'Itri > escreveu: > >On Mar 30, Jonathan Carter wrote: > > > >> Another big question for me is whether I should really still > >> package/upload/etc from an unstable machine. It seems that it may be > >> prudent > >If we do not use unstable for development then who is going to? > >I think that the real question is whether we should really still use > >code-signing keys which are not stored in (some kind of) HSM. > > > > The backdoor was discovered by someone using the compromised xz-utils *in > their own machines*. So we are lucky we have people eating our own sid stuff > before it becomes part of a stable release. > You told the truth, sometimes I think it's better to wait a while to launch very new versions, doing tests beforehand and looking for problems. But if the person hadn't sent the backdoored version to unstable, hadn't worried about issues of seconds of performance, in my opinion it would be quite possible that this would have been in vain and the person did a great job in mitigating this (I personally I found very interesting). But on the other hand it caused inconvenience because I saw in an email here that the processing of the Debian file is momentarily turned off until it checks what needs to be done. -- Cheers, Leandro Cunha -BEGIN PGP PUBLIC KEY BLOCK- mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh 0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7 ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3 k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx /m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C +DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4 hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08 iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X 7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00 4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9 WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O +SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW fNdY6Ns= =rdCA -END PGP PUBLIC KEY BLOCK-
Re: Debian testing/unstable users: beware of Firefox critical CVEs
Hi, On Mon, Mar 25, 2024 at 2:18 AM Paul Wise wrote: > > On Sun, 2024-03-24 at 22:45 +, Samuel Henrique wrote: > > > I'm sending this to d-devel because there should be a lot of testing and > > unstable users on this list. If you're not running firefox 124.0.1 or > > firefox-esr 115.9.1esr-1, you should find a way of upgrading to those > > versions. > > firefox-esr from bookworm-security is currently installable on trixie, > but there is no solution from Debian for firefox 124.0.1 yet. > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise I'm using it in testing, but I merged unstable packages (dependencies resolution) to get firefox-esr and it's working fine so far. I'm even typing this email in firefox-esr. What left something to be desired so far and I had to downgrade was Chromium 123 and downgrade to 122 present in tests (trixie). Chromium freezes the tab the person is accessing and I don't yet have detailed information about the problem, but 122 works fine. -- Cheers, Leandro Cunha -BEGIN PGP PUBLIC KEY BLOCK- mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh 0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7 ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3 k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx /m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C +DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4 hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08 iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X 7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00 4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9 WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O +SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW fNdY6Ns= =rdCA -END PGP PUBLIC KEY BLOCK-
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
Hi,
On Mon, Sep 18, 2023 at 4:20 PM Helmut Grohne wrote:
>
> Hi,
>
> On Sat, Sep 16, 2023 at 10:31:20AM +0530, Hideki Yamane wrote:
> > Today I want to propose you to change default compression format in .deb,
> > {data,control}.tar."xz" to ."zst".
> >
> > I want to hear your thought about this.
>
> I am not very enthusiastic about this idea. I skip over those arguments
> already raised by others and add one that I haven't seen thus far. zstd
> is quite optimized for 64bit CPUs and for amd64 in particular. amd64 is
> the only architecture for which zstd provides a hufmann implementation
> in assembly.
>
> > ## More CPUs
> >
> > 2012: ThinkPad L530 has Core i5-3320M (2 cores, 4 threads)
> > 2023: ThinkPad L15 has Core i5-1335U (10 cores, 12 threads)
> >
> >
> > https://www.cpubenchmark.net/compare/817vs5294/Intel-i5-3320M-vs-Intel-i5-1335U
> > - i5-3320M: single 1614, multicore 2654
> > - i5-1335U: single 3650, multicore 18076 points.
>
> While the majority of CPUs in active deployments is amd64, I'd also like
> to see numbers for 32bit CPUs and non-x86 ones. While I personally find
> the trade-off by zstd fit for a number of my use cases, I was also
> surprised just how slow it decompresses on armhf.
>
> I found some arm board with some linux kernel package sized 36MB.
>
> algo | compressed size | decompression time
> --+-+---
> xz | 36MB| 14.7s
> zstd | 52MB| 5.2s
> zstd -9 | 48MB| 5.2s
> zstd -11 | 47MB| 5.4s
> zstd -19 | 41MB| 5.7s
>
> Not as slow as I remembered apparently, but it still has a more than 10%
> size overhead. The size ratio is consistent with Robert Edmond's
> numbers, but we no longer see that 10-fold speedup. And this did not
> look at decompression memory requirements.
>
> I am decompressing a *lot* of .debs (dedup.d.n, multiarch hinter,
> crossqa.d.n, dumat). All of these applications would benefit from zstd
> compressed .debs in terms of decompression speed. Yet, that has never
> been the bottleneck to me. To me, download speed matters more and
> swapping out a 1GBit link for a faster one isn't that easy.
>
> I'd vote against this given the data we have now.
>
> Can we defer the discussion until there are more convincing numbers?
>
> Helmut
>
If even Helmut voted against, I also vote and I package both for Arch
and Debian, I didn't notice that much of a difference in performance
for compression/decompression. But I use an NVME on the machine (it's
usually very fast along with a processor that isn't slow either) I use
to compile the packages I work with. But when you say that the numbers
are not that convincing, I agree.
--
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-
mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9
Re: Firmware - what are we going to do about it?
Hi, On Mon, Apr 18, 2022 at 9:28 PM Steve McIntyre wrote: > > TL;DR: firmware support in Debian sucks, and we need to change this. See the > "My preference, and rationale" Section below. > > In my opinion, the way we deal with (non-free) firmware in Debian is a mess, > and this is hurting many of our users daily. For a long time we've been > pretending that supporting and including (non-free) firmware on Debian systems > is not necessary. We don't want to have to provide (non-free) firmware to our > users, and in an ideal world we wouldn't need to. However, it's very clearly > no > longer a sensible path when trying to support lots of common current hardware. > > Background - why has (non-free) firmware become an issue? > = > > Firmware is the low-level software that's designed to make hardware devices > work. Firmware is tightly coupled to the hardware, exposing its features, > providing higher-level functionality and interfaces for other software to use. > For a variety of reasons, it's typically not Free Software. > > For Debian's purposes, we typically separate firmware from software by > considering where the code executes (does it run on a separate processor? Is > it > visible to the host OS?) but it can be difficult to define a single reliable > dividing line here. Consider the Intel/AMD CPU microcode packages, or the > U-Boot firmware packages as examples. > > In times past, all necessary firmware would normally be included directly in > devices / expansion cards by their vendors. Over time, however, it has become > more and more attractive (and therefore more common) for device manufacturers > to not include complete firmware on all devices. Instead, some devices just > embed a very simple set of firmware that allows for upload of a more complete > firmware "blob" into memory. Device drivers are then expected to provide that > blob during device initialisation. I'm from the group that defends Debian current position on this and I like to install only what the machine needs to work and I use free firmware on my machine for the wireless network card for example. I don't see it as a mess, but it's organized by separating what's free from what's not. The question of identifying what firmware my machine needs, this for me is easy and it was just a question I had to learn in the beginning many years ago. It is a problem for some and not for all. There is the unofficial installer that solves this problem by installing only what the user's machine needs without the user doing it himself. -- Cheers, Leandro Cunha Software Engineer and Debian Contributor
Re: Helping Ukraine with Debian
Hi, On Thu, Apr 7, 2022 at 3:41 AM Matt Grant wrote: > > 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 They have a Ukrainian language forum and mailing list. As I don't understand this language, I can't say that it was portrayed in one of these links and I see it as the most viable way to have contact with Ukrainians or get information to contribute. Links taken from the page [3]. [1] https://linux.org.ua [2] https://lists.debian.org/debian-user-ukrainian [3] https://www.debian.org/international/Ukrainian -- Cheers, Leandro Cunha Software Engineer and Debian Contributor -BEGIN PGP PUBLIC KEY BLOCK- mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh 0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7 ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3 k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx /m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C +DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4 hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08 iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X 7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00 4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9 WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O +SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW fNdY6Ns= =rdCA -END PGP PUBLIC KEY BLOCK-
Re: Bits from the Release Team: bookworm freeze dates (preliminary)
Hi, On Tue, Mar 15, 2022 at 7:05 PM Pierre-Elliott Bécue wrote: > > > Leandro Cunha wrote on 15/03/2022 at > 22:57:39+0100: > > > On Tue, Mar 15, 2022 at 5:16 PM Pierre-Elliott Bécue > > wrote: > > > > Paul Gevers wrote on 14/03/2022 at 21:43:38+0100: > > > > > Dear all, > > > > > > We are currently considering the following dates as our freeze > > > dates. If you are aware of major clashes of these dates with anything > > > we depend on please let us know. We also like to stress again that we > > > really would like to have a short Hard and Full Freeze (counting in > > > weeks, rather than months), so please plan accordingly. If serious > > > delays turn up during any of the Freeze steps, we rather (partially or > > > completely) thaw bookworm again than staying frozen for a long time. > > > > > > 2023-01-12 - Milestone 1 - Transition and toolchain freeze > > > 2023-02-12 - Milestone 2 - Soft Freeze > > > 2023-03-12 - Milestone 3 - Hard Freeze - for key packages and > > > packages without autopkgtests > > > To be announced - Milestone 4 - Full Freeze > > > > > > On behalf of the Release Team, > > > > Hi, > > > > OOC, isn't that a bit "too short"? We started to work again in August > > 2021, it'll be less than two years until the freeze. > > > > Less than 1 year to go to milestone 1 starts in January. > > I was referring to the delay between the end of the freeze and the next > hard freeze. > > -- > PEB Ok. Debian has been releasing versions every 2 years for a long time. I was looking at the site here to remember the dates. It is a cycle that is being continued. https://www.debian.org/releases/ -- Cheers, Leandro Cunha Software Engineer and Debian Contributor
Re: Bits from the Release Team: bookworm freeze dates (preliminary)
On Tue, Mar 15, 2022 at 5:16 PM Pierre-Elliott Bécue wrote: > > Paul Gevers wrote on 14/03/2022 at 21:43:38+0100: > > > Dear all, > > > > We are currently considering the following dates as our freeze > > dates. If you are aware of major clashes of these dates with anything > > we depend on please let us know. We also like to stress again that we > > really would like to have a short Hard and Full Freeze (counting in > > weeks, rather than months), so please plan accordingly. If serious > > delays turn up during any of the Freeze steps, we rather (partially or > > completely) thaw bookworm again than staying frozen for a long time. > > > > 2023-01-12 - Milestone 1 - Transition and toolchain freeze > > 2023-02-12 - Milestone 2 - Soft Freeze > > 2023-03-12 - Milestone 3 - Hard Freeze - for key packages and > > packages without autopkgtests > > To be announced - Milestone 4 - Full Freeze > > > > On behalf of the Release Team, > > Hi, > > OOC, isn't that a bit "too short"? We started to work again in August > 2021, it'll be less than two years until the freeze. > > Less than 1 year to go to milestone 1 starts in January. -- Cheers, Leandro Cunha Software Engineer and Debian Contributor
Re: Bits from the Release Team: bookworm freeze dates (preliminary)
Hi, On Mon, Mar 14, 2022 at 6:23 PM Jameson Graef Rollins wrote: > > On Mon, Mar 14 2022, Paul Gevers wrote: > > We are currently considering the following dates as our freeze > > dates. If you are aware of major clashes of these dates with anything > > we depend on please let us know. We also like to stress again that we > > really would like to have a short Hard and Full Freeze (counting in > > weeks, rather than months), so please plan accordingly. If serious > > delays turn up during any of the Freeze steps, we rather (partially or > > completely) thaw bookworm again than staying frozen for a long time. > > > > 2022-01-12 - Milestone 1 - Transition and toolchain freeze > > 2022-02-12 - Milestone 2 - Soft Freeze > > 2022-03-12 - Milestone 3 - Hard Freeze - for key packages and > > packages without autopkgtests > > To be announced - Milestone 4 - Full Freeze > > Have not all of these dates already past? Or are these milestones over > three consecutive days in December of this year? > > jamie. > He sent an email with the corrected dates. Debian release occurs every 2 years. The last release one was last year. The next one will be next year. -- Cheers, Leandro Cunha Software Engineer and Debian Contributor
Re: How to contribute ?
Hi, On Tue, Dec 21, 2021 at 4:06 PM Maxime Lombard wrote: > > Hello, > > I'm an user of Debian since 10 years ago and it's only now that i decide to > help to packaging. > I send this email about wine and wine-development package which are not > updated since a very long time. > > The last wine stable version on Sid is the 5.0 and development version is > 6.0+repack. Currently, the wine source code is frozen and the new stable > version 7.0 will release next month. > --> I sent email to Michael Gilbert (without answer from him) and open a bug > report recently to update package. > > Same thing with vkd3d package 1.2 which is still in "experimental" since a > long time too. > I think it's not in Unstable because the test fail with mesa-vulkan-driver >= > 21 (see changelog) > --> I open a bug report upstream about this failure (see > https://bugs.winehq.org/show_bug.cgi?id=52248). Is it possible to build the > package without to do test (set --disable-tests to configure) ? > > Nowadays, the last package of wine-development was uploaded ~6 months ago. > More bugs report opened the last months have no answer from Maintainer > (999753, 995580), same thing with vkd3d bug (994186, 993570) > > I packaged myself vkd3d 1.2-7 and wine-development 7.0~rc2 and all works > correctly. > I updated debian folder for wine to prepare the next Stable version. > > My question is, how to contribute and hope to have updated version of this > package in Debian since I am a novice ? > > Thanks for your answer, >Maxime Yes, there are some packages that haven't been updated for a while. One of them is the retroarch that next year completes its second without updates and the chromium. And I believe it is open to anyone who wants to contribute. There are some processes such as ITS, NMU, QA (orphan packages) and team upload (for packages kept in teams where it is necessary to work with someone on the team or be part of the team). I usually help with QA work and team uploads. But I did deal with ITS once. Full reference on this. https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#managing-packages https://www.debian.org/devel/wnpp https://wiki.debian.org/WNPP https://wnpp.debian.net I remember thinking that it was necessary to be a DM or DD to contribute to Debian and over time I realized I was wrong. Happy 2022! ;) -- Cheers, Leandro Cunha Information Systems Developer and Software Engineer. -BEGIN PGP PUBLIC KEY BLOCK- mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh 0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7 ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3 k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx /m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C +DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4 hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08 iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X 7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00 4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g Q8gCGwwACgkQwtnjMpRb0Dzh6g//
Dúvida com relação a adoção de pacotes
Olá, Surgiu uma dúvida com relação a um pacote que está sem manutenção por parte de seu mantenedor há mais de um ano, eu poderia lançar um ITA para este pacote? O que é feito neste caso? Eu mesmo já andei trabalhando nele, tenho interesse em continuar trabalhando e oferecendo novas versões upstream. -- Cheers, Leandro Cunha Debian Contributor and developer. -BEGIN PGP PUBLIC KEY BLOCK- mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh 0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7 ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3 k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx /m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C +DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4 hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08 iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X 7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00 4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9 WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O +SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW fNdY6Ns= =rdCA -END PGP PUBLIC KEY BLOCK-
Re: Precisando de um sponsor.
Olá, On Sat, Apr 3, 2021 at 9:22 PM Hugo Torres wrote: > Olá Marcos. > > Eu primeiro postei aqui, e em seguida criei o Bug#986314 RFS, porque > acreditei que era necessário existir um Bug do pacote para o Sponsor poder > fechar e subir para o Debian. > Vou prestar mais atenção na próxima. > > Obrigado pelo aviso :) > > > > PGP Key ID: 0x365C8CEF4233E3D8 > Key fingerprint: 4AF1 1173 DCAD 0380 CC43 A5C6 365C 8CEF 4233 E3D8 > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > Em sábado, abril 3, 2021 7:12 PM, Marcos Talau > escreveu: > > > Olá Hugo, > > > > > On Wed, Mar 31, 2021 at 02:51:16AM +, Hugo Torres wrote: > > > > > > Ola a todos! > > > Fiz trabalho de QA em um pacote (gsimplecal) e preciso de um sponsor > que pode fazer a revisão e o upload do pacote. > > > Link do mentors: https://mentors.debian.net/package/gsimplecal/ > > > Desde já, agradeço. > > > > > Vi que você postou aqui e dois dias depois postou na mentors, e acabou > recebendo > > duas respostas, do Giovani e do Andreas. Sugiro evitar isto no futuro, > pois pode > > gerar uma duplicidade de esforços. > > > > > Abraço, > > mt > > Só uma questão que eu gostaria de saber qual a recomendação para este problema, é comum achar pacotes antigos com anonscm como VCS que gera este Lintian https://lintian.debian.org/tags/vcs-obsolete-in-debian-infrastructure.html. Seria mais adequado subir pro grupo do Debian ou a pessoa subir pro pessoal dela no Salsa? Neste caso ficaria um repositório na conta pessoal. Para o grupo do Debian vai precisar de um DD para criar o repositório. -- Cheers, Leandro Cunha Debian Contributor and developer.
Re: Deb conf 2021 website
Em qui., 31 de dez. de 2020 às 18:09, Paul Sutton escreveu: > On 31/12/2020 21:04, Leandro Cunha wrote: > > Em qui., 31 de dez. de 2020 às 17:24, Paul Sutton > > mailto:paulsut...@disroot.org>> escreveu: > > > > Hi > > > > This is probably not quite the right place to report this, but as it > is > > the developer conference, I am guessing someone will know who to > > pass it > > on to. > > > > On the page > > https://www.debconf.org/ <https://www.debconf.org/> > > > > DebConf in 2021 - under that is says > > > > DebConf20 will take place in Haifa, Israel. Please visit the > DebConf21 > > website for more information! > > > > Clicking news it still refers to 2020 > > > > https://debconf21.debconf.org/news/ > > <https://debconf21.debconf.org/news/> > > > > I am guessing this is still happening August 22-29 2021 > > > > Hope this helps > > > > Paul > > > > > > > > -- > > Paul Sutton, Cert ContSci (Open) > > https://personaljournal.ca/paulsutton/ > > <https://personaljournal.ca/paulsutton/> > > OpenPGP : 4350 91C4 C8FB 681B 23A6 7944 8EA9 1B51 E27E 3D99 > > > > https://www.linkedin.com/in/paul-sutton-5737171b8/ > > <https://www.linkedin.com/in/paul-sutton-5737171b8/> > > > > LibrePlanet 2021 - March 2021 - > > https://libreplanet.org/wiki/Main_Page > > <https://libreplanet.org/wiki/Main_Page> > > > > > > Hi, > > > > The debconf team has its own list and IRC. You can send an > > email about this to these means of contact if you want. > > > > [1] https://lists.debian.org/debconf-team > > <https://lists.debian.org/debconf-team> > > [2] irc://irc.debian.org/debconf <http://irc.debian.org/debconf> > > [3] https://debconf20.debconf.org/contact > > <https://debconf20.debconf.org/contact> > > [4] https://wiki.debian.org/DebConf <https://wiki.debian.org/DebConf> > > [5] https://wiki.debian.org/DebConf/21 < > https://wiki.debian.org/DebConf/21> > > [6] http://www.debian.org/events <http://www.debian.org/events> > > > > -- > > Cheers, > > Leandro Cunha > > Debian Contributor and developer. > > Hi Leandro > > Thanks for this, I'll look in to joining the mailing list anyway, as it > may be useful. > > Paul Sutton > > -- > Paul Sutton, Cert ContSci (Open) > https://personaljournal.ca/paulsutton/ > OpenPGP : 4350 91C4 C8FB 681B 23A6 7944 8EA9 1B51 E27E 3D99 > > https://www.linkedin.com/in/paul-sutton-5737171b8/ > > LibrePlanet 2021 - March 2021 - https://libreplanet.org/wiki/Main_Page > Hi again, Ok, I hadn't found it before and only now that I found the link to the other email lists of the debconf conference that I've even subscribed to some of them a time ago is https://lists.debian.org/debconf.html. This link is important. Site https://debconf.org Happy new year! -- Cheers, Leandro Cunha Debian Contributor and developer. -BEGIN PGP PUBLIC KEY BLOCK- mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh 0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7 ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3 k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx /m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C +DloyzlBLT
Re: Deb conf 2021 website
Em qui., 31 de dez. de 2020 às 17:24, Paul Sutton escreveu: > Hi > > This is probably not quite the right place to report this, but as it is > the developer conference, I am guessing someone will know who to pass it > on to. > > On the page > https://www.debconf.org/ > > DebConf in 2021 - under that is says > > DebConf20 will take place in Haifa, Israel. Please visit the DebConf21 > website for more information! > > Clicking news it still refers to 2020 > > https://debconf21.debconf.org/news/ > > I am guessing this is still happening August 22-29 2021 > > Hope this helps > > Paul > > > > -- > Paul Sutton, Cert ContSci (Open) > https://personaljournal.ca/paulsutton/ > OpenPGP : 4350 91C4 C8FB 681B 23A6 7944 8EA9 1B51 E27E 3D99 > > https://www.linkedin.com/in/paul-sutton-5737171b8/ > > LibrePlanet 2021 - March 2021 - https://libreplanet.org/wiki/Main_Page > Hi, The debconf team has its own list and IRC. You can send an email about this to these means of contact if you want. [1] https://lists.debian.org/debconf-team [2] irc://irc.debian.org/debconf [3] https://debconf20.debconf.org/contact [4] https://wiki.debian.org/DebConf [5] https://wiki.debian.org/DebConf/21 [6] http://www.debian.org/events -- Cheers, Leandro Cunha Debian Contributor and developer.
Re: Disabling automatic upgrades on Sid by default?
Em dom., 27 de dez. de 2020 às 03:02, M. Zhou escreveu: > Hi folks, > > I don't quite understand the meaning of automatic upgrades on a rolling > system such as Debian/Sid. According to my own experience, such > automatic upgrades could be dangerous. > > Recently package ppp is pending for upgrade but it does not co-exist > with my currently installed network-manager. Today when I was shutting > down my machine, Gnome automatically checked the "install updates ..." > box for me before I realized its existence. As a result, the system > reboots and installed ppp by force, removing network-manager and break > my system for daily use as I need network-manager for wifi-access. > > I've been a daily Sid user for at least 4 years. Automatic upgrades are > to blame for nearly all my system troubles. And I feel very > disappointed every time linux behaves like M$ windows. > > So, do we have a consensus on whether automatic upgrades should be > enabled by default? > > Hi, Although you can disable this, I usually update and do most things via the command terminal. Using testing I run apt daily. I like to know what is being updated in the system. -- Cheers, Leandro Cunha Debian Contributor and developer.
Re: Upload of package (Closes: #952788) in bug reports
Hi, Busy people usually take a long time to respond, but if don't have the initiative it doesn't help. I also sent also it to the Debian Mentors mailing list and he replied. Understanding that this is not the appropriate list for the problem in question. But I also wanted to talk about open bugs. In the description of the mailing list it mentions. Development of Debian Discussion about technical development topics. (High-volume mailing list.) This list is not moderated; posting is allowed by anyone. Thanks for listening. Em sex., 29 de mai. de 2020 às 06:06, Tomas Pospisek escreveu: > On 28.05.20 18:44, Leandro Cunha wrote: > > Close https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952788 > > With several changes in the package. > > > > Em qui., 28 de mai. de 2020 às 12:52, Leandro Cunha > > mailto:leandrocunha...@gmail.com>> escreveu: > > > > Can I help with uploading a package? I'm starting now with packaging > > and everything went well. It just needs a review and have a > maintainer. > > I think your best option is to coordinate directly with the package > maintainer, Andrej Shadura . Write to him. He's > active but maybe busy so you might want to be patient in communications > with him. > *t > >
Re: Upload of package (Closes: #952788) in bug reports
Close https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952788 With several changes in the package. Em qui., 28 de mai. de 2020 às 12:52, Leandro Cunha < leandrocunha...@gmail.com> escreveu: > Can I help with uploading a package? I'm starting now with packaging and > everything went well. It just needs a review and have a maintainer. >
Upload of package
Can I help with uploading a package? I'm starting now with packaging and everything went well. It just needs a review and have a maintainer.
