Look for keysign
Hi all, OK, don't beat me up too bad, even though I deserve it. I've been away a LONG time and did not retire properly nor update my key and my old key has been removed from the keyring (as it should have been). I'm hoping to get back involved so I'm wondering if any of you old timers that I used to work with might be willing to sign my new key and/or would be looking for possible keysigning in Philadelphia, PA area or maybe even New Haven, CT area. Thanks for any guidance/help! Barry deFreese signature.asc Description: This is a digitally signed message part
Re: Look for keysign
On Thu, 2024-07-18 at 09:38 +0200, Matthias Urlichs wrote: > On 14.07.24 02:28, Barry deFreese wrote: > > OK, don't beat me up too bad, even though I deserve it. I've been > > away > > a LONG time and did not retire properly nor update my key and my > > old > > key has been removed from the keyring (as it should have been). > > Do you still have the secret of your old key? If so you can update > the > key so it's no longer expired, and sign the new key with the old one. > Then email the old key's signers and ask them to please consider > signing > the new key. > > This process worked for me when I had to replace mine. > > -- > -- regards > -- > -- Matthias Urlichs > Hi Matthias, I do and I have signed my new key with the old but many of the people that signed my key aren't really active in Debian these days and P2 was one of them also. Thanks for the idea though, I may try to poke some of them. Barry deFreese
Re: libc6 2.5 and Etch
- Original Message - From: "Michael Banck" <[EMAIL PROTECTED]> To: Cc: Sent: Thursday, October 26, 2006 11:45 AM Subject: Re: libc6 2.5 and Etch On Wed, Oct 25, 2006 at 01:27:07PM +0200, Aurelien Jarno wrote: We plan to upload [glibc-2.5] right after the release of etch. This version works on all architectures, but m68k, hurd and hppa which don't have TLS support. For hppa the work is almost done, I am currently building the packages (but on a slow machine) to test them. For m68k and hurd, I have sent a mail to the porters a few months ago, I haven't received any answer. Maybe we should have to drop those architectures, at least temporarily. Speaking for the Hurd porters, we know that this needs to be done, but so far nobody either had enough time or enough skill to do the necessary work for it. Michael I have looked at it pretty in-depth. Unfortunately as most of you know it is way outside of my skillset. :-( - "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." Rich Cook. Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unknown-field-in-control homepage
Jonas Meurer wrote: Hello, I'm not sure whether this is an issue with dpkg or rather with lintian, but if I check the cryptsetup deb+udeb packages after building them, lintian reports that udebs don't allow the Homepage field in debian/control. If I got it right, the Homepage field belongs to the Source section of debian/control, so I see no way to keep it out of the udeb. Here's the exact lintian message: $ lintian -i -I cryptsetup_1.0.6~pre1+svn45-2_amd64.changes I: cryptsetup-udeb udeb: unknown-field-in-control homepage N: N: See the Policy Manual for a list of the possible fields in a binary N: package control file. N: N: In udeb packages the fields pre-depends, conflicts, essential and N: suggests are disallowed, but they can contain the new fields N: subarchitecture and installer-menu-item. N: N: Refer to Policy Manual, section 5.3 for details. N: what shall I do about that? greetings, jonas What version of lintian do you have? That should be fixed by now. Thanks, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Newest fad of Mass bug closings
[EMAIL PROTECTED] wrote: The newest fad in Mass bug closings is: All bugs against package "nurd5" have been automatically closed without further review, as "nurd5" has been removed from Debian. OK, fair enough, until one checks deeper and finds: "nurd5" has been removed from Debian because: it has been replaced by "nurd6"! Where possible they are being reviewed. Of course it's possible that I am missing some but say in the case of exim, I specifically asked the exim4 folks about them. Aside from exim and a couple of other widely used packages (notice I haven't closed the bind ones yet), the majority of them have been removed since 2005 or better and were closed for "obsolete or unmaintained". Also, would it not be the maintainers responsibility to re-assign a bug from nurd5 to nurd6 if it was still there or no? If I have done something wrong, please feel free to notify me and let me know but I don't think it helps us any to just say "here we go again". Thanks, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: extensive patching
Martin Uecker wrote: [EMAIL PROTECTED] wrote: I disagree. The cause of the disaster was not that Debian does its own patching, but the fact that that patch was buggy. Buggy patches happen all the time. The question is, how could something as bad as this slip through? And one important reason is IMHO, that splitting up the development/bug fixing/review by creating different software branches is bad. Different software branches in what respect? Just by nature of having a distro "package" ? On the whole I think that Debian benefits a lot from custom patches, and in fact many packages would be severely buggy and/or wouldn't integrate properly with the rest of the system without them. > It's not a secret that many projects benefit from Debian patches, so there might be something good with them. Clearly, Debian adds value by its patches. If those patches would be integrated upstream, then the whole free software community would benefit. Which brings up at least two issues. Upstream not wanting the patches or dead upstream. Speaking from the games team alone I would bet that 50% or more of the packages have no upstream anymore. Should those packages be removed? Also, obviously, there are changes that make no sense to upstream that are strictly distro specific. Also, I don't think we should always wait for upstream's new releases for adding them if we have them available. It might depend on every case. I would prefer if only security fixes and bugs which might cause data loss would fixed directly in Debian. Everything else should go upstream first. Sounds good but again, what about unresponsive/dead upstreams. Do you leave your users to "suffer" ? Is Debian here to service the user community or not? Maybe there's a problem with the fact that some of those patches are just reviewed by just one person, but then again, I seriously think that it would have been quite difficult to discover that there was a problem with this one. The proof that it wasn't evident is not only that upstream didn't see the problem either, nor any other developer or derivative distribution or independent reviewers in 2 years. Did you look at the code? This was not exactly a deeply hidden flaw in some obscure looking code. Upstream didn't see the patch. That's exactly the problem. And I doubt that there was any review of this code in all this 2 years. I have seen links where "upstream" was asked about/notified of the patch so this isn't an entirely true statement. Egos play a big part in all of this as well. Of course, the development and checking of the patches should be done as cooperatively with upstream as possible, as upstream might see something we're not seeing, but the way to the solution, in my opinion, is not to avoid patching but to develop a way to check them as extensively as possible. Checking something extensively is much easier if there is one canonical branch which everybody agrees on. Sounds like Utopia but I can't see it happening. Regards, Martin Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still using libgnomeprint
Josselin Mouette wrote: Hi all, libgnomeprint/libgnomeprintui is going to be soon deprecated upstream. The GtkPrint replacement (built in GTK+ itself) has been available for 3 years. I’d like to remove it before the squeeze release. This can only be done by getting rid of as much as possible of the reverse dependencies. When this is done, we’ll see how it is feasible. Note that some of these packages already include GtkPrint support, but you have to select it at compile time. Otherwise, please consider porting to the much more modern Cairo/GtkPrint API. As for bindings, they don’t have any reverse dependencies except for the Python ones, so I think we’d be better off removing them ASAP. If you are fine with it, I’ll do a MBF. Cheers, Joss, I was getting ready to file all of these so a +1 from me. Thanks, Barry deFreese -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Is it time to remove sun-java6?
Hi folks, A few of us have been discussing the removal of sun-java6. It is non-free, orphaned, buggy (including security bugs), and can generally be replaced by openjdk. There are only three reverse depends left and none of them directly depend on sun-java6 but instead dep on java6-runtime. There has also been some similar discussions in Ubuntu with some users reporting that some web sites and packages don't work with openjdk but I have not seen a lot of concrete proof. My personal feeling is that we either need to remove it or fix it up. Any thoughts? Thanks, Barry deFreese -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is it time to remove sun-java6?
Stefano Zacchiroli wrote: On Thu, Oct 08, 2009 at 11:44:21AM -0400, Barry deFreese wrote: There has also been some similar discussions in Ubuntu with some users reporting that some web sites and packages don't work with openjdk but I have not seen a lot of concrete proof. I might look a naive user here, but with openjdk I still don't have plugin support in firefox 3.5, whereas it was working with sun-java*. I'm on amd64 and using icedtea6-plugin, even the most simple examples of http://java.sun.com/products/plugin/1.5.0/demos/applets.html do not appear to work. I know I should have filled the bug report first, but I frankly discovered only now that the equivalent of old sun-java6-plugin metapackage is icedtea and that's bring me to another subject: users should be informed on how to migrate away from sun java6 (even because it would be a de facto switch from non-free software to free software, even if it is the same). Do we currently have a smooth migration path from the old set of packages to the new set in place for Lenny to Squeeze migrations? Before that is in place, I'd consider premature removing sun-java*. Cheers. Stefano, Well that brings up part of my question. I doubt we have a smooth migration since sun-java6 doesn't even have a maintainer. Even Sun is End Of Lifing sun-java6 soonish ( at least the potential is there that it could get EOL'd during Squeezes lifecycle). Not to mention it currently has 34 open security issues (granted, I have not verified all of the ones showing up on PTS). Hell I'd even try to help maintain it from a QA perspective but I am not a Java person. Nor could I even attempt to help fix openjdk/icedtea but at some point these issues have to get resolved, don't they? The potential is that we either have a broken sun-java package or none. I realize that the current package apparently works but the potential is there for it to break and no one to fix it. Thanks, Barry deFreese -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is it time to remove sun-java6?
Alexander Reichle-Schmehl wrote: Hi! Stefano Zacchiroli schrieb: There has also been some similar discussions in Ubuntu with some users reporting that some web sites and packages don't work with openjdk but I have not seen a lot of concrete proof. I might look a naive user here, but with openjdk I still don't have plugin support in firefox 3.5, whereas it was working with sun-java*. I'm on amd64 and using icedtea6-plugin, even the most simple examples of http://java.sun.com/products/plugin/1.5.0/demos/applets.html do not appear to work. Interesting. I just tested all the examples on that page using iceweasel 3.0.14 on amd64.. All worked (Granted; at one point I turned if sound and I didn't checked every tiny bit in the "SwingSet2 Applet"). Best regards, Alexander Well I suppose one way to resolve this would be to file RC bugs on the 34 outstanding security issues? :) OK, I guess it stays but it would be nice to get it fixed up. Thanks for all the input. Barry deFreese -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Removal of *roxen*
Hi again, I was working through some RC bugs recently and came across 3 roxen packages. They have recently been orphaned and roxen4 seems to possibly have some non-free jar files in it. I am planning on just removing them (at least roxen4, libroxen-ecms, and libroxen-form initially) since they have bugs and a very low popcon. Does anyone have any objections before I remove them? Thank you, Barry deFreese Debian QA -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Lucas Nussbaum wrote: > On 27/10/09 at 14:57 +, Simon McVittie wrote: > Also, lots of packages currently in our archive already have those > errors. What do you plan to do with those? If you auto-reject packages > that introduce those errors, it would be logical to file RC bugs and/or > remove them from the archive. I like that plan! Barry deFreese -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: SoundJuicer Package Adoption
Andreas Marschke wrote: > Hi, > > I've recently seen that there are problems with SoundJuicer and open for > adoption maybe. I think its a usefull tool for a fast rip of a cd. > I would like to know if there is a way to adopt the package if necessary and > if you can point me to a wiki page that has a correct way to adopt a package > such as soundjuicer. > > Sincerely, > > Andreas Marschke. > > Andreas, Where did you see that it was up for adoption? It's not listed as Orphaned or RFA'd? In fact it just had an upload on 10/31. Thanks, Barry deFreese -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
libsdl1.2-1.2.14 in Experimental, could use some testers if possible
Hi folks, I just uploaded libsdl1.2-1.2.14 to experimental. I would appreciate any testing folks could do on it as soo many packages depend on it. I had to remove a lot of existing patches as they are applied upstream or the code was re-factored enough as to not warrant them anymore. I would especially appreciate some feedback from any kfreeBSD folks as I re-applied the patch for the joystick stuff but had to re-factor it a little. Thanks! Barry deFreese -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Unidentified subject!
Pierre Habouzit wrote: Hi m68k and Hurd porters, You were previously made aware[0] that glibc-2.6 needs TLS to be implemented for your ports to build and work properly, sadly this is still not the case for m68k, and insufficient for Hurd in the current state. We want to release lenny with glibc 2.6 (see discussion with the Release Team in [1]), and it has been released upstream yesterday. We don't plan an upload to unstable immediately, we already have to make glibc 2.5 reach lenny first. Though, we hope to make the first uploads during DebConf. Bringing a new glibc upstream into Debian is a lot of work, and waiting for m68k and Hurd to support TLS properly is sadly not an option we can consider. [0] http://www.mail-archive.com/debian-glibc%40lists.debian.org/msg31594.html [1] http://lists.debian.org/debian-release/2007/04/msg00161.html On behalf of the Glibc Packaging Team, Hi Pierre, I got 2.5 to build with TLS but we need some changes to Hurd and gnumach to handle it. As I understand it we have even more issues with 2.6. Of course I'm certainly not the expert on the issue.. Thanks, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do with new upstream releases before Lenny is out ?
Charles Plessy wrote: In the next 1~2 monthes that separate us from the release, there will be new upstream releases for the packages I maintain and I am undecided what to do: - Ignore them and dedicate only to Lenny. - Package them only if requested by users. - Upload them to experimental. - Upload them to unstable. For the moment I did one upload to experimental, but I am not convinced by my own choice. If somebody has wise comments, I will be grateful to listen them. Have a nice day, Just help get ctsim to build with wx2.8 so we can drop 2.4. ;-) Thanks, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Josselin Mouette wrote: Debian Games Team <[EMAIL PROTECTED]> lmemory => gcompris ? I'll take a look at this one. Debian QA Group <[EMAIL PROTECTED]> gnome-libs gtkfontsel gtkglarea imlib netdude sqlrelay stegdetect => QA-maintained packages should be removed as soon as they don’t have remaining rdeps I will look at this as well since I'm on an RM:/proposed RM kick. I assume this is more of a Lenny+1 goal? Thanks, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Barry deFreese wrote: OK, I have looked at several of these and man what a mess. Debian QA Group <[EMAIL PROTECTED]> gnome-libs Orphaned but obviously tons of r(b)depends. gtkfontsel Orphaned but a fairly significant popcon. I can't find new upstream source. Could probably be ported or RM:d. gtkglarea Orphaned and I can't find any upstream source yet but again lots of r(b)depends. imlib Orphaned and LOTS of r(b)depends. netdude ITA'd. There is a new upstream available. I've pinged the ITAer to see if the new upstream is GTK 2.0. sqlrelay Some of the binaries have decent popcons. We could probably either port sqlrelay-config-gtk or just remove that binary for now. stegdetect RM: filed. Is this really feasible? How many people are going to work on dead packages? Or if we RM: the lot of them, how many users are we pissing off? Thanks, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Raphael Geissert wrote: Barry deFreese wrote: [...] stegdetect RM: filed. Why isn't just the xsetg package dropped? stegdetect is a CLI app; only xsteg uses GTK+ Cheers, /me who has stegdetect installed and keeps it around to time by time try to find something that just isn't there Feel free to adopt it then. :) Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Morten Kjeldgaard wrote: For whom is the Debian distribution? Is it created to satisfy the needs of only the packagers and developers? If so, it is absolutely logical to get rid of everything a couple of years past expiry date. So I am not advocating keeping every bit of software around. In this discussion, I am advocating keeping GTK+ 1.2 around. The LIBRARIES. I am not opposed to weeding out out-dated applications that make use of it, if reasonable replacements are available. But Libraries represent a resource for _others_ than packagers and developers. Cheers, Morten Morten, I understand where you are coming from but it also becomes an issue of resources. We already have a buttload of orphaned and/or QA maintained packages. If we keep every version of every library out there how do we support it? Look at libnet0. It's orphaned but has several depends while libnet1 exists. Who's taking care of those users? Should we keep every version of glibc in the archive? How about all the gnome1 stuff? BTW, I don't care if GTK+ 1.2 stays or goes but I do care about unmaintained stuff hanging around. Just my worthless $.02 :) Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Michael Banck wrote: On Sat, Dec 06, 2008 at 09:20:31AM -0500, Barry deFreese wrote: Morten Kjeldgaard wrote: So I am not advocating keeping every bit of software around. If we keep every version of every library out there how do we support it? Morten did not say that. Michael Obviously I was exaggerating purposely. Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Morten Kjeldgaard wrote: On 06/12/2008, at 15.47, Barry deFreese wrote: Obviously I was exaggerating purposely. Yes, but, you know, exaggerating the position of others in a forum like this is not really constructive. In fact, it signals that you've run out of arguments. Give me a break. I raised a -- I think -- valid concern that certain libraries can't just be removed just because they're "old" or not used anymore by most Debian apps, because they may still be useful to people who are not Debian Developers or package maintainers. The only argument I've read from various contributors to the thread is: "we can't just keep every ancient bit of software that was once shipped." Again, ridiculing my position doesn't justify yours. No one is ridiculing you to my knowledge, that certainly isn't my intent. This kind of issue goes on constantly. It happened with wxwidgets, the gnome1 stuff, as I mentioned libnet0, and even to a smaller degree just within the games team with clanlib. We were holding on to an old version of clanlib for one game. However, earlier you said: BTW, I don't care if GTK+ 1.2 stays or goes but I do care about unmaintained stuff hanging around. Now that is a true concern, but OTOH it is a tangible problem that could be solved. So, if this is the case, why not try to solve the problem of maintenance for the software in question? I am speaking for GTK+ 1.2, I'll let others speak for software they care for. Btw, I can''t find GTK+ 1.2 on the Orphaned list. Cheers, Morten I wasn't talking about GTK+ 1.2 specifically. I'm talking about many of it's r(b)depends such as imlib, gnome-libs, etc in case GTK goes. Say a major security bug is found withing GTK. Now you have at least two dependent packages with lots of depends themselves that are effected but are unmaintained. Anyway, I'll shut up now as I said, I don't care if it stays or goes. Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Morten Kjeldgaard wrote: I am quite willing to adopt the package and maintain it, but I couldn't find it on the list of orphans. Maybe I didn't look hard enough? That list is enormous... :-( On a side note, I already am attempting to adopt a companion for GTK+ 1.2, namely gktglarea [1]. The modified package is on mentors and I am looking for a sponsor [2] (nudge nudge :-)) Morten, Maybe I've already offended you but I already offered to sponsor your gtkglarea upload, I just had a question on the soname mismatch that I asked about on -mentors. Thanks, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Neil Williams wrote: Barry - PLEASE do not continue with the request for sponsorship of gtkglarea. Neil, My apologies but I just uploaded it. It still has a few r(b)depends: rdepends: xt worlded vertex python-visual rbdepends: celestia vertex xt Sorry, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Neil Williams wrote: Has my response changed your opinion of gtkglarea in Debian? You could always join the calls for packages depending on gtkglarea to migrate to libgtkgl2.0 and thereby support the removal of gtk1.2 and glib1. Not at all. In fact even for Lenny I attempted to do some porting and/or uploads of new upstream where possible. I'd personally love to see it go but I'm just one lowly new DD in a sea of people with much more skills than I. :) Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Hi folks, In case any of you are interested/care. Just for kicks I started digging through many of the r(b)depends for gtk+1.2. I have posted my notes here: http://people.debian.org/~bdefreese/gtk+1.2_rdepends_notes Yes, I know the format is hideous, sorry. I have already done some RM:s and NMUs for a couple of them. I will keep updating these notes if I get anywhere. If any of you maintain any of these packages and have any thoughts/suggestions/etc, please feel free to contact me. Thanks, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Josselin Mouette wrote: Le lundi 08 décembre 2008 à 08:25 -0600, William Pitcock a écrit : On Sat, 2008-12-06 at 19:08 +0100, Josselin Mouette wrote: Gah, I thought it was able to handle SNES ROMs. The correct answer would probably be zsnes, although it only works on i386. Actually, gsnes9x can just be dropped. It is just a frontend to snes9x (which, afaik, uses Xlib directly). If you want to replace gsnes9x which is a frontend, you need another frontend, or another emulator with a builtin frontend. Otherwise this is like proposing to replace a file manager with a shell. Cheers, Looks like snes9express is supposed to be another front-end that is gtk2.0 but it has never been part of a stable release. Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Gtk1.2/Imlib/gnome-lib packages (Long)
Hi folks, Just in case anyone cares/is interested, here is some work I have been doing on packages using Gtk1.2, Imlib, gnome-libs, or any combination thereof. Obviously some packages fall within more than one rdepend/rbdepend. gnome-libs: bluefish Actually built with gtk2 but still build-deps on gnome-bin?? (pinged maintainer). Just a suggests, can probably be removed. mrwtoppm GTK2 app but still build-depends on libart-dev. NMU'd removing build-dep on libart-dev and gdk-pixbuf-dev. ogle-gui GTK2 app but still build-depends on libart-dev. NMU'd removing build-dep on libart-dev. swftools Build depends on libart-2.0-dev | libart-dev digitaldj Will need ported or removed. gwc False positive? slmon Build-depends on libgnome-dev. Will need ported or removed. Upstream inactive since 2004. synce-trayicon New in Lenny. Unneeded build-dep on libgnome-dev? Bug Filed. xpuyopuyo Needs ported or removed. soundtracker Supposedly upstream is "working on it" gnome-lokkit PROP_RM Filed. gfslicer Started working on a patch but is it worth keeping? gbib Will need ported or removed. Upstream has a newer release candidate but still not gtk2. gnomekiss Games team package. Uploaded new release without libgtkhtml-dev. gsnes9x Should probaby just be RM'd. snes9express seems a replacement that is gtk2.0. directory-administrator PROP_RM filed by Frank. powershell E-mailed maintainer about removal. gtkgo PROP_RM bug filed gtkfontsel Orphaned but a fairly significant popcon. I can't find new upstream source. Could probably be ported or RM:d. gtkglarea Orphaned (now new maintainer) and I can't find any upstream source yet but has a few r(b)depends. gtkglarea5: celestia New in Lenny vertex RM: Filed. xt Needs ported or removed. worlded Needs ported or removed. Upstream seems inactive since 2003. (Pretty low popcon). python-visual Needs ported or removed. There is a new upstream beta 5.0, not sure if it requires gtkglarea. imlib: chinput Hasn't seen an upload since 2006. Needs transition to imlib2. Can't find upstream source. e16menuedit e16menuedit2 a gtk2.0 replacement? gkrellm Bug filed to remove unneeded build-dep on gdk-imlib1-dev gkrellmitime Bug filed to remove unneeded build-dep on gdk-imlib1-dev. gretl Unnecessary build-dep? Maintainer is uploading new version without build-dep. qtpixmap Binary gtk-engines-qtpixmap uses gdk-imlib11 sylpheed-gtk1 PROP_RM filed. RM: filed by maintainer. gkrellm-snmp NMU'd removing unneeded imlib build-dep gkrellweather NMU removing unneeded imlib build-dep. icewm Ugh kdegraphics 4.x version in experimental doesn't use imblib11 libgtkimreg Another one for Andreas Tille (Mailed Andreas for thoughts). Started on porting. mgp Not well maintained. Newer upstream but still not imlib2. (Can be built without imlib though). paul Another one for Andreas Tille (Mailed Andreas for thoughts). Started on porting. pixelize PROP_RM filed qiv E-mailed Bart Martens for opinion. Replied, now have e-mailed upstream to see if they are doing any porting work. qvwm PROP_RM filed wallp RM: Filed. xteddy E-mail Andreas Tille (taken over upstream). Sent partial patch. Still needs some work. Peter De Wacther fixed up patch. ygraph Gtk1.2 and imlib. Will need ported or removed. netdude ITA'd. There is a new upstream available. I've pinged the ITAer to see if the new upstream is GTK 2.0. sqlrelay Some of the binaries have decent popcons. We could probably either port sqlrelay-config-gtk or just remove that binary for now. Thanks, Barry deFreese -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Gtk1.2/Imlib/gnome-lib packages (Long)
Paul Wise wrote: On Fri, Dec 19, 2008 at 5:40 AM, Moritz Muehlenhoff wrote: Actually, it would be nice if we had a decicated cleanups/transitions overview page on wiki.debian.org as a central starting point for people who want to help out. This is the old one: http://wiki.debian.org/OngoingTransitions This is the one that Barry added: http://wiki.debian.org/Transitions Shoot, I didn't add that, Moritz did. I didn't see the other one when I was poking around wiki.d.o today though. Which one should we actually use? Sorry, Barry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Gtk1.2/Imlib/gnome-lib packages (Long)
Paul Wise wrote: On Fri, Dec 19, 2008 at 11:55 AM, Barry deFreese wrote: Shoot, I didn't add that, Moritz did. Ah, woops. Which one should we actually use? OngoingTransitions IMO (perhaps it could be renamed too). BTW, found this page too: http://wiki.debian.org/GTK%2B_1.2_leftover Yeah, I just found that too thanks. It's a bit cluttered though. Barry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Josselin Mouette and Planet Debian
Marco d'Itri wrote: On Dec 18, Russell Coker wrote: The Ubuntu community includes many former and current members of the Debian community. It seems that they don't have a problem with the code of conduct. Why do you think that a code of conduct which works well for Ubuntu would fail for Debian? They get paid? In my experience this helps a lot to be nicer to stupid people. No, MOTUs are held to the same CoC and are definetly NOT paid. Barry deFreese -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Gtk1.2/Imlib/gnome-lib packages (Long)
Paul Wise wrote: On Fri, Dec 19, 2008 at 11:55 AM, Barry deFreese wrote: Shoot, I didn't add that, Moritz did. Ah, woops. Which one should we actually use? OngoingTransitions IMO (perhaps it could be renamed too). BTW, found this page too: http://wiki.debian.org/GTK%2B_1.2_leftovers OK, I have created a new page at: http://wiki.debian.org/Gtk1.2ImlibGnome1Removals and linked it to the OngoingTransitions page. Please feel free to update/fix, etc (especially the layout, I'm not happy with). Thanks! Barry deFreese -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Gtk1.2/Imlib/gnome-lib packages (Long)
Daniel Leidert wrote: It does *not* build-depend on gnome-bin and I already told you this (you simply did not answer). Where do you see this build-dependency? Regards, Daniel Daniel, Sorry about that, I keep going through so many of these, I keep mixing up build-deps/deps in my syntax. But I did have "Just a suggests, can probably be removed." in there. Thanks, Barry deFreese -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Should gnome-libs die for Lenny?
Hi folks, There are only 5 packages left that have reverse depends on gnome-libs packages. They are as follows: digitaldj: Removal request was filed but maintainer claims someone has done a Gtk2 port and saved it for now. gbib: Removal was proposed. I mailed upstream and the response was "gbib is no longer maintained or developed". I'm trying to build it now with Gtk2 but not having much luck so far. gsnes9x: Removal requested. It's been listed as dead on SourceForge since 2004. snes9express possibly a Gtk2 replacement? powershell: Removal was requested but maintainer saved it. This one could be a bit of a pain to port. soundtracker: Dead upstream since 2001 but one of the devs started on a Gtk2 port. Currently it fails to build and has bugs according to the website. I've e-mailed but not received a response. Given this and the fact that gnome-libs removal was suggested (and bugs filed) over a year ago, does it make sense to remove gnome-libs before Lenny releases? For more details, I have been trying to keep the wiki page up to date: http://wiki.debian.org/Gtk1.2ImlibGnome1Removals Thanks, Barry deFreese -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should gnome-libs die for Lenny?
Tim Dijkstra wrote: Barry deFreese schreef: Hi folks, There are only 5 packages left that have reverse depends on gnome-libs packages. They are as follows: digitaldj: Removal request was filed but maintainer claims someone has done a Gtk2 port and saved it for now. I thought this was a post-lenny thing anyway, but if there's only so few packages left, I'm tempted to not obstruct the removal of gnome-libs for digitaldj. Well I think it was originally supposed to be for Lenny, then it kind of died. But with so few packages left, I was asking if it was worth it to keep them in Lenny, hence why I mailed this list. I'm fine either way, I was just thinking it might be worth getting it out of Lenny. Lets say I try to get an upload with the GTK2 patch within a week or so, would the new digitaldj sitll be allowed in to lenny? I can't speak for the release team but I would think if the changes aren't massively intrusive, it would be possible. [Johannes is the patch in such a state that we could do that?] grts Tim Thanks! Barry deFreese -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Dropping Freetype1
It's me again. Several month ago I was looking at removal of the freetype1 package. There is only 1 rdepends/r-bdepends left, ttf2tex which is NPOASR. There seems to be some pushback on removing freetype1 (or at least freetype1-tools). Now the freetype1 package is orphaned. Do those of you that wish it to survive, want to take over maintenance of the package? If not, I will likely be requesting removal. It is currently not in testing. Thank you, Barry deFreese Debian QA -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Giving away most of my packages
Amaya wrote: Dear developers, I am sadly (but happily) overwhelmed by work and RL and the time I can dedicate to Debian has been drastically reduced. So I am giving away my packages to sweet, loving and caring maintainers: - xdigger: http://packages.qa.debian.org/x/xdigger.html No upstream, but easy to maintain. Games team candidate? - jail: http://packages.qa.debian.org/j/jail.html There are much better tools out there, maybe RFRemoval? - imsniff: http://packages.qa.debian.org/i/imsniff.html Upstream is a bit unresponsive, otherwise easy to maintain. I still need to issue requests to be removed from the uploaders field for: amaya, fkiss, gnomekiss, libirman, lirc, mencal, perforate, and piuparts. If you are in any of these teams, please remove my name from the uploaders field. I will still keep subtitleeditor, http://packages.qa.debian.org/s/subtitleeditor.html as I still care enough for it, but a Co-maintainer would be *very* wellcome. Heck, if you really fancy it, I will give it to you This is not a "Good bye Debian" email. I still plan to continue working on QA and transitions listed at http://wiki.debian.org/AmayaRodrigo, but at a slower pace, and in a "I got a spare afternoon, let's send some patches" fashion, but don't expect that to happen very often. Regarding my sponsorees, I am also "orphaning" them. If you use and like any of the packages I sponsor, feel free to offer yourself for sponsorship, (see: http://qa.debian.org/developer.php?login=amaya for details), but please keep me in the loop. I am specially worried about twiki, with a security bug (CVE-2007-5193, #444982) and a ready fix, that I simpply don't have the time to review for upload (It took me already too long to find time to write this email). Remember not to feed the trolls while I am away, and expect me back with full force by the beginning of next year :) Happy hacking! I can try to take a look at xdigger from a games team perspective. If you would like I can also take a look at twiki but I am not a DD nor exactly a master but I'm happy to help if you want it. Thanks, Barry deFreese (aka bddebian) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FTPMaster meeting, step1: New FTPMaster
Woohoo, congrats Torsten. Again, I must apologize for my extended absence, work and personal life are just insane right now. I hope it slows down in the winter and I will resume full duties. :( Thanks, Barry On 9/17/2010 11:52 AM, Joerg Jaspert wrote: > Heyho, > > as you may have read in the past, there is a meeting of the FTPTeam this > weekend. And for fun and profit we decided to make Torsten Werner an > FTPMaster (especially because he isn't here), so everybody please send your > condolences (or congratulations, your call) to him now. > > More to come later. > -- 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/4c9394a2.1060...@verizon.net
Re: To the aqualung NMUer....
Adam Cécile (Le_Vert) wrote: Hello, I just received a DAK acknowledgement for aqualung 0.9~beta9.1-1.1 but it's not me who prepared this package. I guess it's a NMU fixing the ffmpeg/libavcodec issue but I can't found any related message neither on the BTS nor on debian mailing lists (-devel and -release). I would have been great if this people told me he were preparing a NMU because I was working on new upstream release package that ALSO fix the ffmpeg issue. Anyway... If someone is responsible of this upload, please overwrite it by the new packages I just uploaded to debian-mentors: http://mentors.debian.net/debian/pool/main/a/aqualung/aqualung_0.9~beta10-1.dsc Thanks in advance, Adam. That was me. I haven't posted the diff for the NMU yet. I'll take a look at the new upstream on mentors. Of course tagging the existing bug as pending or some other form of notification that you were working on it would have helped. Sorry, Barry deFreese -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Should we remove OpenMotif?
Hi folks, As some of you may already know, I have been doing a lot of package removals and QA work. One of the ones I ran across lately is OpenMotif. It has been orphaned since 2006 and has several bugs against it. However, it does still have 1 r(b)depends. (arb which is also in non-free). I was considering packaging up the new upstream but I would have to register to do that and I am not really keen on putting that much effort into a non-free package. Anyone have an opinion? Thanks, Barry deFreese P.S. Apologies for the cross-post but since arb is a Debian Med Packaging team I am CCing them. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should we remove OpenMotif?
Daniel Baumann wrote: Barry deFreese wrote: I was considering packaging up the new upstream but I would have to register to do that not true: ftp://ftp.ics.com/openmotif/ Anyone have an opinion? it's still on my todo list. if i'll not get arround to do it over the current long weekend, no objections for its removal. OK, just for kicks I just pulled arb and it seems to build fine with lesstif. Though I don't know the package well enough to test runtime. Med Team, Any chance of trying to move arb to lesstif? Thanks! Barry deFreese -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/11/2013 11:56 AM, Andrey Rahmatullin wrote: > On Tue, Jun 11, 2013 at 07:04:30AM -0400, Stephen M. Webb wrote: >>> Normally you would keep the old version's changelog. But even if you don't, >>> there's no need >>> for an ITP in cases like this, or when part of a package starts to be >>> shipped from a >>> different source upstream. It's like opening an ITP for every upstream >>> release. You can >>> still do it but people are going to complain if it starts to happen very >>> often... >> Perhaps what is not clear is that there is no old version. The SDL2 family >> of libraries is >> not a new version of the SDL family of libraries so much as a new set of >> incompatible >> libraries serving the same purpose, from the same people. There is no common >> code base and >> the libraries are one hundred percent parallel-installable. > Ah, then this is a different case and I agree that it deserves an ITP. > My only concern here is that while SDL2 is significantly different, there is an SDL team which ideally would be packaging it. Have they been contacted? I am actually a member of that team but admittedly have not been keeping up with it unfortunately. :( Thanks, - -- Barry deFreese Sometimes helper, sometimes hinderer to: Debian Games, QA, GNU/Hurd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG3TKsACgkQ5ItltUs5T36YDwCffehi4s76Tb4Yz+4DjjVKBJFP FhsAni2AeL+FPinC9D/vIvcuisTagwID =18wk -END PGP SIGNATURE- -- 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/51b74cab.3030...@gmail.com
