Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware
Dear Raju, On Fri, Feb 16, 2018 at 09:18:06PM +0530, Raju Devidas wrote: > Hello Kumar, > > I took a look at your repository on salsa. > Before taking a look at your repository I have also taken a look at some > other repositories on github which had steps for > supporting Ubuntu on the RDP. > > Specially this one. > > https://github.com/sundarnagarajan/rdp-thinbook-linux > Indeed. I have adapted the sound and bluetooth configuration in my repository from that one. The author of that repository has helped me in getting my ISO remade with all features working. > Most of the repositories including yours do handle the issue of getting > custom Debian/Ubuntu installed on Debian with everything working. > > And I thank you and others for your work regarding this. > > However it does not solve the scenario wherein, if someone has already > installed Debian or any derivative of it, how do I get things working up > there? > > In my case I have already installed Hamara Sugam on RDP Thinbook 1130. > > By following a few steps from Sundar Nagarajan's repository, I have got > Wi-Fi working. > > Sound is not working. Bluetooth works sometimes, sometimes not. > > I also tried installing firmware-intel-sound from the firmware-nonfree > package as suggested by Praveen. > > But that didn't solved the issue either. > > > Let me know of a way which can add support to already installed > operating systems on the RDP. > > Also in your mail you mentioned about your own repo which would be added > by default on the pre-installed debian systems of RDP. > > If I can get the URL of the repo, may be I can get some packages from > there to make things working. Currently, I have not made the custom repository. I can share the URL of my preseeded configuration generated ISO, though that is designed more for an OEM-style install (it destroys the data on the PC and recreates a fresh stretch install) and it is still under development (in sync with my salsa repository). In you case, my suggestion would be to mail me offline and I can guide you. But the short story for sound is that you should get the sound-config.tar.gz from my repository: https://salsa.debian.org/akumar/debian-installer-rdp-thinbook/raw/master/sound-config.tar.gz Extract the files to /root and run /root/hardware/sound/install.sh. For more help, just mail me off-list. Also, I can share the ISO I build using the above repository; I am not publishing the URL yet because it is still evolving. Thanks. Kumar -- *** PUBLIC flooding detected from erikyyy THAT's an erik, pholx ;) -- Seen on #LinuxGER
Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware (an update)
Dear Vincent, On Sat, Feb 10, 2018 at 08:37:59PM +0100, Vincent Bernat wrote: > ❦ 11 février 2018 00:05 +0530, Kumar Appaiah : > > > - Adding my custom patched rfkill DKMS package and ensuring that > > linux-headers is also installed, so that I can use the > > preseed/late_command to build the DKMS module. > > dkms is able to build an udeb you can ship with the installer. This can > be done with "dkms mkmdeb" (this also provides a regular deb). Thanks. Since I don't really need Bluetooth during the installer, I didn't bother. But this is good to know. Kumar -- ...you might as well skip the Xmas celebration completely, and instead sit in front of your linux computer playing with the all-new-and-improved linux kernel version. -- Linus Torvalds
Maintaining a custom out-of-tree patched Debian kernel for specific hardware (an update)
Dear Debian Developers, This is a follow-up to https://lists.debian.org/debian-devel/2018/01/msg00461.html (Message-ID: <20180122140840.GA4580@odessa>). Some good people in the thread above mentioned that maintaing a forked kernel merely for two one-line patches is too much. I disagreed initially, but then, found that in recent kernels, one of the patches is not needed. For the other (related to rfkill), I managed to make a custom DKMS package with the patch included here: https://github.com/kumanna/rfkill-dkms Luckily, this seems to work. So, my customization of an official Debian ISO consists of: - Grabbing a stable DVD ISO. - Replacing the installed kernel with a more recent one from backports (should be unnecessary for testing) and ensuring that it gets chosen via preseed. - Adding custom scripts for enabling sound and bluetooth (preseeding) grabbed from https://github.com/sundarnagarajan/rdp-thinbook-linux - Adding the non-free firmware that is needed for wireless and sound. - Adding my custom patched rfkill DKMS package and ensuring that linux-headers is also installed, so that I can use the preseed/late_command to build the DKMS module. My current (hack) is documented here: https://gitlab.com/kumanna/debian-installer-rdp I intend moving this to salsa.debian.org and improving this customization. With thanks to the previous responders, I wanted to know if there are other things I should keep in mind. Let me know if I have missed any details. Thanks. Kumar -- We apologize for the inconvenience, but we'd still like yout to test out this kernel. -- Linus Torvalds, announcing another kernel patch
Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware
Dear Ian, On Tue, Jan 23, 2018 at 02:08:48PM +, Ian Campbell wrote: > > > Also, the patches being that small, what's stopping them from > > > being upstreamed? > > > > This is something beyond my understanding. Other distributions, such > > as Linux Mint, Ubuntu etc. also do not possess those patches and > > config changes. My hunch is that the Cherry Trail processors may not > > be considered popular enough for inclusion in mainline at least > > yet. So, we are going with this approach for now. Naturally, when > > that's done, we'll offer a migration path to the stock Debian kernel > > and the need for this hack will be gone. > > The patches appear to be one new ACPI match[0] and some changes to some > debug messages[1] (marked with a ".optional" suffix, so probably not > really needed). Forking the kernel packages for those trivial changes > is _way_ overkill for a first response. If those patches had been > submitted them upstream then I would expect them to be quickly and > easily merged into the relevant maintainer tree and thus be elligible > for application to the Debian kernels. > > I don't know if the kernel config changes/requirements in [2] are > complete but if they are then they seem equally trivial and certainly > worth of a discussion with the Debian kernel maintainers before > deciding to fork. > > Even simple forks are deceptively hard to back away from so avoiding > forking for trival reasons is usually a good default, or else you could > easily find yourself stuck with it for an extended period of time. > > Googling around suggests that Cherry Trail is supported in mainline > Linux today, with some last issues having been resolved in 4.11 (see > e.g. [3]). Thanks for pointing this out. Indeed, I would agree that this is the case. However, the current timeline doesn't permit me to wait for this process to happen, though I'll try to do it in parallel. My expectation is that the fork will be short lived, and eventually, the repository will provide a transition to the general Debian kernel and be removed soon. However, I'll try my best to avoid it in the first place, if time permits. > Ian. > > [0] > https://github.com/sundarnagarajan/kernel_build/blob/master/patches/001_rfkill_bluetooth_rtl8723bs_bt.patch > [1] > https://github.com/sundarnagarajan/kernel_build/blob/master/patches/002_rtl8723bs_nolinked_power_save_enter.patch.optional > [2] https://github.com/sundarnagarajan/kernel_build/blob/master/config.prefs > [3] > https://liliputing.com/2017/03/linux-4-11-brings-improvements-intel-atom-pcs-bay-trail-cherry-trail.html > Thanks. Kumar -- Linux: the operating system with a CLUE... Command Line User Environment. -- seen in a posting in comp.software.testing
Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware
On Tue, Jan 23, 2018 at 10:27:06AM -0200, Antonio Terceiro wrote: > On Mon, Jan 22, 2018 at 07:38:41PM +0530, Kumar Appaiah wrote: > > Dear Debian Developers, > > > > I am part of a team working on getting Debian on low cost laptops (see > > http://www.rdp.in for details) so that they can be sold with Debian > > preinstalled. While vanilla Debian largely works, unfortunately, > > making Bluetooth and sound work require kernel rebuilding. The patches > > and config changes are not likely to be upstreamed any time soon, so > > we would have to ship the laptop with a patched (non-Debian > > kernel). Our team is, thus, taking up the responsibility of ensuring > > that up-to-date kernel (with security fixes) are made available to the > > users of our laptop. The patches and configs are adapted from here: > > https://github.com/sundarnagarajan/kernel_build > > Are the the patches you need are really just those in patches/? If yes, > they are small enough that if I were in your place I would talk to the > Debian kernel team to see if they can be included in the official Debian > kernel. > > Also, the patches being that small, what's stopping them from > being upstreamed? This is something beyond my understanding. Other distributions, such as Linux Mint, Ubuntu etc. also do not possess those patches and config changes. My hunch is that the Cherry Trail processors may not be considered popular enough for inclusion in mainline at least yet. So, we are going with this approach for now. Naturally, when that's done, we'll offer a migration path to the stock Debian kernel and the need for this hack will be gone. Thanks. Kumar -- lp1 on fire (One of the more obfuscated kernel messages)
Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware
On Tue, Jan 23, 2018 at 10:02:55AM +, Ian Campbell wrote: > On Mon, 2018-01-22 at 19:38 +0530, Kumar Appaiah wrote: > > 1. The laptop will ship with stretch preinstalled, but with a custom > > kernel built using the linux-source-x.xx.xx package with a custom > > version number, such as linux-image-4.14.13-iitb-amd64. > > A silly nitpick but the "4.14.13-iitb-amd64" in package a named "linux- > image-4.14.13-iitb-amd64" is actually the kernel ABI (4.14.13-iitb) and > arch (amd64) which is not exactly/necessarily the same as the version. > There is also a third field "flavour" which you don't have here but > which would go between the two e.g. "linux-image-4.14.0-3-rt-amd64" is > a rt patched kernel. > > You should definitately give the package a distinct version and you > should _probably_ give it either a distinct ABI or flavour (or possibly > both). You will probably also want to put a digit in your distinct ABI > so you can rev it if needed. Thanks for pointing this out. Do you mean something like linux-image-4.14.13-2-iitb-amd64? > > 4. Users will be made aware of the fact that this is Debian with a > > custom kernel without ambiguity. > > I _think_ you can add hooks/files to the package so that reportbug DTRT > here, but I don't know the specifics of how. I will figure this out. Thanks for the suggestion. Kumar -- ...[Linux's] capacity to talk via any medium except smoke signals. -- Dr. Greg Wettstein, Roger Maris Cancer Center
Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware
Dear Daniel, On Tue, Jan 23, 2018 at 01:34:32AM +0100, Daniel Reichelt wrote: > Hi, > > what about ripping out the affected kernel modules and provide the > patched sources in a separate package and have them built at install > time via DKMS? > > In order to not interfere with the modules provided by the linux-image-* > packages, you could > > - rename the kernel modules provided by your module package > - add the original module names to a blacklist in /etc/modprobe.d > - add your modules to /etc/modules-load.d/something > - and finally add the blacklist and load list to your package as well. > > (An alternative to changing module names might be to use > update-alternatives or dpkg-divert and just provide/integrate the > renamed .ko files) > > The initial setup of the packaging/build script will require a bit of > fiddling around but in the long run you'll be able to provide your users > with updates much faster and without havingt to go through the > time-consuming kernel build process. Moreover, the required storage and > bandwith for the infrastructure holding your repository will be tiny > compared to those for holding a full-blown kernel package. Thanks for the idea. The reason we don't prefer this at the moment is two-fold: 1. This would lead to "forking" some parts of the kernel source and having to track them separately. 2. More importantly, we hope that this is a temporary measure, since we hope that the patches will be eventuall upstreamed and the kernel configs will also reflect the changes required. If this becomes a longer term requirement, I will use your idea though. Thanks. Kumar -- As usual, this being a 1.3.x release, I haven't even compiled this kernel yet. So if it works, you should be doubly impressed. -- Linus Torvalds, announcing kernel 1.3.3
Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware
On Tue, Jan 23, 2018 at 10:14:42AM +0100, Jonas Smedegaard wrote: > > Thanks. I'll keep this in mind. The only point I'd like to emphasize > > is that we are clear that ours will NOT be a derived distribution; our > > Debian will have only a few kernel line diffs with the pristine > > Debian, and no further changes. And, like I have pointed our to Ian, > > we intend informing the users that this is the case, and provide the > > changes we have made through the same distribution channel as our > > modified packages. > > Technically _any_ derivation from Debian makes it a derivative, but I > understand your point and appreciate it quite much! Indeed, I agree with you technically, though I am glad you comprehend my spirit! :-) Kumar -- Avoid the Gates of Hell. Use Linux (Unknown source)
Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware
Dear Jonas, Good to hear from you. On Mon, Jan 22, 2018 at 04:29:22PM +0100, Jonas Smedegaard wrote: > Hi Kumar, > > Quoting Kumar Appaiah (2018-01-22 15:08:41) > > I am part of a team working on getting Debian on low cost laptops (see > > http://www.rdp.in for details) so that they can be sold with Debian > > preinstalled. > > Looks quite interesting! Thanks for packaging raising questions here. > > > > 1. The laptop will ship with stretch preinstalled, but with a custom > > kernel built using the linux-source-x.xx.xx package with a custom > > version number, such as linux-image-4.14.13-iitb-amd64. > > > > 2. The installation will contain a package called > > linux-image-iitb-amd64 that conflicts with linux-image-amd64, and this > > package will depend on the latest patched kernel built in the previous > > step. > > Specifically regarding repackaging and versioning of derived packages, I > recommend that you follow the guidelines for Derivatives: > https://wiki.debian.org/Derivatives/Guidelines#Packages > > You might find other things in that and related wiki pages useful too > :-) Thanks. I'll keep this in mind. The only point I'd like to emphasize is that we are clear that ours will NOT be a derived distribution; our Debian will have only a few kernel line diffs with the pristine Debian, and no further changes. And, like I have pointed our to Ian, we intend informing the users that this is the case, and provide the changes we have made through the same distribution channel as our modified packages. Thanks again! Kumar -- lp1 on fire (One of the more obfuscated kernel messages)
Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware
Dear Ian,
On Mon, Jan 22, 2018 at 02:32:21PM +, Ian Jackson wrote:
> Kumar Appaiah writes ("Maintaining a custom out-of-tree patched Debian kernel
> for specific hardware"):
> ...
> > 4. Users will be made aware of the fact that this is Debian with a
> > custom kernel without ambiguity.
> >
> > Now, whenever there is a kernel update in Debian, our team will fetch
> > the source of the updated kernel, patch, rebuild and make it available
> > in our repository.
> >
> > Please let me know if the proposed solution is good, else I am open to
> > suggestions.
>
> Thank you for asking and for paying attention to the needs of your
> users.
>
> This seems like a good approach to me.
>
> One thing you don't explicitly say is how you will distribute the
> source code for your custom kernel. It's sort of left implicit in
> your email. You absolutely must make available the source code.
> (Reading your mail I think you probably know this but I wanted to make
> it explicit.)
>
> Best would be to provide both (i) a Debian-format source package (.dsc
> et al) in your apt repository, so apt-source works and (ii) your
> version control branch (git branch) on some git server. Mention both
> of these in some README that gets installed with the kernel.
My current plan is to provide the source package in the same
repository in which I will distribute the binary packages. I will also
add a link to a repository where I manage these changes. The Readme
will be clear about this.
One question I have is, if I plan to just track the
linux-source-x.xx.xx package, should I import that source into my Git
tree, or just maintain the patches?
Thanks.
Kumar
--
Linus? Whose that?
-- clueless newbie on #Linux
Maintaining a custom out-of-tree patched Debian kernel for specific hardware
Dear Debian Developers, I am part of a team working on getting Debian on low cost laptops (see http://www.rdp.in for details) so that they can be sold with Debian preinstalled. While vanilla Debian largely works, unfortunately, making Bluetooth and sound work require kernel rebuilding. The patches and config changes are not likely to be upstreamed any time soon, so we would have to ship the laptop with a patched (non-Debian kernel). Our team is, thus, taking up the responsibility of ensuring that up-to-date kernel (with security fixes) are made available to the users of our laptop. The patches and configs are adapted from here: https://github.com/sundarnagarajan/kernel_build The unfortunate situation is that I am forced to issue this patched kernel. Since I'd like to be a good citizen of the ecosystem, I'd like to outline the solution I have in mind. I'd like your opinion and suggestion on this. All code being developed for this purpose will be released under a DFSG compliant license, and all packages I refer to that aren't in Debian will lie in our custom (outside of Debian) repository. If there are any things I can do to make things better, please do let me know. 1. The laptop will ship with stretch preinstalled, but with a custom kernel built using the linux-source-x.xx.xx package with a custom version number, such as linux-image-4.14.13-iitb-amd64. 2. The installation will contain a package called linux-image-iitb-amd64 that conflicts with linux-image-amd64, and this package will depend on the latest patched kernel built in the previous step. 3. The sources.list on the installation will have an entry pointing to my custom repository in addition to the regular http://deb.debian.org, and will be pinned so that the kernel and kernel related packages are obtained from my custom repository. Needless to say, the custom repository's public key will also be pre-shipped with the laptop. 4. Users will be made aware of the fact that this is Debian with a custom kernel without ambiguity. Now, whenever there is a kernel update in Debian, our team will fetch the source of the updated kernel, patch, rebuild and make it available in our repository. Please let me know if the proposed solution is good, else I am open to suggestions. Thanks. Kumar -- Computers are like air conditioners. Both stop working, if you open windows. -- Adam Heath
Re: Need advice on building a package
On Wed, Feb 12, 2014 at 04:10:25PM -0800, Schlacta, Christ wrote: >On Wed, Feb 12, 2014 at 2:51 PM, John Holland <[1]jholl...@vin-dit.org> >wrote: > > I got some debs built for E 18 not 17 gby oing from the source on > [2]enlightenment.org and building them on Wheezy. They've been working > pretty well for me on a couple machines. > >Thank you for the suggestion, but I'm strictly attempting to stick to >backporting packages from Jessie to maintain upgradability later. Would this be useful? This would enable you to use packages built as build-dependencies for next packages. Naturally, you should update the build-dependencies as well to use the backported ones. https://wiki.debian.org/PbuilderTricks#How_to_include_local_packages_in_the_build Kumar -- Dijkstra probably hates me. -- Linus Torvalds, in kernel/sched.c -- 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/20140213004215.GA19661@odessa
Re: NDEBUG when building packages?
On Fri, Jun 07, 2013 at 11:12:52PM +0200, Kurt Roeckx wrote: > > Currently, I don't bother with this, since the the debug library with > > -O2 is still useful, other than the odd "optimized out" messages. > > As I understand it, with dwarf 4 you should see less problems > trying to debug optimised programs. Dwarf 4 is enabled by default > in gcc 4.8 and supported by gdb 7.5. Thanks. This is useful to know! Kumar -- It's computer hardware, of course it's worth having -- Espy on #Debian -- 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/20130608050352.ga...@bluemoon.alumni.iitm.ac.in
Re: NDEBUG when building packages?
On Fri, Jun 07, 2013 at 08:29:52AM -0400, Stephen M. Webb wrote: > Having debug symbols not matching the runtime would cause a great deal of > trouble. If you're expecting a lot of > debugging, try the new -Og switch. > > One build pass and let dh_strip create the debug symbols package for you. > Unless you're not using dh, in which case > your build system is probably already broken and needs to get fixed first. I see your point. I already use dh_strip, but I think I'll stick with -O2. Kumar -- Whoa...I did a 'zcat /vmlinuz > /dev/audio' and I think I heard God... -- mikecd on #Linux -- 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/20130608050446.gb...@bluemoon.alumni.iitm.ac.in
Re: NDEBUG when building packages?
On Fri, Jun 07, 2013 at 11:54:49AM +0200, Mathieu Malaterre wrote: > cmake from sid makes it even harder. RelWithDebInfo now contains > -DNDEBUG ... I have to source-upload all my packages :( > > $ grep NDEBUG ChangeLog.manual > Add -DNDEBUG to RelWithDebInfo flags where where Release flags had it. > > > The solution (backward compat) is now: > > Either do *not* define CMAKE_BUILD_TYPE, or define CMAKE_BUILD_TYPE to > Debug (and hope -DNDEBUG does not creep in ever) While we're at it, could you please let me know what is the best practice for package builds that generate debug symbol packages? Ideally, I would hapve to rebuild the whole package TWICE, once with -O0 -g, and the other time with -O2, right? Currently, I don't bother with this, since the the debug library with -O2 is still useful, other than the odd "optimized out" messages. In addition, I don't want to add an additional burden to the buildds for this, since the package is probably never used on architectures other than i386/amd64. Thanks. Kumar -- mar...@bdsi.com (no longer valid - where are you now, Martin?) -- from /usr/src/linux/drivers/cdrom/mcd.c -- 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/20130607113421.ga14...@bluemoon.alumni.iitm.ac.in
Re: "Hijacking packages for fun and profit" BoF at DebConf
Dear debian-devel, On Fri, Jul 20, 2012 at 07:24:15PM +0100, Steve McIntyre wrote: > Here's a summary of what we discussed in the BoF [1] last week (12th > July). Thanks to the awesome efforts of the DebConf video team, the > video of the session is already online [2] in case you missed it. I've > also attached the Gobby notes that were taken during the session. I'd > like to express my heartfelt thanks to the people who took part - we > had a very useful and productive discussion on a potentially very > controversial topic. It would be good to continue the discussion with > a wider audience. Thank you for conducting this, and to the video team for putting this up. I have some follow-up questions and comments. If there is something I am missing in what I say, or I am incorrect, please do correct me. > * if a package is *un* maintained? > * if a package is *badly* maintained? > * if a package is not maintained how you'd like? > * if the maintainer is MIA? > * if the Tech Committee say so? > Claimed that the Tech Committee have never explicitly handed over > a package as a decision, although apparently lilo maintainership > was decided by the RC > * lack of uploads > * RC buggy without comment > Or -- interestingly -- RC buggy, and bug is closed without comment > on the particular bug > * not packaged as you would like it packaged > * the maintainer is a bully towards bug reporters? (i.e. misbehaves) > (So package is maintained, just... hurtfully) Several of these might overlap, and some of these seem a little harsh without additional qualifications. For instance, "not maintained how you'd like" and "not packaged the way you would like it packaged" aren't clear, although I can see where that would make a difference (interdependent packages, convenient location of libraries, scripts etc.). Similarly, "lack of uploads" makes sense only if there is either a long divergence from upstream for no good reason. It might be clear to those who are reading it, but I just felt happier qualifying it the way I understand it. > A common concern during the discussion was that in general people are > wary of making this kind of decision; hijacking and package removals > can easily become controversial as maintainers feel ownership or even > emotional attachment. A larger question which the project must address is that of culture. How much of ownership over a package do you have? Would you be offended if someone makes a change in your package which you wouldn't approve of? Now, if the change is prompted by someone who hasn't even waited a month for the maintainer's response, then the maintainer has good reason to be miffed about it. However, in the context of a hijack due to delay, I'd say that the maintainer has lost a little of his/her say in the matter owing to the long period of inactivity. This doesn't (and shouldn't) reflect badly on that person; after all, it's a volunteer driven project. However, if there is something in our culture which makes the attachment to the package more technical than emotional (i.e. "I package this library because I co-wrote it, or I use it every day, or I am an expert" vs. _just_ "I packaged this first, so I should have the final say"), I would love to learn about it. > Hijack tokens > - > At the moment, *any* uploading DD can hijack by simply uploading a new > package version. Is that reasonable, or should we attempt to control > it somehow? There was a concept suggested of "hijack tokens" - an idea > that maintainers should be allowed to hijack packages so long as they > show sense. Only one hijack would be allowed per DD by default, with > maybe more tokens being allocated depending on age / experience / > responsibility within the project. The tokens could be allocated to > developers by the Tech Committee, or maybe restored after review once > a hijack has happened. Potentially problematic, but maybe a useful > idea for discussion? My query with regard to this is whether the size of the problems it solves far exceed the amount of bureaucracy it introduces. Ideally, right from the NM process, we are asked what our "agenda" or ideal contribution for Debian would be. Based on that, I can say with reasonable assurance that you will not find me uploading glibc and gcc tomorrow. However, since I had a grip on some other things, I could help with NMUs (not really hijacks) for the gfortran transition some years ago. Why wouldn't a mere NMU be sufficient? Wouldn't enough affected parties raise alarm bells if the NMU contains bogus fixes? I fear that this might also dissuade people from going for an upload they aren't convinced about. Then again, I might be totally missing the point! :-) Thanks again! Kumar -- Not only Guinness - Linux is good for you, too. -- Banzai on IRC -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.or
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
Hi. On Mon, Mar 26, 2012 at 09:17:53AM +0100, Neil Williams wrote: > > b) useful for the Debian project since experienced people may > >immediately point that there are/there were some problems which > >prevented the package to be added before or made the package > >disappear from Debian archives in the past; > > c) useful for the Debian project since experienced people may ask > >the ITP owner why to package the thing at all if they know/suspect > >there are superior things in the archive already; > > d) useful for the Debian project because people sometimes choose > >too confusing/short names for packages, and answering to an ITP > >is usually the only chance for the public to suggest some better > >name before the package entered the archive, after which the renaming > >is more time-consuming and bureaucratic; > > All of which can be good for those new to packaging but those who would > do the commenting are generally reasonably proficient at anticipating > such issues and choosing sensible names etc. from the beginning. Well, much like code review, a sanity check might be useful sometimes. Just a minor suggestion to improve something could crop up. I always prefer to have my ideas checked by someone else, but then, that's my preference. > I have still used ITPs for recent packages but the packages were all > uploaded within minutes of filing the ITP and closed within hours. As > Joey describes, I was waiting for the bug number in order to make the > changelog entry, create a tag in the VCS and upload. It does make the > whole ITP process seem a waste of time and I might not bother in future > as there is not going to be any real opportunity for anyone to comment > on the ITP in that time. I am guessing that the ITP was closed in hours because of NEW processing. So, to be clear, how does waiting "minutes" for the bug number when it will be processed in "hours" make it a waste of time? > > > The appropriate thing to do when confronted with a months-old ITP > > > for a package with the same content or name as your package is almost > > > certianly to ignore old "intent" and get on with it. > > > > Absolutely disagree. Hijacking the ITP and/or package name without > > saying a single word about that to the ITP bug thread is just plain > > rude. > > I think ITP's should have a strict and absolute time limit - there is > already some work to monitor aged ITP's/ITA's and rename to RFP: or O: > but actually packaging something does not take long and if there are > reasons to delay a particular package, it can be mentioned in a comment > to the ITP or elsewhere. If an ITP remains open without comment for > more than a month, the chances that there will ever be an upload to > close it are close to zero. If the upload is simply waiting for a > sponsor then *say so* in the ITP and put a link to mentors.debian.net. > > ITP bugs must not be allowed to block actual work. It's equivalent to > domain-squatting and just as distasteful. This is taking it to an extreme. Even in the case of domain-squatting, the first attempt to fix the problem would be to contact the domain owner and make a gentle request to vacate. In this case, I frankly don't see the need to hijack an ITP without doing so. > Otherwise, if you are not going to upload within a month of filing the > ITP, then *close the ITP*. There should be no complaints if someone > else assumes that the ITP is stale if there have been no comments on it > for the last month. This may be your opinion, but I would still opine that it would be decent to ask the ITP owner as to why he or she has not got back to uploading it yet. However, my timelines differ greatly, and having the package in the archive very quick may suit your requirements better. Thanks. Kumar -- Make it idiot-proof, and someone will breed a better idiot. -- Oliver Elphick -- 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/20120326122609.ga7...@bluemoon.alumni.iitm.ac.in
Re: Teams in changelog trailers
On Sat, Feb 18, 2012 at 08:01:14PM -0600, Kumar Appaiah wrote: > On Sat, Feb 18, 2012 at 04:24:39PM +0100, Cyril Brulebois wrote: > > Kumar Appaiah (18/02/2012): > > > > This would: > > > > 1) allow to always identify person responsible for a particular upload; > > > > > > To be very pedantic, the signature on the last upload should reveal > > > this, right? > > > > Not if the team upload is prepared by someone who then gets sponsored by > > a DD (or a DM from the relevant team). > > In which case the sponsor of the upload is responsible for the upload, > right? The person signing and uploading is "responsible" for the > content of the upload, whether directly as the person who prepared the > upload or as someone who has checked what is being sponsored before > uploading it. The signer is taking responsibility, if I understand correctly. But pedantry aside, I am also for Jakub's original suggestion. Kumar -- I did this 'cause Linux gives me a woody. It doesn't generate revenue. -- Dave '-ddt->` Taylor, announcing DOOM for Linux -- 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/20120219021329.gc12...@bluemoon.alumni.iitm.ac.in
Re: Teams in changelog trailers
On Sat, Feb 18, 2012 at 04:24:39PM +0100, Cyril Brulebois wrote: > Kumar Appaiah (18/02/2012): > > > This would: > > > 1) allow to always identify person responsible for a particular upload; > > > > To be very pedantic, the signature on the last upload should reveal > > this, right? > > Not if the team upload is prepared by someone who then gets sponsored by > a DD (or a DM from the relevant team). In which case the sponsor of the upload is responsible for the upload, right? The person signing and uploading is "responsible" for the content of the upload, whether directly as the person who prepared the upload or as someone who has checked what is being sponsored before uploading it. The signer is taking responsibility, if I understand correctly. Thanks. Kumar -- I've heard a Jew and a Muslim argue in a Damascus cafe with less passion than the emacs wars." -- Ronald Florence in -- 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/20120219020114.gb12...@bluemoon.alumni.iitm.ac.in
Re: Teams in changelog trailers
Hi. On Sat, Feb 18, 2012 at 03:08:50PM +0100, Jakub Wilk wrote: > Now that we have a concept of a “team upload”[0], I'd like to have > putting team's name in the changelog trailer officially deprecated. > > This would: > 1) allow to always identify person responsible for a particular upload; To be very pedantic, the signature on the last upload should reveal this, right? > 2) help to avoid situations where (inadvertently) no human name is > mentioned in a changelog entry at all. > > What do others think? One problem arises if the last person who "made" the upload (in case it was sponsored) does not put his/her name. I just wish to know what other situations where having just team uploads makes life harder. Thanks. Kumar -- Footnotes are for things you believe don't really belong in LDP manuals, but want to include anyway. -- Joel N. Weber II discussing the 'make' chapter of LPG -- 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/20120218151321.ga4...@bluemoon.alumni.iitm.ac.in
Re: Bug#601596: RFH: festival -- General multi-lingual speech synthesis system
On Mon, Aug 15, 2011 at 09:33:50AM +0800, YunQiang Su wrote:
> Would you found a TTS team?
> and invite all TTS packager to join it?
This would be the ideal solution. I'd love it for people interested to
come forward in this effort.
Thanks!
Kumar
--
/*
* Oops. The kernel tried to access some bad page. We'll have to
* terminate things with extreme prejudice.
*/
die_if_kernel("Oops", regs, error_code);
-- From linux/arch/i386/mm/fault.c
--
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/20110815030313.ga21...@bluemoon.alumni.iitm.ac.in
Re: Bug#601596: RFH: festival -- General multi-lingual speech synthesis system
retitle 601596 O: festival -- General multi-lingual speech synthesis system thanks Dear Debian developers and contributors, (Apologies for the cross post) On Wed, Oct 27, 2010 at 12:46:36PM -0500, Kumar Appaiah wrote: > I request assistance with maintaining the festival (and speech-tools) > package. The package is in a "good" state as of now, but it does have > a TODO list and could do with some love. While I try to do my best > with festival, since I am not familiar with the various sound > subsystems the package seems to depend on, I would be much more > comfortable if someone else steps in to oversee, assist and, > eventually, take over maintenance of the package. > > If a team is willing to take over, or a team is formed for this package. > > This mail has been sent with permission from the other co-maintainers > as well. > > Thanks! > > The package description is: > Festival offers a full text to speech system with various APIs, as well an > environment for development and research of speech synthesis techniques. It > includes a Scheme-based command interpreter. > . > Besides research into speech synthesis, festival is useful as a stand-alone > speech synthesis program. It is capable of producing clearly understandable > speech from text. It has almost been 10 months since the RFA, and since filing it, neither have we been able to step up in maintaining the package better, nor did we receive any offers for help. Therefore, regretfully, we have decided to orphan festival (and, in a subsequent e-mail, speech-tools as well). Since festival is a fairly important package, it deserves more care and attention in keeping it up to date. So, it would be great if an individual or team could step up to fill the void. Needless to say, we would be glad to help out in the team as well as we can. xThanks. Jaldhar, Kartik and Kumar (erstwhile maintainers of festival and speech-tools) -- Kumar Appaiah signature.asc Description: Digital signature
Re: Source code
On Mon, Jan 03, 2011 at 04:55:52PM -0800, Don Armstrong wrote: > On Tue, 04 Jan 2011, Stephen Grant Brown wrote: > > I would like to install dpkg under Windows Vista. > > This is almost certainly going to be an exercise in pain. For building it, maybe, but not for getting it prebuilt. Cygwin ports has a version: (From ftp://sourceware.org/pub/cygwinports/portslist.txt) dpkg 1.15.7.2-1 HTH. Kumar -- ...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and the Ugly). -- Matt Welsh signature.asc Description: Digital signature
Bug#601596: RFH: festival -- General multi-lingual speech synthesis system
Package: wnpp Severity: normal X-Debbugs-CC: debian-accessibil...@lists.debian.org Dear Debian users and contributors, I request assistance with maintaining the festival (and speech-tools) package. The package is in a "good" state as of now, but it does have a TODO list and could do with some love. While I try to do my best with festival, since I am not familiar with the various sound subsystems the package seems to depend on, I would be much more comfortable if someone else steps in to oversee, assist and, eventually, take over maintenance of the package. If a team is willing to take over, or a team is formed for this package. This mail has been sent with permission from the other co-maintainers as well. Thanks! The package description is: Festival offers a full text to speech system with various APIs, as well an environment for development and research of speech synthesis techniques. It includes a Scheme-based command interpreter. . Besides research into speech synthesis, festival is useful as a stand-alone speech synthesis program. It is capable of producing clearly understandable speech from text. -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) -- 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/20101027174636.ga9...@146653177.ece.utexas.edu
Re: How to make Debian more attractive for users
(CCing OP, assuming he isn't subscribed) On Mon, Jul 26, 2010 at 05:05:19PM +0100, Russell Gadd wrote: > I spotted this topic in Debian Project News. I am a non-technical Debian > user (Lenny AMD 64 bit) - I have tried Ubuntu a couple of times but came > back to Debian because of its stability. The main problem I have is lack of > up to date Flash in the browser (Iceweasel) and I think this is a common > problem with other users. I have to resort to using Microsoft Windows > sometimes as Flash is being used more and more by websites. Maybe it's a > Linux problem not just Debian - I don't know, but it is frustrating. > > Anything you could do to resolve this would be very welcome. The sad part is that Flash, at least the original one from Adobe, is proprietary and closed source software, and official updates and fixes happen at the will of the company; and with most other proprietary software, stepmotherly treatment for Linux is the norm when it comes to updates, whether it is for features or fixes. Unless and until a "free" version of Flash comes out/one of the existing ones become much more usable, it is unlikely that this situation will change. > I hope this email is of some help to you, but you do not need to acknowledge > or reply to this email. Please accept my thanks to you and your colleagues > for all the tremendous work you do for the Debian community. Thank you. Good user feedback, bug reports and participation in the community helps Debian a lot as well. Kumar -- 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/20100726163028.ge13...@bowser.ece.utexas.edu
Re: RESPECTED SIR
On Wed, Apr 21, 2010 at 07:28:12PM +0530, Ramkrishan Raghuwanshi wrote: > Respected sir, I am ram krishan raghuwanshi from Indore, Madhya Pradesh > India�s > want to use Debian packages > >But I don�t have money. So sir please send me on my following address if u >you can:- Unfortunately, Debian is a volunteer organization, not a charity, so we can't donate money to you. Kindly do not mail this list unless you want to participate in technical discussions related to Debian development. Thank you. Kumar -- All the existing 2.0.x kernels are to buggy for 2.1.x to be the main goal. -- Alan Cox -- 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/20100421142702.gd17...@146653177.ece.utexas.edu
Re: Has Debian abandoned Python?
On Thu, Dec 03, 2009 at 04:34:42PM -0500, James Vega wrote: > >> Version: 2.6.2-0ubuntu1 (jaunty) > >> Apparently uploaded *33 weeks* ago. > > > > Perhaps more germane to the head of this thread is that python3.0 is not > > in Debian, but prereleases were added to Ubuntu apparently in 2007. > > The python3.1 package has been in experimental since March of this year. > I'm not positive, but I don't think python3.0 was ever uploaded to > Debian. This was indicated by the maintainer to the debian-python list: http://lists.debian.org/debian-devel/2009/02/msg00431.html (last point in the first section). Kumar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Has Debian abandoned Python?
On Thu, Dec 03, 2009 at 10:08:15AM -0600, Kumar Appaiah wrote: > True. IIUC, From a technical point of view, the Social Contract > demands commitments from contributors with regard to their work for > Debian; and nobody has committed to do X in Debian before they do it > for someone else. So, I believe it'd be unwise to use one's > affiliations outside of Debian as a means to justify one's complaint. That should read: "unwise to use someone's affiliations outside of Debian as a means to justify one's complaint." Kumar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Has Debian abandoned Python?
On Thu, Dec 03, 2009 at 04:58:58PM +0100, Andreas Tille wrote: > On Thu, Dec 03, 2009 at 04:48:37PM +0100, Frans Pop wrote: > > So yes, I do have a problem with the way Canonical is taking developer > > commitment away from Debian, at least if and when maintainers no longer > > honor their Debian commitments *and* do not allow others to take over the > > work for Debian. > > I do not completely agree that this is Canonical's fault. IMHO it is > our fault as well if we do not step in by using the defined ways we have > (Technical Committee) and sort out the situation for the profit of our > users. Allowing *any* maintainer (be it an Ubuntu employee or not) to > block important packages should not happen and I do not think that we > should mix up this situation with Ubuntu relations which might or might > not here one specific reason for the maintainer. But there could be > other reasons as well and we should care for the fact in general instead > of fighting a Debian - Ubuntu flamewar. (Please correct me where I am wrong) True. IIUC, From a technical point of view, the Social Contract demands commitments from contributors with regard to their work for Debian; and nobody has committed to do X in Debian before they do it for someone else. So, I believe it'd be unwise to use one's affiliations outside of Debian as a means to justify one's complaint. Thanks. Kumar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
(Note: I am not a porter, so please correct anything wrong I say below) On Thu, Nov 19, 2009 at 08:29:53AM +0900, Charles Plessy wrote: > How about the porters responsability towards the project ? For instance, hppa > is blocking the testing migration of a couple of my packages, and probably the > packages of many other maintainers as well. Why would it be my duty to help > people running Debian on machines that are not used in my profession, and for > which I have no qualification at all? Because of DFSG point 4: "Our priorities are our users and free software". Believe it or not, I've never _imagined_ that some software which are in Debian are actually used on non-x86ish hardware. However, people want to do weird things on weird non-x86ish machines, and they like Debian because they Debian enables them to natively use the very same tools used by ordinary PC users on, say, their embedded machines for low power solutions for various automated tasks. They love it. > I do not want to prevent people having fun with Debian on this arch, > so wouldn't the best solution to never build my package on their > arch in the first place? It would reduce the number of issues to > solve in both groups, Debian Med and the hppa porters, which like > every other group in Debian severely lack manpower. Your complaint makes sense. But such policies are in place because Debian wants to allow for all its users to have all goodness, irrespective of computer type. While it may seem that your packages are (unfairly) being blocked from migration due to one particular architecture's lag, removing a package from that architecture would be looked upon as a regression uniformly, irrespective of whether such packages are used on that architecture or not. You never now on which day someone would decide to try something fancy with your package on a fancy architecture; we don't want to disappoint him/her by saying "Hey, sorry, it was too painful for us to keep providing the package on your architecture, so we just removed it"; (thereby, in my opinion, not fulfilling DFSG 4). Of course, if the architecture fails the release qualification, then it's a different matter. Kumar -- Why are there always boycotts? Shouldn't there be girlcotts too? -- argon on #Linux signature.asc Description: Digital signature
Re: Debian means 'closer to Windows'?
Dear Marek, On Sun, Nov 15, 2009 at 04:53:45PM +, Marek Artur Penther wrote: > When Debian started to mean 'closer to windows'? > I want to use Debian, because I love this OS, but developers cutting this > love > by abadoning i386 arch. Sorry, but Windows making bigger minimal requirments, > and not Debian. And now it's changed? > And this new minimal requirments making my computer completly obsolete? > It's madness! > Even Windows 7 don't making my computer completly obsolete, and Debian 6.0 > making it. You seem to be having some trouble with your Debian installation, which is making it slow (to the best of my understanding). It would make it easier for us to help you if you could focus on the problems you are facing, and mail about it to the debian-user list, where people can offer suggestions and workarounds. I have been using Debian GNU/Linux for years, and have had the opposite experience. On most machines I have installed Debian on, it has performed much faster than Microsoft Windows, and all of these were i386 machines. The minimum requirements are fairly low as well. > I can't understand. Do you want to better then Microsoft? > So why you cutting me from our community? We are not cutting you from our community. Please bring your problems to the Debian users' list, and you will most likely get sound advice on how to resolve your problems with Debian GNU/Linux. HTH, and thanks. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Bug#546270: ITP: taggrepper -- search and match tags of media files against regular expressions
Package: wnpp Severity: wishlist Owner: Kumar Appaiah * Package name: taggrepper Version : 0.03 Upstream Author : Kumar Appaiah (myself) * URL : http://gitorious.org/taggrepper/pages/Home * License : BSD Programming Lang: C Description : search and match tags of media files against regular expressions taggrepper is a small tool written to "grep" tags of media files. Currently, it can be used to match some or any tags of MP3, Ogg Vorbis and FLAC files, against specified regular expressions, and display the name and designated fields of the matching files. It supports recursive directory searches as well. Notes: I wrote this software rather quickly for my own use, but I have tested it fairly well, and it should work for most. I have not come across a software which does exactly this, which is why I believe Debian could possess this. I have done my best to add a tutorial style README and a man page for the program. Please voice your opinions and objections on any of the above. Thanks. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: Explicitely Cc bug reporters
On Thu, Sep 10, 2009 at 03:43:16PM +0100, Mark Brown wrote: > > This is subjective. I know of several bug reporters who would either > > be happy to see that their bug is being dicussed/attended to, or even > > be able to pariticipate in the fixing efforts if their technical > > knowledge falls in the category of that bug. > > > Just my view, I try to remember to Cc the reporter, but I'd much > > rather prefer being subscribed to bugs as I report them. > > What would be really useful here is the ability to set up the BTS to > subscribe you to bugs you've filed by default. That avoids the issue > with confusing less technical users. To be more specific, we should have a pseudo-header like Subscribe: yes which would allow me to subscribe to the bug during submission. This way, we avoid all issues of forcing users to see the BTS mail exchanges, and allow the brave ones to participate without explicit subscription. I recall having contacted Don about this. He was not averse to implementing this feature, but did not have sufficient time to handle it. Thanks. Kumar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Explicitely Cc bug reporters
On Thu, Sep 10, 2009 at 04:21:50PM +0200, Bernhard R. Link wrote: > * Sandro Tosi [090910 16:09]: > > Do others feel we should enable emailing the submitter by default? > > there are some reasons not to? > > But reporters are sacrifing some of their time to help us make our > distribution better. Do you really think we should scare them away > by rewarding bug reports by pulling the reporters in lengthy > discussions how the bug is best fixed? This is subjective. I know of several bug reporters who would either be happy to see that their bug is being dicussed/attended to, or even be able to pariticipate in the fixing efforts if their technical knowledge falls in the category of that bug. Just my view, I try to remember to Cc the reporter, but I'd much rather prefer being subscribed to bugs as I report them. Kumar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Emacs 23.1 released
On Thu, Jul 30, 2009 at 09:38:12AM -0400, Adrian Perez wrote:
>
> Sure, but emacs is a complex package, and I'm working in something else
> by now, if I understood you right. If you mean you're going to work on
> it that's great. I've been using emacs-snapshot for a long time by now,
> I'm pretty excited about this release.
What Cyril meant was, that, the way your initial mail sounded a tad
authoritative ("I'd like to see this in unstable" vis-a-vis a
request). Since Debian is chiefly a volunteer driven project, you'll
probably get better results if you either wait patiently for the
maintainer, make a (more gently sounding) request do the maintainer
(directly, preferably), or do the work yourself and send it to the
maintainer. :-)
HTH.
Kumar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff? (was: Re: phyml_20081203-1_powerpc.changes REJECTED)
On Mon, Apr 27, 2009 at 01:39:15PM +0100, Noah Slater wrote: > * The Debian lists do not have a Reply-To header, meaning that by default my > email client wants to send replies to individual posters. To get the > mailing > list included in the reply means that I have to reply to all. It's a very > easy mistake to make, not to remember to manually shuffle these addresses > around each time I want to send a follow up. Don't make me think! I don't mean to continue the argument, but I see that you are using Mutt. If that is the case, I am certain that it would not take you too much effort to use list-reply (`L', by default). I ask you to do this not because you don't follow list protocol, but you make it difficult for others as to follow it; for example, by default, when I chose to reply, this mail went to the list and was CC'ed to Holger, because of the strange way the headers came from your mail! Do you use the "lists" and "subscribe" keywords for this list in your muttrc? Thanks. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#521978: ITP: armadillo -- streamlined C++ linear algebra library
Package: wnpp Severity: wishlist Owner: Kumar Appaiah Package name : armadillo Version: 0.6.2 Upstream Author: Conrad Anderson (conradsand at ieee.org) URL: http://arma.sf.net License: Dual Licensed, GPL-3+ and LGPL-3+ Programming Lang : C++ Description: streamlined C++ linear algebra library Armadillo is a streamlined C++ linear algebra library (matrix maths) aiming towards a good balance between speed and ease of use. Integer, floating point and complex numbers are supported, as well as a subset of trigonometric and statistics functions. Optional integration with LAPACK and ATLAS libraries is also provided. Extras: Reason for request for inclusion in Debian: The reason why I think this package should be in Debian is because it is (to my knowledge) among the only few libraries which support delayed evaluation to improve computational efficiency. I believe that several users who need scientific computation may derive benefit from this. Another point of note is that, though it does seem to be the case that this library provides similar functionality to IT++ (libitpp), they actually compliment each other with non-overlapping feature sets, and Armadillo can be used along with IT++. Maintenance: I propose to include this package with the Debian Science Team as maintainer, since co-maintaining is much more reliable when I (as an individual) am not as responsive as I ought to be... Comments and suggestions welcome. Thanks. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: Debian -- the best
On Fri, Dec 19, 2008 at 1:47 PM, Kumar Appaiah wrote: > The best part is that, knowing how quality assurance and the BTS > works, I hardly ever run into problems. If I do run into problems (in > the spirit of DFSG 3), I know I can bring it up and someone will hear I meant Debian Social Contract, Point 3. Apologies. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian -- the best
On Fri, Dec 19, 2008 at 1:26 PM, Neil Williams wrote: >> Debian can be considered the optimal environment for brain imaging >> research (compared to all other possible operating systems). > > That is good news - good enough to be made very, very public. (Just keeping the thread up for adding positiveness) Most of what I say applies to other fields as well, but anyway: I would opine, more generally, that Debian is fantastic from science and engineering students and researchers in general, since there are teams which devote as much effort to keeping up-to-date and high quality packages for science and mathematics as, say, teams which take care of core packages such as the kernel. I can safely grab a copy of the Debian DVDs, with the comfort that wherever I install it, I am going to get an environment with all the simulation tools I need, as well as tools to generate reports, visualize data and finally, format documents about it (I am not naming the software for these tasks, since there are too many and varied). The best part is that it is not a _dedicated_ scientists', artists' or publishers' or games distribution, but satisfies all these. This means that on days when I want to goof off, I can try to see if I can complete supertux or choose a nice solo game of cards. Total freedom to to what I want to. Without going anywhere else. The best part is that, knowing how quality assurance and the BTS works, I hardly ever run into problems. If I do run into problems (in the spirit of DFSG 3), I know I can bring it up and someone will hear it. And I can also help in fixing it, if I can, which I often try to do. So, thanks to all those users and developers who participate in Debian. I (I can safely say We) appreciate it a lot! Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: List of RC-buggy source packages by maintainer/uploader
On Mon, Oct 06, 2008 at 09:56:20PM -0400, Hubert Chathi wrote: > On Mon, 6 Oct 2008 21:28:51 +0200, Lucas Nussbaum <[EMAIL PROTECTED]> said: > [...] > > Debian GNUstep maintainers <[EMAIL PROTECTED]> > > gnustep-gui > > Fixed in t-p-u. Waiting to be built (for about a month!) on m68k, > before in can migrate. (Which is kind of silly, since the bug shouldn't > even affect m68k.) Are you sure about this? From what I can see here, m68k isn't even a part of the release architectures for Lenny (before Etch, in fact): http://buildd.debian.org/~jeroen/status/package.php?p=gnustep-gui&suite=testing I think you should just (re-)request an update to stable. HTH. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: List of RC-buggy source packages by maintainer/uploader
On Mon, Oct 06, 2008 at 09:28:51PM +0200, Lucas Nussbaum wrote: >matplotlib Just in case someone observes this, a fixed version is ready in t-p-u, and the release team has acknowledged this and shall be allowing this in soon. Thanks. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: Bug#454707: nethack -- Doesn't purge all files after piuparts Install+Upgrade+Purge test
On Thu, Sep 25, 2008 at 02:18:40PM +0200, Arnaud Fontaine wrote: > Before I maintain nethack-el, it was not relying on dh_installemacsen > and startup file was installed as /etc/emacs/site-start.d/50nethack.el. > However, it now relies on dh_installemacsen and the file is now > installed as /etc/emacs/site-start.d/50nethack-el.el, that's why I got > this bug report. > > I think that just renaming the file from 50nethack.el to 50nethack-el.el > is not the best solution as the former file may be still there for > unstable/testing users and it would wipe possible modifications done in > 50nethack-el.el. I'm wondering how I could handle that? As maintainer, it is for you to decide, or query the release managers in charge of the goal[1]. However, the short answer is that the goal is to have the Etch version installed -> upgrade to sid/lenny -> subsequent purge remove all the files belonging to the package. Therefore, my recommendation would be to purge the file when the purge command is given, if the file exists. That way, you are allowed to keep the file during the upgrade, but remove it only during purge. Does this sound sane? Thanks. Kumar [1]: http://release.debian.org/lenny/goals.txt -- Kumar Appaiah signature.asc Description: Digital signature
Re: NMU versioning
On Tue, Apr 29, 2008 at 12:16:28PM +0200, Adeodato Simó wrote: > > FWIW, I think NMUing a package shouldn't end up with a sourceful upload > > but should instead have a .diff.gz, whether it's a native package or not. > > 100% agreed. (Assuming you mean a NMU should never, ever, create a new > tarball, particularly applying to native packages.) For non-native packages, however, wouldn't it make sense to package a new upstream release as NMU if it fixes a set of RC bugs, say, rather than backporting the fixes (a tad) clumsily? (I may be missing something in what you were intending to say, so I apologise for that.) Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFH: piuparts testing of the archive
On Mon, Apr 07, 2008 at 11:46:24AM +0200, Lucas Nussbaum wrote: > What needs to be done is: > - run installation/removal/purge tests for all packages > - run upgrade tests for all packages in etch > - make changes to piuparts to fix false positives or reduce the number > of failures by ignoring the less critical ones > - file all the bugs (many of those are RC) > > The main problem is that there's currently ~4400 failures for the > installation/removal/purge tests. This includes issues about files being > added/removed/modified during the test, which are not as critical as the > tests where installation simply fails. But still. > > Skills needed: > - python, since piuparts is written in python > - understanding of issues piuparts reports (mostly maintainer scripts > stuff) > - ability to deal with large data sets and semi-automate the process by > writing scripts > > I can of course help by running piuparts on all packages with the > needed options, but that's only a small part of the task. > > If you are interested, the logs for all packages are available on > http://people.debian.org/~lucas/logs/2008/04/07/ , and a dd-list of the > failing packages is available at > http://people.debian.org/~lucas/logs/2008/04/07-piuparts-ddlist.txt . I wish to add that I did an initial round of bug filing for this task last December, and even supplied a few patches and some NMUs. But that was when there were holidays. Later, since I tried to help out a bit more in the gfortran transition and real life difficulties, I did not pursue this goal with the same force. My modus operandi for scripting was as follows. First, a general perusal of the logs reveals that several of the reports are "duds". By this, I don't mean that all of the problems are wrong, but it is just that the problem manifests because of no fault of this package. Please do point out mistakes below; I am not sure if everything I've written is correct. For example, if you check out the logs for libitpp6gf, proc is not mounted, and there seems to be no other major issue. For most other packages, the problem is because some dependencies don't clean up properly. For example, for pkpgcounter, the problem areas are: /etc/alternatives/djview not owned /etc/cups owned by: libcupsys2, cupsys /etc/cups/ssl owned by: cupsys /etc/cups/ssl/server.crt not owned /etc/cups/ssl/server.key not owned /etc/sgml owned by: xml-core, docbook-xml /etc/ssl owned by: openssl /etc/ssl/private owned by: openssl [snipped for brevity] Clearly, there's nothing in pkpgcounter's hands for fixing the above; other packages have the cleaning up to do. So, I tried to parse the logs to get the list of "not found" files, made a list of them, and histogrammed them to find the file(s) which appeared the maximum number of times in these logs. Then, I looked at which package(s) is responsible for mopping up that file, and confirm that that package manifests a similar behaviour. For example, in the above case, cupsys and openssl seems to be among the packages causing pkpgcounter to fail the piuparts test. Checking their piuparts logs, we do find that at least cupsys doesn't clean up quite well before leaving. So, the bug belongs to cupsys, and that should take care of pkpgcounter and the tens (or, in some cases) hunderds of packages which display this error. In short, this is a VERY painful task, since I have to reproduce this error before actually filing a bug. So, it is time consuming. Also, some maintainers probed further and found cases where "disowning" a package's file during upgrade causes dpkg to forget about it. These, of course, are exceptions, and can be handled separately. I hope this was useful. I am not in a position to give my scripts as such, since they were written as dirty one off attempts to get the job done. But in case someone wishes to rewrite scripts, I would be glad to share with them some issues related to this. I also wish to apologise for the fact that I am unable to take this task to completion myself. Thank you! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: dpkg-buildpackage now reorganizing debian/control Depends
On 23/02/2008, Matthew Johnson wrote: > On Sat Feb 23 12:02, Kumar Appaiah wrote: > > So, I want to build against the reference lapack and blas, and then, > > if the user chooses, then I want the alternatives system to enable the > > use of atlas. Now, the new dpkg-source reordering installs atlas as > > well during build, which causes the "smart" build systems of these > > packages to detedct and link against it, which is NOT what I want. > > Which is something you should probably do anyway to satisfy the 'builds > the same in a dirty build environment' goal. Although I do agree that > fetching extra build-deps is bad. Sorry, but this particular case is one where the user might want to deliberately choose this way to achieve the desired goal. So, this _is_ a case where the user may benefit out of the package building differently when in a different environment. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage now reorganizing debian/control Depends field??
On 23/02/2008, Colin Tuckley wrote: > In the gFortran transition we have come across some cases where this > happens, depending on the order specified for depends you either get a > specialist (requested) package, or if you don't care which maths lib for > example is used by the package then you get a default one. Also it may be > that you get a software emulation of something rather than a faster hardware > version because you already have a certain library installed. Well, let me take credit for first discovering this issue as the discussion ensues! :-) What the dpkg devels told me was that the package should build consistently on any environment where the Build-Dependencies were satisfied. However, this is, IMO, too much to ask. I describe it with this situation, which affected python-numpy, libitpp and octave. So, I want to build against the reference lapack and blas, and then, if the user chooses, then I want the alternatives system to enable the use of atlas. Now, the new dpkg-source reordering installs atlas as well during build, which causes the "smart" build systems of these packages to detedct and link against it, which is NOT what I want. OK, so I accepted the dpkg devels' advice, and either add a configure flag to the package build to make it oblivious to the existence of atlas, or, in the case of python-numpy, hack the build system in an ugly way to make it blind to the existence of atlas. However, this still has two disadvantages: 1. During the build, though atlas is never used, it is fetched and installed. This, may be termed insignificant, but I disagree. 2. Under the event that a user wants to rebuild my package _with_ atlas and link against it for some reason, earlier, he/she would just have had to install Atlas and run dpkg-buildpackage to achieve the desired result. Now, since my debian/rules has been made blind to atlas existence, the user would have to _undo_ my hacks/modifications manually to achieve the same result. And no, I cannot make the process too easy for users, because for the purpose of making the Debian package depend only on Atlas, I am forced to resort to this method, made necessary by the dpkg-source change. > > That said this new behaviour is not particulary new. It's been in unstable > > since the 19th november 2007. And we haven't seen major breakage in the > > mean time. > > There *are* breakages and more of them will come to light as the gFortran > transition proceeds. While what I describe isn't breakage, it is something which needs to be given some thought. > So, once again, please revert this change and then maybe we can all debate > what is actually needed (assuming any change at all is actually warranted). I stop short of saying +1, because I am not fully aware of the good reasons why dpkg developers resorted to this, but I am just very unhappy at being forced to work around what was an undocumented but "assumed normal" behaviour of dpkg suddenly changing. Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: avoid conf file overwrite message?
On Fri, Feb 22, 2008 at 08:52:24AM +0530, Kumar Appaiah wrote: > On Thu, Feb 21, 2008 at 06:24:37PM -0800, William Francis wrote: > > Is there a way (short of piping in /usr/bin/yes or something similar) > > to make that go away? Eventually I'll use something like puppet to > > manage these files but for now this happens to be the easiest way. If > > I do answer 'Y' it does indeed do what I want. > > Isn't apt-get -y what you want? OK, won't work if you do dpkg -i I guess. In fact, I may be wrong even with apt, so sorry for the noise. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: avoid conf file overwrite message?
On Thu, Feb 21, 2008 at 06:24:37PM -0800, William Francis wrote: > Is there a way (short of piping in /usr/bin/yes or something similar) > to make that go away? Eventually I'll use something like puppet to > manage these files but for now this happens to be the easiest way. If > I do answer 'Y' it does indeed do what I want. Isn't apt-get -y what you want? HTH. Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: How to cope with patches sanely
On Fri, Feb 01, 2008 at 06:06:04PM +0100, Raphael Hertzog wrote: > No, I said "rebase" and not merge. > See http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html > > (Note that this means that nobody should derive from upstream-patched as > the branch is regularly rewritten and one can't branch and later merge > from it) Dear Raphael, Here is where I want some explanation. Assume that my simple branches are: upstream: Pure upstream sources right from the orig.tar.gz master: Debian packaging on top of upstream (mostly ONLY debian/ directory addition in comparison to upstream). In this simplistic case, should I have a new upstream version, should I update my upstream branch and merge it into master, or rebase master? While rebasing ensures that all my changes apply over the new upstream release, what is the reason I shouldn't merge? Sorry if this is obvious, but I would love to get this right. Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: How to cope with patches sanely
On 01/02/2008, Raphael Hertzog wrote: > With git I'd use a "debian-patches" branch that I would rebase on the > upstream branch regularly and would edit history of changes as needed so > that one commit generates one file in debian/patches/. Dear Raphael, Is this what you mean? - Have a branch upstream, and upstream-patched - Make upstream stay in sync with the upstream tarball. Merge it with debian-patches - Use the differences between these branches to generate debian/patches, which can be wrapped around quilt/dpatch/simple-patchsys? Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: postscropt document without source
On Mon, Jan 14, 2008 at 01:11:36PM +0100, Thomas Weber wrote: > > Yes. Please see the latest mails from debian-toolchain for context. > > Okay, thanks for doing the grunt work. But which upstream tarball are > you using? Everything I could find at Netlib doesn't have a PDF at all. It is a hand-made one, following the _same_ format which Camm used for the earlier refblas. Refer these: 1. http://lists.debian.org/debian-toolchain/2007/12/msg00012.html 2. http://lists.debian.org/debian-toolchain/2007/12/msg00013.html 3. dget -x http://kumar.travisbsd.org/dump/blas_1.2.new-0.2.dsc HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: postscropt document without source
On Mon, Jan 14, 2008 at 11:49:05AM +0100, Thomas Weber wrote: > > Right, so a source tarball repack is needed. > > Which blas package is this? The one from netlib? Yes. Please see the latest mails from debian-toolchain for context. Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: reporting BTS spam easily from Mutt
On Tue, Jan 08, 2008 at 04:26:30PM +0530, Kumar Appaiah wrote: > macro index , "[EMAIL PROTECTED]" > macro index , "[EMAIL PROTECTED]" OK, the second index should be `pager'. And I just tested it on a real spam with report-listspam@, and it works! :-) Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: reporting BTS spam easily from Mutt
On Tue, Jan 08, 2008 at 12:41:23PM +0200, Alexander Schmehl wrote: > Would be cool, if your script would then automatically detect, if the > mail was received via bts or via a list and bounce it to the correct > report address. Er, that's too cool, but here's a simple one to start. Just add this to your .muttrc: macro index , "[EMAIL PROTECTED]" macro index , "[EMAIL PROTECTED]" Of course, change `,' to whatever key you want, and [EMAIL PROTECTED] to [EMAIL PROTECTED] If I press `,', it asks me if I'm sure I wish to bounce it, which is good to stop myself if I pressed `,' by mistake. This could be combined with some hook magic to detect the origin of spam, but I'll think about that later. For now, this seems enough for me. /me spanks myself for not having done this earlier. HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: reporting BTS spam easily from Mutt
On Mon, Jan 07, 2008 at 03:29:21PM +0100, Amaya wrote: > That is incredibly useful, is tehre any similar tool to report spam > delivered through the Debian Mailing Lists? > > Sorry if this has been answered before, I am just starting to keep up > with mail backlog. Well, the steps are simply: 1. Scroll to the message which is spam. 2. Type `b', write the address as [EMAIL PROTECTED] 3. Say yes. I think a single keystroke can be scripted for this. I'll try later tonight, though someone else is welcome to do this ahead of me. :-) HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Bug#451082: ITP: supercat -- program that colorizes text for terminals and HTML
Package: wnpp Severity: wishlist Owner: Kumar Appaiah <[EMAIL PROTECTED]> * Package name: supercat Version : 0.5.3 Upstream Author : Thomas Anderson <[EMAIL PROTECTED]> * URL : http://supercat.nosredna.net/ * License : GPL-3 Programming Lang: C Description : program that colorizes text for terminals and HTML Supercat is a program that colorizes text based on matching regular expressions/strings/characters. Supercat supports html output as well as standard ASCII text. Unlike some text-colorizing programs that exist, Supercat does not require you to have to be a programmer to make colorization rules. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23.1 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of gfortan transition
On 18/10/2007, Kumar Appaiah wrote: > Bidding adieu to the old Fortran compiler and using gfortran is one of > the proposed Lenny release goals[1]. However, the showstoppes, > definitely, are lapack3 and atlas. There hasn't been any movement on > that side, and it seems that the packages could do with some help. OK, Matthias Klose has replied on debian-toolchain, and we'll take it up there. Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Status of gfortan transition
Dear Debian developers, Bidding adieu to the old Fortran compiler and using gfortran is one of the proposed Lenny release goals[1]. However, the showstoppes, definitely, are lapack3 and atlas. There hasn't been any movement on that side, and it seems that the packages could do with some help. This has been a long standing issue. Also, Atlas does have new upstream releases, albeit not declared "stable". However, I feel that must also be packaged for Debian. As for me, I am not a Fortran or a compiler expert. But I will definitely help in testing any releases which you make, since that is something in my capability. Thanks. http://lists.debian.org/debian-toolchain/2007/07/msg0.html -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439551: ITP: libj2ssh-java -- a Java API for the SSH protocol.
Package: wnpp Severity: wishlist Owner: Kumar Appaiah <[EMAIL PROTECTED]> * Package name: libj2ssh-java Version : 0.2.9 Upstream Author : Lee David Painter and contributors. * URL : http://sshtools.sourceforge.net * License : GPL Programming Lang: Java Description : a Java API for the SSH protocol. J2SSH is an object-orientated Java implementation of the SSH version 2 protocol. It provides a rich, powerful, and extensible SSH API that enables developers to gain access to SSH servers and to develop entire SSH client/server frameworks. The API library provides a fully-featured SSH2 implementation specifically designed for cross-platform development. Higher level components, representing both the standard SSH client and SSH servers, are provided which implement the protocol specification for user sessions and port forwarding. The specification currently supports public key and password authentication and a full implementation of the SFTP protocol. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.22.1 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: to start up as a developer
On 24/08/07, suren M wrote: > through the Debian developers corner also. I would like to how exactly to > start, rather if there is some beginners documentation or something like > that. http://www.debian.org/doc/maint-guide/ is the document. Also, you can help out in translation into your (our) language, Tamil, join the Debian-IN project, and in general (often missed by users), file bug reports when you find bugs! > Please do elaborate about orphaned packages and packages to be adopted. > Also please suggest me anything else in can work on. The above document, and the references therein, should lead you to the answer to these questions. All the best, and start helping! :-) Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Britney on a break?
On 21/08/07, Steve Langasek wrote: > Because britney had been OOMing over the past few days, so this > information within packages.qa.d.o was not being updated. Oh! Thanks for the information. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Britney on a break?
On 21/08/07, Kumar Appaiah wrote: > OK, so that's clear. But I still have one doubt. Is it that it is not > necessary that Britney moves my packages into testing _exactly_ on the > tenth bug-free day, or is any day _after_ that 10th day? To elaborate on my day-counting complaint, see the status of python-goopy: http://packages.qa.debian.org/p/python-goopy.html Though it has been uploaded into unstable on 16th August, it's still "Too young, only 0 of 10 days old". Why? Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Britney on a break?
On 21/08/07, Don Armstrong wrote: > google-sitemapgen, pkpgcounter and harvestman should be going in today. Ah, thanks! > In general, > http://qa.debian.org/[EMAIL PROTECTED], and > clicking on "more" should tell you what is going on with a particular > package's testing migration. OK, so that's clear. But I still have one doubt. Is it that it is not necessary that Britney moves my packages into testing _exactly_ on the tenth bug-free day, or is any day _after_ that 10th day? Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Britney on a break?
Dear Debian developers, I've just observed that though some of my packages have been in unstable for 10 days without complaints, Britney hasn't moved them into testing. Moreover, the PTS page has stopped counting the days my packages have spent in unstable since the 18th (I think). Is there something wrong with the scripts, or am I missing something? Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Bug#436195: ITP: logapp -- supervise execution of applications producing heavy output
Package: wnpp Severity: wishlist Owner: Kumar Appaiah <[EMAIL PROTECTED]> * Package name: logapp Version : 0.7 Upstream Author : Michael Brunner <[EMAIL PROTECTED]> * URL : http://logapp.sourceforge.net/ * License : GPL Programming Lang: C Description : supervise execution of applications producing heavy output Logapp is a wrapper utility that helps supervise the execution of applications that produce heavy console output (e.g. make, CVS, and Subversion). It does this by logging, trimming, and coloring each line of the output before displaying it. It can be called instead of the executable that should be monitored; it then starts the application and logs all of its console output to a file. The output shown in the terminal is preprocessed, e.g. to limit the length of printed lines and to show the stderr output in a different color. It is also possible to automatically highlight lines that match a certain regular expression. The output is therefore reduced to the necessary amount, and all important lines are easy to identify. . Homepage: http://logapp.sourceforge.net/ Kumar -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22.1 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436065: ITP: flickcurl -- C library for the Flickr API
Package: wnpp Severity: wishlist Owner: Kumar Appaiah <[EMAIL PROTECTED]> * Package name: flickcurl Version : 0.11 Upstream Author : Dave Beckett <[EMAIL PROTECTED]> * URL : http://librdf.org/flickcurl/ * License : LGPL 2.1 / GPL 2 /Apache 2.0 Programming Lang: C Description : C library for the Flickr API Flickcurl is a C library for the Flickr API, handling creating the requests, signing, token management, calling the API, marshalling request parameters and decoding responses. It uses libcurl to call the REST web service and libxml2 to manipulate the XML responses. The current version supports part of the API, primarily the functions for reading photo, people and tags description, uploading photos, changing tags and comments. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22.1 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435030: ITP: pkpgcounter -- a generic Page Description Language parser
Package: wnpp Severity: wishlist Owner: Kumar Appaiah <[EMAIL PROTECTED]> * Package name: pkpgcounter Version : 2.18 Upstream Author : Jérôme Alet <[EMAIL PROTECTED]> * URL : http://www.pykota.com/software/pkpgcounter * License : GPL Programming Lang: Python Description : a generic Page Description Language parser pkpgcounter is a generic Page Description Language parser which can either count the number of pages or compute the percent of ink coverage needed to print various types of documents. It is written in Python. . It currently recognizes the following file formats : . * PostScript (both DSC compliant and binary) * PDF * PCL3/4/5 * PCLXL (aka PCL6) * DVI * Plain text * TIFF * ESC/P2 * OpenDocument (ISO/IEC DIS 26300) * Zenographics ZjStream * Samsung QPDL (aka SPL2) * Samsung SPL1 . The five latter ones, as well as some TIFF documents, are currently only supported in page counting mode. . Homepage: http://www.pykota.com/software/pkpgcounter -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-ck1 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Shell: /bin/sh linked to /bin/bash
Re: List of (un)sponsored packages on Mentors (approximate)
On Thu, Jul 26, 2007 at 07:50:49PM +1000, Paul TBBle Hampson wrote: > Your title= tagging has unfortunately barfed on my name, due > to the "TBBle" in it causing the quoted string to terminate > early. Well, I don't think this page is necessary anymore, since better options to check this are available (courtesy this thread). So, don't bother too much; that page is going away in a while! :-) Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Bug#434206: ITP: moe -- powerful text editor for ISO-8859 and ASCII character encodings
On 25/07/07, Adam D. Barratt wrote: You can't remove something that's not in the archive... Right! Kumar, you need to e-mail [EMAIL PROTECTED] and ask them to reject the upload from the NEW queue. I have mailed them with a citation to this thread. Also, I have closed the bug report, with a similar citation. Thanks for bringing this issue to my notice. I shall, henceforth, keep this in mind before filing that brand new ITP. :-) Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#434206: ITP: moe -- powerful text editor for ISO-8859 and ASCII character encodings
On 25/07/07, Ben Hutchings wrote: > GNU Moe is a powerful, 8-bit clean, text editor for ISO-8859 and ASCII > character encodings. I don't think we should be adding more programs to the archive that can't handle multibyte encodings. I believe the default character encoding for new installations is UTF-8. OK. It's in the NEW queue. Could you please tell me the procedure to prevent it from entering the archives? Thanks. Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#434206: ITP: moe -- powerful text editor for ISO-8859 and ASCII character encodings
On 23/07/07, Adam Borowski wrote: > GNU Moe is a powerful, 8-bit clean, text editor for ISO-8859 and ASCII [snip] Yeah, but I would rather mention whether it's a console or X one in the very first sentence. In the TODO for the next upload. Thanks. Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of (un)sponsored packages on Mentors (approximate)
On Sun, Jul 22, 2007 at 07:37:13PM +0200, Nico Golde wrote: > [...] > Thanks for your work! But basically you do work that already > had been done by mentors.debian.net. Ok not everyone is > using this service but it would be good if they would. Ah, you get beaten in the race quite often! ;-) > I also see a problem in missing descriptions for the RFS. > Sure it would be not very efficient to download the message > from the archive and parse them but browsing a huge list of > non-descriptive names is somehow bad. You are probably right. But I don't think this is meant to be incorporated into the mentors portal as such. It was merely to provide an indication of which packages did get sponsored at least once, and which didn't. Also, I shared the news since people on #debian-mentors also thought it'd be good to provide this info to debian-devel. Thanks! Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
List of (un)sponsored packages on Mentors (approximate)
(Cross posted to debian-devel, debian-mentors) Dear Debian developers, I have written a few crude and rudimentary scripts to find an approximate list of packages which have been or have _not_ been sponsored despite an RFS to debian-mentors. The program generates bad output if the RFS mailer has not given the package name right after the first "RFS" in the subject, that too, with a space etc., but it's a start, and gives you the idea. Also, the list is a HTML page, with every package having a link. The link points to the RFS message in the Debian Mentors archive. See it at: http://www.ee.iitm.ac.in/~ee03b091/Mentors/output.html The scripts I wrote for this are at: http://www.ee.iitm.ac.in/~ee03b091/Mentors/mentors-sponscheck.tar.bz2 The README in the tarball explains my methodology and the problems in it. The Python + BeautifulSoup program is inefficient and inelegant. But I have spent quite some time in getting it this far. So, if someone wants to improve it, please do so; I'd be happy. Many thanks to Gurkan Sengun, Christoph Haasand Sune Vuorela to inspire me to write this. Hope it's useful. Thanks! Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434206: ITP: moe -- powerful text editor for ISO-8859 and ASCII character encodings
Package: wnpp Severity: wishlist Owner: Kumar Appaiah <[EMAIL PROTECTED]> * Package name: moe Version : 0.9 Upstream Author : Antonio Diaz Diaz <[EMAIL PROTECTED]> * URL : http://www.gnu.org/software/moe/moe.html * License : GPL Programming Lang: C++ Description : powerful text editor for ISO-8859 and ASCII character encodings GNU Moe is a powerful, 8-bit clean, text editor for ISO-8859 and ASCII character encodings. It has a modeless, user-friendly interface, online help, multiple windows, unlimited undo/redo capability, unlimited line length, global search/replace (on all buffers at once), block operations, automatic indentation, word wrapping, filename completion, directory browser, duplicate removal from prompt histories, delimiter matching, etc. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-ck1 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what happened to g77-3.4-doc?
On 19/07/07, Neil Williams wrote: > Why I need this:- I was trying to compile refblas3 package with > gfortran instead of g77. That would be very useful for one of my sponsored packages. Deviating slightly from the topic, could someone point out to a timeline for the gfortran transition[1]? [1] http://lists.debian.org/debian-toolchain/2007/07/msg0.html Thanks. Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
