Re: The problem with security newsletters and newsletters on the security center
Hi, On 08/05/2024 08:53, Тимур Казбеков wrote: Hi! We noticed that you have discrepancies in the mailing list and the information provided on https://security-tracker.debian.org/tracker/ Example: DSA-5248-1 link to the message https://www.debian.org/security/2022/dsa-5248?ref=cve.news redirect to DSA 5246-1, but there is https://security-tracker.debian.org/tracker/DSA-5248-1 on the tracker, and unfortunately it is not clear why it overwrites the DSA 5246-1 in the mailing list, although they are completely different. Here is a list of newsletters where there is a discrepancy between the tracker and the newsletter: DSA-5248-1 php-twig -- security update DSA-4986-1 tomcat9 -- security update DSA-4727-1 tomcat9 -- security update DSA-4342-1 chromium-browser -- security update DSA-3941-1 iortcw -- security update DSA-3931-1 ruby-rack-cors -- security update DSA-3768-1 openjpeg2 -- security update DSA-3529-1 redmine -- security update DSA-3525-1 pixman -- security update DSA-3383-1 wordpress -- security update DSA-3265-1 zendframework -- security update DSA-3249-1 jqueryui -- security update DLA-3177-1 python-django -- LTS security update DLA-2941-1 linux-4.19 -- LTS security update DLA-2887-1 lighttpd -- LTS security update DLA-2785-1 linux-4.19 -- LTS security update DLA-2714-1 linux-4.19 -- LTS security update DLA-2690-1 linux-4.19 -- LTS security update DLA-2652-1 unbound1.9 -- LTS security update DLA-2610-1 linux-4.19 -- LTS security update DLA-2594-1 tomcat8 -- LTS security update DLA-2557-1 linux-4.19 -- LTS security update DLA-2556-1 unbound1.9 -- LTS security update DLA-2483-1 linux-4.19 -- LTS security update DLA-2417-1 linux-4.19 -- LTS security update DLA-2385-1 linux-4.19 -- LTS security update DLA-2323-1 linux-4.19 -- LTS new package DLA-2066-1 gthumb -- LTS security update DLA-1709-1 waagent -- LTS security update DLA-1543-1 gnulib -- LTS security update DLA-1541-1 jekyll -- LTS security update DLA-1540-1 net-snmp -- LTS security update DLA-1539-1 samba -- LTS security update DLA-1538-1 tinc -- LTS security update DLA-1537-1 php-horde-kronolith -- LTS security update DLA-1536-1 php-horde-core -- LTS security update DLA-1535-1 php-horde -- LTS security update DLA-1533-1 git -- LTS security update Could you tell us or improve the experience of using newsletters? This looks like a bug in the website redirections. I'm cc'ing debian-www. Cheers, Emilio
Re: Bits from the DPL -- April-May 2016
On 20/05/16 20:55, Mehdi Dogguy wrote: > Hi Emilio, > > On 20/05/2016 20:11, Emilio Pozuelo Monfort wrote: >> Hi Mehdi, >> >> First of all, congrats for the election! >> > > Thanks! > >> On 17/05/16 18:57, Mehdi Dogguy wrote: >>> Assets >>> == >>> - Approved expenses for MiniDebConf at Vienna, Austria. (Up to 3000€) >> >> Out of curiosity, what was this used/intended for? I couldn't find a mail on >> debian-sprints explaining the request, but since it was a minidebconf and not >> a sprint maybe it was handled differently. >> > > It was requested directly to the DPL on 14/03/2016 and approved by Neil > for a budget up to 3000€. In the above cited line from my bits, I should > have used "budget" instead of "expenses". Initially, the budget was > requested to cover location's cost, travel sponsoring and video equipment > transport. Later, HPE accepted to sponsor the event and organizers asked > me to confirm again that it is okay to keep the approved budget to secure > the event, and use that for travel sponsoring only. > > I haven't heard back from organizers yet. So I cannot tell how the budget > has been used exactly though. HPE's sponsoring might have covered the > costs entirely. > > Hope this answers your question. Absolutely! Thanks. Cheers, Emilio
Re: Bits from the DPL -- April-May 2016
Hi Mehdi, First of all, congrats for the election! On 17/05/16 18:57, Mehdi Dogguy wrote: > Assets > == > - Approved expenses for MiniDebConf at Vienna, Austria. (Up to 3000€) Out of curiosity, what was this used/intended for? I couldn't find a mail on debian-sprints explaining the request, but since it was a minidebconf and not a sprint maybe it was handled differently. Cheers, Emilio
Re: Reverting to GNOME for jessie's default desktop
On 08/08/14 00:29, Don Armstrong wrote: On Thu, 07 Aug 2014, Jordi Mallach wrote: Well, it's roughly that time. :) So I'd like to plainly request GNOME is reinstated as the default desktop environment for a number of reasons. One of the reasons put forward for switching to Xfce was size on the installation images; could you (and/or debian-cd) address this? Specifically: 1) Would you want the default CD/DVD image to use a GNOME even if GNOME was unable to fit on a single image? I think the first CD/DVD should have whatever we choose as the default. 2) Would the GNOME team consider a less-complete DE for cases where image size is a restriction? Yes. If there wasn't enough space, we could drop some not very important modules (e.g. a few games), try a stronger compression ratio, symlink /usr/share/doc directories... We'd need some numbers here but we could work something out. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e49467.5010...@debian.org
Re: Reminder: Debian FTPMaster meeting
On 17/03/11 08:52, Joerg Jaspert wrote: I saw you included most points raised but nothing about XZ support (even though it's a relatively small item in term of work compared to the rest). I had raised it here: http://lists.debian.org/debian-devel/2011/02/msg00072.html Did you miss it or was this a deliberate omission? Missed. Put into medium now. I guess this includes support for orig files, not only .debs? GNOME is going to start shipping tar.xz compressed tarballs very soon[1][2], instead of .tar.gz + .tar.bz2, so I'd like to do the same in Debian to avoid having to repack. Cheers, Emilio [1] http://mail.gnome.org/archives/desktop-devel-list/2011-March/msg00075.html [2] http://mail.gnome.org/archives/desktop-devel-list/2011-March/msg2.html -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d84960d.3020...@debian.org
Re: Using project resources for blends and non-free
Giacomo A. Catenazzi wrote: Ev. some queue priority and allowing to suspend queues will be useful (but I think these are already implemented): we don't want a openoffice backport during a transition. Marc said the builds would happen on non Debian buildds, so this shouldn't be a problem AFAIUI (i.e. the buildds workload won't be increased because of this). Cheers, Emilio -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Closed lists as maintainers
Ben Hutchings wrote: I hope we can agree that maintainers should be able to receive mail from any legitimate sender. However, some maintainer addresses point to mailing lists that automatically reject mail from non-subscribers (without the intervention of a moderator). The case I am painfully aware of is grub-de...@lists.alioth.debian.org, listed as the maintainer for grub and grub2. I believe this configuration is unacceptable, but would like to check that there is a consensus on this before pressing the matter with the GRUB maintainers. I agree. Emilio -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian redesign
Ana Guerrero wrote: Hi, Agnieszka Czajkowska has presented this morning at DebConf a very nice redesign proposal off the Debian logo and the Debian website. She has been working on this all the last year as part of her master thesis in Design. You can take a look at her presentation at: https://penta.debconf.org/dc9_schedule/attachments/112_debian_redesign.tar.gz Watch first the deb_redesign-talk*.jpg images then debian_illustration*.jpg What do you think? :D I'd be happy to see wallpapers/screensavers/gdm artwork to include it in our packages. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Debian redesign
Klistvud wrote: In my view, Debian is far less about image and far more about substance than any competing product (or any product in general, for that matter). Not that I don't agree with that, but it doesn't mean we shouldn't care about our image at all. We can improve the distribution and it's image at the same time, can't we? Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Debian decides to adopt time-based release freezes
Didier 'OdyX' Raboud wrote: + Security fixes prepared for Ubuntu will be (sometimes ?) applicable directly to Debian, which would be a reduction in workload for the Debian Security team. (Or phrased differently: Debian and Ubuntu security teams will be able to prepare security fixes together, for the same frozen versions.) I doubt the Release Team will accept a new GNOME, KDE, X, and Kernel after the freeze in December, in which case Debian and Ubuntu LTS won't have the same major components, since e.g. in the case of GNOME, we would ship the GNOME released in September, and Ubuntu would ship the one released in March. So unless we freezed way later, this wouldn't be true AFAICS. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Debian redesign
Martín Ferrari wrote: You're not talking about sexism, objetification or anything but things that are common to almost everybody in this planet. So what? signature.asc Description: OpenPGP digital signature
Re: so ... let's merge DAM and FD?
Steve Langasek wrote: On Thu, Jul 02, 2009 at 07:11:08PM +0200, Emilio Pozuelo Monfort wrote: No, what is bureaucratic is having to wait one month for FD to review one application, just to say `hey it's complete`, and pass it to the DAM. Then wait another month. I don't see the point in it being reviewed twice if FD has no say in the final decision and his only task is to check that everything is complete. In practice this should only be a problem if the FD check is causing DAM queue starvation. But then, if the DAM gets ahead of FD, there's no reason they couldn't step in and pull directly from the FD queue, right? The converse, giving FD the same powers of DAM, is an expansion of the powers of the FD members which I don't see justification for. If the DAM thought the FD members were ready to be DAM, they could just as well propose themselves that they should be added as DAM. I definitely *don't* agree that there's justification for automatically merging the FD into DAM. OK, you have a point. However, as long as one of the teams (e.g. FD) stops duplicating the same task, and the other one is added more members, the result should be the same. Of course it may not be that easy to find new victims for the position... Emilio P.S.: not saying the FD or DAM are doing a bad job, it's just that duplicating the same task seems like a wasted effort to my eyes signature.asc Description: OpenPGP digital signature
Re: so ... let's merge DAM and FD?
Richard Hecker wrote: While consensus might exist that eliminating bureaucracy is good, division of labor can be a good thing too. I do not think you have established the need to combine the FD and DAM tasks. Are you claiming the DAMs are too bureaucratic? No, what is bureaucratic is having to wait one month for FD to review one application, just to say `hey it's complete`, and pass it to the DAM. Then wait another month. I don't see the point in it being reviewed twice if FD has no say in the final decision and his only task is to check that everything is complete. Of course we could keep the status quo, but it seems to me merging DAM and FD would do no harm and a lot of benefit (or if you want it another way, removing the step of FD checking the application after the AM report, and adding more people to the DAM). Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: so ... let's merge DAM and FD?
Richard Hecker wrote: Emilio Pozuelo Monfort wrote: No, what is bureaucratic is having to wait one month for FD to review one application, just to say `hey it's complete`, and pass it to the DAM. Then wait another month. I don't see the point in it being reviewed twice if FD has no say in the final decision and his only task is to check that everything is complete. In this community, do you really want to suggest we have too many eyes looking for problems? Do you want to re-review all the GNOME packages before we upload them to the archive? Do you want to re-review the packages that go through the NEW queue after the ftpmasters approve them? Then why do you want two teams looking at new applicants? Emilio signature.asc Description: OpenPGP digital signature
Re: DAM and NEW queues processing
Stefano Zacchiroli wrote: On Thu, Jun 25, 2009 at 01:32:14AM +0200, Bernd Zeimetz wrote: Would it be enough to just have a special automated mail congratulating new developers on -newmaint (or modify the subject of this mail to congratulate them?) I'd be happy to modify the cronjob to send such mails to -project, if the interest is large enough. Does anybody want to come up with a proper wording? My 0.02€: « The Debian project is happy to announce that the following applicants, from the New Maintainer queue, have just become official Debian Developers: - foo - bar I'd include their short biography (a few lines) that is sent to -newmaint. +1 for the idea. Emilio signature.asc Description: OpenPGP digital signature
Re: DAM and NEW queues processing
Wouter Verhelst wrote: On Thu, Jun 25, 2009 at 11:15:35AM +0200, Emilio Pozuelo Monfort wrote: I'd include their short biography (a few lines) that is sent to -newmaint. The whole point of this exercise is that the short biography cannot be automated, so it takes too much time from FD to compose such mails... Let's make it automated then? Just put a box in https://nm.debian.org/newnm.php asking for a short biography (you can even put a word count limit) and saying that it will be published in public mailing lists. Then just hope that people introduce nice bios :) But in the meantime I'm all in favour of saying who have become new DDs. Emilio signature.asc Description: OpenPGP digital signature
Re: DAM queues processing
Hi all, This is how I see the process right now, from the applicant's POV: - Applicant applies - DD advocates (wait1) - AM assigned - Work with the AM (PP, TS and whatever is needed) - AM sends report (wait2) - FD checks the application (wait3) - DAM reviews the application (wait4) - DAM creates the account - Key added to the keyring - Shell access to developer machines This is in the case the applicant is accepted everywhere and becomes a DD, of course. So as I see it, wait[1234] are the bigger waiting periods, and reducing them won't decrease the NM process quality (as some people complained if the number of questions was reduced). - Reducing wait1 is complicated. Some possibilities for accelerating this are: + Recruiting more AMs + Reducing the time an AM spends with the applicant. Many people dislike this if it means less questions, so probably not a good idea. + Requiring applicants to apply late rather than soon... - wait2/3 could be merged by removing the duplicate work of both FD and DAM reviewing applications. Only one body should do it (e.g. DAM, and if wanted FD members joining it). That will remove wait2, and if more people joins DAM, reduce wait3. - I don't know why there is wait4. I guess it's because DAM members process people in batches, but IMHO if you have already reviewed an application and accepted it, the account should be immediately created? Is there a (good) reason for this delay? - I have no idea whether the keyring and machine access stuff take another big delay. What do people think? Best regards, Emilio signature.asc Description: OpenPGP digital signature
Re: DAM queues processing
Bernd Zeimetz wrote: Stefano Zacchiroli wrote: I'd be perfectly fine with FD being the last review step, and DAM just in charge of creating the account, trusting FD judgement. What would we be missing that way? What you miss is that I move all problematic candidates to DAM with the comment I'm not entirely happy, but its your job to decide... Also it is good to have more than one person read the mboxes, sometimes you just miss important points/words because you're braindead after reading too many mails. If the FD doesn't have the power to decide whether to accept somebody or not, what is the point of it reviewing candidacies, specially if later the DAM will review it anyway? From an NM point of view, my feeling is: I hope the Keyring Maintainers and the DSA don't feel like reviewing everything *again* to add my key to the keyring and to give me access to the developer machines If there was just one body that reviewed that everything was OK, and then created all the required stuff, things would be so much smooth. And if you want more eyes, well, there already was the AM, but if more are needed, they could be another FD member. No need for 5 different teams IMHO. I hope that explains, Emilio signature.asc Description: OpenPGP digital signature
Re: DAM queues processing
Lucas Nussbaum wrote: On 23/06/09 at 15:30 +0200, Stefano Zacchiroli wrote: On Tue, Jun 23, 2009 at 02:55:42PM +0200, Peter Palfrader wrote: OK, then what I'm proposing is to identify one single entity where the decision is taken. Either is FD or is DAM. It's DAM. DAM has always been the position that decides who is a DD and who isn't. The whole FD/NM thing is just an advisory board to the DAM if you want to call it that. Then drop FD, it looks like it is just a waste of time, given that in the problematic cases the dossier is just handed over to DAM for a new full review. But as things stand nowadays, I wouldn't be happy with that outcome, given that DAM is more understaffed than FD (2 people vs 4), with Joerg also involved in another time-consuming role (ftpmaster). Hence I would more welcome one of the following alternative outcomes: 1) drop FD *and* integrate the current FD people into DAM; it looks like accepting new members is the main part of DAM activities anyhow, so why bother with an extra advisory board? 2) change the It's DAM fact above, from now on it will be FD How do people feel about that? I like the idea a lot. /me too, either of them. Hopefully that would solve the current bottleneck. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Who uses @packages.d.o mail?
Don Armstrong escribió: I think adding the lists.debian.org and bugs.debian.org ruleset[1] to packages.debian.org (possibly with some tweaks) will help resolve the issue with spam flowing through packages.debian.org. Yes, please. We're drowning on spam! Thanks, Emilio signature.asc Description: OpenPGP digital signature
Re: debian forum
Henrik Frid wrote: Hi! Although the forum is down, is it possible to access the forum threads? There is lots of valuable info on the forum. it would be great if the threads could be uploaded somewhere, perhaps on a already working p2p network like the pirate bay. There is Google, searching for site:forums.debian.net gives around 60k results here. signature.asc Description: OpenPGP digital signature
