Re: Seeking consensus on file conflict between python3-proto-plus and nanopb
Hi all, On Sun, Jun 16, 2024 at 11:33 PM Yogeswaran Umasankar wrote: > Thank you all for your suggestions. Since there has been no response > from Laszlo, I will implement the recommendations from your suggestions. Thanks for your patience. I'm here just running back and forth. Going to note nanopb upstream this afternoon. Let's see what their response will be, but if you have a patch meanwhile let me know and I will forward it to them. Regards, Laszlo/GCS
Re: Seeking consensus on file conflict between python3-proto-plus and nanopb
Control: forwarded -1 https://github.com/nanopb/nanopb/issues/977 Hi, On Mon, Jun 17, 2024 at 7:28 AM László Böszörményi (GCS) wrote: > Thanks for your patience. I'm here just running back and forth. Going > to note nanopb upstream this afternoon. As promised, I reported it to upstream yesterday. Turns out it was my bad. Corrected package version will be uploaded soon. Regards, Laszlo/GCS
Re: Intent to MBF: move from fuse to fuse3
Hi, Thanks for adding me, I can't follow -devel. On Wed, Aug 21, 2024 at 11:24 PM Chris Hofstaedtler wrote: > Updated MBF text proposal: [...] > Does that sound good? This sounds right to me, except that the fuse package should be removed in the Trixie release already. It was obsoleted more than five years ago and it's time to move on. The libfuse2 package might remain, but dependent packages had enough time to migrate already. Unfortunately it is known in other distributions as well [1] that for some reason (laziness probably) projects don't migrate to fuse3. Regards, Laszlo/GCS [1] https://github.com/NixOS/nixpkgs/issues/150502#issuecomment-2017295190
Re: Intent to MBF: move from fuse to fuse3
On Sun, Aug 25, 2024 at 11:14 PM Chris Hofstaedtler wrote: > Yeah, I agree. Do you want to upload a new src:fuse package dropping > the fuse binary package? > fuse3 already Provides: fuse, so that should be fine. The question is, how many dependent packages use the binaries from the fuse package or just depend on it. Sure, fuse3 provides fuse but the names of the binaries are different. For example scripts need to update fusermount call to fusermount3 call. As such, it might be better to ping maintainers of those packages about dropping the fuse binary for testing their packages first. Then after a month actually drop it. I was informed that debian-edu and grub-mount-udeb still use fuse-udeb, but in Trixie packages I don't see that anymore. I can drop that as well in a month. How do these sound there? Cheers, Laszlo/GCS
Re: experimental codename: scud?
On Wed, Dec 17, 2003 at 11:56:30AM +0100, Toens Bueker <[EMAIL PROTECTED]> wrote: > Hamish Harvey <[EMAIL PROTECTED]> wrote: > > > I'm not on the list, just follow DWN. Just a thought, > > but naming something after a missile seems odd. > > Question is, after what the missile was named ... If I remember right, Scud is the name of Sid's dog, also broke a lot of things... /GCS
Re: How painful is a lib(fuse) .so version bump for a distribution
On Wed, Sep 25, 2024 at 9:46 PM Bernd Schubert wrote: > I would like to ask how painful is a library (libfuse) .so for a > distribution? In what sense? Upstream ABI breakages don't help, I wait for 3.17 at least if that helps - not upgrading it to middle versions. > As you can see here https://github.com/libfuse/libfuse/pull/1038 > there are some arguments not to do so. > The pull request above explains why and adds even more breakage, > when we already have chance for that. But it would be good to > know how much trouble it is for a distribution. Debian doesn't recompile dependent packages for new releases. Doing library transitions (due to new soname) is an everyday thing for us. The workflow is documented [1], I will not repeat it here. There are forty-two dependent packages that need to be rebuilt for such a case, not a big number. I'm open to schedule the transition if upstream changes the soname. Regards, Laszlo/GCS [1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions
looking for Bernd S. Brentrup
Hi, I am looking for Bernd. I have lost contact with him ages ago, I haven't seen any upload/svn commit from him since then. However his package has NMU, without any reaction from him. I hope he is fine and just has a rest, maybe retired? Anyone knows exact information? Thanks, Laszlo/GCS
[VAC] June 26-July 2
Hi, I am at Bratislava, Slovakia at the specified time. Anyone is there for a meet, keysign or anything, I am open for it. I can be reached by SMS (english or hungarian please) +36-20-4441745 Regards, Laszlo/GCS signature.asc Description: This is a digitally signed message part
[VAC] June 26-July 2
Hi, I am at Bratislava, Slovakia at the specified time. Anyone is there for a meet, keysign or anything, I am open for it. I can be reached by SMS (english or hungarian please) +36-20-4441745 Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using FreeDesktop MIME entries directly in mime-support (Re: Fixing the mime horror ini Debian).
Hi Cyril, On Mon, 2012-07-16 at 22:49 +0200, Cyril Brulebois wrote: > Charles Plessy (16/07/2012): > > If nobody else volunteers, I propose to start a maintenance group for > > the mime-support package, that I would store in a Git repository on > > Alioth's collab-maint group. Just for the record, Charles has an advanced knowledge regarding MIME in general. Hope we can work together. > I think that's a perfect use case for collab-maint. > László, do you really need a dedicated group for that? My intention was to limit people who can commit to mime-support. It seems there are multiple viewpoints for example about application/x-httpd-* types. One may do more harm with a commit if not consulted by a group of more advanced people. But I'm fine with normal collab-maint as well if you and Charles would like that. Cheers, Laszlo/GCS signature.asc Description: This is a digitally signed message part
Re: Using FreeDesktop MIME entries directly in mime-support (Re: Fixing the mime horror ini Debian).
On Mon, 2012-07-16 at 23:35 +0200, Cyril Brulebois wrote: > Laszlo Boszormenyi (GCS) (16/07/2012): > > My intention was to limit people who can commit to mime-support. It > > seems there are multiple viewpoints for example about > > application/x-httpd-* types. One may do more harm with a commit if not > > consulted by a group of more advanced people. But I'm fine with normal > > collab-maint as well if you and Charles would like that. > > As someone processing alioth-related requests, I would find it nice to > use collab-maint for such projects; but I'm willing to hear about > arguments against that. > > As a random developer, I would really hate to see people fight through > commits. In case that would happen, I think that can be fixed, IIRC > collab-maint has some abuse clauses or something similar. > > (IOW: I'm not convinced you need a dedicated group; quite the contrary.) I already wrote my reason and that a normal collab-maint place is fine with me. So I just need to login to git.debian.org and create a repository under /git/collab-maint/ right? Charles, I would add myself as Maintainer and you as an uploader or the vica-versa whichever suits you better. Is this OK with you? Regards, Laszlo/GCS signature.asc Description: This is a digitally signed message part
Re: Collaborative maintenance of mime-support (was Re: Using FreeDesktop MIME entries directly in mime-support).
On Tue, 2012-07-17 at 09:27 +0900, Charles Plessy wrote: > how about the following (inspired by http://dep.debian.net/deps/dep2/) > > Maintainer: mime-supp...@packages.debian.org > Uploaders: > Laszlo Boszormenyi (GCS) , > Charles Plessy , Hope Brian will also join. May we add you? > I propose the following action plan. > > 0) We subscribe to the PTS (done for me). For me as well, I assume Brian is also subscribed. > 1) Upload to experimental an adopted package with the updated maintainer and >uploaders list, the VCS fields updated, and the patch for #497779 applied. +1 > 2) Install in Alioth's collab-maint a git repository made with the --debsnap >option of git-import-dscs, unless we try to go deeper in time ? Set up >commits emails to go to the PTS. I've created an empty git collab-maint repository on Alioth, still not visible over the web interface. As I know, it just need some time. Made the config to send commits to the PTS. So, how deep should be the package import? The full history from snapshot.debian.org or just the last upload is enough? We will have the file history, but not the comment why happened and what. > 3) Make crystal clear in the source package's READMEs that uncoordinated >commits are an abuse of the collab-maint Alioth group. But perhaps >we can allow developers to create topic branches related to bugs in the BTS >if they like ? +1 , but I assume you know that others may create free and public git trees elsewhere, for example on GitHub. They may send a merge request when their work is done. The tree is still visible, separated and can be merged if needed. > 4) Postpone any other change on the main branch until either #681687 (tech. >comittee) is solved or Wheezy released. +1 > Lastly, I would like to thank Brian for his impressively 16-years long work on > mime-support. Brian, feel free to stay among the uploaders ! I join as well. Thanks Brian for your previous work! Hope you will be still close to the package and the recent events don't turn you down. Regards, Laszlo/GCS -- 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/1342503504.8460.88.camel@julia
Re: Collaborative maintenance of mime-support (was Re: Using FreeDesktop MIME entries directly in mime-support).
Answering to my own mail. On Tue, 2012-07-17 at 05:38 +, Laszlo Boszormenyi (GCS) wrote: > On Tue, 2012-07-17 at 09:27 +0900, Charles Plessy wrote: > > 2) Install in Alioth's collab-maint a git repository made with the --debsnap > >option of git-import-dscs, unless we try to go deeper in time ? Set up > >commits emails to go to the PTS. > I've created an empty git collab-maint repository on Alioth, still not > visible over the web interface. As I know, it just need some time. It is now visible: http://anonscm.debian.org/gitweb/?p=collab-maint/mime-support.git;a=summary Empty at the moment. I used git-debimport , the result is at GitHub for review: https://github.com/gcsideal/mime-support If it's OK, I'll rebase to git.debian.org . Regards, Laszlo/GCS signature.asc Description: This is a digitally signed message part
