Re: Echoing commands
Dear all,
the solution to show commands with "set -x" has, however, a flow: it
does not show properly commands that contain redirections. E.g., let
tmp.sh be:
#!/bin/bash
shopt -s expand_aliases
alias @echo-on='set -x'
alias @echo-off='{ set +x; } 2>/dev/null'
PS4=
@echo-on
cat f1.txt f1.txt > f1.tmp
@echo-off
running it we obtain:
$ ./tmp.sh
cat f1.txt f1.txt
I.e. the command is not entirely displayed.
P.S. we can replace "set -x" by "set +v":
alias @echo-on='set -v'
alias @echo-off='{ set +v; } 2>/dev/null'
This shows properly the command, but also shows @echo-off. I.e.
'{ set +v; } 2>/dev/null' shows itself.
I have no idea how to suppress this.
-Angelo Borsotti
On Thu, 13 Jun 2024 at 08:28, Angelo Borsotti
wrote:
> Dear all,
>
> thank you very much for your quick replies. The solution:
>
> alias @echo-on='set -x'
> alias @echo-off='{ set +x; } 2>/dev/null'
> PS4=
>
> Solves the problem, and relieves from writing "echo COMMAND" before each
> command that should be shown.
>
> -Angelo Borsotti
>
>
> On Wed, 12 Jun 2024 at 23:21, Koichi Murase
> wrote:
>
>> 2024年6月13日(木) 5:20 Angelo Borsotti :
>> > This is not the same as debugging, for which set -x is devoted.
>> > "set -x" makes the ensuing commands be printed, but prefixed
>> > with "+ ", which makes the result look ugly,
>>
>> PS4= (as Greg has replied)
>>
>> > not to mention that
>> > the following "set +x" is echoed too (there are hacks to suppress
>> > the "set +x" output, but they are just hacks).
>>
>> What are the hacks? What are the problems with them? You can have aliases:
>>
>> alias @echo-on='set -x'
>> alias @echo-off='{ set +x; } 2>/dev/null'
>>
>> > I would stress the importance of this: the purpose of scripts is
>> > to execute commands, informing the caller of what they execute,
>> > purged of all the builtins and other calculations the script does
>> > in order to come to the commands.
>>
>> I don't think the purpose of scripts is to execute only the external
>> commands in general. The tasks implemented by builtins and other
>> calculations are allowed to be the purpose of scripts.
>>
>> > Many solutions are posted in the internet, all of them are hacks with
>> > lots of edge cases that make them fail in presence of commands
>> > containing special characters, redirections, substitutions, etc.
>>
>> Have you tried `set -v'? `set -v' is not a hack, (though there doesn't
>> seem to be a way to suppress echoing set +v).
>>
>> The detailed design of how the logged commands should be filtered and
>> formatted depends on the purpose of each user. We already have `set
>> -x' and `set -v'. We can adjust the format by PS4 for `set -x'. It's
>> unrealistic to add a new option for every new preference of detailed
>> filtering and formatting. If it is really needed, you can implement
>> your filtering through the DEBUG trap, but it would finally be best to
>> explicitly write `echo COMMAND' before every COMMAND that you think is
>> important (unless you are lazy). It's stable and flexible.
>>
>> --
>> Koichi
>>
>
Re: Echoing commands
Dear all,
thank you very much for your quick replies. The solution:
alias @echo-on='set -x'
alias @echo-off='{ set +x; } 2>/dev/null'
PS4=
Solves the problem, and relieves from writing "echo COMMAND" before each
command that should be shown.
-Angelo Borsotti
On Wed, 12 Jun 2024 at 23:21, Koichi Murase wrote:
> 2024年6月13日(木) 5:20 Angelo Borsotti :
> > This is not the same as debugging, for which set -x is devoted.
> > "set -x" makes the ensuing commands be printed, but prefixed
> > with "+ ", which makes the result look ugly,
>
> PS4= (as Greg has replied)
>
> > not to mention that
> > the following "set +x" is echoed too (there are hacks to suppress
> > the "set +x" output, but they are just hacks).
>
> What are the hacks? What are the problems with them? You can have aliases:
>
> alias @echo-on='set -x'
> alias @echo-off='{ set +x; } 2>/dev/null'
>
> > I would stress the importance of this: the purpose of scripts is
> > to execute commands, informing the caller of what they execute,
> > purged of all the builtins and other calculations the script does
> > in order to come to the commands.
>
> I don't think the purpose of scripts is to execute only the external
> commands in general. The tasks implemented by builtins and other
> calculations are allowed to be the purpose of scripts.
>
> > Many solutions are posted in the internet, all of them are hacks with
> > lots of edge cases that make them fail in presence of commands
> > containing special characters, redirections, substitutions, etc.
>
> Have you tried `set -v'? `set -v' is not a hack, (though there doesn't
> seem to be a way to suppress echoing set +v).
>
> The detailed design of how the logged commands should be filtered and
> formatted depends on the purpose of each user. We already have `set
> -x' and `set -v'. We can adjust the format by PS4 for `set -x'. It's
> unrealistic to add a new option for every new preference of detailed
> filtering and formatting. If it is really needed, you can implement
> your filtering through the DEBUG trap, but it would finally be best to
> explicitly write `echo COMMAND' before every COMMAND that you think is
> important (unless you are lazy). It's stable and flexible.
>
> --
> Koichi
>
Echoing commands
Hi, I am running bash 5.2.15(3)-release (x86_64-pc-cygwin) on cygwin running on Windows 10. Bash lacks a proper way of echoing commands, which is present in other shells, even in ones which are much less powerful, like, e.g. Windows CMD. This is not the same as debugging, for which set -x is devoted. "set -x" makes the ensuing commands be printed, but prefixed with "+ ", which makes the result look ugly, not to mention that the following "set +x" is echoed too (there are hacks to suppress the "set +x" output, but they are just hacks). What is needed is something equivalent to the @echo on, @echo off of the old DOS CMD, that are not printed and that enable/disable echoing of commands without any debugging marks added (such as "+" of set -x). The solution could look like: set -o log cat tmp >tmp1# or any other command set -o nolog producing the output on the console cat tmp >tmp1 I would stress the importance of this: the purpose of scripts is to execute commands, informing the caller of what they execute, purged of all the builtins and other calculations the script does in order to come to the commands. Many solutions are posted in the internet, all of them are hacks with lots of edge cases that make them fail in presence of commands containing special characters, redirections, substitutions, etc. Thank you -Angelo Borsotti
Re: [h-e-w] 23.1.50; Dead keys
Hi Eli, I might be a bit out of exercize with lisp, but have added these to my .emacs: (setq select-active-regions nil) (setq mouse-drag-copy-region t) (setq x-select-enable-clipboard nil) (add-hook 'term-setup-hook '(lambda () (global-set-key [mouse-2] 'mouse-yank-at-click))) to get back the old behavior (according to the changes you sent me, hopefully), but they do not produce the old behavior. -Angelo On 4 June 2018 at 17:45, Eli Zaretskii wrote: > > From: Angelo Borsotti > > Date: Mon, 4 Jun 2018 09:16:07 +0200 > > > > Why private email? > > > > It is the only one I have. > > Your original mail was sent to help-emacs-windows@gnu.org, which is an > Emacs-related mailing list. Unless you have your reasons, please CC > the list on your replies. > > > 1. left mouse button select a piece of text and then click again: > nothing is saved in the system clipboard, > > but it can be pasted with mouse-wheel > > 2. right mouse button: it selects from the cursor to the pointer, but > it does not save in the system clipboard. > > It can be pasted with mouse-wheel > > 3. copy icon in the toolbar: it saves in the system clipboard. The > text can be pasted with mouse-wheel or > > with the paste icon > > 4. the paste icon pastes the text contained in the system clipboard > > Ah, in that case it's a deliberate change in behavior: marking text by > mouse no longer puts text into the clipboard, by default. See the > following fragment from NEWS for Emacs 24: > > ** Selection changes. > > The default handling of clipboard and primary selections has been > changed to conform with modern X applications. In short, most > commands for killing and yanking text now use the clipboard, while > mouse commands use the primary selection. > > In the following, we provide a list of these changes, followed by a > list of steps to get the old behavior back if you prefer that. > > *** `select-active-regions' now defaults to t. > Merely selecting text (e.g. with drag-mouse-1) no longer puts it in > the kill ring. The selected text is put in the primary selection, if > the system possesses a separate primary selection facility (e.g. X). > > `select-active-regions' also accepts a new value, `only'. > This means to only set the primary selection for temporarily active > regions (usually made by mouse-dragging or shift-selection); > "ordinary" active regions, such as those made with C-SPC followed by > point motion, do not alter the primary selection. > > `mouse-drag-copy-region' now defaults to nil. > > *** mouse-2 is now bound to `mouse-yank-primary'. > This pastes from the primary selection, ignoring the kill-ring. > Previously, mouse-2 was bound to `mouse-yank-at-click'. > > *** `x-select-enable-clipboard' now defaults to t on all platforms. > > *** `x-select-enable-primary' now defaults to nil. > Thus, commands that kill text or copy it to the kill-ring (such as > M-w, C-w, and C-k) also use the clipboard---not the primary selection. > > The "Copy", "Cut", and "Paste" items in the "Edit" menu are now > exactly equivalent to M-w, C-w, and C-y respectively. > > Note that on MS-Windows, `x-select-enable-clipboard' was already > non-nil by default, as Windows does not support the primary selection > between applications. > > *** To return to the previous behavior, do the following: > > Change `select-active-regions' to nil. > Change `mouse-drag-copy-region' to t. > Change `x-select-enable-primary' to t (on X only). > Change `x-select-enable-clipboard' to nil. > Bind `mouse-yank-at-click' to mouse-2. >
Errs structures in states
Hi, when resolving conflicts due to %nonassoc, bison creates errs structures attached to states to hold the terminals that must be treated by the parsing engine as errors. At the same time, it removes the shift transitions and the lookaheads in reductions that have such conflicts. However, it seems that such errs structures have no effect: the parse tables are the same as if the errs structures did non exist. If that is the case, then they could be removed. Is this correct? Thank you -Angelo Borsotti
Re: [Ubuntu-x-swat] [Bug 888487] Re: Default video card driver broken
Hi Christopher, this is no longer a bug. Thank you -Angelo Borsotti On 9 January 2014 03:40, Christopher M. Penalver christopher.m.penal...@gmail.com wrote: Angelo Borsotti, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ . If it remains an issue, could you please run the following command in the development release from a Terminal (Applications-Accessories-Terminal), as it will automatically gather and attach updated debug information to this report: apport-collect -p xserver-xorg-video-nouveau REPLACE-WITH-BUG-NUMBER Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful. Thank you for your understanding. Helpful bug reporting tips: https://wiki.ubuntu.com/ReportingBugs ** Changed in: xserver-xorg-video-nouveau (Ubuntu) Importance: Undecided = Low ** Changed in: xserver-xorg-video-nouveau (Ubuntu) Status: New = Incomplete -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/888487 Title: Default video card driver broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/888487/+subscriptions -- You received this bug notification because you are a member of Ubuntu-X, which is subscribed to xserver-xorg-video-nouveau in Ubuntu. https://bugs.launchpad.net/bugs/888487 Title: Default video card driver broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/888487/+subscriptions ___ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 888487] Re: Default video card driver broken
Hi Christopher, this is no longer a bug. Thank you -Angelo Borsotti On 9 January 2014 03:40, Christopher M. Penalver christopher.m.penal...@gmail.com wrote: Angelo Borsotti, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ . If it remains an issue, could you please run the following command in the development release from a Terminal (Applications-Accessories-Terminal), as it will automatically gather and attach updated debug information to this report: apport-collect -p xserver-xorg-video-nouveau REPLACE-WITH-BUG-NUMBER Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful. Thank you for your understanding. Helpful bug reporting tips: https://wiki.ubuntu.com/ReportingBugs ** Changed in: xserver-xorg-video-nouveau (Ubuntu) Importance: Undecided = Low ** Changed in: xserver-xorg-video-nouveau (Ubuntu) Status: New = Incomplete -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/888487 Title: Default video card driver broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/888487/+subscriptions -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xserver-xorg-video-nouveau in Ubuntu. https://bugs.launchpad.net/bugs/888487 Title: Default video card driver broken Status in “xserver-xorg-video-nouveau” package in Ubuntu: Incomplete Bug description: I have upgraded from 11.04 to 11.10. 11.10 comes with a default video driver that does not work on a computer that has a Nvidia video card. The desktop freezes to that there is no way out except by switching off the computer. I then installed the proprietary Nvidia driver thru the Ubuntu Softare Center, and have solved the problem. I think that the upgrade tool should check that the computer has a Nvidia card and install its driver instead of installing the default one. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/888487/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Bug 888487] Re: Default video card driver broken
Hi Christopher, this is no longer a bug. Thank you -Angelo Borsotti On 9 January 2014 03:40, Christopher M. Penalver christopher.m.penal...@gmail.com wrote: Angelo Borsotti, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ . If it remains an issue, could you please run the following command in the development release from a Terminal (Applications-Accessories-Terminal), as it will automatically gather and attach updated debug information to this report: apport-collect -p xserver-xorg-video-nouveau REPLACE-WITH-BUG-NUMBER Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful. Thank you for your understanding. Helpful bug reporting tips: https://wiki.ubuntu.com/ReportingBugs ** Changed in: xserver-xorg-video-nouveau (Ubuntu) Importance: Undecided = Low ** Changed in: xserver-xorg-video-nouveau (Ubuntu) Status: New = Incomplete -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/888487 Title: Default video card driver broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/888487/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/888487 Title: Default video card driver broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/888487/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: git bash does not access drive f:
Hi Heiko, I have changed the external drive and seen that the new one works. The issue is, I guess, that the first drive was named My Passport, with a space in it, while the second one is Iomega. Spaces in drive names are not accepted by Linux, which could explain why they are a problem also with git bash (even if bash could access them using what is passed to it, which is a drive letter, and not the drive name). Thank you -Angelo On 23 November 2012 16:31, Heiko Voigt hvo...@hvoigt.net wrote: Hi, On Thu, Nov 22, 2012 at 08:07:55AM +0100, Angelo Borsotti wrote: I have attached an external disc, which appears on Windows as drive f: in Windows Explorer. Right-clicking on it displays a context menu showing (among other items) Git Init Here, Git Gui and Git Bash. The first two work properly on that drive. However, the git bash does not. Not even the one that is run from the icon: $ cd f: sh.exe: cd: f:: No such file or directory Is there any way to make it access drive f? Try using the environment variable MSYS_WATCH_FSTAB=YesPlease. We have an optimization in msys that does not update the virtually mounted folders and makes msys executable startups faster. I had similar issues with mounted disk images. The other alternative: After having the external disc mounted logout and login again that AFAIR that should also help. Cheers Heiko -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 454722] Re: inotify does not watch /proc
Hi Joseph it is a bit sad to spend time to isolate a bug, file it, provide all the additional data asked, see it confirmed and then see that it has been dropped because bug fixing has taken so much time as to make the OS release obsolete. Anyway, knowing that bugs that are not resolved in one Linux release are very likely to be present also in the next, I made again the same test: the problem is still there in 12.10. Do you need me to file another bug, or can you resurrect it? -Angelo On 16 November 2012 23:51, Joseph Salisbury joseph.salisb...@canonical.com wrote: This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug. This change has been made by an automated script, maintained by the Ubuntu Kernel Team. ** Changed in: linux (Ubuntu) Status: Confirmed = Won't Fix -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/454722 Title: inotify does not watch /proc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/454722/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/454722 Title: inotify does not watch /proc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/454722/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: push branch descriptions
Hi Junio, It would conceptually be a lot cleaner to treat updating of remote Ibranch description as a separate repository management class of Ioperation, similar to setting the repository description stored in I$GIT_DIR/description. I agree, it should be a distinct operation. I was thinking that when you have a remote bare repository, the normal way of adding contents to it is to push to it, and thus also adding a description should be done with some sort of pushing. Creating branches is also normally done with a push (think how difficult it is to create a branch in a bare repository when the HEAD is not set ...). -Angelo On 14 November 2012 14:57, Junio C Hamano gits...@pobox.com wrote: Angelo Borsotti angelo.borso...@gmail.com writes: currently, there is no means to push a branch description to a remote repository. It is possible to create a branch, but not to set its description. Correct. You have to go to the remote repository and run git branch --edit-description there; there is currently no way to do this remotely, which may be an issue, but... Would not be more correct to push also branch descriptions when branches are pushed? ... I do not think git push is the best place to do so, given the inherently local nature of branches and branch descriptions. Imagine the project creates a branch magic to enhance its system with magic words. The description for the magic branch in the project may say support magic words or something. You and your friend are tasked to add a handful of magic words, e.g. xyzzy, frotz and nitfol. You may start your work like so on your magic-xyzzy branch: $ git clone git://example.com/zork.git/ $ git checkout -b magic-xyzzy -t origin/magic And you say something like add xyzzy magic in its branch description. $ git branch --edit-description magic-xyzzy After finishing your work, you may push it $ git push origin magic-xyzzy:magic Should the description of the subtask add xyzzy magic overwrite the purpose of the project wide magic branch support magic words? Most likely not. The local nature of the description becomes even more clear if you imagine the case where the push at the last stage gets rejected due to non-fast-forward error (in other words, your friend has already pushed her support of the frotz magic to the magic branch. In fact, you would normally not directly push your magic-xyzzy branch to the magic branch, but you would do something like this once you are done: $ git checkout -b magic -t origin/magic $ git pull origin ;# to update with her work $ git merge magic-xyzzy $ git push origin magic And the last merge is where the description for your magic-xyzzy is used to fill the commit log template for you to explain your merge (that is, you are merging a branch whose description is add xyzzy magic). There is no reason to propagate the description of your magic-xyzzy topic to the description of shared magic branch when you push, as this merge commit already records what the branch that was merged was about. So you could modify git push to set the branch description when you push to create a branch remotely, but in general, git push should not be updating the branch description with the description of your local branch. This comes as a consequence of the fact that the purpose of the branch in the remote central repository is, more often than not, different from the purpose of the corresponding branch in your repository. It would conceptually be a lot cleaner to treat updating of remote branch description as a separate repository management class of operation, similar to setting the repository description stored in $GIT_DIR/description. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] push: update remote tags only with force
Hi Junio, actually, I proposed to add a key in config files, e.g. pushTagsNoChange to be set in the remote repo do disallow changes to tags, similar to pushNonFastForward that disallows non-fastforward changes to branches. I still have the impression that this is simple and clear, and allows the owner of the remote repository to enforce the policy s/he wants on her/his repository. -Angelo On 14 November 2012 14:22, Junio C Hamano gits...@pobox.com wrote: Chris Rorvick ch...@rorvick.com writes: Do not update, only add new may be a good feature, but at the same time I have this suspicion that its usefulness may not necessarily be limited to refs/tags/* hierarchy. I dunno. Are you suggesting allowing forwards for just refs/heads/*? No, it is a nonsense to unconditionally forbid fast-forwards to refs outside refs/heads/ hierarchy. I was imagining a more general feature to allow the *user* to ask Git not to fast-forward some refs (not limited to refs/tags/) during a push. If such a general feature were in place, you can think of your patch as automatically making the user to ask Git not to fast-forward refs in refs/tags/, which would be a mere special case of it. And I was wondering if such a general feature makes sense. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] push: update remote tags only with force
Hi Junio, That is an independent issue of deciding to accept or reject receiving a push from outside, no? Yes, it is. Actually I thought some means to let the owner do decide what to accept were already present (the pushNonFastForward config key), and going along this avenue I thought it could be appropriate to extent this a bit. -Angelo On 14 November 2012 18:32, Junio C Hamano gits...@pobox.com wrote: Angelo Borsotti angelo.borso...@gmail.com writes: actually, I proposed to add a key in config files, e.g. pushTagsNoChange to be set in the remote repo do disallow changes to tags, similar to pushNonFastForward that disallows non-fastforward changes to branches. I still have the impression that this is simple and clear, and allows the owner of the remote repository to enforce the policy s/he wants on her/his repository. That is an independent issue of deciding to accept or reject receiving a push from outside, no? You can implement any such policy in the pre-receive hook on the receiving end with a simple and clear manner, instead of adding specific logic to enforce a single hardcoded policy to the code that is flipped on with a configuration variable. In any case, I thought this series was about users who run push voluntarily stopping themselves from pushing updates to tags that may happen to fast-forward, so if we were to go with the configuration route, the suggestion would be more like [push] updateNeedsForce = refs/tags/:refs/frotz/ or perhaps [remote origin] updateNeedsForce = refs/tags/:refs/frotz/ if we want to configure it per-remote, to specify that you would need to say --force to update the refs in the listed hierarchies. Then your patch series could become just the matter of declaring that the value of push.updateNeedsForce, when unspecified, defaults to refs/tags/. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] push: update remote tags only with force
Hi Junio, I am *not* convinced that the refs/tags/ is the only special hierarchy whose contents should not move is a bad limitation we should avoid, but if it indeed is a bad limitation, the above is one possible way to think about avoiding it. What other hierarchy besides branches and tags is there? Do you have in mind some other that should not move? -Angelo On 15 November 2012 01:09, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Addendum. In any case, I thought this series was about users who run push voluntarily stopping themselves from pushing updates to tags that may happen to fast-forward, so if we were to go with the configuration route, the suggestion would be more like [push] updateNeedsForce = refs/tags/:refs/frotz/ or perhaps [remote origin] updateNeedsForce = refs/tags/:refs/frotz/ if we want to configure it per-remote, to specify that you would need to say --force to update the refs in the listed hierarchies. Then your patch series could become just the matter of declaring that the value of push.updateNeedsForce, when unspecified, defaults to refs/tags/. The above is not a you should do it this way suggestion, by the way. I was just explaining what I meant by it may be a good feature, but may not necessarily be limited to refs/tags in my earlier message in a different way ... and a possible design that lifts the limitation may go like this. I am *not* convinced that the refs/tags/ is the only special hierarchy whose contents should not move is a bad limitation we should avoid, but if it indeed is a bad limitation, the above is one possible way to think about avoiding it. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git push tags
Hi, Pro Git, By Scott Chacon says: 2.6 Like most VCSs, Git has the ability to tag specific points in history as being important. Generally, people use this functionality to mark release points (v1.0, and so on). 2.6.2: A [lightweight] tag is very much like a branch that does not change ... Clearly, tags are not the same as branches. They are there for a different purpose. If they were exactly the same as branches, there would be no need for them. Of course, they share some behaviors with branches, and there are several commands that handle them in the same way, but the key point is that they do not change, or at least they do not do that by default. The ability to force changes of tags is there only to correct tags that might have set tags to the wrong points by mistake. So, what I am telling is that this property must be preserved consistently across all commands, including git-push. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git push tags
Hi Drew, sure. That is a good starting point. I would suggest to block tag updates of existing tags if a dedicated option is present in the config of the remote repo, like, e.g. pushOverwriteTags. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git push tags
Jeff, Then on top of that we can talk about what lightweight tags should do. I'm not sure. If tags (even the lightweight ones) do not behave differently from branches, then they are of no use, and the main difference is that they do not move. So, I would suggest not to move them either. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git config error message
Hi Ben This still wouldn't be an error condition though, especially in terms of how git config should treat it. The man page says: This command will fail with non-zero status upon error. Of course, one might claim that this does not mean the truth of the reverse condition, i.e. that when the command returns 1 that is necessarily an error, but I would leave that avenue of thinking to philosophers. Besides that, it is common practice in *nix OSs to consider a return != 0 as an error. It should be up to the consumer of the information to display, or not, any error or diagnostics that don't result from either a bad request (your first case) or a malformed configuration file. This fits with the callback nature of how the config file is parsed by builtin tools. The exit code from git config with a missing key is enough for the consumer to make this decision. A well-behaved, user-friendly program, when detects an error tells the user what went wrong. How can otherwise the user tell a corrupted configuration file from a missing key? Of course, is is possible to provide a git-config that simply returns 0 when it has got the key and 1 when it does not, without issuing any error message, but the current one is not like that, it is a middle way solution. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git config error message
Hi Andreas, Is grep not finding a match an error? Is cmp finding a difference an error? It all depends on the context. Manpage of grep, exit staus: Normally, the exit status is 0 if selected lines are found and 1 otherwise. But the exit status is 2 if an error occurred, ... cmp uses the same convention (albeit not reported in its manpage). I am not stating that all linux commands and utilities follow exactly the same convention, but these two are at least consistent with themselves always returning an exit status that has a well defined meaning. git-config returns consistently the exit status, it only issues in certain cases messages and in others not. A consistent solution could be for it to return 0 upon success, 1 when the section or key is absent, and 2 when the config file does not exist or is corrupt issuing also an error message. -Angelo How can otherwise the user tell a corrupted configuration file from a missing key? You cannot, as long as your configuration file is well-formed, because a missing key is an expected condition in many cases. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git push tags
Hi Drew, Changing the tag in the local repository is a tag modification operation. Pushing that change to a remote repository DOES NOT execute git tag in the remote. Plain and simple the two are different operations. They are different for what concerns the implementation. They are not necessarily so for what concerns their semantics, and the most straightforward is to apply to the remote repository the changes done on the local one -- the changes that can legally done on it -- and changing a tag is not one allowed (unless forced). Obviously, the semantics of git-push is different, and then needs to be described clearly. Note that some (probably most) of the operations that are disallowed on the local repo are also disallowed by git-push, like, e.g. deleting the current branch. But the user cannot tell what is disallowed and what not if the man page does not state it. So here we come to the core argument. Is sounds to me like you want changes to remote tags to work differently from push updates to ALL other references. The required change, if I'm not mistaken, would be for tags to not permit fast-forward updates while all other references would be pushed normally. From my brief and un-enlightened look at the push code I can't see that being as easy as it sounds. No, I was hoping that git-push refused to change tags at all, unless forced (e.g. prefixing them with +), as it is on a local repository. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git push tags
Hi Drew, git is an open source, community project, which means that it benefits from all the contributions of many people, and they are not restricted to patches. If the only one suggestions that were taken into account were patches sent by people that had the time to study the sources and propose changes, then we would miss the opportunity of taking many good things that the community generates, like new ideas for example. By the way, I already browsed the code, but have seen that there is not only push.c to understand, but a dozen or more of other sources. This is why I am not yet able to propose patches. But I am using git all day, and often come to unexpected or undocumented behaviors, and want to share my findings in case they could serve to improve git. This means to me to spend time in formulating them the best I can to make others understand what I have found, and that is a contribution too. Here is a proposed change to the git-push manpage: - section: DESCRIPTION, first paragraph (Updates remote ..), add at the end: Remote references (branches and tags) that do not exist are created. The ones that exist are updated except when + is not specified and they are not fast-forward updates. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git push tags
Hello Drew, I made some further tests on git-push to see if it handled branches and tags in the same way, and have discovered the following differences: - git push origin --delete master remote: error: By default, deleting the current branch is denied - git push origin --delete vx(where vx is a tag) ... accepted This is consistent with what is done on the local repo: deleting the current branch is disallowed, but deleting a tag is allowed (even when HEAD points to it). That means that git-push does not handle branches and tags exactly the same. Kacper thank you for the patch. To keep downward compatibility, the denial to update tags should perhaps be enabled with some option. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[nodejs] nodejs vs phyton
nodejs and phyton are somehow comparable: they are both interpreted programming languages with a binding for the underlying OS. Does some comparison document exist? -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups nodejs group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
Re: git push tags
Hi Drew, You specified -f (force) and it did exactly what you asked. That is fully documented (git help tag). Yes, it is, and I used it to show that there is a need to specify explicitly the intent to change a tag, that without such an indication would not be changed. Tags have many uses. Some of those uses are harmed when tags change and some aren't. That's a philosophical argument I agree, but in this case the computer does not provide any means to implement the same strategy on tags as it does instead on local repositories. Why I must force a change on a tag in the local repository and instead I can change it without any forcing in a remote one? Are remote repositories less protected than the local ones? I think that to be consistent, the same strategy should be used on all repositories, i.e. rejecting changes on tags by default, unless they are forced. -Angelo -- -Drew Northup -- As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: push race
Hi Jeff, it would be worth to put your description as comments in the code for future reference. Thanks -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: feature request
Hi Andrew, one nice thing is to warn a developer that wants to modify a source file, that there is somebody else changing it beforehand. It is nicer than discovering that at push time. Take into account that there are changes in files that may be incompatible to each other, or that can be amenable to be automatically merged producing wrong results. So, knowing it could help. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: push race
Hi Marc, correct, there will be no file overwriting because no files are written on the work tree. I tried to follow the actions of the program, but did not quite catch the 6. you mention. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git checkout error
Junio, giving the user a better error message is certainly an improvement. But would not be another improvement to describe better the command syntax so as to help the user write the command right in the first place? After all, what is the syntax section in commands for? If I had seen in the syntax: git checkout [-q] [-f] [-m] [ [--track|--no-track](-b|-B) new_branch] [start_point] I would have written the command correctly, and not even stumbled on a misleading error message. Note that the above syntax is exactly what the command must look like. The syntax is mostly a description of the form of command for the user. Internally, the implementer can use it or can even use a different one (e.g. a more lenient one and detect errors at the semantic level instead). But here what matters is not how the command is implemented, but how the user has to form it. Why it is so difficult to convince people to make documentation better? -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git checkout error
Hi Junio It is not difficult. The discussion on this list is usually done via patches, and without one, constant talking is buried in other noise and often go unnoticed. Could you accept for very small changes also the simple indication of the change itself instead of a patch? There is however an issue about documentation consistency. Do we use elsewhere ( A | B | C ... ) to denote You must write one (and only one) among A, B, C, ... consistently in the documentation? There is no standard for it. Posix provides a standard for commands: http://pubs.opengroup.org/onlinepubs/9699919799/ but does not mention (normal) parentheses to indicate choice. There is one applicable standard for this, though, the ISO 14977: http://www.cl.cam.ac.uk/~mgk25/iso-14977.pdf which gives parentheses () the meaning of grouping (and then with | inside them, the meaning of choice). Parentheses are used in: - git branch - git commit - git reset - git remote - git submodule - git bisect - git grep - git am - git apply - git format-patch - git cat-file - git commit-tree - git rev-list - git update-index I did not find in the documentation an explanation of the use of parentheses, but to me they seem to have been used consistently. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi Philip and all, let me explain in full what is the problem that I tried to solve, and how along the way I stumbled in something that seems to me a git bug (at least a documentation one). There is an RD team developing software using a workflow that is similar to the integerator-manager one (the one described by Scott Chacon in chapter 5 of ProGit). Developers implement features using a local repository hosted on their workstations, and when finished push on a server; integrators pull from it and put all the contributions together. Since integrators rebuild always the software after merging all contribution, there is no need for the developers to push the binaries. Not pushing them speeds up uploading. In order to make life simpler and safer, scripts are provided to perform the pushing, pulling, etc. operations. So, most of the git commands shown below are actually run from within scripts. The development of each feature is done in a dedicated topic branch, and the commits done in it contain both the sources and the binaries (to allow to recover fully a previous snapshot when a later change broke a previous one). When pushing, there are these needs: 1. push the sources only 2. push only the last commit of the topic branch (not the whole history) A note on point 2: the integrators are not interested in seeing all the commits that developers did while implementing their features. Having all the history makes their repositories cluttered. In order to avoid pushing all the history, orphan branches are used to parallel the topic ones. When pushing, first a commit is done on the topic branch, and then a snapshot is created in the parallel branch with the same files, binaries removed. The general case is: source branch D' : topic branchABC---D In the picture, the developer made 4 commits, and pushed the sources of the last one, D. A D' is created on the source branch (the relationship with D is indicated with a dotted line). The push script must cope with all the cases that may occur: 1. the general one (the one in the previous figure) 2. none of the commits in the topic branch with binaries (i.e. D and D' with the same tree) 3. push done immediately after the first commit (A) 4. a push done after another The script: 1. creates the source branch if it does not exist yet (git checkout --orphan), otherwise makes HEAD point to it 2. sets a .git/info/exclude file that excludes the binaries 3. removes the binaries from the index (git rm) 4. creates a commit on the source branch 5. pushes it 6. restores the HEAD and index as they were before The operation that caused problems was nr. 4. In all the cases enlisted above, a git commit creates a brand new and unique commit because either it has a parent that is different from that of any other commit, or because its tree is different. All, except case nr 3 when there are no binaries: source branch A' : topic branchA In this case the parent is the same as that of A, i.e. none, and also the tree is the same. In order to try to force the creation of a brand new and unique commit even when the trees are the same --allow-empty has been used, but this did not avail because git commit creates a brand new one only when the seconds of the system clock have ticked before it. Some of you have suggested to create an A' that is not orphan in such a case, which is a workaround, and some others to change the message in it, and this is another. I choose the latter because it allows to keep the source branch orphan in all cases. So, there are workarounds, and the script has eventually been implemented and tested, but the unexpected, time-dependent behavior of git commit is there and someone could stumble on it sooner or later. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi Phil, \ And why is this a problem? Is there a process or person watching the server for a new commit? Is it not enough to notice that the pushed-to branch has a new HEAD? Yes, the developers use the git gui to see the graph of branches and commits. The simpler and uniform it is, the better. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi Philip, This has the developers having a full copy/history of the integrators relevant branches, so that when the pull of the developers branch occurs there is a proper link to the integrators history. True. There are other ways to create a branch which has all the developers feature history removed, rather tha using an --orphan, which removes the integrators history as well. The topic branches are populated only by the developers. The integrators merge all the topic branches into branches dedicated to the integration. In case of need, the developers can pull these (with all the integrators' history). The disconnection of the D' source branch makes it sound like you have a second SCM system that you have to put stuff into, which is independent of the development teams git repos. I have this [hassle] at my $dayjob -one almost has to hide git from the powers-that-be. Well, there is another way to see this: think to a distributed SCM in which there are some parts of the contents that are shared and some that are not. The technique to use disconnected branches is only a way of implementing this. If, say, git push had an option to filter out the binaries there would be no need for disconnected branches. A reasonable solution. You can also create a sentinel (--root) commit for any time that you need to create the source branch, just so it (the real source code commit) has a different parent when on source branch to that on the binaries branch. Do you mean I could create an empty root commit to be used as parent for the real source commit? Or that there is some --root option to be used? -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi Phil,
Another technique could be to simply switch to the sources branch, and then
use a 'git clean -x' with an updated .gitignore ('reset' the file from the
source branch)[or use the exclude file] to remove those now ignored
binaries, before doing the commit.
Actually, the first time I make a git checkout --orphan to create the
branch, and the following times a git symbolic-ref HEAD to switch to
it. Then I set a proper exclude file and do a list=`git ls-files -c -i
--exclude-standard` to get the paths of the files to remove from the
index. Then I remove them with git rm --cached. Then all is ready to
make a git commit. At this point I restore the HEAD and the index as
they were before.
This allows me to keep the work tree pristine, no files removed or
loaded in it from the repo,
which makes the script quite fast.
-Angelo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi PJ and Hannes, try to run the last script that I posted, with and without a sleep 1 before the last commit: git init echo aaa f1 git add f1 git commit -m A git checkout --orphan sources git commit -m A --allow-empty and git init echo aaa f1 git add f1 git commit -m A git checkout --orphan sources sleep 1 git commit -m A --allow-empty In the first one, no new commit is created, and the sources branch is not orphan (you can easily see it with the git gui). In the second one, a new commit is created, and the sources branch is orphan, as expected. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi Hannes, Perhaps you are confused by the fact that the commit you made first does not have a parent, either. But that is just a side effect that it happened to be the very first commit that you made after 'git init'. Well, I know that, and this is why I added --allow-empty. The man page of git commit (This option bypasses the safety, ...). I thought that it would unconditionally create a brand new, commit. Your case does not demonstrate a bug in git. The bug is that the git commit --allow-empty does a different action depending on whether the system clock has changed its seconds right before the command. This is a time-dependent behavior, and it is very harmful. Our applications must never behave differently depending on the time they are run or on the processor speed. It is an issue of correctness and robustness of software. To have a predictable behavior, i.e. to create a brand new commit with git commit --allow-empty, the command in a script must ALWAYS be preceded by a sleep 1 so as to make sure that the date and time it will use are for sure different from any other commits'. But then it would be a lot better to embed such a sleep in the command. If that is not possible, then the users must be warned in the man page that the command sometimes may not create a brand new commit, and that if the user instead wants it s/he should change something in the commit, like, e.g. the message. Why don't you use a different commit message to ensure that there is a difference between the commits? This is what eventually I did to force the creation of a brand new commit. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
In reply to Philip, I understand what the implementation does, but I am stating that it is not what the user (by reading the man page) expects. The user adds --allow-empty to have a different unique commit, such seems to be the purpose of the option. Unfortunately, it gets that only sometimes, depending on the exact instant in time the command is executed, which is out of his/her control. I think that you would agree with me that this is not a nice behaviour. How could a user ever use a command that is not predictable? If it is not possible to change the implementation, at least warn the user in the man page. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi Matthiew, Then the second commit does not create a new blob object for file2.txt, because it has the same content as an existing one. But the point is: you really don't care, or indeed, you care about sharing the blob objects to save disk space. That is fine, and it is well documented. It is predictible: give it twice the same inputs in the same conditions, and it will yield the same output. Well, I have some difficulties to hit the return key while watching the system clock at the same time so as to make sure that the command is executed before the seconds change. So, it theory it would be predictable, but not in practice. Note that commands must be predictable for the user that writes them, i.e. the user must be able to figure out what the result is. Which is certainly not the case here. You still didn't tell us where the problem was. I described it few mails above. I wanted to create an orphan branch. The command to create it is git checkout --orphan. However, the branch is not actually created until a commit is done on it. Then I did such a commit (all this is placed in a script to be used by my developers), but if there are no changes, git commit does not create a new one. To force it to create a brand new one I added --allow-empty to it because the man page stated that it would bypass the check that prevents to make a new one. The I discovered that sometimes --allow-empty does not behave as expected. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi Andreas, Where does the manual say that --allow-empty implies a different and unique commit? In the git commit man page: --allow-empty Usually recording a commit that has the exact same tree as its sole parent commit is a mistake, and the command prevents you from making such a commit. This option bypasses the safety, and is primarily for use by foreign SCM interface scripts. By reading: the command prevents I understand that a new commit is not created, and This option bypasses that it is instead created. Perhaps my reading was a bit straightforward, but a man page is not a sort of ancient holy writing that the reader has to sift every word to understand hidden meanings, it should be something clear and plain. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi Thomas, The documentation only states that it will skip the 'same tree as parent' check, not that it will *always* create a new commit. Ok, understood: you believe that the documentation is clear, and I that it is somehow not. I would prefer to have it more plain. But that is not all the story. The behavior of the command remains time-dependent, so that a user cannot reliably predict its result. I think that this is an ill-specified option. I would not insist in removing it (although that would be the correct solution), but at least to warn the user about this possibly unexpected behavior. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi Phil I think what you are missing here is that the script does _not_ have to take care for this special case. The script can do the same thing it does for all the other cases and it will work just fine. This is because your goal, as I understand it, is this: A. Take this branch, B. Copy it but remove the binaries, C. Push it to the remote (with no binaries) If the branch has no binaries to begin with, then B is a no-op. Your insistence that the new commits get unique SHA1's is unnecessary and is what is causing your trouble. Suppose the branch has binaries. Then the only way to avoid to push them is to create an orphan branch (one that has no parents), otherwise git push will upload also the parent with its binaries. This is why there is a need to make the script perform different actions depending on the presence of the binaries. In the attempt to make the script handle both cases in a simple way I tried to make an empty commit, and discovered the time-dependent behavior of it. Consider this analogous operation: A. Take this file, B. Remove every line that does not contain foo, C. Cat the result to the console (with only foo lines) This example differs from the commit one in that the user has to cope with data that s/he can fully control (the contents of files), while in the other s/he has to cope with the passing of time, which s/he cannot control. So, taking the files I can predict the result, but taking the commits, I cannot because I do not know exactly when they will actually be run. Time is a sort of independent variable that I know only approximately (or very approximately when the commands are embedded in scripts). It seems to those more familiar with git that you are saying that this is the problem, that the operation did not work because the results are not unique each time. Exactly. But if you ignore the SHA1 of the commits and just rely on the branch names, I think you will be happier. This is because two branches can refer to the same SHA1 commit without causing any problem. You may find that sometimes when you push there is no update applied to the server. But this is not a mistake. It is simply that the server already has the same contents as you are pushing, even though your local branch name is different than it was before. Actually I ignore the SHA1 of the commits, and rely on the branch names I have topic branches and /src/topic branches. Developers push when they have something new. Of course the scripts must take care of when they are called and there is nothing to push, but that is not a big problem. I eventually found a workaround, which is to change the commit message, forcing then git commit to create a brand new commit. I think when you say orphan you mean it has a different SHA1 than any other commit. But this is not what orphan means. No, I mean that it has no parents. Actually, in the special case in which there are no binaries, I could create a branch that points to the same commit as the branch that it is mirroring, and push it. However, this has two disadvantages: 1. that it will not be an orphan while in the more general case it is, and 2, that the history of commits will be pushed to the remote server, while in the general case (with an orphan) it will not. I preferred to have a unique branch topology so as to make the picture as simple as possible for the developers. Note that eventually I solved the problem with a tweak. I still believe that the git commit command does not behave properly, and that changing nothing (implementation or documentation) leaves a drifting mine on which someone (or even myself) will stumble sooner or later. I am spending time to write all this because I care for git and I would really see it improving over time removing weak spots, and believe that you do the same. -Angelo Phil -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi Phil, Perhaps the confusion arises from the the meaning of the safety. In this case, the safety mechanism in place is to prevent you from creating a child commit which has the same tree contents (working directory) as the parent commit. It will not be the same commit because it has different parent(s) than its parent commit; but the tree (working directory) is the same and git normally prevents you from doing this because normally this is an accident, a mistake. --allow-empty tells git you intend to do this and so it should bypass this no changed files safety mechanism. It is not a safety to prevent you creating a new commit with the exact same sha1; the safety is concerned only with the exact same working directory file contents. Can you suggest a rewrite of this description which would make it more clear? Instead of: Usually recording a commit that has the exact same tree as its sole parent commit is a mistake, and the command prevents you from making such a commit. This option bypasses the safety, and is primarily for use by foreign SCM interface scripts. I would suggest: Usually recording a commit that has the exact same tree as its sole parent commit is not allowed, and the command prevents you from making such a commit. This option allows to disregard this condition, thereby making a commit even when the trees are the same. Note that when the tree, author, parents, message and date (with the precision of one second) are the same as those of an existing commit object, no new commit object is created, and the identity of the existing one is returned. Phil -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi Andreas, But where does it say different and unique? It does not, but it says: Usually recording a commit that has the exact same tree as its sole parent commit is a mistake, and the command prevents you from making such a commit., followed by This option bypasses the safety ... leading to thing that the option negates that prevents above. I do understand that by reading very carefully each word of these sentences one can eventually figure out that the option removes the check on the tree only, and that all the others remain, including the one on the identity of the time. However, it does not say that the time must be equal with the approximation of one second. Apart from this detail, it does not state plainly that no commit object is created. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi Matthiew, You don't understand what an orphan branch is. I do not think so. I wanted to create a branch with a commit that has no parent, and I think that this is called orphan branch. I wanted also to have another branch, pointing to a different commit, the difference being that this contains binaries, and the other does not. So, having two references pointing to the same commit is not a problem for me, but it is not either the solution. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
HI PJ, take a git commit without --allow-empty: if the trees are equal, it creates no commit, and if the trees are different it creates one. Take then a git commit --allow-empty: if the trees are equal it may create a commit or not depending on the parent, message, author and date; if the trees are different it creates a commit. So, the statement does not apply to commits in general. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi Andreas, as a user, and owner of a repository I do care about the objects that are in it. I do not care about the way they are names, be it numbers or sha's, but for sure about their existence. So, for me it is important if a command creates a new commit or not. The commit is _always_ created, with a name depending on the parent, message, author and date. I do not understand this: I have produced several examples that show that it is not created, i.e. that the very same objects are present in the repository after the command execution as they were before it. It is possible, though, that you use the word create with a different meaning. Most dictionaries state: to cause to come into existence, i.e. before creation the thing does not exist, and after creation it does. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi having such a time-dependent behavior is not nice. It means that the user must know it, and wait patiently before issuing the command, or in a script add a sleep before the command. The choice is then between adding a warning in the man page (please wait at least a second before executing the command) or adding a sleep inside the command itself. Obviously, the second alternative looks much more appealing. Thank you -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi Junio, if I put on my head the implementor's hat, I would agree with you: that command after all behaves as implemented. However, if I put the user's hat I would reason differently. What I need are predictable commands, and that by all means is not. This because the time at which a command is executed is not predictable (more precisely, the statement in it that reads the system calendar). So, even if an implementor thinks that this behavior is reliable, a user thinks that it is not predictable. Actually, I called that command from within a script, and thus I could not count on it being executed within 1 second from the last commit. Read also the paragraph in the man page that describes it: Usually recording a commit that has the exact same tree as its sole parent commit is a mistake, and the command prevents you from making such a commit. This option bypasses the safety, and is primarily for use by foreign SCM interface scripts. I cannot find any clue in it that lets me know that is does not create a commit if the time is within the same second as the other commit. My suggestion is either to include a sleep in the command so as to guarantee that a commit is created, or to remove the option. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: erratic behavior commit --allow-empty
Hi Junio, It does create one; it just is the same one you already happen to have, when you record the same state on top of the same history as the same person at the same time. No, it does not create one: as you can see from the trace of the execution of my script, the sha of the commit is the same as that of the other, which means that in the .git/objects there is only one such commit object, and not two with the same sha. The meaning of the word create is to bring into being something that did not exist before. There is no creation if the object already exists. And how would it help what to insert a sleep for 1 second (or 1 year for that matter)? As you said, it reads from the system clock, and there are millions of systems in the world that have Git installed. You may record the same state on top of the same history as the same person on two different machines 5 minutes in wallclock time in between doing so. These two machines may end up creating the same commit because one of them had a clock skewed by 5 minutes. I understood that the command does not create a new commit if all its data, i.e. tree, committer, ... and date are the same, representing the date with 1 second precision. Sleeping for 1 second guarantees that there is no commit in the repo that has the same time as the time after the sleep, i.e. that the command creates a (new) commit. What problem are you really trying to solve? You mentioned importing from the foreign SCM, I quoted a piece of the man page of git commit, that states that --allow-empty bypasses the safety check that prevents to make a new commit. That piece incidentally states that it is primarily used by foreign SCM interface scripts. But of course it can be used in any script that needs to build a commit on top of another. You also did not seem to have read what I wrote, or deliberately ignored it (in which case I am wasting even more time writing this, so I'll stop). I did not deliberately ignore what you wrote. I might have missed some point though. This does not have anything to do with --allow-empty; removing the option would not help anything, either. I am reporting a problem with --allow-empty, so why you say that this does not have anything to do with it? Removing the option removes a behavior that is not predictable. Often it is better to remove a feature that turns out to be inconsistent than to leave it in the software. Of course a much better avenue is to make it consistent. Run the following on a fast-enough machine. I did, and obtained most of the times I was quick enough and sometimes I was not quick enough, which is the same kind of behavior of my script. The problem I am trying to solve is to push to a remote server the source files only, while keeping in the local repo both sources and binaries. To do it, I keep an orphan branch, say sources. When I make a commit on the master branch, I make also a commit on the sources one after having un-staged (git rm --cached) the binaries. The script that does this must cope also with the particular case in which in the commit on the master branch there are no sources. Basically the script does: # this is the commit on the master branch git init echo aaa f1 git add f1 git commit -m A # this is the piece of the script that builds the sources branch git checkout --orphan sources # git rm --cached ... remove binaries, if any git commit -m A --allow-empty git rev-list --all --pretty=oneline When there are binaries in the commit A, they are removed, and the tree for the second git commit is then different, and the commit is actually created. When there are no binaries (as in the script above, in which the removal is commented out), the second git commit would not create any new commit, and I would not have an orphan branch. Thence the --allow-empty to force it to create a new commit. Unfortunately, it creates a new commit only if the system clock changes the seconds of the system time between the two git commits. If you insert a sleep 1 before the second git commit, the commit is really created. I spent many hours to spot this time-dependent error -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git gui does not open bare repositories
I have removed the Italian localization so as to make git gui use the English one. The result is the same as I have found before. The message is: Not a Git repository: remote.git. Thus, the misleading message is there. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git gui does not open bare repositories
Hi Ben, I am running git gui on Windows 7. Are you running it on Linux? -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git gui does not open bare repositories
Hi Ben, I run the same test on Linux, and have got the same results as you did. So the problem is only on Windows. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-users] avoid pulling binaries
Hi Konstantin, I have got your suggestion, and done the following: - created a topic branch - forked a develop branch from it - done all the development work, several commits saving all files, sources and binaries - git checkout topic - git merge --squash --no-commit develop (this avoids to move the develop history to the topic) - git rm -r --cached *.all binaries - mv .git/info/exclude .git/info/exclude.save - put a line in .git/info/exclude: *.all binaries - git commit -m some message - mv .git/info/exclude.save .git/info/exclude - git push remote topic This keeps a clean topic branch in which there are only source files and a clean history, that can then be pushed to a public remote repository. -Angelo -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] avoid pulling binaries
Hi Konstantin, the idea of using merge --squash comes from: 1. the need to have a clean history of the changes: the developer that implements something (e.g. a feature or a bugfix) on a topic branch could have done it creating several commits in her/his development branch, commits that are not interesting for the overall project. E.g. s/he could have committed, then run some tests, found bugs or improvements in the code, and then have committed again. This is relevant only for the developer. 2. the need to push only the binaries to reduce push time. A merge without --squash creates a commit merge that has as parents the topic and the develop merge. A push transfers all of them, including the commits on the develop branch, that contain the binaries. -Angelo -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] avoid pulling binaries
Suppose I have a private repository and a public one. I develop using my private repository, and at significant steps I do a commit in which I save all, sources] and binaries. The reason for saving binaries is to allow to recover a previously committed version without having then to rebuild all binaries. When I have completed the development of a feature, I push it to a public repository, one that is accessed by an integrator, that takes my contributes and other developers' as well, and integrates all of them. After having pulled all the contributed, the integrator always rebuilds the binaries. Therefore, there is no need for me to push binaries from my private repository to the public one, and for him to pull them. Is there a way in git to avoid to push and pull binaries in this workflow? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/txZDxAw_laEJ. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[twdev] Re: Testers needed for TiddlyFox, a TiddlyWiki extension for Firefox
The is a long discussion ongoing on this problem in Firefox, see: https://bugzilla.mozilla.org/show_bug.cgi?id=546848 Lots of complaints, and some proposals to solve the issue. Someone mentioned Tiddlywiki there. It would be appropriate to see there the complaints of the developers of Tiddlywiki too. -- You received this message because you are subscribed to the Google Groups TiddlyWikiDev group. To view this discussion on the web visit https://groups.google.com/d/msg/tiddlywikidev/-/YNCk58J_m-sJ. To post to this group, send email to tiddlywikidev@googlegroups.com. To unsubscribe from this group, send email to tiddlywikidev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
Re: WebAPI Security Discussion: Device Storage API
Apps that are implemented using traditional technologies, like, e.g. C++ or Java have already solved this problem, and the solution is quite simple: trust the origin of the app. E.g. when downloading and installing Libreoffice I trust that the app will not wipe out my filesystem and that it will not tamper my OS (e.g. it will not contain viruses). I think that we must not reinvent the wheel, as unfortunately has been done many times with web technologies. If ever web technologies want to become a replacement for the traditional ones, they must allow to do the same things, possibly in a better and simpler way. So, the solution here is very simple: ask the user if s/he trusts the app, and if s/he does, provide full access to the filesystem (and remember it). Do not meddle with what the app wants to do, e.g. that it wants to read only music, or whatever. No OS ever did that when providing an API for its filesystem. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: checkout extra files
Hi all,
consider this example:
$ mkdir gittest
$ cd gittest
$ git init
Initialized empty Git repository in d:/gittest/.git/
$ touch f1
$ git add f1
$ git commit commit -m first commit
[master (root-commit) e6f935e] first commit
0 files changed
create mode 100644 f1
$ touch f2
$ git checkout e6f9 -- *
error: pathspec 'f2' did not match any file(s) known to git.
Note the error.
It is clear that the set of file names that git checkout is taking is
the union of the ones that
match the specified path ('*') in the work directory (gittest) with
the ones that match the
path in the specified commit (e6f9).
I am not questioning this behavior, but the documentation, which does
not describe it:
It updates the named paths in the working tree from the index file or
from a named tree-ish ...
There are two ways to read this sentence:
1. named paths referred to working tree, i.e. the files whose
names match the
paths among all the ones present in the working tree
2. named paths referred to the index or tree-ish, i.e. the
files whose names match
paths among oll the ones present in the index or tree-ish
In both cases, nothing tells the user that the matching of the paths
is done over the union
of the set of file names of the working tree + ndex or tree-ish.
Indeed, the first time I have seen the error above I got quite
confused because I thought
that the checkout would restore the working directory as it was at the
time I made the commit,
without bothering about extra files that the directory contained at
the moment (and note that
f2 is not even a tracked one).
This behavior is a bit strange, but if it is a hundred percent clearly
documented I can live
with it.
I think that knowing precisely what files are involved in this command
is essential for the user.
-Angelo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: checkout extra files
Hi, figuring out what the behavior is by guessing how a command is implemented and what are its interactions with the shell is a bit hard for the user: s/he should instead get it from the documentation. I tried to figure it out from the examples I have done, and as you see, I did not get it quite right. The issue here is that the paths must denote filenames that are present in the index or tree-ish, so, wildcards are misleading since they would instead be interpreted with respect to the working directory. A possible way to make this clear is to warn the user to quote paths that contain wildcards. Something like, e.g.: Note that paths that contain wildcards must be quoted in order to denote files that belong to the index or tree-ish. Otherwise, they are interpreted by the shell with respect to the current directory, with a result that may depend on the shell. -Angelo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[git-users] git contents model
I have the impression that the underlying model of a git repository is made of a .git archive plus a work directory in which (some version of, e.g. the latest) the files are present. I.e. at least one version of the files are stored twice. E.g. suppose I create a new project and initialize git in it. Then I can create files and commit changes. When I am done, i.e. the files are ready to be released, I make the last commit, and thenI have the files in the work directory AND in the .git. At this point if I delete the files from the work directory, I take the project to an inconsistent state (as reported by git status, which tells me that all files have been removed). So, the nornal state of a released project is to have its files stored twice. Is this correct? Is this what we want? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/sGf0sgwK_NwJ. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [Bug 480566] Re: epoll_wait man page error
Hi Michael. the correct text should be: EINTR The call was interrupted by a signal handler before any of the requested events occurred; see signal(7). The issue is that EINTR is not returned when the timeout expires, but only when one of the events occur. -Angelo -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/480566 Title: epoll_wait man page error To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/480566/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 888485] Re: missing icon
I have logged in as guest, and the missing icon is shown. In my home directory there is no .profile. The contents of my xsession error file is quite similar to that of the guest user. What could then the cause of the missing icon? -Angelo -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/888485 Title: missing icon To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-session/+bug/888485/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 888485] Re: missing icon
The installation is a fresh one, with the default theme. If you need I can take a photograph of the screen and send it to you. -Angelo -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/888485 Title: missing icon To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-session/+bug/888485/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 888485] [NEW] missing icon
Public bug reported: I have upgraded from 11.04 to 11.10, and having a computer with a Nvidia card I have installed the latest Nvidia driver thru the Ubuntu software center. On the desktop, on the top bar, the last icon I see is the one with my username account. However, there should be one more because when I place the mouse cursor one pixel to the left of that icon, and I click, a menu appears with a number of items like, e.g. log off, system settings, etc. In 11.04 that was the switch-off icon. N.B. I have tried to adjust the horizontal placement of the screen in the monitor, but have seen that there is nothing to the left. ** Affects: ubuntu Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/888485 Title: missing icon To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/888485/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 888487] [NEW] Default video card driver broken
Public bug reported: I have upgraded from 11.04 to 11.10. 11.10 comes with a default video driver that does not work on a computer that has a Nvidia video card. The desktop freezes to that there is no way out except by switching off the computer. I then installed the proprietary Nvidia driver thru the Ubuntu Softare Center, and have solved the problem. I think that the upgrade tool should check that the computer has a Nvidia card and install its driver instead of installing the default one. ** Affects: ubuntu Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/888487 Title: Default video card driver broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/888487/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 454722] Re: inotify does not watch /proc
Hi Fabio, yes, the same problem occurs in lucid. I have tested it right now and have seen that inotify does not work as expected. -Angelo -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] Re: inotify does not watch /proc
apport information
** Tags added: apport-collected
** Description changed:
Compile the following program (inotifyerr.c)
#include stdlib.h
#include stdio.h
#include sys/inotify.h
int main(int argc, char* argv[]){
int fd = inotify_init();
if (fd == -1){
perror(inotify_init);
}
char path[256];
sprintf(path,/proc/%s,argv[1]);
printf(watching %s\n,path);
int wd = inotify_add_watch(fd,path,IN_ALL_EVENTS);
if (wd == -1){
perror(inotify_add_watch);
}
char buf[1024];
ssize_t siz = read(fd,buf,1024);
if (siz == -1){
perror(inotify read);
}
printf(read done, bytes: %d\n,siz);
}
gcc inotifyerr.c
The program is supposed to watch events occurring on file /proc/nnn, where
nnn is passed as
argument to program invokation.
Then start a process in background, and watch it with the program above. E.g.
$ sleep 20
[1] 8246
$ ls /proc/8246
attr cpuset iomountinfo pagemap smapswchan
auxv cwd latency mounts personality stat
cgroup environ limitsmountstats root statm
clear_refs exe loginuid net schedstatus
cmdline fd maps oom_adj schedstatsyscall
coredump_filter fdinfo mem oom_score sessionidtask
$ ./a.out 8246
watching /proc/8246
^C
[1]+ Donesleep 20
Note that the background process and the inotifyerr one are run from
within the same terminal, same user, and that the latter has read
access to the file being watched.
No events are reported.
The expected behaviour of inotify is to report events on /proc files
and directories instead.
Additional information:
I have run the same test also with superuser privileges, but the result
is the same.
I have modified the test program so as to make the process to whatch
a child of the inotifyerr one. In this case inotify catches all the events.
- Ubuntu 9.04. 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:49:34 UTC
- 2009 i686 GNU/Linux
+ Ubuntu 9.04. 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:49:34 UTC 2009
i686 GNU/Linux
+ ---
+ AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.21.
+ Architecture: i386
+ AudioDevicesInUse:
+ USERPID ACCESS COMMAND
+ /dev/snd/controlC0: angelo 1376 F pulseaudio
+ CRDA: Error: [Errno 2] No such file or directory
+ Card0.Amixer.info:
+ Card hw:0 'NVidia'/'HDA NVidia at 0xfe028000 irq 23'
+Mixer name : 'Realtek ALC888'
+Components : 'HDA:10ec0888,1631e601,0011'
+Controls : 37
+Simple ctrls : 21
+ DistroRelease: Ubuntu 10.04
+ HibernationDevice: RESUME=UUID=335bd2d5-504f-4410-a53a-96814ee336e8
+ InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release i386 (20100429)
+ Lsusb:
+ Bus 002 Device 002: ID 046d:c315 Logitech, Inc. Classic New Touch Keyboard
+ Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
+ Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+ MachineType: Packard Bell BV IMEDIA 8425
+ NonfreeKernelModules: nvidia
+ Package: linux (not installed)
+ ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-24-generic
root=UUID=2258e664-9423-4566-ae33-52c12a4645ec ro quiet splash
+ ProcEnviron:
+ LANG=en_US.utf8
+ SHELL=/bin/bash
+ ProcVersionSignature: Ubuntu 2.6.32-24.41-generic 2.6.32.15+drm33.5
+ Regression: No
+ RelatedPackageVersions: linux-firmware 1.34.1
+ Reproducible: Yes
+ RfKill:
+ 0: phy0: Wireless LAN
+ Soft blocked: no
+ Hard blocked: no
+ Tags: lucid filesystem needs-upstream-testing
+ Uname: Linux 2.6.32-24-generic i686
+ UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
+ dmi.bios.date: 11/01/2006
+ dmi.bios.vendor: Phoenix Technologies, LTD
+ dmi.bios.version: M2N-NM 0401
+ dmi.board.name: M2N-NM
+ dmi.board.vendor: Packard Bell BV
+ dmi.board.version: 1.XX
+ dmi.chassis.asset.tag: 123456789000
+ dmi.chassis.type: 3
+ dmi.chassis.vendor: Packard Bell BV
+ dmi.chassis.version: Chassis Version
+ dmi.modalias:
dmi:bvnPhoenixTechnologies,LTD:bvrM2N-NM0401:bd11/01/2006:svnPackardBellBV:pnIMEDIA8425:pvrPB80107506:rvnPackardBellBV:rnM2N-NM:rvr1.XX:cvnPackardBellBV:ct3:cvrChassisVersion:
+ dmi.product.name: IMEDIA 8425
+ dmi.product.version: PB80107506
+ dmi.sys.vendor: Packard Bell BV
** Attachment added: AlsaDevices.txt
https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513676/+files/AlsaDevices.txt
--
inotify does not watch /proc
https://bugs.launchpad.net/bugs/454722
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] AplayDevices.txt
apport information ** Attachment added: AplayDevices.txt https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513677/+files/AplayDevices.txt -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] ArecordDevices.txt
apport information ** Attachment added: ArecordDevices.txt https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513678/+files/ArecordDevices.txt -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] Card0.Amixer.values.txt
apport information ** Attachment added: Card0.Amixer.values.txt https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513680/+files/Card0.Amixer.values.txt -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] BootDmesg.txt
apport information ** Attachment added: BootDmesg.txt https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513679/+files/BootDmesg.txt -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] Card0.Codecs.codec.0.txt
apport information ** Attachment added: Card0.Codecs.codec.0.txt https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513681/+files/Card0.Codecs.codec.0.txt -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] CurrentDmesg.txt
apport information ** Attachment added: CurrentDmesg.txt https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513682/+files/CurrentDmesg.txt -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] IwConfig.txt
apport information ** Attachment added: IwConfig.txt https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513683/+files/IwConfig.txt -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] Lspci.txt
apport information ** Attachment added: Lspci.txt https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513684/+files/Lspci.txt -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] ProcCpuinfo.txt
apport information ** Attachment added: ProcCpuinfo.txt https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513686/+files/ProcCpuinfo.txt -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] ProcModules.txt
apport information ** Attachment added: ProcModules.txt https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513688/+files/ProcModules.txt -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] PciMultimedia.txt
apport information ** Attachment added: PciMultimedia.txt https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513685/+files/PciMultimedia.txt -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] ProcInterrupts.txt
apport information ** Attachment added: ProcInterrupts.txt https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513687/+files/ProcInterrupts.txt -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] UdevDb.txt
apport information ** Attachment added: UdevDb.txt https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513689/+files/UdevDb.txt -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] WifiSyslog.txt
apport information ** Attachment added: WifiSyslog.txt https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513691/+files/WifiSyslog.txt -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 454722] UdevLog.txt
apport information ** Attachment added: UdevLog.txt https://bugs.edge.launchpad.net/bugs/454722/+attachment/1513690/+files/UdevLog.txt -- inotify does not watch /proc https://bugs.launchpad.net/bugs/454722 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 370853] Re: POSIX cancallation points not supported
Hello Fabio, the error that I have reported in the man page of pthread_cancel has been corrected. That man page has been updated both in 9.04 and in the releases after it. You can then close the bug. Thank you -Angelo Borsotti -- POSIX cancallation points not supported https://bugs.launchpad.net/bugs/370853 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 369757] Re: hibernate does not work
Hello, I have tested again the hibernation in Ubuntu 10.04, and have seen that the problem has been solved. You can then close the bug. Thank you -Angelo Borsotti -- hibernate does not work https://bugs.launchpad.net/bugs/369757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 488691] Re: sigaltstack man page error
Hello Jeremy, the problem is still there in 10.04. The documentation page: http://manpages.ubuntu.com/manpages/lucid/en/man3/sigaltstack.3posix.html is correct, but the man page (i.e. what is shown by entering the command man sigaltstack) is not, and is different from the page at the url above. I have no idea what other information I could provide for this bug since all what is needed to see it is to enter the man sigaltstack command and read the first line below DESCRIPTION: sigaltstack() allows a process to define a new alternate ... which is not correct because the stack is that of a thread, not that of a process. The url above instead mentions explicitly that the stack is that of the current thread. To remove the bug, the man page file for sigaltstack must be changed to make it consistent with the url above. Thank you -Angelo Borsotti -- sigaltstack man page error https://bugs.launchpad.net/bugs/488691 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 489497] Re: timer_delete does not cancel the thread to run the function
Hello Jeremy, I do not understand why the bug was marked as incomplete. The bug report contains all the information needed to reproduce the problem. I have included a sample program that shows the bug in it. I have run today that program on 10.04 and have seen again the same bug. Unfortunately I do not have a way to install the latest development version, but unless that specific issue has been addressed in it, it is likely that the very same bug is still unsolved. Could you reopen the bug and mark in it the all the info needed to solve it is present, or tell me what other info I must provide? Thank you -Angelo Borsotti -- timer_delete does not cancel the thread to run the function https://bugs.launchpad.net/bugs/489497 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 370853] Re: POSIX cancallation points not supported
Hi Fabio, I am on vacation at the moment and have no way to test the bug with lucid, but I will do it as soon as I will come back. Thank you -Angelo -- POSIX cancallation points not supported https://bugs.launchpad.net/bugs/370853 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[h-e-w] edt emulation, arrows
Enable the EDT emulation. Then press the key with the dot on the numeric keypad. This starts the selection of text. Press then the left arrow. The selection disappears, while it should not. The arrows serve to enlarge the portion of the text selected. In GNU Emacs 23.1.50.1 (i386-mingw-nt6.1.7600) of 2009-06-30 on LENNART-69DE564 (patched) Windowing system distributor `Microsoft Corp.', version 6.1.7600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ITA value of $XMODIFIERS: nil locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: HTML Minor modes in effect: global-hl-line-mode: t server-mode: t cua-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t noticeable-minibuffer-prompts-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: n g e SPC t h e SPC d i s p l a y e d SPC t e r m i n a t i o n SPC w h e n SPC t h e r e SPC i s SPC n o SPC a c t i v e help-echo wheel-down wheel-down double-wheel-down wheel-down double-wheel-down triple-wheel-down wheel-down double-wheel-down triple-wheel-down f12 kp-multiply p e r f e c t p a kp-left kp-multiply kp-multiply kp-multiply kp-insert up up up up up up up up up up up up up up up down-mouse-1 mouse-movement mouse-movement drag-mouse-1 down-mouse-3 mouse-3 help-echo down-mouse-1 mouse-1 r i g a SPC 4 SPC d a l SPC f o n d o : SPC down-mouse-1 drag-mouse-1 down-mouse-1 mouse-movement drag-mouse-1 down-mouse-3 mouse-3 help-echo help-echo help-echo help-echo help-echo backspace f12 kp-space f12 kp-multiply z e r o kp-left kp-multiply kp-insert up up up up up kp-insert kp-insert kp-insert kp-insert kp-insert f12 kp-insert SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC p w e r backspace backspace backspace e r f e c t SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC z e r o SPC SPC SPC SPC SPC SPC SPC SPC SPC help-echo help-echo help-echo help-echo C-\ x w C-\ help-echo down-mouse-1 mouse-1 SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC - SPC SPC SPC SPC SPC SPC SPC SPC help-echo C-\ s o m a i C-\ left left left kp-delete right right left left left kp-delete right right right left left left kp-insert kp-insert kp-delete kp-insert kp-insert f12 kp-delete up up kp-delete down down right right right kp-insert kp-insert up up up up up up help-echo help-echo help-echo help-echo M-x r e s p tab backspace backspace p o tab help-echo down-mouse-1 mouse-2 Recent messages: Saving file c:/users/angelo/Desktop/greco/verbigrecoanalisi.html... Wrote c:/users/angelo/Desktop/greco/verbigrecoanalisi.html Undo! Saving file c:/users/angelo/Desktop/greco/verbigrecoanalisi.html... Wrote c:/users/angelo/Desktop/greco/verbigrecoanalisi.html Auto-saving...done Selected text CUT to kill ring [2 times] Auto-saving...done Mark set [4 times] Making completion list...
Re: [Bug 370967] Re: raise(3) produces SI_TKILL in siginfo_t
Philippe, then the man page must be changed because it is telling something that is not true. -Angelo -- raise(3) produces SI_TKILL in siginfo_t https://bugs.launchpad.net/bugs/370967 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 489497] Re: timer_delete does not cancel the thread to run the function
apport information
** Tags added: apport-collected
** Description changed:
timer_create(), when told to run a function at time expiration, creates
immediately an ancillary thread
(it could have created it when armed, or even better, when expired). When the
timer is deleted, the
ancillary thread does not get cancelled. Not even if it was created as
detached. That ancillary thread
must instead be terminated, otherwise it wastes resources (and prevents the
process to terminate
normally).
Program that shows it:
#include stdlib.h
#include stdio.h
#include time.h
#include signal.h
#include unistd.h
#include dirent.h
#include stddef.h
// enumerate all threads of this process
static void listthreads(char* str){
printf(threads %s\n,str);
char buf[100];
sprintf(buf,/proc/%d/task,getpid());
DIR* dir = opendir(buf);
int len = offsetof(struct dirent,d_name) +
pathconf(buf,_PC_NAME_MAX) + 1;
struct dirent* entryp;
entryp = malloc(len);
struct dirent* res;
for (;;){
readdir_r(dir,entryp,res);
if (res == NULL) break;
if (entryp-d_name[0] == '.') continue;
printf(%s\n,entryp-d_name);
}
closedir(dir);
printf(end of list\n);
}
void timerfunction(sigval_t sigval){
}
int main(int argc, char* argv[]){
printf(main %d\n,getpid());
struct sigevent event;
event.sigev_notify = SIGEV_THREAD;
event.sigev_notify_function = timerfunction;
event.sigev_notify_attributes = NULL;
event.sigev_value.sival_ptr = (void*)pthread_self();
timer_t timer_id;
if (timer_create(CLOCK_REALTIME,event,timer_id) 0){
perror(timer create);
}
listthreads(after timer creation);
struct itimerspec itime; // arm timer
itime.it_value.tv_sec = 10;
itime.it_value.tv_nsec = 0;
itime.it_interval.tv_sec = 0;
itime.it_interval.tv_nsec = 0;
if (timer_settime(timer_id,0,itime,NULL) 0){
perror(timer settime);
}
listthreads(after timer arming);
timer_delete(timer_id); // disarm and delete timer
listthreads(after timer delete);
}
$ gcc timerdelete.c -lrt
$ ./a.out
main 9958
threads after timer creation
9958
9959
end of list
threads after timer arming
9958
9959
end of list
threads after timer delete
9958
9959
end of list
ProblemType: Bug
Architecture: i386
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC0: angelo 1643 F pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
Card hw:0 'NVidia'/'HDA NVidia at 0xfe028000 irq 23'
Mixer name : 'Realtek ALC888'
Components : 'HDA:10ec0888,1631e601,0011'
Controls : 37
Simple ctrls : 21
Date: Sat Nov 28 10:24:21 2009
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=335bd2d5-504f-4410-a53a-96814ee336e8
InstallationMedia: Ubuntu 9.10 Karmic Koala - Release i386 (20091028.5)
Lsusb:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 046d:c315 Logitech, Inc. Classic New Touch Keyboard
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: Packard Bell BV IMEDIA 8425
NonfreeKernelModules: nvidia
Package: linux-image-2.6.31-15-generic 2.6.31-15.50
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-15-generic
root=UUID=4643cae4-fc87-4dec-a73c-04ce2ccfc02a ro quiet splash
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-15.50-generic
RelatedPackageVersions:
linux-backports-modules-2.6.31-15-generic N/A
linux-firmware 1.25
RfKill:
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
SourcePackage: linux
Uname: Linux 2.6.31-15-generic i686
dmi.bios.date: 11/01/2006
dmi.bios.vendor: Phoenix Technologies, LTD
dmi.bios.version: M2N-NM 0401
dmi.board.name: M2N-NM
dmi.board.vendor: Packard Bell BV
dmi.board.version: 1.XX
dmi.chassis.asset.tag: 123456789000
dmi.chassis.type: 3
dmi.chassis.vendor: Packard Bell BV
dmi.chassis.version: Chassis Version
dmi.modalias:
dmi:bvnPhoenixTechnologies,LTD:bvrM2N-NM0401:bd11/01/2006:svnPackardBellBV:pnIMEDIA8425:pvrPB80107506:rvnPackardBellBV:rnM2N-NM:rvr1.XX:cvnPackardBellBV:ct3:cvrChassisVersion:
dmi.product.name: IMEDIA 8425
dmi.product.version: PB80107506
dmi.sys.vendor: Packard Bell BV
+ ---
+ AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.21.
+ Architecture: i386
+ AudioDevicesInUse:
+ USERPID ACCESS COMMAND
+ /dev/snd/controlC0: angelo 1356 F pulseaudio
+ CRDA: Error: [Errno 2] No such file or directory
+ Card0.Amixer.info:
+ Card hw:0 'NVidia'/'HDA NVidia at 0xfe028000 irq 23'
+Mixer name : 'Realtek ALC888'
+Components :
[Bug 489497] AplayDevices.txt
apport information ** Attachment added: AplayDevices.txt http://launchpadlibrarian.net/48567207/AplayDevices.txt -- timer_delete does not cancel the thread to run the function https://bugs.launchpad.net/bugs/489497 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 489497] ArecordDevices.txt
apport information ** Attachment added: ArecordDevices.txt http://launchpadlibrarian.net/48567208/ArecordDevices.txt -- timer_delete does not cancel the thread to run the function https://bugs.launchpad.net/bugs/489497 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 489497] BootDmesg.txt
apport information ** Attachment added: BootDmesg.txt http://launchpadlibrarian.net/48567212/BootDmesg.txt -- timer_delete does not cancel the thread to run the function https://bugs.launchpad.net/bugs/489497 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 489497] Card0.Amixer.values.txt
apport information ** Attachment added: Card0.Amixer.values.txt http://launchpadlibrarian.net/48567214/Card0.Amixer.values.txt -- timer_delete does not cancel the thread to run the function https://bugs.launchpad.net/bugs/489497 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 489497] Card0.Codecs.codec.0.txt
apport information ** Attachment added: Card0.Codecs.codec.0.txt http://launchpadlibrarian.net/48567216/Card0.Codecs.codec.0.txt -- timer_delete does not cancel the thread to run the function https://bugs.launchpad.net/bugs/489497 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 489497] CurrentDmesg.txt
apport information ** Attachment added: CurrentDmesg.txt http://launchpadlibrarian.net/48567218/CurrentDmesg.txt -- timer_delete does not cancel the thread to run the function https://bugs.launchpad.net/bugs/489497 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 489497] IwConfig.txt
apport information ** Attachment added: IwConfig.txt http://launchpadlibrarian.net/48567227/IwConfig.txt -- timer_delete does not cancel the thread to run the function https://bugs.launchpad.net/bugs/489497 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 489497] Lspci.txt
apport information ** Attachment added: Lspci.txt http://launchpadlibrarian.net/48567243/Lspci.txt -- timer_delete does not cancel the thread to run the function https://bugs.launchpad.net/bugs/489497 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 489497] PciMultimedia.txt
apport information ** Attachment added: PciMultimedia.txt http://launchpadlibrarian.net/48567245/PciMultimedia.txt -- timer_delete does not cancel the thread to run the function https://bugs.launchpad.net/bugs/489497 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 489497] ProcCpuinfo.txt
apport information ** Attachment added: ProcCpuinfo.txt http://launchpadlibrarian.net/48567247/ProcCpuinfo.txt -- timer_delete does not cancel the thread to run the function https://bugs.launchpad.net/bugs/489497 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 489497] ProcModules.txt
apport information ** Attachment added: ProcModules.txt http://launchpadlibrarian.net/48567249/ProcModules.txt -- timer_delete does not cancel the thread to run the function https://bugs.launchpad.net/bugs/489497 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
