Re: bug #350639
Hi, On Mon, May 18, 2009 at 01:32:01PM -0300, Tiago Saboga wrote: > Freddy Freeloader writes: > > Thorny wrote: > >> On Sun, 17 May 2009 12:31:05 -0700, Freddy Freeloader posted: > >>> In my mind there is no good reason for this fix to go into Sid > >>> and then sit there until the dependencies are satisfied for that version > >>> number. > >>> > >> > >> Well, that is the standard flow. I hear you that it isn't convenient for > >> you but it is standard. > >> > > It is also standard flow to fix bugs that are found in testing, not to > > always wait until a new version comes down from Sid. That's the > > purpose for which testing exists. Those bugs not found while a > > package is in Sid are fixed in testing when fixing them does not > > require a new dependency or will break some other package. So why > > should this bug be any different? It exists in testing so it should > > be fixed in testing too, not allowed to just sit for months when it's > > a very simple fix. > > It seems you do not really understand the workflow in debian. No bug is > never fixed in testing. No upload is never allowed to testing (ok, > except in deep freeze, and even then the package is uploaded to > testing-proposed-updates, not testing). Every single change to a package > must go through sid first. So, if someone find a serious bug in kde 4.1 > now, there is no way to the maintainers to fix it in testing before kde > 4.2 hits testing. This statement is correct for pointing out the basic workflow but there is a bit too strong word. Never say "never" :-) We do fix critical/grave/security bugs for stable. There are special testing security bug fix system once we get decently stable sesting, I expect soonish. > If you use testing, you should know that it can be at times even more > broken than sid. It's the way it works. testing is less unstable than > sid: it means testing changes less than sid, it's all. Testing was supposed to be somewhat usable once "transition period" ends just after release. We are still in this transition period. > Hope that helps, Osamu -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: bug #350639
Freddy Freeloader writes: > Thorny wrote: >> On Sun, 17 May 2009 12:31:05 -0700, Freddy Freeloader posted: >>> In my mind there is no good reason for this fix to go into Sid >>> and then sit there until the dependencies are satisfied for that version >>> number. >>> >> >> Well, that is the standard flow. I hear you that it isn't convenient for >> you but it is standard. >> > It is also standard flow to fix bugs that are found in testing, not to > always wait until a new version comes down from Sid. That's the > purpose for which testing exists. Those bugs not found while a > package is in Sid are fixed in testing when fixing them does not > require a new dependency or will break some other package. So why > should this bug be any different? It exists in testing so it should > be fixed in testing too, not allowed to just sit for months when it's > a very simple fix. It seems you do not really understand the workflow in debian. No bug is never fixed in testing. No upload is never allowed to testing (ok, except in deep freeze, and even then the package is uploaded to testing-proposed-updates, not testing). Every single change to a package must go through sid first. So, if someone find a serious bug in kde 4.1 now, there is no way to the maintainers to fix it in testing before kde 4.2 hits testing. If you use testing, you should know that it can be at times even more broken than sid. It's the way it works. testing is less unstable than sid: it means testing changes less than sid, it's all. Hope that helps, Tiago. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: bug #350639
On Seg, 18 Mai 2009, Freddy Freeloader wrote: It is also standard flow to fix bugs that are found in testing, not to always wait until a new version comes down from Sid. No, that's not the Debian flow. That's the purpose for which testing exists. Those bugs not found while a package is in Sid are fixed in testing when fixing them does not require a new dependency or will break some other package. So why should this bug be any different? It exists in testing so it should be fixed in testing too, not allowed to just sit for months when it's a very simple fix. I could see the lag if this was a bug that's difficult to fix and in some package that hardly anyone uses, but that is not the case with g-v-m or this bug. It exists in every Gnome installation by default. I think you are misunderstanding the way Debian testing/unstable works. Packages never enter testing directly. All packages enter unstable, stay there for a set number of days (the standard is 10, but can be made smaller for things such as security fixes), and if sufficient conditions are met, then migrate to testing. These conditions involve, among possible others, number of serious bug present and if all the dependencies necessary for the package are in testing and can be migrated together. There is not separate "bug fixing in testing" and "in unstable". Bugs are fixed, and new packages enter unstable. I don't know what is the case with this specific bug. It may have been fixed in unstable, but Gnome is in process of a big migration (along with KDE) to testing, so it is normal that Gnome packages are blocked in unstable until everything can be migrated. -- Eduardo M KALINOWSKI edua...@kalinowski.com.br -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: bug #350639
Thorny wrote: On Sun, 17 May 2009 12:31:05 -0700, Freddy Freeloader posted: [...] I have to ask why. Why is this left up every user of testing to fix this problem themselves when the fix is so simple? [...] One possible answer to this question would be that users of "testing" are supposed to be able to troubleshoot and fix problems in "testing". The maintainer may rely on that and not think there is a pressing need to do it. What you say about testing is even more true about Sid, yet the Sid version is fixed. Following your logic there was no need to fix the bug in Sid at all as Sid users are supposed to be even more skilled in fixing the problems they run across. Sid is supposed to be more buggy than testing by its very nature. Why can't this fix be uploaded to the Debian repositories? It's not like auto mounting of cd/dvd's and portable usb devices is something hardly anyone does on a daily basis. All I could suggest is to ask the maintainer directly, he may not read this list. The email address is available in the bug report or with the package itself. [...] In my mind there is no good reason for this fix to go into Sid and then sit there until the dependencies are satisfied for that version number. Well, that is the standard flow. I hear you that it isn't convenient for you but it is standard. It is also standard flow to fix bugs that are found in testing, not to always wait until a new version comes down from Sid. That's the purpose for which testing exists. Those bugs not found while a package is in Sid are fixed in testing when fixing them does not require a new dependency or will break some other package. So why should this bug be any different? It exists in testing so it should be fixed in testing too, not allowed to just sit for months when it's a very simple fix. I could see the lag if this was a bug that's difficult to fix and in some package that hardly anyone uses, but that is not the case with g-v-m or this bug. It exists in every Gnome installation by default. [...] Testing is what the biggest portion of Debian users have on their desktops. Do you have any documentation to support this, I do understand how you might think that reading lists and forums but I've never seen any documentation of version percentages for desktops. [...] Is the Debian development process in that much trouble, i.e. short of help, or have such unreasonable versioning rules that something this simple can't be fixed promptly? Following the standards is not necessarily an indication of "being in trouble", it's an indication of following standards and flow. "Stable" is the version that is stable, probably in some sense that stability is a result of the Debian "flow". This isn't important for your question but I personally don't like to automount, I prefer to mount as I choose and as needed. YMMV I think I do understand your frustration, and you've got a good example to work with but standards are standards and the flow has given us very good stable Debian for many years, I want it to remain the same. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: bug #350639
On Sun, 17 May 2009 12:31:05 -0700, Freddy Freeloader posted: [...] > > I have to ask why. Why is this left up every user of testing to fix > this problem themselves when the fix is so simple? >[...] One possible answer to this question would be that users of "testing" are supposed to be able to troubleshoot and fix problems in "testing". The maintainer may rely on that and not think there is a pressing need to do it. >Why can't this fix be > uploaded to the Debian repositories? It's not like auto mounting of > cd/dvd's and portable usb devices is something hardly anyone does on a > daily basis. > All I could suggest is to ask the maintainer directly, he may not read this list. The email address is available in the bug report or with the package itself. >[...] > In my mind there is no good reason for this fix to go into Sid > and then sit there until the dependencies are satisfied for that version > number. Well, that is the standard flow. I hear you that it isn't convenient for you but it is standard. >[...] > Testing is what the biggest portion of Debian users have on their > desktops. Do you have any documentation to support this, I do understand how you might think that reading lists and forums but I've never seen any documentation of version percentages for desktops. >[...] > Is the Debian development process in that much trouble, i.e. short of > help, or > have such unreasonable versioning rules that something this simple can't > be fixed promptly? > Following the standards is not necessarily an indication of "being in trouble", it's an indication of following standards and flow. "Stable" is the version that is stable, probably in some sense that stability is a result of the Debian "flow". This isn't important for your question but I personally don't like to automount, I prefer to mount as I choose and as needed. YMMV. I think I do understand your frustration, and you've got a good example to work with but standards are standards and the flow has given us very good stable Debian for many years, I want it to remain the same. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: bug #350639
On Mon,18.May.09, 00:48:44, Matteo Riva wrote:
> On Sun, May 17, 2009 at 9:58 PM, Javier Barroso wrote:
>
> > It seems resolved in unstable,
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525183
>
> I have rebuilt the package from source as suggested by a user in that
> bug report, but now the update manager flags gnome-volume-manager as
> needing an update. How can I avoid this?
Add a new changelog entry with a higher version (by appending something
like '+local' to the version string). You can use 'dch' for this.
If you use aptitude you can also use the 'forbid-version' command ('F'
in interactive mode).
Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
signature.asc
Description: Digital signature
Re: bug #350639
Matteo Riva wrote: On Sun, May 17, 2009 at 9:58 PM, Javier Barroso wrote: It seems resolved in unstable, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525183 I have rebuilt the package from source as suggested by a user in that bug report, but now the update manager flags gnome-volume-manager as needing an update. How can I avoid this? You might try using apt-pinning. I'm not sure if it will work though as they are both the same version. I just use the auto-update wizard and uncheck that box before allowing it to proceed. Thanks. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: bug #350639
Javier Barroso wrote: Hi, On Sun, May 17, 2009 at 9:31 PM, Freddy Freeloader wrote: I'd like to point this bug out as it has been around now for 3 1/2 months with no official resolution. What's worse is that this bug was caused by the Debian gnome-volume-manager maintainer. Nobody else is responsible for it. He disabled automount when he compiled the gnome-volume-manager package. It seems resolved in unstable, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525183 I think maintainer forgot about dup (linking) these bugs. They are working in transition to gnome 2.26, so we should have patient. Ummm It took me approximately 5 minutes to download the source, make the changes in debian-rules, and compile a new package. I can count on one hand the number of Debian package I have created, so, it can't take any longer for an experienced developer to do the same thing than it did for me. I also think that waiting 3 1/2 months for a 5 minute fix before complaining is being patient. Regards, -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: bug #350639
On Sun, May 17, 2009 at 9:58 PM, Javier Barroso wrote: > It seems resolved in unstable, > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525183 I have rebuilt the package from source as suggested by a user in that bug report, but now the update manager flags gnome-volume-manager as needing an update. How can I avoid this? Thanks. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: bug #350639
Hi, On Sun, May 17, 2009 at 9:31 PM, Freddy Freeloader wrote: > I'd like to point this bug out as it has been around now for 3 1/2 months > with no official resolution. What's worse is that this bug was caused by > the Debian gnome-volume-manager maintainer. Nobody else is responsible for > it. He disabled automount when he compiled the gnome-volume-manager > package. It seems resolved in unstable, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525183 I think maintainer forgot about dup (linking) these bugs. They are working in transition to gnome 2.26, so we should have patient. Regards, -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
