using testing/stable/unstable names with cdebootstrap
Hi, Is there a reason to not use stable/testing/unstable as the names in config/suites file ? Currently it only has code names like etch/lenny/sid. Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: This is a digitally signed message part.
Re: using testing/stable/unstable names with cdebootstrap
On Monday 08 October 2007, Goswin von Brederlow wrote: > Does it matter anywhere? You can use testing as suite name on > invocation and it will see that testing currently is lenny and use > that. I think it does. [EMAIL PROTECTED]:~$ my-pbuilder-unstable.sh create W: /home/rrs/.pbuilderrc does not exist Distribution is unstable. Building the build environment -> running cdebootstrap /usr/bin/cdebootstrap E: Unknown suite unstable pbuilder: cdebootstrap failed -> Aborting with an error -> cleaning the build env -> removing directory /media/VMIMAGES/pbuilder/unstable/pbuilder/build/7318 and its subdirectories Here's the relevant .pbuilderrc [EMAIL PROTECTED]:~$ cat .pbuilderrc-unstable ROOT_DIR=/media/VMIMAGES/pbuilder BASETGZ=$ROOT_DIR/unstable/pbuilder/base.tgz BUILDPLACE=$ROOT_DIR/unstable/pbuilder/build MIRRORSITE=http://ftp.debian.org/debian USEPROC=yes USEDEVPTS=yes USEDEVFS=no BUILDRESULT=$ROOT_DIR/unstable/pbuilder/result # forces the distribution on "pbuilder update" DISTRIBUTION=unstable APTCACHE="$ROOT_DIR/unstable/pbuilder/aptcache" APTCACHEHARDLINK="yes" REMOVEPACKAGES="lilo" HOOKDIR="" export DEBIAN_FRONTEND="noninteractive" DEBEMAIL="Ritesh Raj Sarraf <[EMAIL PROTECTED]>" BUILDSOURCEROOTCMD="fakeroot" PBUILDERROOTCMD="sudo" DEBBUILDOPTS="" APTCONFDIR="" BUILDUSERID=1234 BINDMOUNTS="" DEBOOTSTRAPOPTS[0]='--variant=buildd' Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: This is a digitally signed message part.
Amarok build-dep failure
Hi Modestas, Since your name was in the Maintainer field for Amarok, I though of asking you. Currently, I don't see amarok having all its build dependencies satisfied. [EMAIL PROTECTED]:~$ apt-get build-dep amarok Reading package lists... Done Building dependency tree Reading state information... Done E: Build-dependencies for amarok could not be satisfied. Is this a bug ? Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: This is a digitally signed message part.
Re: Amarok build-dep failure
On Tuesday 22 January 2008, Modestas Vainius wrote:
> No, pbuilder/cowbuilder is able to satisfy build dependencies. I think it's
> rather that build dependences cannot be satisfied _in your environment_.
> You do have bits of KDE4 installed, don't you? You can run:
>
> # apt-cache showsrc amarok | grep Build-Depends | sed -e 's/[(]
> [^)]\+[)]//g' -e 's/,//g' | awk -F: '{print $2}' | xargs apt-get install
>
> to see what's wrong.
Thank you for the info. It indeed was the mixture of packages.
Ritesh
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
signature.asc
Description: This is a digitally signed message part.
xen-utils installation failure
Package: xen-utils-3.2-1 Version: 3.2.0-1 Severity: important X-Debbugs-Cc: [EMAIL PROTECTED] Hi, xen-utils fails to install. I'm sorry that I couldn't gather other information that reportbug gathers. virtian:~# apt-get install xen-hypervisor-3.2-1-i386 xen-utils-3.2-1 xen-docs-3.2 Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: ssl-cert openssl Use 'apt-get autoremove' to remove them. Recommended packages: xen-hypervisor-3.2-1 The following NEW packages will be installed: xen-docs-3.2 xen-hypervisor-3.2-1-i386 xen-utils-3.2-1 0 upgraded, 3 newly installed, 0 to remove and 39 not upgraded. Need to get 1484kB/2682kB of archives. After unpacking 5689kB of additional disk space will be used. Get:1 http://ftp.us.debian.org unstable/main xen-utils-3.2-1 3.2.0-1 [1105kB] Get:2 http://ftp.us.debian.org unstable/main xen-hypervisor-3.2-1-i386 3.2.0-1 [379kB] Fetched 1169kB in 26s (44.1kB/s) Selecting previously deselected package xen-docs-3.2. (Reading database ... 36815 files and directories currently installed.) Unpacking xen-docs-3.2 (from .../xen-docs-3.2_3.2.0-1_all.deb) ... Selecting previously deselected package xen-utils-3.2-1. Unpacking xen-utils-3.2-1 (from .../xen-utils-3.2-1_3.2.0-1_i386.deb) ... Selecting previously deselected package xen-hypervisor-3.2-1-i386. Unpacking xen-hypervisor-3.2-1-i386 (from .../xen-hypervisor-3.2-1-i386_3.2.0-1_i386.deb) ... Setting up xen-docs-3.2 (3.2.0-1) ... Setting up xen-utils-3.2-1 (3.2.0-1) ... Compiling /usr/lib/xen-3.2-1/lib/python/xen/util/auxbin.py ... File "/usr/lib/xen-3.2-1/lib/python/xen/util/auxbin.py", line 23 +_path = sys.path[0] SyntaxError: can't assign to operator pycentral: pycentral pkginstall: error byte-compiling files (182) pycentral pkginstall: error byte-compiling files (182) dpkg: error processing xen-utils-3.2-1 (--configure): subprocess post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of xen-hypervisor-3.2-1-i386: xen-hypervisor-3.2-1-i386 depends on xen-utils-3.2-1; however: Package xen-utils-3.2-1 is not configured yet. dpkg: error processing xen-hypervisor-3.2-1-i386 (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: xen-utils-3.2-1 xen-hypervisor-3.2-1-i386 E: Sub-process /usr/bin/dpkg returned an error code (1) Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: This is a digitally signed message part.
Re: xen-utils installation failure
Michael Banck wrote: > Why do you CC debian-devel for a regular bug report? If every bug > report would be copied to debian-devel, the list would be totally > flooded. > Sorry. Will take care of that. Ritesh -- If possible, Please CC me when replying. I'm not subscribed to the list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Drop the minor release number
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bob Proulx wrote: > Eduard Bloch wrote: >> Then we would have >> >> Debian 4.0 for etch, 4.1 for etch stable release 1, 4.2 for etch stable >> release 2, 4.2a for etch stable release 2 with a minor CD mastering fix >> (for example), etc.pp. > > Counting numbers start at one. The first update would be the second > release of etch. So really it should be 4.1 for the first release of > etch and 4.2 for the second release and so on. > > Bob Hence, simply 4 (your way of saying) or 4.0 (others preference) would be etch. rrs - -- Ritesh Raj Sarraf RESEARCHUT -- http://www.researchut.com Gnupg Key ID: 04F130BC "Stealing logic from one person is plagiarism, stealing from many is research." "Necessity is the mother of invention." -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCzqhn4Rhi6gTxMLwRAoqwAJ0aLEHEk8omY8cDxCAb9as2M3Gi0ACgivpv 3xXSxzua/IUlixalSBCpHJM= =mw07 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What is going on with udev?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frans Pop wrote: > On Wednesday 03 August 2005 18:15, Steve Greenland wrote: >> Thanks for the pointer, Adam, and a giant "Feh!" to the genius who came >> up with that idea. > > Did you even think of asking for the rationale behind the name change? > > Hint: check the archives of the kernel mailing list. > > Cheers, > FJP I think this is because debian supports other kernels (like freebsd and GNU/Hurd) too. So having linux named as a "kernel" package doesn't cover others. rrs - -- Ritesh Raj Sarraf RESEARCHUT -- http://www.researchut.com Gnupg Key ID: 04F130BC "Stealing logic from one person is plagiarism, stealing from many is research." "Necessity is the mother of invention." -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC8QvM4Rhi6gTxMLwRAhtxAKCUKiVwqypi1lfJVHU7wANTamdNuwCeMNUP 0r/v15Bcp1FFCRv8HSUUdzA= =Qq7p -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian GNU/Darwin
Hello All, I read sometime back about Debian GNU/OpenSolaris idea. Looked great. Mac OSX's open source version, Darwin, Does it qualify under DFSG ? If yes, could we have a Debian GNU/Darwin port ? And even if Apple's Darwin doesn't qualify, GNU-Darwin would definitely will. Why don't we try to port them ? I don't have the fully required expertise but given the help and guidence I can contribute to it. I was just reading this article and thought about it. http://www.macdevcenter.com/pub/a/mac/2005/09/27/what-is-darwin.html?CMP=OTC-13IV03560550 Note: Please CC me, I'm not on the list. Regards, rrs -- Ritesh Raj Sarraf RESEARCHUT -- http://www.researchut.com "Stealing logic from one person is plagiarism, stealing from many is research". -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
package update policy
Hi, I'm not trying to start any argument. The latest nvidia stable release (9629) was made on November 7th, 2006. But it is still not included into Debian (testing/unstable/experimental). I noticed that it is already part of Ubuntu Feisty. I just wanted to know if Debian has a policy (timeline) for inclusion of a newer release of a software. I'm bringing nvidia-kernel-source package as an example because afaik it doesn't affect the package freeze for Debian because it is not part of the stable release. Still, since there is a common maintainer for the package for both the distributions, does Debian have a deadline for such scenarios ? My understanding is that since Debian is completely a voluntary based distribution, no one can demand a date for inclusion/updation of any package. Thanks, Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." "Stealing logic from one person is plagiarism, stealing from many is research." "The great are those who achieve the impossible, the petty are those who cannot - rrs" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package update policy
Evgeni Golov wrote: > On Mon, 04 Dec 2006 00:38:15 +0530 Ritesh Raj Sarraf wrote: > >> The latest nvidia stable release (9629) was made on November 7th, >> 2006. But it is still not included into Debian >> (testing/unstable/experimental). I noticed that it is already part of >> Ubuntu Feisty. > > Didn't you answer this question allready yourself: > http://bugs.debian.org/397505 > > I dont't think 9xxx will be uploaded to unstable until Etch. Maybe > Randall can tell you more. > Yes, but I think nvidia-kernel-source has no effect on Etch's release in any way. Also nvidia-kernel-source has never been part of testing as per the package's qa page. Thanks, Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." "Stealing logic from one person is plagiarism, stealing from many is research." "The great are those who achieve the impossible, the petty are those who cannot - rrs" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#527205: ITP: inotifyx -- Simple Python binding to the Linux inotify file system event monitoring API
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: inotifyx Version : 0.1.0 Upstream Author : Forest Bond * URL : http://www.alittletooquiet.net/software/inotifyx/ * License : MIT/X Programming Lang: C, Python Description : Simple Python binding to the Linux inotify file system event monitoring API inotifyx is a Python extension providing access to the Linux inotify file system event notification API. It is primarily written in C but has some Python window dressing. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#527205: ITP: inotifyx -- Simple Python binding to the Linux inotify file system event monitoring API
On Wednesday 06 May 2009 13:45:19 Adeodato Simó wrote: > > Description : Simple Python binding to the Linux inotify file > > system event monitoring API > > > > inotifyx is a Python extension providing access to the Linux inotify > > file system event notification API. It is primarily written in C but has > > some Python window dressing. > > Could you please include in the description a few lines on why would one > want to use inotifyx instead of the already available pyinotify bindings? > Given the pytagsfs upstream maintainer's announcement email [1], I believe python-inotify is not going to be maintained further. But this whole discussion started with python-inotify in experimental, which isn't backward compatible. I'm CCing the python-inotify maintainer. Probably he can give a better status of python-inotify. > By reading the upstream homepage, it already mentions: > | Reasons you might choose inotifyx over pyinotify: > | > | * inotifyx is a C extension and does not use ctypes, making it faster > | and less prone to subtle breakage due to changes in the inotify API. > | > | * inotifyx is a much thinner wrapper around inotify. pyinotify is more > | complicated. It does provide features that inotifyx does not, but > | many of them are not needed by most applications. > | > | * The API provided by pyinotify seems to change in incompatible ways on > | a fairly regular basis and with little justification. inotifyx has a > | simple API that will change rarely, if ever. > > Maybe that's a bit too long for the description, but it should be easy > enough to summarize those arguments for the long description. > Sure I'll reword and include a better description. > By the way, do you have preview packages available already? I don't have one now, but will start working on it soon. [1] https://lists.launchpad.net/pytagsfs/msg00025.html Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: This is a digitally signed message part.
Bug#527557: general: should have a help tracker for each package
Package: general Severity: wishlist Just an idea. Currently, when I am using a new package, or if I have queries regarding the new package, my friends are upstream and the web. Usually, not much authentic information. I am requesting a tracker kind approach for each package. It could be very similar to Debian BTS. When a user has some query regarding a package, she cannot file a bug report directly unless she's sure that it is a bug (and not an odd behavior). I have a query regarding fdm. Then probably I could just file a "help report" against fdm. It'd go to the same package maintainer. Most of the times, the package maintainer would be one of the best person to give helping instructions about queries against any package. We already have mailing lists, forums et cetera. So why this approach. Well, when the user has a package, and has some query, asking her to subscribe to the mailing list (upstream or distrib's) is not really the very best help. This definitely would be an extra add-on to the maintainers and there will be high chances of users asking questions without RTFMing. For that, we could make the Debian Policy that the "Debian HTS - Debian Help Tracking System", will in no way relate to release schedule or quality of the Debian distribution. I hope my english is play and understandable. Ritesh -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.29-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#527557: general: should have a help tracker for each package
Hi Holger, My proposal is just to see if there can be a way to glue up all the bits n' pieces together. There is a lot of information scattered at multiple places, which if mined properly, can serve as one of the best resource. Debian Bug Reports contain a lot of valuable data. But is it connected ? Unless one goes to the BTS and scans for the logs, they can't find it. In the same way, all cool hacks and best uses of particual software is described at these places; mailing lists, blogs, irc et cetera. Can't there be a way to glue all these data to each other ? IMO, debian-devel and debian-user must be having great amount of data, which can be invaluable. But given their high volume, not much is mined. I was thinking if there could be ways to inter-relate data to each other. I was looking at Launchpad. I haven't used it much but am starting for one of the projects. Mark's ideas is the same. They are drastically different than the way we work today (or have been working for years), but his vision is the same, IMO. And that is to inter-relate all these data sources and create invaluable resource out of it. For Debian's current infrastructure: hit the nail on the head earlier in the forum * Forums: They should be linked to mailing lists also. Like if someone starts a thread in a forum, the same should get posted in the mailing lists. And the same would go for replies. * Wiki: I'm not sure if there is the relational model with other packages, in place for wiki. Is there a way to find all wiki pages related to kdelibs5, from the PTS page ? That would help. I think, data should go to just a single location. Mailing lists, forums, wiki, BTS - all should have a single database. All should be made inter- related. And then all should have tags, so that for focused interest, one could focus on tags. A maintainer could take Tags with BTS and the highest priority item. The benefit is that all the relevant data is inter-related and hopefully mined. To start with, it should begin in Debian and who knows, maybe some day all Free Software projects could follow the same model and be inter-linked. But these are just ideas. I have no implementation details apart from a half confident example of Launchpad. But I think they are in the right direction. Ritesh On Friday 08 May 2009 16:45:18 Holger Levsen wrote: > Hi Ritesh, > > thank you for your suggestion on how to improve Debian! Even though I'm > closing this bug on the assumption that it ain't useful to report arbitary > wishlist bugs about things which could be implemented to improve Debian, no > matter how sensible they are. > > This assumption is based on three main arguments: > > First, there are several places to collect such ideas which IMO are better > suited, like the Debian wiki or personal idea collections. > > Second and more importantly, if you want such a system, I think *you* > should implement a working prototype. For example, wiki.debian.net was just > done and then, as the Debian community liked+used it, it was moved to > wiki.debian.org. > > Third, yes, discussion in advance of doing such a prototype is useful. But > you don't need to file bugs to discuss. > > > And even though I agree with Neils points in his reply, please don't be > discouraged by all of this. If you think it's a good idea, by all means go > for it and show its a cool thing! forums.debian.net is probably an example > of something which many Debian developers don't (or didnt, when it was > started) consider particulary useful, but today it has many happy users :-) > > > regards, > Holger -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: This is a digitally signed message part.
Bug#531699: ITP: apt-offline -- Offline APT Package Manager
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: apt-offline Version : 0.8.0 Upstream Author : Ritesh Raj Sarraf * URL : http://pypt-offline.sf.net * License : GPL Programming Lang: Python Description : Offline APT Package Manager apt-offline is a utility for people using Debian (and distros based on Debian) on a machine with no network connectivity. It helps in downloading the required Package Management data from another networked Windows/Linux/Mac box. Some of the features of apt-offline are: - Fetch the list of package updates - Generate the list of packages to be upgraded - Offline Bug Reports (Currently only Debian BTS) - Multiple download threads - apt cache check - Multiple Platform Support Dear DDs, The original name referred in the upstream link is pypt-offline. Since Debian currently doesn't have a package named apt-offline, I'd like to take over this name for the utility I've developed, if there is no objection. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532564: ITP: argparse -- argparse: Python command line parser
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: argparse Version : 0.9.1 Upstream Author : Steven Bethard * URL : http://code.google.com/p/argparse * License : Apache 2.0 Programming Lang: Python Description : argparse: Python command line parser The argparse module makes writing command line tools in Python easy. Just briefly describe your command line interface and argparse will take care of the rest, including: * parsing the arguments and flags from sys.argv * converting arg strings into objects for your program * formatting and printing any help messages * and much more ... For those familiar with the optparse module from the Python standard library, argparse improves on this module in a number of ways, including: * handling positional arguments * supporting sub-commands * allowing alternative option prefixes like + and / * handling zero-or-more and one-or-more style arguments * producing more informative usage messages * providing a much simpler interface for custom types and actions -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Debian DPL Debate Comments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello People, It was really a good time going through the logs of the Debian DPL Debate. I was quite happy that the organizers brought up the issue of "Under-represented Groups In Debian". I've been thinking of contributing to Debian for a long time since I started using it. The problem is that I've not been able to find a good comprehensive documentation on "Contributing to Debian" yet. Things which are complete and too much to scare me. Eg. Debian New Maintainer Guidelines. I do know that there are other ways also, besides being a DD, to contribute to Debian. But there isn't a formal written way. There, maybe, should be an official responsibility for DD's to work closely with people who are willing to contribute to Debian. As for example, it's been now around 7 years for me now using Linux and I do have a fair amount of knowledge now. It would be great if DD's here could harness the skills in "wannabe contributors" like us and prepare us help this marvelous community. In particular to me, I'm willing to contribute to Debian as maybe a DD, Package Maintainer, SysAdmin or any other work you people find as an undiscovered skill in me. Look forward for guidelines from all of you. Note: Please CC me. I'm not on the list now. Regards, Ritesh - -- Ritesh Raj Sarraf RESEARCHUT -- http://www.researchut.com Gnupg Key ID: 04F130BC "Stealing logic from one person is plagiarism, stealing from many is research". -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCOwBR4Rhi6gTxMLwRAvMwAJoDqazX6UPvp/nYWqF66dLCE4xcXACcCt/L NDSGPcv+v6xT8G5NHBe0bkU= =s8eQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: HOWTO Help (was: Debian DPL Debate Comments)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Schmehl wrote: > I think it is quite short and is missing some quite easy tasks that can > be done by nearly everyone. > > I did the mentioned talk and am about to write the document, because I > got asked a couple of times what people can do to help us, so I think > there is need for a more detailed document about that. > > But thanks for the hint anyway; if it is ready, it should be linked > from there ;) Please do it. It would help a lot to people like me who are willing to contribute but are confused/scared about the legislations listed into some short docs. Regards, rrs - -- Ritesh Raj Sarraf RESEARCHUT -- http://www.researchut.com Gnupg Key ID: 04F130BC "Stealing logic from one person is plagiarism, stealing from many is research". -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCQbOL4Rhi6gTxMLwRArcAAJ9bb+uY1NJxor/3l6fpLj4/7zrUoQCfXwKS sjdLFV7vCVDLywbPrO7gPGs= =pee/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DAMs ( & Co)
April Fool! :-) Ritesh On Friday 01 Apr 2005 12:01 pm, Joerg Jaspert wrote: > Hi, > > in the tradition of "Bits[1] from the DAMs", started in January, we are > now sending another mail to inform you about recent decisions we made. > > > Topics in this mail > --- > 1. Handling of Accounts > 2. The NM Process > 3. New Accounts? > 4. While we are at it, some other stuff too > 5. Mailing Lists > 6. Release related > 7. Are we there yet? > > > 1. Handling of Accounts > --- > > While having a very s3kr1t Cabal[2]-Meeting a bit ago, we decided that > Debian doesn't work anymore the way it is running right now. We gave you > a chance to actually proove we are wrong with this conclusion, but the > huge flamewars following our testmail showed that we are right. > So we decided to have a clean restart with a small team[3] and as such > are deleting every account[4] somewhere around this evening (UTC). > > > 2. The NM Process > - > > Well, as the Cabal[2] decided in Point 1 that we[2] don't have any > additional accounts in the future, we[2] just stopped the NM Process[5], no > need for big queues in this process anymore, they will be deleted > shortly after the accounts. > > 3. New Accounts > --- > > Note that this all does not mean that there wont be new accounts in the > future. Of course we have plans to let others play with our favourite > Universal Operating System as well, so we will accept new Developers - who > then do all the bad work for us. We[2] took some time to come up with > objective[6] criteria for new Developers (NM), some of them are listed > below, some others are to be announced at the time we start accepting new > people into the project again: > > - a NM must pay both DAMs a sum of money, randomly choosen at the time > he applies. This ensures that we always have enough money to process > the request of NMs, you know it needs time to create accounts! > > - a NM must have machines of all architectures Debian supports at his > home, making them available for all other DDs to access over the net, > so we make sure every DD may know what his packages are doing on other > machines. > > - a NM must agree that he wont ever flame anyone behind any > role-address, except he paid him before. > > - [deleted or anyone from debian-women would kill me. Sorry] > > > 4. While we are at it, some other stuff too > --- > > Ok, while we are already at this bit-writing thing, we decided to > add just another bit here, no need for an additional mail only wasting > resources. > As we both have some other hats for our nice shoulders, we just > wanted to add that this NEW is also stopped. You aren't able to upload > anymore, so no need for NEW. Of course we will clean the archive, recent > activities with the long NEW queue, and the long past it had made the > archive just too big. The Cabal doesn't use all the packages, so why > should we keep them around? Be prepared for a 1GB Debian Mirror in the > future, carrying all useful stuff you need to have. > > > 5. Mailing Lists > > > As we considered the climate on the lists to be BAD, we just decided to > randomly shut them down. Whenever we[2] don't like a thread this list > will be dropped for at least a week. We are sure that this will help us > to get to a much friendlier atmosphere, as random people already > announced that need a while ago. > > > 6. Release related > -- > > What for? With the end of this day we will remove sarge and woody. We > all run sid anyways, so why bother keeping something always outdated? > Its so much simpler to just work on sid. Believe us, we are the Cabal, > we know that. > > > 7. Are we there yet? > > > Yes, some ice cream for you. > > > > > Footnotes: > [1] Sorry, only Bits, not Bytes, we[2] didn't have enough time to prepare > Bytes. Please go and collect as many copies as you need to prepare > a byte out of it yourself. > > [2] Cabal[2], OH Cabal[2]. Yes, there is a Cabal[2]. If you need to read > this via a public mailinglist you are not in this Cabal[2]. > Sorry. Bad luck for you. > > [3] Yes, you know, anyone says small teams[2] are good. > > [4] Not our[2] own and some hand-selected Cabal[2] Members Accounts of > course. > > [5] Just think about it. Its *NM* - so *N*o *M*ore Processing fits very > well. > > [6] Really. We used more than two dices for them! -- Ritesh Raj Sarraf RESEARCHUT -- http://www.researchut.com Gnupg Key ID: 04F130BC "Stealing logic from one person is plagiarism, stealing from many is research". pgpjKg8MbRB27.pgp Description: PGP signature
Re: DPL Debate prepared questions list [Debian Policy Sucks]
On Tuesday 21 March 2006 00:08, Adrian von Bidder wrote: > On Saturday 18 March 2006 17:32, Roland Mas wrote: > > Thaddeus H. Black, 2006-03-18 16:00:11 +0100 : > > > It appears that to have a Enterprise Grade Debian Distribution, we > > > need a SPOC [ed.: Single Point of Contact?] team which can address > > > Enterprise demands quickly. > > > > Yeah, and its members should have pointy ears and a puzzled raised > > eyebrow. > > Nah, a fancy letterhead, a certfied logo program and very high fees should > suffice. > You guys are good at making fun. But is that all ?? Forgive me if I've not done my homework but IMO Debian Policy sucks. I had installed Debian Sarge at one of my client's location. The machine serves as a NAT and does Web Content Filtering. The machine has Intel 1000MT NIC. Now, there was a known issue with those cards with e1000 driver upto kernel 2.6.11, IIRC. Sarge shipped with 2.6.8. Now the Debian policy says _only_ security updates are allowed to Debian Stable. Fixes like Feature Enhancement of Hardware Bug Fix aren't part of Debian Stable. So what do you people suggest in such cases: 1) Intel 1000MT NIC sucks, throw it away ? 2) Unh! Why don't you change to Debian Unstable ? 3) Buddy! We are all volunteers. Go and roll your own kernel with the patches ? 4) Wait! That hardware isn't officially supported by us. Build only machines which are known to work with Debian Stable? I ended up going with point number 2. But really, next time I might think of another distribution before deployment. Thanks, Ritesh -- Ritesh Raj Sarraf RESEARCHUT -- http://www.researchut.com "Necessity is the mother of invention." "Stealing logic from one person is plagiarism, stealing from many is research." pgpxvx92MDTJI.pgp Description: PGP signature
Re: DPL Debate prepared questions list [Debian Policy Sucks]
On Tuesday 21 March 2006 02:09, Joey Hess wrote: > Ritesh Raj Sarraf wrote: > > So what do you people suggest in such cases: > > 1) Intel 1000MT NIC sucks, throw it away ? > > 2) Unh! Why don't you change to Debian Unstable ? > > 3) Buddy! We are all volunteers. Go and roll your own kernel with the > > patches ? > > 4) Wait! That hardware isn't officially supported by us. Build only > > machines which are known to work with Debian Stable? > > 5) etch beta 2 was released last week with support for your hardware So my question is: I discovered it today. But there might have been many Debian Users who might have discovered this issue earlier. What choice are they given ? Is the choice: Wait till etch gets released ? RHEL and SLES do a damn good job of Hardware Bug Fixing and Feature Enhancement for the software they ship. Why can't we do it ? Is it just because our policy doesn't allow it ? Can't we revise the policy ? Thanks, Ritesh -- Ritesh Raj Sarraf RESEARCHUT -- http://www.researchut.com "Necessity is the mother of invention." "Stealing logic from one person is plagiarism, stealing from many is research." pgpi1LEuZDQ7c.pgp Description: PGP signature
Re: DPL Debate prepared questions list [Debian Policy Sucks]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anthony DeRobertis on Tuesday 21 Mar 2006 06:34 wrote: > Ritesh Raj Sarraf wrote: >> Now, there was a known issue with those cards with e1000 driver upto >> kernel 2.6.11, IIRC. >> > Hmmm, and 2.6.12 panics (bug #327355 <mailto:[EMAIL PROTECTED]>) > when I try and use the tape drive on my machine. New versions not only > fix bugs, but introduce new ones, too. > > [PS: Which e1000 bug are you referring to?] RH and SLES backport and patch what they release along with security support. They don't ship new kernels just for a bug. Thanks, Ritesh - -- Ritesh Raj Sarraf RESEARCHUT -- http://www.researchut.com "Necessity is the mother of invention." "Stealing logic from one person is plagiarism, stealing from many is research." -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEIEG/4Rhi6gTxMLwRAjURAKCJFEeH5pefP96HBP8iZyKmSa2jHACgmTdH NxvNzAmofrUcsYAHyXafrqw= =iC// -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian Bug Tracking System
Hi, Not trying to start a flame war but can somebody give a convincing explanation as to why don't we have a standard BTS ? If I need to subscribe to a bug I can't use the web interface. The answer you might give is, "Oh! Send am email to [EMAIL PROTECTED]" Can't we have an interface to allow subscribing to a bug through the web interface just like Bugzilla does? Thanks, Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." "Stealing logic from one person is plagiarism, stealing from many is research." "The great are those who achieve the impossible, the petty are those who cannot - rrs" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378157: general: w gives some weird message
Package: general Severity: normal I couldn't figure out what package "w" belongs to, hence general. "w" is reporting some messages on Debian GNU/kFreeBSD. 2.4+ kernel w/o ELF notes? -- report this 05:57:38 up 18 min, 1 user, load average: 0.00, 0.03, 0.04 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root ttyv5-05:46 18:33m 0.00s 0.00s /sbin/getty 384 -- System Information: Debian Release: testing/unstable Architecture: kfreebsd-i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: GNU/kFreeBSD 5.4-1-486 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378157: general: w gives some weird message
On Friday 14 July 2006 01:56, Luis Rodrigo Gallardo Cruz wrote: > On Fri, Jul 14, 2006 at 05:59:33AM +0530, Ritesh Raj Sarraf wrote: > > I couldn't figure out what package "w" belongs to, hence general. > > "w" is reporting some messages on Debian GNU/kFreeBSD. > > Where does /etc/alternatives/w point to in your system? Okay! Sorry for not investigating properly before filing the bug. /etc/alternatives/w points to /usr/bin/w.procps. procps is the package which should be associated with this bug. I don't know how to do that. Can somebody help/do it for me? Thanks, Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." "Stealing logic from one person is plagiarism, stealing from many is research." "The great are those who achieve the impossible, the petty are those who cannot - rrs" pgpD9PPMxkjwc.pgp Description: PGP signature
Bug#663204: ITP: appmenu-qt -- appmenu for qt
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: appmenu-qt Version : 0.2.4 Upstream Author : Aurélien Gâteau * URL : https://launchpad.net/appmenu-qt * License : LGPL Programming Lang: C++ Description : appmenu for qt appmenu provides you with an integrated application menu in your global menu bar. appmenu-qt will work for applications designed for QT and KDE -- 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/20120309124735.8267.63675.report...@champaran.researchut.com
Re: On init in Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Saturday 17 March 2012 10:23 PM, Thomas Goirand wrote: > I'd like people to think twice before opt-in for systemd. I just > taked with a friend working for redhat, and he told me how much he > hates it. He told me that if *anything* goes wrong in the boot > process, then basically, you're stuck, because the next thing will > be waiting forever. That's basically truth with any event based > init, and maybe we're just fine with just dependency booting. I think the same. Apart from the, "its cool. it is an event based framework", I don't see much value. and anybody who cares about events, could also monitor and act with udev's help. Today, on my typical laptop, boot is not the most important task. It is better to have something well working, fixable (being mere shell scripts and that's what your friend is also pointing). sysvinit serves this purpose well. imo it would be better to have an init system that could serve all the platforms (more or less) that we care about. - -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPbIs9AAoJEKY6WKPy4XVpmLwQALp7RUCE2CDtBfO2QehHA42s 1UUbBM7ZlcSvOh54ORQZgTaIHe/F0nockqdNIAXTLW4WJauNeyDZJwe0bvf4cLoh Oior2VF7Vz0TOYh9OrLvBwL9ytfzmbVWC4ruDXQ3xzlfji8vkrldameMzjPb/3he ssXrTD+N18SG36Y+YdpEDwBXQcaXWDkuvve4JYR4PXwXlkQz3EP4kzKmkbFIvGm9 ySqTtRjLrnPnNx9rYh5zMo9PPkhD1AAdVBZXfD3UvHCWiVaxsfXwzLlp276roeyk 9JLIp9sz/tBvQlCkcKlUdbkdnGyjsW9/aXsqgTzyPWhjPeWS2vjBMDWE+GZE0BaR 0cliDb5hvB/qPQqxWDfKhKmyrAjKIHIw/cEGIK7h51+EincQBX8IFcenyKyuHYKL 4hVCDR/dAlNIjhLVcqmqdjKeCdf9TS3iaHUBOFiGFxhvjcfwUX+QnyVTXCAyNyO0 bKatMcr1SRE1+DsOm2z5agPhuVEoepcgWHViMMfR0f5/0MwKSG1sHpmDNnesOBXp XjpkBhDJ26kCWHxAQELS/IDqVJogd9iKp8ouVci1WYB5/H7agsXLWIhSP7IQ9cEq ozzFgTHid/ySiYIrwuR3/tcZgfChmhvjmJ6hSM49/7XeuIYUiXrfzqGgZIv5L7Kx tuSh+/Rqbp6hyZnHdMeO =JEUD -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/tieu39xcns@news.researchut.com
Bug#666495: ITP: plasma-widget-menubar -- plasma widget to display a global menubar
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: plasma-widget-menubar Version : 0.1.16 Upstream Author : Aurélien Gâteau * URL : https://launchpad.net/plasma-widget-menubar * License : GPL Programming Lang: C++ Description : plasma widget to display a global menubar A plasma widget to display a global menubar of application windows -- 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/20120331073907.26394.68330.report...@champaran.researchut.com
APT Signature verification public key
Hi, I'm trying to fix a bug in apt-offline. I try running the following command but gpg complains me about the public key's unavailability. Is there a separate keyring for apt package database trust that I need to use? rrs@champaran:/tmp/apt-offline-downloads-31824$ sudo gpgv --ignore-time-conflict --keyring /etc/apt/trusted.gpg --homedir /etc/apt/trusted.gpg.d/ /tmp/InRelease.txt gpgv: Signature made Tuesday 24 April 2012 01:48:25 PM IST using RSA key ID 473041FA gpgv: Can't check signature: public key not found I tried the same with the old approach of Release files but I get the same error. sudo gpgv --ignore-time-conflict --keyring /etc/apt/trusted.gpg --homedir /etc/apt/trusted.gpg.d/ ftp.debian.org_debian_dists_experimental_Release.gpg ftp.debian.org_debian_dists_experimental_Release gpgv: Signature made Tuesday 24 April 2012 01:48:00 PM IST using RSA key ID 473041FA gpgv: Can't check signature: public key not found Please help on how I should proceed. I have the debian-archive-keyring package installed. Ritesh -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response -- 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/4f967e1d.4030...@debian.org
Re: APT Signature verification public key
Jumped too early on it. It was a corrupted apt keyring leftover of my upgrade from Ubuntu to Debian. Fixing it solved everything. Thanks, Ritesh On Tuesday 24 April 2012 03:49 PM, Ritesh Raj Sarraf wrote: > Hi, > > I'm trying to fix a bug in apt-offline. > > I try running the following command but gpg complains me about the > public key's unavailability. Is there a separate keyring for apt package > database trust that I need to use? > > rrs@champaran:/tmp/apt-offline-downloads-31824$ sudo gpgv > --ignore-time-conflict --keyring /etc/apt/trusted.gpg --homedir > /etc/apt/trusted.gpg.d/ /tmp/InRelease.txt > gpgv: Signature made Tuesday 24 April 2012 01:48:25 PM IST using RSA key > ID 473041FA > gpgv: Can't check signature: public key not found > > > I tried the same with the old approach of Release files but I get the > same error. > > sudo gpgv --ignore-time-conflict --keyring /etc/apt/trusted.gpg > --homedir /etc/apt/trusted.gpg.d/ > ftp.debian.org_debian_dists_experimental_Release.gpg > ftp.debian.org_debian_dists_experimental_Release > gpgv: Signature made Tuesday 24 April 2012 01:48:00 PM IST using RSA key > ID 473041FA > gpgv: Can't check signature: public key not found > > > Please help on how I should proceed. I have the debian-archive-keyring > package installed. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Friday 27 April 2012 02:10 AM, Svante Signell wrote: >> Say you want to mount a network disk during boot. This depend on >> the >>> network being configured. This in turn might depend on a DHCP >>> reply from a DHCP server, and to send the DHCP request the >>> network card need to be detected. To detect the network card, >>> the network driver need to be loaded, and the network card need >>> to be found on the PCI or some other internal bus. And with >>> the Linux kernel today, there is no way to know when during >>> boot the network card will be found on the bus. > This is the whole cause of the problem: You don't know the names of > your devices ay longer. Blame Linus! What's the point of changing > names of peripheral devices "dynamically"? I've been struggling > with eth0 and eth1 for some rime now, never knowing how it will be > named for every new kernel :-( > I think he is talking about when the devices get discovered and in what order. For naming, linux does have ways to guarantee persistent device names, both for block and network devices. - -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPm6dhAAoJEKY6WKPy4XVpJ4gP/28MSVaq/FcxGzYLZG3U3cog RvSIv1RcVQfB0N/HuTKSzP19Y0XTPhq7DxJlFwz0c9MgPaUn+W2YngK05XFCGf/S +zic5zf62pDQymjZ+5M6w+puuzJmbdFYEZdJULBn2e0MzX3b8rZyZulutK5UgMdn n1W51h2Uq6PpYAE4VQ4WqD/Jo+Bbk3D5f8wy7C38yRPEPSaXNW5seLEU8B2xfQGR suShUT+06z/BwYLzImKis+vlj8UWYD08h4mLirQt1722w3OU21EMVGDz7+HXIqxe G4Mggz7wuv7IlxhvxSUitpb3AWHl5Mnnc4vQ+yOKHSHcJsLgOZSfi/ugqHi1YvMm wTUwqnaEdTPq8cSY78zUJsw+JPmDt7NDmwvL0oWDCvNzwQg5MAxFPFIdLBdznnoT Wi6Tvse5NheLFgRxUQj+aCtRYAf4FMY6GtVf46IJaeAyrONYPvV7VRA8JOw82wRw pDirFZjrl/DzXot5LvAbdNpRvOhSFFk6dCoIYVlYvYoBPaNupPC35AvI/waQKseu eobR/fG7PjwsqQlTr2oiXuh8Oj4ideaNGbdvlVFSh2DBGTEqRZ8EQ0Bkk535d3S2 YkOwHm3lmvAaTD+2SP6A2XHmlvliQC1bDrRvNgFFqRtrVJKk1yQOt3Cu2GZltsOr dotNNUSr+OST1sBfAZCW =oGRb -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/4f9ba762.6040...@researchut.com
Bug#671020: ITP: robojournal -- cross-platform journal/diary tool
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: robojournal Version : 0.2 Upstream Author : Will Kraft * URL : http://sf.net/projects/robojournal * License : GPL Programming Lang: C++ Description : cross-platform journal/diary tool RoboJournal is a free, open source journal/diary application written in C++ using Qt libraries. RoboJournal works in conjunction with MySQL to allow the user to create journal databases locally or on a remote server. Support for Sqlite and Postgres is planned. . RoboJournal emphasizes streamlined, practical design plus ease-of-use. . RoboJournal depends on the Qt UI toolkit library -- 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/20120501103837.17213.40426.report...@champaran.researchut.com
Re: Getting power saving to work by default in wheezy
On Friday 11 May 2012 06:29 PM, Touko Korpela wrote: > I think it would be nice if power saving options (SATA,USB,wireless > etc.) were turned on by default when running on laptop. > Powertop can report which kernel tunables are set (and you can use it to > turn individual options on/off). > Laptop task installs pm-utils by default. > There is also optional laptop-mode-tools with some overlap with pm-utils. > TLP Linux Advanced Power Management is another option (not yet in Debian) > https://github.com/linrunner/TLP/wiki/TLP-Linux-Advanced-Power-Management For laptop-mode-tools, it is enabled by default. We have a whilelist of modules that are ON when you install. And all of what you have mentioned is already in the whitelist. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: OpenPGP digital signature
Bug#675078: ITP: overlay-scrollbar -- scrollbar overlay
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: overlay-scrollbar Version : 0.2.16 Upstream Author : Andrea Cimitan * URL : http://launchpad.net/ayatana-scrollbar * License : LGPL-2.1+ Programming Lang: C Description : scrollbar overlay Overlay scrollbar is a GtkModule enabling a dynamic overlay behavior It strives in providing the user with more screen space -- 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/20120529184022.16498.64333.report...@champaran.researchut.com
Re: Moving /tmp to tmpfs is fine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Friday 25 May 2012 05:55 PM, Serge wrote: > So instead of fixing the defaults you suggest everybody to drop > the programs they use (mc, firefox, mysql)? ;) I think I'll agree with you here. The current state seems to be broken. Having tmpfs on /tmp is fine but then we need to fix the values for os.tmpfile(), TMPDIR et cetera. Hopefully targeting it for Wheezy. Regarding the big file for /var/tmp and small file for /tmp, I think that does not make much sense, unless you have os.bigtmpfile() and os.smltmpfile(). If I (human) know it is "tmp", I would rather throw it in Trash. - -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPy7zxAAoJEKY6WKPy4XVpdKUP/3ckvjVlSQF0sMXLSKZkhhbq m2+arwSMJyfCRGeVgajymjAlXtUhsqJJ1FKaqY1eePl4G/PZAI36zlxImzZzxHSn jq7hgPfjoQ4QMlNMXCIJAHBnLX1GjoQi0MaA0F3ZoHJQ0dkofThfWwwKZbGQHL4g kjk3xPzmHVPBTGZ08bpZB2j6BIYvWdmiR1QcQnLjMkrmaTpStB+VRPHDFJIX5FFT RlYQ97xcu951pqVF2j2fUtyZ/0eh+2RQ3+EkBilmBCgYLBZKnBZgcNiRja0CWIIp 35y6iGB1h1HopS75qc8ymQyIZ6WmVlKZFDot9wtdB8IxYHYNNkHWPmNBeQF5xoOL rNS4BJE9DjBB/FdA51fs4v6G9mkmrkOiuk6ZzyuDyCEd1vwNQgccQqTNQrjwPTY0 3oIPPa/GQ3fHWbQS3Nq7y/elD19x0pGxe0FQCQLCfs1SNm7qyzPaj2G4JIZ5cTsy JCq2zBLsm9Ds350G1DVSg6onY/u4C/D2sQC64iZehp4aCpbCYOPN19gUiD0/o+f1 JrZhfyGA37muvBKcpWqgdUgNqHtKkz8C1T8nIOJg1+GsJCAvETZYiWDkqOmDF1rX 13wHSIrFMcW/9gMZUcGWa6jTBxofEPqdAnIOGU20Prn94MJnfz/8kpARDcAF6rQ/ 3mQMG0O6ASr2D8wJRURY =Gu99 -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/4fcbbcf2.4030...@researchut.com
Bug#680958: ITP: be-shell -- lightweight kde shell
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: be-shell Version : git Upstream Author : Thomas Lübking * URL : https://sourceforge.net/projects/be-shell/ * License : GPL Programming Lang: C++ Description : lightweight kde shell KISS Desktop Shell on KDE libs & some applications A Desktop shell using KDE technology (notably KIO and solid) but no plasma, nepomuk, akonadi etc. -- 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/20120709141351.32726.74641.report...@champaran.researchut.com
Bug#551645: ITP: ps3-media-server -- DLNA UPnP Media Server, dedicated to PS3
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: ps3-media-server Version : 1.10.5 Upstream Author : PMS Developers * URL : http://code.google.com/p/ps3mediaserver/ * License : GPLv2 Programming Lang: Java Description : DLNA UPnP Media Server, dedicated to PS3 PS3 Media Server is a DLNA compliant Upnp Media Server for the PS3, written in Java, with the purpose of streaming or transcoding any kind of media files, with minimum configuration. It's backed up with the powerful Mplayer/FFmpeg packages. Current features * Ready to launch and play. No codec packs to install. No folder configuration and pre-parsing or this kind of annoying thing. All your folders are directly browsed by the PS3, there's an automatic refresh also. * Real-time video transcoding of MKV/FLV/OGM/AVI, etc. * Direct streaming of DTS / DTS-HD core to the receiver * Remux H264/MPEG2 video and all audio tracks to AC3/DTS/LPCM in real time with tsMuxer when H264 is PS3/Level4.1 compliant * Full seeking support when transcoding * DVD ISOs images / VIDEO_TS Folder transcoder * OGG/FLAC/MPC/APE audio transcoding * Thumbnail generation for Videos * You can choose with a virtual folder system your audio/subtitle language on the PS3! * Simple streaming of formats PS3 natively supports: MP3/JPG/PNG/GIF/TIFF, all kind of videos (AVI, MP4, TS, M2TS, MPEG) * Display camera RAWs thumbnails (Canon / Nikon, etc.) * ZIP/RAR files as browsable folders * Support for pictures based feeds, such as Flickr and Picasaweb * Internet TV / Web Radio support with VLC, MEncoder or MPlayer * Podcasts audio/ Video feeds support * Basic Xbox360 support * FLAC 96kHz/24bits/5.1 support * Windows Only: DVR-MS remuxer and AviSynth alternative transcoder support -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ITA: dict-gcide
Hi, I have ITAed the package dict-gcide because I use it. I don't have much idea about lexical databases (that being one of the reason adopting it), so hope to gather some help here. The copyright file lists that the copy of GCIDE is archived. I am not very sure who the current upstream is and if this database is still actively maintained. There have been many bugfixes to typos and definitions but I don't see a debian/patches folder. Is Debian the only distribution packaging it now ? Currently there are 19 open bug reports against this package. If I intend to fix them, where do I submit the patches ? This package was orphaned more than 2 years ago and the previous maintainer (Bob Hilliard) seems to be in-active. PS: CCing the DDs who have NMUed this package in the past. Regards, Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: This is a digitally signed message part.
Re: ITA: dict-gcide
Hello Clint, On Tuesday 15 Dec 2009 23:43:45 Clint Adams wrote: > On Tue, Dec 15, 2009 at 05:24:48PM +0530, Ritesh Raj Sarraf wrote: > > The copyright file lists that the copy of GCIDE is archived. I am not > > very sure who the current upstream is and if this database is still > > actively maintained. > > It is not. Upstream abandoned GCIDE on the grounds that WordNet is a free > dictionary that is actively maintained, and so GCIDE was no longer > necessary. I feel that WordNet is of poor quality and largely inadequate, > so I disagree. > Me too. While Wordnet is pretty decent, GCIDE still has a more comprehensive database in my opinion. > > There have been many bugfixes to typos and definitions but I don't see a > > debian/patches folder. Is Debian the only distribution packaging it now ? > > Currently there are 19 open bug reports against this package. If I intend > > to fix them, where do I submit the patches ? > > You don't. You will be effectively maintaining a fork. You might consider > changing the name. Sure. Looks like a good candidate to start a new project with ? Especially since it contains more than 8 decades of data which can stand of value even if just archived and maintained. Probably we just host it on alioth and let interested parties contribute to and use it. Any suggestions on a different name ? Or should we just use the old one ? Regards, Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: This is a digitally signed message part.
Re: ITA: dict-gcide
Hi Pablo, On Wednesday 16 Dec 2009 13:49:18 Pablo Duboue wrote: > > RS> Probably we just host it on alioth and let interested parties > contribute to RS> and use it. > > RS> Any suggestions on a different name ? Or should we just use the old one > ? > > What about GCIDE2? And what about merging in wiktionary? > Merging wiktionary would definitely be great. But that'd be a tough task. In fact, I am not sure if we should even maintain a fork. Maintaining it (as a hosted project) as upstream is going to be a herculean task. It will require a lot of effort, time and commitment to it. Also, I don't think I have the necessary skill set to maintain a project of this magnitude as upstream. I am a user for it but upstream maintenance is going to be a different thing. For the current database that it is, IMO NMUing it, as has been happening might be the best bet. This way we don't lose this software (and all the data it brings with it). But if there are many people with interest in it to maintain, I think we could set up a team and work together. Regards, Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: This is a digitally signed message part.
Re: ifupdown2 by Cumulus Networks
On 08/06/2014 03:21 AM, Vincent Bernat wrote: > Hey! > > Cumulus Networks is using Debian as a base and has produced "ifupdown2", > a "compatible" replacement for ifupdown written in Python: > https://github.com/CumulusNetworks/ifupdown2/tree/master/ifupdown2 > > They maintain a state of what is done and apply changes incrementally to > avoid any disruption. This is quite interesting. Has anyone worked with > them on that? > > I know the main author. May I propose him to package it in Debian? The entire repository has just 4 commits. -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response -- 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/cf7cbb-n5j@news.researchut.com
Re: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Sunday 31 August 2014 12:30 AM, Lucas Nussbaum wrote: During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): >cc -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wunused -Wstrict-prototypes -fPIC -DLIB_STRING=\"lib\" -DLIBDM_API_FLUSH -D_GNU_SOURCE -DLIBDM_API_COOKIE -DUSE_SYSTEMD=208 -c -o uxsock.o uxsock.c >uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory > #include >^ >compilation terminated. >../Makefile.inc:57: recipe for target 'uxsock.o' failed >make[2]: *** [uxsock.o] Error 1 I fixed this one by adding a build-dep to systemd dev library. But for some reason, the build is failing on all architectures. But the same builds fine in my pbuilder. Any help ?? -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
Re: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Monday 01 September 2014 05:56 PM, Michael Biebl wrote: >By quickly glancing over the package, I also noted that you ship a >systemd .service file named multipathd.service but the SysV init scripts >are named /etc/init.d/multipath-tools and >/etc/init.d/multipath-tools-boot (not quite sure why there are two). > Yes. That's how they have been since beginning. Changing the init script now may break for users who may have been using it. >systemd continues to start your SysV init scripts, but I assume this is >not wanted? Typically, the SysV init script and the systemd .service >file should have the same name, this way systemd will automatically pick >the native .service unit. >If you want to keep the upstream name for the .service, this is >absolutely file as well (and even encouraged), but you should make sure >the SysV init script is not run then. >There are two possible ways: Provide a symlink(alias) >/lib/systemd/system/.service → >/lib/systemd/system/ >or mask the SysV init script by shipping a symlink pointing to /dev/null. Okay.. I'll look into it. Another issue: You install the native .service file but you aren't actually enabling it. We recommend to use dh-systemd for that. Thanks. Will look into it too. Since ./multipathd/multipathd.service also references a multipathd.socket unit, make sure this one is installed as well. Yes. I'm installing them both. If you have further questions, please don't hesitate to ask the pkg-systemd-maintainers mailing list. In native init scripts, we did a lot of check before starting and shutting down the daemon. Things like checking the root device, or tiggering LVM Volume Group activitation. They were easily done in shell. What would the systemd team recommend for it ? -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -- 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/54046f17.6010...@debian.org
Re: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Monday 01 September 2014 07:48 PM, Michael Biebl wrote: In native init scripts, we did a lot of check before starting and >shutting down the daemon. Things like checking the root device, or >tiggering LVM Volume Group activitation. They were easily done in shell. > >What would the systemd team recommend for it ? > Could you elaborate a bit more, why those are needed? What is upstream doing about this? The block storage has many components that work closely with one another. Take an example, root fs on LVM on Multipath on iSCSI. The flow for such a setup is to: 1) Start iSCSI and discover the LUNs 2) Detect and create mulitpath maps for matching LUNs in DM Multipath 3) Detect and Activate Volume Group out of the newly detected DM Multipath Physical Volumes 4) Mount the file system. The same can be applied to the shutdown sequence. You want to have proper checks in place before initiating a shutdown of the service. One would argue that the service should not stop if it has active services. Many of the services (mulitpath, iscsi, for example) have a 2 part component. One in the kernel and the other in userspace. The kernel space service will not terminate if any service is active. But the userspace is not so forgiving. In open-iscsi, if you ask the daemon to shutdown, it will. If there are active sessions, the kernel component will not terminate the current sessions. But the userspace daemon will be shutdown. That means, that when there is the next state failure, open-iscsi will have no idea of determining that a LUN state has changed Similar is the case with DM Multipath. The userspace DM Multipath daemon is responsible for polling and keeping an up-to-date status of the Device Mapper maps. If the userspace daemon is inactive, and underneath there is a fabric state change, there is no way to propagate that error to the upper layers. These design issues, since they are part of the core storage stack, if triggered, leave you with a machine with no access to your root disk. Any process at that time, may get into a 'DI' process state or an immediate device failure. The only action then would be to hardware reset your machine. This is why we do a lot of checks in the init scripts to warn the user. Similar approaches were taken in RHEL (5 and 6) and SLES (10 and 11). I'm not sure what Red Hat or SUSE has chosen for their latest releases, as I don't work on those products any more. My inclination is to ship both, the systemd service files and the init scripts, in their current form along with whatever limitations each may have, and let the user choose. And by the way, can someone please shed some more light on Debian bug: 760182 Per the bug report, there is no systemd support in d-i. Which then means that I need to disable systemd support ? -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -- 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/540579e3.50...@debian.org
Re: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Tuesday 02 September 2014 12:46 AM, Christian Hofstaedtler wrote: In native init scripts, we did a lot of check before starting and shutting >down the daemon. Things like checking the root device, or tiggering LVM >Volume Group activitation. They were easily done in shell. > >What would the systemd team recommend for it ? That probably depends on why you were doing these things in the first place. It'd be my understanding that udev should take care about most stuff, and for the root device, your initramfs-tools hook should do it. Yes. udev did take care of many things. But not all got covered by udev. Please see my other email for the problem. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -- 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/54057a72.8020...@debian.org
Re: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Tuesday 02 September 2014 03:00 AM, Michael Biebl wrote: Also, please don't simply override the lintian warning [1]. It is there for a reason. [1] http://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/?id=0783f2ec40f512adfda04c542c5ed38b53bf1247 Yes. After having talked to you, in the next upload, I'll apply the systemd service matching to the init script name. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -- 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/54057b1a.9030...@debian.org
Re: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Tuesday 02 September 2014 01:33 PM, Ritesh Raj Sarraf wrote: Could you elaborate a bit more, why those are needed? What is upstream doing about this? The block storage has many components that work closely with one another. Take an example, root fs on LVM on Multipath on iSCSI. The flow for such a setup is to: 1) Start iSCSI and discover the LUNs 2) Detect and create mulitpath maps for matching LUNs in DM Multipath 3) Detect and Activate Volume Group out of the newly detected DM Multipath Physical Volumes 4) Mount the file system. The same can be applied to the shutdown sequence. You want to have proper checks in place before initiating a shutdown of the service. One would argue that the service should not stop if it has active services. Many of the services (mulitpath, iscsi, for example) have a 2 part component. One in the kernel and the other in userspace. The kernel space service will not terminate if any service is active. But the userspace is not so forgiving. In open-iscsi, if you ask the daemon to shutdown, it will. If there are active sessions, the kernel component will not terminate the current sessions. But the userspace daemon will be shutdown. That means, that when there is the next state failure, open-iscsi will have no idea of determining that a LUN state has changed Similar is the case with DM Multipath. The userspace DM Multipath daemon is responsible for polling and keeping an up-to-date status of the Device Mapper maps. If the userspace daemon is inactive, and underneath there is a fabric state change, there is no way to propagate that error to the upper layers. These design issues, since they are part of the core storage stack, if triggered, leave you with a machine with no access to your root disk. Any process at that time, may get into a 'DI' process state or an immediate device failure. The only action then would be to hardware reset your machine. This is why we do a lot of checks in the init scripts to warn the user. Similar approaches were taken in RHEL (5 and 6) and SLES (10 and 11). I'm not sure what Red Hat or SUSE has chosen for their latest releases, as I don't work on those products any more. My inclination is to ship both, the systemd service files and the init scripts, in their current form along with whatever limitations each may have, and let the user choose. Hi, I did not get any comment on this. How are others doing similar stuff while migrating to systemd ? -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -- 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/5406df56.6070...@debian.org
Re: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Wednesday 03 September 2014 06:51 PM, Henrique de Moraes Holschuh wrote: On Wed, 03 Sep 2014, Ritesh Raj Sarraf wrote: > >My inclination is to ship both, the systemd service files and the > >init scripts, in their current form along with whatever > >limitations each may have, and let the user choose. > >I did not get any comment on this. How are others doing similar >stuff while migrating to systemd ? Well, you can always separate the important setup/teardown logic in one or more scripts, call them from the systemd unit and also from the initscript to not have duplicated logic. Or better let it be as a shell init script and let systemd handle it in compatibility mode. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -- 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/540751a0.4050...@debian.org
Re: new cowbuilder tool: make local package cache available
On Wednesday 24 September 2014 06:24 PM, Thorsten Glaser wrote: I’ve just written a hookscript for pbuilder which makes the locally cached files available during a package build. Just chmod +x it, drop it into the --hookdir, and you’re set¹². Usage scenario here is mostly debian-ports: when building packages that depend on each other, you no longer have to wait until the first package is Installed until you can build the second package³. It also makes older packages, e.g. arch:all ones, available so that you can, with some APT pinning⁴, build packages against others that have temporarily become uninstallable in unstable, e.g. to break build dependency cycles. Hi Thorsten: I think I did the same with some settings in pbuilder. ## IF you do not bind mount, precious tmpfs space is wasted, and you will very soon ## run out of it when building a big package like Bespin/IceDove/KDE #APTCACHE="/var/cache/apt/archives/" ### We set this to off because we are already bind-mounting it. ## Aslo settings cachelink to no becasue we are bind mounting it, thus no need to create a link APTCACHE="" BINDMOUNTS="/var/cache/apt/archives/" APTCACHEHARDLINK=no AUTOCLEANAPTCACHE=no EXTRAPACKAGES="eatmydata apt-utils debdelta" ## Use these when you have a package build-dep that is not yet pushed into archive. ## For details, see: http://wiki.debian.org/PbuilderTricks #OTHERMIRROR="deb file:///var/tmp/Debian-Build/pbuilder-deps ./" #BINDMOUNTS="$BINDMOUNTS /var/tmp/Debian-Build/pbuilder-deps" # Comment HOOKDIR when you are at home with very slow internet connection because # it runs apt-get update on each pbuilder build invocation #HOOKDIR="/home/rrs/.pbuilder/hooks" #ALLOWUNTRUSTED=yes -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response -- 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/0f4dfb-5t2@news.researchut.com
Re: Bug#776628: ITP: needrestart-session -- check for processes need to be restarted in user sessions
On 01/30/2015 03:46 PM, Patrick Matthäi wrote: > * Package name: needrestart-session > Version : 0.3 > Upstream Author : Thomas Liske > * URL : https://github.com/liske/needrestart-session > * License : GPL-2+ > Programming Lang: Perl > Description : check for processes need to be restarted in user sessions > > needrestart checks which processes need to be restarted after library > upgrades. > needrestart-session implements a notification of user sessions about their > obsolete processes after system upgrades. Just FYI. Guido Gunther has done something similar with whatmaps https://honk.sigxcpu.org/piki/projects/whatmaps -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response -- 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/554spb-ubi@news.researchut.com
Re: Bug#777373: ITP: doom3-dhewm3 -- GPL'ed Source code modification of the Doom3 game engine
On 02/08/2015 12:18 AM, Tobias Frost wrote: > dhewm 3 is a Doom 3 GPL source modification. > The goal of dhewm 3 is bring DOOM 3 with the help of SDL to all suitable > plaforms. > > Bugs present in the original DOOM 3 will be fixed (when identified) without > altering the original gameplay. > > Compared to the original DOOM 3, the changes of dhewm 3 worth mentioning are: > > 64bit port > SDL for low level OS support, OpenGL and input handling > OpenAL for audio output, all OS specific audio backends are gone > OpenAL EFX for EAX reverb effects (read: EAX on all platforms) > A portable build system based on CMake > > The packaging will be done under the Debian-games-team umbrella. THis is awesome. :-) -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response -- 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/q6ijqb-uqb@news.researchut.com
Re: building packages of upstream commits with Jenkins
My recent job involves working with Jenkins, these days. On 02/26/2015 02:08 PM, Daniel Pocock wrote: > In the past I've encountered two types of problem: > > a) upstream makes some change (e.g. leaving some new header out of their > distribution tarball) or something else that is only discovered after > they release a new version > This would still be the same. If a build dependency is not added, your package would fail to build. And I think this step should be left as is, and should require human intervention. > b) something else changes in unstable (e.g. somebody uploaded a new > version of a reSIProcate dependency just a few days before I made a > reSIProcate release, this would have been a much easier thing to deal > with before I made the upstream tag) I guess this is where it fits the most. In Debian Sid, everything is a moving piece. With Jenkins, it'd help a lot > and I feel that making regular Jenkins builds of the packages, > possibly for every upstream commit and every dependency change in > unstable, would help detect problems sooner and usually at a point in > time when it is easier to resolve them. In my opinion, that is an overkill. You may instead want to track any point releases (including aplhas, betas and RCs). -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response -- 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/fea8sb-qad@news.researchut.com
Apport for Debian
Hi, Now that Wheezy is released, I'd like to get an opinion from fellow project members if it is okay to add apport to the Debian unstable queue so that we can see it in time for Jessie. Apport [1] is an automated crash reporting tool. It could also be used as a bug reporting tool, but there are certain features missing (a text input to add user description), not making it a candidate for reporting bugs. For crashes, apport does a great job. It can intercept almost all crashes on the box, including Python exceptions. The implementation for Debian is very simple. There is an Apport CrashDB engine for Debian, which drafts the reports, discards the binary crash data (that can be huge), and sends it as an email to the Debian BTS. It lacks the feature to search for duplicate bug reports (like reportbug does, if online) on the BTS though. Apport for Debian currently resides in experimental with a whopping popcon stat of 11000+ installs. In the past, I have blogged [2] about apport's state in Debian, where I received some constructive feedback. 1) Duplicate bug reports: There are high possibilities that we could see a sudden increase in the number of bug reports, many duplicates. This is something I'm not sure how we want to evaluate. We could give apport a try, and leave it to the users to be more conscious when hitting submit. 2) Incomplete / Useless backtrace: This issue has been fixed. If apport senses that the backtrace is incomplete, it will not allow for the bug to be reported. 3) Incomplete / Useless backtrace (Missing debug symbols): Just like point #2, if apport detects that the debug symbol packages are missing for the package, it will deny filing the bug report. 4) Blacklisting: If a developer wants to opt-out for apport reports, they can ship hooks into /etc/apport/blacklist.d/ . There was request to completely blacklist a package on the basis of package names. This is doable. I hacked a patch in the past but it wasn't optimal. If there's a need we can work something out in a later release. I'd like to see this feature in the core apport framework though. I propose to see apport as part of the Debian archive. Having apport will help us catch many unnoticed and unreported crashes. Until some consensus is built, apport will reside in experimental only. [1] https://launchpad.net/apport [2] http://www.researchut.com/taxonomy/term/170 -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response signature.asc Description: OpenPGP digital signature
Re: Apport for Debian
On Monday 13 May 2013 03:55 PM, Arno Töll wrote: > note that, unlike Ubuntu we do not provide automated debug packages. > Hence many crash reports aren't usable at all when they are generated on > Debian systems. This could be a start. It could help users request debug packages from package maintainers. If there are missing debug packages because of which the backtrace is incomplete and useless, apport will complain and not allow to file the report. -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response signature.asc Description: OpenPGP digital signature
Re: Apport for Debian
On Monday 13 May 2013 03:22 PM, Paul Wise wrote: > Another issue is privacy; backtraces may contain private information > that should not leave the system and there is no automated way to > determine that. How does Ubuntu deal with that? Unfortunately, there's no intelligence in apport client to determine that. For the Debian crashdb, we just discard the core file from the report, before submission. The backtrace is still generated. -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response signature.asc Description: OpenPGP digital signature
Re: Apport for Debian
On Monday 13 May 2013 11:04 PM, Steve Langasek wrote: > From past discussions, I think there's a very clear consensus in favor of > doing this; it's now a SMOP. > > The requirements are, in order: > > - implement the changes necessary to ensure all binary packages in the >archive are built on the buildds, not on developers' systems[1] > - deploy centralized infrastructure, outside of the main archive, to permit >collecting debug symbols packages for distribution > - adjust the buildds to begin generating debug symbols packages >automatically - perhaps reusing pkgbinarymangler from Ubuntu, or perhaps >using it as a reference > > So I don't believe there's actually anything further to be discussed... it > just needs someone to do the work. I suggest that anyone interested in > helping should talk with the ftp team. I'll hold off the upload then until this is sorted out. For now, apport will reside in experimental. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: OpenPGP digital signature
Re: Apport for Debian
On Monday 13 May 2013 11:26 PM, Thomas Goirand wrote: > On 05/13/2013 03:06 PM, Ritesh Raj Sarraf wrote: >> > 1) Duplicate bug reports: There are high possibilities that we could see >> > a sudden increase in the number of bug reports, many duplicates. This is >> > something I'm not sure how we want to evaluate. We could give apport a >> > try, and leave it to the users to be more conscious when hitting submit. > I think that Apport is a very good idea, though I really wouldn't like > to receive so many duplicates. I had experience it with one of my > package in Ubuntu, and it was quite annoying. > > Maybe it would be possible to fix that at the BTS level, if it sees > some kind of tags from Apport? (just trowing an idea... not sure if > it is doable / desirable). Perhaps with a way to inform the BTS that > we don't want to receive emails from Apport, rather than having to > upload a new version of the package to do so? That would be IMO > better, because it would be not realistic to upload just for that > reason in the stable release. > That is a good point. Thanks Thomas. We could submit apport reports with the tag "Apport" and instruct reportbug to forward the report to "pack...@qa.debian.org". This way we avoid the flood of bug reports in general while at the same time the concerned parties are kept aware. What do other folks think? Will this model work? I know not every package has the debug symbols generated, but that item doesn't have a time line. And besides, the report can still be useful for some. > I would still consider it very valuable to receive such bug reports, > even with many duplicates. -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response signature.asc Description: OpenPGP digital signature
Hardening Flags for sg3-utils
Hi, Following the Hardening wiki, I have build-dep the hardening-includes package and enabled the hardening flags as follows : rrs@zan:/var/tmp/sg3-utils (build)$ cat debian/rules #!/usr/bin/make -f # debian/rules file for the sg3-utils package # This has to be exported to make some magic below work. export DH_OPTIONS include /usr/share/hardening-includes/hardening.make CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS) CFLAGS:=$(shell dpkg-buildflags --get CFLAGS) CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS) LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS) But still, the hardening-check tool reports this: rrs@zan:/var/tmp/Debian-Build/Result$ hardening-check /usr/bin/sg_inq /usr/bin/sg_inq: Position Independent Executable: no, normal executable! Stack protected: no, not found! Fortify Source functions: no, only unprotected functions found! Read-only relocations: no, not found! Immediate binding: no, not found! any suggestion on what could have gone wrong? Looking at the build log, I don't see the hardening flags being honored: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I ../include -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -W -g -O2 -c sg_pt_linux.c -o sg_pt_linux.o >/dev/null 2>&1 /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I..-I ../include -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -W -g -O2 -c -o sg_io_linux.lo sg_io_linux.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I ../include -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -W -g -O2 -c sg_io_linux.c -fPIC -DPIC -o .libs/sg_io_linux.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I ../include -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -W -g -O2 -c sg_io_linux.c -o sg_io_linux.o >/dev/null 2>&1 If I bump the debhelper version to > 9, I do see the correct build flags. -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response signature.asc Description: OpenPGP digital signature
Re: Hardening Flags for sg3-utils
On Tuesday 25 June 2013 09:47 PM, Nick Andrik wrote: > Would it be that you need this? > > DPKG_EXPORT_BUILDFLAGS = 1 > include /usr/share/dpkg/buildflags.mk > > -- > =Do- > N.AND > Don't know what was wrong. Maybe just the lack of sleep. Your suggestion works. Thank you. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
build warnings treated as failures
I see a sudden surge of build failures against my latest upload of packages[1]. From the build logs, it looks like all warnings are treated as errors now. If that is the case, I would like to know how others are dealing with it? Fixing every build warning [1] https://buildd.debian.org/status/package.php?p=fcoe-utils -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response signature.asc Description: OpenPGP digital signature
Re: build warnings treated as failures
On Wednesday 17 July 2013 10:45 PM, Samuel Thibault wrote: > See configure.ac in your package: > > AM_INIT_AUTOMAKE([-Wall -Werror foreign]) > > You probably want to remove -Werror and tell upstream that it's not so > good an idea. > > That being said, the warnings at stake do produce a bug: %lx is too > short for printing a u_int64_t on 32bit archs, so you actually want to > fix them. Thank you Samuel. -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response signature.asc Description: OpenPGP digital signature
Re: build warnings treated as failures
On Wednesday 17 July 2013 11:03 PM, Guillem Jover wrote: >> > >> > See configure.ac in your package: >> > >> > AM_INIT_AUTOMAKE([-Wall -Werror foreign]) > Actually, those are automake options dealing with automake warnings. > The culprit here is in Makefile.am (AM_CFLAGS). > Yes. Thanks Guillem. The actual change was in Makefile.am. I uploaded the package today and it has build successfully. -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response signature.asc Description: OpenPGP digital signature
Re: build warnings treated as failures
Taking this topic forward, I also reached out to upstream folks, asking them to fix these build errors on various architectures. I already did an upload of -3 and -4 to experimental. And I still see newer build failures popping up. My question to rest of the folks: How do you guys cope up with foreign architectures, for which you do not have direct access to the box? On Wednesday 17 July 2013 11:03 PM, Guillem Jover wrote: > On Wed, 2013-07-17 at 19:15:42 +0200, Samuel Thibault wrote: >> Ritesh Raj Sarraf, le Wed 17 Jul 2013 22:38:51 +0530, a écrit : >>> I see a sudden surge of build failures against my latest upload of >>> packages[1]. From the build logs, it looks like all warnings are treated >>> as errors now. >>> >>> If that is the case, I would like to know how others are dealing with >>> it? Fixing every build warning >> >> See configure.ac in your package: >> >> AM_INIT_AUTOMAKE([-Wall -Werror foreign]) > > Actually, those are automake options dealing with automake warnings. > The culprit here is in Makefile.am (AM_CFLAGS). > >> You probably want to remove -Werror and tell upstream that it's not so >> good an idea. > > True (for both automake and compiler warnings), at least for release > builds, as new warnings might suddenly appear with new toolchains. > > Thanks, > Guillem > > -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response -- 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/5c9ada-cmd@news.researchut.com
Bug#684161: ITP: seascope -- source code navigation tool
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: seascope Version : 0.6 Upstream Author : Anil Kumar * URL : http://code.google.com/p/seascope * License : BSD Programming Lang: Python Description : source code navigation tool Seascope is a graphical source code browsing tool with cross reference functionality support using the following backends: * cscope * idutils * ctags . Seascope is written in Python and is supported on all major operating system platforms -- 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/20120807132602.8706.52984.report...@champaran.researchut.com
Bug#684347: ITP: system-storage-manager -- system storage management tool
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: system-storage-manager Version : 0.2 Upstream Author : Lukas Czerner * URL : https://sourceforge.net/p/storagemanager/home/ * License : GPL-2+ Programming Lang: Python Description : system storage management tool System Storage Manager provides an easy to use command line interface to manage your storage using various technologies like lvm, btrfs, encrypted volumes and more. . In more sophisticated enterprise storage environments, management with Device Mapper (dm), Logical Volume Manager (LVM), or Multiple Devices (md) is becoming increasingly more difficult. With file systems added to the mix, the number of tools needed to configure and manage storage has grown so large that it is simply not user friendly. With so many options for a system administrator to consider, the opportunity for errors and problems is large. . The btrfs administration tools have shown us that storage management can be simplified, and we are working to bring that ease of use to Linux file systems in general. . You should install the ssm if you need to manage your storage with various technologies via a single unified interface. -- 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/20120808223734.20011.88997.report...@champaran.researchut.com
Bug#692529: ITP: gateone -- HTML5 web-based terminal emulator and ssh client
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: gateone Version : 1.1-1 Upstream Author : Dan McDougall * URL : http://liftoffsoftware.com/Products/GateOne * License : AGPLv3 Programming Lang: Python Description : HTML5 web-based terminal emulator and ssh client Gate One is a web-based Terminal Emulator and SSH client that brings the power of the command line to the web. It requires no browser plugins and is built on top of a powerful plugin system that allows every aspect of its appearance and functionality to be customized. Key Features * Clientless * Multi-User and Multi-Session * Multi-Auth and Single Sign-On Ready * Extendable Terminal Emulation * Embeddable and Unrestricted * Resume Sessions From Anywhere * Copy & Paste Just Works * Get Rid of Browser Plugins * Terminal Rewind * Automatation and Scripting * Proven Security and Encryption * Logging and Playback of User Sessions * Open Source & Rock Solid * Terminals of Any Size * Run Any Terminal Application * Display Images, PDFs, and More * Fast, Portable and Efficient * Make Down Time History * IPv6 Support -- 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/20121107075749.30394.49600.report...@champaran.researchut.com
Bug#705263: ITP: ioapps -- IO profiler and IO traces replayer
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: ioapps Version : 1.4.1 Upstream Author : Jiri Horky * URL : http://code.google.com/p/ioapps/ * License : GPL-v2+ Programming Lang: C, Python Description : IO profiler and IO traces replayer IOApps is an application level profiling and tracing utility suite . ioreplay is mainly intended for replaying of recorded (using strace) IO traces, which is useful for standalone benchmarking. It provides many features to ensure validity of such measurements . ioprofiler is a GUI application for profiling application's IO access pattern. It shows all the read/written files by the traced application, how many reads were performed, how much data were read and how much time was spent reading for each file. Most importantly, it produces nice diagrams showing read/write access pattern (i.e. whether the application was reading sequentially or randomly) in how big chunks etc -- 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/20130412075425.27787.98503.reportbug@dev.researchut.local
Re: Bug#605798: ITP: lldpad -- A Link Layer Discovery Protocol implementation
You should work on this at pkg-fcoe on Alioth. On 12/03/2010 09:26 PM, liang wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-CC: debian-devel@lists.debian.org > >Package name: lldpad > Version: 0.9.38 > Upstream Author: Intel Corporation > URL: http://sourceforge.net/projects/e1000/ > License: GPLv2 > Description: A Link Layer Discovery Protocol Implementation > > The lldpad package is an implementation of the Link Layer Discovery Protocol > (LLDP). It originated from Intel's Data Center Bridging (DCB) software - the > dcbd package. The lldpad package adds LLDP support for all ports in addition > to DCB Exchange protocol (DCBX) support on DCB capable ports (as was provided > by dcbd). Also, support for additional LLDP TLVs has been added. > > DCB is a collection of emerging standards-based technologies designed to allow > Ethernet to support multiple types of traffic classes in the Data Center. > The DCBX functionality of this package is designed to work with the DCB kernel > interface (dcbnl in rtnetlink) that is included in the Linux kernel 2.6.29 or > higher. The Intel ixgbe driver supports the dcbnl interface. > -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
/etc/profile.d/
Hello, I was looking at /etc/profile.d/ and was not sure how it was to function. As per LSB 4.0, every script present in /etc/profile.d/ is executed. I am thinking of a way to have a system wide shell variable that can be used and updated by further newer shell processes. Like, if I do an `export FOO="bar"` in /etc/profile.d/foo.sh, is it okay to assume that $FOO will be available throughout the OS as a system variable ? Currently, on sid, it does not seem to be executed. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Re: /etc/profile.d/
On 12/20/2010 02:11 PM, Josselin Mouette wrote: > Please don’t use profile.d to do that. Nothing guarantees you that this > variable will be available everywhere. > > This is precisely the reason why I’d rather we didn’t have such a > feature, since it inevitably gets misused in such a way - as it has been > for years by ISVs on Red Hat. Yes. I later looked more to find out bug reports on why this was discouraged. Since my application has multiple invocations based on udev events, I instead resorted to using locks. But that makes me ask: What is LSB there for ? I had looked at the latest spec and this issue was resolved/deprecated in Debian long back. Shouldn't they look into the rationale provided by Debian ? Thanks, Ritesh -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Bug#622382: ITP: lio-utils -- a simple low-level configuration tool set for LIO
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: lio-utils Version : 3.2 Upstream Author : Nicholas Bellinger * URL : http://www.linux-iscsi.org/ * License : GPL Programming Lang: C Description : a simple low-level configuration tool set for LIO lio-utils provide a simple low-level configuration tool set for LIO, including Target and its backstores including tcm_loop, and the iSCSI, FCoE and Fibre Channel fabric modules. lio-utils use the configFS kernel API that is available with LIO 3, which provides a clean interface for controlling the kernel level Target engine and its fabric module subsystems. lio-utils require LIO 3 or higher, and provide iSCSI target functionality on a number of Linux baremetal and virtualized systems. Running LIO 3 requires a newer Linux kernel (≥v2.6.29). -- 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/20110412164248.17023.67494.report...@champaran.hq.netapp.com
Bug#623847: ITP: rescan-scsi-bus -- tool for reliable scsi hotplugging in linux
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: rescan-scsi-bus Version : 1.48 Upstream Author : Kurt Garloff * URL : http://www.garloff.de/kurt/linux/ * License : GPL Programming Lang: Bash Description : tool for reliable scsi hotplugging in linux Linux allows you to add and remove SCSI devices without rebooting by using the echo "scsi add-single-device H C I L" > /proc/scsi/scsi command (H = host, C = channel, I = SCSI ID, L = SCSI LUN). The remove-single-device command works similarily. .. This tool provides an easy interface to interact with the SCSI subsystem in the linux kernel to perform SCSI Hotplugging To Debian-Devel: This package is just one single shell script. But an important one. The rescan-scsi-bus.sh script helps a lot in the SAN space where there could be targets with sporadic connecitons. Is it okay to package a single shell script as a package? -- 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/20110423162339.1875.90556.report...@champaran.hq.netapp.com
Re: Call for help from KDE Team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/01/2014 11:49 PM, Maximiliano Curia wrote: > Hi all! > > For quite a while now the KDE team has been severely understaffed. > We maintain a lot of packages, with many different kinds of bugs, > but we don't have enough people to do all the work that needs to be > done. We have tools that help us automate the update to new > upstream releases, but that's just the tip of the iceberg of our > work and so we are writing to invite more people to get involved in > the team and help us get KDE software in Debian into better shape. > Thank you for all the work you have been doing. In fact, the rate at which newer KDE releases are in the archive, was never this fast. I've been trying to do my part, in maintaining small packages in the KDE Extras Team. For KDE Core, the commitments are high. Even after the source split, the dependencies that the KDE Components have amongst each other, makes me nervous to pick one up. Perhaps I will start with monitoring the bug report and adding my input as and when necessary. Ritesh - -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTYqAFAAoJEKY6WKPy4XVpQvMP/jViTMqPEJWRocsee5QrJxCN kP42pCju0qQcxAJLYh6XCxIFLTLahxt4FSmc1S9ftQcxRQeh7Jgoi7n+O594mHbA o6us/SoP8OfyJAu2tPe34hATH1QOf3aYK4VUU81f/mSGNa7hMKeNVWmlm6owP8Y1 SKdav+R5wVYRBMsI16lgDvKlDFwXIJ8hjAjLQmOz0oVTaQwymEXEnsbWvYmvbLtN li8rrjzYCBXTggNO7hVzzLj73Lg5kfZCFHshNrAjuQrE1Q0uTd1n94Fh4H63cm+a R5SPeXejDjXE9GY5wjVs0bN64V8t33+c7A4ebgnNmfCepyHAb/z4J5/aSS4ImLoT 1nVIsdT0a6RsfUHVLgHsDSS9Pv2HpYqwkamnNOT3kn1UELwd5Br7qPu+T1cmlBbx +PA81kDw9B0nuBneO7ORx3mIYlqpcgV9hMBQ0l8EqhiXs266tjxVf0a181pKzblk CSdK3UJkXuRxDkKJD+7W7bVG5d+HxDZJcP2iq5toiEwd7NhJbzQbJ9kgohWP9B9d 9y04vKtrDevhO/1xABHxfowtgzY+n72D9fwwxoKM+UTPIsB8v6Gyv4MBi5MLCDM6 LWqTYjMpmgEgfKjCBAsIemHOMn9yhGqpfqSi6jEsJv4eG/4K0SHghAkitDxm7Cuo dKq9k0+o+pOzneTxakQt =Z1Mm -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: https://lists.debian.org/5362a00d.6040...@debian.org
Re: MATE 1.8 has now fully arrived in Debian
On 06/04/2014 11:19 AM, Thomas Goirand wrote: > oh and ... no systemd, so it can run on non-linux ports! :) On that note, how are things with OpenRC. All I've tested so far is inside my test vm, where it works fine. I'd love to have it on my work laptop, if I just had a replacement for policykit. -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response signature.asc Description: OpenPGP digital signature
Re: OpenRC status
On 06/05/2014 12:17 AM, Thomas Goirand wrote: > The current plan was to have the interpreter (of runscripts) called > openrc-run, separated from the rest of OpenRC, so it could be used when > using sysv-rc too. In that way, we could start aggressively replacing > sysv-rc scripts when Jessie is out, if openrc-run becomes a dependency > of sysv-rc. Then the choice of sysv-rc vs openrc would be only about > "the thing who starts stuff", not just sh vs openrc-run. > > But currently, it's only an idea, nobody started implementing it. > > When discussing with one of the upstream (Patrick Lauer, which I'm > hereby adding as Cc) he told me it should be easy. Patrick, would you > have some time for this? Just your explanations will not cut it for > me... Maybe when I get back home we could spend some time hacking > together? :) I went ahead and tried it on my work laptop and it failed to boot (I reported the bug against OpenRC). I may want to (passively) participate in the conversations you guys have. Do you have a mailing list for it ? -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response signature.asc Description: OpenPGP digital signature
Bug#572454: ITP: fcoe-utils -- Fibre Channel over Ethernet utilities
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: fcoe-utils Version : 1.0.11 Upstream Author : Open-FCoE Developers * URL : http://www.open-fcoe.org/ * License : GPLv2 Programming Lang: C Description : Fibre Channel over Ethernet utilities FCoE is the acronym for Fibre Channel over Ethernet, which is the encapsulation of Fibre Channel frames within Ethernet packets. .. This package will contain the Software Initiator for FCoE -- 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/20100304115026.14797.70757.report...@champaran.hq.netapp.com
Bug#572457: ITP: dcbd -- user space daemon for Intel Enhanced Ethernet for the Data Center
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: dcbd Version : 0.9.21 Upstream Author : Intel Wired Ethernet Project * URL : http://e1000.sourceforge.net/ * License : GPLv2 Programming Lang: C Description : user space daemon for Intel Enhanced Ethernet for the Data Center This package contains the Linux user space daemon and configuration tool for Intel Enhanced Ethernet for the Data Center software. .. This infrastructure is required by FCoE -- 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/20100304120955.16147.13125.report...@champaran.hq.netapp.com
Bug#572458: ITP: hbaapi -- SNIA HBAAPI library
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: hbaapi Version : 2.2 Upstream Author : SNIA <http://www.snia.org/home/> * URL : http://sourceforge.net/projects/hbaapi/ * License : SNIA Public License 1.0 Programming Lang: C Description : SNIA HBAAPI library The Host Bus Adapter API (Applications Programming Interface) is a C-level project to manage Fibre Channel Host Bus Adapters. .. This package is required for FCoE .. Couldn't find the complete license on the homepage. There is one on Fedora: https://fedoraproject.org/wiki/Licensing/SNIA_Public_License -- 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/20100304122925.16573.88974.report...@champaran.hq.netapp.com
Bug#572461: ITP: libhbalinux -- HBAAPI vendor library for Linux
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: libhbalinux Version : 1.0.9 Upstream Author : Open-FCoE Developers * URL : http://www.Open-FCoE.org/ * License : LGPLv2 Programming Lang: C Description : HBAAPI vendor library for Linux SNIA HBAAPI vendor library built on top of the scsi_transport_fc interfaces .. This package is required by FCoE -- 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/20100304123438.17224.23865.report...@champaran.hq.netapp.com
Bug#583207: RFA: fusecompress -- transparent filesystem compression using FUSE
Package: wnpp Severity: normal I request an adopter for the fusecompress package. Overall the packaging is in pretty good shape. There are a couple of bugs (forwarded upstream) that need some love. Upstream also has support for lzma in the git repo but I have not bothered backporting that. The package description is: FuseCompress provides a mountable Linux filesystem which transparently compress its content. Files stored in this filesystem are compressed on the background and Fuse allows to create a transparent interface between compressed files and user applications. -- 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/20100526113145.15288.79161.report...@champaran.hq.netapp.com
Bug#627104: ITP: rtslib -- LIO core target management framework - python libs
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: rtslib Version : 1.99 Upstream Author : RisingTide Systems * URL : http://www.risingtidesystems.com * License : AGPLv3 Programming Lang: Python Description : LIO core target management framework - python libs RTSLib Community Edition is a python library that provides an object API to RisingTide Systems generic SCSI Target as well as third-party target fabric modules written for it and backend storage objects. .. It is useful for developing 3rd-party applications, as well as serving as a foundation for RisingTide Systems userspace tools. For more information, see the rtslib API reference, available in both html and pdf formats as a separate package. -- 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/20110517181942.20433.5933.report...@champaran.hq.netapp.com
Bug#627105: ITP: configshell -- python framework for building simple CLI-based applications
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: configshell Version : 1.99 Upstream Author : Name * URL : http://www.risingtidesystems.com * License : AGPLv3 Programming Lang: Python Description : python framework for building simple CLI-based applications ConfigShell Community Edition is a python library that provides a framework for building simple but nice CLI-based applications. For more information, see the configshell API reference, available in both html and pdf formats as a separate package. .. This library is required by rtsadmin -- 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/20110517181954.20565.42614.report...@champaran.hq.netapp.com
Bug#627107: ITP: rtsadmin -- administration tool for managing LIO core target
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: rtsadmin Version : 1.99 Upstream Author : RisingTide Systems * URL : http://www.risingtidesystems.com * License : AGPLv3 Programming Lang: Python Description : administration tool for managing LIO core target RTSAdmin Community Edition is an administration tool for managing RisingTide Systems storage targets using the kernel LIO core target and compatible target fabric modules. The rtsadmin CLI is built on top of the python configshell CLI framework. -- 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/20110517182001.20090.98331.report...@champaran.hq.netapp.com
Re: Bug#627105: ITP: configshell -- python framework for building simple CLI-based applications
On 05/18/2011 12:16 AM, Adam Borowski wrote: > Could you please say "command line" instead of "CLI"? This acronym has been > tainted by .NET, this description makes one wonder whether you're talking > about command line Python tools, or some Python.NET monstrosity. > Thanks for the feedback. Sure, will do. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: OpenPGP digital signature
Re: Bug#627105: ITP: configshell -- python framework for building simple CLI-based applications
On 05/18/2011 03:49 PM, Salvo Tomaselli wrote: > On Tuesday 17 May 2011 20:19:54 Ritesh Raj Sarraf wrote: > > >> * URL : http://www.risingtidesystems.com > Are you sure this is the url of the project? > > http://www.risingtidesystems.com/git/ sorry about that. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Bug#632707: ITP: smp-utils -- SAS Expander (SMP) utilities for SAS/SATA disk arrays
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: smp-utils Version : 0.96 Upstream Author : Douglas Gilbert * URL : http://sg.danny.cz/sg/smp_utils.html * License : GPLv2 Programming Lang: C Description : SAS Expander (SMP) utilities for SAS/SATA disk arrays Utilities that send a Serial Attached SCSI (SAS) Management Protocol (SMP) request to a SMP target. If the request fails then the error is decoded. If the request succeeds then the response is either decoded, printed out in hexadecimal or output in binary. This package supports multiple interfaces since SMP passthroughs are not mature. This package supports the Linux 2.6 series. -- 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/20110705072339.13415.23677.report...@champaran.hq.netapp.com
Re: Forw/Re: Removal of systemtap from testing
On 07/29/2011 12:17 PM, Lucas Nussbaum wrote: > Please get in touch with the other systemtap maintainer (Ritesh Raj > Sarraf , Cced). He currently has the "lock" on the > update of 1.6. Help is of course welcomed. Yes, please. Any help is appreciated. If you'd like to co-maintain, please respond to this email. I'll add you to uploaders. The 1.6 packaging is almost done. It runs on my box. TODO: * 1.6 stripped down many things. The systemtap-client package is almost empty. The only worthy file it installs is stap-env. I'm not sure if that is still required (I use stap only on my local box). * There were a bunch of CVEs. We need to run through them to check which all are fixed in the 1.6 release. If they are not, we need to pull in those fixes. * There's also an FTBFS with newer gcc. That needs to be fixed. Frank, can you please confirm if the following CVEs are fixed in 1.6 ? https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-2502 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-2503 CVE-2011-1769 CVE-2011-1781 It doesn't talk about the exact systemtap version in the bug report. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Bug#638419: ITP: openxenmanager -- full-featured graphical management tool for Xen using XenAPI
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: openxenmanager Version : r48 Upstream Author : OpenXenManager * URL : http://sourceforge.net/projects/openxenmanager * License : GPL Programming Lang: Python Description : full-featured graphical management tool for Xen using XenAPI OpenXenManager is a graphical interface to manage XenServer / Xen Cloud Platform (XCP) hosts through the network. OpenXenManager is an open-source multiplatform clone of XenCenter (Citrix). -- 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/20110819083606.5543.14042.report...@champaran.hq.netapp.com
packages under the AGPL-3 license
Hello Fellow Devs, I am working on packaging the LIO tools [1]. The userspace component is licensed under AGPL-3. As per Debian bug #621462, the license is not part of common-licenses because there aren't many consumers for it, yet. I plan to document the license in the debian/copyright file and proceed. lintian reports error, E: python-configshell: copyright-should-refer-to-common-license-file-for-gpl, for which I've filed a bug report. PS: Please CC me in replies. [1] http://linux-iscsi.org/wiki/Main_Page -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Bug#649483: ITP: libstoragemgmt -- library for storage management
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: libstoragemgmt Version : git master Upstream Author : Tony Asleson * URL : http://sourceforge.net/apps/trac/libstoragemgmt/ * License : LGPL Programming Lang: C++, Python Description : library for storage management library for a vendor agnostic open source storage application programming interface (API) that will allow management of storage arrays. Planned features: Plug-in framework to facilitate storage array addition/integration Allow proprietary plug-ins (open source encouraged) Strong configurable security (TBD) Username/password, client/server certificates Interrogate/Query Capabilities, limits, versioning LUN listings Initiator listing Volume/Storage pool listing (Where to carve new logical disks) Manage logical disks (LUNS) creation (including thin provisioning) deletion re-sizing access control (LUN Masking) cloning/mirroring snapshots Command line interface for exercising API Python bindings Future features: Monitoring and alerting (asynchronous event notification) Network attached file systems (NFS, CIFS) Integrated support for LIO target (http://linux-iscsi.org) Management of SAN switches Portable, availability for Linux, Solaris and Windows Java, Perl, Ruby bindings -- 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/2021114237.5232.79365.report...@champaran.hq.netapp.com
Bug#651090: ITP: colibri -- alternate notification system for KDE4
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: colibri Version : 0.2.2 Upstream Author : Aurélien Gâteau * URL : http://kde-apps.org/content/show.php?content=117147 * License : GPL Programming Lang: C++ Description : alternate notification system for KDE4 passive notification system for kde4 colibri is a passive notification system for KDE4 desktop . Colibri notifications look lighter and are completely passive: they do not provide any buttons. You may or may not like this. Since they are completely passive, they smoothly fade away when you mouse over them, allowing you to interact with any window behind them. . They also do not stack each others: if multiple notifications happen, they will be shown one at a time. -- 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/20111205184424.18548.90899.report...@champaran.hq.netapp.com
Bug#651091: ITP: bespin -- Bespin artwork for KDE
Package: wnpp
Severity: wishlist
Owner: Ritesh Raj Sarraf
* Package name: bespin
Version : 0.r1421
Upstream Author : Thomas Luebking
* URL : http://cloudcity.sf.net
* License : GPL
Programming Lang: C++
Description : Bespin artwork for KDE
The packaging is already available at:
https://github.com/rickysarraf/debian-bespin
I'd like to see this in Debian.
Bespin is an alternative artwork for KDE. IT comprises of a couple of
tools. Details below:
Package: kde-style-bespin
Architecture: any
Depends: ${shlibs:Depends}
Suggests: kdm-theme-bespin, ksplash-theme-bespin
Conflicts: kde4-style-bespin, kwin4-style-bespin, plasma-widget-xbar
Description: A very glossy Qt4/KDE4 window decoration
Bespin is a window decoration for KDE4, the name is nothing about
quantum
mechanics, but just refers to cloud city (StarWars Episode V: The
Empire
Strikes Back)
Package: kdm-theme-bespin
Architecture: all
Suggests: kde-style-bespin
Description: A very glossy Qt4/KDE4 window decoration
Bespin is a window decoration for KDE4, the name is nothing about
quantum
mechanics, but just refers to cloud city (StarWars Episode V: The
Empire
Strikes Back)
.
This package includes the kdm theme for Bespin
Package: ksplash-theme-bespin
Architecture: all
Suggests: kde-style-bespin
Description: A very glossy Qt4/KDE4 window decoration
Bespin is a window decoration for KDE4, the name is nothing about
quantum
mechanics, but just refers to cloud city (StarWars Episode V: The
Empire
Strikes Back)
.
This package includes the ksplash theme for Bespin
Package: bespin-icon-theme
Architecture: all
Suggests: kde-style-bespin
Description: A very glossy Qt4/KDE4 window decoration
Bespin is a window decoration for KDE4, the name is nothing about
quantum
mechanics, but just refers to cloud city (StarWars Episode V: The
Empire
Strikes Back)
.
This package includes the icon theme for Bespin
--
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/20111205185052.19477.31266.report...@champaran.hq.netapp.com
Fwd: Re: Open-FCoE for Wheezy
Including debian-devel.. Original Message Subject:Re: Open-FCoE for Wheezy Date: Fri, 09 Dec 2011 18:31:01 +0530 From: Ritesh Raj Sarraf Reply-To: r...@debian.org Organization: RESEARCHUT To: debian-rele...@lists.debian.org Any suggestions? It is a new and expensive technology and hasn't seen much adoption yet. On 12/02/2011 01:14 AM, Ritesh Raj Sarraf wrote: > Hello Release Team, > > Please provide me some Release readiness assistance for Open-FCoE's > inclusion for Wheezy/Sid > > Open-FCoE [1], is a newer SAN technology to carry Fiber Channel traffic > over Ethernet. The ethernet is generalized in the definition but in > reality, a newer 10 GiB DCB Ethernet card is required for FCoE > capabilities. Also to mention the refreshes required on the switch > infrastructure. > > My initial hope was to get some access to FCoE hardware setup that I > could spare for Debian. Unfortunately, for multiple reasons that didn't > happen and I don't see having access to the hardware any time soon. > > Open-FCoE stack is currently in experimental. I have had no [bug] > reports yet. Also the popcon stats is very low. > > > The assistance I'm seeking from you is about its release readiness for > Wheezy/Sid. Should I get these packages uploaded to Wheezy/Sid? There > might not be many packaging errors, but with no real user testing in a > production environment, I have no idea how the stack will behave. > > > Should I go ahead with the inclusion of Open-FCoE into the Debian archive? > > > [1] http://www.open-fcoe.org > -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System --- Begin Message --- On Fri, Dec 9, 2011 at 18:31:01 +0530, Ritesh Raj Sarraf wrote: > Any suggestions? > > It is a new and expensive technology and hasn't seen much adoption yet. > I think debian-devel would be a better place for your question. Cheers, Julien --- End Message --- signature.asc Description: OpenPGP digital signature
Re: Fwd: Re: Open-FCoE for Wheezy
On 12/10/2011 11:07 PM, Jack Morgan wrote: > There is an effort to develop a software target along with the open-FCoE > stack. This would help reduce some of the cost by removing the need for > target and possible a switch. (back to back configuration: FCoE > initiator to software target) You would still need a 10Gb adapter on > both ends. > > There is already some support for this in opensuse, fedora and ubuntu. Yes, and these are special 10 GiB DCB Ethernet Adapters. I guess I'll push it to unstable. If there are issues reported, we'll see about its inclusion for the stable release, then. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Bug#654443: ITP: gimx -- game input multiplexer for ps3
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: gimx Version : 0.25 Upstream Author : Mathieu Laurendeau * URL : http://blog.gimx.fr/ * License : GPLv3 Programming Lang: C++ Description : game input multiplexer for ps3 GIMX stands for Game Input MultipleXer or Game Input MatriX. The purpose of this software is to control a video game console with a PC. It currently only works with the PS3, but the Xbox 360 is a also targeted. . It operates: ¤ over bluetooth: works with Linux only. A compatible bluetooth dongle is required. ¤ over usb: works with Linux and Windows. A usb-usb adapter is required. . The application gets data from the PC peripherals (mice, keyboards and joysticks) and sends controls to the PS3 over bluetooth or usb. Other controls such as gesture or voice are possible through the emulation of PC peripherals. -- 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/20120103190004.1988.44340.report...@champaran.hq.netapp.com
Bug#892412: ITA: rabbitvcs -- Easy version control
Package: wnpp Followup-For: Bug #892412 Owner: Ritesh Raj Sarraf As part of my work, I have dependence on rabbitvcs. Hence, I intend to adopt and maintain the rabbitvcs package Thanks, Ritesh
Bug#572853: ITP: thunarx-python -- Python bindings for the Thunar file manager
Package: wnpp Followup-For: Bug #572853 Owner: Ritesh Raj Sarraf I intend to take up maintenance for this package. My work currently depend on this and rabbitvcs package, which provides a rabbitvcs-thunar plugin. Since this bug has not had any activity for a long time, I am marking myself as the owner for this bug. Please let me know if you would like to co-maintain. THanks, Ritesh
package uploads not being processed
Hi, I made a couple of uploads in the last couple of weeks. I did get email confirmation for my uploads but that is it. None of my package uploads have been processed. I thought it must have been because of the Buster release freeze but I see other package uploads from other developers showing up. Neither have I received any error/rejection email nor any further package processing confirmation or the packages showing up on tracker. thunarx-python_0.5.1-1_amd64.changes uploaded successfully to localhost along with the files: thunarx-python_0.5.1-1.dsc thunarx-python_0.5.1.orig.tar.gz thunarx-python_0.5.1-1.debian.tar.xz thunarx-python-dbgsym_0.5.1-1_amd64.deb thunarx-python_0.5.1-1_amd64.buildinfo thunarx-python_0.5.1-1_amd64.deb mergerfs_2.28.1-1_source.changes uploaded successfully to localhost along with the files: mergerfs_2.28.1-1.dsc mergerfs_2.28.1.orig.tar.gz mergerfs_2.28.1-1.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org) And for rabbitvcs: https://alioth-lists.debian.net/pipermail/python-apps-team/2019-July/017020.html -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Re: package uploads not being processed
Hello Mattia, Thank you for your email. On Sat, 2019-07-20 at 14:49 +0200, Mattia Rizzolo wrote: > 20190720123419|process-upload|dak|thunarx-python_0.5.1- > 1_amd64.changes|Error while loading changes: No valid signature > found. (GPG exited with status code 0) > 20190720123419|process-upload|dak|mergerfs_2.28.1- > 1_source.changes|Error while loading changes: No valid signature > found. (GPG exited with status code 0) > > I.e. both your uploads are stuck in a loop, waiting for that > signature > to validate. > > Your GPG key is expired, so the way to go is: > 1. update your key expiry (and whatever subkey you might have used > to > sign those files) > 2. upload the updated key to keyring.debian.org's hkp endpoint > 3. wait a few days for the keyring team to pick up the change and > publish it > 4. your uploads get accepted > > Note that point 3 is going to happen in 3-5 days if everything goes > as > planned, so you should hurry, or wait for the next keyring update at > the > end of August! > > And please add a note to your calendar to update the key expiry in > the > next years. That must have been the case because in my records, it shows that the previous expiration was set to happen at 2019-06-10. I did update the expiry to 2021 in time, but maybe I forgot to explicitly send the keys to the Debian Keyring server. I have done that now and let's hope that works, soon if not now. Thanks, Ritesh -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
