Bug#753520: ITP: printer-driver-brlaser -- printer driver for (some) Brother laser printers
Package: wnpp Severity: wishlist Owner: Didier Raboud Package name: printer-driver-brlaser Version : 2 Upstream Author : Peter De Wachter URL : https://github.com/pdewacht/brlaser License : GPL-2+ Programming Lang: (C Description : printer driver for (some) Brother laser printers CUPS filter driver supporting (some) Brother laser printer. .. This driver is known to support these printers: * Brother DCP-7030 * Brother DCP-7065DN This driver will be maintained under the debian-printing umbrella. -- 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/20140702183023.6312.35772.reportbug@gyllingar
Bug#695829: ITP: colobot -- educational programming strategy game
Package: wnpp Severity: wishlist Owner: Didier Raboud Package name: colobot Version : Gold Pre-Alpha (git snapshot) Upstream Author : Daniel Roux (EPSITEC) previously. Now committers of https://github.com/colobot/ URL : https://colobot.info/wiki/Main_Page/EN License : GPLv3 Programming Lang: C++ Description : educational programming strategy game Colobot (Colonize with Bots) is an educational game aiming to teach programming through entertainment. You are playing as an astronaut on a journey with robot helpers to find a planet for colonization. It features 3D real-time graphics and a C++ and Java-like, object-oriented language, CBOT, which can be used to program the robots available in the game. The game comes with GPL game data, such as textures, music, sound, 3D models, etc. which will be packaged in colobot-data. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121213073429.17362.60171.reportbug@gyllingar
Re: release goal for jessie! (Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
Le mercredi, 21 novembre 2012 20.59:02, Holger Levsen a écrit : > Hi, > > On Dienstag, 20. November 2012, Henrique de Moraes Holschuh wrote: > > > I am asking why, when I had a reason to do so, was not able to do a > > > source-only upload. > > > Is this a feature of dak, or a policy enforcement? > > > > Both. > > I'd argue that it's a bug in both. > > BTW, can we have this as a release goal for jessie, that all packages have > been build on Debian buildd infrastructure? ;-) Actually, I like that way to put it as it leaves us with multiple ways forward: * accept source-only; * drop uploaded binaries; * (optionally: ) diff built and uploaded binaries, blame; What is yet unclear is if we want to build all (as in arch:any+all) or all (as in arch:any) packages on buildds. OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201211212121.19776.o...@debian.org
Re: (seemingly) declinging bug report numbers
Le dimanche, 21 octobre 2012 19.33:28, Enrico Zini a écrit : > On Sun, Oct 21, 2012 at 01:26:56PM +0900, Charles Plessy wrote: > > generalisation of application stores. How can we attract the creative > > people who entered the field of software development and distribution on > > Android or iOS ? > > Worse, because of the fragmentation of the « Linux » landscape, if they > > want to distribute their work on « Linux », these developers need to > > learn how to do so on Debian, Ubuntu, Fedora, openSUSE, etc., or need to > > convince develpers to package their work. And this still does not save > > them from learning complex details, as for instance it is not obvious to > > determine how long it will take for a package to migrate from Debian to > > Ubuntu. > > I've said this at the AppInstaller meeting almost 2 years ago and I'm > still convinced of it: the distribution fragmentation is the least of > our concerns. The big concern is that we don't have a stable "Linux" > API. Isn't that what "LSB" is meant to provide? Besides that is suffers from another type of fragmentation: upstream's engagements on long-term supporting their supposedly extra-stable APIs. The case I'm thinking about is stuff like Qt3, that is a "must" of the LSB version we will claim to support in Wheezy but that noone can reasonably claim to support security-wise, because Qt upstream's moved to Qt4 (or 5, or 6 already?). Salut, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201210212233.36977.o...@debian.org
Re: lsb-base "Fancy output"; please test lsb-base/experimental (4.1+Debian0+fancy0)
Hi -devel (and -lsb), Le mercredi, 4 avril 2012 11.35:49, Didier 'OdyX' Raboud a écrit : > I have recently uploaded lsb-base 4.1+Debian0+fancy0 to experimental. As > this version introduces a small change that has a big visual impact on > the Debian boot, I would like to get some feedback on it before > uploading it to unstable. Given the feedback I got and 7 days in experimental, I have just uploaded this change to unstable; let's see how much bugs it triggers! Many thanks to those that provided concerns and feedback, it has been valuable. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#664076: ITP: shatag -- tool for computing and caching file checksums in filesystem extended attributes
Package: wnpp Severity: wishlist Owner: Didier Raboud Package name: shatag Version : 0.3.1 Upstream Author : Maxime Augier URL : https://bitbucket.org/maugier/shatag License : GPL-3 Programming Lang: Python (3) Description : tool for computing and caching file checksums in extended attributes Shatag is a tool for computing and caching file checksums, and do remote duplicate detection. Files are compared on their SHA-256 hash to find duplicates, and will use filesystem extended attributes to cache the checksum values. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120315135622.25861.76436.reportbug@Icterus
Announcing debian-mob...@lists.debian.org!
Hi all, Thanks to our benevolent listmasters[0], everyone interested in discussing mobile interfaces in Debian, Debian on mobile devices, etc, now has a new mailing-list: debian-mob...@lists.debian.org http://lists.debian.org/debian-mobile As its description says, this new mailing list is meant to be the place for "discussions around packaging suitable mobile interfaces for Debian." When discussing the creation of the mailing-list [0], we tried to define what was meant by "mobile": "Mobile systems have a user-interface different than the traditional 'keyboard+mouse' pair, can be battery-powered, have a generally small form factor and/or only allow few elements on a given screen." Information about running Debian, Linux and other Free Software on mobile devices has been gathered on the Mobile[1] and Smartphone[2] wiki pages. We would like to invite all participants scattered around in the multiple mailing lists to join debian-mob...@lists.debian.org to discuss and work on bringing Debian to mobile devices. In order to organize and coordinate the team work, we would also like to hold an IRC meeting soon, so please add your preferences to the poll[3]. Cheers, Didier Raboud (OdyX) and Paul Wise (pabs) 0. http://bugs.debian.org/643678 1. http://wiki.debian.org/Mobile 2. http://wiki.debian.org/Smartphone 3. http://papillon.lamiral.info/poll/8Rg7331327063101/ signature.asc Description: This is a digitally signed message part.
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Le mardi, 3 janvier 2012 16.58:08, Axel Beckert a écrit : > Hi, > > Marco d'Itri wrote: > > If /tmp is noexec then the administrator mounted it this way and knows > > about it. Another idea would be to use /usr/bin as temporary place for the old screen. That would be a Policy violation but not a much "bigger" than using /tmp . 1) in screen/wheezy's `preinst upgrade`: cp /usr/bin/screen /usr/bin/screen-old touch /tmp/flag-screen-has-been-upgraded-no-reboot-yet (+ appropriate mktemp and usual version and sanity checks) 2) This means that as long as the machine hasn't been rebooted (/tmp emptied), both the new /usr/bin/screen and the old /usr/bin/screen-old exist for the admin to use. 3) In a "screen-cleanup init script", test the inexistance of the flag and the existance of /usr/bin/screen-old; in that case, `rm` it. (+ appropriate version and sanity checks, + idempotency) This is mostly the "put it under /tmp" idea minus the "noexec" caveat, plus the "init script insanity" (which can be dropped in unstable as soon as Wheezy is released). Opinions ? OdyX signature.asc Description: This is a digitally signed message part.
Re: /tmp as tmpfs and consequence for imaging software
Salvo Tomaselli wrote:
>> I think the problems you describe are quite uncommon. Yes, there are use
>> cases where tmpfs for /tmp isn't the best solution but I think most
>> people do not place 1.2GB files in their /tmp and benefit greatly from
>> tmpfs.
>
> I thought DVD burners were quite common... and almost every desktop or
> laptop has one. And a DVD is 4GiB when not 7. And usually burning software
> lets you decide if you want to 1st create an iso and then burn it.
Given that any burning software can (approximately) determine what size the
ISO file will be, it should really not start to write it in /tmp when the
/tmp size is not big enough (which the software can also check). Prompting a
user with "I will not be able to write ${file} in /tmp, please point me to a
location where I can." should not be too much of a problem.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ja09sr$p6q$1...@dough.gmane.org
Re: Bug#645656: network-manager in Gnome
Josselin Mouette wrote: > > Worse, it would let metapackages migrate to testing without the > appropriate dependencies. Then _this_ problem should be fixed and not used as a justification to use Depends, either at the britney side or by providing "enforcing" metapackages, not supposed to be used by mere humans (see e.g. printer- driver-all-enforce that serves exactly this purpose and is the "Depends" counterpart to printer-driver-all). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j93oj2$lam$1...@dough.gmane.org
Bug#645898: ITP: jimtcl -- Jim is a small-footprint implementation of Tcl.
Package: wnpp Severity: wishlist Owner: Didier Raboud -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package name: jimtcl Version : 0.72 Upstream Author : Steve Bennnett , Øyvin Harboe URL : http://jim.berlios.de/ License : FreeBSD Programming Lang: C Description : Jim is a small-footprint implementation of Tcl. Jim is a small-footprint implementation of the Tcl programming language. It implements a large subset of Tcl and adds new features like references with garbage collection, closures, built-in Object Oriented Programming system, Functional Programming commands, first-class arrays and UTF-8 support. All this with a binary size of about 100-200kB (depending upon selected options). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQGcBAEBCAAGBQJOnsjeAAoJEIvPpx7KFjRVpTQL/jMjc3p2uvgrgS9/pGTPEfoS dv86Yrlygzetjwt5z5gqejsG2ZnQAnPryfahi4ca7sYSe4CHkkQJOopkcrcJUisX 7H/cdbSrWm6yoVyW8hgYPohgEw2DuYCxIocmBALScXUCFEuOcKOzL7IA9eO6xhpO 21fR75Pqqb1ozCcw4MUSahthAd0TEXnDyikyUmDJuizJgqn2z8p8vp+NCLe7Orho /PuKs05LsQhlyMMBAGoy+XnSrSa4DOMBdZUvqOKxPvf082Md73AfmLz7ZMqZGmaB 2OJRZLGw3LGjIAIlCCVkkwEm5c5XOwjU0GkyOB397pdlkVgL6zQ3lqH8ajMGcKN8 QX95+CObetn19HU7cSGh2KfyzpNdLufcoEeFr6J0b71V2cdVvrSFQMkiqhd3fUD9 /VyLlXkw9/dp341e06f6ICqntHFWmUpolHcANFXlCqZzBtnWD0bpP72EdW9rMXtl 1bYvafww2xnjL4Gg18HFEyXZbjGxgT7ZOy9CxF2Gig== =xG9K -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111019125600.25860.44016.reportbug@Tamino
Re: RFC: usb-modeswitch 1.2.0 release embedding jimtcl
Hi all again, first of all, thanks for the healthy discussion. Now, given the feedback, I plan to go with the brand new option 6 which is an option 2, "done right" (eh, IMHO). 6) "Allow interpretation using separate libjim, from jimtcl" This means packaging jimtcl and allow the usb-modeswitch-dispatcher to be dynamically linked against libjim. (That, plus "repacking to avoid the embedded jimtcl copy") Pros: relatively easy, avoids the binary embedding of jimtcl. Cons: replaces the need of the desktop install on a "tcl interpreter" to "libjim"; it weighting (with default options that are more than what is needed by the usb-modeswitch-dispatcher) 268k. As far as I could see, it's possible to win 32k by providing a libjim-tiny alternative library, but it doesn't seem worth it. So, ITP on its way I guess. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201110191417.12386.o...@debian.org
Re: Build error form Ubuntu regarding xz compression
olivier sallou wrote: > Rejected: > Require Pre-Depends: dpkg (>= 1.15.6) when using xz compression. > > Package indeed uses xz compression, but do you know what I should put > in package for this on debian side? > > Should I add in debian control a pre-depends on dpkg as said in message? Yes, you should. That's because no dpkg << 1.15.6 [0] is able to uncompress xz-compressed data.tar members of binary packages, hence the Pre-Depends (which implies that you have a fully configured dpkg >= 1.15.6 before your package gets uncompressed). Now, strictly speaking, this is not formally needed within Debian as our current stable has a newer dpkg (1.15.8.11), but this cannot hurt. Cheers, OdyX P.S. This would probably have been more suited for debian-mentors. [0] http://anonscm.debian.org/gitweb/?p=dpkg/dpkg.git;a=commit;h=9bb208a8338253a1c9e1d0642cf1ef039a335951 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j7mf2b$rha$1...@dough.gmane.org
Re: RFC: usb-modeswitch 1.2.0 release embedding jimtcl
Tollef Fog Heen wrote: > ]] Didier Raboud > > | network-manager recommends modemmanager recommends usb-modeswitch. > > This sounds like the bug, then. Recommends is «The Recommends field > should list packages that would be found together with this one in all > but unusual installations.» and I belive that the use of NM/MM with > a mobile phone and bluetooth is as common as using a USB dongle or > built-in 3g and so a Suggests looks more appropriate. usb-modeswitch being mostly useful for 3G USB dongles, I don't understand where you want the s/Recommends/Suggests/. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j7kj1c$pj4$1...@dough.gmane.org
Re: RFC: usb-modeswitch 1.2.0 release embedding jimtcl
Yves-Alexis Perez wrote: > Drop usb-modeswitch completely from the default desktop install? network-manager recommends modemmanager recommends usb-modeswitch. network-manager wants modemmanager to handle "mobile network modems". modemmanager wants usb-modeswitch because most "mobile network modems" need "modeswitching". Without usb-modeswitch installed, those devices are just seen as "USB Mass Storage", often readonly with Windows installers on them (aka "brick"). The presence of usb-modeswitch in the default desktop installs (of Ubuntu and Debian fwiw) is not really my call, but I think it is justified: having those "mobile network modems" work out-of-the-box is at least "nice to have". Think for example about users that have no other internet connection than trough such a mobile network modem. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j7k0fp$veu$1...@dough.gmane.org
Re: RFC: usb-modeswitch 1.2.0 release embedding jimtcl
Marco d'Itri wrote: > On Oct 18, Didier Raboud wrote: > >> Cons: does not solve the "desktop install needs tcl interpreter". > Is this actually a problem? TCL is < 2 MB, how big is jimtcl? jimsh is 240k. usb-modeswitch-dispatcher compiled with its embedded jimtcl interpreter (that is, with not all modules) is 196k. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j7jvgu$qgf$1...@dough.gmane.org
RFC: usb-modeswitch 1.2.0 release embedding jimtcl
Hi all, while upgrading the usb-modeswitch package to 1.2.0 [0] (currently in "beta"), I noticed that it is now embedding the "jimtcl" interpreter [1]: at build- time, the usb-modeswitch "dispatcher" (currently written in Tcl), can now be embedded in a binary that contains: a tailored jimtcl interpreter, the dispatcher's tcl code and wrapping bits. The resulting binary is self- contained and functionally equivalent to interpreting the tcl usb-modeswitch- dispatcher. Let's also note as context that the goal of this trick (AFAIUI) is to avoid having a tcl interpreter pulled up to first CDs; as usb-modeswitch is part of the standard desktop installs (trough dependencies/recommendations), this imposes the presence of tcl on the first Ubuntu CD [2]. Additionally, this means that upstream can continue hacking in tcl instead of migrating to a compiled language. [0] http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-1.2.0beta.tar.bz2 [1] http://jim.berlios.de/ [2] https://bugs.launchpad.net/ubuntu/+source/usb-modeswitch/+bug/679256 == Issues == Now I see at least those issues with the proposed approach: * code duplication: the shipped jimtcl is 0.71, where upstream released 0.72 already. jimtcl 0.71 is also already shipped as part of the openocd [3] package. So shipping one more copy of it in usb-modeswitch's source doesn't sound. * binary-embedding: as it's proposed, the jimtcl code gets compiled as part of the usb-modeswitch-dispatcher binary. This essentially means that for any jimtcl update (be it as embedded code or as separate binary), a binNMU of usb- modeswitch is required. [3] http://packages.qa.debian.org/openocd == Propositions == So in order to solve this smartly, I think there are basically 5 possibilities: 1) "Forget about jimtcl, rely on existing tcl interpreters" This is mostly "repacking to avoid the embedded jimtcl copy", "no packaging of it, go on as is done currently; by relying on existing tcl interpreters. Pros: easy, straightforward,avoids the binary embedding of jimtcl. Cons: does not solve the "desktop install needs tcl interpreter". 2) "Allow interpretation using separate jimtcl" This means packaging jimtcl and allow usb-modeswitch to depend on it (That, plus "repacking to avoid the embedded jimtcl copy") Pros: relatively easy, avoids the binary embedding of jimtcl. Cons: replaces the need of the desktop install on a "tcl interpreter" to "jimtcl". Although it's probably smaller. 3) "Embed jimtcl using the internal copy" This means taking the upstream tarball as is. Pros: small standalone -dispatcher binary. Cons: code duplication, potential security issues with out-of-date jimtcl versions, … 4) "Embed jimtcl using a standalone package" This means packaging jimtcl and do some build-time trickery to include the jimtcl static library (if possible, only the needed parts) into usb- -modeswitch-dispatcher. Pros: small standalone -dispatcher binary, no code duplication. Cons: binNMU needed at each jimtcl upgrade, static linkeage. 5) "Rewrite the usb-modeswitch-dispatcher in C" This work has already been done by Mathieu Trudel-Lapierre for the Ubuntu ackage. For now, the upstream developer hasn't included this rewrite into the upstream package (for his own set of reasons). My current strategy is to avoid as much as possible to diverge from upstream, hence why it's not in Debian's usb-modeswitch for now. Pros: No tcl interpreter needed. Cons: as it's not an upstream effort, it can become out-of-sync in terms of functionality and bugfixes (and indeed currently is as of 1.2.0~beta). For now and before the enlightenments of d-devel, I think that I would order the solutions as following: 2 1 4 5 3 What's your opinion ? Thanks in advance, and cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: Mobile UXes - From the DebConf11 BoF to the stars
Le vendredi, 9 septembre 2011 09.21:20, Luca Capello a écrit : > On Thu, 08 Sep 2011 10:36:17 +0200, Didier Raboud wrote: > > The main reference to build up this list has been > > http://wiki.debian.org/Smartphone, which is still a good reference! Now > > to the list. > > What about [1]? There is no reference in your email. > > [1] <http://wiki.debian.org/Mobile> Thanks for that. Unfortunately, nobody mentionned it during the BoF, so it just got under the radar. > Please note that I am not volunteering for anything, given that I have > completely lost any faith about having a real free smartphone Too bad. :-/ -- OdyX signature.asc Description: This is a digitally signed message part.
lists.debian.org: Please create debian-mob...@lists.debian.org (was: Re: Mobile UXes - From the DebConf11 BoF to the stars)
Package: lists.debian.org Severity: normal Le jeudi, 8 septembre 2011 16.32:45, Stefano Zacchiroli a écrit : > I applaud this "merge" effort. Kudos! > > On Thu, Sep 08, 2011 at 10:36:17AM +0200, Didier Raboud wrote: > > c) Create a new Alioth project, 'mobile-ux', with associated > > mailing-lists and a wiki page. > > Given you are going to provide a central discussion forum for Debian > "mobile" stuff, you might want to be a bit more bold and request the > "debian-mobile@lists.d.o" mailing list. That might provide some more > visibility to this laudable initiative. Agreed. So here is the formal request for a debian-mob...@lists.debian.org : Name: debian-mob...@lists.debian.org Rationale: Packaging efforts around mobile user interfaces are currently scattered around in many different alioth projects, mailing lists, etc. See http://lists.debian.org/debian-devel/2011/09/msg00126.html for a more complete rationale. Short description: Mobile interfaces in Debian Long description: Discussions around packaging suitable mobile interfaces to Debian. Mobile systems have a user-interface different than the traditional 'keyboard-mouse' pair, can be battery-powered, have a generally small form factor and/or only allow few elements on a given screen. Category: Developers Subscription Policy: open Post Policy: open Web Archive: yes Thanks for considering, cheers, -- OdyX signature.asc Description: This is a digitally signed message part.
Mobile UXes - From the DebConf11 BoF to the stars
Hi all, This is the sumary of the discussion held at DebConf11 during the "Mobile UXes" BoF, on 2011-07-29, at 18h00 in the meeting room. (= tl;dr version =) (Search for "Proposal" down this mail.) (Please answer to debian-devel@lists.debian.org only. ) The point of this mail is to inform people and communities of the content of those discussions and propose a sort-of plan of action. Note that nothing has been clearly decided there but the discussion was really nice and promising so I sort-of hope the consensus acknowledged upon there can be reflected online. = Outline = 0 - Commented overview of the various available stacks 1 - Proposal for future actions and meet-together = 0 - Commented overview of the various available stacks = The initial idea to frame the discussion was to share experiences and opinions about known free software mobile stacks: are they packaged in Debian? What has been the experience so far? If not, why not? The main reference to build up this list has been http://wiki.debian.org/Smartphone, which is still a good reference! Now to the list. == Android == The Canonical effort [0] to port an Android execution environment is currently reported as a dead-end. The most free-software-friendly efforts reported are IcedRobot [1] and Replicant [2]. They don't seem ready enough for inclusion in Debian though but we should keep an eye on them. [0] https://wiki.ubuntu.com/Specs/AndroidExecutionEnvironment [1] http://icedrobot.org [2] http://replicant.us/ == MeeGo == Back when the MeeGo project was launched, some hoped it could be Debian-based. Some persons from the Debian community tried to make that a reality back then but didn't succeed. Then the pkg-meego team [3] was formed to get software produced by the MeeGo project in Debian. This effort has faced a tough reality with regards to project management, interfaces stability, FHS respect, trademark policies, etc; and as a result it is currently stalled. Nowadays, various software pieces produced by or within the MeeGo project are probably interesting to get in Debian: - Maliit [4] it is the input methods solution used in MeeGo (in particular it's the project behind the Harmattan virtual keyboard / input method; also used for the N900/N950 Community Edition) - the Tablet User Experience [5] released by Intel earlier this year. - Handheld UX in the MeeGo CE form [6] As a side-note; the software released with the Nokia N9 (of which the "swipe" user interface [7] is not known to be available as free software) is available as a downloadable qemu image [8]. MeeGo CE [9] is a community effort both to make free MeeGo releases for a few smartphones, and to make MeeGo as a project more transparent by being an example of a contributing "vendor". Since the project aims for a product level quality in the UIs, the packages they've put on top of MeeGo Core and integrate back to the Core are interesting for Debian as well. Timo Jyrinki wrote a very interesting blogpost on this topic [10]. [3] http://pkg-meego.alioth.debian.org/ [4] http://maliit.org [5] https://meego.com/downloads/releases/1.2/meego-tablet-developer-preview [6] https://build.pub.meego.com/project/packages?project=Project%3ADE%3ATrunk [7] http://www.developer.nokia.com/swipe/ux/ [8] http://harmattan-dev.nokia.com/ [9] http://wiki.meego.com/N900 [10] http://losca.blogspot.com/2011/08/meego-ce-and-freesmartphoneorg.html == Maemo == Maemo [11] is the Debian derivative that powers the Nokia N900 that was one branches of the MeeGo merge. Nowadays, both Maemo 6 and Harmattan (software basis of the Nokia N9) are reported to be dead-ends. A Debian team [12] was formed to work on the inclusion of the Maemo software back in Debian, but it decided earlier this year that Maemo is a dead end and removed Maemo related software from Debian [13]. It could still make sense to package some of the Maemo GTK themes to make running unmodified GTK applications easier on mobile devices. Openmoko also produced some. [11] http://maemo.org [12] http://wiki.debian.org/pkg-maemo [13] http://article.gmane.org/gmane.linux.debian.alioth.maemo.maint/1013 == GNOME Mobile & Embedded Initiative == The GNOME Mobile & Embedded Initiative was announced in 2007 for developing and promoting the use of the GNOME platform in mobile devices. It is not packaged in Debian (although the GNOME team might be able to give more insightful information) and doesn't seem to have a home on the Internet. It is part of the Hackable1 distribution (see below). == KDE Plasma Active == From their website: "KDE Plasma Active [14] aims at creating a cross-device user experience for emerging devices such as tablet computers, media centers, smartphones, and more." It is currently not packaged in Debian, but some members of the pkg-qt-kde team could certainly be interested [15]. [14] http://community.kde.org
Bug#639898: ITP: pxljr -- driver for HP's Color LaserJet 35xx/36xx color laser printers
Package: wnpp Severity: wishlist Owner: Didier Raboud -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package name: pxljr Version : 1.3 Upstream Author : Hin-Tak Leung URL : http://hp-pxl-jetready.sourceforge.net/ License : GPL-2+, LibJPEG Programming Lang: C Description : driver for HP's Color LaserJet 35xx/36xx color laser printers HP's Color LaserJets 35xx and 36xx are supported by HP's HPIJS driver (part of HPLIP), but HPIJS supports only the lowest quality level of the three which are available under Windows. This driver which is not developed at HP but by a independent developer supports all modes and so provided the highest printout quality for these printers. This package will be based on the existing Ubuntu package and will see its .orig tarball repacked to get its libjpeg and libijs embedded copies removed. Packaging is currently at http://git.debian.org/?p=collab-maint/pxljr.git. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQGcBAEBCAAGBQJOXjiSAAoJEIvPpx7KFjRVhKYL/2BmPUGhGBomzUV5jhrGqkuy 6awQMSO8gkHgXdc2G4Xx4Mo9Reu8y38dsyY3//6XLYK6PQERZ3D6swHf0zynCrw6 FCyb2VNS65x5y8Io+F1Pf7RMYcWt9BTLpbQfWqwa05IUCIrYb7kbRZNM7ncCOeux mbfwV9yLPnd9iB5EKn8WxqBMC6VevLX1FypkfOskw+aaItu2X5bIAEEFDzZe8VyA Q5vcq1rlv3GvJ2b39vj0CR2FuyV61N1uFjzLhuiXYw+uLKaHOz7ajwQT4KX0IQJT rik5w1HvQG7RjaRfnW6Zt3zE3mRhaMz85nlgXNxOSAl2ff98NiG7ZYHP6AbPEyTj idePqyT4KAHDaVLqYq9DFg3ZgOHI2QRCbkFr7rXiIvcCU7K0K7NP+ZEa6NnzM/oy vrgWoIl+7L34ccnOo9eUSkCy/5Cxzl5zNMHezIouOtvy+eKChtYozPXZsvc3LVgX /E5vImG2X6wu0pfbhD6a7RHJVgNZgcRrXdW/jYlI9g== =DER8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110831133516.17102.84453.reportbug@Tamino
Bug#637887: ITP: pkg-printing-tools -- various packaging tools for the Debian Printing Team
Package: wnpp Severity: wishlist Owner: Didier Raboud Package name: pkg-printing-tools Version : 0.1 Upstream Author : Didier Raboud License : GPL-3+ Programming Lang: Perl, etc. Description : various packaging tools for the Debian Printing Team This native package will centralize much of the current duplication that exists trough the various printing-related packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110815143614.7603.37723.reportbug@Tamino
Bug#637866: ITP: rastertosag-gdi -- printer driver for Ricoh Aficio SP1100s/SP1100
Package: wnpp Severity: wishlist Owner: Didier Raboud Package name: rastertosag-gdi Version : 0.1 Upstream Author : palz URL : http://www.openprinting.org/driver/rastertosag-gdi/ License : GPL Programming Lang: Python Description : printer driver for Ricoh Aficio SP1100s/SP1100 The rastertosag-gdi driver is an open source Linux driver for the Ricoh Aficio SP1100s/SP1100s printers. These are some of the few Ricoh printers which do not understand PostScript or PCL, but only a proprietary raster format. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110815102217.8951.18994.reportbug@Tamino
Re: Whether should grub2 write MBR automatic
Le mercredi, 22 juin 2011 12.01:08, Paul Wise a écrit : > My strategy with Windows is to let it have the MBR and use Debian's > setup.exe to create an item for Debian in the Windows boot menu and > chainload Debian grub-pc from the Windows grub installed by setup.exe. > Seems to work find even though the grub scripts in Debian complain > about not being installed in the MBR on every upgrade. Hi Paul, could win32-loader (either in it's "CD" or in its "standalone (on mirrors)" version) help to setup this ? If so, a detailed bug would be appreciated. (Note that the "install a PXE loader" functionality has been included already (although not built by default), so there is certainly room for this type of things.) -- OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201106221421.09896.o...@debian.org
Bug#630810: ITP: epson-inkjet-printer-escpr -- Epson Inkjet Printer Driver (ESC/P-R)
Package: wnpp Severity: wishlist Owner: Didier Raboud Package name: epson-inkjet-printer-escpr Version : 1.0.3 Upstream Author : Seiko Epson Corporation, AVASYS CORPORATION URL : http://avasys.jp/eng/linux_driver/download/lsb/epson-inkjet/escpr/ License : GPLv2+ Programming Lang: C Description : Epson Inkjet Printer Driver (ESC/P-R) ESC/P-R is a common language for selected Epson printers that supports every media type, paper size and associated printing mode available on those printers. It is suited especially for consumer electronics devices and embedded equipments. ESC/P-R allows many kinds of devices to connect and communicate with Epson inkjet printers, expanding possibilities for use with medical equipment, measuring equipment, electronic whiteboards, and at home with home electronics and game machines. This will be maintained under the Debian Printing Team umbrella. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110617140724.19977.71800.reportbug@Tamino
Bug#629916: ITP: c2esp -- Driver for Kodak ESP 5xxx AiO color inkjet printers
Package: wnpp Severity: wishlist Owner: Didier Raboud -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: c2esp Version : 18 Upstream Author : Paul Newall URL : http://cupsdriverkodak.sourceforge.net/ License : GPLv2+ Programming Lang: C Description : Driver for Kodak ESP 5xxx AiO color inkjet printers The c2esp driver is an open source Linux driver for the Kodak ESP 5xxx AiO color inkjet printers. It is likely to work on ESP 3250, ESP 5250, ESP 7, ESP 9. Note: this will be maintained under the Debian Printing Team Umbrella. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iJwEAQECAAYFAk3w5loACgkQKA1Vt+jBwDj2mwP/cXJNf1dRleekBQslb+JvcpA4 SiuSmtxlkgNOs9rloSR0ll5vBYbKxcVXuRN5X7exJAm8hecTgmFr2qX/JtB7jRfD Ze5/ZsV+j9qo+u6Vd96R1a4D9v2oRLcLnUo7WhmiyuWWCjtD9VwzUwfZgGoiUEB0 3YrzgmvesPBbAkvKZ1Q= =OrT3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110609152722.1910.1625.reportbug@Tamino
Bug#629906: ITP: m2300w -- Driver for the Minolta magicolor 2300W/24000W color laser printers
Package: wnpp Severity: wishlist Owner: Didier Raboud Package name: m2300w Version : 0.51 Upstream Author : Leif Birkenfeld URL : http://m2300w.sf.net/ License : GPLv2+ Programming Lang: C Description : Driver for the Minolta magicolor 2300W/24000W color laser printers The m2300w driver is an open source Linux driver for the Konica Minolta magicolor 2300W and 2400W color laser printers. . The driver is basically intended for being used in conjunction with "foomatic" (see http://www.openprinting.org/foomatic.html), which is a database-driven system for integrating free software printer drivers with common spoolers under Unix, like CUPS, LPRng, LPD, GNUlpr, PPR, PDQ, CPS, and direct printing. Note: this will be maintained under the Debian Printing Team Umbrella and is basically a merge back from Ubuntu; thanks to them ! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110609130031.19502.19093.reportbug@Tamino
Re: Color Management in Debian
Hi Till, and thanks for your message. First, I think that this type of communication between Debian and its derivatives (and reversely in that case) is very important for the health of our ecosystem. So thank you for this. Le mardi, 31 mai 2011 16.16:18, Till Kamppeter a écrit : > What is needed is to introduce some new packages, especially colord, > update other packages, build packages against colord, ... > > This would be perhaps much easier when Debian would add the same color > management stack and also if we want to follow the plans to have a > unique printing stack in Debian and Ubuntu. This sounds like a very worthwhile goal. > What has to be done is to fix all the "Related bugs" (which are more > feature requests than bugs) on the Blueprint linked above also for > Debian. Especially colord needs to get packaged first: > > https://bugs.launchpad.net/ubuntu/+bug/741448 > > and then all the other packages built with colord being present. Given that Debian is currently not frozen (and that the Oneiric release will very probably happen before Wheezy's), I really think that not uploading those packages to Debian first would be a shame, as this would only mean doubling efforts. So I suggest we group people interested from Debian and Ubuntu (and any other derivatives fwiw) in a single place [0] and start working towards getting those packages to Debian first. With the NEW delays[1] these days, a sync from Debian to Ubuntu could happen in a few days; I don't think this is a serious limit. As for the common place, my personal preference would be an alioth group (pkg- colormgmt ?), with git-based packaging; but this should by no means hinder other proposals [2]. So despite my limited knowledge in this area, I would be happy to help getting those packages to Debian, by reviewing and eventually upload packages. Cheers, OdyX [0] debian-printing@l.d.o /could/ be that place, but I'm not certain it's within it's scope. [1] For which the FTP-Masters team is to be thanked for their awesome job ! [2] Who knows, we could even imagine using bazaar! signature.asc Description: This is a digitally signed message part.
Re: bug reporting workflow is outdated
Pedro Larroy wrote: > I think expecting having a working smtp on laptops, workstations, etc, > is unreasonable these days. > I suggest that we can make an HTTP based bug reporting method. While I disagree with your appreciation, I am sure that it would be technically feasible to code and deploy an HTTP-to-Debian-BTS gateway (some things have to be DoneRight™, but it's doable). IMHO, there is certainly no consensus around dropping the currently working BTS email interface, so the gateway is the only possible option, on which one can start working on right now. So in short: "Show us the code !" :-) Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/irbuvh$9qq$1...@dough.gmane.org
Re: Using -Werror in CFLAGS for a debian package build
Wouter Verhelst wrote: > I was working on nbd-server upstream, and so had ran ./configure with > CFLAGS='-Wall -Werror', which I consider good practice when writing C > code. > > What I didn't notice immediately was that gcc was emitting some > warnings, but that the -Werror option was not honored for those > warnings. Investigating turned up #615157 (Cc'd): the gcc maintainers > have decided to disable -Werror for some new warnings, because otherwise > it would cause FTBFS bugs in packages that have -Werror set in their > debian/rules file. Wouldn't it be possible to use the dpkg-buildflags framework for this? As far as I understand it, this framework sets the gcc options used to build Debian packages. Using it would allow to have an upstream-like gcc for the whole system, and Debian-specific options when building packages. (It would also have the side-effect of making sure all packages actually work fine when dpkg-buildflags sets something different as usually expected.) Opinions ? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ir5apo$kdd$1...@dough.gmane.org
Re: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID smart card readers
Le mercredi, 18 mai 2011 11.56:39, Ludovic Rousseau a écrit : > Godfrey, are you a Debian Developer? If not the bug should be an RFP > instead of ITP. But that is a minor point. Wrong. Anyone can submit an ITP if he Intends To Package something. Getting it uploaded by a DD is then still mandatory to get the package to the archive, but said DD will not be the maintainer of the package. -- OdyX signature.asc Description: This is a digitally signed message part.
Re: 0-day NMUs for RC bugs without activity for 7 days?
Roberto C. Sánchez wrote: > So, my experience with #624819 was basically this. The bug was > reported, followed by an NMU upload about 45 minutes after the bug was > initially reported. Please don't misunderstand. I appreciate that the > submitter was proactive. However, emailing the patch first and giving > me a few days would have been nice. As the reporter+NMUer, let me apologize and try to explain my reasoning: I was in the process of uploading a new upstream release for PySide (including shiboken, which is libsparsehash-dev's only reverse build-dependency in the archive) and bumped on that issue, hence reported it (with a patch, applied by the upstream authors of shiboken; which revealed itself to be insufficient, but still). A side-reason for the speed of the NMU, was that I noted that the Maintainer of the package, "Athena Capital Research " hadn't proved to be very responsive to bug reports: http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=acr-debian%40athenacr.com But that was clearly not enough, and I shouldn't have taken that unresponsiveness for granted. > Since the NMUer made changes directly to the source files, I have to back > out the patch and convert it over to quilt (I use quilt on all my > packages). So, his helpfulness actually created more work. That criticism is unfair (although I understand it), as this package is not currently using quilt (nor is in 3.0 (quilt) format). AFAIK, adding new build-dependencies (quilt in this case) and/or adding/changing patch systems is usually considered a too big change for a NMU. But I can prepare the quilt patch for you if you want. > Another thing to note is that while the NMU was uploaded to DELAYED/2, > the upload was actually ACCEPTed about 24 hours after the upload. Yep, I was really too impatient on that case, and rescheduled it after one day. At the time, I considered it harmless, but at the light of your mail, it appears that I clearly overpassed the NMU rules; I am sorry for that (and be assured that it will not happen again). Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/iq8iut$714$1...@dough.gmane.org
Re: A concrete proposal for rolling implementation
Piotr Ożarowski wrote: > [Josselin Mouette, 2011-05-04] >> This would be a pseudo-suite, like experimental. Except that while >> experimental is built on top of unstable and filled manually by >> maintainers, rolling would be built on top of testing and filled >> semi-automatically. A rolling system would have typically 2 APT lines: >> one for testing and one for rolling. > > +1 > > [...] >> What to do during freezes >> - >> I’m not sure we really need to do something different in times of >> freeze. Our time would be better spent by reducing the freeze time and >> making it more predictable; squeeze has been an awesome step in this >> direction. > > I'm not interested in helping f.e. with Perl bugs so once the ones > I care about are fixed, I just want to focus on Sid (i.e. upload new > upstream versions, prepare new transitions etc.) - I can wait a month or > two, but these long freezes demotivate me a lot. While I agree with the demotivation stance, why can't those packages be uploaded to experimental, fwiw ? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/iprk5f$hgt$1...@dough.gmane.org
Re: Bug#624997: writerperfect: FTBFS: Style.hxx:36:45: error: 'NULL' was not declared in this scope
Lucas Nussbaum wrote: > Note that the alternatives are: > - tag it 'sid'. But then, I would need to determine the root cause of > each FTBFS, and when the status of the FTBFS changes in testing. > - do not tag it. But then, it would be seen as affecting stable. > > What I would need is a way to express "It FTBFS in sid. I know it > doesn't FTBFS in stable, I don't know about wheezy." Wouldn't it be possible to introduce a "not-stable" or "not-in-squeeze" (better names welcome) tag for this purpose ? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ipoq8k$otp$1...@dough.gmane.org
Re: Mass GCC 4.6 bug filling (Re: Bug#624997: writerperfect: FTBFS: Style.hxx:36:45: error: 'NULL' was not declared in this scope)
Sandro Tosi wrote: > Who do you expect to send such communication? the gcc maintainer? good > luck with that. Do we really need that type of public bashing on -devel ? Your gripes with Matthias are notorious enough to avoid the need to repeat them all over the place, IHMO. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ipok8n$odb$1...@dough.gmane.org
Re: Bits from the Release Team - Kicking off Wheezy
Philipp Kern wrote: > Improvement to update testing more quickly by easing the pain of > transitions, like rebuilding everything in a self-contained way > to avoid entanglements, would be well appreciated. As it's not the first time I see this mentionned (but still fail to understand it fully), could you please explain a bit more what this would mean? In particular, what infrastructure are we missing ? Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ipccvt$33p$1...@dough.gmane.org
Bug#617243: ITP: kcm-gtk -- configuration module for GTK+ appearance in KDE
Package: wnpp Severity: wishlist Owner: Didier Raboud Package name: kcm-gtk Version : 0.5.3 Upstream Author : Jonathan Thomas URL : https://launchpad.net/kcm-gtk License : GPLv2 Programming Lang: Qt, KDE, C++ Description : configuration module for GTK+ appearance in KDE This is a configuration module for System Settings for configuring the widget style and fonts of GTK+ applications in KDE. It is derived from gtk-qt-engine's configuration module. Its packaging will lead to the removal (in its favour) of the gtk-qt-engine source package. The packaging is done from the Ubuntu packaging and currently happens in http://git.debian.org/?p=pkg-kde/kde-extras/kcm-gtk.git Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110307131807.12273.26316.reportbug@Icterus
Bug#602389: ITP: pyppd -- CUPS PostScript Printer Driver's compressor and generator
Package: wnpp Severity: wishlist Owner: Didier Raboud -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package name: pyppd Version : 0.4.9 Upstream Author : Vitor Baptista URL : http://pypi.python.org/pypi/pyppd License : GPLv3 Programming Lang: Python Description : CUPS PostScript Printer Driver's compressor and generator pyppd is a CUPS PPD generator. It holds an compressed archive of PPDs, which can be listed and retrieved only when needed by CUPS, saving disk space This package will be maintained under the "Debian Printing Group" umbrella. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iJwEAQECAAYFAkzSqiQACgkQKA1Vt+jBwDiJ2AQApx+H6H6vRHyg7xui32new4PD cMg/6o3xRH7sl09fcjKarhpIrXqmB8lXCH+fgU1znQtDW/ph6nw8gTRvru6+xoLc lXfkCBOlkP3xgr589synVmPrd/xYiShA4WXrfDaqF6EJHnG6WF+iNGjmM7roQraO BTAr52DCs2irT+a0CKs= =eaVc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101104124224.26294.76752.report...@tamino
Bug#599917: ITP: pyside-mobility -- Python bindings for Qt4 Mobility
Package: wnpp Severity: wishlist Owner: Didier Raboud -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package name: pyside-mobility Version : 0.1.0 Upstream Author : Nokia and Openbossa URL : http://www.pyside.org/ License : LGPL 2.1 Programming Lang: C++, Python Description : Python bindings for Qt4 Mobility Qt is a cross-platform C++ application framework. Qt's primary feature is its rich set of widgets that provide standard GUI functionality. . Python bindings for Qt4 Mobility framework. This package is similar to pyside (already in Debian), but uses a different source tarball. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iJwEAQECAAYFAky0RtQACgkQKA1Vt+jBwDjCkAP/dHX3t9l6M1RJBbT3a9LhDCyC W9wejhQTlOZbkCRVc4RRL93w3eZxrUmyLt20Avv2XpAYSeHA8NnuV0fxdETQsj58 gZ0pcsLUIVKJuQVhruv4yqLv5PAkszKyni5FdbV66PhbvaEHwD92RKDInZtp3VsD fjfSRE2A+lPEIvfLk3o= =3Qgc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101012113029.21419.97345.report...@tamino
Bug#597295: ITP: libmeegotouch -- application and UI framework library built on top of Qt
Package: wnpp Severity: wishlist Owner: MeeGo Maintainers -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package name: libmeegotouch Version : 0.20.34 Upstream Author : Nokia Corporation URL : http://meego.com License : LGPL2.1 Programming Lang: C++ Description : application and UI framework library built on top of Qt. Meego Touch is a cross-platform application and UI framework library built on top of Qt. The framework library makes use of the very latest Qt features to implement a specific UI style primarily targeting touch screen devices. NOTE to debian-devel This is the first ITP of a _long_ list of ITPs. The "Debian Meego Maintainers " intend to package almost everything that comes out of MeeGo (see http://meego.gitorious.org ). [Some packages might also come from Maemo and/or Moblin.] Hence further ITPs will drop the CC:debian-devel in favour of pkg-meego-maintain...@l.a.d.o in order to avoid flooding debian-devel. People who might want to join the effort please gatecrash on pkg-meego-maintain...@l.a.d.o or #debian-meego to coordinate. Cheers, OdyX -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iJwEAQECAAYFAkyUx6cACgkQKA1Vt+jBwDi/TAP/bhNYUXmU6CEs3kQHEMtuzzeM 6BzboohsJQE6O5AcatWYJn2tzf+KNf7v00u6Vvl6YBmtdkz9q3ER2os6n0IR94L0 y7tHClzocvtOXuXFvkl4TfAvzzpRJildIfY7j/dCgIE0QKysFPW9387tFpl7CeHX p4P0R10L352NPgwPaCE= =5IWo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100918140736.1977.42095.report...@tamino
Bug#582120: ITP: lightspark -- High-performance SWF player (experimental)
Package: wnpp Severity: wishlist Owner: Didier Raboud -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package name: lightspark Version : 0.3.1 Upstream Author : Alessandro Pignotti and others URL : http://lightspark.sourceforge.net/ License : GPLv3+ Programming Lang: C++ Description : High-performance SWF player (experimental) Lightspark is a free Flash player for Linux which aims for high-performance by using modern technologies such as JIT compilation and OpenGL shaders. . The project is currently in an alpha status, we provide the standalone player and mozilla plugin for testing purposes only. . Nice features: * JIT compilation of ActionScript to native x86 bytecode * Hardware accelerated rendering using OpenGL shaders (GLSL) * Aims to support current-generation ActionScript 3 * A new, clean, codebase exploiting multithreading and optimized for modern hardware. Designed from scratch after the official Flash documentation was released. This package already exists as a Ubuntu PPA [0] and is really experimental for now; I intend to reuse that packaging. Cheers, OdyX [0] https://launchpad.net/~sssup/+archive/sssup-ppa -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iJwEAQECAAYFAkvyn3UACgkQ884eR6Y9JhT3pgP/SNJTTM4aZXWV7AelMkblXPCP hKHv12+5uASaNkyFwo5zgoWkvLCwPMCvVpnbWwofk9sT4iqZzPNpAx8kvDTxjNxg pe/P/4XF/exsJX0jawCotMSP4Ooda8Z+3KUCLVIhQT2GkLcjk2taH+YzQqdnKgpC Sj2tRc6ylBJi4e2Ergw= =4VZc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100518140902.19412.73322.report...@tamino
Bug#572207: ITP: fosfat -- library to access Smaky formatted disk (read-only), with fuse
Package: wnpp Severity: wishlist Owner: Didier Raboud Package name: fosfat Version : 0.3.2 Upstream Author : Mathieu Schroeter URL : http://home.gna.org/fosfat License : GPLv3+ Programming Lang: C Description : library to access Smaky formatted disk (read-only), with fuse Fosfat is a library written in C for accessing in read-only to an Smaky formatted disk (compatible hard disk and floppy disk). A tool and a FUSE extension are available for read a Smaky FOS disk. . The Smaky is a line of mostly 8-bit personal computers and accompanying operating system developped at the EPFL, from 1974. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100302111850.4061.3001.report...@tamino
Bug#569173: ITP: shiboken -- python bindings generator that uses apiextractor and outputs CPython code
Package: wnpp Severity: wishlist Owner: Didier Raboud * Package name: shiboken Version : 0.0.1 Upstream Author : Nokia and OpenBossa Anderson Lizardo (lizardo) Bruno Araujo (baraujo) Hugo Parente Lima (hlima) Lauro Moura (lmoura) Luciano Miguel Wolf (luck) Marcelo Lira (setanta) Renato Araujo Oliveira Filho (renatofilho) … and others. . The Nokia contact person for PySide is Matti Airas (mairas) URL : http://www.pyside.org/ Code is at: http://qt.gitorious.org/pyside/shiboken License : GPLv2 + LGPLv2.1 Programming Lang: C++, Python Description : python bindings generator that uses apiextractor and outputs CPython code shiboken uses apiextractor to generate CPython code, then useable to generate python bindings. It is the core of the next-generation PySide. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564924: ITP: usb-modeswitch-data -- Mode switching data for usb-modeswitch
Package: wnpp Severity: wishlist Owner: Didier Raboud Package name: usb-modeswitch-data Version : 20100110 Upstream Author : Josua Dietze URL : http://www.draisberghof.de/usb_modeswitch License : GPLv2+ Programming Lang: Configuration files Description : Mode switching data for usb-modeswitch See the long description of usb-modeswitch. This packages will be a source split of usb-modeswitch containing only the configuration data (and no binaries). Upstream intends to release these configuration datas more frequently than the binary, hence the source split. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545022: ITP: pyside-tools -- PySide tools – UI Compiler (pyside-uic) plus Qt Resource Compiler (pyside-rcc4)
Package: wnpp Severity: wishlist Owner: Didier Raboud -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package name: pyside-tools Version : 0.1 Upstream Author : Nokia Corporation and subsidiaries Trolltech Torsten Marek RiverBank Computing Limited URL : http://www.pyside.org/ License : GPL [0] Programming Lang: Python, C++ Description : PySide tools – UI Compiler (pyside-uic) plus Qt Resource Compiler (pyside-rcc4) The PySide Tools are a fork from PyQt tools, simply adapted to PySide, amongst which "pyside-uic" (UI Compiler) and pyside-rcc4 (Qt Resource Compiler). I intend to prepare an initial package within the Python-Modules team and seek co-maintainers there. Best regards, OdyX [0] A slight note about the licensing : Due to upstream bug http://bugs.openbossa.org/32 , some files are actually not releasable at all. I will of course wait for this issue to be solved before actually releasing in Debian. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10rc1 (GNU/Linux) iJwEAQECAAYFAkqhGdwACgkQ884eR6Y9JhSJ2gP/aGtbDTeMzir31CYGnASncA+j GVS6PPHnioAxcVBLAV7aXJu5xtDGeWhmUu28Dv9uLU/fzNQs9PClxfBrQy8oB2sN /ewPsapYzcAQr8J4ZNfmCZncsV2Gyf2yN7QkBAf59Y2x+uyAPPk2EqOARnR5ASMz iPUm9wjV7NWXZ/k7znQ= =eezC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543719: ITP: boostpythongenerator -- Binding source code generator
Package: wnpp Severity: wishlist Owner: Didier Raboud -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package name: boostpythongenerator Version : 0.2 Upstream Author : Nokia and OpenBossa Anderson Lizardo (lizardo) Bruno Araujo (baraujo) Hugo Parente Lima (hlima) Lauro Moura (lmoura) Luciano Miguel Wolf (luck) Marcelo Lira (setanta) Renato Araujo Oliveira Filho (renatofilho) … and others. . The Nokia contact person for PySide is Matti Airas (mairas) . URL : http://www.pyside.org/home-binding/binding-generator/ License : GPL v2 Programming Lang: C++ Description : Binding source code generator The Binding Generator is a utility that parses the headers for a given C/C++ library and modifies this data with the information and guides from XML files (called typesystem files) containing complementar semantic information, modifications, renamings, etc, in order to generate binding source code (or documentation, or anything you want) for the target language for which it was written. I intend to prepare an initial package within the Python-Modules team and seek co-maintainers there. Regards, OdyX -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10rc1 (GNU/Linux) iJwEAQECAAYFAkqVV7kACgkQ884eR6Y9JhTEqQP/Wdhvv1iokEZwwV30/+BJRgDI /4Bs5G9pUYc5UtOBQCY1jm/+ZW34bWoAAlzcpxqZnfTNbzBDAz+Id475oRHMleir NgDfhcOVb36FqpuNrI3rjvTK02cExK4TonqaICGp8qQ29+jD+y66nBrU6ptn7L40 QrJKhAwjFkmTPayCkpA= =6AUe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543642: ITP: apiextractor -- Library headers parser that creates an abstract representation of an API
Package: wnpp Severity: wishlist Owner: Didier Raboud -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package name: apiextractor Version : 0.2 Upstream Author : Nokia and OpenBossa Anderson Lizardo (lizardo) Bruno Araujo (baraujo) Hugo Parente Lima (hlima) Lauro Moura (lmoura) Luciano Miguel Wolf (luck) Marcelo Lira (setanta) Renato Araujo Oliveira Filho (renatofilho) … and others. . The Nokia contact person for PySide is Matti Airas (mairas) . URL : http://www.pyside.org/home-binding/api-extractor/ License : GPL 2 Programming Lang: C++ Description : Library headers parser that creates an abstract representation of an API The API Extractor library is used by the binding generator to parse headers of a given library and merge this data with information provided by typesystem (XML) files, resulting in a representation of how the API should be exported to the chosen target language. The generation of source code for the bindings is performed by specific generators using the API Extractor library. I intend to prepare an initial package within the Python-Modules team and seek co-maintainers there. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10rc1 (GNU/Linux) iJwEAQECAAYFAkqVDIcACgkQ884eR6Y9JhQCkwQAoRftsf2G/O8yX7gYXN5gKq5q KYGKeR8qu1+JUNxi87uCko4NyQi6OPzDTLtglNeqszLJE+wBUg/mnBEByazlJlQU f2kc4ne24GUYD/cXVsxcOls1Ezr65j8C8IkCg5rEndyNL6jpdhhCAUpezubx0kmY 52JPJYClWYGaNjPx9So= =qcob -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543636: ITP: pyside -- Python bindings for Qt4 framework.
Package: wnpp Severity: wishlist Owner: Didier Raboud -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package name: pyside Version : 0.1.4.5 Upstream Author : Nokia and OpenBossa Anderson Lizardo (lizardo) Bruno Araujo (baraujo) Hugo Parente Lima (hlima) Lauro Moura (lmoura) Luciano Miguel Wolf (luck) Marcelo Lira (setanta) Renato Araujo Oliveira Filho (renatofilho) … and others. . The Nokia contact person for PySide is Matti Airas (mairas) . URL : http://www.pyside.org/ License : LGPL 2.1 Programming Lang: C++, Python Description : Python bindings for Qt4 framework. PySide is an open source sofware project providing Python bindings for the Qt framework. Combining the power of Qt and Python, PySide provides the wealth of Qt framework for developers writing software in Python and presents a first-class rapid application development platform purported to be available on all major operating systems. I intend to prepare an initial package within the Python-Modules team and seek co-maintainers there. Best regards, OdyX -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10rc1 (GNU/Linux) iJwEAQECAAYFAkqU+N8ACgkQ884eR6Y9JhRM6AP/eG/2CXIQv99C+raMT972XSNG mwwTn0t/7bRmpEOZJIV0OB7kwWULBTY5yyAph9kUyhuhS+t4Nk71f6QgiT+0sR27 R8sh124q5WswOwd9emqEhTOOzXoNtplEB5jyDQyFSApw7V/7OgUkIS+AwT6MHKYK A1ROGcBogvHTr2R2ZPc= =iHRW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Goswin von Brederlow wrote:
> Didier 'OdyX' Raboud writes:
>> Goswin von Brederlow wrote:
>>> Didier 'OdyX' Raboud writes:
Norbert Preining wrote:
> - calling /usr/share/ia32-apt-get/convert-all-sources.list
Which horribly breaks with anything a little custom (proxies, custom
repositories, ...) and fills your /etc/apt/sources.list.d/ with
ia32-apt- get.{i386,amd64} copies of all your pet sources.
>>>
>>> Examples please.
>>
>> Hi Goswin,
>>
>> Here is an example from my laptop :
>>
>> (...)
>>
>> Is that enough of an example ?
>
> Not realy. None of your entries causes an error. They all convert
> perfectly.
>
> What do you mean "no valid repository"? Are you trying to use them
> without first having called "apt-get update" to actualy create the
> index files they reference? So far everything you have shown is as
> designed.
Okay. This is #533746 then. I do always use aptitude (both command-line only
and with the curses interface) and never apt-get. You cannot expect me to
use apt-get AFAIK.
While installing wine (e.g) with aptitude, I cannot except to get new
archives added to my sources.list which should be somehow mangled by a
wrapper around apt-get, which I should begin to use instead of aptitude.
s/apt-get/aptitude/g is really too much of an intrusion in the way I admin
my machines... Sorry.
> MfG
> Goswin
I feel good intentions, but a poor result. This really seems a big plaster
on a wooden leg.
Regards,
OdyX
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Giacomo A. Catenazzi wrote: > Emilio Pozuelo Monfort wrote: >> No, users should file bugs if their HW is broken so that those can be >> blacklisted too. > > Are you joking? > For one year that user could not use debian stable? > > BTW for one reported bug, there are 10 unreported bugs. > I try hard to convince people to report bugs and I help > translating and explaining how to report bugs. > Anyway some user will no report the bug, and you can > immagine the people that doesn't hit me ;-) > > It is also a misuse of bug reports ;-) because it is > required "by design". > > ciao > cate Okay. Now reporting bugs for errors in software is a misuse… Explain me… -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
Joerg Schilling wrote: > Josselin Mouette wrote: > >> If you don???t publish this email, we will simply not believe you, >> that???s all. > > Using "majestetis pluralis" in this relation seems to be a bit absurd. > > Jörg If you don't publish this email, I will not believe you, that's all. -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: urgent RFH: please help test mdadm 2.6.7.2-1
martin f krafft wrote: > I found a bit of time to package up mdadm 2.6.7.2-1, which fixes two > RC bugs, but I cannot test it. I've built unofficial packages for > i386 and amd64 and put them at > > http://debian.madduck.net/repo/pool/main/m/mdadm/ > > so please try them out if you can, otherwise I won't be able to > upload them soon, which might delay the lenny release. Hi, I tested it on one amd64-lenny box. Two RAID1 array on two 250GB SATA disks (one array for /boot and one for LVM). It installed OK, debconf asked for the arrays needed on boot (I had "all" which is fine). So far so good ! (But I can't tell for the RC bugs...) Regards, OdyX P.S. Maybe you'll get your "I-fixed-a-RC-bug" beer :-) -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#509685: ITP: hardlink -- Hardlink multiple copies of the same file
Andrew Vaughan wrote: > On Fri, 26 Dec 2008, John Goerzen wrote: >> Julian Andres Klode wrote: >> > Hardlink is a tool which detects multiple copies of the same file and >> > replaces them with hardlinks. >> > . >> > The idea has been taken from http://code.google.com/p/hardlinkpy/, but >> > the code has been written from scratch and licensed under the MIT >> > license. >> >> Do we really need another tool like this? >> >> We already have these packages: >> >> fdupes >> perforate >> > Hi John > > I think that's a little harsh. There are lots of apps in Debian that > provide similar functionality to other apps in Debian. I do agree that > iff hardlink is only duplicating functionality available in finddup, then > there is no point in maintaining both. > > (...) > > Andrew V. Note that hardlink just hit Sid. -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Ana Guerrero wrote:
> On Tue, Dec 16, 2008 at 12:29:21AM +0100, Didier Raboud wrote:
>>
>> Look for example at the upcoming KDE4.2 : KDE4.0 ("public beta") went out
>> in january 2008. Since then and 'because' of the unstable-to-testing
>> pipe, KDE4.0 has only lived in experimental with the big fat blinking
>> red "WARNING" sign above.
>>
>> KDE4 was then hard to test for "testing" users that don't play with
>> apt-pinning and KDE4 will not be part of Lenny (even if it could…),
>> roughly 15 months after its release.
>>
>> That's not a problem from Debian stable users, who need a "stable before
>> all" release. But for the FLOSS community and the geeky users, I guess
>> that it is in fact a problem.
>>
>> With a less jungle experimental which you could trust as the unfrozen
>> unstable or with a constantly unfrozen unstable, this would not be an
>> issue.
>
> Please, next time pick up an example you know better.
>
> KDE 4.0 totally belonged to experimental, 4.1 has never been uploaded to
> unstable because lenny was planned to be released with KDE 3.5, and even
> there was an update to this series a few months ago. Furthermore, Lenny
> users can test it from http://kde4.debian.net
> KDE 4.2 has not being release *yet*.
Point understood. I apologize for that.
> I encourage you to (co)maintain packages in Debian. It will give you a
> better idea of how some stuff works and I think it could change some of
> the points of view I have read from you in this thread.
>
> Ana
Thanks for the encouragement.
Didier
--
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Thomas Viehmann wrote: > Hi, > Bastian Venthur wrote: > > What I'd like to see is a solution where unstable is *never* frozen > > Bastian, this is a brilliant idea!! Debian needs those excellent people > like you who have splendid ideas and all ready to implement them!!! You > are the most valuable person in Debian right now! Because you > contribute a lot!!! You should start this super-unstable > today!!! When it works out later, Debian should integrate it as > official repository! Do not delay starting > it! No one else in Debian has your brains, so no one > else can do this!!! > > Kind regards > > T. Thomas, Many thanks for this constructive answer. I really appreciate the tone used and the fact that you seem to belittle the "fight of ideas". No really, I love how people seem to think that if you think you can't work and if you work, you can't think. Or s/think/communicate your ideas/g Indulgent regards, OdyX -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Christian Perrier wrote: > (…) > So, I had another "idea": open -backports at the moment is > frozen so that maintainers can upload the latest bleeding edge > versions of their packages there, when using experimental is not > possible for some reasons. And make backports an official service of Debian? > Hopefully, that discussion (in backports-us...@lists.b.o) could lead > to somethingwe'll see. Yes. Hopefully. But maybe after Lenny's release (and parties ;) ). -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Romain Beauxis wrote: > > Honnestly, this discussion takes place at every freeze. As many others: firmware, dfsg-freeness, … ;) > First of all, you probably should propose such thing *after* the release, > not now. > > Secondly, I'm still wondering what new arguments were brought here. For > instance, if you want to do a serious proposal, you probably could come up > with links to previous discussions on the topic, and explain how that > changed and how your point differs from the point already mentioned in the > previous discussions. > > Until then, I don't really see the point in discussing this... > > Romain Agreed. That's what I think too : http://lists.debian.org/debian-devel/2008/12/msg00599.html Regards, OdyX -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Johannes Wiedersich wrote: > Didier Raboud wrote: >> Yes. But there is a bunch of non-DD people that strongly want to use >> Debian and prefer the recent software over the stabilized one. > > These are called 'users of unstable' or 'users of testing'. Fair enough. >> With the new >> laptops coming out every two weeks, having the latest kernel, Xorg or hal >> is no caprice, it's needed⊠> > I think that the three existing flavours of debian already provide more > than is needed to offer comfort for both users with stability needs and > users with desire for new software. Actually, I would agree if you consider the 4th flavour: experimental. Just to name some important ones which are only there: OpenOffice.org, amarok, openjdk, vlc, wine, samba. The list is ever-growing (during the freeze). Having the latest OO.o is more than confort… > At the times of a freeze, I guess the available resources would be > better spent on trying to keep that time as short as possible, instead > of having to explain to users that there is one more section that they > could use in their sources.list. I don't think that it only helps geeky users ot have "one more section". My guess is that it'll help "keeping the fun" for the Developers as well… > It would be great, if the remaining RC bugs were solved faster so that > lenny could be released sooner, allowing newer versions in squeeze > faster, allowing earlier testing of newer software, speeding up the > release of squeeze, leading I agree that with a shorter freeze it would solve it all. Just don't forget that the amount of packages is growing faster than the number of workers (DD's) [not counting how many users flew to Ubuntu and that don't report and fix in Debian…]. So, the potential source of bugs is becoming bigger, while the forces to solve the issues is not (at least not fast enough). Thus the bigger freeze time. Another solution would be to reduce the number of packages, but this is reducing the fun (and the _universal_ity) too… >> With a less jungle experimental which you could trust as the unfrozen >> unstable or with a constantly unfrozen unstable, this would not be an >> issue. > > With a faster fixing of RC bugs and a faster release, all this would not > be an issue. Agreed. But fixing RC bugs faster is not possible. You can't ask people to work more than their "fun threshold". And with the low rate of new DD's compared to the high rate of new upstreams and ITP's and so the growing rate of new packages, and so the rate of bugs, I think that reducing the freeze time is not possible. So there is a need for something else. > Cheers, > > Johannes > > - -- speaking as a user, who believes that debian's way is close to > perfect for _both_ stability and new software. > > Thanks to all for their great work! Regards, OdyX -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Romain Beauxis wrote:
> You can't get both recent *and* stabilized software. For a solid release
> to be done, one needs to hold new improvements for a while.
Yes. But there is a bunch of non-DD people that strongly want to use Debian
and prefer the recent software over the stabilized one. With the new
laptops coming out every two weeks, having the latest kernel, Xorg or hal
is no caprice, it's needed…
Debian Testing before the freeze is satisfying for most geeks that run their
own laptop only, and not a great bunch of desktops.
> I am proud that we can take this time freely from any commercial
> constraints. The main problem is that this needs to be explained to users.
> Most likely, people want both recent versions and stability, which is just
> impossible. (and yes, these sort of issues happen in Ubuntu).
Define "people"… I guess that with various user's types, you get various
hopes.
> Besides, I don't see the polemic with this "upload to unstable or
> experimental" issue. I get the impression that some developpers confuse
> their own comfort with the interest of the distribution somehow.
>
>
> Romain
Maybe the problem comes from the time needed to package and test a new
upstream version.
Look for example at the upcoming KDE4.2 : KDE4.0 ("public beta") went out in
january 2008. Since then and 'because' of the unstable-to-testing pipe,
KDE4.0 has only lived in experimental with the big fat blinking
red "WARNING" sign above.
KDE4 was then hard to test for "testing" users that don't play with
apt-pinning and KDE4 will not be part of Lenny (even if it could…), roughly
15 months after its release.
That's not a problem from Debian stable users, who need a "stable before
all" release. But for the FLOSS community and the geeky users, I guess that
it is in fact a problem.
With a less jungle experimental which you could trust as the unfrozen
unstable or with a constantly unfrozen unstable, this would not be an
issue.
Anyway, time to sleep.
'night !
OdyX
--
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Bastian Venthur wrote: > Didier Raboud schrieb: >> Bastian Venthur wrote: >>> Something like that, I don't really care about the name. The important >>> thing is, that unstable is never frozen, but temporarily disconnected >>> from the unstable > testing > stable flow. >>> >>> Another way to see it is that unstable is constantly flowing and we're >>> just forking a stable distribution from it from time to time. >> >> Isn't there a need for a freeze+stabilisation time (~ a year for Lenny…) >> in which updates occur in 2 stages to finalize and "stable"ize one >> particular snapshot ? > > I'm not sure what you're asking but by temporarily insterting a > $frozen-something between unstable and testing, we basically have the > same flow as currently just with the benefit of a living unstable. I > don't see the problem: > > currently during the freeze: > > unstable (frozen) > testing > stable > > new: > > unstable || unstable (frozen) > testing > stable That's http://wiki.debian.org/AddAnotherRepositoryBetweenUnstableAndTesting Which needs update and clarification… >> Note that forking+stable'izing Sid is what Ubuntu does every six months. > > Is that important? No. But if Debian was to adopt the same Release Process as Ubuntu, why not joining forces, entirely ? I ''guess'' that it wouldn't be the "fun in Debian"… > Unstable is frozen for nearly 1/2 year now, that's a problem we should try > to solve if we don't want to degrade ourselves to a server-only > distribution. 100% ACK. My feeling is that a release per sub-system [0] could be viable and could make Debian a really dynamic and up to date distro, but adding a repository between Sid and Testing is a good way to go. Best regards, OdyX [0] http://wiki.debian.org/ReleasePerSubsystem -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Hmmm. Thinking about it again: * For now, until the Lenny Release, there is testing-proposed-updates, which should maybe pushed more for users and DD's to use. * http://wiki.debian.org/ReleaseProposals has enough thoughts about possible changes. Maybe develop ideas further more directly in the wiki. After, AFTER, after releasing Lenny, propose a GR for changing the Release Process. -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Bastian Venthur wrote: > Didier Raboud schrieb: >> Bastian Venthur wrote: >>> What I'd like to see is a solution where unstable is *never* frozen, >>> maybe by replacing the current frozen unstable with something temporary >>> and putting it between unstable and testing, where all the fixes go >>> while all the new stuff can still go into unstable but cannot enter the >>> next step while we're in the freeze: >>> >>> Normal: >>> >>> experimental || unstable > testing > stable >>> >>> Freeze: >>> >>> experimental || unstable || $something frozen > testing > stable >>> >>> Basicly we already have this with: >>> >>> experimental || unstable > testing > stable >> >> Something like >> >> experimental || unstable-be || unstable-pt > testing >> stable >> >> with: >> >> experimentalReal >> sandbox/playground/if-your-box-breaks-its-your-own-fault >> unstable-be Bleeding-Edge Constantly updated to "newest upstream" >> unstable-pt Pre-Testing Last "considered long-time and stable" >> upstream >> Bug-fixing, actual "unstable" >> testing as actually Future Stable >> >> ? > > Something like that, I don't really care about the name. The important > thing is, that unstable is never frozen, but temporarily disconnected > from the unstable > testing > stable flow. > > Another way to see it is that unstable is constantly flowing and we're > just forking a stable distribution from it from time to time. Isn't there a need for a freeze+stabilisation time (~ a year for Lenny…) in which updates occur in 2 stages to finalize and "stable"ize one particular snapshot ? Note that forking+stable'izing Sid is what Ubuntu does every six months. /me scratches head. -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Bastian Venthur wrote: > Russell Coker schrieb: > [...] >> While changes to the processes for uploading new packages are probably >> not desirable when a freeze is starting, it seems that Lenny might be >> delayed for >> a while. So if the GR on the Lenny release ends up actually changing >> anything then I suggest that we make some changes to prevent stalling all >> development. > > I support that request. Not only is unstable quite outdated already > (bleeding edge?) it also becomes more and more a problem since the > kernel and Xorg aren't updated anymore in unstable. That means that > newer hardware (especially Laptops) don't fully work anymore (WLAN, > Graphic, Sound). > > Since we're making it very hard for our users to get their new hardware > working seamlessly, unstable becomes more and more unattractive compared > to other distributions. > > Some suggest to cherry pick packages from experimental, but first some > packages like the kernel aren't even available there and second, since > experimental is not part of the unstable > testing > stable flow, it has > the aura of sandbox/playground/if-your-box-breaks-its-your-own-fault. > And officially we don't even recommend using unstable, aren't we? So for > me that argument is invalid. > > What I'd like to see is a solution where unstable is *never* frozen, > maybe by replacing the current frozen unstable with something temporary > and putting it between unstable and testing, where all the fixes go > while all the new stuff can still go into unstable but cannot enter the > next step while we're in the freeze: > > Normal: > > experimental || unstable > testing > stable > > Freeze: > > experimental || unstable || $something frozen > testing > stable > > Basicly we already have this with: > > experimental || unstable > testing > stable Something like experimental || unstable-be || unstable-pt > testing >> stable with: experimentalReal sandbox/playground/if-your-box-breaks-its-your-own-fault unstable-be Bleeding-Edge Constantly updated to "newest upstream" unstable-pt Pre-Testing Last "considered long-time and stable" upstream Bug-fixing, actual "unstable" testing as actually Future Stable ? -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#502959: general: raff.debian.org uses non-free software
Le mardi 21 octobre 2008 11:41:14, vous avez écrit : > Package: general > Severity: serious > Justification: DFSG > > raff.debian.org uses a Compaq Smart 5i RAID card. A flash memory is used > to store the firmware. While the firmware is freely downloadable (as in > beer) on HP website [1], we don't have the corresponding source code. > > I suggest that someone works with HP to get the corresponding source > code. Until we found a solution, I recommend we simply shutdown the > machine. > > [1] > http://h2.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?la >ng=en&cc=us&prodTypeId=329290&prodSeriesId=374803&prodNameId=266599&swEnvOID >=4004&swLang=8&mode=2&taskId=135&swItem=MTX-3d1aaa0b48c04b628789e598d3 Hi, considering this serious issue, instead of shutting down the machine which handles two important services [0], I would rather reconfigure the machine to use software RAID with mdadm and not using the hardware RAID card which leads to unacceptable use of non-free software in the core of Debian buildd's. This will inevitably lead to temporary shutdown of these two services, which would have to be superseeded in another machine, running exclusively free software and no non-free blobs... And this needs work by powerful and "having-time" DD's, but freedom is maybe at that price. Regards, OdyX [0] buildd.debian.org - autobuild master keyring.debian.org - debian keyring master and keyserver -- Didier Raboud, proud Debian user. CH-1802 Corseaux [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part.
Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight
Reinhard Tartler wrote: > Didier Raboud <[EMAIL PROTECTED]> writes: > >>> - source packages in 'main' may build-depend on packages in 'patented' >> >> This is problematic for a self-buildable main everywhere, no ? > > This means that buildds would need to add both 'main' and 'patented' to > their sources.list, right. > > Do you see a particular problem with requiring that? Yes... If I am in a country where the usage of the "patented" repo is forbidden for whatever reason, I could (legally) not rebuild the whole "main" myself. And if I understand the DFSG correctly, for each package in "main", I should be able to get access to the full source code needed for its build. This could not be realised if I can't access to "patented" for legal reasons. Regards, OdyX -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight
Reinhard Tartler wrote: > Robert Millan <[EMAIL PROTECTED]> writes: > >>> At the very least, we could distribute them in a specific "patented" >>> section, with rules similar to non-free, and that we’d only mirror in >>> countries where it is not a problem. >> >> While we are at it, would be nice to have a section for DMCA-impaired >> software such as libdvdcss. > > How about this: > > - introduce a new section 'patented' > - packages in 'patented' must fulfill the requirements of the dfsg > - source packages in 'main' may produce binaries in 'patented' > - binary packages in 'main' must not depend on packages in 'patented' > > - source packages in 'main' may build-depend on packages in 'patented' This is problematic for a self-buildable main everywhere, no ? > - source and binary packages in 'patented' may depend on package on >both 'main' and 'patented' > - source packages in 'patented' must not produce binaries in 'main' > - packages in 'contrib' and 'non-free' may additionally depend on > packages >in 'patented' Sounds good for the rest... Regards, OdyX -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Live Lenny Beta1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Baumann wrote: > Debian Live Lenny Beta1 > === > > The Debian Live team[0] is pleased to announce the first beta of Debian > Lenny's Live images. Hi, I wonder if multi-arches LiveCD's are planned ? Those amd64-i386-powerpc netinst installation CDs are the _magic_ CDs which allows you to install Debian on "almost" anything. Why not building a multi-arch LiveDVD ? Regards, OdyX - -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAki2n4oACgkQwW1nnOmiePBfZwCcDe5uNpONHwGl16d2TDyq0eMo L0gAmQEfwJxPBtsFBBdTSD9PsWOpbRGj =7MK/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installer lenny beta 2 released
Le mardi 10 juin 2008 12:26:05 Frans Pop, vous avez écrit : > Didier Raboud wrote: > > as of now, the *.torrent files are missing for multi-arch cd's. > > http://cdimage.debian.org/cdimage/lenny_di_beta2/multi-arch/bt-cd/ > > They are available now. > > Cheers, > FJP Seen. Thank you. Regards, OdyX -- Didier Raboud, proud Debian user. CH-1802 Corseaux [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part.
Re: Debian Installer lenny beta 2 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frans Pop wrote: > The Debian Installer team is proud to announce the second beta release of > the installer for Debian GNU/Linux Lenny. > (...) > For the Debian Installer team, > Frans Pop > > (...) > [4]http://www.debian.org/devel/debian-installer Hi, as of now, the *.torrent files are missing for multi-arch cd's. http://cdimage.debian.org/cdimage/lenny_di_beta2/multi-arch/bt-cd/ Regards, Didier -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhNnWYACgkQwW1nnOmiePAXAgCfZwydKPyzT2r8J4dvFnOQpgik FFUAn0pFRpzf8dYNwPQ+RkhWZF7ExIll =ECAb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
