ssh & master
It seems master does not accept ssh connections. What's going on? Michael P.S.: Pleasee CC me on my private address on replies since I rely on ssh to master for my debian mail. -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
Has recibido una postal de Michael
Hola debian-devel@lists.debian.org, Has recibido una postal de Michael <[EMAIL PROTECTED]> ! Para ver tu postal por favor clickea este link : http://postales.sonico.com/view.php?cid=12354503&[EMAIL PROTECTED]&db=1&t=ecards_sonico&ss=1 Muchas Gracias, http://Postales.Sonico.com Sitios recomendados http://www.TarjetasTelefonicas.com - Ahorra hasta 95% en tus llamadas telefónicas http://www.Sexymetro.com - ¿Crees que eres sexy? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Reomve
Remove
Re: Bug#760592: ITP: bsdowl -- bmake macros for building OCaml projects, TeX projects, and more
Adam D. Barratt wrote: > #debian-mentors on irc.debian.org / irc.oftc.net is very much _not_ > invite-only. Thank you for correcting this, most likely I connected to another server. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544e5a4a.6010...@gmail.com
Re: IMPORTANT: Do live Debian images have a future?
I'm not a dev but I am a user and I do test so I'll add my bit here. Let's be frank Live Wrapper only exists because of animosity within Debian towards the originator of Live Build (and to be honest his own lack of concern for what Debian required of Live Build). Live Wrapper was rushed and was never going to be ready for Stretch and in hindsight it was a little foolish to think it would be ready to build the types of images Debian required. Live Build wasn't up to scratch but the UEFI support issue has been fixed so what other issues are there with Live Build that makes it unreasonable to use? On 27 June 2017 at 00:08, Steve McIntyre wrote: > [ Note the cross-posting... ] > > Hey folks, > > Background: we released live images for Stretch using new tooling, > namely live-wrapper. It is better than what we had before (live-build) > in a number of ways, particularly in terms of build reliability and > some important new features (e.g. UEFI support). But it's also less > mature and has seen less testing. There have been bugs because of > that. I have fixes for most of the ones I know about [1], and I'm > still working on more bugfixes yet. > > While the bugs are annoying, what worries me more is that they were > only spotted in release builds. There had been testing versions of > live images available for multiple weeks beforehand, presumably with > the same bugs included. (Almost) none of them reported. This shows > that we don't have enough people using these live images and/or caring > about filing bugs. > > We have a similar lack of involvement in terms of the content of the > live images. As I said above, I'm happy that we now have a reliable > tool for building our live images - that makes my life much > easier. But I honestly have no idea if the multiple desktop-specific > live images are actually reasonable representations of each of the > desktops. For example, I *seriously* hope that normal KDE > installations are not effected by #865382 like our live KDE > images. Validation by the various desktop teams would be useful here. > > The current situation is *not* good enough. I ended up getting > involved in live image production because the images needed making, > and I was already the main person organising production of Debian's > official images. To be frank, I had (and still have) no direct use for > the live images myself and I don't *particularly* care about them all > that much. Despite that, I've ended up spending a lot of time working > on them. A few other people have also spent a lot of time working in > this area - thanks are due to those people too. But it's still not > enough. > > If our live images are going to be good enough to meet the standards > that Debian users deserve and expect, we need *consistent*, > *sustained* involvement from a lot more people. Please tell me if > you're going to help. If we don't see a radical improvement soon, I'll > simply disable building live images altogether to remove the false > promises they're making. > > [1] https://get.debian.org/images/release/current-live/amd64/ > iso-hybrid/#issues > > -- > Steve McIntyre, Cambridge, UK. > st...@einval.com > "...In the UNIX world, people tend to interpret `non-technical user' > as meaning someone who's only ever written one device driver." -- Daniel > Pead >
Re: IMPORTANT: Do live Debian images have a future?
Charles, let me clear up a couple of misconceptions for you. Debian Live (made with Live Wrapper) is an official Debian project. Live Build (the old Debian Live) apparently wasn't official but was recognised by Debian for its official images. Live Build is now officially part of Debian and Rafael Hertzog is the new developer maintainer of Live Build. As for reporting bugs because Debian Live (that uses Live Wrapper) is an official Debian project bugs should be reported through the bug tracker. That is the way it has been since Live Wrapper was first released. However people still do, and I have done it also, report issues with Live Wrapper in the Live mailing list. Hope that helps. On 27 June 2017 at 21:54, Charles Chambers wrote: > And I'll add my 2¢ as an end user. > > The live images exist IMHO to test compatibility before committing to > installation, and to install what was just tested and demonstrated, > regardless of environment. It's a nice feature (arguably an essential > feature) that the actual install mirror *exactly* the tested compatibility > and appearance. To go with this, it *was* nice to be able to install in > the absence of a network connection or Internet service. > > The Live environment still works fine for testing for compatibility, > especially when the Nonfree repository is included. Installation, no > longer. > > My 2¢ is that installation suffers from a lack of testing, probably > because Debian Live is a "unofficial" branch off the development tree. > It's made worse because bugs for Live have no clear reporting process. > Where DOES one report a problem - to this mailing list, or the mailing list > more obviously suited (think a bug found while installing...report here, or > report to debian-install, or to debian-boot)? > > Inquiring minds want to know! > > Charlie > > > > On Jun 26, 2017 12:55 PM, "Michael ." wrote: > >> I'm not a dev but I am a user and I do test so I'll add my bit here. >> >> Let's be frank Live Wrapper only exists because of animosity within >> Debian towards the originator of Live Build (and to be honest his own lack >> of concern for what Debian required of Live Build). Live Wrapper was rushed >> and was never going to be ready for Stretch and in hindsight it was a >> little foolish to think it would be ready to build the types of images >> Debian required. Live Build wasn't up to scratch but the UEFI support issue >> has been fixed so what other issues are there with Live Build that makes it >> unreasonable to use? >> >> On 27 June 2017 at 00:08, Steve McIntyre wrote: >> >>> [ Note the cross-posting... ] >>> >>> Hey folks, >>> >>> Background: we released live images for Stretch using new tooling, >>> namely live-wrapper. It is better than what we had before (live-build) >>> in a number of ways, particularly in terms of build reliability and >>> some important new features (e.g. UEFI support). But it's also less >>> mature and has seen less testing. There have been bugs because of >>> that. I have fixes for most of the ones I know about [1], and I'm >>> still working on more bugfixes yet. >>> >>> While the bugs are annoying, what worries me more is that they were >>> only spotted in release builds. There had been testing versions of >>> live images available for multiple weeks beforehand, presumably with >>> the same bugs included. (Almost) none of them reported. This shows >>> that we don't have enough people using these live images and/or caring >>> about filing bugs. >>> >>> We have a similar lack of involvement in terms of the content of the >>> live images. As I said above, I'm happy that we now have a reliable >>> tool for building our live images - that makes my life much >>> easier. But I honestly have no idea if the multiple desktop-specific >>> live images are actually reasonable representations of each of the >>> desktops. For example, I *seriously* hope that normal KDE >>> installations are not effected by #865382 like our live KDE >>> images. Validation by the various desktop teams would be useful here. >>> >>> The current situation is *not* good enough. I ended up getting >>> involved in live image production because the images needed making, >>> and I was already the main person organising production of Debian's >>> official images. To be frank, I had (and still have) no direct use for >>> the live images myself and I don't *particularly* care about them all >>> that much. Despite
Re: IMPORTANT: Do live Debian images have a future?
Thomas it is all fine and good to say "(lets not go into details why this happened)" but the details support the reality of the situation. Please read (https://lists.debian.org/debian-live/2015/11/msg8.html) and see where Iain says >>It is worth noting that live-build is not a Debian project, it is an external project that claims to be an official Debian project. This is something that needs to be fixed. My understanding come from the people who initiated the take over of building live images. If I am wrong then so was Iain and you should have been a part of the discussion back in November 2015 to clear it all up for us. I want Live-Wrapper to succeed (only because it is the official Debian Live system) and I support it through testing it and reporting on things I have found which would limit the audience who could use it but I also want Live-Build to continue (because Live-Build is more suitable for a roll your own images that derivatives would create). I must admit I am concerned about this reluctance "to go into details". This type of thing keeps people in the dark and that is something I do not support. There is no need to go over all the details but at least provide proof as I have done. On 5 July 2017 at 08:34, Thomas Goirand wrote: > On 06/27/2017 11:53 PM, Michael . wrote: > > Charles, let me clear up a couple of misconceptions for you. Debian Live > > (made with Live Wrapper) is an official Debian project. Live Build (the > > old Debian Live) apparently wasn't official but was recognised by Debian > > for its official images. Live Build is now officially part of Debian > > Hum... You also have some misunderstanding here. Live-build has been > packaged in Debian, and fully part of Debian for *years* (well before > Raphael worked on it). > > What changed is that, since Daniel Baumann doesn't build the live images > anymore (let's not go into details why this happened), Steve does it at > the same time as other Debian images. It's now included in a single > process of building images. > > Cheers, > > Thomas Goirand (zigo) > >
Re: An abrupt End to Debian Live
I'd also like to remain a user if at all possible. On 10 November 2015 at 12:07, Harshad Joshi wrote: > Count me in for your new fork, let's not give up so easily. > > Sent from my Cyanogen phone > On 09-Nov-2015 10:33 pm, Daniel Baumann < > daniel.baum...@progress-technologies.com> wrote: > > [ I don't know why this post is not showing up on planet.debian.org: > https://danieltmp.wordpress.com/2015/11/09/an-abrupt-end-to-debian-live/ > I am sending it here by mail now. ] > > > An abrupt End to Debian Live > > > Debian can be great. > > But depending on who you are, where you come from, and who your friends > are, Debian can also be hateful and full of deceit. > > Before even more of reality[0] is spin-doctored into some distorted[1] > view of it, and before my past work is being discredited, I will take > the high road and continue my work on Debian Live images on the outside. > > If there is one thing I did learn over the past years of agressions > towards me, then that it is this: I am forced to blindly and > unchallenged accept everything others decide about me or my work, > resistence to the cabal is futile, anything goes, no[2] matter[3] what[4]. > > Therefore, after having founded Debian Live back in 2006 and having by > now almost 10 years continuously worked on it, without further ado: > > Debian Live is dead, hijacked by the debian-cd and the > debian-installer Teams[5] > > The live.debian.net server will be shut down end of month, the Git > repositories are read-only as of now and mirrored to GitHub[6] for > archival. > > So long, and thanks for all the fish[7]. > > Daniel > > [0] https://www.debian.org/News/weekly/2006/08/ > [1] https://lists.debian.org/debian-live/2015/11/msg8.html > [2] https://bugs.debian.org/497471 > [3] https://bugs.debian.org/759189 > [4] https://bugs.debian.org/754910 > [5] https://bugs.debian.org/804315 > [6] https://github.com/debian-live > [7] http://live.debian.net/project/downstream/ > >
Re: An abrupt End to Debian Live
Daniel, since this rukus blew up and your announcement I have been considering my involvement with Debian (I have even install Devuan to see if that would suit my purposes). I don't have anything to add to my previous comments apart from I hope you create a Debian Live repository or PPA and let us know where it is located. Debian Live is to good a project (and tool) to just let die. Many people, apart from myself, rely on Debian Live (to create our own purpose specific distros, which is something you know already) and its demise will create many problems downstream (which is obviously something the "other" team chose to ignore when they started this mess). I don't want to pressure you into anything, even though the crux of this email is to highlight the problems that will occur downstream, I just want to let you know that Debian Live does have a loyal following of people who do use it for reasons that are to help others even further downstream. Regards Michael. On 10 November 2015 at 03:47, Daniel Baumann < daniel.baum...@progress-technologies.com> wrote: > [ I don't know why this post is not showing up on planet.debian.org: > https://danieltmp.wordpress.com/2015/11/09/an-abrupt-end-to-debian-live/ > I am sending it here by mail now. ] > > > An abrupt End to Debian Live > > > Debian can be great. > > But depending on who you are, where you come from, and who your friends > are, Debian can also be hateful and full of deceit. > > Before even more of reality[0] is spin-doctored into some distorted[1] > view of it, and before my past work is being discredited, I will take > the high road and continue my work on Debian Live images on the outside. > > If there is one thing I did learn over the past years of agressions > towards me, then that it is this: I am forced to blindly and > unchallenged accept everything others decide about me or my work, > resistence to the cabal is futile, anything goes, no[2] matter[3] what[4]. > > Therefore, after having founded Debian Live back in 2006 and having by > now almost 10 years continuously worked on it, without further ado: > > Debian Live is dead, hijacked by the debian-cd and the > debian-installer Teams[5] > > The live.debian.net server will be shut down end of month, the Git > repositories are read-only as of now and mirrored to GitHub[6] for > archival. > > So long, and thanks for all the fish[7]. > > Daniel > > [0] https://www.debian.org/News/weekly/2006/08/ > [1] https://lists.debian.org/debian-live/2015/11/msg8.html > [2] https://bugs.debian.org/497471 > [3] https://bugs.debian.org/759189 > [4] https://bugs.debian.org/754910 > [5] https://bugs.debian.org/804315 > [6] https://github.com/debian-live > [7] http://live.debian.net/project/downstream/ > >
Re: Mandatory LC_ALL=C.UTF-8 during package building
Am 06.06.24 um 18:52 schrieb Andrey Rakhmatullin: On Thu, Jun 06, 2024 at 12:08:17PM +0200, Johannes Schauer Marin Rodrigues wrote: Or whether we should switch the default and require that d/rules is run in an environment (for example as set-up by dpkg-buildpackage) where these variables are set? (a previous discussion on this: https://lists.debian.org/debian-devel/2017/10/msg00317.html) I would prefer that dpkg-buildpackage provides a "sane" build environment by default (which I think includes a LC_ setting pointing at a .UTF-8 locale) and fewer packages explicitly setting those things via debian/rules. Afaics, this would actually make efforts like reproducible builds *easier* as settings provided by reproducible-builds wouldn't be overwritten by debian/rules. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072491: Dead keys stopped working in unspecified environment
Hi all, First: - DE is Cinnamon. - DM is lightdm. - Keyboard model is Generic 105-key PC - keyboard layout is Danish - AltGr function is default - Compose key is 'Meny key' I have now tried installing and uninstalling gnome-session-bin which have no effect so that cannot be the cause. Changing DE from Cinnamon to XFCE4 and dead key works. Creating a new user and using this user session in both Cinnamon and XFCE4 and dead key works in both DE. Conclusion: My Cinnamon DE using my old user must have gone haywire somehow so I have created a new user and therefore this bug can be closed with solution 'works here, must be user error' ;-) Sore to all for the noise. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc https://keys.openpgp.org/vks/v1/by-fingerprint/A1306C5094B5E31B7721A3A66F4844C7CA7501AA mir datanom net https://keys.openpgp.org/vks/v1/by-fingerprint/0C14CD9479667E848770C8F98417B6C5E1BB093F mir miras org https://keys.openpgp.org/vks/v1/by-fingerprint/5F71405B571CB8EE2A414A4FC77C11E049A06E66 -- 'During times of universal deceit, telling the truth becomes a revolutionary act.' -George Orwell Don't just echo the code with comments - make every comment count. - The Elements of Programming Style (Kernighan & Plaugher) This mail was virus scanned and spam checked before delivery. This mail is also DKIM signed. See header dkim-signature.
Bug#1073003: ITP: python-django-structlog -- Structured Logging for Django
Package: wnpp Severity: wishlist Owner: Michael Fladischer X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-django-structlog Version : 8.1.0 Upstream Contact: Michael Fladischer * URL : https://github.com/jrobichaud/django-structlog * License : Expat Programming Lang: Python Description : Structured Logging for Django django-structlog is a structured logging integration for Django project using structlog. Logging will then produce additional cohesive metadata on each logs that makes it easier to track events or incidents. I intend to maintain this as part of the DPT. -BEGIN PGP SIGNATURE- iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmZogXwbHGZsYWRpc2No ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqXPoIAJC4pQVllONVB1tF0xZI 0bJ0HGSW9UHtAC3HlkirN5RNS2Ax8VCUGRQjBlXtfDh38CdHuMH6KodCRi0t0mqR 7lnUu7cvK/I//3FGutqKonRAO9RQGA5d+dqLGauATQ0CrRFSU05BMspRAdWWjWHA 4/iaVbl2crB2obgQnCxHFf3Wg/HowdchY2yyMQlgeQgt1SdIzu0ttt+LZKqUaYs/ zM+DHBVL0hRF92JcROvTD/iH5X3DCsCp7upkkvYZ45NyVMBza68lKwGUkIwQh9LJ nrs5oibLlkupbhXPyGMJvcLPf1irbVae2Aw/icWAKAlelHorMqw1cwuBm6EhQbx8 Hvo= =XYb0 -END PGP SIGNATURE-
Re: File descriptor hard limit is now bumped to the kernel max
Am 14.06.24 um 14:13 schrieb Mourad De Clerck: PSA: as of systemd/256~rc3-3 the open file descriptors hard limit is bumped early at boot from 1048576 to the max value that the kernel allows, which on amd64 is currently 1073741816. Hi, It seems some proprietary software (the JetBrains IDEs) has some problems with this change. See for instance: https://youtrack.jetbrains.com/issue/IJPL-156522 See https://github.com/JetBrains/pty4j/pull/149 Feel free to upvote the MR. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: default network management tools
Am 10.07.24 um 18:36 schrieb Bernd Zeimetz: On Tue, 2024-07-09 at 11:45 +0100, Simon McVittie wrote: On Tue, 09 Jul 2024 at 10:57:39 +0200, Matthias Urlichs wrote: Agreed: either it's drop-in compatible or we may as well switch the default to NM and/or systemd-networkd. Well, here's a heretical thought: why don't we do that anyway, at least for new installations? To some extent, we are already there: for new laptop/desktop installations, NM is already the default (certainly true for GNOME, and hopefully for most/all of the other tasksel-supported desktops). For new server/embedded installations, I think networkd would be a better default than ifupdown [] yes please, I would love to see Debian switch from ifupdown to NM/networkd. ifupdown was the perfect tool for the time it was created in, but things have advanced, and imho now is a good time to switch. I agree. On all my systems I purged ifupdown long ago and use networkd exclusively for simpler/more static setups and NM for more dynamic environments, like my work laptop. Both proved to be very stable and solid. Since there is a lot of support for this idea, the next logical step as smcv said, would be to make d-i/netcfg networkd aware. At the beginning, this could be opt-in (for testing purposes) and we could make it the default later on. Any takers? Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1076144: ITP: python-jq -- lightweight and flexible JSON processor
Package: wnpp Severity: wishlist Owner: Michael Fladischer X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-jq Version : 1.7.0 Upstream Contact: Michael Williamson * URL : https://github.com/mwilliamson/jq.py * License : BSD-2-clause Programming Lang: Python Description : lightweight and flexible JSON processor A lightweight and flexible JSON processor that provides Python bindings for jq. I intend to maintain it as part of the DPT. -BEGIN PGP SIGNATURE- iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmaPzHkbHGZsYWRpc2No ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFq9FoH/RILM4s9aZRYxlMPK3Wu MxhOK8kfJ7/ZO/DhK3uZaXjWjBe+7yKMVnjYBg+RL9QGCevlBRiscO4pfJm1DLwh FO7Hf1aez9CJ1OKAwY7UhhbrRz/PlPTsp89DgC+Y39U6g8ceoxHc5nJrUud0/sJM fU2f2shyOHBdxYqbGr1oQ3IjO1ZkuNKLtbRa8+PLiBNQGumGqqjxg1FPHZt/e9M2 6JiizqHAHgZ1AjNfOC9wRNohcxjKm/aMykbAkXiCnSYhvhOUrnMLFsuiU2yo1MqS /t2ESlmKpnH2ORwJn5gzLC9pGAyGhGhEPfvOQFl3x+S8brkjktQbnJxF02XwdVDv qyk= =SB98 -END PGP SIGNATURE-
Bug#1076652: ITP: python-async-property -- decorator for async properties
Package: wnpp Severity: wishlist Owner: Michael Fladischer X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-async-property Version : 0.2.2 Upstream Contact: Ryan Anguiano * URL : https://github.com/ryananguiano/async_property * License : Expat Programming Lang: Python Description : decorator for async properties Python decorator for async properties. You can use @async_property just as you would with @property, but on an async function. . Features: * Both regular and cached property. * Cached properties can be accessed multiple times without repeating function call. * Uses asyncio.Lock to ensure cached functions are called only once. * Full test coverage with py.test. I intend to maintain it as part of the DPT. -BEGIN PGP SIGNATURE- iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmacES8bHGZsYWRpc2No ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqzD4H/13JKuP1fZh6MF/Mh1fg D/ZaZyrUzj3k2CIKs2z7C4/Pp1MLGWsOuvffHNCDtpogeSfQafTWtIQ6NT8eQw2i 2Qy4iXF10Y0j8euKQ5xJ25PKDOvcZFjB/Sy1PHEaRdI0Gr0H/vyfCRdA0cpFgSSt UKfQdkm573uPatp0nDIHaopvasGDvO2q/4VwRsx0hKikqw3RhhXnW2Yih4KG5NfA Rg/2B09yQn1PtT7FY+dG0Z7ECa8AVoW1vSAMfS2E0Dv7FI8Pplwq8fmAm2RIM2o2 P/WolVW/Kpsq/RHsyvsxKDgal4kyfYLLVbAk+sfsVKGmXRgMi2Sk/5FSXUCkAxro 9Q4= =irMQ -END PGP SIGNATURE-
Bug#1076735: ITP: python-django-zeal -- Detect N+1s in your Django app
Package: wnpp Severity: wishlist Owner: Michael Fladischer X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-django-zeal Version : 1.2.0 Upstream Contact: Tao Bojlén * URL : https://github.com/taobojlen/django-zeal * License : Expat Programming Lang: Python Description : Detect N+1s in your Django app Catch N+1 queries in your Django project. . Features: * Detects N+1s from missing prefetches and from use of .defer()/.only() * Friendly error messages like N+1 detected on User.followers at myapp/views.py:25 in get_user * Configurable thresholds * Allow-list * Well-tested * No dependencies I intend to maintain it as part of the DPT. -BEGIN PGP SIGNATURE- iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmaeulcbHGZsYWRpc2No ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqhBkH/2dLIXJ47jGoGnc1hC4l jpmdj1TA8W+i1Z2vmy7F+C10yqEJBlWh3rwW0v5j9oB+Ogo82aDmev/mGuwLeXNo w19SVoIMm34YXypI1Y0L4lt3yAPiXOaPD99cvk2EiKW/+XoiE8Ot98GhErgwMo4P fVp1Nveq5HPEW64msxYB/7qC7eBqhhjiXJ8mtpl4bYExn+9qJMl7V6Nj33zz6oFq cfWmQYcp3hkv3LXrj96hlSmvOJ9ox5cdfYtOU73O6uOv9I81emVriOSJFmqeJNU3 E8Bx7Vsbo17uZKPm3uNeJJX+fyOVdYzZevNQWEB1s5yBAlRbK+jXQr2KHi2Bs+IF DL8= =OUm1 -END PGP SIGNATURE-
unsubcribe
Bug#1078680: ITP: python-django-timescaledb -- database backend and tooling for Timescaledb
Package: wnpp Severity: wishlist Owner: Michael Fladischer X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-django-timescaledb Version : 0.2.13 Upstream Contact: Rasmus Schlünsen * URL : https://github.com/jamessewell/django-timescaledb * License : Apache-2 Programming Lang: Python Description : database backend and tooling for Timescaledb A Django database backend and tooling for Timescaledb. It provides a model field and manager to store and retrieve timescale data through the Django ORM. I intend to maintain it as part of the DPT. -BEGIN PGP SIGNATURE- iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAma8aCobHGZsYWRpc2No ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqz1oH/RfeyK27cRrOHKfN7Fww di7OLCL4de4qFz5ttowtfsaYvp8FeZH7Dr+N6UuXemLXV+jLRpRoIufohzv18he+ YpPCW/mVUvA+pszh4nUXdsnVaiFnTRI3/WeJfHq40UCM6134vu/vlz4hgCXtRBw/ TgJUhkgLqqhcuEC6XsJKVB3sflp1jPME1fJlbqt7qHQpf9o4cyMSPV4gNs9kBrbN rXpZ8NR81DsxaTHQ8NNkDpihEvLpiomwXxn21xudSW31XbfHNOJ7Mefsyhp1qvyt vYviOPUzC8gw23PiW6M06Lph5NrYjpuHxWiJT0Be+uykVDrhllb99BQHMK/BYWj5 q90= =4lpP -END PGP SIGNATURE-
Re: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts
The first time I rebooted after iproute2 removed the /sbin/ip link, my system failed to boot. I eventually discovered this was because /sbin/vconfig (from the "vlan" package) calls /sbin/ip and when that failed the network was not configured. This meant having to boot into single user mode for diagnostics because systemd hung forever waiting for the network. This change was noted in NEWS. I would suggest hooking your config into something that uses the network-online.target target, with a timeout like network-manager and networkd do, so that the boot process doesn't hang. If it's a simple unit, it's enough to add RuntimeMaxSec= to it, so that it's killed if it doesn't work within the configured timeout. It's just so depressing that this is how debian works now. We used to try to not break things, now the answer is "you should have read the NEWS, and known that unrelated packages were going to break, and reconfigured standard debian network tools to add non-default timeouts". All because the aesthetic preference for not having the same binary appear in two different paths is a higher priority than keeping systems working.
Re: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts
On Fri, Aug 16, 2024 at 04:54:02PM +0100, Colin Watson wrote: Quite. If nothing else, I think the code actually in the Debian archive that relies on the old path ought to be changed _first_, e.g. via an MBF. I see a bunch of cases that are relatively subtle and might suck a lot of other people's time trying to debug them from cold, such as AppArmor profiles and example scripts, and it's just good manners to give maintainers an explicit heads-up. Or, of course, leave it forever since it causes no problems...
removing a non-static version of qemu-user?
Hi! I'd love to get some input about an idea which I expressed in https://bugs.debian.org/1079603 - namely, to move static qemu-user emulation binaries from qemu-user-static package to qemu-user package (which contains dynamically-linked binaries with exactly the same functionality), effectively keeping just one, static, build of qemu-user instead of two. I see no reason of building two versions of qemu-user binaries, since static version is well-suited for all usages, while dynamically-linked one, while obviously smaller, is limited to just a few use cases. The details are expressed in the bugreport mentioned above. The resulting layout is compatible with current expectations, so nothing should be (immediatly) changed in existing packages/habits. If there are other reasons to keep non-static build of qemu-user which I didn't think of, please tell me. Thanks, /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
HEADS-UP: removing support for dhclient in NetworkManager
Hi, so far the Debian network-manager package has been built with support for dhclient (isc-dhcp-client). In version 1.49.90-1 (1.50 rc1), I decided to disable support for dhclient. This has been triggered by the following upstream change: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/001b3e9494234ff0bf7714bb37e36b48b10321dc * The support for "dhclient" has been deprecated, not built unless explicitely enabled, and will be removed in a future release. The internal DHCP client should be used instead and has been the default since version 1.20 (1.12 when built with meson). If you have used "dhcp=dhclient" in NetworkManager.conf, you can now remove this setting, as it will no longer be effective and only generate a warning in the journal like "dchp: init: DHCP client 'dhclient' not available" NetworkManager will automatically fall back to the internal client in this case. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Re: ifupdown maintenance
On Tue, Jul 09, 2024 at 10:57:39AM +0200, Matthias Urlichs wrote: Agreed: either it's drop-in compatible or we may as well switch the default to NM and/or systemd-networkd. Well, here's a heretical thought: why don't we do that anyway, at least for new installations? Frankly the default is a completely uninteresting issue. The major concern IMO is that the zeal to have Yet Another New Thing doesn't break all of the existing systems that are running perfectly well with ifupdown and which clearly don't need a new thing. As long as that's the case, make the default whatever is easiest to support and call it a day.
Re: ifupdown maintenance
On Tue, Jul 09, 2024 at 02:13:26PM +0200, Daniel Gröber wrote: If ifupdown's paradigm were working for people we wouldn't be having this conversation. Well, the problem is that there's a selection bias in people having this conversation--the people who are using ifupdown without issues aren't looking for a conversation about getting rid of it, right? How else would you move /etc/network/interfaces forward without breaking anything? Just don't. If someone needs to do something new that's supported by a new tool and not ifupdown, they should just use the new tool. Freeze ifupdown functionality, mark feature requests as wontfix, and update the documentation.
Re: ifupdown maintenance
On Mon, Sep 16, 2024 at 09:49:24AM +0200, Ansgar 🙀 wrote: Hi, On Sun, 2024-09-15 at 23:07 -0400, Michael Stone wrote: On Tue, Jul 09, 2024 at 02:13:26PM +0200, Daniel Gröber wrote: > If ifupdown's paradigm were working for people we wouldn't be having this > conversation. > How else would you move /etc/network/interfaces forward without breaking > anything? Just don't. If someone needs to do something new that's supported by a new tool and not ifupdown, they should just use the new tool. Hmm, ifupdown has problems assigning addresses for the internet protocol to interfaces. Is that something "new"? :) (And AFAIR that includes assigning static addresses to a static interface due to race conditions.) It's weird that something that apparently doesn't work, does work for so many.
Bug#280209: ITP: codeville -- More anarchic revision control system
Package: wnpp Severity: wishlist * Package name: codeville Version : 0.1.9 Upstream Author : Ross Cohen <[EMAIL PROTECTED]> * URL : http://www.codeville.org * License : Open Software License 2.0 Description : More anarchic revision control system Codeville is a new version control system. All other version control systems require that you keep careful track of the relationships between branches so as not have to repeatedly merge the same conflicts. Codeville is much more anarchic. It allows you to update from or commit to any repository at any time with no unnecessary re-merges. Codeville works by creating an identifier for each change which is done, and remembering the list of all changes which have been applied to each file and the last change which modified each line in each file. When there's a conflict, it checks to see if one of the two sides has already been applied to the other one, and if so makes the other side win automatically. When there's an actual not automatically mergeable version conflict, Codeville behaves in almost exactly the same way as CVS. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.23-grsec Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Bug#280553: portmap: do NOT silently switch to localhost only operation !
Package: portmap Version: 5-5 Severity: serious portmap should not silently switch to listening to the localhost interface only. This behaviour breaks things for every networked machine that uses NFS for example. This should not be the default behaviour. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-rc4-mm1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages portmap depends on: ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an ii libwrap07.6.dbs-6Wietse Venema's TCP wrappers libra -- no debconf information
Re: Debian's status as a legal entity and how it could effect a potential defense.
Ron Johnson writes: > On Mon, 2004-12-06 at 23:40 +1100, Hamish Moffatt wrote: > > On Mon, Dec 06, 2004 at 01:11:10AM -0600, Manoj Srivastava wrote: > [snip] > > Well, I've changed my mind actually. An optional package called > > 'hot-babe' is pretty harmless. The images are hardly pornography, > > though I certainly couldn't run it on my office PC (unless I was > > trying to get fired). > > Why would you get fired for displaying "hardly pornographic" images > on your PC? > > Oh, yeah, that's right: sexual harassment, uncomfortable workplace, > fear of lawsuits, blah, blah. > > Thanks, Hamish, for helping to make our point. There are lots of things in Debian that would violate workplace rules at some workplace (or at many): offensive fortunes, games, software that the IT department has not approved or does not track, and so forth. None of that is relevant to whether someone is exposed to criminal liability or liable for actual damages for distributing a package like hot-babe. Michael Poole
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote:
> Let me first say unequivocally that the LCC is very interested in
> getting Debian involved. The question has always been: How do we do
> that?
I think there is one obvious answer to this question: 'Learn from
history'.
1. Unix and UnitedLinux failed. LSB party succeeded but has no practical
importance.
2. GNOME succeeded for the desktop.
The reason why the above failed have already been outlined in this
thread and one quote from Bruce sums it up pretty well: 'The members
considered that they had proprietary value at the level at which they
were collaborating'.
The reason why GNOME succeeded is because it builds a solid, predictable
and free base for vendors and distributions to build on. Every major
distribution which is interested (mostly RedHat, Novell and Sun) has
people working on GNOME and collaborating with each other.
The other reason why GNOME succeeded is because it spectaculary managed
to reinvent itself to make it feasable for others to build upon it.
Before those mentioned above used GNOME as their base, it was pretty
much similar to what Debian is today: No proper release schedules,
delays and not much of a broad and far-reaching vision.
So I think the obvious conclusion to the above answer ('learn from
history') is:
*** The interested parties of the LCC should pick Debian as a base and
Debian should make this possible. ***
Rather than everybody just throwing all their stuff in together and
mixing it up.
Of course, this would also mean for Debian to change. Debian is free
and solid today, but not predictable. Thus:
* We should commit to strict release cylces of a base system others
(and Debian itself) can build value upon.
* We should proabably also commit to a set of core architectures which
*need* to be bug-free on release, while the rest *should* be, but
would not delay the release.
* We should look into having a reality-check with respect to licensing
and the way we treat each other.
On the other hand, this would also mean: The other partners should get
involved into Debian development, both by getting their toolchain/base
developers into the Debian project and possibly accepting Debian
developers into their ranks.
All this could not be done easily, but it is the only viable solution
for a solid, free and predictable base system. There is no alternative
to it.
thanks,
Michael
Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1
On Fri, Dec 10, 2004 at 01:49:33PM +0100, Frank Küster wrote: > > I'm sorry the NMU annoyed you but I welcome it. There is nothing worse > > than a package that kills buildds, esspecially such a common one. > > I agree. But still LaMont should have expressed his intent to do so, and > send the patch to the BTS. I don't have a problem with being NMUed, but > with NMUs prepared improperly. At this point, any RC bug in an important (as in for the release, not priority-wise) package is an implicit express to be NMUd, at any time. Deal with it, we want to release. One could argue about sending the NMU-patch/interdiff to the BTS, but I personally do not see much point in it, since (hi Omnic!) you can just get it from the archive and sync it yourself. It still makes sense for packages where you suspect the maintainer to be inactive/not willing to deal with this or (as is the case here apparently) already working on a new revision. In any case, NMUs are never meant as personal attacks or gratuitous. Especially when they are done by buildd maintainers you can be certain there was some need for it. I envision a time where there are no more NMUs, just uploads by people who care. cheers, Michael
Re: LCC and blobs
Goswin von Brederlow writes: > Brian Nelson <[EMAIL PROTECTED]> writes: > > > You aren't reading what I've written. Virtually 100% of firmware > > out there (included on the device or loaded externally) is non-free. By > > your reasoning, the entire kernel should be moved to contrib since no > > free hardware exists on which it can run. > > Sure it runs on free hardware. On 100% free hardware. Take a pen, a > paper and the boch source code and run your own linux on the pen+paper > system. :) > > Ok, it's a bit insane, but possible. > > But let me say it again: "What matters is if the firmware itself is > distributable at all and if it is DFSG-compliant." You contradict yourself. You can execute the firmware-loading driver on pen and paper also; it operates just as well as the rest of the kernel does. Less trivially, imagine a device that speaks the same protocol as the "problematic" device+firmware combination -- with the distinction of not needing firmware. Since the software can use that device instead, the status of the firmware is irrelevant. Otherwise, we must move clients and servers for network protocols into contrib if the other end is not implemented by software in main: they do not function properly without the other end. Some examples would be things that speak AIM, MSN, Yahoo! messenger, etc. Since some suggest that Linux kernel modules should be moved to contrib while the rest of the kernel stays in main, it seems reasonable that AIM support for gaim, naim, etc. should also be moved to contrib. Michael Poole
Re: LCC and blobs
Thomas Bushnell BSG writes: > Matthew Garrett <[EMAIL PROTECTED]> writes: > > > > Think of it this way. For the card with the built-in firmware, the > > > driver does not depend on any additional packages or software > > > distribution to work. By contrast, for the card with the separate > > > firmware, the driver *does* depend on that additional package to work. > > > > The dependency still exists - it just isn't expressed within the terms > > of our package management system. I am entirely happy to describe this > > distinction as arbitrary. > > And yet, in this case the non-freeness of the software isn't hurting > the user. The point isn't whether the firmware "exists", the point is > whether the user is being prevented from modifying it by licensing or > non-source-distribution restrictions. When the firmware is burned into the device, the user is prevented from modifying it in a rather more drastic and permanent fashion than when the restrictions are a matter of missing code or permissions. Michael Poole
Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1
On Fri, Dec 10, 2004 at 07:04:57AM -0800, Steve Langasek wrote: > On Fri, Dec 10, 2004 at 02:45:17PM +0100, Michael Banck wrote: > > One could argue about sending the NMU-patch/interdiff to the BTS, but I > > personally do not see much point in it, since (hi Omnic!) you can just > > get it from the archive and sync it yourself. It still makes sense for > > packages where you suspect the maintainer to be inactive/not willing to > > deal with this or (as is the case here apparently) already working on a > > new revision. > > I don't see how this should be a point of contention at all; the requirement > that diffs from NMUs be posted to the BTS has been explicit for a very long > time. It is the responsibility of the NMUer to ensure that the diffs are > delivered to the maintainer for inspection via the BTS. Yeah, you're right, there's nothing to argue about here. I was trying to state my personal POV, but (i) that's irrelevant and (ii) I was not clear on the general case. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: If you really want Free firmware...
Chasecreek Systemhouse writes: > > To design software, all you need is a fully functional computer. > > > > To design hardware, you need to create and test a prototype every once > > in a while. That'll cost you. > > > Your logic doesnt follow. > Why, then, isn't Be (BeOS) still around ? > > Plenty of fully functional computers around at the time -- and Yes, I > know Steve Jobs killed off the Apple clone market. But the problem > was Be could not switch architectures fast enough to survive. > > > True point revealed: functional hardware doesnt go very far without > functional Software. That is an entirely different point. Creating "complex" functional hardware (for a definition of "complex" that changes over time, as proto boards and cheap FGPAs become more capable) is much more expensive than creating software of comparably "complex" functionality. Tooling up for an ASIC production run using current processes costs tens or hundreds of thousands of dollars -- even if you assume the design is bug-free and there is zero cost until the design has taped out. That is a generous assumption given the absense of free software to perform many pre-tape-out steps and the dependence of that design file on a particular ASIC vendor's cell library. Those tens or hundreds of thousands have to be spent by everyone who wants to actually build the chip. If you just need to do a circuit board design, depending on number of layers and other details, ignoring per-unit costs and again assuming zero design costs, you might get off with paying thousands to low tens of thousands of dollars for a production run. Hardware design has very different and higher third-party costs than software design, and the cost to make and test minor revisions can be a significant fraction of the cost to do the initial build. As long as that is true, free hardware is not possible on the same scale as free software or with many of its benefits. Michael Poole
Re: If you really want Free firmware...
Chasecreek Systemhouse writes: > On 14 Dec 2004 09:03:20 -0500, Michael Poole <[EMAIL PROTECTED]> wrote: > > > Hardware design has very different and higher third-party costs than > > software design, and the cost to make and test minor revisions can be > > a significant fraction of the cost to do the initial build. As long > > as that is true, free hardware is not possible on the same scale as > > free software or with many of its benefits. > > Those costs exist mainly, IMHO, because the general public doesn't > have wide spread manufacturing like Linux developers do with regard to > software development. Well, yeah. Have you priced out a quarter micron fab lately or looked at price lists for multi-layer PCB manufacturing equipment? The general public doesn't have widespread electronics manufacturing because the up-front and operating costs are both orders of magnitude above what you need for software, and because (again) a minor tweak of hardware involves disproportionately more cost than a minor tweak of software. > Personally I'm not buying it. Hardware costs what it does for the > same reasons as software -- to advance the state of the art and to > create better hardware (or software as the case may be.) I have been on the design teams for an ASIC and a full system that required custom PCI boards. I have a reasonably accurate idea about the manufacturing costs for hardware, and those costs are all my email talked about. I ignored the design and testing costs, since free software has shown that you can amortize them across users. The manufacturing and distribution cost for software, on the other hand, can be effectively driven to zero. When the cost to produce an existing third-party design (making no changes) is five or six figures, there is not much reason to freely license whole designs. That cost is not your own labor: it is what you need to pay the companies who own fabs or PCB mills to build your design. The economics demand added value. That is why opencores.org deals with logic cores and proto boards rather than retail products. Michael Poole
Re: Linux Core Consortium
On Tue, Dec 14, 2004 at 06:16:03AM -0800, Steve Langasek wrote: > That wasn't my question. My question was, why should any ISV care if > their product has been LSB-*certified*? ISVs can test against, and > advertise support for, whatever they want to without getting the LSB's > imprimatur. I cannot fathom why any ISV would go through the expense (money > or time) of getting some sort of LSB certification instead of simply making > this part of their in-house product QA; and therefore I don't see how the > absence of LSB-certified applications can be regarded as a failure of the > LSB process. I don't think we are talking about ISVs paying to get LSB certification but about ISVs certifying their own applications for a certain LSB level, aren't we? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: Linux Core Consortium
On Fri, Dec 10, 2004 at 04:04:22PM +0100, Bill Allombert wrote: > It seems to me than one of the main value of Debian is in the quality of > its core distribution. One of the reason of the quality is that it > is not developed for itself but as a platform for the 10^4+ packages > and the 10+ architectures in Debian. For example the compiler must be > ... > Given that, an attempt to develop the core distribution as a separate > entity is going to be impractical and to reduce its quality. Why? In fact you are proving your own argument wrong. If a seperate core distribution is developed as a core of more, let alone all, Linux distributions including Debian, the amount of packages using it as platform will certainly increase. > On the other hand, nothing bars the LCC to build a distribution on top of > Debian. There is a lot of precedent for doing so (Xandros,libranet, > lycoris, linspire, mepis, etc.). This is one argument why I'd say, we surely should work with LCC. > As a practical matter, what if the Debian gcc team decide to release > etch with gcc 3.3 because 3.4 break ABI on some platforms and gcc-4.x is > not stable enough on all the platforms ? Will LCC follow ? If not, how > are we going to share binary package if we do not use the same compiler? Another reason why we should work together as the problem will arise with the other dists anyway. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: Linux Core Consortium
On Sat, Dec 11, 2004 at 12:22:13PM +0100, Florian Weimer wrote: > I don't think Debian should try to adopt an extensive, externally > specified ABI. For a few core packges, this may make some sense, but > not for most libraries. Lcc is also about those few core packages. > Instead, proprietary software vendors should ship all libraries in the > versions they need, or link their software statically. I wouldn't >From a technical standpoint this may make sense, but not from the commercial standpoint ISVs have to take. Building your own environment to work on all distros is certainly much more work than just certifying for the one distribution you use in your development labs anyway. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: Linux Core Consortium
On Fri, Dec 10, 2004 at 12:44:05AM +0100, Christoph Hellwig wrote: > In fact I'm using Debian exactly because it doesn't try to apeal ISVs, > IHVs, OEMs and other business-driven three-letter acronyms. As soon > as you ty to please them quality of implementation goes down. Why? It took me some time to read all those mails, in particular because some new threads were created in reply to this one creating a giant thread in my mutt view. :-) Anyway, I did not find any mention of Ian asking Debian to lose anything. His question was if we are interested in participating. So this certainly does not lower our quality of implementation. Also there was talk about ADDITONAL packages replacing those base packages that need to be changed. No one is forced to use them the way I understand things. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Bug#285773: ITP: smartpm -- A alternative package manager that works with dpkg/rpm
Package: wnpp Version: N/A; reported 2004-12-15 Severity: wishlist * Package name: smartpm Version : 0.28 Upstream Author : Gustavo Niemeyer <[EMAIL PROTECTED]> * URL : http://linux-br.conectiva.com.br/~niemeyer/smart/files/ * License : GPL Description : A alternative package manager that works with dpkg/rpm The Smart Package Manager project has the ambitious objective of creating smart and portable algorithms for solving adequately the problem of managing software upgrading and installation. This tool works in all major distributions, and will bring notable advantages over native tools currently in use (APT, APT-RPM, YUM, URPMI, etc). . This project is in beta testing. Please, understand that bugs are expected to be found at that stage, and there are features that still must be implemented in the forthcoming future. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux gluck 2.4.28-es #1 SMP Sun Nov 21 19:05:12 EST 2004 i686 Locale: LANG=C, LC_CTYPE=C
Re: LCC and blobs
Raul Miller writes: > On Wed, Jan 05, 2005 at 10:16:25AM +0100, Tollef Fog Heen wrote: > > However, if somebody writes a graphviz-client which just pushes the > > dot file over the network to graphviz.example.com on some port and > > gets a postscript file back, it can go into main. No matter what > > software said server is running. Correct? > > In essence, yes. > > Do you have a problem netcat being in main? That is a disingenuous comparison. netcat is to network data as hex editors are to file data. The suggested graphviz-client is very different. Michael Poole
Re: ndiswrapper should be in contrib
Rene Engelhard writes: > Package: ndiswrapper > Severity: serious > Tags: sarge, sid > > Hi, > > Christoph Hellwig wrote: > > On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote: > > > Apparently the dickhead maintainer of ndiswrapper-source has just gone > > > into his shell and refuses to discuss this problem. > > > > Btw, could anyone explain why ndiswrapper is in main? It's only use > > is to run propritary windows drivers inside the linux kernel, so it's > > a clear fit for contrib. > > ACK. To play devil's advocate: Why is wine in main? Its only use is to run proprietary windows programs inside the WINE environment, so it's a clear fit for contrib. The main page of the NdisWrapper project has a link to a GPLed NDIS driver, so it seems like the main reason to remove ndiswrapper from Debian is spite. Michael Poole
Re: ndiswrapper should be in contrib
Matt Kraai writes: > On Thu, Jan 06, 2005 at 06:53:40PM -0500, Michael Poole wrote: > > To play devil's advocate: Why is wine in main? Its only use is to run > > proprietary windows programs inside the WINE environment, so it's a > > clear fit for contrib. > > No, there is free software for Microsoft Windows. See, for instance, > the GNU Emacs port. Likewise, there are free NDIS drivers for Microsoft Windows. I mentioned one the other paragraph of my email. Michael Poole
Re: New version of ipsec-tools
Hi Ganesan, [EMAIL PROTECTED] wrote: Hi, I have taken over as maintainer of ipsec-tools. I'll be soon uploading ipsec-tools 0.5rc2 to unstable, skipping version 0.4 (0.3.3 is the latest version in Debian). I would really like to get 0.5 into sarge because there have been many enhancements to ipsec-tools (for e.g. NAT-T support, Dead Peer Detection, support for PlainRSA keys for easy migration from FreeSWAN, Hybrid authentication). This is also the first release that supports Linux kernel versions 2.6.10 and above (FWD policy support). Does it have the fixes for the incorrect isakmp source address when using the listen directive and also the HUP fix when using the listen directive? These make the listen directive work and useful :) Patches on both these bugs: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289604 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241980 Both are quite straightforward and are needed to allow a floating ipsec gateway address (for firewall failover config with heartbeat). If they're in there i'll test the packages for you. ~mc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-src cannot build
On Thu, Feb 17, 2005 at 03:09:41PM +0200, Marcus Sundman wrote: > On Thursday 17 February 2005 13:18, Bartosz Fenski aka fEnIo wrote: > > On Thu, Feb 17, 2005 at 06:19:59AM +0200, Marcus Sundman wrote: > > > I do the following (irrelevant output omitted): > > > 8< > > > /usr/src/tmp$ apt-src install foo > > > /usr/src/tmp$ cd foo-version > > > /usr/src/tmp/foo-version$ apt-src build foo > > > E: Not installed > > > /usr/src/tmp/foo-version$ > > > >8 > > > > > > Any idea what might be wrong? > > > > You don't have to enter to foo-version directory. > > Anyway it should work even with that... both ways works for me. > > I tried that, too, but it still just says "E: Not installed". > > What's "E" and what's not installed? (This must be one of the least helpful > error messages I've ever seen.) E means "error". Are you sure all build dependencies are installed ? apt-get build-dep foo Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
remove
Remove me from the list or explain how! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tips wanted for debugging and testing Debian
Hi! [...] If you want to take this one step further, actually trying to crash an application in a reproducible way, or trying to narrow down a bug to a specific set of actions can be really helpful as well; for instance, if there's a bug that says something like 'If I run this application, it sometimes segfaults when I close it', and you can narrow it down to 'if you run it, and use this and this and that option and /then/ close it, it will segfault', that's very nice. You can browse our bug database at <http://bugs.debian.org/>. A good way to start is to search for any bugs in software you regularly use, and to see if you can help out. But what could one do, if the maintainer doesn't react (for some time) - such that even bugreport with fixes provided are never acted upon? Thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tips wanted for debugging and testing Debian
If a bug is serious, and not a trivial thing, and if a patch has been filed then a NMU could be applied. But only a Debian developer can do so, right? When saying "trivial" - did you mean easy to fix or the priority of a bug (i.e., wishlist)? [...] Thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tips wanted for debugging and testing Debian
Usually, but I've sponsored NMU uploads by non-DDs before. Sounds interesting - how does that work? When saying "trivial" - did you mean easy to fix or the priority of a bug (i.e., wishlist)? I mean it should be a serious bug which is affecting real people but has gone unadressed. Not something like adding a new feature which was filed as a wishlist. It's a judgement which people may make differently. That seems sensible to me too. I might get flamed, but I'd like to mention just one example - the a2ps-package. Some of the bugs might be really easy to fixed (patches are attached) - but have not even been acknowledged by the developer. So - is there anything I could do to help? Thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297629: ITP: gallery2 -- web-based photo album written in PHP
Package: wnpp Severity: wishlist Owner: Michael Schultheiss <[EMAIL PROTECTED]> * Package name: gallery2 Version : 2.0-alpha-4 * URL : http://gallery.sf.net * License : GPL Description : web-based photo album written in PHP Gallery2 is a web-based photo album with multiple user support. It provides users with the ability to create and maintain their own albums via an intuitive web interface. Photo management includes automatic thumbnail creation, image resizing, rotation, ordering, captioning, searching and more. Albums can have read, write and caption permissions per individual authenticated user for an additional level of privacy. Gallery2 (G2) has been redesigned from the ground up and is database driven. Two years of design and development have gone into G2. It has customizable themes and layouts using XHTML compliant templates which make it much easier for you to personalize your G2 install. G2 is modularized and features can be enabled and disabled separately for maximum control. The upstream web site is: http://gallery.sf.net -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.26-1-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NoX idea
On Tue, Mar 01, 2005 at 11:36:46PM +0100, Jesus Climent wrote: > What would people think about adding a check on all the *dm managers (read > kdm, gdm and friends) about cheking the kernel command line from /proc/cmdline > and grep for nox? > > I have the need some times to start a laptop with console mode, and it would > be nice to just add an append to the kernel command line to stop it from > running... > > Any comments? Why dont you just utilise the runlevels ? runlevel 2 without *dm, 3 with *dm. That is what I do all the time. Pretty easy to do. In Grub I just tell to start runlevel 2 or 3. Michael -- Java Trap: http://www.gnu.org/philosophy/java-trap.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#297629: ITP: gallery2 -- web-based photo album written in PHP
Lars Wirzenius wrote: > ti, 2005-03-01 kello 16:46 -0500, Michael Schultheiss kirjoitti: > > Gallery2 (G2) has been redesigned from the ground up and is database > > driven. Two years of design and development have gone into G2. It has > > customizable themes and layouts using XHTML compliant templates which > > make it much easier for you to personalize your G2 install. G2 is > > modularized and features can be enabled and disabled separately for > > maximum control. > > Is there any way to let people upgrade to Gallery2 from the original > Gallery? If so, then we could do without having two packages in the > archive and our users wouldn't have to have both installed, either. There are upgrade paths from G1 to G2 but G2 is currently in alpha, soon to be beta. I wouldn't want to replace the current G1 package with G2 until G2 goes golden. -- Michael Schultheiss E-mail: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NoX idea
On Tue, Mar 01, 2005 at 09:06:41PM -0300, Gustavo Noronha Silva wrote: > Em Ter, 2005-03-01 às 23:36 +0100, Jesus Climent escreveu: > > What would people think about adding a check on all the *dm managers (read > > kdm, gdm and friends) about cheking the kernel command line from > > /proc/cmdline > > and grep for nox? > > > > I have the need some times to start a laptop with console mode, and it would > > be nice to just add an append to the kernel command line to stop it from > > running... > > > > Any comments? > > I like the idea. I sometimes miss an easy way to say "don't start X", > too, although most times I do want it to run. is "rm /etc/rc2.d/S99gdm" not easy enough for you ? Michael -- Java Trap: http://www.gnu.org/philosophy/java-trap.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NoX idea
On Wed, Mar 02, 2005 at 02:45:26PM +0100, Christoph Berg wrote: > Re: Michael Koch in <[EMAIL PROTECTED]> > > is "rm /etc/rc2.d/S99gdm" not easy enough for you ? > > Please don't recommend rm'ing the S* links. Rename them to K* instead > or else they will be recreated on the next upgrade. Read the policy. They will only be created when *ALL* runlevel links are deleted. Michael -- Java Trap: http://www.gnu.org/philosophy/java-trap.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NoX idea
On Fri, Mar 04, 2005 at 09:04:21AM +0100, Benjamin Mesing wrote: > > > Well, my point was to have a common predefined way of doing it: once you > > install kdm (or someone else), or move to xdm or whatever, you still can > > disable the start of X by putting nox in the command line, instead of having > > to erase the links in rc2.d. > Acutally there should be no link in runlevel 2 to start a *dm because > runlevel 2 is for console only mode. Thats not true. Read the Debian Policy. Its just that some other distributions use runlevel 2 for console mode. In Debian thats all up to the user/administrator of the system. Of course we can change this but its not true currently. Michael -- Java Trap: http://www.gnu.org/philosophy/java-trap.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: combining fakeroot and distcc/SSH
also sprach Goswin von Brederlow <[EMAIL PROTECTED]> [2005.03.05.1840 +0100]: ssh -i usualy helps. not if you cannot influence how SSH is called. Actually I don't really know, but maybe the environment-variable DISTCC_SSH could be helpful. Regards, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299242: ITP: ha-prosper -- improved LaTeX class for writing transparencies
Package: wnpp Severity: wishlist Owner: Michael Prokop <[EMAIL PROTECTED]> * Package name: ha-prosper Version : 4.21 Upstream Author : Hendri Adriaens <[EMAIL PROTECTED]> * URL : http://stuwww.uvt.nl/~hendri/Downloads/haprosper.html * License : LaTeX Project Public License Description : improved LaTeX class for writing transparencies The HA-prosper package for LaTeX provides a way to make nice looking slides using LaTeX. This gives you the opportunity to copy and paste formulas from your papers directly into the presentation. The package has been based on the prosper class but offers a lot of new possibilities and some bug fixes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#299242: ITP: ha-prosper -- improved LaTeX class for writing transparencies
* Josselin Mouette <[EMAIL PROTECTED]> [20050313 00:37]: > Le samedi 12 mars 2005 à 23:44 +0100, Michael Prokop a écrit : > > * Package name: ha-prosper > > Version : 4.21 > > Upstream Author : Hendri Adriaens <[EMAIL PROTECTED]> > > * URL : http://stuwww.uvt.nl/~hendri/Downloads/haprosper.html > > * License : LaTeX Project Public License > > Description : improved LaTeX class for writing transparencies > > The HA-prosper package for LaTeX provides a way to make nice > > looking slides using LaTeX. This gives you the opportunity to > > copy and paste formulas from your papers directly into the > > presentation. The package has been based on the prosper class > > but offers a lot of new possibilities and some bug fixes. > Is it compatible with prosper? If it is, maybe it would be better to > simply replace the prosper package with this version. | This is the last release of the package HA-prosper. All future | developments in the line of this package will be collected in a new | class called TeXciting. The reason that this package will be | converted into a class is that some ideas for improvements (like A4 | paper support) can only be realized when stepping away from prosper. | The conversion will take some time and any bugs in HA-prosper will | be dealt with in the meantime. Changes necessary for presentations | to step from HA-prosper to TeXciting will be kept to a minimum. -- http://stuwww.uvt.nl/~hendri/Downloads/haprosper.html I think replacing the prosper-package with ha-prosper wouldn't be a good choice. I'd like to provide ha-prosper in a separate package so when TeXciting is available there aren't any breakages with prosper. regards, -mika- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299257: ITP: xkeyval -- extension of the keyval package
Package: wnpp Severity: wishlist Owner: Michael Prokop <[EMAIL PROTECTED]> * Package name: xkeyval Version : 2.3 Upstream Author : Hendri Adriaens <[EMAIL PROTECTED]> * URL : http://stuwww.uvt.nl/~hendri/Downloads/xkeyval.html * License : LaTeX Project Public License Description : extension of the keyval package This package is an extension of the keyval package by David Carlisle and offers additional macros for setting keys and declaring and setting class or package options. This distribution also includes the pst-xkey package which is a specialization of the xkeyval package for PSTricks packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#299242: ITP: ha-prosper -- improved LaTeX class for writing transparencies
* Andreas Tille <[EMAIL PROTECTED]> [20050313 18:15]: > On Sun, 13 Mar 2005, Michael Prokop wrote: > > I think replacing the prosper-package with ha-prosper wouldn't be > > a good choice. I'd like to provide ha-prosper in a separate > > package > > so when TeXciting is available there aren't any breakages with > > prosper. > Recently I investigated some time in LaTeX based presentation tools. > The consequence was: > 1. Prosper is nice but development tsopped since about 3 years. > 2. HA-prosper was kind of continuing the work of prosper. It is >more enhanced and I even builded some packages for my private >use of it until I noticed latex-beamer (see below). My impression >was that while it is superior about prosper and should prosper >replace regarding to this fact it is not really worth packaging >because development is stalled as well because of the new >TeXciting project. > 3. LaTeX-Beamer has compatibility modes for prosper and ha-prosper. >It is much more feature complete and flexible than both above. >There is absolutely no reson to investigate time into any >*prosper package because LaTeX-Beamer is the package your >really want. For an example see > http://people.debian.org/~tille/talks/200503_peking_cdd/index_en.html >I do not know anything about TeXciting and thus I can not compare >but before crowding the archive with a package like ha-prosper >try LaTeX-Beamer. I do know many people who are used to ha-prosper and haven't switched to LaTeX-Beamer yet. ha-prosper needs less space than latex-beamer (not taking care of dependencies but ratio should be equalent): [EMAIL PROTECTED] ~ # apt-cache show ha-prosper | grep Installed-Size Installed-Size: 516 [EMAIL PROTECTED] ~ # apt-cache show latex-beamer | grep Installed-Size Installed-Size: 3364 [EMAIL PROTECTED] ~ # And TeXciting might never be released, quoting Hendri - the author of ha-prosper: | I have reconsidered whether it will be possible | to finish this project. Taking into account also | the work that I'm doing on other packages and | my involvement in LaTeX3, I conclude that it will | unfortunately be very unlikely, that I will ever | finish that project. See his posting on ha-prosper-mailinglist for more details: http://listserv.surfnet.nl/scripts/wa.exe?A2=ind0503&L=ha-prosper&F=&S=&P=777 So in my opinion it would be useful to provide a debian package of ha-prosper. regards, -mika- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On 2005-03-15, Julien BLACHE <[EMAIL PROTECTED]> wrote: > > Matt Zimmerman <[EMAIL PROTECTED]> wrote: > >>> How could we know ? We know nothing about Ubuntu, nothing about >>> Canonical, nothing about the goals, nothing about how everything was >>> done to begin with, nothing about who works or doesn't work there. >> >> Details about Ubuntu and its goals can be found on the website. In many >> respects there is more information available about Ubuntu activity, and the >> goals of the project, than about organizations which provide you with the >> essentials of life. Yet, you seem to trust them by default, while you >> assume that Ubuntu seeks to cause you harm. Why? > > Because Ubuntu appeared behind a screen of smoke. And smoke hasn't > dissipated yet. Debian Developers were not informed in an appropriate > manner of what was going on there. Sorry, but i can't see the problem here. Everyone can go ahead and do a value-added Distribution based on Debian. There is no need be verbose about it, though. Also, i dont think the Debian Developers working for Ubuntu have to justify why they are doing so. > By destroying the Project ? Interesting approach. As this is just a _proposal_, you are free to suggest alternative approaches on how to solve the Problems the Project is currently facing. bye, - michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299713: ITP: cvsfs -- Translator for transparent access to cvs repositories
Package: wnpp Severity: wishlist * Package name: cvsfs Version : 0.1 Upstream Author : Stefan Siegl <[EMAIL PROTECTED]> * URL : http://cvsfs4hurd.berlios.de/cvsfs.html * License : GPL Description : Translator for transparent access to CVS repositories cvsfs is a Hurd translator providing transparent (read-only for now) access to CVS repositories by virtualizing the remote repository in the local file system. Once translated, the user can browse around in directories and view file contents by the means of standard GNU tools. Contrary to a usual cvs checkout, cvsfs only transmits the necessary data and not the whole source tree. This is somewhat similar to the cvsfs (http://cvsfs.sourceforge.net/) project for Linux using FUSE, modulo the usual differences. The binary package name is yet to be decided, pending a Hurd translator naming convention decision. enjoy, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#299713: ITP: cvsfs -- Translator for transparent access to cvs repositories
On Tue, 15 Mar 2005 20:57:45 -0500, Glenn Maynard wrote: > > Once translated, the user can browse around in directories and view > > file contents by the means of standard GNU tools. > By my vague (secondhand) understanding of Hurd translators, it shows up > as a regular filesystem tree--so any tools can be used, not just GNU > tools. s/GNU //? Indeed. (I think I was going to write 'Unix' there first, but then changed that to 'GNU' for some reason) I works with all kind of tools, including graphical file managers, though the documentation talks about performance problems in that case, as they are stat-ing all files in a directory. There is an option to force stating off, though. cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Source of LPhoto
hi Andreas, On 2005-03-17, Andreas Tille <[EMAIL PROTECTED]> wrote: > But there is no link or other sign of a downloadable source. > > Am I to stupid to find the source or do the people at this site have a > different opinion about downloadable source than I. I wanted to issue an > ITP if it is worth but wonder which link to the source I should use. I couldnt find any link, but the .changes file in their archive, so: http://software.linspire.com/emptypool//lindowsos/pool/main/l/lphoto/lphoto_2.0.42-0.0.0.45.lindows0.1.tar.gz bye - michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OASIS -- Our Membership and their IP Policy?
rs, has somehow managed to produce standards
(RFCs) without requiring any membership dues -- in fact without having
any permanent "membership" -- or without much infrastructure at all.
Interested people just get together, come up with draft standards, and
send them out for review an comment by anybody who cares to take the
time to read and comment on them. Real standards, with implementations.
And there are few stamps of approval (in my world at least) that carry
more weight than being able to say that something is "RFC compliant".
Also, consider the fact the membership in OASIS cannnot, practically,
be called "open" at all. The US$250 annual membership fee -- as
inexpensive as it may seem relative to what, say, the W3C charges for
membership -- is prohibitively expensive for many individuals and
organizations. Especially for individuals in non-rich countries (that
is, most of the world).
Participation in development of open standards should not require
financial contributions to some standards body. Standards should be
driven by the people who have the most interest and enthusiasm and
investment in time in them (like the IETF). If there are any additional
criteria involvement, it should just be based on demonstrated knowledge
and skills (as with the process for becoming a Debian developer).
If we don't currently have organizations that let us participate and
help develop standards that wey, maybe it's time we started creating
them.
--Mike
> {1} http://perens.com/Articles/OASIS.html
> >
> > Claire
> >
> >[1] http://lwn.net/Articles/124548/
> >
> >[2] Lawrence Rosen, Bruce Perens, Richard Stallman, Lawrence
> >Lessig, Eben Moglen, Marten Mickos, John Weathersby, John
> >Terpstra, Tim O'Reilly, Tony Stanco, Don Marti, Michael
> >Tiemann, Andrew Aitken, Karen Copenhaver, Doug Levin, Dan
> >Ravicher, Larry Augustin, Mitchell Kapor, Russell Nelson,
> >Guido van Rossum, Daniel Quinlan, Murugan Pal, Stuart Cohen,
> >Danese Cooper, Eric Raymond, Mark Webbink, Ken Coar, Doc
> >Searls, Brian Behlendorf.
> >
--
Michael Smith
http://logopoeia.com/ http://www.oreillynet.com/pub/au/890
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libvorbis and vorbis-tools
hi,
On 2005-11-13, Elimar Riesebieter <[EMAIL PROTECTED]> wrote:
> is Christopher L Cheeney submerged? There are new upstreamversions
> of libvorbis and vorbis-tools available which fix a lot.
Adeodato Simó is looking into this (#339846).
bye,
- michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with dependencies/conflics on third party packages
On Sun, Nov 20, 2005 at 10:23:58AM +, Joerg Sommer wrote: > Hi, > > I've got a bug report (#336527) my package bootchart-view do not work > with j2re1.3. But j2re1.3 is not in Debian. Can I set a conflict upon a > packages that is not in Debian? But if it do not work with j2re1.3 it > should more than ever not work with older version. But I would assume > older version have different packages names. So I must add a list of > packages names (j2re1.3 j2re1.2 j2re1.1), because I can not use the > version clause (j2re1.3 (<< 1.3)). So what should I do? Dont use a Conflicts: as this would deinstall j2re1.3 from the system. The correct solution would be to check the version in your binary and fail if the java version is too old. BTW: the Debian Java Maintainers group is thinking about a more general solution of this problem. Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Wed, Nov 23, 2005 at 03:50:11PM +0100, Goswin von Brederlow wrote: > If you NEED to do a manual binNMU it is probably best to use sbuild > (the cvs, not deb) Patches for the Debian package are welcome, of course. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Thu, Nov 24, 2005 at 11:02:36AM +, Roger Leigh wrote: > Goswin von Brederlow <[EMAIL PROTECTED]> writes: > > > If you NEED to do a manual binNMU it is probably best to use sbuild > > (the cvs, not deb) > > Which sbuild CVS repo? It is a SVN repo now, the one used by the buildd infrastructure. > BTW, are there any good reasons why the autobuilders don't use the > packaged version anywat? The differences are minimal. Last time I looked the changes seemed to be pretty big, but merging is of course a mid-term goal. In any case, the Debian package is the fork, while the sbuild in wanna-build is upstream. As I understand it, we do not plan to use the Debian sbuild package for the buildds, the upstream one works well enough (and currently much better for what the buildds need) Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Thu, Nov 24, 2005 at 06:44:42PM +0100, Goswin von Brederlow wrote: > Michael Banck <[EMAIL PROTECTED]> writes: > > On Wed, Nov 23, 2005 at 03:50:11PM +0100, Goswin von Brederlow wrote: > >> If you NEED to do a manual binNMU it is probably best to use sbuild > >> (the cvs, not deb) > > > > Patches for the Debian package are welcome, of course. > > > > Michael > > Do you know about > > http://svn.cyberhqz.com/svn/wanna-build/ Was that a question? I stated in the mail you replied to that wanna-build is now maintained in svn. Still, I don't have time to look at it myself right now, so if somebody wants to send a patch, fine, otherwise, we will get to it eventually. Unless the release team and/or ftp-masters think this kind of new binNMU style should be restricted to the buildds (does the old style still work?). Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Thu, Nov 24, 2005 at 06:51:24PM +0100, Goswin von Brederlow wrote: > Wouter Verhelst <[EMAIL PROTECTED]> writes: > > They were, originally. Ryan's been very active on it since, and it's > > diverged a bit from the code you're maintaining. > > Then he should send patches and bug reports to the debian > package. When the sbuild package got orphaned two years ago or so, I asked Ryan whether he would like to maintain it, and he said he was not interested. Which is totally fine for me and about everybody else. > This split between the user/developer visible sbuild and the secret > actual buildd is just not in the spirit of Debian. 1. Please drop the `secret' immediately. Unless you really want to call http://www.debian.org/devel/buildd `secret'. That your mail got resent with the this subject to debian-devel-announce is already stressing it *a lot*, IMHO. 2. I do not see why this should be against the spirit of Debian. As I stated already, the sbuild package was always a fork intended to be more usuable by humans, whereas the real sbuild is optimized for the buildds. > > I personally see the packages in unstable as something good for > > end-users who want to use it, or understand how the system works; but > > for Debian's purposes, it's not optimal. > > So non "cabal" members should look at a different sbuild and then > magically figure out where and how the secret one differs? What is the > point in looking at sbuild if it isn't THE sbuild? The point of looking at the sbuild package is to have a convenient tool for people to build their packages in a chroot, similar to pbuilder. Nothing more, nothing less. Please keep your cabalistic tendencies to yourself, or at least off this mailing list. > Last year the aim was to get the buildd sbuild and debian sbuild back > in sync and it pains me to see Ryan silently diferting it further and > further instead of aiding that goal. Again: It is the sbuild's packages maintainers duty to sync with upstream, not the other way round, and we've been slacking (again, patches welcome). You seem to look at this from the wrong side of the fork. If somebody wants to package wanna-build, buildd and the accompayning sbuild, they shall be my guest; but I believe the packages provided at db.debian.org are easy enough to setup (as has been shown numerous times now), and I will not engage in that undertaking. If that happens, we can discuss how packages should be named, and whether the current sbuild package should be renamed. Until then, less drama would be welcome. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Fri, Nov 25, 2005 at 02:38:32PM +0100, Goswin von Brederlow wrote: > Michael Banck <[EMAIL PROTECTED]> writes: > > On Thu, Nov 24, 2005 at 06:51:24PM +0100, Goswin von Brederlow wrote: > >> Wouter Verhelst <[EMAIL PROTECTED]> writes: > >> > They were, originally. Ryan's been very active on it since, and it's > >> > diverged a bit from the code you're maintaining. > >> > >> Then he should send patches and bug reports to the debian > >> package. > > > > When the sbuild package got orphaned two years ago or so, I asked Ryan > > whether he would like to maintain it, and he said he was not interested. > > Which is totally fine for me and about everybody else. > > > >> This split between the user/developer visible sbuild and the secret > >> actual buildd is just not in the spirit of Debian. > > > > 1. Please drop the `secret' immediately. Unless you really want to call > > http://www.debian.org/devel/buildd `secret'. That your mail got resent > > with the this subject to debian-devel-announce is already stressing it > > *a lot*, IMHO. > > The subject and initial mail is not about sbuild being secret but > about the overall change for Debian. I think that one is > justified. Nothing to do with this subthread. Right, these are two different things. However, the binNMU change is mostly/only useful for the release managers and buildd admins, so I fail to see why not having documented/announced it less than a week after its implementation should imply it was done in `secret', as those people are busy with the next library transition. To make this clear, I totally welcome your post documenting the new binNMU features while the authors have been too busy to do so for now. And the existance of the wanna-build/buildd/sbuild packages is not a secret, either. > As for http://www.debian.org/devel/buildd: > > $ grep sbuild http://www.debian.org/devel/buildd > wanna-build and calls sbuild to build the packages. > http://packages.debian.org/sbuild";>sbuild > > This nice public page only points to the nice public sbuild debian > package. There is no link to the actual sbuild used on buildds. > > Further the links for wanna-build and buildd (which probably > indirectly included sbuild) are broken: > > http://m68k.debian.org/buildd/getting.html --> connection refused The documentation should get fixed, then. > Did you by chance mean the wanna-build svn link on > http://buildd.debian.org/? So it is documented there as well, good. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package name changes in atlas-cpp (was Re: library renaming due to changed libstdc++ configuration)
On Wed, Nov 30, 2005 at 08:08:15PM +0100, Stephan Hermann wrote: > Well, I will try to revert the change, no problem. But even for > libatlas-cpp-0.6 there was a soname change (if you see this bugreport about > the rename of libatlas-cpp-0.5) and there was no need to rename > libatlas-cpp-0.6 because the soname change was introduced by a new upstream > source. > > When I got the merge report into my hands for libatlas-cpp-0.6, there was no > renaming in rev 1, so I had to add c2a as soname change. I just saw too late, > that there was a rev 2 of this package, and in this rev a renaming was made. > > At the time of the merge, I was right. There is now a difference between > ubuntu and debian. I'm sorry for that, but I don't change it right now. If > there is a new upstream of atlas-cpp, we can try to bring the two packages > again in sync. Sorry for the trouble I made. My fault to not correctly reread the transition mail again before doing the actual transition of atlas-cpp. It's clearly my bug. What shall I do now? Rename the binary packages again? Wait for a new upstream version (0.6.0) which changes the SONAME again? 0.6.0rc2 is already out. Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package name changes in atlas-cpp (was Re: library renaming due to changed libstdc++ configuration)
On Wed, Nov 30, 2005 at 09:10:58PM +0100, Stephan Hermann wrote: > Hi Michael, > > On Wednesday 30 November 2005 22:00, Michael Koch wrote: > > On Wed, Nov 30, 2005 at 08:08:15PM +0100, Stephan Hermann wrote: > > > Well, I will try to revert the change, no problem. But even for > > > libatlas-cpp-0.6 there was a soname change (if you see this bugreport > > > about the rename of libatlas-cpp-0.5) and there was no need to rename > > > libatlas-cpp-0.6 because the soname change was introduced by a new > > > upstream source. > > > > > > When I got the merge report into my hands for libatlas-cpp-0.6, there was > > > no renaming in rev 1, so I had to add c2a as soname change. I just saw > > > too late, that there was a rev 2 of this package, and in this rev a > > > renaming was made. > > > > > > At the time of the merge, I was right. There is now a difference between > > > ubuntu and debian. I'm sorry for that, but I don't change it right now. > > > If there is a new upstream of atlas-cpp, we can try to bring the two > > > packages again in sync. > > > > Sorry for the trouble I made. My fault to not correctly reread the > > transition mail again before doing the actual transition of atlas-cpp. > > It's clearly my bug. What shall I do now? Rename the binary packages > > again? Wait for a new upstream version (0.6.0) which changes the SONAME > > again? 0.6.0rc2 is already out. > > Don't worry :) If new 0.6.0 upstream source will change the soname and the > package is named to libatlas-cpp-0.7 then you can just conflicts/replaces to > libatlas-cpp-0.6, libatlas-cpp-0.6c2, libatlas-cpp-0.6c2a, so ubuntu can sync > it directly without any problems. we are then in sync again and avoid any > serious troubles during updates. It will be named libatlas-cpp-0.6-1. Just its interface version is changed. > Actually what you can also do is to follow Matthias Kloses post from > 2005-11-14 about the libstdc++ new allocator transition. You actually need to > rename libatlas-cpp-0.6c2 to c2a so we are in sync as well.. > If you want I can send you an accurate debdiff. > > Any objections? I dont mind what the solution of this problem is finally choosen. My Problem is that I made the same fault with wfmath and cal3d. I would like a vote from a RM about this. Steve ? Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341486: ITP: gnome-chemistry-utils -- GNOME chemistry utility library
Package: wnpp Severity: wishlist Owner: Michael Banck <[EMAIL PROTECTED]> * Package name: gnome-chemistry-utils Version : 0.4.7 Upstream Author : Jean Brefort <[EMAIL PROTECTED]> * URL : http://www.nongnu.org/gchemutils/ * License : GPL Description : GNOME chemistry utility library The Gnome Chemistry Utils provide C++ classes and Gtk+-2 widgets related to chemistry. . Existing widgets are: - a periodic table of the elements (GtkPeriodic) - a crystal structure viewer - a molecular structure viewer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341487: ITP: gchempaint -- Chemical structure editor
Package: wnpp Severity: wishlist Owner: Michael Banck <[EMAIL PROTECTED]> * Package name: gchempaint Version : 0.6.2 Upstream Author : Jean Brefort <[EMAIL PROTECTED]> * URL : http://www.nongnu.org/gchempaint/ * License : GPL Description : Chemical structure editor gchempaint is a 2D chemical strucutre editor for the GNOME desktop. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341915: ITP: mozilla-greasemonkey -- firefox extension which enables customization of webpages with user scripts
Package: wnpp Severity: wishlist Owner: Michael Spang <[EMAIL PROTECTED]> * Package name: mozilla-greasemonkey Version : 0.5.4 Upstream Author : Aaron Boodman * URL : http://greasemonkey.mozdev.org/ * License : No restrictions Description : firefox extension which enables customization of webpages with user scripts Greasemonkey allows Firefox and Seamonkey users to install "user scripts" which run when the user visits any site which the script is enabled for. These scripts can modify the content of the page. A large collection of existing scripts can be found at userscripts.org. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-rc4-git1 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux in a binary world... a doomsday scenario
Aníbal Monsalve Salazar writes: > Should we do something about packages in main that load MS Windows > binary drivers? Are there many of these? If there are (as I suspect) just one or two, would it hurt to name them? How do you evaluate the tradeoff between someone using Debian with a non-Linux binary driver loaded versus that person using some other Linux distribution or some (non-free?) OS? Those questions need to be answered before deciding whether Debian should "do something" about the packages you describe. Michael Poole
Bug#342366: ITP: postgresql-filedump -- Utility to format PostgreSQL files
Package: wnpp Severity: wishlist Owner: Michael Meskes <[EMAIL PROTECTED]> * Package name: postgresql-filedump Version : 8.1 Upstream Author : Patrick Macdonald <[EMAIL PROTECTED]> * URL : http://sources.redhat.com/rhdb/ * License : GPL Description : Utility to format PostgreSQL files This package contains a utility to format PostgreSQL heap/index/control files into a human-readable form. You can format/dump the files several ways. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-rc4-686 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Thu, Dec 08, 2005 at 02:04:28PM +0100, Goswin von Brederlow wrote: > Rescheduling a job that failed with a missing build-depends is the > buildd admins job. Only people with wanna-build access can do that. Correct, and the release managers don't consider this to be a problem at the moment. So nothing to see here, please move along. kthxbye, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Thu, Dec 08, 2005 at 01:01:10PM +0100, Petter Reinholdtsen wrote: > [Josselin Mouette] > > I started my implication in the project four years ago. For four > > years, there have been problems with keyring maintenance and buildd > > administration. For four years, people responsible for these tasks > > have refused help on these matters. For four years, everything that > > was suggested on these topics haven't lead to any result, because > > these same people have simply ignored the suggestions. Can someone > > tell me when this nightmare is going to end? > > Perhaps it is time for a replacement buildd network, and a new > delegation from the DPL for keyring maintenence? Anything else, while we're at it? Maybe you have missed something, so let's reiterate: The main problem of the arm port is *not* the buildd maintenance, but rather the lack of people fixing actual bugs, which is *not* the job of the buildd admin but of the porters. (as Steve pointed out, in some cases those sets overlap, but that just means the buildd guy gets to fix bugs with his porter hat on) I guess nobody says the buildd network does not have any issues, but they wane when compared to the lack of porting. Unfortunately, you do not seem to trust James' opinion on this, but why do you not trust our beloved Release Manager, either, who said he knew of no serious issues with buildd maintenance right now? Now, for the keyring stuff, please post to -project, as this is seems to be off-topic here. thanks, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Thu, Dec 08, 2005 at 04:52:31PM -0500, Nathanael Nerode wrote: > >I also see the keyring's been updated earlier this week, including > >both a replacement key for Horms from late last month, and Chip's > >requested updates. > Indeed, complaining on debian-devel appears to get results, doesn't > it? At least, that's the conclusion that a rational outside observer > would come to. Where should I best complain for your NM application to be cancelled? Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, Dec 09, 2005 at 12:47:59PM -0600, Manoj Srivastava wrote: > On Fri, 9 Dec 2005 16:27:10 +0100, Michael Banck <[EMAIL PROTECTED]> said: > > Where should I best complain for your NM application to be > > cancelled? > > Err, so if a NM candidate speaks as openly as some DD's do, > they get threatened with having their applications cancelled because > of them speaking their minds? "I apologize for publically insulting people; I should have found a better way to deal with their idiocy." -- Nathanael Nerode If he thinks he can resolve issues by flaming people publically on debian-devel, then yes, I think we have different opinions about this project and I would like to voice my concern. Obviously, my voice does not hold any more weight than any other DD's, so I fail to see how this is threatening in any way, unless no other DDs (or his AM) would support him either. That I believe that other DDs should not flame on debian-devel either is somewhat unrelated to this. > What is this, a munich beer hall in 1933? On a historical anecdote, most things in 1933 happenend in Berlin already. Unless you consider how I live in Munich, which makes this comment more appropriate as an ad-hominem attack, I guess. cheers, Michael -- Jeroen: Is that your first big flamewar? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Sat, Dec 10, 2005 at 09:18:28AM +0100, Ingo Juergensmann wrote: > On Sat, Dec 10, 2005 at 08:22:24AM +0100, Bernd Eckenfels wrote: > > BTW: is there a way to get build failures by mail? especially from the > > architectures which are not visible on buildd.debian.org/PTS like hurd and > > bsd. Took me two days to find a build failure, and I guess it would have > > taken weeks before i would get a FTBFS bug report (asuming those are > > manual). > > No, the log receiving addresses are configured in the sbuild/buildd configs. > It's not a per-package config. But you can find a link to the buildd logs of > hurd and such on buildd.net. There are currently no public build logs for hurd-i386, but we are working on getting them published on experimentel.ftbfs.de as well. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian and the desktop (was: Re: Complaint about #debian operator)
(Dropping Josh and moving to -devel, as this is discussion is going elsewhere) On Mon, Dec 12, 2005 at 01:59:05PM +0100, martin f krafft wrote: > However, some users just want a computer that works (the "plain > users"). They don't want to have to learn too much about Linux or > Debian, they just want to get work done. I don't understand why for Etch, if a user chooses "Desktop" during tasksel, they shouldn't get the just works[tm] experience. This might take some effort, and perhaps some more tuning than just a bunch of packages getting installed, but I think there is still time left to make Etch rock on the desktop. Hey, even Sarge seems pretty much good enough for a lot of users already. > Let them use Ubuntu. Ubuntu's excellence shouldn't be an excuse to sit back and not make our Desktop the best possible. cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: c2a transition: libraries still needing transition
On Tue, Dec 20, 2005 at 04:59:46PM -0500, Nathanael Nerode wrote: > The following libraries still need to be uploaded with name changes > for the c2a transition > (http://lists.debian.org/debian-devel-announce/2005/11/msg00010.html): > Most are not in testing at the moment. > > alps-light1 > aqsis > gnuift -- old version is in testing > ivtools -- orphaned, also hadn't undergone c2 transition properly > libsigcx > libterralib > log4cxx > omnievents > plptools > qgis > rlog -- old version is in testing > sqlxx > xalan -- old version is in testing > vtk > zipios++ -- old version is in testing > > The following packages appear to have deliberately skipped the renaming, > so check what's up with debian-release before uploading: > > atlas-cpp This should be fixed now. Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Thu, Jan 05, 2006 at 03:02:05PM -0500, Joey Hess wrote: > Daniel Leidert wrote: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345823 > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891 > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345956 > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346002 > > These are all notable in > > a) being RC > b) not having any response from an apt maintainer Sorry for the delay. I'm preparing a new upload that adds the 2006 archive key to the default keyring. Cheers, Michael P.S. The source for debians apt is maintained with baz (package 'bazaar') at: http://people.debian.org/~mvo/arch/ in the [EMAIL PROTECTED]/apt--debian-sid--0 branch -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 01:26:41AM +0100, Bartosz Fenski aka fEnIo wrote: > On Thu, Jan 05, 2006 at 11:13:06PM +0100, Michael Vogt wrote: > > > These are all notable in > > > > > > a) being RC > > > b) not having any response from an apt maintainer > > > > Sorry for the delay. I'm preparing a new upload that adds the 2006 > > archive key to the default keyring. > > Does it mean we need new version of apt everytime when key changes? Please see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891 for a proposal how the keys can be upgraded in the future. We certainly don't want new apt uploads just for that in the future. Cheers, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 01:22:50AM +0100, Petter Reinholdtsen wrote: > [Michael Vogt] > > Sorry for the delay. I'm preparing a new upload that adds the 2006 > > archive key to the default keyring. > > Sounds good. Will this automatically take care of the key update and > make sure no manual intervention is needed to get packages upgraded? I uploaded a new apt that supports multiple signatures on the release file. The policy is that it needs at least one good signature and no bad signatures (but any number number of NO_PUBKEY signatures) to be considered trusted. It will still warn about missing keys but that's only fatal if no good signature was found. The upload also contains the new key in apts default keyring. This dosn't fix the key-upgrade problem yet. I outlined my proposal in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891 Early testing (from incoming) is welcome :) > Isn't Ubuntu using the signed apt stuff? How are they handling the > new archive keys? Ubuntu handles the archive keys with the mechanism described in #345891. Threre is a "ubuntu-keyring" package that contains the valid and no-longer valid server keys. apt-key update takes care of adding/removing the appropriate keys. Cheers, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
> You do realize that your work is out there for anyone to take and to > modify. I agree that for the modified packages it should be more clear > that the package has been modified by ubuntu and the maintainer or some And why isn't this done? It's so simple to do. I would prefer to know about MY package in ubuntu before some user contacts me. > other field should reflect that. But again, some people are offended if > the maintainer field is changed to something ubuntu specific for the > modified packages. As before it's not an easy task, you get burnt if you > go either way. Wait a moment, just to clarify this, you mean if you take a Debian package change it for Ubuntu and let's say add your name to the maintainer field but also add an additional X-Debian-Mantainer field (for example) that lists the original maintainer, this will offend some fellow Debian maintainers? Anyone care to tell me why? But still, I have no problem with my name in the Ubuntu packages, but I'd expect to know about this BEFORE it gets published. > And about pulling the changes, did you notice these: > ... > Ubuntu side: > https://launchpad.net/people/alfie/+packages Whow! No, noone ever told me that I have an entry there that looks like it is my entry but instead is created and kept up-to-date by someone else without even caring to tell me. Sorry, but this is not the way I would treat anyone. > you should easily be able to pull changes to your packages from there, > if you feel like it. A good indicator that your package has been > modifies in ubuntu is the string ubuntu in the package version. Right I just tried this, but found that I have to diff the diffs to find the changes. Or did I miss something. Again, this is not against Ubuntu, the distribution, but I would expect a different treatment of upstream authors. I wrote some pieces of software that are available with all/most Linux distributions. Noone told me about this either, but I'm fine with it because they all tell people that I am the upstream and they did the packaging. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Better communication between projects
On Sun, Jan 15, 2006 at 01:07:05PM +, Roger Leigh wrote: > Completely agreed. While I don't object to occasional mails from > Ubuntu users, I don't generally have a proper Ubuntu contact (or list) > to point them to. This would help a lot there, as well as preventing > the problem in the first place. Right. I should also note that I got some very positive emails and feedback from Ubuntu users. So, no, this is not neccessarily negative. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making more packages binary NMU safe
On Mon, Jan 16, 2006 at 11:05:55PM -0600, Ken Bloom wrote: > Here is the corresponding patch for that possibility. I hope the dpkg > maintainers will pick up one of these patches quickly. You should submit them to the proper channels, then, i.e. either [EMAIL PROTECTED] or a bug report. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Tue, Jan 17, 2006 at 01:28:07PM +0100, Adam Borowski wrote: > On Tue, 17 Jan 2006, Anthony Towns wrote: > >I've changed the override to Priority: standard; I can't say I'm remotely > >impressed by how this has been handled. > > Could this be stopped, please? I am not sure why you are replying to Anthony, if you read his mail, you see that he *has* stopped this. I guess this was a honest mistake from Matthias, he accidently uploaded a package not stripped of the Ubuntu-specific Essential: yes tags. This is unfortunate, but no reason for the world to end. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about debian-devel-announce
On Wed, Jan 18, 2006 at 06:44:32PM +0100, Josselin Mouette wrote: > Sorry to feed again the troll, but I would like to know what is the > rationale behind removing the permissions for Andrew and not for > Raphaël. This has nothing to do with the technical aspects of Debian development (too bad the M-F-T from d-d-a makes replies come here). Can we move this to -project, pretty please? thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about debian-devel-announce
On Wed, Jan 18, 2006 at 06:25:07PM +, Dave Holland wrote: > On Wed, Jan 18, 2006 at 06:44:32PM +0100, Josselin Mouette wrote: > > Raphaël has also harmed the project by implicitly > > linking it to Ubuntu. > > Don't be ridiculous. Ubuntu explicitly acknowledge that they build on > Debian - see http://www.ubuntulinux.org/ubuntu/relationship - and Debian > positively encourages derivative distributions - so where's the harm? > > Can we stop this time-wasting flame war already, please? That's not the right way to stop flame wars: 1. Wrong list, please discuss this on -project if you must. 2. Do not add opinions to it if you think you want a thread to end. cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about debian-devel-announce
Joerg Jaspert writes: > On 10538 March 1977, Martin Schulze wrote: > > > The charter for this list says: "Announcements for developers". > > The charter for -private reads > "Private discussions among developers: only for issues that may not be > discussed on public lists. Anything sent there should be treated as > sensitive and not to be spread to other lists;" > > Ever read that? > > > Since this mail also mentions Andrews sarcastic posting > > http://lists.debian.org/debian-devel-announce/2006/01/msg9.htmlI > > may lose posting permissions as well. > > You should lose -private rights, as you clearly cant follow its rule to > not leak. I don't understand. Martin's email did not mention -private. Do you mean to say that this decision was made as the result of discussion on -private? Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Autobuilding and the build-arch target, again
On Mon, Jan 23, 2006 at 06:36:40PM +0100, Simon Richter wrote:
> To summarize the proposals so far:
>
> - "Scan debian/rules, invoke build-arch if present".
>
> Has been tried, does not work.
AFAIK it is working as long as you assume debian/rules to be a Makefile,
which is a pretty safe assumption considered it is mandated by policy.
We had a talk about this in #debian-tech some days ago, and the general
consensus seemed to be that somebody should submit a patch for that to
dpkg.
I have attached the log.
cheers,
Michael
okay. if somebody familiar with the build-{arch,indep} in rules story
wants to comment, I think this could work out (but have to re-read
#218893; did a while ago but did not make myself a summary):
dato: I think dpkg-buildpackage needs to get changed to call build-arch
if available
but I don't recall the whole discussion
make Policy require the presence of build-{arch,indep}; this will need a
bump of Standards-Version, and of course packages are free to provide
the trivial implementation only.
then, since dpkg-buildpackage receives a .dsc as argument, _check_ the
Standards-Version of that package, and invoke build-arch if appropriate
(dpkg-buildpackage -B) iff it's >= whatever verison introduced the
"must".
err.
why shouldn't dpkg-buildpackage -B not just check whether build-arch is
there, and call that?
s#receives a .dsc as argument#has debian/control available#
azeem: because a big part of the discussion was about how hackish, error
prone, and even impractical in some cases, that approach was.
otoh, if a package updates its S-V, and does not provide build-arch,
that's a serious bug...
but otoh^2, I'm not sure what the Policy editors will think about this,
but I see really no other way out.
aba?
why can't we just make binary-arch: depend on build-arch: instead of
build?
because dpkg-buildpackage calls build first (as non-root), and
binary-arch afterwards.
it does?
indeed
so I thought somebody came up with a sane way of checking for build-arch
which, OTOH, relied that debian/rules be a Makefile, which some people
dispute (though Policy mandates it AFAIK)
http://lists.debian.org/debian-policy/2004/05/msg6.html
my personal order of preference is (1) Standards-Version bump, (2)
Build-Options, (3) Do nothing about the issue, (4) autodetect the
existance of build-arch
what's wrong with what keybuk proposed? (i.e. make --dry-run | grep
^build-arch)
keybuk proposed (2), didn't he?
ah
I read backwards.
I didn't really read the first paragraph the first time round :)
on the third try, I think I parsed it correctly, and went back to my
initial reading...
aiui, historically, the reason is because the dpkg maintainer (wiggy)
wanted to support #!/bin/sh debian/rules riles
fwiw, S-V bump detection in dpkg seems by a great length the most sane
choice to me
atm Standards-Version is only advisory
wouldn't the make -f check just fail then, and we assume no build-arch?
i'm all for (4) -- immediate functionality with no extra changes, and
pretty minimal breakage
(1) also gets our hands dirty in getting a bit a better way to be able to
introduce policy changes without making half the archive instanta-buggy
did somebody send a good patch for (4) in, yet?
it's very much against current practice, that no demand in policy can do
that, and that any demand in policy applies per direct to all packages,
but from a practical POV, being able to gradually introduce stuff into
policy this way is nice
we could also test it on one of the lesser important buildds for a
while, e.g. (like armeb or hurd-i386, dunno=
of course, it requires demanding a certain minimum version of policy after
a limited period
I really don't see the point in mandating build-arch
it is useful for a lot of packages, but pretty irrelevant for a lot as
well I guess
having an environment variable that indicates binary: doesn't need to build
arch:all stuff is another option, though the functionality isn't as
immediate then
azeem: probably so that lesser (in terms of power) arches don't need to
build huge masses of useless, because never uploaded documentation?
DavidS: yes, but this can be introduced gradually for the packages which
needs it most
instead of changing the whole archive
azeem: not as long as stuff like dpkg-bp use build?
DavidS: sure, I am assuming we go for (4)
azeem: ah, reading helps (I did miss your earlier statements as
context)
so, let's see. If we changed d-b to check for build-arch, that'd mean
older d-b would make the package FTBFS, right?
or maybe not
no, build: implies buil
Re: Autobuilding and the build-arch target, again
On Mon, Jan 23, 2006 at 07:31:08PM +0100, Wouter Verhelst wrote: > On Mon, Jan 23, 2006 at 06:59:55PM +0100, Michael Banck wrote: > > On Mon, Jan 23, 2006 at 06:36:40PM +0100, Simon Richter wrote: > > > To summarize the proposals so far: > > > > > > - "Scan debian/rules, invoke build-arch if present". > > > > > > Has been tried, does not work. > > > > AFAIK it is working as long as you assume debian/rules to be a Makefile, > > No, that is not true. The code to do it that way had been added to dpkg > 1.10.11 (from 2003!), but was pulled in 1.10.15, with the following > changelog: Yeah, I know (it is quoted in the URL referenced in the IRC log). In the same URL however, is the proposal from keybuk to use make -pn instead of make -qn (the latter got used and later reverted in dpkg). The difference between the two is that -q checks whether a target is uptodate and return an appropriate exit code, while -p prints out the data base (i.e. the rules and variables) that results from reading the Makefile. The latter seems more robust to me, so we should reevaluate the "It is *not* possible *at all* to detect available targets in a rules file." assertion, IMHO. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiple package variants with CDBS?
On Sun, Jan 29, 2006 at 11:06:20AM +0100, Michelle Konzack wrote: > Am 2006-01-28 13:27:11, schrieb W. Borgert: > > I have a package that is configured and compiled two times, so > > that two binary packages are built in one dpkg-buildpackage run: > > One with --enable-gnome, the second without. Is this supported > > by CDBS somehow? Is there a package, that already does such a > > thing using CDBS? Any hint or example debian/rules file > > appreciated, thanks in advance! > > Look at fvwm. fvwm does not use cdbs, I think we all know how to do this in general. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
