=== vicky_ is now known as Guest59152 === pjarnahomzz is now known as pjarnahom [05:08] hi all i am new to linux [05:09] please tell me how to get package from net [08:52] hi === jsimmons_ is now known as jsimmons === ext2 is now known as ext3 === persia` is now known as persia [12:45] hi === daker_ is now known as daker === pjarnahom is now known as pjarnahomzz === ext2 is now known as ext3 === bauerj|away is now known as bauerj [16:50] Just to be sure noone is here too early - my talk is at 18:00 UTC, which is in two hours earliest. :) [16:51] ah! [16:51] Thu Jul 22 17:51:46 CEST 2010 [16:51] cest = utc+2 [16:53] Also, I'd like to point out to not make this too messy, this channel will get muted at that time with only me being able to speak up. Be invited to also hang out in #ubuntu-classroom-chat and ask your questions in there. If you prefix them with QUESTION ClassBot will pick them up and offer them to me for relaying into here. [17:10] make sure you don't forget the colon, so QUESTION: === tenach_ is now known as tenach[Laptop] === tenach[Laptop] is now known as tenach === MichealH_ is now known as MichealH [18:57] aloha [18:58] yo ppl [18:58] nameste === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Packaging Training Session - Current Session: Working with Debian BTS for (not only) Ubuntu Contributors - Instructor: Rhonda [19:00] Like mentioned before, this channel will become moderated soonishly, so be reminded again to take questions prefixed with QUESTION: to #ubuntu-classroom-chat so that the ClassBot can pick them up. [19:01] Welcome everybody. Todays topic for this talk is the Debian BTS. [19:01] BTS stands for Bug Tracking System. Some might question themself, why being bothered? We are Ubuntu, right? [19:02] Wrong. ;) [19:02] As lined out in last weeks devweek talk that Laney gave together with me it is important to work together with the Debian people. [19:02] If you might want to catch up on the why - read up its log from the archive: https://wiki.ubuntu.com/MeetingLogs/devweek1007/WorkDebian [19:03] I'd like to start off with the basic web interface that the BTS offers. Contrary to what launchpad offers, this is a readonly interface, so it only offers query possibilities. [19:04] http://bugs.debian.org/ redirects you to a basic page in which you have some few forms that allow you to query the web interface. But there are very handy shortcut options that are useful to keep in mind. [19:05] If you would be a package maintainer, or might want to track the open bugs of a specific maintainer, you would query e.g. http://bugs.debian.org/rhonda@debian.at (this is my own overview) [19:06] Please notice that this doesn't contain co-maintained packages - this is a wishlist bugreport that is open against the BTS. [19:07] If on the other hand as user you would like to know which of the bugs you have reported are still open, you would use the from: keyword, like http://bugs.debian.org/from:rhonda@debian.at to get an overview of the still outstanding bugreports that you opened, to be able to remind yourself of the status and potential send a followup to question what's going on. [19:09] There is also the posibility to query for bugreports against specific packages one is interested in. One approach would be to query for a specific binary package, like e.g. http://bugs.debian.org/wesnoth-1.8 [19:10] To refer to a specific _source_ package (which would list all bugreports against the individual binary packages) you use the src: prefix, like http://bugs.debian.org/src:wesnoth-1.8 [19:11] Finally, if you know a specific bugnumber, you would just query http://bugs.debian.org/459935 [19:12] These are the most important shortcuts for querying the webinterface, at least the basic ones. You can see at the end of the overview queries a form with which you can tweak the overview a bit, too. [19:14] Also in the overview you have for each bugreport several information listed: [19:15] First of all obviously the unique bug number by which the bug is referenced. Next is a group of flags which give information about the bug status. If you hover with your mouse over the individual entries you'll receive a tooltip expansion what they stand for. [19:16] Also you can click into that part to get a bit more information about the bug at hand. Next would be the binary package the bug is filed against, and then the subject. The rest of the information should also be pretty self explaining. [19:17] Please notice that package maintainers (or maintenance teams) can tweak the grouping of the bugs in their overview page, like you can see on e.g. http://bugs.debian.org/qa.debian.org or on http://bugs.debian.org/ftp.debian.org [19:18] How to do that would explode the context of this session though, so I won't cover it here. [19:19] This covers the webinterface pretty well me thinks, let's move on to reporting some bugs, won't we. :) [19:20] I mentioned that the web interface is read-only, so how to report bugs? While the web interface is pretty useful, you might have noticed download links for mailbox files in individual bugreports. [19:20] This gives somehow the impression as wether it would work by emails - and you are right on that! The real main interface to the BTS is email based. [19:22] The webpage http://www.debian.org/Bugs/Reporting gives a short guide how to use it, I'll cover a few bits of here though. [19:23] There is are some helpful tools that I can encourage to report bugs with, they though depend on a local running mailserver. Laney encourages you to use ssmtp which is pretty easy to set up and get used to for sending out mails. [19:23] nigelb asked: Is there any plan for a web manipulatable interface for BTS? [19:24] There is a GSoC project proposed since a while, unfortunately noone signed up to do it, especially since the BTS depends so heavily on emails and would require some sort of login mechanism or challenge-response style things. [19:25] So plans are there, noone though did pick up on it to work on it. Most people are happy enough with the email approach. [19:26] Anyway, about the tools for reporting, there is reportbug to be run in a terminal, and reportbug-ng for a graphical interface. [19:27] Personally I have to admit that I didn't use the later so I can talk about the former. To not have a confusion for regular Ubuntu users reportbug is changed in Ubuntu to _not_ send mails to the Debian BTS by default. [19:28] One either has to use the "-B debian" switch, or put "bts debian" into the .reportbugrc (thanks for mentioning that, cjwatson) [19:29] Even though reportbug is a textbased interface it is extremely helpful in the way that it gathers additional information that the package maintainer might want to know, like dependencies or debconf answers that were given on installation. [19:30] reportbug has different operating modes that one can set - those tweak what kind of additional information the user is asked about. The default mode is set to novice and can also be tweaked through the .reportbugrc file. [19:31] Another very very handy tool is called "bts" (nomen est omen) and is included in the devscripts package. [19:33] It can be used to change meta information of different bugreports from the commandline. If you more regularly have to change bugreports you really should get used to this tool, it can increase your performance a fair bit. Just in case, if you do, please don't forget to also leave a helpful comment with adding "# some remark" on why the change was done so it's more obvious. [19:34] But like said, the main interface is emails, and all these tools only actually craft emails in the background for you. [19:34] Thus, I also like to mention the format of said emails. There are three important mail addresses that the BTS recognizes: [19:35] submit@bugs.debian.org - mails sent to this address will open a new bugreport. [19:35] These mails require some additional "Pseudo" headerlines at the start of your email body to do something useful. ;) [19:36] The subject of the mail itself will be taken as subject of the bugreport, so be sure to make it as clear as possible (like you try to do with all your emails anyway, right? ;)) [19:37] The most important pseudo header is "Package: foo". This means that this newly submitted bugreport is for the package named foo. [19:37] Second important pseudo header is "Version: 1.2.3". This is important because the Debian BTS has this special thing called version tracking. [19:38] Through the version information it knows which bugs apply to which release, and it is also an important information to the package maintainer obviously. [19:38] sense asked: In Ubuntu we have a lot of packageless bugs that are reported by people who don't know against what package to report the bugs. The Bug Squad has to find time and people to assign these bugs against the correct package. Does Debian have packageless bugs? [19:40] Yes, there is. There are several different approaches here. One thing is the "Package: general". Bugreports against that pseudo package gets sent to debian-devel and get addressed though that. [19:41] Also bugreports against non-existing packages aren't lost or go to the void, there are people explicitly hunting those down, and I think also bugreports with no Package: header do land in some special place where interested people can check on them. [19:43] There are also some more things in the submit mails that can get set: "Severity: important" for the importance of the bugreport (known values are critical, grave, serious, important, normal (default), minor and wishlist) [19:44] So a wishlist type report is also filed through the same interface as "bugreport". [19:45] Also, one can set "Tags: patch" on a bugreport when one adds a patch to it to make it easy for people who like to check patches and fast-track such bugreports (so adding patches is always a good idea ;)) [19:46] mistrynitesh asked: won't every reporter set the Severity: Critical? Is there a way to govern this? [19:46] No, they don't. :) Most users don't bother at all setting a severity and have the bugs dropped in as normal. [19:47] Also, tweaking these things is easy and is usually done quickly, which I want to come to now. :) [19:48] There is also the control@bugs.debian.org mailaddress which is the one that the former mentioned "bts" tool sends its mails to. [19:48] It can be often seen when package maintainers followup to a bugreport that they send a Cc to this address in addition to the bugnumber mailaddress (which is @bugs.debian.org btw.) and add some other pseudo headers. [19:49] The control facility take a tiny bit different syntax than the submit one. [19:50] There are are 10 minutes remaining in the current session. [19:50] And it is mainly documented on http://www.debian.org/Bugs/server-control [19:51] Things that are often used is "reassign ". This will reassign the given bugnumber to a different package. [19:51] Please notice that this will lose the bugs version information so if you are aware that this affects a specific version of the other package add it as additional argument. [19:52] Quick strawpoll question: What I feared happened - the time did run faster than I was able to type, and I still have stuff on my agenda to adress. [19:53] Do people prefer if I continue the session (there is nothing planed after this one) or if we cut it and continue another time? [19:53] I will in the meantime continue anyway so that we don't lose time by this dilemma. Please raise your voice on this topic in #ubntu-classroom-chat [19:54] Addressing mistrynitesh's question there is the "severity " command which can fix the severity in case a bugreporter has a non-fitting opinion in comparison to the package maintainer. ;) [19:55] There are are 5 minutes remaining in the current session. [19:56] Please also notice that anyone can change bugreports - so at times it happens that bugreports switch the severity back and forth, this is not a good style, please respect the package maintainer's opinion on it and try to convince them with reasoning - repeated severity inflation have resulted in getting banned from the control address in the past. [19:57] If you notice that the bugreport is found in a specific version you can use the "found " to mark that. [19:57] Please notice that this is often enough only useful when you have found it in an _older_ version too, like in the stable release when a bug was reported against the version in Debian testing. [19:58] forwarded is also a pretty useful control command to mark that a bugreport has got forwarded. You set it to the URL or email address where you forwarded the bug to. [20:00] If you set it to a URL it can be pretty helpful because there is a service that checks known upstream bug trackers and can set specific tags as notification for the maintainer. [20:00] Which brings me to the "tags" command. With this one can set some helpful marks onto a bugreport. [20:01] The syntax is "tags + tag1 tag2 - tag3 tag4" - so one can add tags and remove in a single line. [20:01] Or set the tags explicit to a specific set with = [20:03] Often used tags are moreinfo when the user is asked to submit additional information, unreproducible if the maintainer isn't able to reproduce the issue, pending when the bug is fixed within the maintainer's VCS but not uploaded yet, security for bugreports that are relevant for the security team, upstream to mark bugreports that aren't happening just because of the packaging, confirmed, and many more. [20:04] Also there are tags for each release. Please notice that those have change its meaning since version tracking got implemented, so please don't use them unless you know what you are doing. I will mention an example for them a bit later. ;) [20:05] There are more commands that control accepts, you can find them all listed in the former mentioned URL, http://www.debian.org/Bugs/server-control - and usually these control mails are ended with "thanks" or "stop" to tell the control server to stop processing the mail here so it doesn't produce errors. [20:05] This ending markers are especially useful when following up to bugreports and sending a cc to control@ [20:06] One _very_ common problem people stumble into is using the @bugs.debian.org mail address. [20:06] Often enough people expect this such mails to get sent to the bug reporter - but they won't. [20:07] These bugs only go the maintainer of the package (and people subscribed through the http://packages.qa.debian.org/ to the according package) [20:08] If one want to reach out to the submitter of the bugreport they have to explicitly be put in the to line, but there is a helpful bugs address: -submitter@bugs.debian.org [20:09] This will get to the submitter of the bugreport then too. Keep that in mind, otherwise you will fall into the pit that many package maintainers did fall into and wonder why you don't receive any response from the submitter at all. [20:10] Alright. This is the main part of my talk. Thanks for your attention! [20:10] … though, I won't end here, because I mentioned in my announce that there is the question pending why some bugreports won't get archived. [20:10] And you want to know why so, right? [20:11] Some part of this is rooted in the version tracking, which I want to try to explain now. [20:12] mistrynitesh asked: When one reports a bug, is he/she subscribed to that bug and receive updates on it? [20:12] To some degree yes, to some no. [20:13] Like mentioned, @bugs.debian.org doesn't reach the submitter of the bugreport. [20:13] But one thing that _always_ reaches the submitter is closing a bugreport. [20:14] Closing a bugreport is either done by adding a "Closes: #1234" into the debian/changelog and uploading the package (the way to do it when the bug requires changes to the package) [20:15] Otherwise people can send mails to -done@bugs.debian.org explaining why the bugreport is closed. If it was closed in a former upload already but reported later or forgotten to be closed with the upload, this mail should contain a "Version: 1.2.4" in its first line so that the version tracking can do its good for this bugreport, too. [20:16] yofel asked: there is a possibility to subscribe to bug reports.. -subscribe@b.d.o - what mails do you get if you do that? [20:18] From what I perceived this makes one receive all mails that are sent to @b.d.o, including control@ processing mails, but don't pin me down on that. [20:18] So, back to version tracking: When you go to an individual bug page, let's take http://bugs.debian.org/580391 as example here, you'll notice a graph in the upper corner. [20:19] That graph shows the information that version tracking works on. [20:21] You will notice that there is a green box with (testing, unstable) in it, and a red circle with (stable) in it. [20:21] green means good versions, the bug is fixed in those, red means bad versions, the bug is not fixed in those. [20:22] On the left hand side you see the information of the bug, like Severity: grave, Found and Fixed in versions, and that the bug actually is Done. [20:22] Usually a bugreport gets archived after being done for 28 days in testing. [20:23] Given that this bugreport is of severity grave, it is considered release-critical. [20:23] release-critical means that Debian doesn't want to release with a package that contains such a bugreport. [20:24] So how did this bugreport happen to be affecting stable, then? It was reported after stable was released, that's why. [20:25] Actually though, this bugreport doesn't really affect stable, because the cause of this happened after the release, squeakvm did still exist in the stable release. It's just that the found version was the same in unstable at the time this was reported. [20:26] so this is where the release tags come into play. I am going to mark this bugreport as not affecting stable by tagging it with squeeze sid, like this: [20:26] bts tag 580391 + squeeze sid '# not affecting stable' [20:26] We will have to wait for the mail to arrive at the BTS to se its reult. [20:27] If you click on the "etoys" link at the top now you see the overview of the bugreports against the etoys package. [20:28] Like mentioned when you click on the [G|+|☺] part in that page you get the additional information. [20:28] You'll see that there is no information about archival in there currently. We'll come back to this in a few minutes,. [20:29] When you look at http://bugs.debian.org/581337 now, which is another release critical bugreport, you can see it also be seen as affecting stable. [20:29] You will notice that this bugreport doesn't has any found version. [20:30] This makes the BTS think that the bugreport affects every version it is aware of. [20:30] The root of this is that the bug got reassigned without any version information. This is also easy to fix because the version information in the original report is actual correct. [20:31] bts found 581337 0.18-1 "# readd found version lost in reassign" [20:31] This will fix the version information for this done bugreport and mark get it closed for real and archiveable. :) [20:33] This now is a more difficult issue now to decypher: http://bugs.debian.org/src:isync - who gets an idea why there are so many resolved bugreports that doesn't get archived? [20:33] If we choose any individual bugreport of those, e.g. http://bugs.debian.org/177280 the graph has some interesting content. [20:34] You can click on it to receive a larger version in case you still don't see it. ;) [20:34] The topmost green box contains (testing, unstable, stable) while the topmost red circle contains (unstable) [20:34] Now how is that possible? Having unstable both fixed and not-fixed? [20:36] Here the packages interface comes handy: http://packages.debian.org/unstable/isync gives us some more information on this confusing graph. [20:37] You will notice that almost all architectures have the same version - except one. [20:37] Given that hurd-i386 is in a special state, it's not part of testing and not a release architecture, the way to fix the isync issues is to request removal of the package for this architecture. [20:39] I found the same issue last week in another package: wormux. You can see still some not-yet archived bugreports on http://bugs.debian.org/src:wormux - but when you click on the informational part there you'll see that they "Can be archived in 8 days" now that the removal of the outdated package on the hurd architecture was processed. [20:40] If we now look back at http://bugs.debian.org/etoys ypi [20:41] If we now look back at http://bugs.debian.org/etoys you'll see when you click on [G|+|☺] after a reload that the bugreport is set to be able to get archived in 28 days and also the added squeeze sid tags. [20:42] Likewise in http://bugs.debian.org/581337 you see the fixed adjusted version graph, it doesn't contain the stable version in there anymore and will be able to get archived. [20:43] I guess this should cover the most confusing things that can happen with version tracking and how to get them fixed. Please don't refrain to ask when you are unsure - even though almost all changes can be undone easily it might annoy someone. [20:44] … and I hope I didn't bore you too much and you all fell asleep in the meantime! [20:45] I guess we can start a final round of questions, if I didn't overflow your brains with too many information in too short time. [20:46] As final reminder, there are some Debian Developer still hanging out in #ubuntu-debian which are working on better collaboration so if you don't want to expose yourself on more specific Debian channels feel invited to come by and ask in there if unsure. [20:47] … scratch that "still", we won't run away when you come. ;) === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi === daker_ is now known as daker